HK1062971B - Data access management system and management method using access control ticket, data access management system, memory-equipped device, data access management method - Google Patents

Description

Data access management system and management method using access control certificate, data access management system, memory mounting device, data access management method

Technical Field

The invention relates to a data access management system, a memory mounting device, a data access management method and a program storage medium. More particularly, the present invention relates to a data access management system, a memory installation device, a data access management method, and a program storage medium, which divide 1 memory into a plurality of areas (partitions) and store data managed by a service provider or a related entity in each partition, thereby enabling a user to install a device with 1 memory for use by various services.

Background

Heretofore, as a device for holding a memory, a tape medium, a flexible disk, a hard disk, an optical disk, a semiconductor medium, and the like have been used. Among them, a semiconductor medium capable of securely managing a memory in a device is attracting attention. The reason for this is that the semiconductor memory is easy to realize a structure that is difficult to access from the outside, i.e., a tamper-resistant structure.

The tamper-proof structure can be realized, for example, by making the device a monolithic semiconductor structure, providing a control unit, a memory control unit, a nonvolatile memory, a voltage detection device, a frequency detection device, and the like on the chip, and interposing an interlayer such as an aluminum layer between the control unit, the memory control unit, the nonvolatile memory, the voltage detection device, the frequency detection device, and the like, so that the nonvolatile memory cannot be easily read from and written to from the outside.

A conventional memory structure of such a security device will be described with reference to "a conventional memory structure" in fig. 96. The memory of fig. 96 shows a memory structure that can be used as electronic money, for example. As shown in fig. 96, the storage area is roughly divided into 3 areas. Namely a data area, a memory management area, a system area.

In the data area, data is stored based on the "data structure" stored in the head of each data, and in this example, various data such as the user's name, address, telephone number, amount of money, memo, record, and the like are stored. In the memory management area, a storage address, an access method, an access authentication key, and the like for accessing each data of the data area are stored. For example, it is shown that access to data 1 (user name) in the data area can be performed in a Read Only (Read Only) manner by using an access authentication key (0123). In the system area, a device Identifier (ID), a memory management key that is an authentication key for securing a storage area in the data area, and the like are stored.

The data area of the storage device shown in fig. 96 may be structurally divided into a plurality of data areas, and these divided data areas may be managed by different service agents, for example, if electronic money, by respectively different electronic money service providing agents (for example, different banks). The data of each divided area can be read out and written in (for example, update of balance data) by a user using a reader/writer (a dedicated reader/writer, a PC, or the like) as a device access device provided in a shop for selling goods using electronic money, for example, in addition to each service providing main body.

The relationship between the administrator and the user having the secure device divided into a plurality of data areas as shown in fig. 96 is shown in "memory administrator, user" of fig. 97. As shown in fig. 97, there are a memory manager as a transmission master of the secure device and a memory user who requests the memory manager to allocate a data area and use the allocated memory. As memory users, data 1 user to data 6 user are shown. The memory user is, for example, a bank, a shop, or the like in the above-described examples of electronic money.

The memory manager grasps the memory management key for access control for securing the storage area, and allocates the memory (divided data area) of each memory user using the memory management key. The memory user can access the memory in each allocated data area by grasping the access authentication key for accessing the data in each data area. As the access mode, there are various modes such as reading (Read), writing (Write), and balance reduction (Decrement), and it is possible to individually set an access authentication key according to various processing modes and set whether or not to perform individual processing.

For example, since the data 4 in the memory shown in fig. 96 is money amount data, the user of the data 4 can perform a Decrement (Decrement) process and a Read/Write (Read/Write) process on the data 4 as shown in fig. 97. As shown in the right table of fig. 96, since the access keys are different in the Decrement (increment) process and the Read/Write (Read/Write) process of the data 4, it is necessary to access the memory using the access keys corresponding to the respective processes.

Fig. 98 is a diagram for explaining a memory manager's memory securing process for allocating a certain data area in a storage device to a memory user. As shown in "memory securing mode" of fig. 98, a memory manager performs securing management of a data area for a memory device shown on the right side of the figure by using a memory securing Reader/Writer (R/W) shown on the left side of the figure. In a memory securing Reader/Writer (R/W: Reader/Writer), an NVRAM (Non-Volatile random access memory) for keeping memory management keys secure is provided. Further, the memory securing R/W may be a dedicated reader/writer R/W of the secure device, or when the secure device is a device having an I/F such as USB or PCMCIA, a device capable of reading and writing through these interfaces, for example, a PC.

To secure the memory with R/W, the device ID is first read out from the security device. An authentication key is then generated within the R/W using the memory management key and the device ID, and mutual authentication is performed with the secure device using the generated authentication key. The mutual authentication process may be performed, for example, in accordance with mutual authentication based on a common key system (for example, ISO/IEC 9798-2).

After the mutual authentication is successful, the R/W encrypts the data structure, the data volume, the access method, and the access authentication key with the session key, and sends a command to the secure device after adding an MAC (message authentication Code) value for data verification as necessary. The security device that has received the command decrypts the received data and performs verification of the tampering of the data by MAC verification processing as necessary, then secures a storage area in the data area of the memory according to the amount of data in the received data, and writes the secured address, access method, and access authentication key of the memory into the data management area while writing the data structure into the secured area.

In the above manner, a plurality of divided data regions can be set in the storage device. Hereinafter, a memory access method for a memory device having a plurality of divided data regions will be described with reference to "the memory access method" in fig. 99. The reader/writer on the left side of fig. 99 is a memory access reader/writer (R/W) owned by a memory user, and is configured by a dedicated R/W, a PC, or the like, as in the above-described memory securing R/W. A memory access reader/writer (R/W) is provided with an NVRAM for keeping the access authentication key secure. To access the data area of the secure device with R/W, the device ID is first read from the secure device. An authentication key is then generated within the R/W 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 mutual authentication is successful, the R/W performs predetermined access to the data of the data area corresponding to the access authentication key.

At this time, since the access method is defined in the memory management area, for example, as shown in "memory access method" of fig. 99, when the access authentication for the Decrement (deletion) of the data 4 (amount data) is successful, the Decrement of the data 4 can be performed, but the increment or free rewrite processing cannot be performed. In this way, it is possible to set different access authentication keys for authentication processing according to various access modes, thereby improving the security of each data. For example, even when the amount reduction processing R/W is stolen and the NVRAM in the stolen amount reduction processing R/W is decoded, the possibility of performing illegal amount increase processing on the data 4 (money amount data) in the security device of fig. 99 can be reduced.

Generally, a cash receiving terminal can improve security as in an ATM, but in many cases, a payment terminal is used as a cash collector at the time of delivery of a product in a shop or the like, and the installation location is varied, so that the risk of fraudulent use of the terminal is high, and it is difficult to improve security. Therefore, it is effective to constitute different access authentication keys for data access.

In the above-described conventional usage mode of a storage device having a partitioned data area, the authentication process using a memory management key and the authentication process using an access authentication key are executed in the data area securing process of the memory and the access process of each data area, respectively, and each process is executed separately.

As described above, in the configuration in which the common key is applied to the memory management key and the access authentication key, there is an advantage that authentication can be performed and whether or not access is permitted can be determined by one-time processing, but there is a disadvantage that once the authentication key is leaked, memory access is possible with the leaked key, and there is a problem in security.

Further, in order to reduce the cost of a reader/writer (R/W) that accesses a storage device, a configuration may be considered in which no encryption algorithm is installed in the reader/writer (R/W), but if such a configuration is adopted, all processes of authentication with the device and encryption of communication data cannot be executed, and therefore, the reader/writer is not suitable for use as a reader/writer for a device that holds user amount data, other user-specific information, and the like.

Disclosure of the invention

The present invention has been made in view of the above-described current state of the art, and an object thereof is to implement an independent management structure of data in each partition by issuing various types of access control certificates for accessing a storage area divided into a plurality of partitions under the management of each device or each partition management entity and executing processing by a memory mount device according to rules described in each certificate.

In particular, an object of the present invention is to provide a data access management system, a memory installation device, a data access management method, and a program storage medium, which are configured to individually issue, for each access device, a service license certificate (SPT) that is an access control certificate in which an allowable access mode is set for the access device, thereby realizing access of different types for each access device.

Another object of the present invention is to provide a data processing system, a memory-mounted device, a data management method, and a program storage medium, which can perform secure data communication between a device and an access apparatus under various environments based on various access control certificate configurations, in which the memory-mounted device determines and executes either one of a public key scheme and a common key scheme, which is a mutual authentication scheme with the access apparatus, based on a specification from the access apparatus or a description of the received access control certificate, and also determines and executes either one of a public key scheme and a common key scheme, which is a scheme for verifying the access control certificate, based on the description of the received access control certificate.

It is still another 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, which can perform access to a memory under more secure management and can realize access management in which security levels corresponding to memory access processing are set by setting various authentication forms and certificate forms for each access, in which the memory-mounted device receives an access control certificate configured as access control data from an access device, and allows data access with the establishment of authentication based on an authentication rule described in the access control certificate and the establishment of a condition for identifying identification data of the access device described in the access control certificate.

The present invention has been made in view of the above-described current state of the art, and an object of the present invention is to provide a data access control system, a memory installation device, a memory access control method, and a program storage medium, which are configured to receive an access control certificate for accessing a storage area divided into a plurality of partitions from an access device, execute access processing for a data file based on a description of the access control certificate, and thereby execute access processing for a plurality of data files based on the plurality of access control certificates in a manner of reducing processing of a device.

The present invention in its 1 st aspect is a data access management system for managing access processing to a stored data file of a storage unit by an access device to a memory mount apparatus having the storage unit capable of storing data, the data access management system characterized in that: the access device receives a service license certificate (SPT) which is an access control certificate for which an allowable access mode is set for the access device from a certificate issuing device, and outputs the received service license certificate (SPT) to the memory mount device, and the memory mount device is configured to execute processing based on the access mode described in the service license certificate (SPT) after receiving the service license certificate (SPT) from the access device.

In one aspect of the data access management system of the present invention, the data access management system further includes: the service license (SPT) includes a file identifier for identifying a data file to be accessed, and the memory mount device is configured to receive the service license (SPT) from the access apparatus, select a data file based on the file identifier described in the service license (SPT), and execute processing on the selected file based on the access pattern.

In one aspect of the data access management system of the present invention, the data access management system further includes: the service license ticket (SPT) has a structure including a plurality of file identifiers for identifying a plurality of data files to be accessed, and has a structure in which one of the plurality of file identifiers is set as a target file identifier and read or write license data corresponding to the target file is stored, and the memory-mounted device has a structure in which, after receiving the service license ticket (SPT) from the access apparatus, it executes processing in accordance with the access mode and executes read or write processing on the target file set in the service license ticket (SPT) for the target file identifier in accordance with the read or write license data set in the service license ticket (SPT).

In one aspect of the data access management system of the present invention, the data access management system further includes: the service license (SPT) has a structure including a plurality of file identifiers for identifying a plurality of data files to be accessed, and has a structure in which one of the plurality of file identifiers is set as a target file identifier, read or write license data corresponding to the target file is stored, and an access mode of another data file is set as an encryption process using an encryption key stored in the data file, and the memory-mounted device is configured to execute an internal encryption process in the memory-mounted device by receiving the service license (SPT) from the access apparatus, and then executing the read of the target file and the encryption process using the encryption key as a process according to the access mode.

In one aspect of the data access management system of the present invention, the data access management system further includes: the certificate issuing apparatus for issuing the service license (SPT) is a certificate issuing apparatus under the management of an entity for managing the storage area of the memory mounted device, and has a configuration in which the service license (SPT) having various access modes set therein is issued individually for each access apparatus, thereby allowing each access apparatus to perform access in different modes.

In one aspect of the data access management system of the present invention, the data access management system further includes: the memory mount device is configured to generate a file open table in which a file identifier, which is identification data of a file on which a file open process is executed based on a service license certificate (SPT) received in a session with an access apparatus, is associated with an access pattern described in the service license certificate (SPT), and to determine whether or not a command received from the access apparatus can be executed by referring to the file open table.

In one aspect of the data access management system of the present invention, the data access management system further includes: the storage unit of the memory mount device has 1 or more partition areas as storage areas managed by the respectively corresponding partition managers, the data file is stored in any of the 1 or more partition areas, and the memory mount device is configured to execute processing in response to an access request for the data file in each partition based on a description of a service license certificate (SPT) issued by a certificate issuing apparatus under the management of the partition manager and input to the memory mount device by the access apparatus as a certificate utilizing apparatus.

In one aspect of the data access management system of the present invention, the data access management system further includes: the service license (SPT) includes mutual authentication form designation data designating a mutual authentication form to be executed between the memory mount device and an access apparatus which has outputted the certificate, and the memory mount device is configured to execute mutual authentication based on the mutual authentication form designation data of the service license (SPT) and execute processing corresponding to recording of the received certificate on condition that the authentication is established.

In one aspect of the data access management system of the present invention, the data access management system further includes: the service license (SPT) includes certificate verification specifying data specifying a verification form of the service license (SPT) received by the memory-mounted device, and the memory-mounted device is configured to execute a certificate verification process based on the certificate verification specifying data of the service license (SPT) and execute a process corresponding to the record of the received certificate on condition that the verification is established.

Further, the invention of claim 2 is a memory mounting device having a storage section capable of storing data, characterized in that: the control device is configured to select a data file based on a file identifier described in a service license certificate (SPT) received from the access device, and to execute processing on the selected file based on an access pattern described in the service license certificate (SPT).

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the service license (SPT) includes a file identifier for identifying a data file to be accessed, and the control device is configured to receive the service license (SPT) from the access device, select a data file based on the file identifier described in the service license (SPT), and execute processing on the selected file based on the access pattern.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the service license ticket (SPT) has a structure including a plurality of file identifiers for identifying a plurality of data files to be accessed, and has a structure in which read or write license data corresponding to a target file is stored while one of the plurality of file identifiers is set as a target file identifier, and the control device has a structure in which, after receiving the service license ticket (SPT) from the access device, processing is executed in accordance with the access mode, and at the same time, processing is executed in accordance with the read or write license data set in the service license ticket (SPT), and processing is executed in accordance with the read or write license data set in the service license ticket (SPT) for reading or writing the target file set in accordance with the target file identifier in the service license ticket (SPT).

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the service license (SPT) has a structure including a plurality of file identifiers for identifying a plurality of data files to be accessed, and has a structure in which one of the plurality of file identifiers is set as a target file identifier, read or write license data corresponding to the target file is stored, and an access mode of another data file is set as an encryption process using an encryption key stored in the data file, and the control device is configured to execute the internal encryption process in the memory-mounted device by receiving the service license (SPT) from the access device, and executing the read of the target file and the encryption process using the encryption key as a process according to the access mode.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the control device generates a file open table in which a file identifier, which is identification data of a file to which a file open process is performed based on a service license certificate (SPT) received in a session with an access device, is associated with an access pattern described in the service license certificate (SPT), and determines whether or not a command received from the access device can be executed with reference to the file open table.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the storage unit of the memory mount device includes 1 or more partition areas which are storage areas managed by the corresponding partition managers, the data file is stored in any of the 1 or more partition areas, and the control device is configured to execute processing of responding to an access request for the data file in each partition based on a description of a service license certificate (SPT) issued by a certificate issuing device under the management of the partition manager and input to the memory mount device by the access device which is a certificate utilizing device.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the service license (SPT) includes mutual authentication form designation data designating a mutual authentication form to be executed between the memory mount device and an access device that outputs a certificate, and the control device is configured to execute mutual authentication based on the mutual authentication form designation data of the service license (SPT) and execute processing corresponding to recording of a received certificate on condition that the authentication is established.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the service license (SPT) includes certificate verification specifying data specifying a verification form of the service license (SPT) received by the memory mount device, and the control device is configured to execute a certificate verification process based on the certificate verification specifying data of the service license (SPT) and execute a process corresponding to the record of the received certificate on condition that the verification is established.

Further, the 3 rd aspect of the present invention is a data access management method for managing access processing to a storage data file of a storage unit capable of storing data by an access device to a memory mount apparatus having the storage unit, the data access management method characterized by: the access device receives a service license certificate (SPT) which is an access control certificate for which an allowable access mode is set in the access device from a certificate issuing device, and outputs the received service license certificate (SPT) to the memory installation device, and the memory installation device executes processing based on the access mode described in the service license certificate (SPT) after receiving the service license certificate (SPT) from the access device

The memory installation device executes processing for responding to an access request to a stored data file, based on a description of a service license certificate (SPT) issued by a certificate issuing apparatus under the management of the partition manager and input to the memory installation device by the access apparatus as a certificate utilizing apparatus.

In one aspect of the data access management method according to the present invention, the data access management method includes: the service license (SPT) includes a file identifier for identifying a data file to be accessed, and the memory mount device receives the service license (SPT) from the access device, selects a data file based on the file identifier described in the service license (SPT), and executes processing on the selected file based on the access pattern.

In one aspect of the data access management method according to the present invention, the data access management method includes: the service license ticket (SPT) has a structure including a plurality of file identifiers for identifying a plurality of data files to be accessed, and has a structure in which one of the plurality of file identifiers is set as a target file identifier and read or write license data corresponding to the target file is stored, and the memory-mounted device executes processing in accordance with the access mode after receiving the service license ticket (SPT) from the access device, and executes read or write processing in accordance with the read or write license data set in the service license ticket (SPT) for the target file identifier.

In one aspect of the data access management method according to the present invention, the data access management method includes: the service license (SPT) has a structure including a plurality of file identifiers for identifying a plurality of data files to be accessed, and has a structure in which one of the plurality of file identifiers is set as a target file identifier, read or write license data corresponding to the target file is stored, and an access mode of another data file is set as an encryption process using an encryption key stored in the data file, and the memory-mounted device receives the service license (SPT) from the access apparatus, and then executes the internal encryption process in the memory-mounted device by executing the read of the target file and the encryption process using the encryption key as a process according to the access mode.

In one aspect of the data access management method according to the present invention, the data access management method includes: the certificate issuing apparatus for issuing the service license (SPT) is a certificate issuing apparatus under the management of an entity for managing the storage area of the memory mounted device, and the certificate issuing apparatus individually issues the service license (SPT) in which various access modes are set for each access apparatus, thereby enabling access of different forms to be executed for each access apparatus.

In one aspect of the data access management method according to the present invention, the data access management method includes: the memory mount device generates a file open table in which a file identifier, which is identification data of a file on which a file open process is executed based on a service license (SPT) received in a session with an access device, is associated with an access pattern described in the service license (SPT), and determines whether or not a command received from the access device can be executed with reference to the file open table.

In one aspect of the data access management method according to the present invention, the data access management method includes: the storage unit of the memory mount device has 1 or more partition areas as storage areas managed by the respectively corresponding partition managers, the data file is stored in any one of the 1 or more partition areas, and the memory mount device executes processing in response to an access request for the data file in each partition based on a description of a service license certificate (SPT) issued by a certificate issuing apparatus under the management of the partition manager and input to the memory mount device by the access apparatus as a certificate utilizing apparatus.

In one aspect of the data access management method according to the present invention, the data access management method includes: the service license (SPT) includes mutual authentication form designation data designating a mutual authentication form to be executed between the memory mount device and an access apparatus which has outputted the certificate, and the memory mount device executes mutual authentication based on the mutual authentication form designation data of the service license (SPT) and executes processing corresponding to recording of the received certificate on condition that the authentication is established.

In one aspect of the data access management method according to the present invention, the data access management method includes: the service license (SPT) includes certificate verification specifying data specifying a verification form of the service license (SPT) received by the memory-mounted device, and the memory-mounted device executes a certificate verification process based on the certificate verification specifying data of the service license (SPT) and executes a process corresponding to the record of the received certificate on condition that the verification is established.

Further, according to a 4 th aspect of the present invention, there is provided a program storage medium for providing a computer program for executing on a computer a data access management process for managing an access process performed by an access device to a storage data file stored in a storage unit having the storage unit capable of storing data, the program storage medium comprising: the computer program includes a step of receiving, by an access device that accesses the memory-mounted device, a service license certificate (SPT) that is an access control certificate in which an allowable access mode is set, and executing processing according to the access mode described in the service license certificate (SPT).

Further, a 5 th aspect of the present invention is a data processing system for executing data processing on a storage unit having the storage unit capable of storing data in response to an access request issued from an access device to a memory mount apparatus having the storage unit, the data processing system characterized in that: the memory mount device is configured to receive an access control certificate having a configuration corresponding to data processing in the storage unit from the access device, execute data processing based on a rule described in the access control certificate, and respond to an access request from the access device on the condition that both mutual authentication and certificate verification are established, based on specification of the access device or a description of the access control certificate received from the access device, and a manner of determining and executing mutual authentication with the access device.

In one aspect of the data processing system of the present invention, the data processing system further includes: the mutual authentication method is either a public key method or a common key method, and the verification method of the access control certificate is either a public key method or a common key method.

In one aspect of the data processing system of the present invention, the data processing system further includes: the memory mounting device is configured to have a key for MAC verification for verifying the access control certificate, execute a tamper check process using the key for MAC verification when verifying the access control certificate received from the access apparatus by a common key method, and execute a signature check process based on a public key of the certificate issuing apparatus acquired from a public key certificate of the certificate issuing apparatus when verifying the access control certificate by a public key method.

In one aspect of the data processing system of the present invention, the data processing system further includes: the memory mounting device is configured to have a plurality of MAC verification keys for verifying the access control certificate and to select a MAC verification key to be used based on information recorded in the access control certificate received from the access device.

In one aspect of the data processing system of the present invention, the data processing system further includes: the access control certificate includes a data update certificate (DUT) that allows update processing of data stored in a storage unit of the memory device, the memory device includes a plurality of MAC verification keys for verifying the access control certificate, and when update target data specified in the data update certificate (DUT) received from the access apparatus is a MAC verification key for verifying the access control certificate, the memory device selects a MAC verification key that does not match an update target from the plurality of MAC verification keys for verifying the access control certificate and performs verification processing of the received data update certificate (DUT).

In one aspect of the data processing system of the present invention, the data processing system further includes: the storage unit of the memory mount device has 1 or more partition areas as storage areas managed by the respective corresponding partition managers, and the memory mount device is configured to execute processing of responding an access request from the access device to a data file in each partition, based on a description of an access control certificate issued by a certificate issuing device under the management of the partition manager and input to the memory mount device by the access device as a certificate utilizing device.

In one aspect of the data processing system of the present invention, the data processing system further includes: the storage unit of the memory-mounted device has 1 or more partition areas as storage areas managed by the corresponding partition manager, and the memory-mounted device has a configuration for generating an authentication table in which public key system authentication information and a session key or common key system authentication information and a session key acquired by partition authentication or device authentication performed in a session with the access apparatus are associated with each other and holding the authentication table during the session.

Further, the present invention in its 6 th aspect is a memory mounting device having a storage section capable of storing data, the memory mounting device characterized in that: the control device is configured to receive an access control certificate having a configuration corresponding to data processing to the storage unit from the access device, execute the data processing based on a rule described in the access control certificate, and respond to the access request from the access device on the condition that both mutual authentication and certificate verification are established, while determining and executing a mutual authentication with the access device based on the specification of the access device or the description of the access control certificate received therefrom.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the control device selectively executes either a public key system or a common key system as the mutual authentication system, and selectively executes either a public key system or a common key system as the verification system of the access control certificate.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the memory mounting device includes a key for MAC verification for verifying the access control certificate, and the control unit performs a tamper check process using the key for MAC verification when verifying the access control certificate received from the access unit by a common key method, and performs a signature verification process based on a public key of the certificate issuing unit obtained from a public key certificate of the certificate issuing unit when verifying the access control certificate by a public key method.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the memory mount device includes a plurality of MAC verification keys for verifying the access control certificate, and the control device is configured to select a MAC verification key to be used based on information recorded in the access control certificate received from the access device.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the access control certificate includes a data update certificate (DUT) that allows update processing of data stored in a storage unit of the memory-mounted device, the memory-mounted device includes a plurality of MAC verification keys for verifying the access control certificate, and the control device selects a MAC verification key that does not match an update target from among the plurality of MAC verification keys for verifying the access control certificate and executes verification processing of the received data update certificate (DUT), when update target data specified in the data update certificate (DUT) received from the access device is a MAC verification key for verifying the access control certificate.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the storage unit of the memory mount device has 1 or more partition areas as storage areas managed by the respective corresponding partition managers, and the control device is configured to execute processing of responding an access request from the access device to a data file in each partition, based on a description of an access control certificate issued by a certificate issuing device under the management of the partition manager and input to the memory mount device by the access device as a certificate utilizing device.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the storage unit of the memory-mounted device has 1 or more partition areas as storage areas managed by the corresponding partition manager, and the control device has a configuration for generating an authentication table in which public key system authentication information and a session key or common key system authentication information and a session key acquired by partition authentication or device authentication performed in a session with the access device are associated with each other and holding the authentication table during the session.

Further, a 7 th aspect of the present invention is a data processing method for executing data processing on a storage section capable of storing data in response to an access request issued from an access device to a memory mount apparatus having the storage section, the data processing method characterized by: in the memory mount device, receiving an access control certificate having a configuration corresponding to data processing in the storage unit from the access device, performing data processing based on a rule described in the access control certificate, determining and executing a mutual authentication method with the access device based on specification of the access device or the description of the access control certificate received from the access device, determining and executing a verification method of the access control certificate based on the description of the received access control certificate, and executing an access request from the access device on condition that both the mutual authentication and the certificate verification are established;

the memory installation device executes processing for responding to an access request to a stored data file, based on a description of a service license certificate (SPT) issued by a certificate issuing apparatus under the management of the partition manager and input to the memory installation device by the access apparatus as a certificate utilizing apparatus.

In one aspect of the data processing method of the present invention, the data processing method further includes: the mutual authentication method is either a public key method or a common key method, and the verification method of the access control certificate is either a public key method or a common key method.

In one aspect of the data processing method of the present invention, the data processing method further includes: the memory mounting device has a key for MAC verification for verifying the access control certificate, executes a tamper check process using the key for MAC verification when verifying the access control certificate received from the access device in accordance with a common key system, and executes a signature check process based on a public key of the certificate issuing device acquired from a public key certificate of the certificate issuing device when verifying the access control certificate in accordance with a public key system.

In one aspect of the data processing method of the present invention, the data processing method further includes: the memory mounting device has a plurality of MAC verification keys for verifying the access control certificate, and selects a MAC verification key to be used based on information recorded in the access control certificate received from the access device.

In one aspect of the data processing method of the present invention, the data processing method further includes: the access control certificate includes a data update certificate (DUT) that allows update processing of data stored in a storage unit of the memory device, the memory device includes a plurality of MAC verification keys for verifying the access control certificate, and when update target data specified in the data update certificate (DUT) received from the access apparatus is a MAC verification key for verifying the access control certificate, the memory device selects a MAC verification key that does not match an update target from the plurality of MAC verification keys for verifying the access control certificate and performs verification processing of the received data update certificate (DUT).

In one aspect of the data processing method of the present invention, the data processing method further includes: the storage unit of the memory mount device has 1 or more partition areas as storage areas managed by the corresponding partition managers, and the memory mount device executes processing of responding an access request from the access device to a data file in each partition, based on a description of an access control certificate issued by a certificate issuing device under the management of the partition manager and input to the memory mount device by the access device as a certificate utilizing device.

In one aspect of the data processing method of the present invention, the data processing method further includes: the storage unit of the memory-mounted device has 1 or more partition areas as storage areas managed by the corresponding partition manager, and the memory-mounted device generates an authentication table in which public key system authentication information and a session key or common key system authentication information and a session key acquired by partition authentication or device authentication performed in a session with the access apparatus are associated with each other, and holds the authentication table during the session.

Further, according to a 8 th aspect of the present invention, there is provided a program storage medium for causing a computer system to execute data processing executed on a storage unit capable of storing data in response to an access request issued from an access device to a memory mount apparatus having the storage unit, the program storage medium comprising: the computer program includes a step of receiving, from the access device, an access control certificate having a configuration corresponding to data processing in the storage unit, a step of determining a mode of performing mutual authentication with the access device based on the specification of the access device or the description of the access control certificate received from the access device, a step of determining a mode of performing verification of the access control certificate based on the description of the received access control certificate, and a step of executing an access request from the access device on the condition that both mutual authentication and certificate verification are established.

Further, according to a 9 th aspect of the present invention, there is provided a data access control system for transmitting a command from an access device to a memory mounted device having a storage unit capable of storing data and executing processing on the data stored in the storage unit, the data access control system comprising: the memory mount device is configured to receive an access control certificate configured as access control data for data stored in the storage unit from the access device, and to permit data access in accordance with the establishment of authentication based on an authentication rule described in the access control certificate and the confirmation of a condition for permitting data access to identification data of the access device described in the access control certificate.

In one aspect of the data access control system of the present invention, the data access control system further includes: the access control certificate includes authentication format specifying information indicating whether the authentication method is permitted, that is, one or both of a public key method and a shared key method, and the memory-attached device is configured to execute the authentication process based on the authentication format described in the access control certificate received from the access apparatus.

In one aspect of the data access control system of the present invention, the data access control system further includes: the memory-mounted device is configured to execute a process of confirming that the certificate is a certificate issued by a legitimate issuing apparatus based on the type or identifier of the issuing apparatus of the access control certificate described in the access control certificate received from the access apparatus, and to permit data access on condition of the confirmation.

In one aspect of the data access control system of the present invention, the data access control system further includes: the memory-mounted device is configured to execute a process of confirming that the certificate is a certificate issued by a legitimate issuing apparatus based on a comparison between the type or identifier of the issuing apparatus of the access control certificate described in the access control certificate received from the access apparatus and the user information stored in the public key certificate of the issuing apparatus of the access control certificate, and to permit data access on condition of the confirmation.

In one aspect of the data access control system of the present invention, the data access control system further includes: the memory-mounted device executes a process of confirming that the certificate is a certificate provided by a legitimate user device on the basis of the type or identifier of the access device, which is the user device of the access control certificate, described in the access control certificate received from the access device, and permits data access on the condition that the confirmation is made.

In one aspect of the data access control system of the present invention, the data access control system further includes: the memory-mounted device is configured to execute a process of confirming that the certificate is a certificate provided by a legitimate user device based on a comparison between the type or identifier of the user device, which is the access device, described in the access control certificate received from the access device and the user information stored in the public key certificate of the user device of the access control certificate, and to permit data access on the condition that the confirmation is made.

In one aspect of the data access control system of the present invention, the data access control system further includes: the storage unit of the memory-mounted device has 1 or more partition areas as storage areas managed by the corresponding partition managers, and the memory-mounted device has a configuration for generating an authentication table in which public key system authentication information and a session key or common key system authentication information and a session key obtained by partition authentication or device authentication performed in a session with the access apparatus are associated with each other.

Further, a 10 th aspect of the present invention is a memory mounting device having a storage section capable of storing data, the memory mounting device characterized in that: the control device receives an access control certificate configured as access control data for the data stored in the storage unit from the access device, and permits data access under conditions that an authentication according to an authentication rule described in the access control certificate is established and identification data of the access device described in the access control certificate is confirmed.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the access control certificate includes authentication format specifying information indicating whether the authentication is permitted, that is, whether the authentication is permitted by one or both of the public key method and the shared key method, and the control device is configured to execute the authentication process based on the authentication format described in the access control certificate received from the access device.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the control device is configured to execute a process of confirming that the certificate is a certificate issued by a legitimate issuing device based on the type or identifier of the issuing device of the access control certificate described in the access control certificate received from the access device, and to permit data access on condition of the confirmation.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the control device is configured to execute a process of confirming that the certificate is a certificate issued by a legitimate issuing device based on a comparison between the type or identifier of the issuing device of the access control certificate described in the access control certificate received from the access device and the user information stored in the public key certificate of the issuing device of the access control certificate, and to permit data access on condition of the confirmation.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the control device is configured to execute a process of confirming that the certificate is a certificate provided by a legitimate user device based on the type or identifier of the access device, which is the user device of the access control certificate described in the access control certificate received from the access device, and to permit data access on the condition that the confirmation is made.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the control device is configured to execute a process of confirming that the certificate is a certificate provided by a legitimate user device based on a comparison between the type or identifier of the access device, which is a user device of the access control certificate described in the access control certificate received from the access device, and the user information stored in the public key certificate of the user device of the access control certificate, and to permit data access on the condition that the confirmation is made.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the storage unit of the memory-mounted device has 1 or more partition areas as storage areas managed by the corresponding partition manager, and the control device has a configuration for generating an authentication table in which public key system authentication information and a session key or common key system authentication information and a session key obtained by partition authentication or device authentication performed in a session with the access device are associated with each other.

Further, an 11 th aspect of the present invention is a data access control method for transmitting a command from an access device to a memory mount apparatus having a storage unit capable of storing data and executing processing on the data stored in the storage unit, the data access control method characterized by: the memory mount device receiving an access control certificate configured as access control data for data stored in the storage unit from the access device, and permitting data access in accordance with an authentication establishment based on an authentication rule described in the access control certificate and a determination condition for identification data of the access device described in the access control certificate;

The memory installation device executes processing for responding to an access request to a stored data file, based on a description of a service license certificate (SPT) issued by a certificate issuing apparatus under the management of the partition manager and input to the memory installation device by the access apparatus as a certificate utilizing apparatus.

In one aspect of the data access control method of the present invention, the data access control method includes: the access control certificate includes authentication format specifying information indicating whether the authentication method is permitted, that is, one or both of a public key method and a shared key method, and the memory-attached device executes the authentication process based on the authentication format described in the access control certificate received from the access apparatus.

In one aspect of the data access control method of the present invention, the data access control method includes: the memory-mounted device executes a process of confirming that the certificate is a certificate issued by a legitimate issuing apparatus based on the type or identifier of the issuing apparatus of the access control certificate described in the access control certificate received from the access apparatus, and permits data access on condition of the confirmation.

In one aspect of the data access control method of the present invention, the data access control method includes: the memory-mounted device executes a process of confirming that the certificate is a certificate issued by a legitimate issuing apparatus based on a comparison between the type or identifier of the issuing apparatus of the access control certificate described in the access control certificate received from the access apparatus and the user information stored in the public key certificate of the issuing apparatus of the access control certificate, and permits data access on condition of the confirmation.

In one aspect of the data access control method of the present invention, the data access control method includes: the memory-mounted device executes a process of confirming that the certificate is a certificate provided by a legitimate user device on the basis of the type or identifier of the access device, which is the user device of the access control certificate, described in the access control certificate received from the access device, and permits data access on the condition that the confirmation is made.

In one aspect of the data access control method of the present invention, the data access control method includes: the memory-mounted device executes a process of confirming that the certificate is a certificate provided by a legitimate user device based on a comparison between the type or identifier of the user device, which is the access device that is the access control certificate described in the access control certificate received from the access device, and the user information stored in the public key certificate of the user device of the access control certificate, and permits data access on the condition that the confirmation is made.

In one aspect of the data access control method of the present invention, the data access control method includes: the storage unit of the memory-mounted device has 1 or more partition areas as storage areas managed by the corresponding partition managers, and the memory-mounted device generates an authentication table in which public key system authentication information and a session key or common key system authentication information and a session key obtained by partition authentication or device authentication performed in a session with the access apparatus are associated with each other.

Further, a 12 th aspect of the present invention is a program storage medium for causing a computer system to execute a process of transmitting a command from an access device to a memory mount device having a storage unit capable of storing data and executing the data stored in the storage unit, the program storage medium comprising: the computer program includes a step of receiving an access control certificate configured as access control data for data stored in the storage unit from the access device, and a step of establishing authentication based on an authentication rule described in the access control certificate and permitting data access to the access device under a condition that is determined as identification data of the access device described in the access control certificate.

A 13 th aspect of the present invention is a data access control system for controlling a memory access by an access device to a memory mount device having a storage unit storing a plurality of data files, the data access control system characterized in that: the storage unit of the memory mount device has 1 or more partition areas as storage areas managed by the corresponding partition managers, the data file is stored in any of the 1 or more partition areas, the memory mount device has a configuration that receives an access control certificate from the access device and executes access processing for the data file according to a description of the access control certificate, and the memory mount device has a configuration that executes access processing for a plurality of data files according to a plurality of access control certificates on the condition that device authentication, which is authentication for the memory mount device, is established or partition authentication, which is authentication for each partition storing the data file to be accessed, is established.

In one aspect of the memory access control system according to the present invention, the memory access control system further includes: the authentication mode that can be set for each partition is described in an access control certificate that is configured as access control data, and the memory-mounted device is configured to receive the access control certificate from the access apparatus and to determine the authentication mode required for each partition based on the description of the access control certificate.

In one aspect of the memory access control system according to the present invention, the memory access control system further includes: the memory mount device is configured to permit access to files in a plurality of different partitions based on a plurality of access control certificates on the condition that the device authentication is established.

In one aspect of the memory access control system according to the present invention, the memory access control system further includes: the memory mount device is configured to permit access to files in a plurality of different partitions based on a plurality of access control certificates on the condition that all of the partition authentication or device authentication, which is authentication conditions set in association with the respective different partitions, have succeeded.

In one aspect of the memory access control system according to the present invention, the memory access control system further includes: the memory mount device is configured to generate a unique integrated session key from a plurality of session keys obtained as a result of a plurality of authentication processes performed under file access conditions in a plurality of different partitions, and to perform an encryption process of communication data with the access device based on the integrated session key.

In one aspect of the memory access control system according to the present invention, the memory access control system further includes: the memory-mounted device is configured to generate a unique integrated session key by exclusive-or operation of each session key based on a plurality of session keys obtained as a result of a plurality of authentication processes performed under file access conditions in a plurality of different partitions, and to perform encryption processing of communication data with the access device based on the integrated session key.

In one aspect of the memory access control system according to the present invention, the memory access control system further includes: the memory mount device is configured to select a unique session key from among a plurality of session keys obtained as a result of a plurality of authentication processes performed under file access conditions in a plurality of different partitions, and to perform an encryption process of communication data with the access device based on the selected session key.

In one aspect of the memory access control system according to the present invention, the memory access control system further includes: the memory-mounted device may be configured to generate an authentication table in which public key system authentication information and a session key or common key system authentication information and a session key obtained by partition authentication or device authentication performed with the access apparatus are associated with each other, and to hold the authentication table during the session.

Further, a 14 th aspect of the present invention is a memory mount device having a storage unit storing a plurality of data files, the memory mount device characterized in that: the storage unit has 1 or more partition areas as storage areas managed by the respectively corresponding partition managers, the data file is stored in any one of the 1 or more partition areas, the control unit receives an access control certificate from the access unit and executes access processing for the data file according to the description of the access control certificate, and the control unit executes access processing for a plurality of data files according to a plurality of access control certificates on the condition that device authentication, which is authentication for the memory mounted device, is established or partition authentication, which is authentication for each partition storing the data file to be accessed, is established.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the authentication mode set for each partition may be described in an access control certificate configured as access control data, the memory-mounted device may receive the access control certificate from the access apparatus, and the control apparatus may determine the authentication mode required for each partition based on the description of the access control certificate.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the control device is configured to permit access to files in a plurality of different partitions based on a plurality of access control certificates on the condition that the device authentication is established.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the control device is configured to permit access to files in a plurality of different partitions based on a plurality of access control certificates on the condition that all of the partition authentication or the device authentication, which is the authentication condition set in association with each of the different partitions, has succeeded.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the control device is configured to generate a unique integrated session key from a plurality of session keys obtained as a result of a plurality of authentication processes performed under the file access conditions in a plurality of different partitions, and to perform an encryption process of communication data with the access device based on the integrated session key.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the control device is configured to generate a unique integrated session key by an exclusive-or operation of the session keys based on the session keys acquired as a result of the authentication processing performed a plurality of times under the file access conditions in the plurality of different partitions, and to perform encryption processing of communication data with the access device based on the integrated session key.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the control device is configured to select a unique session key from among a plurality of session keys obtained as a result of a plurality of authentication processes performed under file access conditions in a plurality of different partitions, and to perform an encryption process of communication data with the access device based on the selected session key.

In one aspect of the memory mounting device of the present invention, the memory mounting device further includes: the control device may be configured to generate an authentication table in which public key system authentication information and a session key or common key system authentication information and a session key obtained by partition authentication or device authentication performed with the access device are associated with each other, and to hold the authentication table during the session.

A 15 th aspect of the present invention is a memory access control method for controlling a memory access by an access device to a memory mount device having a storage unit storing a plurality of data files, the memory access control method comprising: the data file is stored in any one of the 1 or more partition areas, and the access device receives an access control certificate and executes access processing to the data file based on the description of the access control certificate, and executes access processing to a plurality of data files based on a plurality of access control certificates on the condition that device authentication as authentication to the memory mounted device is established or on the condition that partition authentication as authentication to each partition storing the data file to be accessed is established.

In one aspect of the memory access control method of the present invention, the method further includes: the authentication mode that can be set for each partition is described in an access control certificate that is configured as access control data, and the memory-mounted device receives the access control certificate from the access apparatus and determines the authentication mode required for each partition based on the description of the access control certificate.

In one aspect of the memory access control method of the present invention, the method further includes: the memory mount device allows access to files in a plurality of different partitions based on a plurality of access control certificates on the condition that the device authentication is established.

In one aspect of the memory access control method of the present invention, the method further includes: the memory mount device allows access to files in a plurality of different partitions based on a plurality of access control certificates on the condition that all of the partition authentication or device authentication, which is authentication conditions set in association with the respective different partitions, are successful.

In one aspect of the memory access control method of the present invention, the method further includes: the memory mount device generates a unique integrated session key from a plurality of session keys obtained as a result of a plurality of authentication processes performed under the file access conditions in a plurality of different partitions, and performs an encryption process of communication data with the access device based on the integrated session key.

In one aspect of the memory access control method of the present invention, the method further includes: the memory-mounted device generates a unique integrated session key by exclusive-or operation of each session key based on a plurality of session keys obtained as a result of a plurality of authentication processes performed under file access conditions in a plurality of different partitions, and performs encryption processing of communication data with the access device based on the integrated session key.

In one aspect of the memory access control method of the present invention, the method further includes: the memory mount device selects a unique session key from among a plurality of session keys obtained as a result of a plurality of authentication processes performed under file access conditions in a plurality of different partitions, and performs an encryption process of communication data with the access device based on the selected session key.

In one aspect of the memory access control method of the present invention, the method further includes: the memory-mounted device generates an authentication table in which public key system authentication information obtained by partition authentication or device authentication performed with the access apparatus is associated with a session key or common key system authentication information is associated with a session key, and holds the authentication table during the session.

Further, a 16 th aspect of the present invention is a program storage medium for providing a computer program for executing on a computer system a memory access control process for controlling a memory access by an access device to a memory mount device having a storage unit in which a plurality of data files are stored, the program storage medium characterized by: the computer program includes a step of performing either device authentication, which is authentication for the memory-mounted device, or partition authentication, which is authentication for each partition storing a data file to be accessed, a step of performing access processing for a plurality of data files based on the access control certificate received from the access device on the condition that authentication in the authentication step is established, a step of executing access processing for a plurality of data files based on the access control certificate received from the access device, and a program for executing the program,

In addition, the program recording medium of the present invention is, for example, a medium that provides a computer program in a computer-readable form to a general-purpose computer system that can execute various program codes. The medium may be a recording medium such as a CD, FD, or MO, a communicable medium, or the like, and the form thereof is not particularly limited.

The program storage medium defines a structure or function relationship between a computer program for realizing a predetermined computer program function on a computer system and the storage medium. In other words, the computer program is loaded into the computer system via the storage medium, thereby exerting a synergistic effect on the computer system and achieving the same effect as the other aspects of the present invention.

Other objects, features and advantages of the present invention will become apparent from the embodiments described hereinafter and from the accompanying drawings, which are described in more detail. The system according to the present invention is a logical set structure of a plurality of devices, and is not limited to the case where the constituent devices are in the same housing.

Brief description of the drawings

Fig. 1 is a system configuration diagram (1 thereof) illustrating an outline of the system configuration of the present invention.

Fig. 2 is a system configuration diagram (2 thereof) illustrating an outline of the system configuration of the present invention.

Fig. 3 is a system configuration diagram (3) illustrating an outline of the system configuration of the present invention.

Fig. 4 is a diagram illustrating a relationship between an apparatus for issuing an access control certificate and a device using the access control certificate in the system of the present invention.

Fig. 5 is a diagram showing a configuration of an apparatus having a storage unit in the system of the present invention.

Fig. 6 is a diagram showing a memory format of the apparatus of the present invention.

Fig. 7 is a diagram showing a configuration of a device manager in the system of the present invention.

Fig. 8 is a diagram showing a configuration of a control device of the device manager in the system according to the present invention.

FIG. 9 is a diagram showing the structure of a partition manager in the system of the present invention.

Fig. 10 is a diagram showing a configuration of a reader/writer (R/W) in the system of the present invention.

Fig. 11 is a diagram illustrating a format of a public key certificate available in the system of the present invention.

Fig. 12 is a diagram showing a flow of signature generation processing by a public key scheme that can be used in the system of the present invention.

Fig. 13 is a diagram showing a flow of signature verification processing by a public key scheme usable in the system of the present invention.

Fig. 14 is a diagram showing a data structure of a manufacturing information block in data stored in a storage unit of the device of the present invention.

Fig. 15 is a diagram showing a data structure of a device management information block in data stored in a storage unit of a device according to the present invention.

Fig. 16 is a diagram showing a data structure of a public-key-system device key definition block in data stored in a storage unit of the device according to the present invention.

Fig. 17 is a diagram showing a data structure of a common-key device key definition block in data stored in a storage unit of the device according to the present invention.

Fig. 18 is a diagram showing a data structure of a device key area in data stored in a storage unit of the device according to the present invention.

Fig. 19 is a diagram showing a data structure of a partition definition block in data stored in a storage unit of the device according to the present invention.

Fig. 20 is a diagram showing a data structure of a partition management information block in data stored in a storage unit of the apparatus according to the present invention.

Fig. 21 is a diagram showing a data structure of a public key partition key definition block in data stored in a storage unit of the device according to the present invention.

Fig. 22 is a diagram showing a data structure of a partition key definition block made of a common key among data stored in a storage unit of the device of the present invention.

Fig. 23 is a diagram showing a data structure of a partition key area in data stored in a storage unit of the device of the present invention.

Fig. 24 is a diagram showing a data structure of a file definition block in data stored in a storage unit of the device of the present invention.

Fig. 25 is a diagram illustrating a file structure format in data stored in the storage unit of the device according to the present invention.

Fig. 26 is a diagram showing a format of a partition registration certificate (PRT) used as an access control certificate in the system of the present invention.

Fig. 27 is a diagram showing a format of a file registration certificate (FRT) as an access control certificate used in the system of the present invention.

Fig. 28 is a diagram showing a format (example 1) of a service license certificate (SPT) as an access control certificate used in the system of the present invention.

Fig. 29 is a diagram for explaining the type of file access mode using a service license certificate (SPT) as an access control certificate employed in the system of the present invention.

Fig. 30 is a diagram illustrating a file structure to be accessed using a service license certificate (SPT) as an access control certificate employed in the system of the present invention.

Fig. 31 is a diagram showing a format (example 2) of a service license certificate (SPT) as an access control certificate employed in the system of the present invention.

Fig. 32 is a diagram showing a format of a data update certificate (DUT) used as an access control certificate in the system of the present invention.

Fig. 33 is a diagram illustrating data to be updated using a data update certificate (DUT) as an access control certificate employed in the system of the present invention.

Fig. 34 is a diagram schematically illustrating processing up to the utilization of the device in the system of the present invention.

Fig. 35 is a diagram showing a flow of device initial registration processing performed by the device manufacturing entity in the system of the present invention.

Fig. 36 is a diagram showing a flow (1) of the device initial registration processing by the device manager in the system of the present invention.

Fig. 37 is a diagram showing a flow of the device initial registration processing (2 thereof) by the device manager in the system of the present invention.

Fig. 38 is a diagram showing a flow of the device initial registration processing (3) performed by the device manager in the system of the present invention.

Fig. 39 is a diagram showing a flow of a device initial registration process (4) performed by the device manager in the system of the present invention.

Fig. 40 is a diagram showing a flow (5) of the device initial registration processing by the device manager in the system of the present invention.

Fig. 41 is a diagram illustrating device storage data after device initial login processing by the device manager in the system of the present invention.

Fig. 42 is a diagram showing a public key certificate issuance process flow (1) performed by the device manager in the system of the present invention.

Fig. 43 is a diagram showing a public key certificate issuance process flow (2) performed by the device manager in the system of the present invention.

Fig. 44 is a diagram for explaining public key certificate issuing processing by the device manager in the system of the present invention.

Fig. 45 is a diagram for explaining public key certificate issuing processing by the device manager in the system of the present invention.

Fig. 46 is a diagram illustrating device storage data after public key certificate issuance processing by the device manager in the system of the present invention.

Fig. 47 is a diagram illustrating a flow of partition creation and deletion processing for a device in the system of the present invention.

Fig. 48 is a flowchart (1 thereof) illustrating a mutual authentication process with a device in the system of the present invention.

Fig. 49 is a flowchart (2 thereof) illustrating a mutual authentication process (device authentication) with a device in the system of the present invention.

FIG. 50 is a diagram for explaining mutual authentication processing with a device in a public key system in the system according to the present invention

Fig. 51 is a diagram illustrating the configuration of an authentication table generated by a device after mutual authentication processing with the device in the system of the present invention.

Fig. 52 is a diagram illustrating the configuration of an authentication table generated by the reader/writer after mutual authentication processing with the device in the system of the present invention.

Fig. 53 is a diagram for explaining mutual authentication processing of a common key system with a device in the system of the present invention.

Fig. 54 is a diagram for explaining mutual authentication processing of a common key system with a device in the system of the present invention.

Fig. 55 is a flowchart (3 thereof) explaining a mutual authentication process (partition authentication) with a device in the system of the present invention.

Fig. 56 is a flowchart (4 thereof) explaining the mutual authentication processing (partition authentication) with the device in the system of the present invention.

Fig. 57 is a flowchart (1) illustrating a certificate validity/user verification process in the system of the present invention.

Fig. 58 is a flowchart (2) illustrating a certificate validity/user verification process in the system of the present invention.

Fig. 59 is a flowchart (1) illustrating a MAC generation method applicable to the validity of a certificate in the system of the present invention.

Fig. 60 is a flowchart (1) illustrating a partition creation/deletion operation in the system of the present invention.

Fig. 61 is a flowchart (2 thereof) illustrating a partition creation/deletion operation in the system of the present invention.

Fig. 62 is a flowchart (1 thereof) illustrating the partition initial login process in the system of the present invention.

Fig. 63 is a flowchart (2 thereof) illustrating the partition initial login process in the system of the present invention.

Fig. 64 is a flowchart (3 thereof) illustrating the partition initial login process in the system of the present invention.

Fig. 65 is a diagram illustrating device storage data after partition initial login processing in the system of the present invention.

Fig. 66 is a diagram (1) illustrating public key certificate issuance processing by the partition manager in the system of the present invention.

Fig. 67 is a diagram (2) illustrating public key certificate issuance processing by the partition manager in the system of the present invention.

Fig. 68 is a diagram for explaining processing performed when public key system authentication and public key system certificate verification are executed in partition generation processing performed by the partition manager in the system of the present invention.

Fig. 69 is a diagram for explaining a process when public key system authentication and common key system certificate verification are executed in the partition generation process performed by the partition manager in the system of the present invention.

Fig. 70 is a diagram for explaining a process when the common key scheme authentication and the common key scheme certificate verification are executed in the partition generation process performed by the partition manager in the system of the present invention.

Fig. 71 is a diagram for explaining a process when the common key system authentication and the public key system certificate verification are executed in the partition generation process performed by the partition manager in the system of the present invention.

Fig. 72 is a flowchart for explaining a file creation/deletion process using a file registration certificate (FRT) in the system of the present invention.

Fig. 73 is a flowchart for explaining a file creation/deletion operation using a file registration certificate (FRT) in the system of the present invention.

Fig. 74 is a diagram illustrating device storage data after file generation using a file registration certificate (FRT) in the system of the present invention.

Fig. 75 is a diagram for explaining a process when performing public key authentication and public key certificate verification in a file generation process using a file registration certificate (FRT) in the system of the present invention.

Fig. 76 is a diagram for explaining a process when performing public key authentication and common key certificate verification in a file generation process using a file registration certificate (FRT) in the system of the present invention.

Fig. 77 is a diagram for explaining the processing when performing common key system authentication and common key system certificate verification in the file generation processing using the file registration certificate (FRT) in the system of the present invention.

Fig. 78 is a diagram for explaining a process when performing common key system authentication and public key system certificate verification in a file generation process using a file registration certificate (FRT) in the system of the present invention.

Fig. 79 is a diagram showing a flow of file access processing using a service license certificate (SPT) in the system of the present invention.

Fig. 80 is a diagram showing a flow of a file opening operation using a service license certificate (SPT) in the system of the present invention.

Fig. 81 is a diagram illustrating a structure of a file open table generated by a file open operation using a service license certificate (SPT) in the system of the present invention (example 1).

Fig. 82 is a diagram illustrating a structure of a file open table generated by a file open operation using a service license certificate (SPT) in the system of the present invention (example 2).

Fig. 83 is a diagram (example 1) illustrating an example of file access processing using a service license certificate (SPT) in the system of the present invention.

Fig. 84 is a diagram (example 2) illustrating an example of file access processing using a service license certificate (SPT) in the system of the present invention.

Fig. 85 is a diagram illustrating the use of a session key generated by authentication in the system of the present invention.

Fig. 86 is a diagram (example 1) illustrating an example of file access processing using a service license certificate (SPT) in the system of the present invention.

Fig. 87 is a diagram (example 2) illustrating an example of file access processing using a service license certificate (SPT) in the system of the present invention.

Fig. 88 is a diagram for explaining an example of access processing of a compound file using a service license certificate (SPT) in the system of the present invention.

Fig. 89 is a diagram for explaining a process when public key system authentication and public key system certificate verification are executed in a file access process using a service license certificate (SPT) in the system of the present invention.

Fig. 90 is a diagram for explaining a process when public key system authentication and common key system certificate verification are executed in a file access process using a service license certificate (SPT) in the system of the present invention.

Fig. 91 is a diagram for explaining a process when performing common key scheme authentication and common key scheme certificate verification in a file access process using a service license certificate (SPT) in the system of the present invention.

Fig. 92 is a diagram for explaining a process when performing common key system authentication and public key system certificate verification in a file access process using a service license certificate (SPT) in the system of the present invention.

Fig. 93 is a diagram showing a flow of data update processing using a data update certificate (DUT) in the system of the present invention.

FIG. 94 is a diagram showing a data update operation flow using a data update certificate (DUT) in the system of the present invention.

Fig. 95 is a diagram illustrating an example of data update processing using a data update certificate (DUT) in the system of the present invention.

Fig. 96 is a diagram showing a conventional memory configuration.

Fig. 97 is a diagram illustrating a relationship between a conventional memory manager and a user.

Fig. 98 is a diagram illustrating a conventional storage area securing process.

Fig. 99 is a diagram illustrating a conventional memory access method.

Best mode for carrying out the invention

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

The explanation is made with the following items.

A. Description of constituting entities and certificates of a data processing system using devices

A1. Data management system outline using memory mounting device

A2. Structure of equipment

A3. Structure of device manager

A4. Partition manager architecture

A5. Arrangement of certificate users (readers/writers as equipment access devices)

A6. Public key certificate

A7. Storage data in a storage section of a device

A7.1. Device specific information and intra-device partition information area

A7.2. Partitioned areas

A8. Data format of each certificate

A8.1. Partition login certificate (PRT)

A8.2. File denuder certificate (FRT)

A8.3. Service license (SPT)

A8.4. Data update certificate (DUT)

B. Detailed description of device assignment to user, various settings for device, and device usage processing

B1. Procedure from initial login to use of device

B2. Initial login process for device manufacturing entity

B3. Management processing of device manager

B3.1. Device login process for device manager

B3.2. Public key certificate issuing process under device manager management

B4. Management processing of partition manager

B4.1. Partition setting registration/deletion processing using partition registration certificate (PRT) under partition manager management

B4.2. Public key certificate issuing process under partition manager management

B4.3. Processing procedure of various partition generation processing modes

B4.4. File creation and deletion process using file registration certificate (FRT)

B4.5. Processing procedure of various file generation processing modes

B4.6. Service (file access) processing using service license certificates (SPTs)

B4.7. Processing procedure of various access processing modes using service license certificate (SPT)

B5. Data update processing for device using data update certificate (DUT)

[ A1. overview of data management System Using memory mounting device ]

Fig. 1 shows a diagram illustrating an outline of the data management system of the present invention. A memory mount device (hereinafter, simply referred to as a device) 100 is manufactured by a device manufacturing entity (manufacturer) 500 and is provided to a user under the management of a Device Manager (DM) 200 as a device management entity. The form of providing the device to the user may be any form of renting or selling (including transferring), and the like.

The device 100 divides a storage area into a plurality of partitions as data storage areas, and each Partition (Partition a, b.. Z) is used for various services under the management of a Partition manager as various service agents (a, b.. Z)300A to 300Z.

In order to perform the partition setting registration processing for the device 100, the file setting registration processing in the partition set in the device, and the access processing to each registered file, it is necessary to have an access control certificate transmitted to the device by each legitimate certificate issuing apparatus (Ticket issue).

In order to perform the setting/Registration process for the partition of the device 100, a partition Registration certificate (PRT) transmitted from a valid certificate issuing apparatus (packet Issuer) is necessary, and in order to perform the setting/Registration process for the File in the partition set in the device, a File Registration certificate (FRT) issued from a valid certificate issuing apparatus (packet Issuer) is necessary, and in order to access each File, a Service permission certificate (SRT) issued from a valid certificate issuing apparatus (packet Issuer) is necessary.

Each certificate stores, in addition to an access rule to the device 100, a rule related to mutual authentication processing between a reader/writer that performs various processing such as reading and writing to and from the device and the device, for example, a partition size that can be set in the case of a partition registration certificate (PRT), a file length in the case of a file registration certificate (FRT), an executable access mode (e.g., data read and write) in the case of a service permission certificate (SPT), and information on a certificate issuer, a certificate user, and other information. In addition, an ICV (Integrity Check Value) for checking falsification of these certificate storage data is also recorded, and processing within the range recorded in the certificate is allowed to be performed only if the certificate is not falsified.

In the example shown in fig. 1, a certificate issuing apparatus (packet issue) that issues a partition registration certificate (PRT) is set in the Device Manager (DM)200, and a certificate issuing apparatus (packet issue) that issues a file registration certificate (FRT) and a service license certificate (SPT) is set in the service agents a and 300A that are partition managers. In the configuration of fig. 1, the service agents B.. Z, 300B to 300Z basically have the same configuration as the service agent a, and a certificate issuing apparatus (Ticket issue) that issues a file registration certificate (FRT) and a service license certificate (SPT) is set in each service agent.

In fig. 1, the service entity and the Partition Manager (PM) are shown as the same entity, but these entities do not necessarily have to be the same entity, and the partition manager that manages the partition as the storage area set in the device may be a different entity from the service entity that leases the partition as the storage area managed by the partition manager from the partition manager in accordance with a predetermined contract and stores various files in the leased partition to provide the service. In the following description, for the sake of simplicity, a configuration example in which a service agent is provided with a function as a partition manager will be described.

The Partition Manager (PM) of each of the service agents 300A to 300Z issues a request for issuing a partition registration certificate (PRT) to the Device Manager (DM)200 under a predetermined contract for payment of a reward or the like, for example, and a certificate issuing apparatus (ticketsuerer) in the Device Manager (DM) issues the partition registration certificate (PRT) to the Partition Manager (PM) of each service agent with permission of the Device Manager (DM).

Each service agent (partition manager (PM))300 accesses the device 100 owned by the user via the communication interface (I/F), executes processes such as authentication and verification in accordance with rules recorded in the partition login certificate (PRT) received from the Device Manager (DM)200, and executes a partition setting login process within the permission range recorded in the partition login certificate (PRT). The processing thereof will be described in detail later.

The communication (I/F) may be a wired or wireless interface as long as it is an interface capable of data communication with an external device (equipment), and for example, when the equipment has a USB connection structure, it may be a USB I/F, and if it is an IC card, it may be a reader/writer for an IC card, and further, if it is equipment having various communication functions such as a public line, a communication line, and the internet, or equipment connectable to these communication devices, it may be configured as a data communication I/F according to various communication methods.

When the partition of the service agent 300 is set in the device 100, each service agent 300 accesses the device 100 owned by the user through the communication interface (I/F), executes processes such as authentication and verification in accordance with rules recorded in a file registration certificate (FRT) issued by a certificate issuing apparatus (packet issue) of each service agent 300, and executes a file setting registration process within a permission range recorded in the file registration certificate (FRT). The processing thereof will be described in detail later.

Further, each service agent 300 accesses the device 100 owned by the user through the communication interface (I/F), executes processing such as authentication and verification in accordance with the rule recorded in the service license certificate (SPT) issued by the certificate issuing apparatus (packet issue) of each service agent, and executes processing such as access (for example, reading and writing of data) within the permitted range recorded in the service license certificate (SPT). The processing thereof will be described in detail later.

As shown in fig. 1, a code management means 400 is provided at a level higher than the device manager 200 and the partition manager 300, and performs a process of assigning codes, which are identification information of the respective entities, to the device managers and the partition managers. The code given to each manager is used as storage data of the access control certificate such as the partition registration certificate (PRT), the file registration certificate (FRT), and the service license certificate (SPT).

Before the device 100 is provided (e.g., rented, sold) to and used by a user, a Device Manager (DM)200 that manages a providing device is set, and device manager code and other management information of the device manager are written into the providing device. These data will be described in detail later.

The relationship between the issuing process of the public key certificate and each entity in the data management system using the storage device according to the present invention will be described below with reference to fig. 2.

Fig. 2 shows a device manager as a device management entity, 2 partition managers 300A and 300B as management entities of respective partitions set in a device, and a code management mechanism 400 for giving an identification code to the device manager 200. In addition, still be equipped with: the device manager association Certificate Authority (CA) (DEV) 610 issues a device (partition registration Certificate (PRT) issuing device (PRT issue) 210 or a device association public key Certificate (CERT-DEV) corresponding to the device manager 200 or the device 100 in response to a public key Certificate issue request from the login Authority 210 managed by the device manager 200, and the partition manager association Certificate Authority (CA PAR) 620, 630 issues a device (file registration Certificate (FRT) issuing device (FRT issue) 310, a service license issuing device (SPT)320, readers 711-714 as a Certificate user or device access device, or a partition association public key Certificate (CERT-PAR) corresponding to a partition of the device 100 in the partition managers 300A, 300B.

In addition, in fig. 2, it is illustrated that the certification authorities are respectively set as the device manager corresponding certification authorities: the DM corresponds to the certification authority with CA (or CA (dev))610 and partition manager: the PAR is configured by CA (or CA (PAR)), but a unique certification authority having two functions may be provided, or a common certification authority corresponding to a plurality of partition managers and a certification authority corresponding to a device manager may be provided separately, and the configuration may be freely set.

The device manager 200 and the partition managers 300A and 300B each have a Registration Authority (RA: Registration Authority)220 and 330 for receiving a public key certificate of its own, a public key certificate of each device (certificate issuing device or certificate user) managed by each manager, or a public key certificate issuing request from the device 100, verifying the received issuing request, and performing processing for transmitting the certificate issuing request to the certification Authority and processing for managing the issued public key certificate after verification.

Public key certificates issued from the respective Certification Authorities (CA)610, 620, 630 by the two Registration Authorities (RA)220, 330 are stored in the device 100, and used in, for example, partition setting processing as processing for 100, mutual certification processing such as file setting processing as processing for partitioning, access processing for files, and the like, or validity check processing of the respective certificates. The process of issuing the public key certificate and the various processes using the public key certificate will be described in detail later.

In fig. 2, the device 100, as a management partition having partition managers 1, 300A: PM1 area, management partition of partition manager 2, 300B: the PM2 area, and in addition, a DM area as a management partition of the device manager 200.

The device manager 200 includes a partition registration certificate issuing apparatus (PRT issue) 210, a partition manager 300 includes a file registration certificate issuing apparatus (FRT issue) 310 and a service license certificate issuing apparatus (SPT issue) 320, and issues each certificate.

The partition managers 1 and 300A structurally have dedicated readers 711 to 713 (read/write interfaces for devices) for PRT, FRT, and SPT certificates, respectively, and the partition managers 2 and 300B have a reader 714 for each certificate. The reader/writer may adopt the various configurations described above.

Further, a specific example of the entity will be described with reference to fig. 3. Fig. 3 shows an example of a device use configuration in which a partition manager serving as a service agent for providing services using partitions set in a device is assumed to be two entities, namely, east-west rail company and south-north rail company. It is assumed that a company such as the japanese railroad group registers the partition settings of the partition manager.

East-west rail company, sets and registers a plurality of files in a partition set in a user equipment managed by itself: PM 1. Such as promissory note files, prepaid files, and other files for other purposes. The partition manager, which is the subject of each service, can register various files in the partition set according to the service provided by itself and allocated by the device manager. However, in order to perform the setting registration of a file, a file registration certificate (FRT) is necessary.

East-west railroad company, 1 partition serving as a management device: the partition manager of the PM1 zone. Partitioning: the PM1 area is configured to be set by the japan railway group as a device manager by performing processes such as authentication and verification according to rules recorded in a partition registration certificate (PRT) issued by the japan railway group, and by partition setting registration processes within an allowable range recorded in the partition registration certificate (PRT), and then to be assigned to the east-west railway company.

The east-west railroad company sets various files in the assigned partitions according to the services provided by itself: PM1 region. For example, a scheduled ticket file or a prepaid file, and various necessary data such as the name of the scheduled ticket user, the period of use, and the use interval as scheduled ticket management data are recorded in the data storage area of the scheduled ticket file. In addition, in the prepaid file, a user name, prepaid amount, balance data, and the like are recorded. In this file setting process, processes such as authentication and verification are executed according to rules recorded in a file registration certificate (FRT) issued by the FRT issue of the east-west railroad company, and setting is performed by the file setting registration process within the allowable range recorded in the file registration certificate (FRT).

The apparatus in which various files are set as above is used by the user. For example, when the user uses the device, the device may be installed in a ticket checker provided with a reader/writer as a device access device. For example, a legitimate reader/writer provided in the ticket checker accesses a file for a scheduled ticket, and reads the usage section. In addition, it is also possible to access the prepaid file and perform an update process on the balance data in the prepaid file.

In the service license (SPT) issued by the service license (SPT issue) issuing device (SPT issue) of east-west railway companies, which file in the access device is accessed and which process (reading, writing, deduction, etc.) is performed is recorded. For example, the above-described certificate is stored in a reader/writer, which is a legitimate device access apparatus provided in the ticket checker, and processes such as an authentication process and a certificate check with the device are executed according to a rule recorded in the certificate. When the reader/writer as the device access apparatus and the device are mutually legitimate apparatuses and thus the use certificate is legitimate, processing (for example, data reading, writing, deduction, or the like within a file) within the permission range recorded in the service license certificate (SPT) can be performed.

Fig. 4 shows a general correspondence relationship between a certificate issuing apparatus (packet issue) that issues various certificates such as a partition login certificate (PRT), a file login certificate (FRT), and a service license certificate (SPT), and a certificate User (packet User) that uses the certificate issued by the certificate issuing apparatus.

As described in fig. 1 and other figures, the certificate issuing apparatus (packet Issuer) issues various certificates such as a partition registration certificate (PRT), a file registration certificate (FRT), and a service license certificate (SPT) under the management of the device manager or the partition manager in accordance with the processing performed on the device. The certificate User (Ticket User) is a device or apparatus that uses a certificate issued by the certificate issuing apparatus, and specifically corresponds to, for example, a device such as a reader/writer as a device access apparatus that performs processing such as writing and reading of data to and from the device.

As shown in fig. 4, a credential user may store and use multiple credentials. Further, only a single certificate, for example, the service license certificate (SPT) which permits only the section data reading of the scheduled ticket file described with reference to fig. 3 may be stored, and only the process of reading the section data may be executed.

For example, in a ticket checker dedicated for reading a promissory note of a railway company as a service agent (partition manager), a reader/writer as a device access device is set which stores only a service license certificate (SPT) which permits only reading of section data of a file for the promissory note, and a reading process of the section data is executed from a device owned by a user. For example, the service license (SPT) that allows only reading of the section data of the scheduled ticket file and the service license (SPT) that allows the reduction processing of the balance data of the prepaid file may be stored in a reader/writer as a device access device of a ticket checker that can execute both the scheduled ticket and the prepaid monetary amount processing, and the processing of both the scheduled ticket file and the prepaid file may be executed.

Further, a certificate user (for example, a reader/writer) may be configured to store a partition registration certificate (PRT), a file registration certificate (FRT), and a service license certificate (SPT) and to be able to perform all processes such as partition registration, file registration, and data access in a file. The processing that the credential user can perform is determined by the credentials that the credential user can use.

[ A2. Structure of apparatus ]

Hereinafter, a device having the above-described memory in which the data storage area is divided into a plurality of partitions will be described. Fig. 5 shows a block diagram of the apparatus.

As shown in fig. 5, the device 100 includes a CPU (Central Processing Unit) 101 having a program execution function and an arithmetic Processing function, and includes: a communication interface 102 having an interface function for performing communication processing with an external device such as a reader/writer as a device access apparatus; a ROM (Read Only Memory) 103 that stores various programs executed by the CPU101, such as an encryption processing program and the like; a RAM (Random access memory) 104 functioning as a loading area for executing programs or a work area in each program process; an encryption processing unit 105 that executes encryption processing such as authentication processing with an external device, generation of an electronic signature, verification processing, encryption and decryption processing of stored data; the storage unit 106 is configured by, for example, an EEPROM (Electrically Erasable and programmable read only memory) that stores device specific information including various key data while setting a storage file. Information stored in the storage section 106 (e.g., EEPROM)106 will be described in detail later.

Fig. 6 shows a data storage structure of the storage unit 106. The storage unit is, for example, a flash memory which is one form of a nonvolatile memory called an eeprom (electrically Erasable Programmable rom) and which can be electrically rewritten.

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

In the partition area, a partition registered as a management area of the partition manager is set. The memory shown in fig. 6 gives an example in which partitions have been set, but in a newly manufactured device, partitions have not been set yet and thus there is no partition area. As described above, the partition is set in the memory of the device by the partition manager as each service master according to the rule set in the partition registration certificate (pRT), which is a predetermined program, based on the PRT certificate issued by the partition registration certificate (PRT) issuing device (PRT issue) managed by the device manager.

In the device specific information and intra-device partition information area, information on a device manufacturing entity, information on a device manager, partition setting information, key information necessary for performing access to the device and partition setting registration processing, and the like are stored. These pieces of stored information will be described in detail later. The stored data in the device unique information area may be used as data corresponding to IDm, which is a device unique value used in mutual authentication described later.

As shown in the figure, the partition area further includes 1 or more file areas, unused areas, partition unique information, and intra-partition file areas. The file area is an area for storing a file set by the service agent as the partition manager for each service such as the scheduled ticket and the prepaid service. The unused area is an area in which a file can be further set. The partition unique information and the intra-partition file area store, for example, information on files in the partition, key information necessary for file access processing, and the like. These pieces of stored information will be described in detail later.

[ A3. Structure of device manager ]

Hereinafter, the configuration of the device manager will be described with reference to fig. 7. A device manager is a management entity that provides (rents or sells) devices to users.

The device manager 200 includes a partition registration certificate (PRT) issuing device (PRT issue) 210, and issues a partition registration certificate (PRT) that enables partition setting for a device in response to a request from a partition manager serving as a service agent that provides services using a partition set as a partition area in the device.

The device manager 200 also issues a device-associated public key certificate (CERT-DEV) corresponding to the device. The device manager 200 has a function as a Registration Authority (RA) 220 that receives a public key certificate issuance request from a device, checks the received issuance request, and performs a process of transmitting the certificate issuance request to a certificate Authority (ca (dev)) 610 and a process of managing the issued public key certificate.

As shown in fig. 7, the partition registration certificate (PRT) issuing apparatus (PRT issue) 210 includes a control apparatus 211 and a database 212, and stores, in the database 212, data for certificate issuance management, such as a partition manager identifier, a certificate identifier, and a certificate user (e.g., a reader/writer, a PC, etc.) identifier, which are associated with each other, as issue management data of the partition registration certificate (PRT).

The Registration Authority (RA) 220 includes a control unit 221 and a database 222 for public key certificate issuance management, and stores data relating, for example, a device identifier for transmitting a public key certificate, an identifier (serial number) of the public key certificate, and the like in association with each other in the database 222 as issuance management data of the public key certificate.

The control device 211 of the partition registration certificate (PRT) issuing device (PRT issue) 210 of the device manager 200 executes the process of issuing the partition registration certificate (PRT) by data communication with the partition manager. The control device 221 of the Registration Authority (RA) 220 executes a process of issuing a public key certificate to a device, and at this time, executes communication with the device and communication with a device manager association Authority (ca (dev)) 610. These processes will be described in detail later. Here, the configuration of the control devices 211 and 221 will be described with reference to fig. 8.

The control devices 211 and 221 are each realized by the same configuration as that of a PC as a data processing device, for example, and specifically have the configuration shown in fig. 8. The following describes the configuration of the control device. The control Unit 2111 is constituted by a Central Processing Unit (CPU) that executes various Processing programs. A ROM (Read Only Memory) 2112 is a Memory for storing an execution processing program such as an encryption processing program. A RAM (Random Access Memory) 2113 is used as a storage area for programs executed by the control unit 2111, for example, programs such as a database management program, an encryption processing program, and a communication program, and is also used as a work area for the various program processes.

The display portion 2114 includes a display device such as a liquid crystal display device or a CRT, and displays data when various programs are executed, for example, data content of a processing target, under the control of the control portion 2111. The input unit 2115 includes a keyboard and a pointing device such as a mouse, and outputs commands and input data from the respective input devices to the control unit 2111. An HDD (Hard Disk Drive) 2116 stores programs such as a database management program, an encryption processing program, a communication program, and various data.

The drive 2117 has a function of controlling access to various recording media, and examples thereof include a magnetic Disk such as an HD (Hard Disk) or FD (flexible Disk), an optical Disk such as a CD ROM (Compact Disk ROM), a magneto-optical Disk such as a Compact Disk, and a semiconductor memory such as a ROM or flash memory. Various recording media such as magnetic disks, etc., store programs, data, etc. The communication interface 2118 functions as a wired or wireless communication interface via a network, a cable connection, a telephone line, or the like, and functions as a communication interface with each entity such as a user's device, a partition manager, and a certification authority.

[ A4. Structure of partition manager ]

The following describes the configuration of the partition manager with reference to fig. 9. The partition manager is a management entity for a partition set in a device provided (sold or leased) to a user.

The partition manager 300 sets a partition, which is a storage area, in the storage unit of the user equipment according to the rule recorded in the supplied PRT using the partition registration certificate (PRT) supplied from the device manager, and provides a service using the set partition.

In the set partition, a file corresponding to the service or the data can be set. However, in order to perform the file setting process, it is necessary to acquire a file registration certificate (FRT), and in order to perform data access such as reading and writing of data in a file, it is necessary to acquire a service license certificate (SPT). File setting and data access processing are executed by a certificate user, specifically, for example, a dedicated reader/writer as a device access apparatus using a certificate.

The partition manager 300 includes the file registration certificate (FRT) issuing device (FRT issue) 310 and the service license certificate (SPT issue) 320 as the certificate issue processing devices for the certificate users as described above.

The partition manager 300 also issues a partition-associated public key certificate (CERT-PAR) corresponding to the partition of the device. The device manager 300 has a function as a Registration Authority (RA) 330 that receives a public key certificate issuance request from a device, checks the received issuance request, and performs a process of transmitting the certificate issuance request to a certificate Authority (ca (dev)) 620 and a process of managing the issued public key certificate.

As shown in fig. 9, the file registration certificate (FRT) issuing device (FRT issue) 310 of the partition manager 300 includes a control device 311 and a database 312, and stores, in the database 312, data for certificate issuance management, for example, data relating to a certificate user (for example, a reader/writer, a PC, or the like) identifier, a certificate identifier, and the like of a certificate issuance destination as issuance management data of the file registration certificate (FRT).

The service license (SPT) issuing device (SPTIssuer)320 of the partition manager 300 includes a control device 321 and a database 322, and the database 322 stores data for certificate issuance management, such as data associating a certificate user (e.g., a reader/writer or pC as a device access device) identifier, a certificate identifier, and the like of a certificate issuance destination, as issuance management data of the service license (SPT).

The Registration Authority (RA) 330 has a database 332 for public key certificate issuance management, and stores data relating to the issuance management data of public key certificates, such as device identifiers, partition identifiers, and identifiers (serial numbers) of public key certificates.

The control means 311 of the file registration certificate (FRT) issuing means (PRT issue) 310 of the partition manager 300 executes the issuing process of the file registration certificate (FRT) by data communication with a certificate user (for example, a reader/writer, a PC, or the like as a device access means),

the control device 321 of the service license certificate (SPT) issuing device (SPT issue) 320 of the partition manager 300 executes the process of issuing the service license certificate (SPT) by data communication with a certificate user (for example, a reader/writer, a PC, or the like as a device access device). The controller 331 of the Registration Authority (RA) 330 executes a process of issuing a public key certificate to a device, and at this time, executes communication with the device and communication with a partition manager association Authority (ca (par)) 620. These processes will be described in detail later.

The control devices 311, 321, and 331 of the partition manager 300 have the same configurations as those of the device manager described above with reference to fig. 8, and therefore, the description thereof will be omitted.

[ A5. Structure of certificate user (reader/writer as device access means) ]

The reader/writer as the device access device is configured as a device that executes various processes such as partition setting, file setting, data reading, writing, and increase/decrease of money amount data on the device. The processing of the device is performed according to the rule recorded in the partition registration certificate (PRT), the file registration certificate (FRT), and the service license certificate (SPT) used in the processing. I.e. all processing of the device, is limited by the certificates used.

Fig. 10 shows an example of the configuration of a reader/writer as a device access apparatus. As shown in fig. 10, the reader/writer 700 includes a CPU (central processing Unit) 701 having a program execution function and an arithmetic processing function, and includes: a communication interface 702 having an interface function for performing communication processing with an external device; a ROM (Read Only Memory) 703 that stores various programs executed by the CPU701, such as an encryption processing program and the like; a RAM (Random Access Memory) 704 functioning as a loading area for executing programs or a work area in each program process; an encryption processing unit 705 that executes encryption processing such as authentication processing with an external device, generation of an electronic signature, verification processing, encryption and decryption processing of stored data; the storage unit 706 is configured by, for example, an EEPROM (Electrically Erasable and Programmable ROM) that stores various key data for authentication, encryption, and decryption, and information unique to the reader/writer.

[ A6. public key certificate ]

In the use of the device having a storage area divided into partitions according to the present invention, when data communication is performed between entities, a certificate issuing apparatus, a certificate user, a device, and the like, it is necessary to transmit necessary information after confirming that a data transmitting side and a data receiving side are mutually legitimate data transmission/reception targets. As measures for realizing a security structure in data transfer, encryption processing of transfer data, signature generation and verification processing corresponding to data should be performed.

The encrypted data can be restored to usable decrypted data (plaintext) by decryption processing performed in predetermined steps. Such data encryption and decryption methods that use an encryption key for encryption of information and a decryption key for decryption have been known.

There are various types of data encryption and decryption methods using an encryption key and a decryption key, and one example thereof is a so-called public key encryption method. In the public key encryption system, the keys of the sender and the receiver are different from each other, one key is a public key that can be used by an unspecified user, and the other key is a secret key to be kept secret. For example, the data encryption key is made a public key, and the decryption key is made a secret key. Alternatively, the authenticator generation key is used as a secret key, and the authenticator verification key is used as a public key.

Unlike the so-called common key encryption system using a key common to encryption and decryption, in the public key encryption system, a secret key that must be kept secret can be possessed by a specific user, and thus management of the key is advantageous. However, the public key encryption system is slower in data processing speed than the common key encryption system, and is often used for a small amount of data such as transmission of a secret key and digital signature. A typical public key encryption scheme is RSA (Rivest-Shamir-Adleman: rivast-samimel-aldleman). In the RSA encryption scheme, a very large product of 2 prime numbers (e.g., 150 bits) is used, and the difficulty in factoring the product of 2 large prime numbers (e.g., 150 bits) is utilized.

In the public key encryption system, since a public key can be used for a plurality of unspecified users, a method of using a certificate for certifying whether or not an assigned public key is legitimate, that is, a so-called public key certificate, is often used. For example, the user a may generate a pair of a public key and a secret key, issue the generated public key to the certification authority, and acquire a public key certificate from the certification authority. The user a discloses the public key certificate to the public. The unspecified user obtains the public key from the public key certificate by a predetermined program, encrypts a document or the like, and transmits the encrypted document to the user a. The user a encrypts the encrypted document with the secret key, and the like. In addition, the system may be such that the user a signs a document or the like with a secret key, and a non-specific user obtains a public key from a public key certificate by a predetermined program and verifies the signature.

The public key Certificate is a Certificate issued by a certification Authority (ca (dev)) by public key cryptography, that is, a Certificate generated by a certification Authority by submitting a user's own ID, public key, and the like to the certification Authority and adding information such as the ID and expiration date of the certification Authority and a signature of the certification Authority.

The format of the public key certificate is briefly shown in fig. 11. Each data will be briefly described below.

The Version of certificate (Version) number indicates the Version of the public key certificate format.

The Serial Number of the certificate is a Serial Number (SN), and is a Serial Number of a public key certificate set by a public key certificate issuing authority (certification authority: CA).

The Signature algorithm (algorithm) and the algorithm parameter (parameters) of the Signature algorithm Identifier (Signature algorithm Identifier) field are fields in which the Signature algorithm and the parameter of the public key certificate are recorded. Further, as the signature algorithm, there are elliptic curve cryptography and RSA, and when elliptic curve cryptography is used, parameters and key length are recorded, and when RSA is used, key length is recorded.

The Name of the issuing authority (certification authority: CA) is a field in which the Name (issue) of the issuing authority (CA), which is the Issuer of the public key certificate, is recorded in a recognizable form (recognized Name).

The validity period (validity) of the certificate, the start date and time and the end date and time of the validity period of the certificate are recorded.

The user name (Subject) of the public key certificate records identification data as an authentication target of the user. Specifically, for example, an identifier or category such as an ID of the user equipment, an ID of the entity providing the service, or the like is recorded.

The user Public Key field (subject Public Key Info) is a field in which a Key algorithm (algorithm) and a Key (subject Public Key) as Public Key information of the user are stored.

In the option area, attribute data of the user and other optional data related to the 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 membership group information of a user. Here, the user is a user of the public key certificate, for example, a device manager, a partition manager, a certificate user, a certificate issuing apparatus, a device, or the like.

In the optional area, category information indicating categories of entities and apparatuses such as a certificate user, a certificate issuing apparatus, a device manager, and a partition manager is also recorded as category information.

In addition, when the device manager also serves as a partition registration certificate issuing apparatus (PRT issue), a partition registration certificate issuing apparatus Code (PRTIC: PRT issue Code) described later may be set as a Device Manager Code (DMC), and when the partition manager also serves as a file registration certificate issuing apparatus and a service license issuing apparatus, a file registration certificate issuing apparatus Code (FRTIC: FRT issue Code) and a service license certificate issuing apparatus Code (SPT IC: SPT issue Code) may be set as a Partition Manager Code (PMC). These codes are also recorded in certificates (PRT, FRT, SPT, and the like) described later.

Further, each certificate issuing apparatus may be assigned a unique code different from the Device Manager Code (DMC) or the Partition Manager Code (PMC). The code allocation in this case is performed by the code management organization described above.

The issuer signature is an electronic signature performed on data of a public key certificate using a secret key of a public key certificate issuer (CA), and a user of the public key certificate can check whether the public key certificate is falsified by using the public key of the public key certificate issuer (CA).

Hereinafter, a method of generating an electronic signature using the public key encryption method will be described with reference to fig. 12. The processing shown in fig. 12 is a flow of processing for generating electronic signature data using ECDSA (Elliptic Curve digital signature Algorithm). Here, an example in which Elliptic Curve Cryptography (hereinafter, referred to as ECC) is used as the public key Cryptography will be described. In addition, in the data processing apparatus of the present invention, in addition to the elliptic curve cryptography, RSA cryptography (Rivest, Shmir, Adleman: Riwester, Samier, Adleman) which is also a public key cryptography, or the like (ANSI X9.31) can be used.

The steps in fig. 12 will be described below. In step S1, let P be the characteristic number and a, b be the coefficient of the elliptic curve (elliptic curve: y)²＝x³+ax+b、4a³+27b²≠0)(mod P)), G is a base point on the elliptic curve, r is the number of bits of G, and Ks is a secret key (0)<Ks<r). In step S2, the hash value of the information M is calculated and set to f ═ hash (M).

Here, a method of obtaining a hash value by a hash function will be described. The hash function is a function that takes information as input, compresses the information into data having a predetermined bit length, and outputs the data as a hash value. The hash function has a characteristic that it is difficult to predict an input from a hash value (output), when data input to the hash function is changed by 1 bit, the hash value is changed by a plurality of bits, and it is difficult to find different input data having the same hash value. As the hash function, MD4, MD5, SHA 1, or the like is sometimes employed. In this case, the MAC (check value: equivalent to ICV) as the final output value is a hash value.

Next, in step S3, a random number u (0< u < r) is generated, and in step S4, coordinates V (Xv, Yv) obtained by multiplying the base point by u are calculated. The addition operation and the 2-fold operation on the elliptic curve are defined as follows.

Assuming that P ═ P (Xa, Ya), Q ═ Q (Xb, Yb), R ═ R (Xc, Yc) ═ P + Q, then

When P ≠ Q (additive operation)

Xc＝λ²-Xa-Xb

Yc＝λ×(Xa-Xc)-Ya

λ＝(Yb-Ya)/(Xb-Xa)

When P is Q (2 times operation)

Xc＝λ²-2Xa

Yc＝λ×(Xa-Xc)-Ya

λ＝(3(Xa)²+a)/(2Ya)

The method of calculating u times the point G using the above-listed formulae (calculation speed is slow but is most easily understood) is performed as follows. Calculating G, 2 XG, 4 XG, and spreading u to 2-system number, and corresponding to the position of 1 occurrence to 2ⁱX G (i times 2 times the value of G (i is the position of the bit counted from the LSB of u)) is added.

In step S5, c is calculated to Xvmod r, and it is determined whether the value is 0 in step S6, and if not, d [ (f + cKs)/u ] mod r is calculated in step S7, and it is determined whether d is 0 in step S8, and if d is not 0, c and d are output as electronic signature data in step S9. Assuming that r is 160 bits in length, the electronic signature data is 320 bits in length.

When c is 0 in step S6, the process returns to step S3 to regenerate a new random number. Also, when d is 0 in step S8, the process returns to step S3 to regenerate a new random number.

Hereinafter, a method of verifying an electronic signature using the public key encryption method will be described with reference to fig. 13. In step S11, let M be information, p be the number of features, and a, b be the coefficients of an elliptic curve (elliptic curve: y)²＝x³+ax+b、4a³+27b²Not equal to 0) (mod P)), G being the base point on the elliptic curve, r being the number of bits of G, G and Ks × G being the public key (0)<Ks<r). In step S12, it is checked whether the electronic signature data c and d satisfy 0<c<r、0<d<And r. When satisfied, in step S13, the hash value of the information M is calculated and set to f ═ hash (M). Next, in step S14, h 1/d mod r is calculated, and in step S15, h1 fhmod r and h2 ch mod r are calculated.

In step S16, the calculated h1 and h2 are used to calculate the point P ═ (Xp, Yp) ═ h1 × G + h2 · Ks × G. Since the base points G and Ks × G are known to the electronic signature verifier, scalar product calculation of the points on the elliptic curve can be performed in the same manner as in step S4 of fig. 12. Then, in step S17, it is determined whether or not the point P is an infinity point, and if not, the routine proceeds to step S18 (actually, determination of an infinity point may be performed in step S16, that is, when addition of P ═ X, Y and Q (X, Y) is performed, λ cannot be calculated, and thus P + Q can be determined to be an infinity point). Xp mod r is calculated in step S18 and compared with the electronic signature data c. Finally, if the values match, the process proceeds to step S19, and the electronic signature is determined to be correct.

When the electronic signature is determined to be correct, it is determined that the data has not been tampered with, and the party having the secret key corresponding to the public key generates the electronic signature.

In step S12, if the electronic signature data c and d do not satisfy 0< c < r, 0< d < r, the flow proceeds to step S20. Further, in step S17, if the point P is the infinity point, the flow proceeds to step S20. Further, in step S18, when the value of Xp mod r does not match the electronic signature data c, the process also proceeds to step S20.

When it is determined in step S20 that the electronic signature is not correct, it can be determined that the data has been tampered with or that the party having the secret key corresponding to the public key has not generated the electronic signature.

The device in the system of the present invention stores a public key certificate (CERT-DEV) corresponding to the device, which is issued to the device by a management registration authority of a device manager, in the device, and also stores a public key certificate (CERT-PAR) corresponding to a partition, which is issued to the partition of the device by a management registration authority of a partition manager, in each partition of the device. These public key certificates are used for mutual authentication between a certificate user (for example, a reader/writer as a device access apparatus) and a device, signature generation, verification processing, and the like in processing for the device, that is, partition login setting processing using a partition login certificate (PRT), file login setting processing using a file login certificate (FRT), and data processing using a service license certificate (SPT). Specific examples of these processes will be described later with reference to flowcharts.

[ storage data in storage section of A7. device ]

Hereinafter, storage data of a device having a partitioned storage area according to the present invention will be described. As described above with reference to fig. 6, the device has a storage unit made of, for example, an EEPROM, and has, as main areas, a partition area, an unused area, device specific information, and an intra-device partition information area. The storage data of the above-described areas will be described in order with reference to the drawings.

(A7.1. Equipment intrinsic information and information area partitioned in Equipment)

First, the device specific information and the data in the intra-device partition information area will be described. In the device specific information and intra-device partition information area, information of a device manufacturing entity, information related to a device manager, partition setting information, key information necessary for performing access to the device and partition setting registration processing, and the like are stored.

Fig. 14 shows a data structure of the manufacturing Information Block (manufacturing Information Block). The numerical value of each region indicates the number of bytes. As described with reference to fig. 6, in the structure of the present embodiment, there are 1: a 32 byte structure. The gray portion in the figure may be encrypted data or unencrypted data.

In the manufacturing Information Block (manufacturing Information Block), the following data is stored.

Writeable Flag (writeable Flag): a discrimination flag to allow writing to the block (e.g., 0 xffff: write allowed, others: write not allowed)

Manual Code (manufacturer Code): card manufacturer identification number

Manual Equipment Code: card production line numbering

Manufacturing Date: the date of card manufacture. For example, 1/2001 is set to 0x 0000.

Manual Serial Number (manufacturing Serial Number): card manufacturing serial number

Device vendor Code: IC chip supplier number

Device Code: IC chip model

Device Parameter: other parameters

Since these pieces of information written in the block are unique, IDm, which is an inherent identifier of the Device (Device), is defined based on these pieces of information. The Device unique identifier may be obtained from all Information written in the manufacturing Information Block (manufacturing Information Block), a part of the written Information, or operation data obtained from the written Information.

Fig. 15 shows a data structure of a Device Management information block (Device Management information block). The following data is stored in a Device management information Block (Device management information Block).

Writeable Flag (writeable Flag): a discrimination flag to allow writing to the block (e.g., 0 xffff: write allowed, others: write not allowed)

DMC (Device Manager Code: Device Manager Code): identification number of Device Manager (DM)

DMC Version: a version of a Device Manager Code (DMC). E.g. as comparison conditions when updating the DMC

Total Block number Device: total number of blocks in a Device

Free Block number Device: number of free blocks in a Device

Pointer of Free Area: pointer to free area

Fig. 16 shows a data structure of a Device Key DefinitionBlock (PUB). The following data is stored in a public key system Device key definition Block (PUB).

PUB _ ca (dev) Pointer: pointer to block storing public key of device manager corresponding certification authority (CA (DEV)) for issuing public key certificate through login authority managed by device manager

PUB _ ca (dev) Size: size of public key of certification authority ca (dev)

PRI _ DEV Pointer: pointer to block storing secret key of Device

PRI _ DEV Size: size of secret key of Device

PARAM _ DEV Pointer: pointer to block storing public key parameters of Device

PARAM _ DEV Size: size of public key parameter of Device

CERT _ DEV Pointer: pointer to block storing public key certificate of Device (Device) issued by certification authority ca (dev)

CERT _ DEV Size: size of public key certificate of Device (Device) issued by certification authority ca (dev)

CRL _ DEV Pointer: pointer to block storing revocation list (RevocationList) of Device (Device)

CRL _ DEV Size: size of Revocation List (Revocation List) of Device (Device)

Prtic (prt issue category): partition login credential (PRT) issuer categories

PRTIC Version: version of partition Login certificate (PRT) issuer Category (PRTIC)

Dual _ dev (dut issue category): data update certificate (DUT) issuer category

Dual _ DEV Version: version of data Update certificate (DUT: Date Update Ticket) Issuer (DUTIC)

Among the above data, the revocation list is a device revocation list issued in the form of a table of unauthorized devices by, for example, a manager of the device distribution system, and is data in which identification data of unauthorized devices is listed in the form of a table. When the device set in the reader/writer as the device access apparatus is a device listed in the revocation list, measures such as stopping the processing should be taken.

For example, the latest revocation list is transferred to all the readers/writers as the device access means that perform processing on the device at any time, and the reader/writer can refer to the list to determine whether to perform or stop the processing when performing the processing on the device. Alternatively, the latest revocation list is browsed through the network by using a communication function of a reader/writer as a device access apparatus, thereby acquiring device information listed in the revocation list and determining whether to execute or stop the process. The specific processing using the revocation list will be described later with a flowchart.

The data Update certificate (DUT: Date Update Ticket) among the above-mentioned data is an access restriction certificate for permitting and restricting Update processing when performing Update processing on various data stored in the device, and is a certificate for recording access rules to the device, as with the above-mentioned PRT, FRT, SPT certificates. This data update certificate (DUT) will be described in more detail later.

Fig. 17 shows a data structure of a Common Key system Device Key definition block (Common). The following data is stored in a device key Definition Block (Common) of the Common key system.

Mkauth _ DEV _ A Pointer: pointer to master key for two-way single key authentication (Mkauth _ DEV _ A)

Mkauth _ DEV _ a Size: size of master key (Mkauth _ DEV _ A) for bidirectional single key authentication

Kauth _ DEV _ B Pointer: pointer to a bidirectional single-key authentication key (Kauth _ DEV _ B)

Kauth _ DEV _ B Size: size of Key for two-way Single Key authentication (Kauth _ DEV _ B)

Kprt Pointer: pointer to block storing MAC verification key (Kprt) of partition login certificate (PRT)

Kprt Size: size of key (Kprt) for MAC verification of partition registration certificate (PRT)

Kdut _ DEV1-4 Pointer: pointer to block storing MAC check key (Kdut) of data update certificate (DUT)

Kd ut _ DEV1-4 Size: size of key (Kdut) for MAC verification of data update certificate (DUT)

IRL _ DEV Pointer: pointers to blocks storing Device ids (Device ids) of illegal devices in the form of revocation lists (revocationlists) of the devices (devices).

IRL _ DEV Size: size of Revocation List (Revocation List) of Device (Device)

The method of bidirectional single-key authentication, MAC (message authentication Code) verification processing, given in the above data will be described in detail later.

In addition, there are 4 kinds of Kdut _ DEV and used in pairs, that is, (Kdut _ DEV1, Kdut _ DEV2), (Kdut _ DEV3, Kdut _ DEV 4). For example, Kdut _ DEV1, 3 is used to generate the MAC and Kdut _ DEV2, 4 is used for encryption.

Fig. 18 shows a data structure of a Device Key Area (Device Key Area). The following data is stored in a Device Key Area (Device Key Area). In addition, version information is also stored in each storage Key of the Device Key Area (Device Key Area). When the key is updated, the version information is also updated.

IRL _ DEV: revocation List (Device ID) in which Identifiers (IDs) of a Revocation Device (Device) and a Revocation apparatus (a certificate user such as a reader/writer or a PC serving as a Device access apparatus, or a certificate issuing apparatus) are registered

CRL _ DEV: revocation List (Certificate) in which public key Certificate identifiers (e.g., serial numbers: SN) of a Revocation Device (Device) and a Revocation apparatus (a reader/writer as a Device access apparatus, a Certificate user such as a PC, and a Certificate issuing apparatus) are registered

Kd ut _ DEV 1: key for MAC verification of data update certificate (DUT)

Kd ut _ DEV 2: encryption key for data update

Kd ut _ DEV 3: key for MAC verification of data update certificate (DUT)

Kd ut _ DEV 4: encryption key for data update

Kprt: key for MAC verification of partition entry certificate (PRT)

CERT _ DEV: the issuing manager corresponds to the public key certificate of the Device (Device) issued by the certification authority (CA (DEV)) of the public key

PRI _ DEV: secret key of Device

PARAM _ DEV: public key parameters for a Device (Device)

PUB _ ca (dev): public key of certification authority (CA (DEV)) for issuing public key corresponding to equipment manager

Kauth _ DEV _ B: common key for bidirectional single key authentication

Mkauth _ DEV _ a: master key for bidirectional single key authentication

In addition, Kauth _ DEV _ a is stored in a Device Key Area (Device Key Area) shown in the figure: bidirectional single key authentication common key, Mkauth _ DEV _ B: the master key for bidirectional single-key authentication may not be stored in the device structure when the request for the common-key authentication process is not made, or may not be stored when the device does not execute the certificate verification process: a key for MAC verification of a partition registration certificate (PRT).

In addition, for IRL _ DEV: in a Revocation List (Device ID) in which a Device Identifier (ID) of a revoked Device (Device) is registered, or a Revocation List (verification)) in which a public key Certificate identifier (for example, serial number: SN) of the revoked Device (Device) is registered, these Revocation lists may not be stored when there is no revoked Device or when the Revocation List can be obtained from another source.

Fig. 19 shows a data structure of a Partition Definition Block (Partition Definition Block). The following data is stored in a Partition Definition Block (Partition Definition Block).

PMC (Partition Manager Code: Partition Manager Code): code assigned to a Partition Manager (Partition Manager). Such as a serial number.

PMC Version: version of Partition Manager Code (PMC)

Partition Start Position: partition (Partition) storage start address

Partition Size: size of Partition (Partition)

The above description refers to the device specific information in the storage unit of the device and various data in the intra-device partition information area.

[ A7.2. divisional area ]

Hereinafter, various data of the partition area will be described. The partition area is a management area of the partition manager. As described above, the partition manager, which is the service agent, is set in the memory of the device according to a predetermined program, that is, a rule set in the partition registration certificate (PRT), based on the PRT certificate issued by the partition registration certificate (PRT) issuing apparatus (PRT issue) managed by the device manager. Hereinafter, a data structure of the partition area will be described.

Fig. 20 shows a data structure of the Partition Management information block (Partition Management information block). The following data is stored in the Partition management information Block (Partition management information Block).

Pmc (partition Manager code): the serial number of the Partition (Partition) holder.

PMC Version: version of Partition Manager Code (PMC)

Total Block Number in Partition: total number of blocks within a Partition (Partition)

Free Block Number in Partition: number of free blocks within a Partition (Partition)

File Number: number of files (files) currently logged into partition

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

PUB _ ca (par) Pointer: pointer to block storing public key of certification authority CA (PAR) issuing public key certificate through management register of partition manager

PUB _ ca (par) Size: size of public key of certification authority ca (par)

PRI _ PAR Pointer: pointer to block storing secret key of Partition (Partition)

PRI _ PAR Size: size of secret key of Partition (Partition)

PARAM _ PAR Pointer: pointers to blocks storing public key parameters for partitions (partitions)

PARAM _ PAR Size: size of public key parameter of Partition (Partition)

CERT _ PAR Pointer: pointers to blocks storing public key certificates of partitions (partitions) issued by a certification authority ca (par)

CERT _ PAR Size: size of public key certificate of Partition (Partition) issued by certification authority ca (par)

CRL _ PAR Pointer: pointer to block storing Revocation List (Revocation List) of Partition (Partition)

CRL _ PAR Size: size of Revocation List (Revocation List) of Partition (Partition)

Frtic (frt issue category): file login certificate (FRT) issuer categories

FRTIC Version: version of file login certificate (FRT) issuer category (FRTIC)

Dual _ par (dut issue category): data update certificate (DUT) issuer categories

Dual _ PAR Version: version of data update certificate (DUT) issuer class (DUTIC)

Fig. 22 shows a data structure of a Common Key Partition Key information block (Partition Key DefinitionBlock (Common)). The following data is stored in a Partition Key information Block (Common) of the Common Key system.

Mkauth _ PAR _ a Pointer: pointer to master key for two-way single key authentication (Mkauth _ PAR _ A)

Mkauth _ PAR _ a Size: size of Master Key for two-way Single Key authentication (Mkauth _ PAR _ A)

Kauth _ PAR _ B Pointer: pointer to a bidirectional single-key authentication key (Kauth _ PAR _ B)

Kauth _ PAR _ B Size: size of Key for two-way Single Key authentication (Kauth _ PAR _ B)

Kfrt Pointer: pointer to block of MAC check key (Kfrt) storing file registration certificate (FRT)

Kfrt Size: size of MAC verification key (Kfrt) for file registration certificate (FRT)

Kdut _ PAR1-4 Pointer: pointer to block storing MAC check key (Kdut) of data update certificate (DUT)

Kdut _ PAR1-4 Size: size of key (Kdut) for MAC verification of data update certificate (DUT)

IRL _ PAR Pointer: a pointer to a block of a Revocation List Device (Revocation List Device ID) storing the ID of the Revocation List of the Partition (Partition).

IRL _ PAR Size: size of Revocation list (ID) of Partition (Partition)

The method of bidirectional single-key authentication, MAC (message authentication Code) verification processing, given in the above data will be described in detail later.

In addition, there are 4 kinds of Kdut _ PAR and used in a pair-wise manner, that is, (Kdut _ PAR1, Kdut _ PAR2), (Kdut _ PAR3, and Kdut _ PAR 4). For example, Kdut _ PAR1, 3 is used to generate the MAC and Kdut _ PAR2, 4 is used for encryption.

Fig. 23 shows a data structure of and partitions a Key Area (Partition Key Area). The following data is stored in a Partition Key Area (Partition Key Area). In addition, version information is also stored in each storage Key of the Partition Key Area (Partition Key Area). When the key is updated, the version information is also updated.

IRL _ PAR: a Revocation List (Device ID) in which Identifiers (IDs) of a partition access Revocation Device (Device) and Revocation apparatuses (a certificate user such as a reader/writer and a PC as a Device access apparatus, and a certificate issuing apparatus) are registered

CRL _ PAR: revocation List (Certificate) in which public key Certificate identifiers (e.g., serial number: SN) of partition access Revocation devices (devices) and Revocation apparatuses (Certificate users such as readers and PCs as Device access apparatuses, and Certificate issuing apparatuses) are registered

Kd ut _ PAR 1: key for MAC verification of data update certificate (DUT)

Kd ut _ PAR 2: encryption key for data update

Kd ut _ PAR 3: key for MAC verification of data update certificate (DUT)

Kd ut _ PAR 4: encryption key for data update

Kfrt: key for MAC verification of file registration certificate (FRT)

CERT _ PAR: certificate authority CA (PAR) issued public key certificate of Partition (Partition)

PRI _ PAR: secret key for partitions (partitions)

PARAM _ PAR: public key parameter for Partition (Partition)

PUB _ ca (par): public key of certification authority ca (par)

Mkauth _ PAR _ a: master key for bidirectional single key authentication

Kauth _ PAR _ B: common key for bidirectional single key authentication

FIG. 24 shows a data structure of a File Definition Block (FDB). The following data is stored in a File Definition Block (FDB).

File ID: file identifier

File Start Position: file start address

File Size: size of File

Sptic (spt issue category): service license credential (SPT) issuer categories

SPTIC Version: version of service license credential (SPT) issuer class (SPTIC)

File Structure Type Code: code of File structure type (File structure type)

Acceptable Authentication Type: indicating an allowable authentication scheme. The access pattern defined for each File Structure Type (File Structure Type) is made to correspond to each bit (in this example, 16 at most) of this field. The details of which are described below.

Acceptable Verification Type: indicating an allowable inspection mode. The access pattern defined for each File Structure Type (File Structure Type) is made to correspond to each bit (in this example, 16 at most) of this field. The details of which are described below.

Kspt: MAC verification key (Kspt) for service license certificates (SPT)

The above-mentioned allowable Authentication Type is set so that the access pattern defined for each File Structure Type (File Structure Type) corresponds to each bit (in this example, 16 bits at most) of the field, and for example, when a certain access pattern is executed, if 1 bit corresponding to the pattern appears, the public key Authentication is completed, and if the Authentication is not completed, the access pattern is not executed. Therefore, when a command of high importance (for example, a receipt process) is executed, it is specified that public key authentication is necessary, and security can be ensured. Although the same control can be performed even when a certificate is used, since an Acceptable authentication type (Acceptable authentication type) is stored in the device as a part of the File Definition Block (FDB) unlike the certificate, the information cannot be changed after the File is generated. Therefore, when it is desired to provide a strict restriction that absolutely does not allow the change of the allowable authentication method, it is possible to provide a minimum security guarantee by using the information.

The allowable Verification Type is set so that the access pattern defined for each File Structure Type (File Structure Type) corresponds to each bit (in this example, 16 bits at most) of the field, and for example, when a certain access pattern is executed, if 1 is present in the bit corresponding to the pattern, the certificate Verification by the public key method is not completed, and the access pattern is not executed. In the structure of this example, since each field is 2 bytes each, it can correspond to only 16 access modes at most, but can correspond to more commands if the length of the field is increased as necessary.

In the configuration of the present embodiment, the allowable authentication Type (Acceptable authentication Type) and the allowable verification Type (Acceptable verification Type) are set to require authentication or verification by the public key method when the set value is "1", but since these 2 fields are configured in units of 2 bits, it is also possible to perform finer setting, for example, the allowable public key method when the value is "11", the allowable common key method when the value is "01", and the public key method and the common key method when the value is "00" and "10".

The File Structure Type (File Structure Type) in the data is a code indicating the Structure of a File generated in a 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. 25, and codes 0001 to 0007 are assigned to the structures.

Random (Random): the data having the structure of this file is a file that can be read and written randomly.

Pure (style): the data having the file structure is money amount information data, and is a data file capable of performing money amount value change processing such as subtraction (Sub) and addition (Add).

Cyclic (cycle): the data having the file structure is a file structure in which a Cyclic (Cyclic) data can be written.

Log (record): the data having the file structure is a recording data file and a recording information file related to each data processing information.

Key (Key): the data having the structure of this file represents a key information file.

Composite file: are files having a composite structure of the various file structures described above (e.g., Purse and Log). To the compound file, different codes are assigned according to their combination patterns (in the figure, 0006: compound file 1, 0007: compound file 2)

In the above, the data stored in the storage unit of the device is described. Specific processing using these data will be described later.

[ A8. data Format of each certificate ]

As described above, in order to perform the partition setting Registration processing for the device, a partition Registration certificate (PRT) transmitted from a valid certificate issuing apparatus (packet Issuer) is necessary, and in order to perform the setting Registration processing for the File in the partition set in the device, a File Registration certificate (FRT) issued from a valid certificate issuing apparatus (packet Issuer) is necessary, and in order to access each File, a Service permission certificate (SRT) issued from a valid certificate issuing apparatus (packet Issuer) is necessary. As briefly described in the data description section of the storage unit of the device, a data update certificate (DUT) is necessary to update the device storage data.

Each certificate is composed of a data string in which an access rule to a device is described in the form of binary data. The certificate is sent to the device by a certificate user, e.g. a reader/writer as a device access means. The device that receives the certificate performs verification processing on the validity of the certificate, and when the validity verification is successful, performs various processing (e.g., partition generation, file generation, data access) according to the rules recorded in the certificate. The data format of each certificate will be described below.

(A8.1. partition Login certificate (PRT))

A Partition Registration certificate (PRT) is an access control certificate used when performing Partition setting Registration processing on a device. By using a PRT issued by a certificate issuing apparatus (packet issue) managed by a legitimate apparatus manager by a certificate user (for example, a reader/writer as an apparatus access apparatus) managed by a partition manager, and accessing an apparatus according to the procedure recorded in the PRT, a partition can be set within the restriction recorded in the PRT.

The data format of the Partition login certificate (PRT) is shown in FIG. 26. Within the Partition login certificate (PRT), data to be described later is stored.

Ticket Type: category of certificate (Ticket).

Format Version: format version of certificate (Ticket)

Ticket issue: identifier of device manager (═ DMC)

Serial Number: serial number of certificate (Ticket)

Size of Ticket: certificate (Ticket) size

Authentication Flag (Authentication Flag): flag indicating whether mutual authentication with Device (Device) is required or not in use process of certificate (Ticket)

Membership of Ticket User (Group: Group): membership groups of credential (Ticket) users

Authentication Type (Authentication method): mutual authentication method (public key authentication, common key authentication, or both) of Device (Device)

Identifier of packet User: identification data (class or identifier) of the user of a certificate of authenticity (Ticket)

When the field is data combined with the [ Authentication Type ] and the [ Authentication Type ] is public key Authentication, an identification Name (DN), a Category (Category), or a Serial Number (SN) is stored, and when the field is common key Authentication, an Authentication ID is stored. No storage is required when authentication is not required.

PMC Version: version of Partition Manager Code (PMC)

Operation Type; designation of partition Generation or deletion (Generation)/Delete))

Partition Size: size of Partition (Partition)

Integrity Check Type: type of validity check value of certificate (Ticket) (Public key mode (Public)/Common key mode (Common))

Integrity Check Value: validity check value of certificate (Ticket) (public key system: Signature (Signature), common key system: MAC)

When a certificate (Ticket) issued by a partition registration certificate issuing apparatus (PRT issue) is issued to a certificate user, a public key certificate (CERT _ PRTI) of the partition registration certificate issuing apparatus (PRT issue) is also issued together, as in the public key system. The Attribute (Attribute) of the public key certificate (CERT _ PRTI) of the PRT issuing apparatus coincides with the identifier (PRTIC) of the PRT issuing apparatus (PRT issue).

An Authentication method to be executed as mutual Authentication using a certificate is recorded in an Authentication Type in which a mutual Authentication method (public key Authentication, common key Authentication, or both Authentication methods (Any)) of a Device (Device) is recorded. Specifically, information specifying which authentication of the device authentication and the partition authentication is performed or both of them are performed, or information specifying which authentication method of the public key method and the common key method is performed or which authentication is possible is recorded, and details thereof will be described later.

In the [ Integrity Check Value ] field in which a validity Check Value (public key system: Signature (Signature), common key system: MAC) of a certificate (packet) is recorded, if the field is the public key system, a Signature is generated and stored from a secret key of a partition entry certificate issuing apparatus (PRTIssuer) (see fig. 12). When the device manager itself also doubles as a partition login certificate issuing apparatus (PRT issue), a signature is generated with the device manager's secret key. When the signature verification process (see fig. 13) is performed, the public key of the corresponding ca (dev) is used. Therefore, when or before receiving a certificate, a device that performs certificate verification needs to acquire a public key (public key certificate) of a partition login certificate issuing apparatus (PRT Issuer) (e.g., a device manager).

After the public key certificate (CERT _ PRTI) of the partition login certificate issuing apparatus (PRT issue) is verified, the signature of the icv (integrity Check value) may be verified using the public key of the partition login certificate issuing apparatus (PRT issue) taken from the public key certificate (CERT _ PRTI).

(A8.2. File registration certificate (FRT))

A File Registration Ticket (FRT) is an access control Ticket used when setting and registering a File in a partition set in a device. By using an FRT issued by a certificate issuing apparatus (Ticket issue) under the management of a legitimate partition manager by a certificate user (for example, a reader/writer as an apparatus access apparatus) and accessing an apparatus according to the steps recorded in the FRT, a file can be set within the restrictions recorded in the FRT.

The data format of the File Registration certificate (FRT) is shown in FIG. 27. In a File Registration Ticket (FRT), data to be described later is stored.

Ticket Type: category of certificate (Ticket).

Format Version: format version of certificate (Ticket)

Ticket issue: identifier of partition manager (═ PMC)

Serial Number: serial number of certificate (Ticket)

Size of Ticket: certificate (Ticket) size

Authentication Flag (Authentication Flag): flag indicating whether mutual authentication with Device (Device) is required or not in use process of certificate (Ticket)

Membership of Ticket User (Group): membership groups of credential (Ticket) users

Authentication Type (Authentication method): mutual authentication method (public key authentication, common key authentication, or both) of Device (Device)

Identifier of packet User: identification data (class or identifier) of the user of a certificate of authenticity (Ticket)

When the field is data combined with the [ Authentication Type ] and the [ Authentication Type ] is public key Authentication, an identification Name (DN), a Category (Category), or a serial number (CN) is stored, and when the field is common key Authentication, an Authentication ID is stored. No storage is required when authentication is not required.

SPTIC: code of service license issuing apparatus

SPTIC Ver: version of code (SPTIC) of service license issuing apparatus

File ID: identifier (ID) of File (File) generated in partition

Operation Type; designation of File Generation or deletion (Generation)/Delete))

File Size: size of File

File Structure: file Structure (Structure) of generated File (File)

Acceptable Authentication Type: a bit string representing a mode (any of a public key mode, and a common key mode) of mutual authentication required for executing an access mode to a file defined in the certificate

Acceptable Verification Type: bit string representing the verification mode (any of public key mode, and common key mode) of the service license certificate (SPT) required to execute the access mode to the file defined in the certificate

Kspt _ Bncrypted: data Kfrt (Kspt) obtained by encrypting the MAC check key Kspt of the service license certificate (SPT) described in the File Definition Block (File Definition Block) with the MAC check key Kfrt of the partitioned File registration certificate

Integrity Check Type: type of validity check value of certificate (Ticket) (Public key mode (Public)/Common key mode (Common))

Integrity Check Value: validity check value of certificate (Ticket) (public key system: Signature (Signature), common key system: MAC)

When a certificate (Ticket) issued by a file registration certificate issuing apparatus (FRT issue) is issued to a certificate user, a public key certificate (CERT _ FRTI) of the file registration certificate issuing apparatus (FRT issue) is also issued together, as in the public key system. The Attribute (Attribute) of the public key certificate (CERT _ FRTI) of the FRT-issuing apparatus matches the identifier (FRTIC) of the file registration certificate (FRT) issuing apparatus (FRT issue).

An Authentication method to be executed as mutual Authentication using a certificate is recorded in an Authentication Type in which a mutual Authentication method (public key Authentication, common key Authentication, or both Authentication methods (Any)) of a Device (Device) is recorded. Specifically, information specifying which authentication of the device authentication and the partition authentication is performed or both of them are performed, or information specifying which authentication method of the public key method and the common key method is performed or which authentication is possible is recorded, and details thereof will be described later.

In the [ Integrity Check Value ] field in which a validity Check Value (public key system: Signature (Signature), common key system: MAC) of a certificate (packet) is recorded, if the field is the public key system, a Signature is generated and stored from a secret key of a file registration certificate issuing apparatus (FRTIssuer) (see fig. 12). When the partition manager itself also doubles as a file login certificate issuing device (FRT issue), a signature is generated with the partition manager's secret key. When the signature verification process (see fig. 13) is performed, the public key of the certificate issuing apparatus is registered with the file. Therefore, the device that performs certificate verification must acquire a public key (public key certificate) of a file registration certificate issuing apparatus (FRT Issuer) (e.g., partition manager) when or before receiving the certificate.

After the public key certificate (CERT _ FRTI) of the file registration certificate issuing apparatus (FRT issue) is checked, the signature of the icv (integrity Check value) may be checked using the public key of the file registration certificate issuing apparatus (FRT issue) taken from the public key certificate (CERT _ FRTI). These processes will be described later with flowcharts.

(A8.3. service license certificate (SPT))

The Service Permission Ticket (SPT) is an access control Ticket used when data reading, data writing, increase/decrease of money data, and the like are performed while accessing each data in a partition set in the device. Data processing can be performed within the limits recorded in the SPT by a certification user (for example, a reader/writer as a device access device) using the SPT issued by a certificate issuing device (Ticket issue) under the management of a legitimate partition manager and accessing the device according to the steps recorded in the SPT.

The Service Permission Ticket (SPT) has a format allowing access only to a unique file among files set in a partition and a format allowing access to a plurality of files, and each format will be described below.

Fig. 28 shows a data format of a Service Permission certificate (SPT) in a form in which access is permitted only to a unique file among files set in a partition. Within the Service Permission Ticket (SPT), data to be described later is stored.

Ticket Type: category of certificate (Ticket).

Format Version: format version of certificate (Ticket)

Ticket issue: identifier of partition manager (═ PMC)

Serial Number: serial number of certificate (Ticket)

Size of Ticket: certificate (Ticket) size

Authentication Flag (Authentication Flag): flag indicating whether mutual authentication with Device (Device) is required or not in use process of certificate (Ticket)

Membership of Ticket User (Group): grouping of certificate (Ticket) users

Authentication Type (Authentication method): mutual authentication method (public key authentication, common key authentication, or both) of Device (Device)

Identifier of packet User: identification data (class or identifier) of the user of a certificate of authenticity (Ticket)

When the field is data combined with the [ Authentication Type ] and the [ Authentication Type ] is public key Authentication, an identification Name (DN), a Category (Category), or a serial number (CN) is stored, and when the field is common key Authentication, an Authentication ID is stored. No storage is required when authentication is not required.

File ID: identifier (ID) of access File (File) in partition

FileAccess Mode: access mode (Access mode) for files (File) that are allowed to be accessed

Integrity Check Type: type of validity check value of certificate (Ticket) (Public key mode (Public)/Common key mode (Common))

Integrity Check Value: validity check value of certificate (Ticket) (public key system: Signature (Signature), common key system: MAC)

When a certificate (Ticket) issued by a service license certificate (SPT) issuing apparatus (SPT issue) is issued to a certificate user, a public key certificate (CERT _ SPTI) of the service license certificate (SPT) issuing apparatus (SPT issue) is also issued together in the public key system. The Attribute (Attribute) of the public key certificate (CERT _ SPTI) of the SPT issuing apparatus (SPT Issuer) matches the identifier (SPTIC) of the SPT issuing apparatus (SPT Issuer).

In a configuration in which the partition manager also serves as (SPT) issuing device (SPT issue), the code of the service license (SPT) issuing device (SPT issue) may be set as the Partition Manager Code (PMC).

An Authentication method to be executed as mutual Authentication using a certificate is recorded in an Authentication Type in which a mutual Authentication method (public key Authentication, common key Authentication, or both Authentication methods (Any)) of a Device (Device) is recorded. Specifically, information specifying which authentication of the device authentication and the partition authentication is performed or both of them are performed, or information specifying which authentication method of the public key method and the common key method is performed or which authentication is possible is recorded, and details thereof will be described later.

In the [ Integrity Check Value ] field in which a validity Check Value (public key system: Signature (Signature), common key system: MAC) of a certificate (Ticket) is recorded, if the field is the public key system, a Signature is generated and stored from a secret key of a service license issuing apparatus (SPTIssuer) (see fig. 12). When the partition manager itself doubles as a service license issuing device (SRT Issuer), a signature is generated with the secret key of the partition manager. When the signature verification process (see fig. 13) is performed, the public key of the service license certificate (SPT) issuing apparatus (SPT issue) is used. Therefore, the apparatus that performs the certificate verification must acquire the public key (public key certificate) of the service license certificate (SPT) issuing device (SPT Issuer) (e.g., partition manager) when or before receiving the certificate.

After the public key certificate (CERT _ SPTI) of the service license certificate (SPT issue) Issuer (SPT issue) is checked, the signature of the icv (integrity Check value) may be checked using the public key of the service license certificate (SPT) Issuer (SPT issue) taken from the public key certificate (CERT _ SPTI). These processes will be described later with flowcharts.

Hereinafter, in the above description of the certificate format, the following description will be given in File access mode with reference to fig. 29: the Mode and Access Mode recorded in the Access Mode (Access Mode) of the File (File) to which Access is permitted,

data generated in a file format includes various formats such as user identification data, money amount data, encryption key data, record data, and compound file data, and thus access processing corresponding to each data, that is, data reading, writing, deleting, adding and subtracting, encrypting, and decrypting, needs to be performed on the access data.

In the File Access Mode of the service license credential (SPT), which Access Mode is permitted to be performed in the above-described various Access modes is defined. Fig. 29 shows a list of access modes. The access mode shown in fig. 29 is only an example, and other access modes corresponding to data stored in the device may be set.

For [ File ID: the File indicated by the Identifier (ID) ] of the access File (File) in the partition can execute the processing defined in the File access Mode [ FileAccess Mode ]. If the file access mode set in the service license ticket (SPT) is Read (Read), the reading of the data in the file can be performed. If the file access mode set in the service license certificate (SPT) is Write (Write), data Write to the file can be performed.

The access mode is limited in the settable mode by the File Structure (see fig. 25). For example, if the file structure is pull, it is money amount data, and thus, access modes such as add (add), subtract (sub), and the like can be set. Fig. 30 shows an example of the file structure, settable access modes, and commands issued from a reader/writer as a device access apparatus to a device.

Fig. 30 shows examples of settable access modes and commands when the file structure is Random and when the file structure is a compound file.

For example, when the file structure is Random, and when the access mode is Read, the only commands that the device can tolerate are Read. Also, when the file structure is Random, and when the access mode is encrypted Read, the only commands that the device can tolerate are encrypted Read EncRead.

In addition, when the file structure is a compound file containing pull and Log, and when the access pattern is collection, the device may allow only a Deposit [ Deposit ]. Also, when the file structure is a compound file containing both Purse and Log, and when the access mode is of the pay type, the device may allow commands of extract [ Withdraw ], Receipt generation [ Make Replace ], Receipt readout [ Read Replace ].

The Deposit Command (Deposit Command) is defined as an allowable Command (see fig. 30) corresponding to the receiving class in the File Access Mode (see fig. 29), and [ receiving class ] is set in the File Access Mode (File Access Mode) of the Access permission certificate, and an Access permission certificate (SPT) in which a compound File constituting electronic money is specified by a File id (File id) is generated, and then transmitted from the File Access device to the device, and the Deposit amount data is transmitted together with the Deposit Command (Deposit Command), whereby, for example, a sequential process of adding X days to the File [ pull ] in the compound File and writing a process record in the File [ Log ] in the compound File can be executed. These processes will be described in detail later.

In addition to the configuration shown in fig. 30, various combinations of access modes and commands may be used, and the configuration may be set according to the actual device usage pattern.

The device stores definition data of allowable commands for each file stored in the storage unit in the form of a table shown in fig. 30, and executes a command only when the command input from the access device is a command defined in the definition table. As described above, the definition data of the allowable commands for a plurality of files includes the sequential command made up of a plurality of commands that can be executed for a plurality of files included in the compound file.

By setting a specific File to be processed in the File id (File id) column of the service license (SPT) and setting a predetermined Access Mode in the File Access Mode (File Access Mode) of the service license (SPT), File Access using the service license (SPT) can be controlled. The specific processing will be described later with reference to a flowchart.

Next, fig. 31 shows a data format of a Service Permission certificate (SPT) in a format allowing access to a plurality of files among the files set in the partition. Within the Service Permission Ticket (SPT), data to be described later is stored.

Ticket Type: category of certificate (Ticket).

Format Version: format version of certificate (Ticket)

Ticket issue: identifier of partition manager (═ PMC)

Serial Number: serial number of certificate (Ticket)

Size of Ticket: certificate (Ticket) size

Authentication Flag (Authentication Flag): flag indicating whether mutual authentication with Device (Device) is required or not in use process of certificate (Ticket)

Membership of Ticket User (Group): membership groups of credential (Ticket) users

Authentication Type (Authentication method): mutual authentication method (public key authentication, common key authentication, or both) of Device (Device)

Identifier of packet User: identification data (class or identifier) of the user of a certificate of authenticity (Ticket)

When the field is data combined with the [ Authentication Type ] and the [ Authentication Type ] is public key Authentication, an identification Name (DN) and a Category (Category) are stored, and when the field is common key Authentication, an Authentication ID is stored. No storage is required when authentication is not required.

File ID: identifier (ID) of access File (File) in partition

File Access Mode: access mode (Access mode) for files (File) that are allowed to be accessed

Group of Target File (grouping of Target File): grouping (Group) of files (File) to be allowed access

Target File ID: identifier (ID) of File (File) allowed to be accessed

Read/Write Permission: allowable processing mode (Read, Write) for File (Target File) to which access is allowed

Integrity Check Type: type of validity check value of certificate (Ticket) (Public key mode (Public)/Common key mode (Common))

Integrity Check Value: validity check value of certificate (Ticket) (public key system: Signature (Signature), common key system: MAC)

As described above, by defining a Group of Target files: the grouping (Group) of files (files) that are allowed to be accessed is recorded in a certificate, i.e. access to a plurality of files within a partition that is allowed by a unique service license certificate (SPT) can be made.

When the certificate (Ticket) issued by the service license certificate (SPT) issuing apparatus (SPT issue) is issued to the certificate user, the public key certificate (CERT _ SPTI) of the service license certificate (SPT) issuing apparatus (SPT issue) is also issued together in the public key system. The Attribute (Attribute) of the public key certificate (CERT _ SPTI) of the SPT issuing apparatus coincides with the identifier (SPTIC) of the service license certificate (SPT) issuing apparatus (SPT issue).

An Authentication method to be executed as mutual Authentication using a certificate is recorded in an Authentication Type in which a mutual Authentication method (public key Authentication, common key Authentication, or both Authentication methods (Any)) of a Device (Device) is recorded. Specifically, information specifying which authentication of the device authentication and the partition authentication is performed or both of them are performed, or information specifying which authentication method of the public key method and the common key method is performed or which authentication is possible is recorded, and details thereof will be described later.

After the public key certificate (CERT _ SPTI) of the service license certificate (SPT issue) Issuer (SPT issue) is checked, the signature of the icv (integrity Check value) may be checked using the public key of the service license certificate (SPT) Issuer (SPT issue) taken from the public key certificate (CERT _ SPTI). These processes will be described later with flowcharts.

(A8.4. data update certificate (DUT))

A data Update certificate (DUT: Date Update Ticket) is an access control certificate used when performing Update processing of data on various data stored in a device. Data processing can be performed within the limits recorded in the DUT by using the DUT issued by a legitimate data update certificate (DUT) issuing device (Ticket issue) by a certificate user (e.g., a reader as a device access device) and accessing the device according to the steps recorded in the DUT.

In addition, there are a certificate DUT (dev) for performing Update processing of data items managed by the device manager and a certificate DUT (par) for performing Update processing of data items managed by the partition manager. Certificate: a dut (dev) issuing device managed by the device manager, and a certificate: DUT (PAR) issuing device managed by partition manager

In FIG. 32, data formats of 2 data Update certificates (DUT: Date Update Ticket) DUT (DEV) and DUT (PAR) are shown. Within the data update certificate (DUT: Date update Ticket), data to be described later is stored.

Ticket Type: the category of certificate (Ticket) DUT (DEV)/DUT (PAR).

Format Version: format version of certificate (Ticket)

Ticket issue: an identifier of a device/partition manager. DMC if the Type (Ticket Type) of the certificate (Ticket) is DUT (DEV), or the Type (Ticket Type) of the certificate (Ticket) is DUT (PAR), or the Type (Ticket Type) of the certificate (Ticket) is PMC

Serial Number: serial number of certificate (Ticket)

Size of Ticket: certificate (Ticket) size

Membership of Ticket User (Group): membership groups of credential (Ticket) users

Identifier of packet User: identification data (class or identifier) of the user of a certificate of authenticity (Ticket)

When the field is data combined with the [ Authentication Type ] and the [ Authentication Type ] is public key Authentication, an identification Name (DN) and a Category (Category) are stored, and when the field is common key Authentication, an Authentication ID is stored. No storage is required when authentication is not required.

Authentication Type (Authentication method): mutual authentication method (public key authentication, common key authentication, or both) of Device (Device)

Encrypted Flag (Encrypted Flag): whether to encrypt (Encrypted/non-Encrypted) updated data

Old Data Code: code of original data being updated (Code)

Data Version Rule: version condition when updating data

Data Version Condi ton: version value at data update

Size of New Data: size of new data updated

New Data: updated new data (sometimes encrypted)

New Data Version: updating versions of data

Integrity Check Type: type of validity check value of certificate (Ticket) (Public key mode (Public)/Common key mode (Common))

Integrity Check Value: validity check value of certificate (Ticket) (public key system: Signature (Signature), common key system: MAC)

When Data Update is performed using a Data Update certificate (DUT: Date Update Ticket), the Data Update certificate is updated according to [ Data Version Rule: version condition when data update is performed ] and [ DataVersion Conditon: version value when data update is performed ] a combination of these two fields represents a condition.

There are 3 types of Version conditions [ Data Version Rule ] for updating Data, that is, Any, Exact, and Older.

Any indicates that data update can be performed regardless of Version (Version) conditions.

Exact indicates that Data update is possible when the Version value is the same as the value specified in the following Data Version Conditon.

Older indicates that Data update can only be done when New Data Version is New. Further, when the Version condition [ Data Version Rule ] is Any or Older, [ Data Version Conditon ] is not used or is ignored.

An Authentication method to be executed as mutual Authentication using a certificate is recorded in an Authentication Type in which a mutual Authentication method (public key Authentication, common key Authentication, or both Authentication methods (Any)) of a Device (Device) is recorded. Specifically, information specifying which authentication of the device authentication and the partition authentication is performed or both of them are performed, or information specifying which authentication method of the public key method and the common key method is performed or which authentication is possible is recorded, and details thereof will be described later.

In a configuration in which the device manager also serves as a data update certificate Dut (dev) issuing apparatus (dutissue), the code (certificate User) of the data update certificate Dut (dev) issuing apparatus (dutissue) may be set as the Device Manager Code (DMC). In a configuration in which the partition manager also serves as a data update certificate Dut (par) issuing device (dutissue), the code of the data update certificate Dut (par) issuing device (dutissue) may be set as Partition Manager Code (PMC).

An Authentication method to be executed as mutual Authentication using a certificate is recorded in an Authentication Type in which a mutual Authentication method (public key Authentication, common key Authentication, or both Authentication methods (Any)) of a Device (Device) is recorded. Specifically, information specifying which authentication of the device authentication and the partition authentication is performed or both of them are performed, or information specifying which authentication method of the public key method and the common key method is performed or which authentication is possible is recorded, and details thereof will be described later.

In the [ Integrity Check Value ] field in which a validity Check Value (public key system: Signature (Signature), common key system: MAC) of a certificate (packet) is recorded, if the field is the public key system, a Signature is generated and stored from a secret key of a data update certificate issuing apparatus (DUTIssuer) (see fig. 12). When the device manager itself doubles as a data update certificate issuing apparatus (DUT issue), a signature is generated with the secret key of the device manager. And when the partition manager itself doubles as a data update certificate issuing device (DUT issue), a signature is generated with the secret key of the partition manager. In this case, when signature verification processing (see fig. 13) is performed, the public key of the device manager or partition manager is used. Therefore, the device that performs certificate verification must acquire a public key (public key certificate) of a data update certificate issuing apparatus (DUT issue) (e.g., a device manager or a partition manager) when or before receiving the certificate.

After the public key certificate (CERT _ DUT) of the data update certificate issuing apparatus (DUT issue) is checked, the signature of the icv (integrity Check value) may be checked using the public key of the data update certificate (DUT issue) taken from the public key certificate (CERT _ DUT).

Fig. 33 shows an example of data updated using a data Update certificate (DUT: Date Update packet).

As shown in fig. 33, the update target data includes a device manager code, a device manager code version, a partition manager code version, each certificate issuing apparatus code, a MAC generation key and version of each certificate, a revocation list, and the like. Each item of data of the Update objects is updated by using a data Update certificate (DUT) according to a rule recorded in the DUT. The specific procedure of the update process will be described later with reference to a flowchart. The device manager code version, the partition manager code version, and other version information are updated together when updating the data to which each version is added. These version information are stored in a data Update certificate (DUT).

[ B. detailed description of device assignment to user, various settings for device, and device usage processing ]

Hereinafter, the details of the processing performed until the device having the partitioned storage area is used and the device use processing will be described with reference to the flowchart and other drawings. The procedure of the description is as follows.

B1. Procedure from initial login to use of device

B2. Initial login process for device manufacturing entity

B3. Management processing of device manager

B3.1. Device login process for device manager

B3.2. Public key certificate issuing process under device manager management

B4. Management processing of partition manager

B4.1. Partition setting registration/deletion processing using partition registration certificate (PRT) under partition manager management

B4.2. Public key certificate issuing process under partition manager management

B4.3. File creation and deletion process using file registration certificate (FRT)

B5. Service (file access) processing using service license certificates (SPTs)

B6. Device data update processing using data update certificates (DUTs)

[ B1. procedure from initial registration to use of the device ]

A device having an EEPROM (flash memory) is manufactured by a device manufacturing entity (manufacturer), and writing of initial data is performed by a device manager. And then provided (e.g., sold, leased) for use by the user. In order for a user to receive services using a device from various service agents, it is necessary for a partition manager to set a partition in a storage unit of the device and a file storing data for providing the services in the set partition.

When various processes are performed on the device, such as partition setting using a partition registration certificate (PRT), file setting using a file registration certificate (FRT), and data access using a service license certificate (SPT), various processing programs are executed between the device and a certificate user (for example, a reader/writer as a device access apparatus) that performs the processes on the device. Examples of the authentication include mutual authentication processing of devices and apparatuses for confirming both of them are legitimate, signature generation and verification processing for ensuring and confirming the legitimacy of transmitted data, and data encryption/decryption processing. In the configuration of the present invention, a configuration is proposed in which a public key certificate is used when the above-described processing is performed. Therefore, before receiving a service using a device, a process of issuing a public key certificate to the device and a process of storing the device should be executed.

For example, a mutual authentication process using a public key certificate is performed between a device and a certificate user (for example, a reader/writer as a device access apparatus) performing a process on the device, and various processes such as partition setting using a partition registration certificate (PRT), file setting using a file registration certificate (FRT), and data access using a service license certificate (SPT) are performed on condition that the legitimacy of both of them is confirmed. Further, an electronic signature is attached to the mutually transmitted data and verification is performed as necessary. Encryption and decryption processing of the transmitted data may also be performed as necessary.

Fig. 34 is a diagram schematically showing a flow from manufacturing of the device to use thereof. Although the above-described processes will be described in detail below with reference to flowcharts, the stages shown in fig. 34 will be briefly described in order to understand the processes as a whole.

1. First, a device is manufactured by a device manufacturing entity (manufacturer). When manufacturing the devices, device codes, which are Identification Data (IDs) of the respective devices, are given to the respective devices. In the manufacturing stage, various kinds of manufacturing information (manufacturing information Block (refer to fig. 14)) such as a device code, a manufacturing code, and the like are written into the device and stored in the memory of the device.

2. Next, before the Device manager provides the user with the Device, information such as Device management information (see fig. 15) such as the ID of the Device manager and a public Key (PUB CA (DEV)) of the certification authority, and a Device Key (see fig. 18) are stored in the memory.

3. The device in which the management information of the device manager is written is provided to the user.

4. Next, the user executes a process of acquiring the public key certificate of the corresponding device, and stores the acquired device-corresponding public key certificate (CERT DEV) in the device key area of the device (see fig. 18).

5. A service agent (partition manager) that sets a partition in a storage unit of a device and provides a service requests the device manager to set the partition, and receives a partition registration certificate (PRT) together with an allowable response. Meanwhile, a public key of a certification authority (PUB CA (PAR)) used is specified in a communication process with the device.

6. The device performs communication with a certificate user (for example, a reader/writer as a device access apparatus) managed by the partition manager, performs partition login processing using a partition login certificate (PRT), and stores a public key (PUB CA (PAR)) of the certification authority in the partition key area (see fig. 23).

7. The device having set the partition transmits a partition-associated public key certificate issue request to the partition manager, and stores the acquired partition-associated public key certificate (CERT PAR) in the partition key area (see fig. 23).

The partition setting and other processes described above in 5 to 7 are executed by each partition manager that wants to set a partition and provide a service, and a plurality of partitions are registered in the device.

8. Next, the partition manager executes a setting registration process of a file corresponding to, for example, a service, using a file registration certificate (FRT) in a partition set in the device.

9.10. By registering a file in the set partition, various services defined by data in the file, such as electronic money and promissory notes, can be executed. The service license certificate (SPT) is used for data reading, data writing, and the like in a file. That is, only when a service license certificate (SPT) issued by a legitimate certificate issuing apparatus is used, data reading, data writing, and the like are performed in accordance with the rule recorded in the SPT.

Note that, although not shown in the drawings, the update process of the update target data (for example, a device manager code version, a partition manager code version, each certificate issuing apparatus code, a MAC generation key and version of each certificate, a revocation list, and the like) in the storage data of the data update certificate execution apparatus may be performed using the data update certificate as necessary. Further, the device manager code version, the partition manager code version, and other version information are updated together when data attached to each version is updated. These version information are stored in a data Update certificate (DUT).

Each process will be described in detail below with reference to flowcharts and other diagrams.

[ B2. initial registration processing of device manufacturing entity ]

First, the initial registration process of the device manufacturing entity will be described with reference to fig. 35. The left side of fig. 35 shows the process of the registration device of the device manufacturing entity (manufacturer), and the right side shows the process of the device (see fig. 5). The registration device of the device manufacturing entity (manager) is a dedicated reader/writer as a device access device (see fig. 10) that can perform data reading and writing processing on the device.

First, in step S101, the login device transmits a command to read out a write Flag (writeable Flag) of a manufacturing Information Block (MIB: manufacturing Information Block (see fig. 14)) to the device. When the device receives the command (S121), it transmits a write (Writable) flag in a Manufacturing Information Block (MIB) of the storage unit of the device to the registration device (S122).

The registration device that has received the write Flag (writeable) in the Manufacturing Information Block (MIB) (S102) determines whether the write Flag (writeable Flag) is set to Writable (0xffff) (S103). When the write Flag (writeable Flag) is not set to Writable (0xffff), the following process of writing the Manufacturing Information Block (MIB) is not executed, and the process ends as an error.

When the write Flag (Writable Flag) is set to Writable (0xffff), a manufacturing Information Block (MIB: manufacturing Information Block (refer to fig. 14)) of the device is generated (S104) and MIB data is transmitted to the device together with a MIB write command (S105).

The apparatus which receives the MIB write command and the MIB data (S123) checks the MIB write Flag (Writable Flag) (S124), and when the write Flag (Writable Flag) is not set to Writable (0xffff), does not perform the following write processing of the Manufacturing Information Block (MIB) but ends as an error. When the write Flag (writeable Flag) is set to Writable (0xffff), the received MIB data is written into the MIB area (S125).

After the MIB data writing process is completed, a writing 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) sets the write Flag (writeable Flag) of the manufacturing Information Block (MIB: management Information Block) to non-Writable (0x0000) (S128), and transmits the write completion notification to the registration device (S129).

The login device that has received the write completion notification (S108) transmits a command to read the write Flag (Writable Flag) of the manufacturing Information Block (MIB: manufacturing Information Block (see fig. 14)) to the device (S109). When the device receives the command (S130), it transmits a write Flag (writeable Flag) in a Manufacturing Information Block (MIB) in the storage unit of the device to the registration device (S131).

The registration device that received the write Flag (writeable Flag) in the Manufacturing Information Block (MIB) (S110) determines whether the write Flag (writeable Flag) is set to be unwritable (0x0000) (S111). When the write Flag (writeable Flag) is not set to non-Writable (0x0000), it indicates that the normal MIB data write processing has not ended, and the processing ends as an error. When the write Flag (writeable Flag) is set to writeable (0x0000), normal MIB data write processing ends.

[ B3. management processing of device manager ]

The management processing of the device manager is explained below. Here, a process performed before the device starts to be used will be described. The processes performed before the Device starts to use the Device manager include a Device login process in which a Device Management Information Block (DMIB) for a storage unit of the Device, a public Key system Device Key Definition Block (PUB), a Common Key system Device Key Definition Block (DKDB) for a storage unit of the Device, and a data Key write process for a Device Key Area (Device Area) are performed, and a process of transmitting a Device-associated public Key Certificate (CERTDEV) to the Device. These processes are described in detail below.

[ B3.1. device Login processing of device manager ]

The initial registration processing when the device manager performs storage processing of device management information and other information for a device will be described with reference to fig. 36 and the subsequent flowchart. In fig. 36 and the following flowcharts, the left side shows the processing of the initial login means of the Device Manager (DM), and the right side shows the processing of the device (see fig. 5). The initial registration device of the Device Manager (DM) is a device (for example, a reader/writer or a PC as a device access device) capable of performing read/write processing on a device, and has a configuration equivalent to the reader/writer as the device access device of fig. 10.

First, in step S201, a Read command of the device identifier IDm is output to the device. The device receives the command and sends the device identifier IDm to the login means (S212).

The login Device having received the Device identifier IDm (S202) transmits a command to read out the write Flag (WTitable Flag) of the Device Management information block (DMIB: Device Management information block (see fig. 15)) to the Device in step S203. When the device receives the command (S213), the device transmits a write (Writable) flag in a Device Management Information Block (DMIB) of a storage unit of the device to the login apparatus (S214).

The registration device that has received the write Flag (Writable) in the Device Management Information Block (DMIB) (S204) determines whether or not the write Flag (Writable Flag) is set to Writable (0xffff) (S205). When the write Flag (writeable Flag) is not set to Writable (0xffff), the write processing of the following Device Management Information Block (DMIB) is not executed, and the process ends as an error.

When 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 assigned to the device manager in advance by a code management organization (see fig. 1 to 3).

The device that receives the DMC Write command (S215) checks the DMIB Write Flag (Writable Flag) (S216), and when the Write Flag (Writable Flag) is not set to Writable (0xffff), does not perform the Write processing of the following Device Management Information Block (DMIB) but ends as an error. When the write Flag (writeable Flag) is set to Writable (0xffff), the received Device Manager Code (DMC) and DMC version are written into the DMIB area (S217).

After the write processing of the Device Manager Code (DMC) and the DMC version is completed, a write completion notification is transmitted to the login device (S218). The registration Device, having received the write completion notification (S207), then transmits a Device Total Block number (Device Total Block number) write command to the Device (S208)

The Device that receives the Device Total Block Number (Device Total Block Number) write command (S219) checks the DMIB write Flag (Writable Flag) (S220), and when the write Flag (Writable Flag) is not set to Writable (0xffff), the write process of the following Device Management Information Block (DMIB) is not executed, and ends as an error. When the write Flag (Writable Flag) is set to Writable (0xffff), the received Total Number of Device blocks (Device Total Block Number) is written in the DMIB area (S221), and the Device writes TB4 in the Device Free Block Number information area (Free Block Number in Device) of the DMIB area (S222). TB means the Device Total Block Number (Device Total Block Number). And 4 blocks of TB4 indicate a manufacturing information Block (MIB: manufacturing information Block), a Device Management information Block (DMIB: Device Management information Block), a public-Key system Device Key definition Block (dbd: Device Key definition Block (PUB)), and a Common-Key system Device Key definition Block (DKDB: Device Key definition Block (Common)).

Next, the device writes 0 in the partition number area (PartitionNumber) of the Device Management Information Block (DMIB) (S223). This is because the partition has not been set in the device at that time. Further, 0 is written to the Pointer (Pointer of Free Area) of the DMIB (S224). And transmits a write processing completion notification to the login apparatus (S225).

The login device that has received the write process completion notification from the device (S209) then determines whether or not the common key is used for device authentication (S231). As for the authentication process, either of a public key system and a common key system may be structurally performed, and an authentication system required by the device may be set by the device manager, which will be described in detail later. If the device is a device that executes the common key method, the device manager sets information (for example, a master key for authentication key generation) necessary for common key authentication in the device, and if the device is a device that does not execute the common key method, the device manager does not store the information in the device. And the device manager sets data which can execute either a common key mode or a public key mode or both modes in the device according to the authentication mode adopted by the device.

As shown in fig. 37, steps S232 to S233, S241 to S245 are executed when the common key is employed in the device authentication, and are omitted when the common key is not employed in the device authentication.

When the common key is used for device authentication, the registration apparatus registers, in step S232, Mkauth _ DEV _ a: master key for bidirectional single key authentication, Kauth _ DEV _ B: bidirectional single key authentication key, IRL _ DEV: a Revocation List (Device ID) in which a Device Identifier (ID) of a Revocation Device (Device) is registered and version information thereof are transmitted to the Device as a common key authentication data write command.

In step S241, the device receives the write command, and in step S242, after confirming that the DMIB write Flag (Writable Flag) is Writable, writes the received data in the device key area (see fig. 18) (S243). Next, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S244), and a write completion notification is transmitted to the login device (S245).

The login device that has received the write completion notification (S233) determines in step S234 whether or not the public key is used for device authentication. As shown in fig. 37, steps S235 to S239, S246 to S254 are executed when the public key is employed in the device authentication, and are omitted when the public key is not employed in the device authentication.

When the public key is used for device authentication, the registration apparatus registers, in step S235, the public key including PUB _ ca (dev): the transmitting device manager corresponds to the public key of the certification authority (ca (DEV)) of the public key, PARAM _ DEV: public key parameter of Device (Device), CRL _ DEV: a Revocation List (Revocation List) in which a public key Certificate identifier (e.g., serial number: SN) of a Revocation Device (Device) is registered, and version information thereof are transmitted to the Device as a public key authentication data write command.

In step S246, the device receives the write command, and in step S247, after confirming that the DMIB write Flag (Writable Flag) is Writable, writes the received data in the device key area (see fig. 18) (S248). Next, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S249), and a write completion notification is transmitted to the login device (S250).

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

The device that has received the key pair generation command (S251) generates a key pair of the public key (PUB DEV) and the secret key (PRI DEV) by the encryption processing unit (see fig. 5) in the device, and writes the generated key in the device key area (see fig. 18) (S252). The public key (PUB DEV) is temporarily stored in a CERT DEV area of a device key area, and is replaced with a public key Certificate (CERT) when a public key certificate storing the public key (PUB DEV) is received. Next, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S253), and the generated and stored public key is transmitted to the login apparatus (S254).

The registration means receives the public key (PUB DEV) from the device and stores the public key (PUB DEV) in a database (db (DEV)) in the device manager together with the device identifier IDm previously received from the device (see fig. 7).

Next, the registration device of the device manager determines whether or not the common key is used in the verification process of the partition registration certificate (PRT) (S261). For the certificate verification, any one of a common key system such as MAC value verification and a public key system using signature generation by a secret key and signature verification by a public key described above with reference to fig. 12 and 13 may be used, and details thereof will be described later. The device manager can set the checking processing mode adopted by the device. And the device manager sets data which can execute either a common key or a public key or both modes according to the PRT certificate verification mode adopted by the device.

If the device is a device that executes the shared key scheme, the device manager sets information necessary for PRT verification of the shared key scheme (for example, PRT verification shared key) in the device, and if the device is a device that does not execute the shared key scheme, the device manager does not store the information in the device.

As shown in fig. 38, steps S262 to S263 and S271 to S275 are executed when the common key scheme is adopted in the PRT verification, and these steps are omitted when the common key is not adopted in the PRT verification.

When the common key scheme is adopted in the PRT verification, the device is logged in step S262, and Kprt: the MAC verification key and version information of the partition registration certificate (PRT) are transmitted to the device as a PRT verification common key write command.

In step S271, the device receives the write command, and in step S272, after confirming that the DMIB write Flag (Writable Flag) is Writable, writes the received data in the device key area (see fig. 18) (S273). Next, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S274), and a write completion notification is transmitted to the login apparatus (S275).

The login device that has received the write completion notification (S262) determines in step S264 whether or not the public key is used for the PRT verification. As shown in fig. 38, steps S265 to S266, S276 to S282 are performed when the public key is employed in the PRT verification, and are omitted when the public key is not employed in the PRT verification.

When the public key is used for the PRT verification, the registration device registers, in step S265, the public key of prtic (PRT issue category): partition login certificate (PRT) issuer category, PUB _ ca (dev): public key of a certificate authority (ca (DEV)) for issuing a device manager corresponding to the public key, PARAM _ DEV: public key parameter of Device (Device), CRL _ DEV: a Revocation List (Revocation List) in which a public key Certificate identifier (e.g., serial number: SN) of a Revocation Device (Device) is registered, and version information thereof are transmitted to the Device as a PRT check data write command.

In step S276, the device receives the write command, and after confirming that the DMIB write Flag (Writable Flag) is Writable in step S277, in step S278, the device writes, in the received data, a value of prtic (prt issue category): the partition registration certificate (PRT) issuer category is written in a public key system Device key definition Block (DKDB: Device key definition Block (PUB)) (refer to fig. 16), and version information is written in a version area of the Block.

Next, the apparatus, in step S279, determines whether or not PUB _ ca (dev): if the public key data of the certification authority (ca (DEV)) that issued the device manager and corresponds to the public key has not been written yet, PUB _ ca (DEV) and CRL _ DEV are written into the device key area in step S289 (see fig. 18). Then, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S281), and a writing end notification is transmitted to the login apparatus (S282).

The registration device that has received the write completion notification (S266) then determines whether or not the device supports the common key data update in step S291. Among the data stored in the device, some data can be updated with a data Update certificate (DUT) (refer to fig. 32). The data to be updated is explained above with reference to fig. 33. In the Update process using the data Update certificate (DUT), either a common key system or a public key system may be used, and the device manager sets, in the device, data that can be executed in either one or both of the systems, depending on the device.

If the device is a device that performs data update of the common key scheme, the device manager sets information (for example, a key for MAC verification of a data update certificate (DUT)) necessary for data update processing of the common key scheme in the device, and if the device is a device that does not perform common key authentication, the device manager does not store the information in the device.

As shown in fig. 39, steps S292 to S293 and S301 to S305 are executed when the common key scheme is adopted in the data update process using the data update certificate (DUT), and are omitted when the common key scheme is not adopted in the data update.

When the common key is used for data update, the registration device registers, in step S292, the following data of Kdut _ DEV 1: key for MAC verification of data update certificate (DUT), Kdut _ DEV 2: encryption key for data update, Kdut _ DEV 3: key for MAC verification of data update certificate (DUT), Kdut _ DEV 4: the encryption key for data Update and its version information are transmitted to the device as a data Update certificate (DUT) verify common key write command.

In step S301, the device receives the write command, confirms that the DMIB write Flag (Writable Flag) is Writable in step S302, and writes the received data in the device key area (see fig. 18) (S303). Next, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S304), and a write completion notification is transmitted to the login device (S305).

The login device that has received the write completion notification (S293) determines in step S294 whether or not the device supports data update processing using a data update certificate (DUT) using a public key scheme. As shown in fig. 39, steps S295 to S296 and S306 to S310 are executed when the public key scheme is supported, and are omitted when the public key scheme is not supported.

When the public key scheme is supported, the registration device registers, in step S295, the result _ dev (dut issue category): the data Update certificate (DUT: Date Update Ticket) issuer category and its version information are sent to the device as a data Update certificate (DUT: Date Update Ticket) issuer code write command.

In step S306, the Device receives the write command, and after confirming that the DMIB write Flag (Writable Flag) is Writable in step S307, in step S308, writes the received data into a public key system Device key definition Block (DKDB: Device key definition Block (PUB)) (S308). Next, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S309), and a write completion notification is transmitted to the login apparatus (S310).

The login means that received the write completion notification (S296) then transmits a Device Manager (DM) initial login completion command to the device in step S321. The device that has received the command (S331) determines in step S332 whether data in which at least one of the public key system and the shared key system can be executed is set for each of the mutual authentication, the verification of the partition registration certificate (PRT), and the verification of the data update certificate (DUT). If the data is not sufficient, no processing can be executed, and therefore, the initial registration of the device manager is determined to be an error and the processing is terminated.

When it is determined in step S332 that data in at least one of the public key system and the shared key system can be executed is set in all of the mutual authentication, the verification of the partition registration certificate (PRT), and the data update certificate (DUT), the Device sets a write (Writable) flag of a Device Management Information Block (DMIB) to be non-Writable (0x0000) in step S333, and transmits a write completion notification to the registration Device (S334).

The login Device that has received the write completion notification (S322) transmits a command to read out the write Flag (Writable Flag) of the Device Management Information Block (DMIB: Device Management Information Block (see fig. 15)) to the Device (S323). When the device receives the command (S335), the device transmits a write Flag (writeable Flag) in the Device Management Information Block (DMIB) of the storage unit of the device to the login apparatus (S336).

The login device that receives the write Flag (writeable Flag) in the Device Management Information Block (DMIB) (S324) determines whether or not the write Flag (writeable Flag) is set to writeable (0x 0000). When the write Flag (writeable Flag) is not set to Writable (0x0000), it indicates that the normal DMIB data write processing has not ended, and the processing ends as an error. When the write Flag (writeable Flag) is set to writeable (0x0000), the normal DMIB data write processing ends.

Fig. 41 shows an example of the data structure stored in the memory of the device in a state in which the initial registration of the registration means of the device manufacturing entity (manufacturer) (the processing flow of fig. 35) and the initial registration processing (the processing flows of fig. 36 to 40) of the Device Manager (DM) are completed. Fig. 41 shows a manufacturing Information Block (manufacturing Information Block), a Device management Information Block (Device management Information Block), a public Key system Device Key Definition Block (PUB)), a Common Key system Device Key Definition Block (Common), and a Device Key Area (Device Key Area) explained with fig. 6 and 14 to 18. At this point, no partitions have been formed in the memory.

In the manufacturing Information Block (manufacturing Information Block), as described with reference to fig. 14, a device code and other Information are written as device-specific Information. The Information written in the manufacturing Information Block (manufacturing Information Block), a part of the written Information, or operation data obtained from the written Information corresponds to the device identifier (IDm).

In addition, Kauth _ DEV _ B is stored in a Device Key Area (Device Key Area) shown in the figure: bidirectional single key authentication common key, Mkauth _ DEV _ a: the master key for bidirectional single-key authentication may not be stored in the device structure when the request for the common-key authentication process is not made, or may not be stored when the device does not execute the certificate verification process: a key for MAC verification of a partition registration certificate (PRT).

In addition, for IRL _ DEV: in a Revocation List (Device ID) in which a Device Identifier (ID) of a revoked Device (Device) is registered, or a Revocation List (verification)) in which a public key Certificate identifier (for example, serial number: SN) of the revoked Device (Device) is registered, these Revocation lists may not be stored when there is no revoked Device or when the Revocation List can be obtained from another source.

[ B3.2. public Key certificate issuing processing under device manager management ]

Hereinafter, the process of issuing a device-associated public key certificate by the device manager will be described with reference to fig. 42 and the flowchart that follows. A device-associated public key certificate (CERT DEV) applicable to authentication of the entire device and processing on a device-by-device basis, and a partition-associated public key certificate (CERT PAR) applicable to authentication and other verification processing when a specific partition within the device is processed may be stored in the device. The partition corresponds to a public key certificate (CERT PAR), and can be set and stored for each partition set in the device.

The Device-associated public Key certificate (CERT DEV) is stored in a Device Key Area (see fig. 18) which is a storage Area managed by the Device manager, and the Partition-associated public Key certificate (CERT PAR) is stored in a Partition Key Area (see fig. 23) which is a storage Area managed by the Partition manager.

The device is issued by a program for providing the public key certificate issued by a certificate authority (CA for DM) (see fig. 2 and 3) to the device through a registration authority managed by a device manager in accordance with the public key certificate (CERT DEV), and the management of the issued public key certificate (CERT DEV) is executed by the registration authority managed by the device manager (database 222 (see fig. 7)).

The partition is associated with a public key certificate (CERT PAR), issued by a program for providing the public key certificate issued by a certificate authority (CA for PM) (fig. 2 and 3) to the device by a registration authority managed by the partition manager, and the registration authority managed by the partition manager manages the issued public key certificate (CERT PAR) (a database 332 (see fig. 9)).

The process of issuing a device-associated public key certificate (CERT DEV) to a device by a registration authority managed by a device manager will be described with reference to fig. 42 and 43. Fig. 44 shows the relationship among the issuer (DM), the Certification Authority (CA), and the user equipment, which is shown only by the Registration Authority (RA) managed by the device manager. As shown in fig. 44, the control device 221 includes an encryption processing device. 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)).

In fig. 42 and 43, the left side is a CERT (public key certificate) issuing apparatus of a registration authority managed by a device manager, specifically, a process of the control apparatus 221 in the configuration diagram of the device manager shown in fig. 7, and the right side is a process of the device.

First, in step S351, the CERT issuing apparatus acquires user information of a device to which the device-associated public key certificate (CERT DEV) is issued, allows (determines) the issuing of the certificate, and secures a communication line with the device to which the certificate is issued. The user information of the device to which the device-associated public key certificate (CERT DEV) is issued may be obtained from data generated at the time of initial registration of the device, for example. In addition, the user name, address, telephone number, Email address, and the like may be acquired by other methods and other routes. Further, the communication line with the device may be set and then acquired from the device. The communication line, whether wired or wireless, may be any communication line that can transmit and receive data.

Then, in step S352, the CERT issuing apparatus transmits an authentication data generation command including a random number to the device. The device that has received the authentication data generation command (step S361) executes a generation process of a digital signature (S) (refer to fig. 12) by applying the device secret key (PRI DEV) to the combined data of the received random number R and the device identifier (IDm) (S362). The device transmits the identification data (IDm) and the signature (S) of the device to the CERT issuing apparatus.

The CERT issuing apparatus, which has received the identification data (IDm) and the signature (S) from the device (step S353), acquires the stored device public key (PUB DEV) from the database Db (DEV)222 using the received device identification data (IDm) as a search key. Further, verification processing (see fig. 13) of the signature (S) is executed using the acquired device public key (PUB DEV) (S355). When the verification is unsuccessful, it is determined that the transmission data from the device is illegal data, and the process is ended.

When the verification is successful, the certification authority (CA for DM)610 is requested to perform the process of issuing the device-specific public key certificate (CERT DEV) (S357). The device manager receives the device-associated public key Certificate (CERTDEV) issued by the certificate authority (CA for DM)610 (S358) and transmits it to the device (S359).

A device that receives the device-corresponding public key Certificate (CERTDEV) from the device manager (login authority) performs signature verification of the received device-corresponding public key Certificate (CERTDEV) using the public key (PUB CA (DEV)) of the certification authority that has been stored in advance in the device key area. That is, a signature executed with the secret key of the certification authority in the public key certificate (see fig. 11), and the signature is verified (S366).

When the signature verification fails, the public key certificate is determined not to be legitimate, and an error notification is transmitted to the CERT issuing apparatus (S385).

When the signature verification is successful, the device public key (PUB DEV) stored in the device-associated public key certificate (CERT DEV) is compared with the device public key (PUB DEV) stored in the device itself (S382), and when they do not match, an error notification is transmitted, and when they match, the received device-associated public key certificate (CERT DEV) is stored in the device key area (see fig. 18) (S383). Before the device-associated public key certificate (CERT DEV) is transmitted, the device public key (PUB DEV) generated by the device itself is stored in the area, and the device-associated public key certificate (CERT DEV) is rewritten and stored at the time when the device-associated public key certificate (CERT DEV) is issued.

When the storage of the device correspondence public key certificate (CERT DEV) is finished, a storage process end notification is transmitted to the CERT issuing apparatus (S384). The CERT issuing apparatus receives the storage process end notification (S371), confirms the success of the storage (S372), and ends the process. If the success of the storage cannot be confirmed, the process ends as an error.

Fig. 45 is a diagram for explaining data transmission and reception processing among the entities of the device manager 200, the device 100, and the Certification Authority (CA)610 in the process of issuing the device-associated public key certificate (CERT DEV).

The processing is performed in the order of Nos. 1 to 14 in FIG. 45. The process of process No.1, in which the device manager 200 acquires the device identifier (IDm) and the device public key (PUB DEV) from the device 100, and the process of process No.2, in which the device identifier (IDm) is registered, are processes executed in the initial registration by the device manager.

The device-based public key certificate (CERT DEV) issuing procedure starts with process No.3, namely, 3. the device manager acquires customer information from the device, 4. registration of the customer information (which is not required when registration is completed), 5. the device identifier (IDm) is acquired from the device, 6. the public key (PUB DEV) is acquired by performing database search based on the acquired device identifier (IDm), and 7. the authentication process between the device and the device manager. Although these processes are omitted in the processes of fig. 42 and 43, in fig. 42 and 43, the signature verification is performed when the device identifier (IDm) is acquired from the device, and the transmission data of the communication partner is confirmed, so that the authentication is omitted. Either or both of the signature verification in fig. 42, 43 and the authentication in fig. 45 are preferably performed. Further, as for the authentication processing, detailed description will be made in the following item of management processing of b.4. partition manager

8. The device-associated public key certificate transmitted from the device manager to the certification authority is transmitted, 9, the device-associated public key certificate (CERT DEV) is generated, 10, the generated public key certificate is registered in the certification authority, 11, the public key certificate is distributed from the Certification Authority (CA)610 to the device manager 200, 12, the database of the device manager is updated (registered public key certificate transmission information), 13, the device-associated public key certificate (CERT DEV) is transmitted from the device manager to the device, 14, the device-associated public key certificate (CERT DEV) is stored in the device, and the storage method is written in the device key area.

Through the above processing, the device acquires the device-associated public key Certificate (CERTDEV) and stores it in the storage unit. Fig. 46 shows a data structure of each block in the memory after storing the device-specific public key certificate (CERT DEV) in the device key storage area of the memory. Fig. 46 shows the manufacturing Information Block (manufacturing Information Block), the Device management Information Block (Device management Information Block), the public Key system Device Key Definition Block (PUB)), the Common Key system Device Key Definition Block (Common), and the Device Key Area (Device Key Area) described above with reference to fig. 6 and 14 to 18. At this point, no partitions have been formed in the memory.

Within the Device Key Area (Device Key Area) shown in fig. 46, the storage Device corresponds to a public Key certificate (CERT DEV). Before the device-associated public key Certificate (CERTDEV) is issued, a public key (PUB DEV) generated by the device is stored in the area, and when the device-associated public key certificate (CERT DEV) is received, the device-associated public key certificate (CERT DEV) performs a rewriting process. When there is a pointer, data size, management data, it is necessary to perform update processing by the above-described rewrite processing.

[ B4. management processing of partition manager ]

The following describes management processing of the partition manager. Here, a process performed before starting to use the apparatus will be described. The processes performed by the partition manager before the device starts to use include a process of setting a partition in a storage unit of the device and a process of issuing a partition-associated public key certificate (CERT PAR) to the device. These processes are described in detail below. The process of setting the Partition includes mutual authentication processing (device authentication or Partition authentication) between the device and the Partition manager, and validity check processing of a Partition registration certificate (PRT). The deletion processing of the partition can be basically executed in accordance with the same program as the partition creation, and therefore, the description will be given together.

[ B4.1. partition setting registration/deletion processing using partition registration certificate (PRT) under partition manager management ]

First, a partition setting registration/deletion process using a partition registration certificate (PRT) (see fig. 26) will be described. This is explained with reference to fig. 47 and other flowcharts that follow. As described above, the Partition setting process includes mutual authentication processing (device authentication or Partition authentication) between the device and the Partition manager, and validity check processing of the Partition registration certificate (PRT), and these processes are also described.

A flowchart of the partition setting registration/deletion process 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). The partition creation/deletion device of the partition manager is a device (for example, a reader/writer or a PC as a device access device) capable of performing data reading/writing processing on a device, and corresponds to the reader/writer as the device access device in fig. 10. First, the outline of the partition creation and deletion process will be described with reference to fig. 47, and then various processes included in the present process will be described in detail in order with reference to fig. 48 and the subsequent flowcharts.

First, in steps S401 and S410 of fig. 47, a mutual authentication process between the partition creating and deleting apparatus and the device is performed. Between 2 devices that perform data transmission and reception, it is confirmed whether the other party is a legitimate data correspondent or not, and then necessary data transfer can be performed. The mutual authentication process is a process of mutually confirming whether the partner is a legitimate data communicator. A configuration in which generation of a session key is performed when mutual authentication processing is performed, and data transmission is performed after encryption processing is performed using the generated session key as a common key is performed is a preferable data transfer method.

In the mutual authentication processing in the system of the present invention, any one of device authentication or partition authentication is performed. In addition, the two types of authentication are subjected to either common key authentication or public key authentication. These processes will be described later.

The processing to be executed as the mutual authentication processing is determined by 2 items of data in the partition registration certificate (PRT) used (see fig. 26), that is, the following data

Authentication Flag (Authentication Flag): a flag indicating whether or not mutual authentication with the Device is required in the process of using the certificate (packet),

Authentication Type (Authentication method): the mutual authentication method (public key authentication, common key authentication, or both authentication methods (Any)) of the Device (Device).

If the authentication process fails (No in steps S402 and S411), the following process is not executed, and the process ends as an error, because the device or equipment that cannot be verified as being legitimate is indicated.

When the authentication process is successful, the Partition creating/deleting device issues a Partition Registration certificate (PRT) to the device. The partition registration certificate (PRT) is a certificate that is issued by a partition registration certificate (PRT) issuing apparatus (PRT issue) managed by the partition manager in response to a request from the partition manager.

When the partition login certificate (PRT) is issued to the certificate user, the public key certificate (CERT _ PRTI) of the partition login certificate issuing apparatus (PRT issue) is also issued together, as in the public key system. The Attribute (Attribute) of the public key certificate (CERT _ PRTI) of the PRT issuing apparatus coincides with the identifier (PRTIC) of the PRT issuing apparatus (PRT User).

The device that received the partition registration certificate (PRT) (S412) executes the process of verifying the validity and user of the certificate (PRT) (S413). The certificate validity verification process is executed by either MAC verification based on a common key system or signature verification process based on a public key system. The user check is a process of checking the legitimacy of the device (certificate user) that issued the certificate, and is executed after the mutual authentication is successful, as a process of checking whether or not the identification data of the authentication partner matches the certificate user identifier (see fig. 26) recorded in the certificate. These processes will be described in detail later.

When the validity of the received certificate (PRT) and the validity of the user cannot be confirmed as a result of the user verification processing (no in S414), the device notifies the partition creation/deletion apparatus of an error to the partition registration certificate (PRT) (S418). When the validity of the certificate and the user can be confirmed (yes in S414), the partition creation or deletion process of the storage unit in the device is executed according to the rule described in the partition registration certificate (PRT). This process will also be described in detail later with additional flowcharts.

When the partition creation or deletion process performed based on the description in the partition registration certificate (PRT) has succeeded (yes in S416), the partition creation/deletion apparatus is notified of the success of PRT reception (S417). On the other hand, if the partition creation or deletion process fails (no in S416), the partition creation or deletion apparatus is notified of a PRT acceptance error (S418).

The partition creating/deleting device receives the PRT reception result (S404), determines the PRT reception result, ends the processing as an error if the PRT reception result is an error (no in S405), and executes the processing of writing partition initial data if the PRT reception result is a success (yes in S405) and the processing is partition creation (S406, S419). The writing process of the partition initial data will be described in detail later with another flowchart. When the processing for writing the partition initial data is finished, and when the PRT reception result is successful (yes in S405) and the processing is the partition deletion, the transmission and reception of the session termination command are executed (S407, S420), the authentication table generated on the device side is discarded (S421), and the processing is finished. The authentication table is a table generated in the mutual authentication processing in steps S401 and S410, and details thereof are as described later.

In the above manner, generation of a new partition or deletion of an already generated partition can be performed within the device using the partition login certificate (PRT). The following describes in detail the mutual authentication processing (S401 and S410), certificate validity and user verification (S413), partition creation and deletion processing (S415), and partition initial data write processing (S406 and S419) included in the present processing.

(mutual authentication processing)

The mutual authentication process executed in steps S401, S410 of fig. 47 will be explained. The mutual authentication process described below may be performed in a device access process using another certificate, that is, a File Registration certificate (FRT), a service permission certificate (SPT), and a data Update certificate (DUT), as necessary.

Fig. 48 shows a flow of the mutual authentication processing. In fig. 48, the left side shows the process of the authentication device of the partition manager, and the right side shows the process of the device (see fig. 5). The authentication device of the partition manager is a device (for example, a reader/writer or a PC as a device access device) capable of performing data reading/writing processing on a device, and has a configuration corresponding to the reader/writer shown in fig. 10.

In step S431 of fig. 48, the authentication apparatus reads out the certificate and determines the authentication method required when using the partition registration certificate (PRT). The authentication mode is not limited to the authentication method described in the certificate, and for example, the device authentication and the partition authentication may be determined according to a method specified by an access device (for example, a reader/writer).

The determined authentication method is assumed to be a (1) to a (n). Various authentication processing modes are set in the partition setting registration or deletion processing using the partition registration certificate (PRT). For example, when a partition is registered, it is necessary to perform device authentication for a device, and when a partition is deleted, it is necessary to perform two types of authentication, i.e., device authentication and partition authentication for deletion. Therefore, it is possible to describe in the partition registration certificate (PRT) that one or both of the authentications are necessary according to the processing. The authentication method required for the PRT use process is described in the partition registration certificate (PRT), and the authentication device reads out the certificate and determines the authentication method required for using the partition registration certificate (PRT), and defines the authentication process sequence as a (i): a (1) to A (n).

In step S432, the first authentication method a (1) is read, and it is determined that the authentication method of a (1) is device authentication or partition authentication (S433), and if it is device authentication, steps (S434, S441) are executed, and if it is partition authentication, steps (S435, S442) are executed. When the authentication result with the device is that the authentication is unsuccessful, the processing is ended as an error. If the authentication is successful, step S437 increments by 1, returns to step S433, and determines the next authentication method. And performs authentication according to the manner. The above-described processing is executed from a (1) to a (n), and when all authentications are successful, the subsequent step is entered.

The device authentication process is described with reference to the flowchart of fig. 49. In fig. 49, the left side shows the processing of the device authentication apparatus of the partition manager, and the right side shows the processing of the device (see fig. 5). The device authentication apparatus of the partition manager is an apparatus (for example, a reader/writer or a PC as a device access apparatus) capable of performing data reading/writing processing on a device, and has a configuration corresponding to the reader/writer of fig. 10.

The device authentication apparatus determines whether or not a public key authentication method using a public key is used in the device authentication process based on the partition login certificate (PRT) in step S451. The device authentication is performed by either a common key system or a public key system, and the certificate describes the specification of the execution system.

When the common key scheme is designated, the process proceeds to step S456 without executing steps S452 to S455 and S461 to S465 in fig. 49. When the public key scheme is designated, the device authentication apparatus transmits a public key authentication start command to the device in step S452. Upon receiving the command (S461), the device checks whether or not the device-associated public key certificate (CERT DEV) is stored, with reference to the public-key-system device key definition block (see fig. 16) in the storage unit of the device (S462). When there is no storage device-compatible public key certificate (CERT DEV), mutual authentication by the public key method is not performed, and the determination process is terminated as an error.

When it is confirmed that the device-associated public key certificate (CERT DEV) is stored, mutual authentication and key sharing processing using a public key certificate issued by a device manager association authority (ca (DEV)) is executed in steps S453 and S463.

Mutual authentication and key sharing processing by the public key method will be described with reference to fig. 50. Fig. 50 shows a mutual authentication procedure using a 160-bit long Elliptic Curve Cipher (ECC) as a public key system. In fig. 50, ECC is used as the public key system, but another public key system may be used. Further, the key size is not necessarily 160 bits. In fig. 50, first, a 64-bit random number Rb is generated by B and transmitted to a. A, which receives the random number Rb, generates a new 64-bit random number Ra and a random number Ak smaller than the feature number p. Then, a point Av where the base point G is multiplied by Ak is determined to be Ak × G, an electronic signature a.sig corresponding to Ra, Rb, and Av (X coordinate and Y coordinate) is generated, and the signature is transmitted to B together with the public key certificate of a. Here, Ra and Rb are 64 bits each, and Av has 160 bits each in X and Y coordinates, so that an electronic signature corresponding to 448 bits in total is generated.

When the public key certificate is used, the user verifies the electronic signature of the public key certificate with the public key of a public key certificate issuing authority (CA) held by the user, and after the verification of the electronic signature is successful, the user takes out the public key from the public key certificate and uses the public key. Therefore, all users who use the public key certificate must maintain the public key of the common public key certificate issuing authority (CA). The method of verifying the electronic signature is already described with reference to fig. 13, and thus a detailed description thereof will be omitted.

If the result of the verification matches, the electronic signature in the public key certificate of A is verified by the public key of the certification authority, and the public key of A is extracted. Then, the electronic signature a.sig is verified with the public key of the extracted a. After the verification of the electronic signature is successful, B authenticates A as being legal.

Next, B generates a random number Bk smaller than the feature number p. Then, a point Bv where the base point G is multiplied by Bk is determined as Bk × G, an electronic signature b.sig corresponding to Ra, Rb, and Bv (X coordinate and Y coordinate) is generated and transmitted to a together with the public key certificate of B.

A receiving B public key certificate, Ra, Rb, Bv and electronic signature B.Sig checks whether Rb sent by B is consistent with that generated by A. If the result of the verification matches, the electronic signature in the public key certificate of B is verified with the public key of the certification authority, and the public key of B is extracted. Then, the electronic signature b.sig is verified with the public key of the retrieved B. After the verification of the electronic signature is successful, A authenticates B as being legal.

When both authentication succeeds, B calculates Bk × Av (although Bk is a random number, Av is a point on the elliptic curve, and therefore, it is necessary to perform scalar product calculation of the point on the elliptic curve), a calculates Ak × Bv, and uses 64 bits of the lower X-coordinate of the point as a session key in subsequent communication (when a common key cipher having a key length of 64 bits is used). Of course, the session key may be generated from the Y coordinate, and may not be the lower 64 bits. In the secure communication after mutual authentication, the transmission data may be encrypted with a session key and may be added with an electronic signature.

When the electronic signature is verified or the received data is authenticated, if the verification is found to be illegal or inconsistent, the mutual authentication is failed and the process is interrupted.

In the mutual authentication process described above, the transmission data is encrypted by the generated session key, and mutual data communication is performed.

Returning to fig. 49, the description of the flowchart is continued. After the mutual authentication and key sharing process described above has succeeded in steps S453 and S463, the device refers to the CRL _ DEV: a Revocation List (verification) in which public key Certificate identifiers (for example, serial numbers SN) of a Revocation Device (Device) and a Revocation apparatus (a reader/writer as a Device access apparatus, a Certificate user such as a PC, or a Certificate issuing apparatus) are registered verifies whether or not a Device authentication apparatus as a communication partner is revoked. If the partition is cancelled, the process is terminated as an error because the partition creation process is not permitted.

If the authentication is not cancelled, in step S465, the session key Kses generated in the mutual authentication and key sharing process, the identification Name (DN) in the public key certificate of the communication partner (the reader/writer, PC, etc. serving as the device access device constituting the device authentication apparatus), the serial number, and the category are stored in the authentication table in association with each other, using the Device Manager Code (DMC) as a key.

On the other hand, the device authentication apparatus also refers to the CRL _ DEV: a Revocation List (Revocation List) in which public key Certificate identifiers (for example, serial numbers: SNs) of a Revocation Device (Device) and a Revocation apparatus (a reader/writer as a Device access apparatus, a Certificate user such as a PC, or a Certificate issuing apparatus) are registered determines whether or not the Device has been revoked. The device authentication apparatus can acquire a revocation list (CRL _ DEV) from a registration authority (RA (PAR)). When the partition is cancelled, the process is terminated as an error because the partition creation process is not permitted.

If the key is not revoked, the session key Kses generated in the mutual authentication and key sharing process, the identification Name (DN) in the public key certificate of the communication partner (device), the serial number, and the category are stored in the authentication table in association with each other in step S455 using the Device Manager Code (DMC) 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 (which may be a PC) serving as an authentication apparatus, i.e., a device access apparatus.

Fig. 51 is an example of an authentication table generated in the device at the time of device authentication and the completion of authentication of the partitions 1 and 2 as partition authentication described later. As one Group (Group), a Device Manager Code (DMC) is recorded when device authentication is performed, a partition login certificate (PRT) is recorded when partition authentication is performed, and data of each Group is stored according to various authentication methods performed. In the case of the public key authentication method, as described above, the session key Kses, the identification Name (DN) in the public key certificate of the communication partner (e.g., the reader/writer of the device access apparatus), the serial number, and the type are stored in the table, and in the case of the common key authentication method, the session key Kses and the identifier (ID RW) of the communication partner (e.g., the reader/writer of the device access apparatus) are stored.

The authentication table is discarded at the time of session termination. The device can check the authentication state of the device and each partition by referring to the information in the authentication table, and can check 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 apparatus. This example is also an example of the authentication table at the time of device authentication and the authentication end time of the partitions 1 and 2 as partition authentication. The basic structure is the same as the authentication table in the device, and as a Group (Group), a Device Manager Code (DMC) is recorded when performing device authentication, a partition login certificate (PRT) is recorded when performing partition authentication, and data of each Group is stored according to various authentication methods executed. In the case of the public key authentication method, as described above, the session key Kses, the identification Name (DN) in the public key certificate of the communication partner (device), the serial number, and the type are stored in the table, and in the case of the common key authentication method, 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 discarded at the time of session termination. The reader/writer as the device access apparatus may determine the authentication state of the device and each partition by referring to the information in the authentication table, and may check the session key to be used.

Returning to fig. 49, the description of the device authentication process is continued. If it is determined in step S451 that the device authentication method is not the public key method, the device authentication apparatus transmits a shared key device authentication command to the device in step S456. Upon receiving the command (S466), the device checks whether or not the master key for bidirectional single-key authentication (Mkauth _ DEV) used for the shared-key authentication is stored, with reference to the shared-key partition key definition block (see fig. 16) in the storage unit of the device (S467). When the master key for bidirectional single-key authentication (Mkauth _ DEV) is not stored, mutual authentication by the common key method cannot be performed, and the determination process is ended as an error.

When it is confirmed that the master key (Mkauth _ DEV) for bidirectional single key authentication is stored, mutual authentication and key sharing processing using the master key is executed in steps S457 and S468.

Mutual authentication and key sharing processing by the common key scheme using the master key will be described with reference to fig. 53. In fig. 53, a and B are entities that perform authentication in a shared key scheme using a master key. A has its own identifier IDa, a common key Ka for bidirectional single-key authentication, and a master key MKb for bidirectional single-key authentication, and B has its own identifier IDb, a common key Kb for bidirectional single-key authentication, and a master key Mka for bidirectional single-key authentication. In the example of fig. 53, a DES algorithm (for example, DES, triple DES) is used as the common key encryption method, but other encryption methods may be used as long as they are common key encryption methods.

First, B generates a 64-bit random number Rb, and transmits Rb and IDb, which is its own ID, to a. Upon receiving Rb and IDb a, a new 64-bit random number Ra is generated, and a bidirectional single-key authentication shared key Kb is obtained by DES encryption processing of IDb using a bidirectional single-key authentication master key MKb. Then, the data is encrypted with the keys Ka, Kb in the order of Ra, Rb, IDa, IDb in the CBC mode of DES, and sent to B together with its own identifier IDa.

B that has received this data first obtains the bidirectional single-key authentication shared key Ka by performing DES encryption processing of IDa with the bidirectional single-key authentication master key MKa. The received data is then decrypted with the keys Ka, Kb. And checking whether Rb and IDb in Ra, Rb, IDa and IDb obtained after decryption are consistent with those sent by B. When this check passes, B authenticates a as legitimate.

Next, B generates a 64-bit random number Kses serving as a session key, encrypts data in the order of Rb, Ra, IDb, IDa, and Kses with keys Ka and Kb in the CBC mode of DES, and transmits the encrypted data to a.

A, which received the data, decrypts the received data with the keys Ka, Kb. And checking whether the Ra, Rb, IDa and IDb obtained after decryption are consistent with those sent by A. When this check passes, a authenticates B is legitimate. After mutually authenticating the partner, the session key Kses is used as a common key in the authenticated secure communication.

When the received data is checked, if it is found that the received data is illegal or inconsistent, the mutual authentication is failed and the processing is terminated.

Fig. 54 is a diagram for explaining the flow of data in common key authentication using a master key added in correspondence with stored data in the system of the present invention. As shown in fig. 54, a reader/writer (R/W) as a Device access apparatus generates a 64-bit random number Rb and transmits Rb and IDrw, which is its own ID, to a Device (Device). The Device (Device) that has received Rb and IDrw generates a new 64-bit random number Ra and obtains a bidirectional single-key authentication shared key Kauth _ DEV _ a by DES encryption of IDrw by a bidirectional single-key authentication master key MKauth _ DEV _ a. Then, the data is encrypted with the key Kauth _ DEV _ A, Kauth _ DEV _ B in the order of Ra, Rb, IDrw in, for example, DES CBC mode as an encryption algorithm, and transmitted to the reader/writer (R/W) as the device access apparatus together with the own identifier IDm.

The reader/writer (R/W) as the device access apparatus that has received the data first obtains the bidirectional single-key authentication shared key Kauth _ DEV _ a by DES encryption processing of IDm by the bidirectional single-key authentication master key Kauth _ DEV _ B. Then, the received data is decrypted with the key Kauth _ DEV _ A, Kauth _ DEV _ B. Whether Rb and IDrw obtained after decryption are consistent with those transmitted by a reader/writer (R/W) serving as a device access apparatus is checked. When the check is passed, a reader/writer (R/W) as a Device access means authenticates the Device (Device) as being legitimate.

Next, the reader/writer (R/W) generates a 64-bit random number Kses serving as a session key, encrypts data with a bidirectional single-key authentication common key Kauth _ DEV _ A, Kauth _ DEV _ B in the order of Rb, Ra, Kses in, for example, DES CBC mode as an encryption algorithm, and transmits the encrypted data to the Device (Device).

The device that receives the data decrypts the received data with the bidirectional single key authentication common key Kauth _ DEV _ A, Kauth _ DEV _ B. And checking whether the Ra, Rb and IDrw obtained after decryption are consistent with those sent by the Device (Device). When the check passes, the Device (Device) authenticates that the reader/writer (R/W) is legitimate. After authentication, the session key Kses is used as a common key in secure communication.

IDm, which is an inherent value of the device, may be an appropriate value according to the storage data of the device manager management area, as described above with reference to the device memory format of fig. 6.

As described above, according to the mutual authentication and key sharing process by the common key method using the master key, since the two keys of the generated individual key of the communication partner and the individual key of the user are set as the common key by the master key execution process of the communication partner, and the mutual authentication by the common key method is performed using the set 2 keys, it is possible to realize the secure authentication system and method compared to the conventional common key authentication method in which the common key is stored in advance in the device or the access apparatus.

Returning to fig. 49, the description of the flowchart is continued. When the mutual authentication and key sharing process described above is successful in steps S457 and S468, the device refers to the IRL _ DEV stored in the device key area (see fig. 18) of the device in step S469: when the revocation list (ID) is registered with the Identifier (ID) of the revocation Device (Device) or the revocation apparatus (the certificate user such as a reader/writer or a PC as a Device access apparatus or a certificate issuing apparatus), it is checked whether or not the Device authentication apparatus as a communication partner is revoked.

If the key is not revoked, in step S470, 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, a PC, or the like serving as a device access apparatus constituting the device authentication apparatus) are stored in the authentication table (see fig. 51) so as to be associated with each other, using the Device Manager Code (DMC) as a key.

On the other hand, the device authentication apparatus, in step S458, also refers to IRL _ DEV: a revocation list (ID) in which Identifiers (ID) of a revocation Device (Device) and revocation apparatuses (a certificate user such as a reader/writer and a PC as a Device access apparatus, and a certificate issuing apparatus) are registered judges whether or not the Device is revoked.

If the key is not revoked, in step S459, the session key Kses generated in the mutual authentication and key sharing process and the identification information (IDm) of the communication partner (device) are stored in the authentication table (see fig. 52) so as to be associated with each other, using the Device Manager Code (DMC) as the key.

The above processing is device authentication processing executed between a device and a reader/writer as a device access apparatus managed by the partition manager.

The partition authentication processing executed in steps S435 and S443 of fig. 48 will be described below with reference to fig. 55 and 56. In the partition setting registration or deletion process using the partition registration certificate, as described above, either or both of the device authentication and the partition authentication are required depending on the process. These settings are described in the partition registration certificate (PRT), and when the partition registration certificate (PRT) contains a description for performing partition authentication, partition authentication is performed.

The following describes steps in the processing flows of fig. 55 and 56. In fig. 55, the left side shows the processing of the partition authentication apparatus of the partition manager, and the right side shows the processing of the device (see fig. 5). The partition authentication device of the partition manager is a device (for example, a reader/writer or a PC as a device access device) capable of performing data read/write processing on a device, and has a configuration equivalent to the reader/writer as the device access device shown in fig. 10.

The partition authentication means outputs a partition a presence check command for performing presence confirmation of the partition a as an authentication target to the device in step S471. The device that has received the command (S481) checks whether or not the partition a exists in the storage unit of the device (S482). Here, as the identifier of the Partition a, for example, a Partition Manager Code (PMC) is used, and the device may determine the presence or absence of a Partition based on the PMC stored in a Partition Definition Block (PDB). After the presence or absence of the partition is determined by the device, the check result is transmitted to the partition authentication apparatus.

The partition authentication device that received the check result (S472) checks the check result (S473), and when receiving the result that the partition does not exist, the authentication is disabled, and the operation ends with an error. When the check result indicates that the partition exists, the partition authentication apparatus determines whether or not the public key authentication method using the public key is used in the partition authentication process based on the partition registration certificate (PRT) in step S474. The partition authentication is performed by either a common key method or a public key method, as in the device authentication described above, and the certificate describes a specification of the execution method.

When the common key scheme is designated, the process proceeds to step S491 without executing steps S475 to S478 and S484 to S488 in fig. 55. When the public key system is designated, the partition authentication apparatus transmits a partition a authentication start command to the device in step S475. Upon receiving the command (S484), the device checks whether or not the public key certificate (CERT PAR) corresponding to the partition a is stored, with reference to the public key partition key definition block (see fig. 21) of the storage unit of the device (S485). When the public key certificate (CERT PAR) is not associated with the partition a, mutual authentication in the public key system is not performed, and the determination process is terminated as an error.

When it is confirmed that the partition a corresponding public key certificate (CERT PAR) is stored, mutual authentication and key sharing processing using a public key certificate issued by a partition manager corresponding certification authority (ca (PAR)) is executed in steps S476 and S486.

The mutual authentication and key sharing process by the public key method is the same as the procedure shown in fig. 50 described above in the device authentication process, and therefore, the description thereof is omitted. However, the public key certificate used for partition authentication is a public key certificate issued by a partition manager compliant certification authority (CA (PAR)), and the public key (PUB CA (PAR)) of the partition manager compliant certification authority (CA (PAR)) is used for signature verification of the public key certificate. The public key (PUB CA (PAR)) is stored in the partition key area (see fig. 23). In the mutual authentication process described above, the transmission data is encrypted by the generated session key, and mutual data communication is performed.

After the mutual authentication and key sharing processing in the order shown in fig. 50 succeeds in steps S476 and S486, the device refers to the CRL _ PAR stored in the partition area (see fig. 23) of the storage unit of the device in step S487: a revocation list (revocation list) (verification) in which public key certificate identifiers (for example, serial numbers: SNs) of a revocation Device (Device) and a revocation apparatus (a reader/writer as a Device access apparatus, a certificate user such as a PC, or a certificate issuing apparatus) are registered is checked to see whether or not a partition authentication apparatus as a communication partner is revoked. When the partition is deleted, the process of creating or deleting the partition is not permitted, and therefore the process is ended as an error.

If the key is not revoked, the session key Kses generated in the mutual authentication and key sharing process, the identification Name (DN) in the public key certificate of the communication partner (the reader/writer, PC, etc. that is the device access device constituting the partition authentication apparatus), the serial number, and the category are stored in the authentication table in association with each other in step S488, using the Partition Manager Code (PMC) as the key.

On the other hand, the partition authentication apparatus also refers to the CRL _ PAR: a Revocation List (verification) in which public key Certificate identifiers (for example, serial numbers SN) of a Revocation Device (Device) and a Revocation apparatus (a reader/writer as a Device access apparatus, a Certificate user such as a PC, and a Certificate issuing apparatus) are registered determines whether or not the Device has been revoked. The device authentication apparatus can acquire a revocation list (CRL _ PAR) from a registration authority (RA (PAR)). When the deletion is cancelled, the generation processing or deletion processing of the partition is not permitted, and therefore the processing ends as an error.

If the key is not revoked, the session key Kses generated in the mutual authentication and key sharing process, the identification Name (DN) in the public key certificate of the communication partner (device), the serial number, and the category are stored in the authentication table in association with each other in step S478 using the Partition Manager Code (PMC) 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 the partition authentication apparatus, that is, the reader/writer (or PC) as the device access apparatus. Fig. 51 and 52 show examples of authentication tables generated in the device and in the reader/writer as the device access apparatus at the time of completion of device authentication and authentication of the partitions 1 and 2 as partition authentication.

When partition authentication is performed, a Partition Manager Code (PMC) is recorded, and each data is stored in accordance with various authentication methods executed. In the case of the public key authentication method, as described above, the session key Kses, the identification Name (DN) in the public key certificate of the communication partner, the serial number, and the type are stored in the table, and in the case of the common key authentication method, the session key Kses and the identifier of the communication partner are stored. The authentication table is discarded at the time of session termination. The device and the reader/writer as the device access apparatus can confirm the authentication state of the device and each partition by referring to the information of the authentication table, and can confirm the session key to be used.

The partition authentication process will be described with reference to the flowcharts of fig. 55 and 56. If the partition authentication apparatus determines in step S474 that the partition authentication method is not the public key method, the partition authentication apparatus transmits a shared key partition a authentication command to the device in step S491. Upon receiving the command (S501), the device checks whether or not the master key for bidirectional single-key authentication (Mkauth _ PAR _ a) used for shared-key authentication is stored, with reference to the shared-key partition key definition block (see fig. 22) in the storage unit of the device (S502). When the master key for bidirectional single key authentication (Mkauth _ PAR _ a) is not stored, mutual authentication by the common key method cannot be performed, and the determination processing is ended as an error.

When it is confirmed that the bidirectional single-key authentication master key (Mkauth _ PAR _ a) is stored, mutual authentication and key sharing processing using the master key is executed in steps S492 and S503. The mutual authentication and key sharing process by the common key method is performed in the same order as described with reference to fig. 53 and 54, and therefore, the description thereof will be omitted. However, the keys used for partition authentication are a common key for two-way single key authentication (Kauth _ PAR _ B) and a master key for two-way single key authentication (Mkauth _ PAR _ a) which are defined by the partition definition block (see fig. 22) and stored in the partition key area (see fig. 23).

When the mutual authentication and key sharing process of the common key scheme succeeds in steps S492 and S503, the device refers to the IRL _ PAR stored in the partition area of the storage unit of the device (see fig. 23) in step S504: a Revocation List (ID) in which Identifiers (IDs) of a Revocation Device (Device) and Revocation apparatuses (a reader/writer as a Device access apparatus, a certificate user such as a PC, and a certificate issuing apparatus) are registered checks whether or not a partition authentication apparatus as a communication partner is revoked.

If the key is not revoked, in step S505, the session key Kses generated in the mutual authentication and key sharing process and identification information (IDrw) of the communication partner (a reader/writer, a PC, or the like serving as a device access apparatus constituting the partition authentication apparatus) are stored in the authentication table (see fig. 51) so as to be associated with each other, using the Partition Manager Code (PMC) as a key.

On the other hand, the partition authentication apparatus also refers to the IRL _ PAR: a partition authentication Device acquires a Revocation List (IRL _ PAR) from a registration means (RA (PAR)), and when the Revocation List (IRL _ PAR) is revoked, does not allow generation processing or deletion processing of a partition, and thus terminates processing as an error.

If the key is not revoked, in step S494, the session key Kses generated in the mutual authentication and key sharing process and the identification information (IDm) of the communication partner (device) are stored in the authentication table (see fig. 52) so as to be associated with each other, using the Partition Manager Code (PMC) as a key.

The above processing is partition authentication processing executed between a device and a reader/writer as a device access apparatus managed by a partition manager. By the mutual authentication, authentication between the device or the partition and the reader/writer as the device access apparatus can be established, and the session key can be shared, whereby communication in which the communication data is encrypted with the session key can be performed.

The device authentication process and the partition authentication process may be performed as needed when the device access process is executed using another certificate, that is, a File Registration certificate (FRT), a Service Permission certificate (SPT), and a data update certificate (DUT). These processes will be described later in a process using each certificate.

(certificate validity and user verification)

Hereinafter, the certificate validity and user verification processing in the device of step S413 in the partition creation and deletion processing flow of fig. 47 will be described in detail with reference to the flowcharts of fig. 57 and 58.

The certificate validity and user verification process described below may be performed in a device access process using another certificate, that is, a File registration certificate (FRT), a Service Permission certificate (SPT), and a data Update certificate (DUT), as necessary. The flowcharts of fig. 57 and 58 constitute a processing flow common to the certificates.

The certificate validity and user verification processing is processing executed by an apparatus (see fig. 5) based on a certificate received from a certificate user (for example, a reader/writer, a PC, or the like as an apparatus access device) that performs communication with the apparatus. After the validity of the certificate and the user, i.e., the user of the certificate user (e.g., a reader/writer or a PC as a device access apparatus), is confirmed in the user verification process, the device permits the process within the limited range described in the certificate.

The certificate validity and user verification processing will be described in detail with reference to the flowcharts of fig. 57 and 58. A device that receives a certificate from a certificate user (e.g., a reader/writer, a PC, etc., which is a device access apparatus), checks the certificate type and determines whether the certificate is a Partition Registration certificate (PRT) in step S511 of fig. 57. The certificate type is recorded in each certificate (see fig. 26, 27, 28, 31, and 32).

If the Partition login certificate is the Partition login certificate (PRT), the steps S512 to S514 are executed, and if the Partition login certificate is not the Partition login certificate (PRT), the step S515 is executed.

When the certificate Type is the Partition registration certificate (PRT), it is determined in step S512 whether or not the setting of Integrity Check Type (the Type of validity Check value of the certificate (Ticket)) (Public key scheme (Public)/Common key scheme (Common)) described in the certificate is Public key scheme (Public) or not.

When the Type of the validity Check value (Integrity Check Type) is Public key mode (Public), the flow proceeds to step S513, and various processes are executed. The process executed in step S513 is a verification process of the public key Certificate (CERT) of the certificate Issuer (Ticket Issuer) using the public key PUB CA (DEV) of the device manager compliant certification authority (CA (DEV)) first.

As described above, when the certificate (Ticket) issued by the partition registration certificate (PRT) Issuer (PRT Issuer) is issued to the certificate user, the public key certificate (CERT _ PRTI) of the partition registration certificate (PRT) Issuer (PRT Issuer) is also transmitted to the device in the public key system. The Attribute (Attribute) of the public key certificate (CERT _ PRTI) of the PRT issuing apparatus coincides with the identifier (PRTIC) of the partition registration certificate (PRT) issuing apparatus (PRT issue).

A signature executed with a secret key of a device manager compliant certificate authority (CA (DEV)) is attached to a public key certificate (see fig. 11), and the signature is verified with a public key (PUB CA (DEV)) of the device manager compliant certificate authority (CA (DEV)). The signature generation and verification are performed, for example, according to the flowcharts shown in fig. 12 and 13 described above. Based on this signature verification, it is determined whether or not the public key Certificate (CERT) of the certificate issuer is a legitimate public key Certificate (CERT) that has not been tampered with.

Further, in step S513, it is determined whether the code as the user class recorded in the selectable area of the public key Certificate (CERT) of the certificate issuing apparatus, the validity of which has been confirmed by the signature check, coincides with the certificate issuing apparatus code (PRTIC: PRT issue code) recorded in the DKDB (Device key definition Block (PUB)) in the Device.

As described in the section of description of the public key certificate in fig. 11, the public key certificate stores the membership code of the certificate issuing apparatus (packet issue) that is the issuing apparatus of each certificate (PRT, FRT, SPT, etc.), and in this case, stores prtic (prtissuer code). When it is confirmed that the Code in the optional area matches the certificate issuing apparatus Code (PRTIC) in the DKDB (Device Key Definition Block (PUB)) recorded in the Device, it can be confirmed that the received certificate (PRT) is a certificate issued by a legitimate certificate issuing apparatus.

Then, the Device refers to a Revocation List (verification) in which public key Certificate identifiers (for example, serial number: SN) of a Revocation Device (Device) and a Revocation apparatus (a reader/writer as a Device access apparatus, a Certificate user such as a PC, and a Certificate issuing apparatus) are registered, and determines whether or not the Certificate issuing apparatus is revoked, in a CRL _ DEV (see fig. 18) stored in a Device key area in a storage unit of the Device.

Next, verification of the validity Check Value (public key system: Signature) of the Integrity Check Value (certificate) which is a Signature recorded in the partition registration certificate (PRT) (see fig. 26) as the received certificate is performed, and it is confirmed that the certificate is not falsified.

As described above, it is confirmed that (1) the public Key Certificate (CERT) of the certificate Issuer (Ticket Issuer) is a legitimate public Key Certificate (CERT) that has not been tampered with, (2) the Code recorded in the optional area of the public Key Certificate (CERT) of the certificate issuing apparatus matches the certificate issuing apparatus Code (PRTIC: PRT Issuer Code) in DKDB (Device Key DefinitionBlock (PUB)) recorded in the Device, (3) the certificate issuing apparatus (Ticket Issuer) has not been revoked, and (4) the certificate has not been tampered with by checking the Signature (Signature) of the received certificate (PRT)). And judging the success of the validity check of the certificate by taking all the items as the conditions for confirmation. If any of the above (1) to (4) is not confirmed, it is determined that the validity of the certificate is not confirmed, and therefore, the process using the Partition registration certificate (PRT) is suspended.

When it is determined in step S512 that the type of Integrity check value of the certificate (Ticket) described in the certificate (Public key system (Public)/Common key system (Common)) is set to the Common key system (Common)), the process proceeds to step S514, and a check of the mac (message Authentication code) is performed. A device that uses a MAC verification key of a partition registration certificate (PRT) stored in a device key area (see fig. 18) of the device: kprt performs MAC verification processing of the certificate.

Fig. 59 shows an example of MAC value generation using the DES encryption processing structure. As shown in the configuration of fig. 59, the target information M is divided into 8 byte units (hereinafter, it is assumed that the divided information is M1, M2.., MN), and first, an exclusive or operation is performed on an Initial Value (hereinafter, abbreviated as IV) and M1 (the result is I1). Then, I1 is input to the DES encryption section, and the MAC verification key: kprt encryption (let output be E1). Next, E1 and M1 are xored, and the output I2 is input to the DES encryption unit and encrypted with the key Kprt (output E2). The above process is repeated until all the information is encrypted. The EN that is finally output is set as a message Authentication code (mac). In addition, as the information, partial data constituting data to be inspected may be used.

Comparing the ICV (integrity Check value) generated by the data transmitting side when generating data for ensuring that the data is not tampered with the ICV generated by the data receiving side according to the received data, if the same ICV is obtained, ensuring that the data is not tampered, and if the ICVs are different, determining that the data is tampered. As described in the description of the partition registration certificate (PRT) format of fig. 26, an ICV generated when data is generated, for example, by the data transmission side to ensure that the ICV is not tampered is stored in an ICV (integrity Check value) field of the PRT. The ICV generated by the device is compared with the ICV stored in the received certificate (PRT), if the ICV and the ICV are consistent, the certificate is judged to have legality, and if the ICV and the ICV are not consistent, the certificate is judged to be falsified, so the process of using the certificate is stopped.

By the above processing, the certificate verification processing in the case where the Integrity Check Type described in the certificate is the common key system can be completed.

Returning to the flowchart of fig. 57, the description continues with the certificate validity and user verification processing. When it is determined in step S511 that the certificate type is not the partition Registration certificate (PRT), in step S515, the certificate type is checked and it is determined whether the certificate is the File Registration certificate (FRT).

When the certificate type is a File Registration certificate (FRT), steps S516 to S518 are executed, and when the certificate type is not a File Registration certificate (FRT), the process proceeds to step S519.

When the certificate Type is a File Registration certificate (FRT), in step S516, it is determined whether or not the setting of the Integrity Check Type (the Type of validity Check value of the certificate (Ticket)) (Public key method (Public)/Common key method (Common)) described in the certificate is Public key method (Public).

When the Type of the validity Check value (Integrity Check Type) is Public key mode (Public), the flow proceeds to step S517, and various processes are executed. The process executed in step S516 is first a verification process of the public key Certificate (CERT) of the certificate Issuer (Ticket Issuer) using the public key PUB CA (PAR) of the partition manager correspondence certification authority (CA (PAR)).

When a certificate (Ticket) issued by a file registration certificate (FRT) issuing apparatus (FRT issue) is transmitted to a certificate user, if the certificate user is a public key system, a public key certificate (CERT _ FRTI) of the file registration certificate (FRT) issuing apparatus (FRT issue) is also transmitted to the device. The Attribute (Attribute) of the public key certificate (CERT _ FRTI) of the FRT issuing apparatus coincides with the identifier (FRTIC) of the partition registration certificate (FRT) issuing apparatus (FRT issue).

A signature performed with a secret key of the partition manager corresponding certification authority (CA (PAR)) is attached to the public key certificate (refer to fig. 11), and the signature is verified with a public key (PUB CA (PAR)) of the partition manager corresponding certification authority (CA (PAR)). The signature generation and verification are performed, for example, according to the flowcharts shown in fig. 12 and 13 described above. Based on this signature verification, it is determined whether or not the public key Certificate (CERT) of the certificate issuer is a legitimate public key Certificate (CERT) that has not been tampered with.

Further, in step S517, it is determined whether the membership Code of the user recorded in the selectable area of the public Key Certificate (CERT) of the certificate issuing apparatus, the validity of which has been confirmed by the signature check, coincides with the certificate issuing apparatus Code (FRTIC: FRT issue Code) recorded in the PKDB (Partition Key DefinitionBlock (PUB)) in the device.

As described in the section of description of the public key certificate in fig. 11, the public key certificate stores the membership code of the certificate issuing apparatus (packet issue) which is the issuing apparatus of each certificate (PRT, FRT, SPT, etc.), and in this case, stores the frtic (frtisuer code). In the case where it is confirmed that the Code in the optional area coincides with the certificate issuing apparatus Code (FRTIC: FRT issue Code) in the PKDB (Partition Key Definition Block (PUB)) recorded in the device, it can be confirmed that the reception certificate (FRT) is a certificate issued by a legitimate certificate issuing apparatus.

Then, the Device refers to a Revocation List (Revocation List) in which a public key Certificate identifier (for example, serial number: SN) of a Revocation Device (Device) and a Revocation apparatus (a reader/writer as a Device access apparatus, a Certificate user such as a PC, or a Certificate issuing apparatus) is registered, and determines whether or not a valid Certificate issuing apparatus has not been revoked, of CRL _ PAR (refer to fig. 23) stored in a partition key area in a storage unit of the Device.

Next, verification of the validity Check Value (public key system: Signature) of the Integrity Check Value (certificate) recorded in the file registration certificate (FRT) (see fig. 27) as the received certificate is performed, and it is confirmed that the certificate has not been tampered with.

As described above, it is confirmed that (1) the public Key Certificate (CERT) of the certificate Issuer (Ticket Issuer) is a legitimate public Key Certificate (CERT) that has not been tampered with, (2) the Code recorded in the optional area of the public Key Certificate (CERT) of the certificate issuing apparatus matches the certificate issuing apparatus Code (FRT: FRT Issuer Code) in the PKDB (Partition Key definitional block (PUB)) recorded in the device, (3) the certificate issuing apparatus (Ticket Issuer) has not been revoked, and (4) the certificate has not been tampered with by checking the Signature (Signature) on the received certificate (FRT)). All the items are confirmed to be successful in verifying the validity of the conditional decision file login certificate (FRT). When any of the above (1) to (4) is not confirmed, it is determined that the validity of the file registration certificate (FRT) is not confirmed, and the process using the file registration certificate (FRT) is terminated.

When it is determined in step S516 that the type of the Integrity check value of the certificate (Ticket) (Public key system (Public)/Common key system (Common)) is set to the Common key system (Common)), the process proceeds to step S518, and a check of the mac (message Authentication code) is performed. A device that uses a MAC verification key of a file registration certificate (FRT) stored in a partition key area (see fig. 23) of the device: kfrt performs MAC verification processing of the certificate. The MAC verification process is executed in accordance with the MAC value generation process described above using the DES encryption processing configuration of fig. 59.

Comparing the ICV (integrity Check value) generated by the data transmitting side when generating data for ensuring that the data is not tampered with the ICV generated by the data receiving side according to the received data, if the same ICV is obtained, ensuring that the data is not tampered, and if the ICVs are different, determining that the data is tampered. As described in the description of the file registration certificate (FRT) format of fig. 27, an ICV generated when data is generated, for example, by the data transmission side in order to ensure that it is not tampered is stored in an ICV (integrity Check value) field of the FRT. The ICV generated by the device is compared with the ICV stored in the reception certificate (FRT), if the ICV and the ICV are consistent, the certificate is judged to have legality, and if the ICV and the ICV are not consistent, the certificate is judged to be falsified, so the process of using the certificate is stopped.

By the above processing, the file registration certificate (FRT) verification processing when the Integrity Check Type described in the certificate is the common key system can be completed.

When it is determined in step S519 that the certificate type is not a file registration certificate (FRT), in step S519, the certificate type is checked and it is determined whether the certificate is a Service Permission certificate (SPT).

When the certificate type is the Service Permission certificate (SPT), steps S520 to S522 are executed, and when not, the process proceeds to step S523.

When the certificate Type is a Service Permission certificate (SPT), it is determined in step S520 whether or not the setting of Integrity Check Type (the Type of validity Check value of the certificate (Ticket)) (Public key scheme (Public)/Common key scheme (Common)) described in the certificate is Public key scheme (Public) or not.

When the Type of the validity Check value (Integrity Check Type) is Public key mode (Public), the flow proceeds to step S521, and various processes are executed. The process executed in step S521 is first a verification process of the public key Certificate (CERT) of the certificate Issuer (Ticket Issuer) using the public key PUB CA (PAR) of the partition manager correspondence certification authority (CA (PAR)).

When a certificate (Ticket) transmitted from a service license certificate (SPT) issuing apparatus (SPT issue) is transmitted to a certificate user, if the certificate user is of the public key system, a public key certificate (CERT _ SPTI) of the service license certificate (SPT) issuing apparatus (SPT issue) is also transmitted to the device. The Attribute (Attribute) of the public key certificate (CERT _ SPTI) of the SPT issuing apparatus coincides with the identifier (SPTIC) of the service license certificate (SPT) issuing apparatus (SPT issue).

A signature performed with a secret key of the partition manager corresponding certification authority (CA (PAR)) is attached to the public key certificate (refer to fig. 11), and the signature is verified with a public key (PUB CA (PAR)) of the partition manager corresponding certification authority (CA (PAR)). The signature generation and verification are performed, for example, according to the flowcharts shown in fig. 12 and 13 described above. Based on this signature verification, it is determined whether or not the public key Certificate (CERT) of the certificate issuer is a legitimate public key Certificate (CERT) that has not been tampered with.

Further, in step S521, it is judged whether or not the membership Code of the user recorded in the selectable item area of the public key Certificate (CERT) of the certificate issuing apparatus, the validity of which has been confirmed by the signature check, coincides with the certificate issuing apparatus Code (SPTIC: SPT issue Code) recorded in the file definition Block (FDB: FileDefinition Block) in the device.

As described in the section of description of the public key certificate in fig. 11, the public key certificate stores the membership code of the certificate issuing apparatus (packet issue) that is the issuing apparatus of each certificate (PRT, FRT, SPT, etc.), and in this case, stores sptic (sptissuer code). When it is confirmed that the code in the optional area matches the certificate issuing apparatus code (SPTIC: SPT issued code) in the fdb (file Definition block) recorded in the device, it can be confirmed that the received certificate (SPT) is a certificate issued by a legitimate certificate issuing apparatus.

Then, the Device refers to a Revocation List (Revocation List) in which a public key Certificate identifier (for example, serial number: SN) of a Revocation Device (Device) and a Revocation apparatus (a reader/writer as a Device access apparatus, a Certificate user such as a PC, or a Certificate issuing apparatus) is registered, and determines whether or not the Certificate issuing apparatus is revoked, in the CRL _ PAR (see fig. 23) stored in the storage unit of the Device.

Next, verification of the validity Check Value (public key system: Signature) of the Integrity Check Value (certificate) which is a Signature recorded in the service license certificate (SPT) as a received certificate (see fig. 28 and 31) is performed, and it is confirmed that the certificate is not tampered with.

In the above, it was confirmed that (1) the public key Certificate (CERT) of the certificate Issuer (Ticket Issuer) is a legitimate public key Certificate (CERT) that has not been tampered with, (2) the Code recorded in the optional area of the public key Certificate (CERT) of the certificate issuing apparatus matches the certificate issuing apparatus Code (SPTIC: SPT Issuer Code) recorded in the fdb (file Definition block) in the device, (3) the certificate issuing apparatus (Ticket Issuer) has not been revoked, and (4) the certificate has not been tampered with by checking the Signature (Signature) of the received certificate (SPT)). The success of the validity check of the service license certificate (SPT) is determined on the condition that all the items are confirmed. When any of the above-mentioned items (1) to (4) cannot be confirmed, it is determined that the validity of the service license certificate (SPT) is not confirmed, and the process using the service license certificate (SPT) is suspended.

When it is determined in step S520 that the type of the Integrity check value of the certificate (Ticket) described in the certificate (Public key system (Public)/Common key system (Common)) is set to the Common key system (Common)), the process proceeds to step S522, and a check of the mac (message Authentication code) is performed. A device that uses a MAC verification key of a service license certificate (SPT) stored in a file definition block (see fig. 24) of the device: kspt performs MAC verification processing of certificates. The MAC verification process is executed in accordance with the MAC value generation process described above using the DES encryption processing configuration of fig. 59.

Comparing the ICV (integrity Check value) generated by the data transmitting side when generating data for ensuring that the data is not tampered with the ICV generated by the data receiving side according to the received data, if the same ICV is obtained, ensuring that the data is not tampered, and if the ICVs are different, determining that the data is tampered. As described in the description of the service license certificate (SPT) format in fig. 28 and 31, an ICV generated when data is generated, for example, by the data transmission side to ensure that the data is not tampered is stored in an ICV (integrity Check value) field of the SPT. The ICV generated by the device is compared with the ICV stored in the received certificate (SPT), and if the ICV and the ICV match, the certificate is judged to be legal, and if the ICV and the ICV do not match, the certificate is judged to be falsified, so that the process of using the service license certificate (SPT) is stopped.

Through the above processing, the service license (SPT) verification processing when the integrattheck Type described in the service license (SPT) is the common key system can be completed.

When it is determined in step S515 that the certificate type is not the service permission certificate (SPT), the certificate type is checked and it is determined in step S523 whether the certificate is a data Update certificate DEV (DUT: Date Update certificate (DEV)) (refer to fig. 32). As described above, the data update certificate (DUT) is an access permission certificate when the update processing is executed on various data stored in the storage unit of the device. Including a data update certificate-DEV (dut (DEV)) used in a process of updating management data of the device manager and a data update certificate-PAR (dut (PAR)) used in a process of updating management data of the partition manager.

When the certificate-DEV (DUT (DEV)) is updated for data, steps S524 to S528 are executed, and when the certificate-DEV (DUT: Date Update packet (DEV)) is not updated, the process proceeds to step S529.

When the certificate Type is the data update certificate DEV (dut (DEV)), it is determined in step S524 whether the setting of the Type of Integrity Check value (Public key system (Public)/Common key system (Common)) described in the certificate is a Public key system (Public) or not.

When the Type of the validity Check value (Integrity Check Type) is Public key mode (Public), the flow proceeds to step S525, and various processes are executed. The process executed in step S521 is a verification process of the public key Certificate (CERT) of the certificate Issuer (Ticket Issuer) using the public key PUB CA (DEV) of the partition manager compliant certification authority (CA (DEV)) first.

When the certificate (Ticket) transmitted from the data update certificate-DEV (DUT) (DEV)) issuing apparatus (DUT issue) is transmitted to the certificate user, if the certificate is a public key system, the public key certificate (CERT _ DUT) of the data update certificate (DUT) issuing apparatus (DUT issue) is also transmitted to the device. The Attribute (Attribute) of the public Key certificate (CERT _ DUT) of the DUT issuing apparatus coincides with the identifier (duty) of the code (duty _ DEV) of the certificate issuing apparatus within the dkdb (PUB) recorded in the Device.

A signature executed with a secret key of a device manager compliant certificate authority (CA (DEV)) is attached to a public key certificate (see fig. 11), and the signature is verified with a public key (PUB CA (DEV)) of the device manager compliant certificate authority (CA (DEV)). The signature generation and verification are performed, for example, according to the flowcharts shown in fig. 12 and 13 described above. Based on this signature verification, it is determined whether or not the public key Certificate (CERT) of the certificate issuer is a legitimate public key Certificate (CERT) that has not been tampered with.

Further, in step S525, it is judged whether the membership code of the user recorded in the selectable item area of the public key Certificate (CERT) of the certificate issuing apparatus, the validity of which has been confirmed through the signature check, coincides with the certificate issuing apparatus code (DUTIC _ DEV: DUTISSur Category for Device) recorded in DKDB (PUB) of the Device.

As described in the section of description of the public key certificate of fig. 11, the public key certificate stores the membership code of the certificate issuing apparatus (packet issue) that is the issuing apparatus of each certificate (PRT, FRT, SPT, etc.), and in this case, stores the duration (duration code). When it is confirmed that the code in the selectable area matches the certificate issuing apparatus code (DUT _ DEV) in the dkdb (PUB) (Device Key Definition Block (PUB)) recorded in the Device (see fig. 16), it can be confirmed that the reception certificate (DUT) is a certificate issued by a legitimate certificate issuing apparatus.

Then, the Device refers to a Revocation List (verification) in which public key Certificate identifiers (for example, serial number: SN) of a Revocation Device (Device) and a Revocation apparatus (a reader/writer as a Device access apparatus, a Certificate user such as a PC, and a Certificate issuing apparatus) are registered, and determines whether or not the Certificate issuing apparatus is revoked, in a CRL _ DEV (see fig. 18) stored in a Device key area in a storage unit of the Device.

Next, verification of the validity Check Value (public key system: Signature) of the Integrity Check Value (certificate) recorded in the data update certificate-DEV (dut (DEV)) as the reception certificate (refer to fig. 32) is performed, and it is confirmed that the certificate is not tampered.

In the above, it was confirmed that (1) the public key Certificate (CERT) of the certificate Issuer (Ticket Issuer) is a legitimate public key Certificate (CERT) that has not been tampered, (2) the code recorded in the optional area of the public key Certificate (CERT) of the certificate issuing apparatus matches the certificate issuing apparatus code (DUT _ DEV: certificate Category for Device) recorded in dkdb (PUB) (Device key definition Block (PUB)) in the Device, (3) the certificate issuing apparatus (Ticket Issuer) has not been revoked, and (4) the certificate has not been tampered by checking the Signature (Signature) of the received certificate (DUT). All the above items are confirmed as the validity check success of the conditional decision data updating certificate-DEV (dut (DEV)). When any of the above-described items (1) to (4) cannot be confirmed, it is determined that the validity of the data update certificate DEV (dut (DEV)) is not confirmed, and the process using the data update certificate DEV (dut (DEV)) is terminated.

When it is determined in step S524 that the type of the Integrity check value of the certificate (Ticket) (Public key system (Public)/Common key system (Common)) is set to the Common key system (Common)), it is determined in step S526 whether or not the data indicated by the OldData Code described in the data update certificate DEV (DUT (DEV)) is Kdut _ DEV1 (MAC verification key of the data update certificate (DUT)) or Kdut _ DEV2 (encryption key for data update) stored in the device key area (see fig. 18).

When Data indicated by Old Data Code described in the Data update certificate-DEV (DUT (DEV)) is Kdut _ DEV1 (key for MAC check of Data update certificate (DUT)) or Kdut _ DEV2 (encryption key for Data update) stored in the device key area (see fig. 18), in step S528, MAC check processing is performed using Kdut _ DEV3 (key for MAC check of Data update certificate (DUT)) stored in the device key area (see fig. 18), and when Data indicated by Old Data Code described in the Data update certificate-DEV (DUT (DEV)) is not kd _ DEV1 (key for MAC check of Data update certificate (DUT)) or kd _ DEV2 (encryption key for Data update) stored in the device key area (see fig. 18) in step S527, the MAC verification process is performed using Kdut _ DEV1 (key for MAC verification of data update certificate (DUT)) stored in the device key area (see fig. 18).

The reason why the verification is performed using different MAC verification keys as described above is that, when data to be updated is Kdut _ DEV1 (a key for MAC verification of a data update certificate (DUT)) or Kdut _ DEV2 (an encryption key for data update), since the key data is information that is prescribed in advance and should be stopped for some reason, for example, key information is leaked, the MAC verification using the data to be updated should be avoided. The MAC verification process is executed in accordance with the MAC value generation process described above using the DES encryption processing configuration of fig. 59.

When the device stores a new Kdut _ DEV1 (the key for MAC verification of the data update certificate (DUT)) in the device key area (see fig. 18), it is necessary to perform a replacement process, which is an exchange with the previously stored Kdut _ DEV3 (the key for MAC verification of the data update certificate (DUT)). When storing new Kdut _ DEV2 (encryption key for data update), exchange with Kdut _ DEV4 (encryption key for data update), that is, replacement processing should be performed.

By this exchange process of Kdut _ DEV1 with Kdut _ DEV3, and Kdut _ DEV2 with Kdut _ DEV4, a pair of Kdut _ DEV3 (key for MAC verification of data update certificate (DUT)) and Kdut _ DEV4 (encryption key for data update) is always kept as a new version of a pair of Kdut _ DEV1 (key for MAC verification of data update certificate (DUT)) and Kdut _ DEV2 (encryption key for data update). That is, kd ut _ DEV1 and kd ut _ DEV2, which are keys used normally, kd ut _ DEV3 and kd ut _ DEV4, are used to update kd ut _ DEV1 and kd ut _ DEV2 under abnormal conditions and function as spare keys to be replaced with keys kd ut _ DEV1 and kd _ DEV 2. The above-described processing will be further explained in the data update processing using the data update certificate (DUT) described later.

Comparing the ICV (integrity Check value) generated by the data transmitting side when generating data for ensuring that the data is not tampered with the ICV generated by the data receiving side according to the received data, if the same ICV is obtained, ensuring that the data is not tampered, and if the ICVs are different, determining that the data is tampered. As described in the description of the format of the data update certificate (DUT) in fig. 32, an ICV generated, for example, when data is generated by the data transmitting side to ensure that the data is not tampered is stored in the ICV (integrity Check value) field of the data update certificate (DUT).

The ICV generated by the device is compared with the ICV stored in the data update certificate DEV (DUT (DEV)) which is a reception certificate, and if the ICV and the ICV are consistent, the certificate is judged to be legal, and if the ICV and the ICV are not consistent, the certificate is judged to be falsified, so that the processing using the data update certificate DEV (DUT (DEV)) is stopped.

Through the above-described processing, the verification processing of the data update certificate DEV (dut (DEV)) in the case where the Integrity Check Type described in the data update certificate DEV (dut (DEV)) is the common key scheme can be completed.

When it is determined in step S523 that the certificate type is not the data update certificate DEV (dut (DEV)), the certificate is determined to be the data update certificate PAR (dut (PAR)) (see fig. 32). Data update certificate — PAR (dut (PAR)), which is a certificate used in update processing of management data of the partition manager.

In this case, in step S529, it is determined whether or not the setting of the Type of the integrity check value of the certificate (Ticket) (Public key system (Public)/Common key system (Common)) described in the certificate is a Public key system (Public).

When the Type of the validity Check value (Integrity Check Type) is Public key mode (Public), the flow proceeds to step S530, and various processes are performed. The process executed in step S530 is, first, a verification process of a public key Certificate (CERT) of a certificate Issuer (Ticket Issuer) using a public key PUB CA (PAR) of a partition manager compliant certification authority (CA (PAR)).

When a certificate (Ticket) issued by a data update certificate-PAR (DUT) (PAR) issuing apparatus (DUT issue) is transmitted to a certificate user, if the certificate is a public key system, a public key certificate (CERT _ DUT) of the data update certificate (DUT) issuing apparatus (DUT issue) is also transmitted to a device. The Attribute (Attribute) of the public Key certificate (CERT _ DUT) of the DUT issuing apparatus coincides with the code (duty _ PAR) of the certificate issuing apparatus within the Pkdb (PUB) (Partition Key Definition Block (PUB)) recorded in the device.

A signature performed with a secret key of the partition manager corresponding certification authority (CA (PAR)) is attached to the public key certificate (refer to fig. 11), and the signature is verified with a public key (PUB CA (PAR)) of the partition manager corresponding certification authority (CA (PAR)). The signature generation and verification are performed, for example, according to the flowcharts shown in fig. 12 and 13 described above. Based on this signature verification, it is determined whether or not the public key Certificate (CERT) of the certificate issuer is a legitimate public key Certificate (CERT) that has not been tampered with.

Further, in step S530, it is judged whether the membership code of the user recorded in the optional area of the public key Certificate (CERT) of the certificate issuing apparatus, the validity of which has been confirmed through the signature check, coincides with the certificate issuing apparatus code (DUTIC _ PAR: DUT IssuerCategory for Partition) recorded in the PKDB (PUB) (Partition KeyDefinition Block) in the device.

As described in the section of description of the public key certificate of fig. 11, the public key certificate stores the membership code of the certificate issuing apparatus (packet issue) that is the apparatus that issues each certificate (PRT, FRT, SPT, DUT), and in this case, stores the DUT (failure code). When it is confirmed that the code in the optional area matches the certificate issuing apparatus code (DUT issue) in the pkdb (pub) (partition Key Definition block) recorded in the device (see fig. 21), it can be confirmed that the received certificate (DUT) is a certificate issued by a legitimate certificate issuing apparatus.

Then, the Device refers to a Revocation List (verification) in which public key Certificate identifiers (for example, serial number: SN) of a Revocation Device (Device) and a Revocation apparatus (a reader/writer as a Device access apparatus, a Certificate user such as a PC, and a Certificate issuing apparatus) are registered, and determines whether or not the Certificate issuing apparatus is revoked, in a CRL _ DEV (see fig. 18) stored in a Device key area in a storage unit of the Device.

Next, verification of the Signature recorded in the data update certificate-PAR (dut (PAR) (refer to fig. 32), i.e., the Integrity Check Value (public key system: Signature) of the certificate (Ticket)), which is the received certificate, is performed, and it is confirmed that the certificate is not falsified.

In the above, it was confirmed that (1) the public key Certificate (CERT) of the certificate Issuer (Ticket Issuer) is a legitimate public key Certificate (CERT) that has not been tampered, (2) the code recorded in the optional area of the public key Certificate (CERT) of the certificate issuing apparatus matches the certificate issuing apparatus code (DUT _ PAR) recorded in the pkdb (pub) (authorization key definition block) of the device, (3) the certificate issuing apparatus (Ticket Issuer) is not revoked, and (4) the certificate is not tampered by checking the Signature (Signature) of the received certificate (DUT). All the above items are confirmed as the success of the validity check of the conditional decision data updating certificate-par (dut)). When any of the above-mentioned items (1) to (4) cannot be confirmed, it is determined that the validity of the data update certificate-par (dut) is not confirmed, and the process using the data update certificate-par (dut) is terminated.

When it is determined in step S529 that the Integrity check value type of the certificate (Ticket) described in the certificate (Public key system (Public)/Common key system (Common)) is set to the Common key system (Common), it is determined in step S531 whether or not the data indicated by the OldData Code (updated original data Code) described in the data update certificate-PAR (DUT (PAR)) is Kdut _ PAR1 (MAC verification key of data update certificate (DUT)) or Kdut _ PAR2 (encryption key for data update) stored in the partition key area (see fig. 23).

When Data indicated by the Old Data Code (Code of updated original Data) described in the Data update certificate-PAR (DUT), (PAR)) is Kdut _ PAR1 (key for MAC check of Data update certificate (DUT)) or Kdut _ PAR2 (encryption key for Data update) stored in the device key area (see fig. 23), in step S533, the MAC check process is performed using the Kdut _ PAR3 (key for MAC check of Data update certificate (DUT)) stored in the partition key area (see fig. 23), and when Data indicated by the Old Data Code (Code of original Data) described in the Data update certificate-PAR (DUT) (PAR)) is not Kdut _ PAR1 (key for MAC check of Data update certificate (DUT)) or Kdut _ PAR2 (encryption key for Data update) stored in the partition key area (see fig. 23), in step S532, the MAC verification process is performed using Kdut _ PAR1 (key for MAC verification of data update certificate (DUT)) stored in the partition key area (see fig. 23).

The reason why the verification is performed using different MAC verification keys as described above is that when the data as the update subject is Kdut _ PAR1 (key for MAC verification of data update certificate (DUT)) or Kdut _ PAR2 (encryption key for data update), since these key data are pieces of information prescribed in advance that should be stopped from being used for some reason, for example, key information leakage or the like, the MAC verification using these update subject data should be avoided. The MAC verification process is executed in accordance with the MAC value generation process described above using the DES encryption processing configuration of fig. 59.

Comparing the ICV (integrity Check value) generated by the data transmitting side when generating data for ensuring that the data is not tampered with the ICV generated by the data receiving side according to the received data, if the same ICV is obtained, ensuring that the data is not tampered, and if the ICVs are different, determining that the data is tampered. As described in the description of the format of the data update certificate (DUT) in fig. 32, an ICV generated, for example, when data is generated by the data transmitting side to ensure that the data is not tampered is stored in the ICV (integrity Check value) field of the data update certificate (DUT).

The ICV generated by the device is compared with the ICV stored in the received certificate, i.e. the data updating certificate PAR (DUT (PAR)), if the two are consistent, the certificate is judged to be legal, and if the two are not consistent, the certificate is judged to be falsified, so the processing using the data updating certificate PAR (DUT (PAR)) is stopped.

By the above-described processing, the data update certificate-PAR (dut (PAR)) verification processing can be completed when the Integrity Check Type described in the data update certificate-PAR (dut (PAR)) is of the common key system.

In step S541, the Device checks Authentication Flag (Flag indicating whether or not mutual Authentication with the Device (Device) is necessary in the use process of the certificate (Ticket)) of the reception certificate (PRT, FRT, SPT, or DUT). When the flag indicates that authentication is not required, the process is not executed and ends.

When the flag check in step S541 indicates that authentication is required, the process proceeds to step S542, and the authentication table (see fig. 51) is referred to with the membership (packet) of the certificate user (a reader/writer, a PC, or the like as a device access apparatus, which wants to execute processing using the certificate on the device) as a key.

Next, in step S543, the Authentication Type of the received certificate (data in which the mutual Authentication method (public key Authentication, common key Authentication, or both Authentication methods (Any)) of the Device (Device) is recorded) is checked, and if the Authentication method is either (Any), the flow proceeds to step S544, and it is determined whether or not the mutual Authentication data of the packet checked in step S542 is stored in the Authentication table (see fig. 51). If it is determined that mutual authentication information corresponding to the packet is stored in the table and mutual authentication between the certificate user (a reader/writer as an apparatus access device, a PC, or the like, which intends to perform a process of using the certificate with respect to the apparatus) and the apparatus has been completed, the legitimacy of the certificate user (for example, the reader/writer as the apparatus access device) is confirmed and the process is determined as user verification success. If the mutual authentication information of the corresponding packet is not stored in the authentication table (see fig. 51), it is determined that the user verification is not completed and the process ends as an error.

When the Authentication Type (data in which the mutual Authentication method (public key Authentication, common key Authentication, or both Authentication methods (Any)) of the Device (Device) is recorded) is not the same Authentication method (Any) in step S543, it is determined whether the Authentication Type is public key Authentication or not in step S545.

If the Authentication Type is public key Authentication, the process proceeds to step S546, and it is determined whether or not public key mutual Authentication data of the packet checked in step S542 is stored in the Authentication table (see fig. 51). If it is determined that the public-key mutual authentication information of the corresponding packet is stored in the table and the mutual authentication between the certificate user (a reader/writer, a PC, or the like as a device access apparatus which intends to perform a process using the certificate for the device) and the device is completed in the public-key authentication process, the process proceeds to step S547, and it is determined whether or not the identifier of the certificate user is present in the processing target certificate (PRT, FRT, SPT, or DUT), and if so, it is determined in step S548 whether or not the identifier, the class, or the Serial Number (SN) recorded as the identification Data (DN) in the public-key certificate of the authentication partner (the certificate user, i.e., the reader/writer or the like as the device access apparatus) matches the identifier, the class, or the Serial Number (SN) recorded as the identification data of the certificate user stored in the certificate. When the two are consistent, the user is judged to be successful in verification and the processing is finished.

When it is determined in step S546 that the public-key mutual authentication data of the packet checked in step S542 is not stored in the authentication table (see fig. 51), and therefore the mutual authentication between the certificate user (the reader/writer, PC, or the like as the device access apparatus, which intends to perform a process of using the certificate with respect to the device) and the device is not completed in the public-key authentication process, it is determined that the user verification is not completed and the process is ended as an error.

Further, when it is determined in step S548 that the identifier, the type, or the Serial Number (SN) recorded as the identification data in the public key certificate of the authenticated party (the certificate user, i.e., the reader/writer serving as the device access apparatus) does not match the identifier of the certificate user stored in the certificate, it is also determined that the user verification has not been completed and the process ends as an error.

If the identifier of the certificate user does not exist in the certificate, the process of step S548 is not executed, and the process is terminated as the user confirms success.

When it is determined in step S545 that the Authentication Type (data in which the mutual Authentication method (public key Authentication, common key Authentication, or both Authentication methods (Any)) of the Device (Device) are recorded) of the received certificate is not public key Authentication, the process proceeds to step S549, and it is determined whether or not the common key mutual Authentication data of the packet checked in step S542 is stored in the Authentication table (see fig. 51). If it is determined that the common key mutual authentication information of the corresponding packet is stored in the table and the mutual authentication between the certificate user (a reader/writer, a PC, or the like as an apparatus access device which intends to perform a process of using the certificate for the apparatus) and the apparatus is completed in the common key authentication process, the process proceeds to step S550, where it is determined whether or not the identifier of the certificate user is present in the processing target certificate (PRT, FRT, SPT, or DUT), and if so, it is determined whether or not the identification data (IDrw) of the authentication partner (the certificate user, i.e., the reader/writer or the like as the apparatus access device) matches the identifier of the certificate user stored in the certificate in step S551. If the two are consistent, the user is determined to confirm the success and the process is ended.

When it is determined in step S549 that the common key mutual authentication data of the packet checked in step S542 is not stored in the authentication table (see fig. 51), and therefore the mutual authentication between the certificate user (the reader/writer, PC, or the like as the device access apparatus, which intends to perform a process of using the certificate with respect to the device) and the device is not completed in the common key authentication process, it is determined that the user verification is not completed and the process is ended as an error.

In addition, when it is determined in step S551 that the identification data (IDrw) of the authenticated party (the certificate user, i.e., the reader/writer as the device access apparatus, etc.) does not match the identifier of the certificate user, it is also determined that the user verification has not been completed and the process ends as an error.

When the identifier of the certificate user does not exist in the certificate or all certificate users can be used, the process of step S550 is not performed, and the process is ended as the user confirms success.

The above processing is the certificate validity and user check processing executed by the apparatus in step S413 of the flowchart of fig. 47.

(partition creation deletion processing)

The following describes in detail the partition creation and deletion process executed based on the partition registration certificate (PRT) in step S415 in the flowchart in fig. 47, with reference to the process flow in fig. 60 and 61. The partition creation/deletion process is a process executed by a device that receives a partition registration certificate (PRT) from a certificate user (for example, a reader/writer, a PC, or the like that is a device access apparatus) based on the partition registration certificate (PRT).

In step S601 in fig. 60, the processing method recorded in the received Partition Registration certificate (PRT: Partition Registration packet), i.e., the Operation Type (designation of Partition (Partition) generation or deletion) (generation/deletion) is checked, and when the processing method (Operation Type) is generated for a Partition (Partition), the processing in step S602 and subsequent steps is executed, and when the Partition (Partition) is deleted, the processing in step S621 and subsequent steps is executed.

First, the Partition (Partition) generation process will be described. In step S602, the device checks whether or not a partition exists in the storage unit of the device, the partition having the same code as the Partition Manager Code (PMC) described in the partition registration certificate (PRT). This determination can be made by checking whether or not the same code as the description code of the reception certificate PRT is described in the partition definition block (see fig. 19) of the storage section of the device.

When a partition having the same code (PMC) already exists in the device, since a duplicate partition having the same code is not allowed to exist, the generation of the partition cannot be performed and ends up as an error. When there is no Partition having the same code in the Device, in step S603, the Free Block Number in the Device (Device) of the Device management information Block (see fig. 15) is compared with the Partition Size (Partition Size) described in the Partition registration certificate (PRT), and it is determined whether or not there is a Free Block area larger than the Partition Size (Partition Size) described in the certificate (PRT) in the storage unit of the Device. If not, the partition of the size described in the PRT cannot be generated, and therefore, the process ends as an error.

When it is determined that a Free block Area larger than the Partition Size (Partition Size) described in the certificate (PRT) exists in the storage unit of the Device, the process proceeds to step S604, where a Partition Definition Block (PDB) Area is secured in the highest block of the Free Area (Free Area in Device) of the Device by referring to the Pointer (Pointer of Free Area) of the Device management information block (see fig. 19).

Next, the device copies the Partition Manager Code (PMC) described in the partition registration certificate (PRT) into the secured Partition Definition Block (PDB) area (S605), and also copies the PMC version described in the PRT into the secured Partition Definition Block (PDB) area (S606).

Then, a process (S607) of copying the Pointer (Pointer of free area) of the device management information block to the Partition start position (Partition start position) of the Partition Definition Block (PDB) area is executed, and a process (S608) of copying the Partition Size (Partition Size) described in the Partition registration certificate (PRT) to the Partition Size (Partition Size) of the Partition Definition Block (PDB) area is further executed.

Next, the Partition Size (Partition Size) copied to the Partition Definition Block (PDB) area is added to the Pointer (Pointer of Free area) of the Device management information Block (S609), and the Partition Size (Partition Size) +1 is subtracted from the Number of Free blocks (Free Block Number in Device) in the Device (Device) of the Device management information Block (see fig. 15) (S610). +1 means a block used for the Partition Definition Block (PDB).

Next, the partition number (partition number) of the device management information block (see fig. 15) is added to 1, that is, the generated partition (1) is added (S611).

Next, in step S631 of fig. 61, the highest Block of the generated Partition area is set as the Partition Management Information Block (PMIB) (see fig. 20), a process of copying the PMC of the Partition registration certificate (PRT) to the Partition Manager Code (PMC) field of the set Partition Management Information Block (PMIB) (S632), a process of copying the PMC version of the Partition registration certificate (PRT) to the PMC version field of the Partition Management Information Block (PMIB) (S633), and a process of copying the Partition Size (Partition Size) of the Partition registration certificate (PRT) to the Total Number of Partition blocks (Total Block Number in Partition) field of the Partition Management Information Block (PMIB) (S634) are performed.

Further, Partition Size (Partition Size) -3 of the Partition registration certificate (PRT) is recorded in the Free Block number Partition field of the Partition Management Information Block (PMIB) (S635). -3 means deducting three blocks of a Partition Management Information Block (PMIB) which has been scheduled for use, a common key system partition key definition block (pkdb (common)), and a public key system partition key definition block (pkdb (pub)). A

Then, 0 is entered in the File Number (File Number) of the Partition Management Information Block (PMIB) (S636). At this point in time no files have been set in the partition. The file setting may be performed using a file registration certificate (FRT). The login process using the file login certificate (FRT) will be described later.

Next, the Partition start position (Partition StartPosition) of the Partition Definition Block (PDB) Area is copied to the pointer (pointer of Free Area) of the Free Area of the device management information block (PMIB), and the setting registration of the Partition is terminated.

The partition deletion processing in steps S621 to S628 in fig. 60 will be described below. In step S621, it is checked whether or not a partition having the same code as the Partition Manager Code (PMC) described in the partition registration certificate (PRT) exists in the storage unit of the device. This determination can be made by checking whether or not the same code as the description code of the reception certificate PRT is described in the partition definition block (see fig. 19) of the storage section of the device.

When there is no partition having the same code (PMC) in the device, deletion of the partition is not possible, and therefore ends up as an error. When there is a partition having the same code in the device, it is determined in step S622 whether or not there is a partition generated after the partition of the object is deleted in the device. If the partition is not present, the partition to be deleted is the latest partition, and therefore, in step S629, the Partition Definition Block (PDB) (see fig. 19) of the partition to be deleted is deleted.

When it is determined in step S622 that a partition generated after the partition to be deleted exists in the device, a process of moving the data of the partition to be generated later (the later partition) to a lower position by the Partition Size (PS) corresponding to the deletion target is executed (S623), and a process of moving the Partition Definition Block (PDB) of the later partition by 1 block to the upper position is further executed (S624). Further, a process of subtracting the size (PS) of the deleted partition from the partition start Position (PartitionStart Position) recorded in the Partition Definition Block (PDB) of the post-partition is also executed (S625).

After the processing in step S625 or S629, in step S626, the deleted Partition Size (PS) +1 is added to the Free Block Number in Device in the Device (Device) of the Device management information Block (see fig. 15). +1 means deleting the block used by the Partition Definition Block (PDB) of the partition.

Next, in step S627, the size (PS) of the deletion partition is subtracted from the value of the Pointer (Pointer of Free Area) of the Free Area of the device management information block (see fig. 15). Further, in step S628, the Number of partitions (Partition Number) in the device management information block (see fig. 15) is subtracted by 1, that is, the deleted Partition (1) is subtracted, and the Partition deletion process based on the Partition registration certificate (PRT) is terminated.

The above processing is the partition creation and deletion processing based on the partition registration certificate (PRT) in step S415 of the processing flow of fig. 47.

(initial registration of partition)

The partition initial data writing process in steps S406 and S419 of the process flow of fig. 47, that is, the partition initial registration process based on the partition registration certificate (PRT), will be described in detail below with reference to fig. 62 and the flowcharts that follow.

In the processing flows shown in fig. 62, 63, and 64, the left side shows the processing of the initial login device managed by the partition manager, and the right side shows the processing of the device (see fig. 5). The initial login device managed by the partition manager is a device (for example, a reader/writer or a PC as a device access device) capable of performing data reading/writing processing on a device, and has a configuration equivalent to the reader/writer as the device access device in fig. 10. As shown in the processing flow of fig. 47, before the process of fig. 62 is started, it is assumed that mutual authentication has been performed between the initial login apparatus and the device, and the legitimacy of the certificate and the user (the certificate user, i.e., the reader/writer as the device access apparatus, etc.) is confirmed in the certificate legitimacy and user verification, and further, the partition creation process based on the partition login certificate (PRT) has been completed. The data transmission/reception between the initial registration apparatus and the device in fig. 62, 63, and 64 is performed in a data format encrypted with the session key Kses generated at the time of mutual authentication.

In step S641 in fig. 62, the initial login apparatus determines whether or not the common key is used for partition authentication. This determination is made with reference to the Authentication Type of the partition registration certificate (PRT) used (refer to her 26) (data in which the mutual Authentication method (public key Authentication, common key Authentication, or both Authentication methods (Any)) of the Device (Device) is recorded) is not performed in the field of either Authentication method (Any).

As shown in fig. 62, steps S642 to S643 and S651 to S654 are executed when the common key is used for the partition authentication, and are omitted when the common key is not used for the partition authentication.

When the common key is employed in the partition authentication, in step S642, Mkauth _ PAR _ a: master key for bidirectional single key authentication, Kauth _ PAR _ B: bidirectional single key authentication key, IRL _ PAR: a Revocation List (Device ID) in which a Device Identifier (ID) of a Revocation Device (Device) is registered and version information thereof are transmitted to the Device as a common key authentication data write command.

In step S651, the device receives the write command, and writes the received data in the partition key area in step S652 (see fig. 23). Next, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S653), and a write completion notification is transmitted to the login apparatus (S654).

The login device that has received the write completion notification (S643) determines in step S644 whether or not the public key is used for partition authentication. As shown in fig. 62, steps S645 to S649, S655 to S662 are executed when the public key is employed in the partition authentication, and these steps are omitted when the public key is not employed in the partition authentication.

When the public key is used for partition authentication, the login device registers, in step S645, the public key to the PUB _ ca (par): public key of certification authority (ca (PAR)) for transmitting partition manager corresponding public key, PARAM _ PAR: public key parameter of Partition (Partition), CRL _ PAR: a Revocation List (Revocation List) in which a public key Certificate identifier (e.g., serial number: SN) of a Revocation Device (Device) is registered, and version information thereof are transmitted to the Device as a public key authentication data write command.

In step S655, the device receives the write command, and in step S656, writes the received data in the partition key area (see fig. 23)). Next, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S657), and a write completion notification is transmitted to the registration device (S658).

The login device that has received the write completion notification (S646) transmits a key pair generation command of the public key and the secret key to the device (S647). In the present embodiment, the generation of the key pair is executed by the device, but may be executed by a registration device and provided to the device.

The device that has received the key pair generation command (S659) generates a key pair of the public key (PUB PAR) and the secret key (PRI PAR) by the encryption processing unit (see fig. 5) in the device, and writes the generated key in the partition key area (see fig. 23) (S660). Next, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S661), and the generated and stored public key is transmitted to the login apparatus (S662).

The login means receives the public key (PUB PAR) from the device (S648), and stores the public key together with the device identifier IDm previously received from the device in the database (db (PAR)) in the partition manager (see fig. 9).

Next, the registration device of the partition manager determines whether or not the common key is used for the verification process of the partition registration certificate (PRT) (S671). As described above, the certificate verification may be performed by using any one of a common key system such as MAC value verification and a public key system in which signature generation using a secret key and signature verification using a public key are performed, and the partition manager may set a verification processing system to be used by the device. And the partition manager sets data which can execute either a common key or a public key or both modes according to the FRT certificate verification mode adopted by the equipment.

When the partition manager is set to execute the common key authentication in the verification process of the File registration certificate (FRT), information (for example, an FRT verification common key) required for the FRT verification of the common key system is set in the device, and if the device does not execute the common key system, the partition manager does not store the information in the device.

As shown in fig. 63, steps S672 to S673, S681 to S684 are performed when the common key scheme is adopted in the FRT test, and are omitted when the common key scheme is not adopted in the FRT test.

When the common key is used in the FRT check, the login device registers, in step S672, Kfrt: the MAC verification key and version information of the file entry certificate (FRT) are transmitted to the device as an FRT verification common key write command.

In step S681, the device receives the write command, and writes the received data in the partition key area in step S682 (see fig. 23). Next, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S683), and a write completion notification is transmitted to the registration device (S684).

The login device that has received the write completion notification (S673) determines in step S674 whether or not the FRT check employs the public key. As shown in fig. 63, steps S675 to S676, S685 to S690 are performed when the public key is employed in the FRT verification, and are omitted when the public key is not employed in the FRT verification.

When the public key is used for the FRT test, the registration apparatus registers, in step S675, an identifier of frtic (FRT issue category): file login certificate (FRT) issuer category, PUB _ ca (par): public key of certificate authority (ca (PAR)) for issuing partition manager corresponding to public key, PARAM _ PAR: public key parameter of Partition (Partition), CRL _ PAR: a Revocation List (Revocation List) in which a public key Certificate identifier (e.g., serial number: SN) of a Revocation Device (Device) is registered, and version information thereof are transmitted to the Device as an FRT check data write command.

In step S685, the device receives the write command, and after confirming that the DMIB write Flag (Writable Flag) is Writable in step S686, in step S278, the device writes the information of the frtic (prt clearance category): the file registration certificate (FRT) issuer type is written in a public key Partition key definition Block (PKDB: Partition key definition Block (PUB)) (refer to fig. 22)), and version information is written in the version area of the Block.

Next, the apparatus, in step S687, determines whether or not PUB _ ca (par) has been written: if the public key data of the certification authority (ca (PAR)) that issues the partition manager and corresponds to the public key has not been written yet, PUB _ ca (PAR), PARAM _ PAR, and CRL _ PAR are written in the partition key area in step S688 (see fig. 23). Then, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S689), and a write completion notification is transmitted to the login device (S690).

The registration device that has received the write completion notification (S676) then determines in step S701 whether or not it is a device that supports the update of the common key data. Among the data stored in the device, some data can be updated with a data Update certificate (DUT) (refer to fig. 32). The data to be updated is explained above with reference to fig. 33. In the Update process using the data Update certificate (DUT), either a common key method or a public key method may be used, and the partition manager sets, in the device, data that can be executed in either or both of the methods, depending on the partition.

If the set partition is configured to perform data update in accordance with the shared key method, the partition manager sets information (for example, a key for MAC verification of a data update certificate (DUT)) necessary for data update processing in the shared key method in the partition key area of the device, and if the device is a device that does not perform shared key authentication, the partition manager does not store the information in the device.

As shown in fig. 64, steps S702 to S703 and S711 to S714 are executed when the common key scheme is adopted in the data update process using the data update certificate (DUT: Date update ticket), and are omitted when the common key scheme is not adopted in the data update.

When the common key is used for data update, the login device registers Kdut _ PAR 1: key for MAC verification of data update certificate (DUT), Kdut _ PAR 2: encryption key for data update, Kdut _ PAR 3: key for MAC verification of data update certificate (DUT), Kdut _ PAR 4: the encryption key for data Update and its version information are transmitted to the device as a data Update certificate (DUT) verify common key write command.

In step S711, the device receives the write command, and writes the received data in the partition key area in step S712 (see fig. 23). Next, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S713), and a write completion notification is transmitted to the login apparatus (S714).

The login device that has received the write completion notification (S703) determines in step S704 whether or not the partition set in the device supports data Update processing using a data Update certificate (DUT: Date Update packet) using the public key scheme. As shown in fig. 64, steps S705 to S706 and S715 to S718 are executed when the public key scheme is supported, and are omitted when the public key scheme is not supported.

When the public key scheme is supported, in step S705, the login device registers, for example, dut _ par (dut issue category): the data Update certificate (DUT: Date Update Ticket) issuer category and its version information are sent to the device as a data Update certificate (DUT: Date Update Ticket) issuer code write command.

In step S715, the device receives the write command and writes the received data in a public key system Partition Key Definition Block (PKDB) in step S716. Next, adjustment of the pointer generated by data writing, the data size, and the number of free blocks in the device is performed (S717), and a write end notification is transmitted to the login apparatus (S7183. the login apparatus receives the write end notification (S706), and ends the processing.

Fig. 65 shows an example of the in-memory data structure of the device in a state after the initial login processing (the processing flow of fig. 62 to 64) by the partition manager is completed. In the Partition (Partition) area shown in fig. 65, the following data is transmitted from the registration device to the Partition key area and written in the above-described flow (fig. 62 to 64).

IRL _ PAR: a Revocation List (Device ID) in which Identifiers (IDs) of a partition access Revocation Device (Device) and Revocation apparatuses (a certificate user such as a reader/writer and a PC as a Device access apparatus, and a certificate issuing apparatus) are registered

CRL _ PAR: revocation List (Certificate) in which public key Certificate identifiers (e.g., serial number: SN) of partition access Revocation devices (devices) and Revocation apparatuses (Certificate users such as readers and PCs as Device access apparatuses, and Certificate issuing apparatuses) are registered

Kauth _ PAR _ B: common key for bidirectional single key authentication

Mkauth _ PAR _ a: master key for bidirectional single key authentication

Kd ut _ PAR 1: key for MAC verification of data update certificate (DUT)

Kd ut _ PAR 2: encryption key for data update

Kd ut _ PAR 3: key for MAC verification of data update certificate (DUT)

Kd ut _ PAR 4: encryption key for data update

Kfrt: key for MAC verification of file registration certificate (FRT)

In addition, the following data is generated and written by the device.

PUB _ PAR: public key for Partition (Partition)

PRI _ PAR: secret key for partitions (partitions)

The following data are data written at the time of partition creation (see processing flowcharts 60 and 61),

PARAM _ PAR: public key parameter for Partition (Partition)

PUB _ ca (par): public key of certification authority (CA (PAR))

Partition Key information Block (common) of shared Key system

Partition Key information Block (PUB) for public Key System

Partition Management Information Block (Partition Management Information Block)

[ B4.2. public Key certificate issuing processing under partition manager management ]

Next, the process of issuing the partition-associated public key certificate by the partition manager will be described with reference to fig. 66 and the flowchart that follows. The device can store a device-associated public key certificate (CERT DEV) applicable to authentication of the entire device and processing on a device-by-device basis, and a partition-associated public key certificate (CERT PAR) applicable to authentication and other verification processing when a specific partition in the device is processed. The partition corresponds to a public key certificate (CERT PAR), and can be set and stored for each partition set in the device.

The partition corresponds to the public key certificate (CERT PAR), is issued by the login authority managed by the partition manager in accordance with a program that provides the public key certificate issued by the certificate authority (CA for PM) (see fig. 2 and 3) to the device, and the login authority manages the public key certificate (CERT PAR) issued by the login authority managed by the partition manager (database 332 (see fig. 9)).

A procedure of the partition-based public key certificate (CERT PAR) issuing process performed on the set partition by the registration authority managed by the partition manager will be described with reference to fig. 66 and 67. In fig. 66 and 67, the left side is a CERT (public key certificate) issuing apparatus of a registration authority managed by the partition manager, specifically, a process of the control apparatus 331 in the configuration diagram of the partition manager shown in fig. 9, and the right side is a process of the device.

First, in step S721, the CERT issuing apparatus acquires user information of a device to be issued as a partition-associated public key certificate (CERT PAR), allows (determines) the issuing of the certificate, and secures a communication line with the device to be issued. The user information of the device to which the partition correspondence public key certificate (CERT PAR) is issued can be obtained from data generated at the time of initial login of the device, for example. The user information may be acquired from the device after setting a communication line with the device. The communication line, whether wired or wireless, may be any communication line that can transmit and receive data.

Then, in step S722, the CERT issuing apparatus transmits an authentication data generation command including a random number to the device. The device that has received the authentication data generation command (step S731) executes a generation process of a digital signature (S) (see fig. 12) by applying the partition secret key (PRI PAR) to the combined data of the reception random number R and the device identifier (IDm) (S732). The device transmits the identification data (IDm) and the signature (S) of the device to the CERT issuing apparatus.

The CERT issuing apparatus, which has received the identification data (IDm) and the signature (S) from the device (step S723), acquires the stored partition public key (PUB PAR) from the database db (PAR)222 using the received device identification data (IDm) as a search key. Further, verification processing of the signature (S) (see fig. 13) is executed using the acquired partition public key (PUB PAR) (S725). When the verification is unsuccessful, it is determined that the transmission data from the device is illegal data, and the process is ended.

When the verification is successful, the issuing process of the partition associating public key certificate (CERT PAR) is requested to the certification authority (CA for PM) 620 (S727). The partition manager receives the partition corresponding public key certificate (CERT PAR) issued by the certificate authority 620 (S728) and transmits the same to the device (S729).

The device that receives the partition correspondence public key Certificate (CERTPAR) from the partition manager (login authority) performs signature verification of the received partition correspondence public key certificate (CERT PAR) using the public key (PUB CA (PAR)) of the certification authority that has been stored in advance in the partition key area (refer to fig. 23). That is, a signature executed with the secret key of the certification authority is included in the public key certificate (see fig. 11), and the signature is verified (S735).

When the signature verification fails, the CERT is determined not to be a valid public key certificate, and an error notification is transmitted to the CERT issuing apparatus (S745).

When the signature verification is successful, the partition 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 device itself (S741), and when they do not match, an error notification is transmitted, and when they match, the received partition corresponding public key certificate (CERT PAR) is stored in the partition key area (see fig. 23) (S743). Before the partition corresponding public key certificate (CERT PAR) is issued, a public key (PUB PAR) generated by the device itself is stored in the area, and at the time when the partition corresponding public key certificate (CERT PAR) is issued, the partition corresponding public key certificate (CERT PAR) is rewritten and stored.

When the storing of the partition correspondence public key certificate (CERT PAR) is finished, a storing process end notification is transmitted to the CERT issuing apparatus (S744). The CERT issuing apparatus receives the storage process end notification (S751), confirms the success of storage (S752), and ends the process. If the success of the storage cannot be confirmed, the process ends as an error.

[ B4.3. processing procedure for various partition creation processing methods ]

As described above, in the setting registration processing of the partition, mutual authentication is performed between the reader/writer as the device access apparatus managed by the partition manager and the device, and the partition is set based on the partition registration certificate (PRT). The mutual authentication processing described above is performed in either one of two ways, public key mutual authentication and common key mutual authentication, and the verification processing of the certificate (PRT) also performs either one of two ways, signature verification by public key system and MAC verification by common key system. That is, the treatment forms can be roughly classified into the following 4 types.

(A) Mutual authentication (public key), certificate (PRT) verification (public key)

(B) Mutual authentication (public key), certificate (PRT) verification (shared key)

(C) Mutual authentication (shared key), certificate (PRT) verification (shared key)

(D) Mutual authentication (shared key), certificate (PRT) verification (public key)

The above-described 4 types of processes will be briefly described with reference to the drawings, centering on the data transfer process performed by the Device Manager (DM), Partition Manager (PM), device, and entities.

(A) Mutual authentication (public key), certificate (PRT) verification (public key)

First, data transfer between entities when the public key method is used for mutual authentication processing and the public key method is used for verification of a certificate (PRT) will be described with reference to fig. 68. In addition, as shown in the configuration of fig. 68, hereinafter, for simplification of description, 1 Certification Authority (CA) is set, 1 registration authority is set in the device manager, and the device manager public key certificate (cert.dm) and the partition manager public key certificate (cert.pm) are issued by the respective registration authorities and certification authorities. The device for issuing the partition registration certificate (PRT) is a Device Manager (DM), and the signature of the partition registration certificate (PRT) is executed by using a secret key of the device manager.

Data transfer is performed between the entities in the order of the sequence numbers shown in the figure. Hereinafter, the processing will be described by each number.

(1) Distribution of a public key certificate (cert. DM) for a Device Manager (DM)

The public key certificate (cert.dm) is issued by a Certification Authority (CA) to a device manager through a registration authority in accordance with a certificate issuance procedure in response to an issuance request from the device manager.

(2) Issuing of public key certificate (cert. PM) of Partition Manager (PM)

The public key certificate (cert. pm) is issued by a Certification Authority (CA) to the partition manager through a registration authority in accordance with a certificate issuance procedure in response to an issuance request from the partition manager.

(3) Issuing process of partition login certificate (PRT)

The partition registration certificate (PRT) is issued to the Partition Manager (PM) by a partition registration certificate issuing apparatus (PRT packet issue) managed by the device manager. In this case, in order to generate and verify a Signature by the public key method, a Signature (Signature) is generated by a secret key of the device manager (see fig. 12) and added to the PRT.

(4) Supply of PRT and DM public Key certificate (Cert. DM) to PM

A partition registration certificate (PRT) issued by a partition registration certificate issuing apparatus (PRT ticketsusher) managed by a device manager is issued to the partition manager together with a DM public key certificate (cert.dm).

(5) Mutual authentication between PM and device

A target device that generates a partition from an issued PRT and a partition manager (specifically, a reader/writer as a device access apparatus that is a certificate user) are required to perform mutual authentication by a public key method (see fig. 50).

(6) Provisioning of PRT and DM public Key certificate (Cert. DM) to a device

When the PM and the device are authenticated with each other, the Partition Manager (PM) issues a partition registration certificate (PRT) and a DM public key certificate (cert.dm) to the device.

A Device that performs, on a received partition entry certificate (PRT), confirmation that (1) a public Key Certificate (CERT) of a certificate Issuer (Ticket Issuer) DM is a legitimate public Key Certificate (CERT) that is not falsified, (2) a Code recorded in an optional area of the public Key Certificate (CERT) of a certificate issuing apparatus (Ticket Issuer) coincides with a certificate issuing apparatus Code (PRTIC: PRT Issuer Code) recorded in DKDB (Device Key Definition Block (PUB)) in the Device, (3) the certificate issuing apparatus (Ticket) is not revoked, (4) a confirmation that the certificate has not been falsified according to a verification of a Signature (Signature) on a received certificate (PRT)), and further, confirms that a user as a PRT stored in the PRT certificate (PM in this case: a reader/writer as a device access apparatus) and whether or not the identifier, the class, or the Serial Number (SN) recorded in the identification Data (DN) of the certificate user matches the identifier, the class, or the Serial Number (SN) recorded in the received public key certificate of the partition manager as the identification Data (DN), and the authentication of the PRT user (PM: a reader/writer as a device access apparatus, etc.) (see fig. 57 and 58).

(7) Partition generation

When the verification of the partition registration certificate (PRT) and the verification of the PRT Issuer (PRT Issuer) and the PRT user are successful, the partition is generated in the storage unit of the device according to the rule recorded in the partition registration certificate (PRT) (see fig. 60 and 61).

(8) Key data write

After a partition is generated in a storage unit of a device, storage processing of various keys is executed in the generated partition.

(9) Reading of public keys

(10) Issuing of public key certificates

When performing public key authentication in authentication processing when various services are provided to a partition (authentication processing when services such as partition generation, file access, and data update are provided), a device generates a key pair of a public key and a secret key, transmits the generated key to a partition manager, performs transmission processing of a public key certificate by a login mechanism and an authentication mechanism, and stores the issued public key certificate in a partition key area (see fig. 23). In this case, the issued public key certificate is stored in the storage area of the generated public key. The processes (9) and (10) can be executed when performing public key authentication in authentication processes when various services are provided to a partition (authentication processes when services such as partition creation, file access, and data update are provided).

According to the above processing, the partition generation processing can be performed in each of the modes of mutual authentication (public key) and certificate (PRT) verification (public key).

(B) Mutual authentication (public key), certificate (PRT) verification (shared key)

Hereinafter, data transfer between entities using the public key method for mutual authentication processing and the common key method for certificate (PRT) verification will be described with reference to fig. 69. Data transfer is performed between the entities in the order of the sequence numbers shown in the figure. Hereinafter, the processing will be described by each number.

(1) Issuing of public key certificate (cert. PM) of Partition Manager (PM)

The public key certificate (cert. pm) is issued by a Certification Authority (CA) to the partition manager through a registration authority in accordance with a certificate issuance procedure in response to an issuance request from the partition manager.

(2) Issuing process of partition login certificate (PRT)

The partition registration certificate (PRT) is issued to the Partition Manager (PM) by a partition registration certificate issuing apparatus (PRT packet issue) managed by the partition manager. In this case, a MAC (Message Authentication Code) (see fig. 59) is added to the PRT as a verification value of the common key method.

(3) PRT to PM supply

A partition registration certificate (PRT) issued by a partition registration certificate issuing apparatus (PRT TicketIssuer) managed by a device manager is issued to the partition manager.

(4) Mutual authentication between PM and device

A target device that wants to generate a partition from a transmitted PRT and a partition manager (specifically, a reader/writer as a device access apparatus that is a certificate user) perform mutual authentication by a public key method (see fig. 50).

(5) Transmission of PRT

A partition login certificate (PRT) issued by a partition manager is issued to a device. The device executes MAC verification processing for the received partition login certificate (PRT), verifies the verification of the PRT Issuer (PRT Issuer), further verifies whether or not the identifier, the class, or the Serial Number (SN) recorded as the identification Data (DN) of the PRT user (in this case, the PM: the certificate user, i.e., the reader/writer as the device access apparatus) stored in the PRT certificate matches the identifier, the class, or the Serial Number (SN) recorded as the identification Data (DN) in the received public key certificate of the partition manager, and executes verification of the PRT user (PM: the reader/writer as the device access apparatus, etc.) by confirming the completion of mutual authentication (see fig. 57 and 58).

(6) Partition generation

When the verification of the partition registration certificate (PRT) and the verification of the PRT Issuer (PRT Issuer) and the PRT user are successful, the partition is generated in the storage unit of the device according to the rule recorded in the partition registration certificate (PRT) (see fig. 60 and 61).

(7) Key data write

After a partition is generated in a storage unit of a device, storage processing of various keys is executed in the generated partition.

(8) Reading of public keys

(9) Issuing of public key certificates

When performing public key authentication in authentication processing when various services are provided to a partition (authentication processing when services such as partition generation, file access, and data update are provided), a device generates a key pair of a public key and a secret key, transmits the generated key to a partition manager, performs public key certificate issuance processing by a login mechanism and an authentication mechanism, and stores the issued public key certificate in a partition key area (see fig. 23). At this time, the issued public key certificate is stored in the storage area of the generated public key. The processes (8) and (9) can be executed when performing public key authentication in authentication processes when various services are provided to a partition (authentication processes when services such as partition creation, file access, and data update are provided).

According to the above processing, the partition generation processing can be executed in each of the modes of mutual authentication (public key) and certificate (PRT) verification (common key).

(C) Mutual authentication (shared key), certificate (PRT) verification (shared key)

Next, data transfer between entities using the common key scheme for mutual authentication processing and verifying the use of the common key scheme for a certificate (PRT) will be described with reference to fig. 70. Data transfer is performed between the entities in the order of the sequence numbers shown in the figure. Hereinafter, the processing will be described by each number.

(1) Issuing process of partition login certificate (PRT)

The partition registration certificate (PRT) is issued to the Partition Manager (PM) by a partition registration certificate issuing apparatus (PRT packet issue) managed by the partition manager. In this case, the MAC (see fig. 59) is added to the PRT as a check value of the common key scheme.

(2) PRT to PM supply

A partition registration certificate (PRT) issued by a partition registration certificate issuing apparatus (PRT TicketIssuer) managed by a device manager is issued to the partition manager.

(3) Mutual authentication between PM and device

A target device that wants to generate a partition from an issued PRT and a partition manager (specifically, a reader/writer as a device access apparatus that is a certificate user) perform mutual authentication by a common key method (see fig. 53 and 54).

(4) Distribution of PRT

A partition login certificate (PRT) issued by a partition manager is sent to a device. The device executes MAC verification processing on the received partition login certificate (PRT), verifies the PRT Issuer (PRT Issuer) and further verifies whether or not the identifier of the PRT user (in this case, the PM: the certificate user, i.e., the reader/writer as the device access apparatus) stored in the PRT certificate matches the identifier of the partition manager, and executes verification on the PRT user (PM: the reader/writer as the device access apparatus) by confirming completion of mutual authentication (see fig. 57 and 58).

(5) Partition generation

When the verification of the partition registration certificate (PRT) and the verification of the PRT Issuer (PRT Issuer) and the PRT user are successful, the partition is generated in the storage unit of the device according to the rule recorded in the partition registration certificate (PRT) (see fig. 60 and 61).

(6) Key data write

After a partition is generated in a storage unit of a device, storage processing of various keys is executed in the generated partition.

(7) Reading of public keys

(8) Issuing of public key certificates

When performing public key authentication in authentication processing when various services are provided to a partition (authentication processing when services such as partition generation, file access, and data update are provided), a device generates a key pair of a public key and a secret key, transmits the generated key to a partition manager, performs public key certificate issuance processing by a login mechanism and an authentication mechanism, and stores the issued public key certificate in a partition key area (see fig. 23). At this time, the issued public key certificate is stored in the storage area of the generated public key. The processes (7) and (8) can be executed when performing public key authentication in authentication processes when various services are provided to a partition (authentication processes when services such as partition creation, file access, and data update are provided).

According to the above processing, the partition generation processing can be executed in each of the modes of mutual authentication (common key) and certificate (PRT) verification (public key).

(D) Mutual authentication (shared key), certificate (PRT) verification (public key)

Next, data transfer between entities using the common key scheme and verifying the public key scheme for a certificate (PRT) in mutual authentication processing will be described with reference to fig. 71. Data transfer is performed between the entities in the order of the sequence numbers shown in the figure. Hereinafter, the processing will be described by each number.

(1) Distribution of a public key certificate (cert. DM) for a Device Manager (DM)

The public key certificate (cert.dm) is issued by a Certification Authority (CA) to a device manager through a registration authority in accordance with a certificate issuance procedure in response to an issuance request from the device manager.

(2) Issuing process of partition login certificate (PRT)

The partition registration certificate (PRT) is transmitted to the Partition Manager (PM) by a partition registration certificate issuing apparatus (PRT packet issue) managed by the device manager. In this case, in order to generate and verify a Signature by the public key method, a Signature (Signature) is generated by a secret key of the device manager (see fig. 12) and added to the PRT.

(3) Supply of PRT and DM public Key certificate (Cert. DM) to PM

The partition login certificate (PRT) issued by a partition login certificate issuing apparatus (PRT ticketsusher) managed by a device manager is transmitted to the partition manager together with a DM public key certificate (cert.dm).

(4) Mutual authentication between PM and device

A target device that wants to generate a partition from a transmitted PRT and a partition manager (specifically, a reader/writer as a device access apparatus that is a certificate user) perform mutual authentication by a shared key method (see fig. 50).

(5) Provisioning of PRT and DM public Key certificate (Cert. DM) to a device

When the PM and the device are authenticated with each other, the Partition Manager (PM) issues a partition registration certificate (PRT) and a DM public key certificate (cert.dm) to the device.

A Device that performs, on a received partition entry certificate (PRT), confirmation that (1) a public Key Certificate (CERT) of a certificate Issuer (Ticket Issuer) DM is a legitimate public Key Certificate (CERT) that is not falsified, (2) a Code recorded in an optional area of the public Key Certificate (CERT) of a certificate issuing apparatus (Ticket Issuer) coincides with a certificate issuing apparatus Code (PRTIC: PRT Issuer Code) recorded in DKDB (Device Key Definition Block (PUB)) in the Device, (3) the certificate issuing apparatus (Ticket) is not revoked, (4) a confirmation that the certificate has not been falsified according to a verification of a Signature (Signature) on a received certificate (PRT)), and further, confirms that a user as a PRT stored in the PRT certificate (PM in this case: a reader/writer as a device access apparatus) and whether or not the identifier, the class, or the Serial Number (SN) recorded in the identification Data (DN) of the certificate user matches the identifier, the class, or the Serial Number (SN) recorded in the received public key certificate of the partition manager as the identification Data (DN), and the authentication of the PRT user (PM: a reader/writer as a device access apparatus, etc.) (see fig. 57 and 58).

(6) Partition generation

When the verification of the partition registration certificate (PRT) and the verification of the PRT Issuer (PRT Issuer) and the PRT user are successful, the partition is generated in the storage unit of the device according to the rule recorded in the partition registration certificate (PRT) (see fig. 60 and 61).

(7) Key data write

After a partition is generated in a storage unit of a device, storage processing of various keys is executed in the generated partition.

(8) Reading of public keys

(9) Issuing of public key certificates

When performing public key authentication in authentication processing when various services are provided to a partition (authentication processing when services such as partition generation, file access, and data update are provided), a device generates a key pair of a public key and a secret key, transmits the generated key to a partition manager, performs public key certificate issuance processing by a login mechanism and an authentication mechanism, and stores the issued public key certificate in a partition key area (see fig. 23). At this time, the issued public key certificate is stored in the storage area of the generated public key. The processes (8) and (9) can be executed when performing public key authentication in authentication processes when various services are provided to a partition (authentication processes when services such as partition creation, file access, and data update are provided).

According to the above processing, the partition generation processing can be executed in each of the modes of mutual authentication (common key) and certificate (PRT) verification (public key).

[ B4.4. File creation and deletion processing Using File registration certificate (FRT) ]

Hereinafter, a process of generating or deleting a file using a file registration certificate (FRT) in a partition generated in a device will be described. This is explained with reference to fig. 72 and other flowcharts that follow. The File generation and deletion processes include mutual authentication (device authentication or partition authentication) between the device and a reader/writer (partition manager) as a device access apparatus, and validity check processing of a File Registration certificate (FRT).

The file creation and deletion processing flow shown in fig. 72 will be described. In fig. 72, the left side shows the processing of the file creating and deleting device of the partition manager, and the right side shows the processing of the device (see fig. 5). The file creating/deleting device of the partition manager is a device (for example, a reader/writer or a PC as a device access device) capable of performing data reading/writing processing on a device, and corresponds to the reader/writer as the device access device in fig. 10. First, an outline of the file generation and deletion process will be described with reference to fig. 72, and then, file generation and deletion operations included in the present process will be described in detail with reference to a flowchart of fig. 73.

First, in steps S801 and S810 of fig. 72, mutual authentication processing between the file generation/deletion apparatus and the device is performed. Between 2 devices that perform data transmission and reception, it is confirmed whether the other party is a legitimate data correspondent or not, and then necessary data transfer can be performed. The mutual authentication process is a process of mutually confirming whether the partner is a legitimate data communicator. The mutual authentication processing is performed by generating a session key and performing encryption processing using the generated session key as a common key, and then transmitting data.

In the mutual authentication process, the same process as described in the section of the partition creation/deletion process, that is, partition authentication, is executed. The authentication process is performed by either a common key authentication process or a public key authentication process. This mutual authentication processing is the same as the processing described above with reference to fig. 48 to 56, and therefore the description thereof will be omitted.

The process to be executed as the mutual authentication process is determined by 2 items of data in the file registration certificate (FRT) used (see fig. 27)

Authentication Flag: a flag indicating whether or not mutual authentication with the Device is required in the process of using the certificate (packet),

Authentication Type: the mutual authentication method (public key authentication, common key authentication, or both authentication methods (Any)) of the Device (Device).

If the authentication process fails (no in steps S802 and S811), the following process is not executed and the authentication process ends as an error, because it indicates that the devices and apparatuses cannot be verified as being legitimate.

When the authentication process is successful, the file generation and deletion apparatus issues a file Registration certificate (FRT) to the device. The file registration certificate (FRT) is a certificate issued by a file registration certificate (FRT) issuing apparatus (FRT issue) managed by the partition manager. The file registration certificate (FRT) is an access control certificate for the device, and has the data format structure of fig. 32 described above.

When a file registration certificate (FRT) is issued to a certificate user, if the system is a public key system, a public key certificate (CERT _ FRTI) of a file registration certificate (FRT) issuing apparatus (FRT issue) is also transmitted together. The Attribute (Attribute) of the public key certificate (CERT _ FRTI) of the FRT-issuing apparatus matches the identifier (FRTIC) of the file registration certificate (FRT) issuing apparatus (FRT issue).

The device that receives the file registration certificate (FRT) (S812) performs the validity and user verification processing of the received certificate (FRT) (S813). The certificate validity verification process is executed by either MAC verification based on a common key system or signature verification process based on a public key system. The user check is a process of checking the validity of the device (certificate user) that issued the certificate, and is executed after the mutual authentication is successful, as a process of checking whether or not the identification data of the authentication partner matches the certificate user identifier (see fig. 27) recorded in the certificate. These processes are the same as those described with reference to fig. 57 to 59 in the above description of the process of using the partition registration certificate (PRT), and therefore, the description thereof will be omitted.

In the device, when the validity of the received certificate (FRT) and the user verification process result indicates that the validity of the certificate and the user cannot be confirmed (no in S814), the file generation/deletion apparatus receives the file registration certificate (FRT) and notifies an error (S818). When the validity of the certificate and the user can be confirmed (yes in S814), file creation or deletion processing of the storage unit in the device is executed according to the rule described in the file registration certificate (FRT). This process will be described in detail later with another flowchart.

When the file generation or deletion process performed based on the description in the file registration certificate (FRT) has succeeded (yes in S816), the FRT reception success is notified to the file generation/deletion apparatus (S817). If the file generation or deletion process fails (no in S816), the FRT acceptance error is notified to the file generation or deletion apparatus (S818).

The file creating/deleting device receives the FRT reception result (S804), determines the FRT reception result, ends the process as an error if the FRT reception result is an error (no in S805), transmits and receives a session termination command if the FRT reception result is successful (yes in S805) (S806, S819), discards the authentication table generated on the device side (S820), and ends the process. The authentication table is a table generated in the mutual authentication processing in steps S801 and S810, and has the same configuration as that described in the item of the above-described processing for using the partition registration certificate (PRT), that is, the configuration shown in fig. 51.

As described above, the file generation or deletion process of the generated file is performed in the partition set in the device using the file registration certificate (FRT). Next, the file creation and deletion process (S815) included in this process will be described with reference to fig. 73.

(File creation and deletion processing)

The file generation and deletion process executed based on the file registration certificate (FRT) in step S815 shown in the flowchart of fig. 72 will be described in detail below with reference to the process flow of fig. 73. The file generation and deletion process is a process executed by a device that receives a file registration certificate (PRT) from a certificate user (for example, a reader/writer, a PC, or the like as a device access apparatus) based on the file registration certificate (FRT).

In step S821 of fig. 73, the processing method recorded in the received file registration certificate (FRT: FileRegistration packet), that is, the Operation Type (designation (generation)/deletion (deletion) of generation or deletion of a Partition) is checked.

First, the file generation process will be described. In step S822, the device checks whether or not a file having the same Identifier (ID) as the file Identifier (ID) described in the file registration certificate (FRT) exists in the partition to be processed of the device. This determination can be made by checking whether or not the same file ID as the file ID described in the reception certificate (FRT) is described in the file definition block (see fig. 24) of the partition area set in the storage unit of the device.

When a file having the same ID already exists in the device, since a duplicate file having the same ID is not allowed to exist in the same partition, the generation of the file cannot be performed and ends as an error. When no File having the same ID exists in the processing target Partition, in step S823, the Free Block Number in the Partition (Free Block Number in Partition) of the Partition management information Block (see fig. 20) is compared with the File Size (File Size) described in the File registration certificate (FRT), and it is determined whether or not a Free Block area larger than the File Size (File Size) described in the certificate (FRT) exists in the processing target Partition of the device. If not, the file of the size described in the FRT cannot be generated, and therefore, the generation ends as an error.

When it is determined that a Free block Area larger than the File Size (File Size) described in the certificate (FRT) exists in the processing target Partition of the storage unit of the device, the flow proceeds to step S824, where a File Definition Block (FDB) Area is secured in the highest block of the Free Area (Free Area in Partition) of the Partition by referring to the Pointer (Free Area) of the Free Area of the Partition management information block (see fig. 24).

Next, the device copies the File ID described in the File registration certificate (FRT) into the secured File Definition Block (FDB) Area (S825), and executes a process of copying the Pointer of Free Area (Pointer of Free Area) of the partition management information block (see fig. 20) to the File Start Position (File Start Position) of the File Definition Block (FDB) Area (S826).

Further, in step S827, the File Size (File Size), the service license issuing device Code (SPTIC), the Version (SPTIC Version), the File Structure Type Code (File Structure Type Code), the Authentication method (authorization Type) specified when the File access is performed, and the Verification method (authorization Type) specified are copied to the respective pieces of corresponding data described in the File registration certificate (FRT).

Then, in step S828, the Kspt _ Encrypted stored in the File registration certificate (FRT) (data Kfrt (Kspt)) obtained by encrypting the MAC verification key Kspt of the service license certificate (SPT) described in the File definition block (File DefinitionBlock) with the MAC verification key Kfrt of the File registration certificate of the partition is decrypted and stored in the File Definition Block (FDB). The MAC verification key Kfrt of the file registration certificate is already stored in the partition key area when the partition is generated.

Next, in step S829, the File Size (File Size) +1 is subtracted from the Free Block Number in Partition in the Partition (Partition) of the Partition management information Block (see fig. 20). +1 means a block used for a File Definition Block (FDB).

Next, in step S830, the generated File Size (File Size) is added to the Pointer (Pointer of Free Area) of the Free Area of the partition management information block (see fig. 20), and in step S831, the Number of files (File Number) of the partition management information block is added to 1, that is, the generated File (1) is added.

Next, in step S832, initialization processing is executed based on the FileStructure (Structure) of the generated File (File) stored in the File registration certificate (FRT). For example, a process of resetting to 0 if the file structure is a Random (Random) file, or resetting the pointer and data to 0 if the file structure is a Cyclic (Cyclic) file is performed. Through the above processing, a new file can be generated within the generated partition.

The file deletion processing in steps S841 to S848 of fig. 73 will be described below. In step S841, it is checked whether or not a file having the same ID as the file ID described in the file registration certificate (FRT) exists in the partition to be processed in the storage unit of the device. This determination can be made by checking whether or not the same file ID as that described in the reception certificate (FRT) is described in a file definition block (see fig. 24) in the storage unit of the device.

When a file having the same file ID does not exist in the processing target partition of the device, deletion of the file is not possible, and therefore the operation ends as an error. When a file having the same ID exists in the device partition to be processed, it is determined in step S842 whether or not a file generated after the file to be deleted exists in the partition to be processed. If not, the file to be deleted is the latest file, and thus the File Definition Block (FDB) (see fig. 24) of the file to be deleted is deleted in step S849.

When it is determined in step S842 that a file generated after the file to be deleted exists in the processing target partition, a process of shifting the data of the file to be generated (the subsequent file) to a lower level by the File Size (FS) corresponding to the deletion target is executed (S843), and a process of shifting the File Definition Block (FDB) of the subsequent file by 1 block to a higher level is further executed (S844). Further, a process of subtracting the size of the deleted File (FS) from the file start Position (FileStart Position) recorded in the File Definition Block (FDB) of the later is also performed (S845).

After the processing in step S845 or S849, in step S846, the deleted File Size (FS) +1 is added to the Free Block Number in Partition (Free Block Number in Partition) in the Partition of the Partition Management Information Block (PMIB) (see fig. 20). +1 means a block used to delete a File Definition Block (FDB) of a file.

Next, in step S847, the size (FS) of the delete file is subtracted from the value of the Pointer (point of Free Area) of the Free Area of the Partition Management Information Block (PMIB) (see fig. 20). Further, in step S848, the deleted File (1) is subtracted by 1 from the File Number (File Number) of the Partition Management Information Block (PMIB) (see fig. 20), and the File deletion process by the File registration certificate (FRT) is ended.

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

Fig. 74 shows an example of the in-memory data structure of the device in a state after completion of the file generation processing by the partition manager. In the Partition (Partition) area shown in fig. 74, the following data are written at the time of file generation or Partition generation.

File Definition Block (1-N) (File Definition Block)

Partition Key zone (Partition Key Area)

Partition Key information Block (Common) of shared Key system

Partition Key information Block (PUB) for public Key System

Partition Management Information Block (Partition Management Information Block)

The File Data Area (File Data Area 1-N) is secured as a File Area in the processing target partition by the File generation process.

[ B4.5. processing steps for various document creation processing methods ]

In the above-described file setting registration process, mutual authentication is performed between a reader/writer as a device access apparatus, which is a file registration certificate user managed by the partition manager, and a device, and a file is set based on a file registration certificate (FRT). The mutual authentication process is performed in any one of two ways, i.e., mutual public key authentication and mutual shared key authentication, and the verification process of the certificate (FRT) also performs any one of two ways, i.e., signature verification by public key system and MAC verification by shared key system. That is, the treatment forms can be roughly classified into the following 4 types.

(A) Mutual authentication (public key), certificate (FRT) verification (public key)

(B) Mutual authentication (public key), certificate (FRT) verification (shared key)

(C) Mutual authentication (shared key), certificate (FRT) verification (shared key)

(D) Mutual authentication (shared key), certificate (FRT) verification (public key)

The above 4 types of processes will be briefly described with reference to the drawings, centering on data transfer processing performed by a certification authority (ca), (PM), a Partition Manager (PM), a device, and each entity.

(A) Mutual authentication (public key), certificate (PRT) verification (public key)

First, data transfer between entities when the public key scheme is used for mutual authentication processing and the public key scheme is used for verification of certificates (FRT) will be described with reference to fig. 75.

Data transfer is performed between the entities in the order of the sequence numbers shown in the figure. Hereinafter, the processing will be described by each number.

(1) Transmission of public key certificate (cert. FRT) of file registration certificate issuing apparatus (FRT Issuer)

A public key certificate (Cert. FRT) of a file registration certificate issuing apparatus (FRT) is issued by a partition supporting Certification Authority (CA) (PAR) in accordance with a certificate issuing procedure by a Registration Authority (RA) in accordance with an issuing request from the file registration certificate issuing apparatus (FRT) in accordance with a certificate issuing procedure. In addition, the partition manager may also be configured to serve as a file registration certificate issuing apparatus (FRT Issuer), and in this case, the public key certificate of the Partition Manager (PM) may be used as the public key certificate of the file registration certificate issuing apparatus (FRT Issuer)

(2) Issuance of public key certificate (cert. fttuser) of file login certificate User (FRT User)

A public key certificate (cert. FRT User) of a file registration certificate User (FRT User, specifically, a reader/writer as a device access apparatus that issues a certificate to a device) is issued by a partition corresponding certification authority (ca (par)) in accordance with an issuance request from the file registration certificate User (FRTUser) through a Registration Authority (RA) in accordance with a certificate issuance procedure. In addition, the partition manager may also be configured to serve as a file registration certificate User (FRT User), and in this case, the public key certificate of the Partition Manager (PM) may be used as the public key certificate of the file registration certificate User (FRT User).

(3) Generation processing of file login certificate (FRT)

The file registration certificate (FRT) is generated by a file registration certificate issuing apparatus (FRT packet issue) managed by the partition manager. In this case, in order to generate and verify a Signature by the public key method, a Signature (Signature) is generated by a secret key of a file registration certificate issuing apparatus (FRT ticket issuer) (see fig. 12) and added to FRT.

(4) Supply of FRT and file registration certificate issuing apparatus (FRT Ticket Issuer) public key certificate (cert

A file login certificate (FRT) issued by a file login certificate issuing apparatus (FRT ticketing issue) managed by a partition manager is transmitted to a file login certificate User (FRT User), that is, an apparatus (for example, a reader/writer as an apparatus access apparatus) that issues a certificate to a device, together with a file login certificate issuing apparatus (FRTTicket issue) public key certificate (cert.

(5) Mutual authentication between a document registration certificate issuing apparatus and a device

The partition manager (specifically, a reader/writer as a device access device) issues a public key certificate (cert. FRT User) of a file registration certificate User (FRT User) to a device that wants to generate a file from the file registration certificate (FRT) issued by a file registration certificate issuing device (FRT User), thereby performing mutual authentication by a public key scheme (see fig. 50).

(6) Supply of FRT and file registration certificate issuing apparatus (FRT Ticket Issuer) public key certificate (cert

When mutual authentication between the Partition Manager (PM) and the device is established, the Partition Manager (PM) (specifically, a file login certificate User (FRT User), that is, a reader/writer as a device access apparatus) issues a file login certificate (FRT) and a file login certificate Issuer (FRT packet Issuer) public key certificate (cert.

The device confirms that (1) a public key certificate (CERT certificate) of a certificate Issuer (packet Issuer) is a legitimate public key Certificate (CERT) that has not been tampered, (2) a code recorded in an optional area of the public key certificate (CERT FRT Issuer) of a certificate Issuer (packet Issuer) is identical to a certificate Issuer code (FRT: FRT Issuer code) recorded in a pkdb (partition key definition block (pub) of the device, (3) the certificate Issuer (packet Issuer) is not revoked, and (4) a verification certificate that has not been tampered with a Signature (Signature)) of a received certificate (FRT) is stored in the FRT certificate, and confirms that a read/write identifier (DN) recorded as identification Data (DN) of a FRT user (user, i.e., a device that is an access device of the device) stored in the FRT certificate is not tampered with the certificate, The category or the Serial Number (SN), the identification name (DN), and the identifier, the category or the Serial Number (SN), and the identification name (DN) recorded as the identification Data (DN) in the public key certificate (cert. FRT User) of the certificate User (FRT User) are identical with each other, and the FRT User (a reader/writer as a device access apparatus, etc.) is checked by confirming the completion of the mutual authentication (see fig. 57 and 58).

(7) Registering SPTIC and Kspt in FDB

The device registers a service license (SPT) user (SPTIC) (e.g., a reader/writer as a device access device that accesses data in a File of the device) and Kspt (a key (Kspt) for MAC verification of the service license (SPT)) in a File Definition Block (FDB: File Definition Block) (see steps S827 and S828 in the flow of fig. 73).

(8) Securing file data regions

The device secures a file area having a size described in a file registration certificate (FRT) in the partition to be processed.

According to the above processing, the file generation processing can be performed in each mode of mutual authentication (public key) and certificate (FRT) verification (public key).

(B) Mutual authentication (public key), certificate (PRT) verification (shared key)

Hereinafter, data transfer between entities using a public key method for mutual authentication processing and a common key method for certificate (FRT) verification will be described with reference to fig. 76.

Data transfer is performed between the entities in the order of the sequence numbers shown in the figure. Hereinafter, the processing will be described by each number.

(1) Issuance of public key certificate (cert. fttuser) of file login certificate User (FRT User)

A public key certificate (cert. FRT User) of a file registration certificate User (FRT User, specifically, a reader/writer as a device access apparatus that issues a certificate to a device) is issued by a partition corresponding certification authority (ca (par)) in accordance with an issuance request from the file registration certificate User (FRTUser) through a Registration Authority (RA) in accordance with a certificate issuance procedure. In addition, the partition manager may also be configured to serve as a file registration certificate User (FRT User), and in this case, the public key certificate of the Partition Manager (PM) may be used as the public key certificate of the file registration certificate User (FRT User).

(2) Generation processing of file login certificate (FRT)

The file registration certificate (FRT) is generated by a file registration certificate issuing apparatus (FRT packet issue) managed by the partition manager. In this case, mac (message authentication code) (see fig. 59) is added to FRT as a check value of the common key scheme.

(3) Supply of file login credentials users (FRT users) by FRT

A file registration certificate (FRT) issued by a file registration certificate issuing apparatus (FRT ticketsusher) managed by a partition manager is issued to a file registration certificate user (FRTUser), that is, an apparatus that issues a certificate to a device (for example, a reader/writer as a device access apparatus).

(4) Mutual authentication between a document registration certificate issuing apparatus and a device

The partition manager (specifically, a reader/writer as a device access device) issues a public key certificate (cert. FRT User) of a file registration certificate User (FRT User) to a device that wants to generate a file from the file registration certificate (FRT) issued by a file registration certificate issuing device (FRT User), thereby performing mutual authentication by a public key scheme (see fig. 50).

(5) Supply of FRT to equipment

When mutual authentication between the Partition Manager (PM) and the device is established, the Partition Manager (PM) (specifically, a file registration certificate User (FRT User), that is, a reader/writer as a device access apparatus) issues a file registration certificate (FRT) to the device. The device executes MAC verification processing on the received file registration certificate (FRT), verifies the verification of the FRT issuer (FRT), further verifies whether or not the identifier, the class or the Serial Number (SN), and the identification name (DN) recorded as the identification Data (DN) of the FRT user (i.e., the certificate user, i.e., the reader/writer as the device access apparatus, etc.) stored in the FRT certificate and the identifier, the class or the Serial Number (SN) recorded as the identification Data (DN) in the received public key certificate of the partition manager coincide with each other, and executes verification of the FRT user (PM: the reader/writer as the device access apparatus, etc.) by confirming the completion of mutual authentication (see fig. 57 and 58).

(6) Registering SPTIC and Kspt in FDB

The device registers a service license (SPT) issuer type (SPTIC) (for example, a reader/writer as a device access device that accesses data in a File of the device) and Kspt (a key (Kspt) for MAC verification of the service license (SPT)) in a File Definition Block (FDB) (see steps S827 and S828 in the flow of fig. 73).

(7) Securing file data regions

The device secures a file area having a size described in a file registration certificate (FRT) in the partition to be processed.

According to the above processing, the file generation processing can be performed in each mode of mutual authentication (public key) and certificate (FRT) verification (common key).

(C) Mutual authentication (shared key), certificate (FRT) verification (shared key)

Hereinafter, data transfer between entities using the common key scheme for mutual authentication processing and verifying the use of the common key scheme for certificate (FRT) will be described with reference to fig. 77.

Data transfer is performed between the entities in the order of the sequence numbers shown in the figure. Hereinafter, the processing will be described by each number.

(1) Generation processing of file login certificate (FRT)

The file registration certificate (FRT) is generated by a file registration certificate issuing apparatus (FRT packet issue) managed by the partition manager. In this case, mac (message authentication code) (see fig. 59) is added to FRT as a check value of the common key scheme.

(2) Supply of file login credentials users (FRT users) by FRT

A file registration certificate (FRT) issued by a file registration certificate issuing apparatus (FRT ticketsusher) managed by a partition manager is issued to a file registration certificate user (FRTUser), that is, an apparatus that issues a certificate to a device (for example, a reader/writer as a device access apparatus).

(3) Mutual authentication between a document registration certificate issuing apparatus and a device

The partition manager (specifically, a reader/writer as a device access device, which is a file registration certificate User (FRT User)) and a device which wants to generate a file from a file registration certificate (FRT) issued by a file registration certificate issuing device (FRTTicket issue) execute mutual authentication of a common key scheme (see fig. 53 and 54).

(4) Supply of FRT to equipment

When mutual authentication between the Partition Manager (PM) and the device is established, the Partition Manager (PM) (specifically, a file registration certificate User (FRT User), that is, a reader/writer as a device access apparatus) issues a file registration certificate (FRT) to the device. The device executes MAC verification processing on the received file registration certificate (FRT), verifies the FRT issuer (PRTIssuer), further verifies whether or not the identifier of the FRT user (i.e., the certificate user, i.e., the reader/writer as the device access apparatus, etc.) stored in the FRT certificate matches the identifier of the partition manager, and verifies the FRT user (PM: the reader/writer as the device access apparatus, etc.) by confirming the completion of mutual authentication (see fig. 57 and 58).

(5) Registering SPTIC and Kspt in FDB

The device registers a service license (SPT) issuer type (SPTIC) (for example, a reader/writer as a device access device that accesses data in a File of the device) and Kspt (a key (Kspt) for MAC verification of the service license (SPT)) in a File Definition Block (FDB) (see steps S827 and S828 in the flow of fig. 73).

(6) Securing file data regions

The device secures a file area having a size described in a file registration certificate (FRT) in the partition to be processed.

According to the above processing, the file generation processing can be executed in each mode of mutual authentication (common key) and certificate (FRT) verification (common key).

(D) Mutual authentication (shared key), certificate (FRT) verification (public key)

Hereinafter, data transfer between entities using the common key scheme and the public key scheme for certificate (FRT) verification for mutual authentication processing will be described with reference to fig. 78.

Data transfer is performed between the entities in the order of the sequence numbers shown in the figure. Hereinafter, the processing will be described by each number.

(1) Issuance of public key certificate (cert. FRT) of file registration certificate issuing apparatus (FRT Issuer)

A public key certificate (Cert. FRT) of a file registration certificate issuing apparatus (FRT) is issued by a partition supporting Certification Authority (CA) (PAR) in accordance with a certificate issuing procedure by a Registration Authority (RA) in accordance with an issuing request from the file registration certificate issuing apparatus (FRT) in accordance with a certificate issuing procedure. In addition, the partition manager may also be configured to serve as a file registration certificate issuing apparatus (FRT Issuer), and in this case, the public key certificate of the Partition Manager (PM) may be used as the public key certificate of the file registration certificate issuing apparatus (FRT Issuer)

(2) Generation processing of file login certificate (FRT)

The file registration certificate (FRT) is generated by a file registration certificate issuing apparatus (FRT packet issue) managed by the partition manager. In this case, in order to generate and verify a Signature by the public key method, a Signature (Signature) is generated by a secret key of a file registration certificate issuing apparatus (FRT ticket issuer) (see fig. 12) and added to FRT.

(3) Supply of FRT and file registration certificate issuing apparatus (FRT Ticket Issuer) public key certificate (cert

A file login certificate (FRT) issued by a file login certificate issuing apparatus (FRT ticketing issue) managed by a partition manager is issued to a file login certificate User (FRT User), that is, an apparatus (for example, a reader/writer as an apparatus access apparatus) that issues a certificate to a device, together with a file login certificate issuing apparatus (FRTTicket issue) public key certificate (cert.

(4) Mutual authentication between a document registration certificate issuing apparatus and a device

The partition manager (specifically, a reader/writer as a device access device, which is a file registration certificate User (FRT User)) and a device which wants to generate a file from a file registration certificate (FRT) issued by a file registration certificate issuing device (FRTTicket issue) execute mutual authentication of a common key scheme (see fig. 53 and 54).

(5) Supply of FRT and file registration certificate issuing apparatus (FRT Ticket Issuer) public key certificate (cert

When mutual authentication between the Partition Manager (PM) and the device is established, the Partition Manager (PM) (specifically, a file login certificate User (FRT User), that is, a reader/writer as a device access apparatus) issues a file login certificate (FRT) and a file login certificate Issuer (FRT packet Issuer) public key certificate (cert.

A device that performs, on a received file registration certificate (FRT), confirmation that (1) a public key certificate (CERT certificate) of a certificate Issuer (packet Issuer) is a legitimate public key Certificate (CERT) that has not been tampered, (2) a code recorded in an optional area of a public key certificate (CERT certificate) of a certificate Issuer (packet Issuer) is identical with a certificate Issuer code (frtc: FRT certificate) recorded in a pkdb (part key definition block) (pub) in the device, (3) the certificate Issuer (packet Issuer) is not revoked, (4) a verification confirmation that a certificate is not tampered according to a Signature (Signature) on the received certificate (FRT)), and further confirms that an identifier of a FRT User (i.e., a device that is an access device of the device) stored in the FRT certificate is identical with a read-write identifier of the FRT User (reader-writer) of the FRT certificate, and checks the FRT user (reader/writer as a device access apparatus, etc.) by confirming the completion of the mutual authentication (see fig. 57 and 58).

(6) Registering SPTIC and Kspt in FDB

The device registers a service license (SPT) issuer type (SPTIC) (for example, a reader/writer as a device access device that accesses data in a File of the device) and Kspt (a key (Kspt) for MAC verification of the service license (SPT)) in a File Definition Block (FDB) (see steps S827 and S828 in the flow of fig. 73).

(7) Securing file data regions

The device secures a file area having a size described in a file registration certificate (FRT) in the partition to be processed.

According to the above processing, the file generation processing can be executed in each mode of mutual authentication (common key) and certificate (FRT) verification (public key).

[ B4.6. service (File Access) processing Using service license certificate (SPT) ]

The following describes file access processing using a service license certificate (SPT) (see fig. 28 and 31)

This is explained with reference to fig. 79 and other flowcharts that follow. The file access process includes a mutual authentication process (device authentication or partition authentication) between the device and the file access apparatus, and a validity check process of a Service Permission certificate (SPT).

In the flowchart 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). The file access device is a management device of the partition manager, and is a device (for example, a reader/writer or a PC as a device access device) capable of performing data reading/writing processing on a device, and corresponds to the reader/writer as the device access device of fig. 10. First, an outline of the file access processing of the file access device will be described with reference to fig. 79, and then, the respective processes included in the present processing will be described in detail in order with reference to the flowchart of fig. 80.

First, in steps S851 and S860 of fig. 79, a mutual authentication process between the file access apparatus and the device is performed. Between 2 devices that perform data transmission and reception, it is confirmed whether the other party is a legitimate data correspondent or not, and then necessary data transfer can be performed. The mutual authentication process is a process of mutually confirming whether the partner is a legitimate data communicator. The mutual authentication processing is performed by generating a session key and performing encryption processing using the generated session key as a common key, and then transmitting data.

In the mutual authentication process, the same process as described in the section of the partition creation/deletion process, that is, partition authentication, is executed. The authentication process is performed by either a common key authentication process or a public key authentication process. This mutual authentication processing is the same as the processing described above with reference to fig. 48 to 56, and therefore the description thereof will be omitted.

The process to be executed as the mutual authentication process is determined by 2 items of data in the service license credential (SPT) to be used (see fig. 28 and 31)

Authentication Flag: a flag indicating whether or not mutual authentication with the Device is required in the process of using the certificate (packet),

Authentication Type: the mutual authentication method (public key authentication, common key authentication, or both authentication methods (Any)) of the Device (Device).

If the authentication process fails (no in S852 and S861), since it indicates that the devices and apparatuses are not verified to be legitimate, the following process is not executed, and the process ends as an error.

The device may permit file access processing in a plurality of different partitions based on a plurality of service license certificates (SPTs). For example, file access is permitted in a plurality of different partitions according to a plurality of service license certificates (SPTs) on condition of device authentication. The file access rule for each partition is described in a service license certificate (SPT) constituting access control data, and the device receives a plurality of service license certificates (SPT) from the access device, and when each certificate requests device authentication, permits file access in each partition only on the condition that successful device authentication is performed according to the described rule.

When different authentication conditions are set for each of the plurality of service licenses (SPTs), the device permits access to a file designated by the plurality of service licenses (SPTs) only if partition authentication set for each service license (SPT) is successfully authenticated.

Next, in step S853, the file access device issues a Service Permission certificate (SPT) to the device. The service license certificate (SPT) is a certificate issued by an issuing apparatus (SPT issue) of the service license certificate (SPT) managed by the partition manager. The service license certificate (SPT) is an access control certificate for the certificate user, and has the data format structure of fig. 28 and 31 described above.

When the service license certificate (SPT) is issued to the certificate user, if the public key method is used, the public key certificate (CERT _ SPTI) of the service license certificate (SPT Issuer) is also issued together. The Attribute (Attribute) of the public key certificate (CERT _ SPTI) of the SPT issuing apparatus coincides with the identifier (SPTIC) of the issuing apparatus (SPT issue) of the service license certificate (SPT).

The device that received the service license certificate (SPT) (S862) performs the process of verifying the validity and user of the received certificate (SPT) (S863). The certificate validity verification process is executed by either MAC verification based on a common key system or signature verification process based on a public key system. The user verification is a process of verifying the legitimacy of the device (certificate user) that issued the certificate, and is executed after the mutual authentication is successful, as a process of verifying whether or not the identification data of the authentication partner matches the certificate user identifier (see fig. 28 and 27) recorded in the certificate. These processes are the same as those described with reference to fig. 57 to 59 in the above description of the process of using the partition registration certificate (PRT), and therefore, the description thereof will be omitted.

When the validity of the received certificate (SPT) and the validity of the user cannot be confirmed as a result of the user check processing (no in S864), the device notifies the file access device of an error in reception of the service license certificate (SPT) (S868). When the validity of the certificate and the user can be confirmed (yes in S864), the file opening process stored in the storage unit of the device is executed according to the rule described in the service license certificate (SPT). This process will be described in detail later with another flowchart.

When the file opening process performed based on the description in the service license certificate (SPT) has succeeded (yes in S866), the file access device is notified of the SPT acceptance success (S867). On the other hand, if the file opening process fails (no in S866), the file access apparatus is notified of the SPT acceptance error (S868).

The file access device receives the SPT reception result (S854), determines the SPT reception result, ends the process as an error if the SPT reception result is an error (no in S855), determines whether to end transmission of all SPTs if the SPT reception result is successful (yes in S855), and repeatedly executes step S853 and subsequent steps if there are any unsent SPTs.

When the transmission of all SPTs is completed, file access is performed based on the service license certificate (SPT) in steps 857 and S869, and after the file access is completed, transmission and reception of a session termination command is performed (S858 and S870), the authentication table generated on the device side is discarded (S871), and the process is terminated. The file access processing will be described in detail later with another flowchart. The authentication table is generated in the mutual authentication processing in steps S851 and S860, and has the same configuration as that described in the item of the use processing of the partition registration certificate (PRT), that is, the configuration of fig. 51.

As described above, access processing to a file is performed within a partition set in a device using a service license certificate (SPT). The following describes the file opening process (S865) and various file access processes (S857 and S869) included in the present process.

(File opening processing)

The file opening process (fig. 79, S865) is described according to the flowchart of fig. 80. The file opening process is a process performed by the device according to the received service license certificate (SPT).

In step S881, the device determines whether or not a file specified in the received service license certificate (SPT) is generated and exists within the device. The service license (SPT) stores the file ID of the processing target file (see fig. 28 and 31), and for example, the presence or absence of a file having the same ID can be determined by referring to the file definition block (fig. 24). If there is no file having the same ID as that described in the certificate, the file cannot be processed, and therefore the processing ends as an error.

When there is a file having the same ID as that described in the certificate, in step S882, an item that associates the certificate issuing apparatus (PMC (Partition Manager Code)) described in the service license certificate (SPT) with the file ID described in the service license certificate (SPT) is written in the file opening table.

Further, in step S883, a File Access Mode [ File Access Mode: in the process of writing the Access Mode (Access Mode) of the File (File) permitted to Access into the File open table in association with the created entry, in step S884, a process of storing the Access permitted Group File [ Group of Target File: in the process of writing the Group (Group) ] of the File (File) to which access is permitted, in step S885, the access-permitted File identifier [ Target File ID: in the process of writing the Identifier (ID) ] of the File (File) to which access is permitted, in step S886, the process form data [ Read/Write Permission: the processing for the access-permitted File (Target File) is not limited to Read (Read) and Write (Write), and various types of processing may be set.

Fig. 81 and 82 show an example of the configuration of the file open table. The file opening table is a table in which information such as files and access modes in the access processing state in the device is recorded, and description information of the service license certificate (SPT) received by the device is recorded and stored in the storage device of the device.

When the certificate is a service license certificate (see fig. 28) of a format that allows only access to a unique file, the file open table stores the following information.

Ticket issue: identifier of certificate issuing apparatus (Ticket issue)

File ID: access File (File) identifier within a partition

File Access Mode: access mode (Access mode) for files (File) that are allowed to be accessed

Fig. 81 shows an example of the configuration of the file open table at this time.

As shown in fig. 81, in the file open table, as grouping information, namely, packet issue: since the identifier of the certificate Issuer (packet Issuer) describes the Partition Manager Code (PMC), it is possible to distinguish the partition, identify the file from the file ID, and determine the executable access mode (for example, Read (Read), Write (Write), encryption/decryption (Enc, Dec)) from the file access pattern.

In addition, when the service license (SPT) is in the form of a service license (see fig. 31) that allows access to a plurality of files among the files set in the partition, the following pieces of information are written in the table in addition to the above pieces of information.

Group of Target File: group of files (File) allowed to be accessed

Target File ID: identifier (ID) of File (File) allowed to be accessed

Read/Write Permission: processing mode (Read permission and Write (Write)) of File (Target File) permitted to access

Fig. 82 shows an example of the configuration of the file open table at this time.

As shown in fig. 82, in the File opening table set in association with the service license in the form of allowing access to a plurality of files, in addition to the data shown in fig. 81, a Partition Manager Code (PMC) which is partition identification data of a File (File) group allowing access, a File ID which is an Identifier (ID) of the File (File) allowing access, and [ Read/Write Permission ] data indicating a processing mode to the Target File (Target File) are stored, and thus it is possible to determine processing executable to the plurality of files.

The process of accessing a plurality of files may be, for example, a process of encrypting data stored in the file B with a key stored in the file a. For this reason, file B must allow the read request of file a. In this case, the file B is referred to as a source file, and the allowed counterpart file is referred to as a destination file.

As described above, the device generates a file open table in which the Partition Manager Code (PMC) as a certificate issuing apparatus (packet issue (PMC)), the file identifier as identification data of a file on which the file open process is performed, and the access pattern described in the service permission certificate (SPT) are associated with each other, based on the service permission certificate (SPT) received in the session with the access apparatus, and can determine whether or not the command received from the access apparatus can be executed by referring to the file open table.

(File Access processing)

The file access processing executed in steps S857 and S869 in fig. 79 will be described in detail below.

First, an access process in generating the file open table shown in fig. 81 will be described with reference to fig. 83. The left side of the figure shows 2 file access means (R/W: reader/writer as device access means) 750, 760, and the right side shows the partition part of the device 100 after file generation.

A file access device (R/W: reader/writer) 750 for issuing a certificate to the device 100 after mutual authentication with the device

File ID: [0x0002]

File access mode: [ reading: read)

And assuming that the certificate validity check, the certificate issuer and the user check have been successfully performed.

At this time, the device creates an entry in line 2 of the file open table shown in fig. 81. This entry, representing that an access pattern can be executed for file ID [0x0002] within the partition identified by the partition manager code (PMC 1): [ reading: read ].

In this case, the file access device (R/W: reader/writer) 750 generates a command and transmits the command to the apparatus. When the device receives a data read command such as file ID [0x0002 ]: ReadCommand (0x0002), the device confirms the entry of the file open table, and confirms that the access mode [ read: read ], and performs a Read process.

In addition, when the file access means (R/W: reader/writer) 750 transmits a data write command such as a file ID [0x0002] to the device: the data encryption processing Command of Write Command (0x0002), or file ID [0x0001 ]: when Encryption Command (0x0001), the device that receives the Command confirms the entry of the file open table and confirms that the service license certificate (SPT) received from the file access apparatus (R/W: reader/writer) 750 does not permit execution of [ write: write ] processing and [ encryption processing ] for the file ID [0x0001], thus stopping the processing.

The file access device (R/W: reader/writer) 760 has a function of issuing a certificate to the device 100 after mutual authentication with the device

File ID: [0x0001]

File access mode: [ encryption/decryption processing: enc & Dec ]

And assuming that the certificate validity check, the certificate issuer and the user check have been successfully performed.

At this time, the device creates an entry in line 1 of the file open table shown in fig. 81. This entry, representing that an access pattern can be performed on file ID [0x0001] within the partition identified by the partition manager code (PMC 1): [ encryption/decryption processing: enc & Dec ].

In this case, the file access device (R/W: reader/writer) 760 generates a command and transmits the command to the apparatus. When the device receives an Encryption Command [ Encryption Command (0x0001) ] such as a file ID [0x0001], the device confirms the entry of the file open table and confirms that the file ID: 0x0001 executes access mode [ encryption/decryption process: enc & Dec ], and performs an encryption process.

In addition, when the file access device (R/W: reader/writer) 760 sends a data read command such as a file ID [0x0002] to the apparatus: when Read Command (0x0002), the device that receives the Command confirms the entry of the file open table and confirms that the service license certificate (SPT) received from the file access apparatus (R/W: reader/writer) 760 does not allow [ Read: read ] process, thus stopping the process.

As described above, the device generates the file open table according to the processing flow of fig. 80 based on the service license (SPT) received from the service license user, that is, the reader/writer as the device access apparatus, determines whether or not to execute various commands from the reader/writer as the device access apparatus based on the generated file open table, and executes the processing based on the determination result.

Hereinafter, an access process when processing is performed on 2 files will be described with reference to fig. 84. The left side of the figure shows 2 file access means (R/W: reader/writer) 770, 780, and the right side shows the partition part of the apparatus 100 after file generation.

First, an example of processing performed using a service license certificate (SPT) in which a target file is specified (see fig. 31) will be described.

A file access device (R/W: reader/writer) 770, which, after mutual authentication with the device, issues a file having the function of issuing a file to the device 100

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 modality: [ reading: read)

And assuming that the certificate validity check, the certificate issuer and the user check have been successfully performed.

At this time, the device creates an entry of the file open table shown in fig. 82. This entry indicates that the file ID [0x0001] in the partition identified by the partition manager code (PMC1) is a key file, and the key file can be encrypted and decrypted after being opened. The File ID [0x0002] is a data File, and since the File Access Mode (File Access Mode) column is blank, it cannot be read from the outside, and the purpose of opening and setting the File Access Mode as an entry in the File open table is to enable [ read from File ID [0x0001 ]: and Read ].

In this case, the file access device (R/W: reader/writer) 770 generates a command and transmits, for example, a command to read the file ID [0x0002] and to internally encrypt with the file ID [0x0001 ]: internal Encryption Command (0x0001, 0x0002), the device receives the Command, checks the entry of the file open table, and determines that [ read of [ Encryption processing ] for the target file group [ PMC1], target file ID [0x0001] can be executed for the file ID [0x0002 ]: read ], then, the data of the file ID [0x0002] is Read, encrypted with the key of the file ID [0x0001], and transmitted to the access device.

According to the processing using the service license certificate (SPT) (see fig. 31) specifying the target file, since data obtained by encrypting data read from one file with the encryption key stored in the other file can be acquired, there is no risk that the decrypted data will leak to the outside.

The following describes processing performed when a plurality of service licenses (SPTs) (see fig. 28) are used, each of which designates processing for a unique file, instead of the service license (SPT) (see fig. 31) designating a target file.

A file access device (R/W: reader/writer) 780 which, after mutual authentication with the device, issues a file having the device 100

As SPT Format 1

File ID: [0x0002]

File access mode: [ reading: read)

As SPT format 2

File ID: [0x0001]

File access mode: [ encryption/decryption processing: enc & Dec ]

And assuming that the certificate validity check, the certificate issuer and the user check have been successfully performed.

At this time, the device creates the items on the 1 st and 2 nd lines of the file shown in fig. 81. This entry indicates that the file access mode [ encryption/decryption processing: enc & Dec ], and may compare the file ID within the partition identified by the partition manager code (PMC 1): 0x0002 executes file access mode [ read: read ].

In this case, the file access device (R/W: reader/writer) 780 generates a command and transmits it to the apparatus. First, when the device receives a data read command for file ID [0x0002 ]: read Command (0x0002), the device confirms the entry of the file open table, and confirms that the file ID: 0x0002 performs access mode [ read: read ], and after the Read processing is executed, the Read data is transmitted to the file access device.

Then, the file access device (R/W: reader/writer) 780 further generates a command and transmits the command to the device. When the device receives the usage file ID: when Data (Data) of [0x0001] encrypts a Command [ encryption Command (0x0001, Data) ], the device confirms the entry of the file open table and confirms that the file ID: [0x0001] performs [ encryption/decryption processing: enc & Dec ], and transmits encrypted Data [ Encryption Data ] to the file access device (R/W: reader/writer) 780 after performing the Encryption process.

As described above, when not the service license (SPT) specifying the target file (see fig. 31) but a plurality of service licenses (SPTs) specifying processing for a unique file (see fig. 28) are used, it is possible to perform read processing for object data to be encrypted and increase the number of data transfer processing between the file access device 780 and the device. In addition, the data may be read out of the device without encryption.

On the other hand, in the case where a plurality of file identifiers for identifying a plurality of data files to be accessed are included in the service license ticket (SPT) (see fig. 31), one of the file identifiers may be set as a destination file identifier and the license data for reading or writing to the destination file may be stored, and the encryption process using the encryption key stored in the data file may be set as the access pattern of another data file, and when such a configuration is adopted, the memory mounted device may receive the service license ticket (SPT) from the access device, and may execute the process of reading the destination file and encrypting the destination file with the encryption key in accordance with the specified access pattern, thereby executing the internal encryption process in the memory mounted device. In addition, data can be prevented from flowing out of the device in an unencrypted form.

A certificate issuing apparatus for issuing service license certificates (SPTs) under the management of a partition manager, which is an entity managing a storage area of a memory-mounted device, is configured to individually issue service license certificates (SPTs) in which various access modes are set for respective access apparatuses, thereby enabling access of different types to be performed for the respective access apparatuses.

(usage form of session key)

Data to be transmitted and received between the file access device and the device is often data that must be prevented from being leaked to the outside, such as user information and money amount information of the device. Therefore, it is preferable that the data transmitted and received between the file access device and the device is encrypted and added with a MAC (Message Authentication Code) as a tamper check value.

For encryption of data, a session key generated when mutual authentication processing is performed between the file access apparatus and the device may be used. As described above, the mutual authentication includes device authentication for a device and partition authentication, which is authentication for each partition. In the case of performing access to a file that has been generated in a partition, there are several options as to which key is used as an encryption key used in data transfer.

For example, as shown in fig. 85, between the device 100 and the access apparatus 800, there are some cases where a session key Kses1 generated by device authentication, a session key Kses2 generated by partition authentication of a partition corresponding to a partition manager code (PMC1), and a session key Kses3 generated by partition authentication of a partition corresponding to a partition manager code (PMC 2).

These keys are stored in an authentication table (see fig. 51 and 52) generated at the time of mutual authentication before the session is terminated.

The device and the reader/writer (PC and other devices) as a device access device that performs communication with the device determine in advance which of the plurality of session keys is used to perform encrypted communication as a rule, and use the session key according to the determined rule.

When file access in a plurality of different partitions is permitted on the condition that all of partition authentication and device authentication, which are authentication conditions set in association with the plurality of different partitions, are successfully authenticated, a unique integrated session key is generated from a plurality of session keys acquired as a result of a plurality of authentication processes, and an encryption process of communication data with an access device is executed based on the integrated session key.

One method as the integrated session key generation method is to perform an exclusive or operation (for example, 8-byte processing) of the plurality of session keys Kses1 to KsesN when the session keys Kses1 to KsesN are generated by mutual authentication processing between the device and a reader/writer (PC and other devices) as a device access apparatus that performs communication with the device, and to use the operation result as a session key for encryption of communication data. That is, Kses calculated by the following operation is used as the session key.

Kses＝Kses1 XOR Kses2 XOR Kses3...

XOR: XOR operation processing (e.g., 8-byte processing)

A rule for performing an exclusive or operation on a session key stored in authentication tables of both parties and using an output value thereof as a session key is determined between a device and a reader/writer (PC and other devices) as a device access device that performs communication with the device, and the session key is calculated from the rule and used for encryption of communication data. Similarly, the MAC value may be added to the communication data during the session by using another session key shared simultaneously with the mutual authentication, for example, a session key generated at the time of public key authentication, or session key generation data such as 64 bits of the lower order of the Y coordinate. By transmitting this MAC value together with the communication data and performing MAC verification processing on the receiving side, data falsification on the communication line can be prevented. The MAC generation and verification process can be referred to fig. 59 described above.

Alternatively, a rule may be set in which one key (for example, the latest session key) is selected from among the plurality of session keys Kses1 to KsesN obtained through mutual authentication processing between the device and a reader/writer (PC and other devices) as a device access device that performs communication with the device, and the selected session key is used as a data encryption key in subsequent communication processing, thereby configuring the selected session key according to the rule and using the selected session key for encryption of communication data.

The above-described calculation and selection processing based on the operation of the plurality of session keys can be applied not only to encrypted communication between the file access device and the device but also to encrypted communication processing between all certificate (PRT, FRT, SPT, DUT) users (devices that perform data communication with the device, such as a reader/writer as a device access device) and the device when the plurality of session keys are generated by mutual authentication. As for the session key used for calculation or selection from a plurality of session keys between each certificate user and the device according to what kind of rule each other, there may be adopted a method in which a rule is made in advance and then executed after mutually confirming the rule, or the rule is recorded in each certificate.

Hereinafter, a representative example of the procedure of the access processing (steps S857 and 869 in the processing flow of fig. 79) to the device by the file access apparatus will be described with reference to fig. 86 and 87.

The processing (normal) when access is performed only to 1 file will be described with reference to fig. 86, and the processing (composition) when access is performed to a plurality of files will be described with reference to fig. 87.

First, the processing (normal) in the case of performing access to only 1 file in fig. 86 is explained. 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 data is transferred between the file access device and the device, the encryption is performed using the session key Kses acquired in the mutual authentication process or the session key calculated or selected from the plurality of session keys, and the generation and verification process of the MAC for tamper check is executed.

The file access device, in step S891, transmits an access command to the device. This command specifies the file ID and access mode of the access target, and is, for example, a data read command of file ID [0x0002] described above with reference to fig. 83: read Command (0x0002), or Encryption Command [ Encryption Command (0x0001) ] of file ID [0x0001], and the like.

Upon receiving a command from the file access device (S901), the device determines whether or not the file ID and the access mode included in the command are recorded as permitted items in the file open table (S902). If the file ID and the access mode entry corresponding to the command do not exist in the file open table, the processing required by the command is not executed, and an access error is transmitted to the file access device (S908).

When the File ID and the access mode entry corresponding to the command are already present in the File open table, in step S903, the authentication Type (authentication Type specified when accessing a specific File) recorded in the File Definition Block (FDB) (see fig. 24) of the corresponding partition in the memory of the device is referred to, and the authentication level (whether public key authentication is required) required for executing the access command to the access target File is checked.

When it is confirmed in step S903 that the file access Authentication Type (Acceptable Authentication Type) of the File Definition Block (FDB) is set to require public key Authentication, it is determined in step S904 whether public key Authentication, which is Authentication of an Authentication level required for an access command, has been completed, and if Authentication has not been completed, the processing required by the command is not executed, and an access error is transmitted to the file access device (S908). The authentication is completed or not completed, and the authentication is determined from an authentication table (see fig. 51) set at the time of mutual authentication.

When it is confirmed in step S903 that the public key Authentication is required and the public key Authentication is completed in step S904, or when the File access Authentication method (accessible Authentication Type) of the File Definition Block (FDB) is set to be unnecessary, then, in step S905, the Verification level required for executing the access command to the access target File (whether the Verification of the public key method is required) is confirmed by referring to the File access Verification method (accessible Verification Type: the Verification method specified when the access to the specific File (File) is performed) recorded in the File Definition Block (FDB) of the corresponding partition in the memory of the device (see fig. 24).

When it is confirmed in step S905 that the file access Verification Type (Acceptable Verification Type) of the File Definition Block (FDB) is set to require public key certificate Verification, it is determined in step S906 whether public key certificate Verification is completed as Verification of the Verification level required for the access command, and if the Verification is not completed, the processing required by the command is not executed and an access error is transmitted to the file access device (S908).

When it is confirmed in step S905 that the file access Verification Type (Acceptable Verification Type) of the File Definition Block (FDB) is set to require the certificate Verification of the public key system and it is determined in step S906 that the certificate Verification of the public key system is completed, or when the file access Verification Type (Acceptable Verification Type) of the File Definition Block (FDB) is set to require no certificate Verification of the public key system, 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.

The file access device that has received the result of the access command (S892) further determines whether or not to perform another file access (S893), and when performing another file access, repeats steps S891 and subsequent steps, and ends the process when not performing another file access.

Hereinafter, a process (composition) when access is performed to a plurality of files will be described with reference to fig. 87. In the flow of fig. 87, 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 data is transferred between the file access device and the device, the encryption is performed using the session key Kses acquired in the mutual authentication process or the session key calculated or selected from the plurality of session keys, and the generation and verification process of the MAC for tamper check is executed.

The file access device, in step S911, transmits an access command to the device. This command specifies the file ID (source), destination file ID, and access mode of the access target, and for example, the command described above with reference to fig. 84 executes internal encryption for the source file ID [0x0002] using the key of the file ID [0x0001 ]: an Internal Encryption Command (0x0001, 0x0002), and the like.

Upon receiving the command from the file access device (S921), the device determines whether or not there is a permission item corresponding to the access command among the items of the target file ID in the file open table (S922). When the permission item corresponding to the access command does not exist in the file open table, the processing required by the command is not executed, and an access error is transmitted to the file access device (S934).

If the permission item corresponding to the access command is already present in the File open table, in step S923, the authentication level (whether public key authentication is necessary) required to execute the access command to the target File to be accessed is checked with reference to the File access authentication type (authentication type specified when the specific File (File) is accessed) recorded in the File Definition Block (FDB) (see fig. 24) of the corresponding partition in the memory of the device.

When it is confirmed in step S923 that the file access Authentication Type (Acceptable Authentication Type) of the File Definition Block (FDB) is set to require public key Authentication, it is determined in step S924 whether or not public key Authentication, which is Authentication of an Authentication level required for an access command, has been completed, and if Authentication has not been completed, the process required by the command is not executed, and an access error is transmitted to the file access device (S934). The authentication is completed or not completed, and the authentication is determined from an authentication table (see fig. 51) set at the time of mutual authentication.

When it is confirmed in step S923 that the public key Authentication is required and the public key Authentication is completed in step S924, or when the File access Authentication method (accessible Authentication Type) of the File Definition Block (FDB) is set to be unnecessary, then, in step S925, the Verification level required for executing the access command to the target File to be accessed (whether the Verification of the public key method is required) is confirmed by referring to the File access Verification method (accessible Verification Type: the Verification method specified when the access to the specific File (File) is performed) recorded in the File Definition Block (FDB) (see fig. 24) of the corresponding partition in the memory of the device.

When it is confirmed in step S925 that the file access Verification Type (Acceptable Verification Type) of the File Definition Block (FDB) is set to require public key certificate Verification, it is determined in step S926 whether public key certificate Verification is completed as Verification of the Verification level required for the access command, and if the Verification is not completed, the processing required by the command is not executed, and an access error is transmitted to the file access device (S934).

When it is confirmed in step S925 that the file access Verification Type (Acceptable Verification Type) of the File Definition Block (FDB) is set to require public-key certificate Verification and it is determined in step S926 that public-key certificate Verification is completed, or when it is determined in step S927 that public-key certificate Verification is not required, the access method (Read/Write) of the file specified by the target file ID included in the access command is confirmed in response to the command.

The device determines whether or not the file specified by the source file ID included in the command from the file access device is permitted to be opened to the access method (Read/Write) included in the access command (S928). When there is no access method (Read/Write) for executing the command in the file open table, the processing required by the command is not executed, and an access error is transmitted to the file access device (S934).

If the access method (Read/Write) corresponding to the command exists in the File open table, in step S929, the authentication Type (authentication Type specified when accessing a specific File) recorded in the File Definition Block (FDB) (see fig. 24) of the corresponding partition in the memory of the device is referred to, and the authentication level (whether public key authentication is required) required for executing the access command to the source File to be accessed is checked.

When it is confirmed in step S929 that the file access Authentication Type (Acceptable Authentication Type) of the File Definition Block (FDB) is set to require public key Authentication, it is determined in step S930 whether public key Authentication, which is Authentication of an Authentication level required for an access command, is completed, and if Authentication is not completed, the process required by the command is not performed, and an access error is transmitted to the file access device (S934). The authentication is completed or not completed, and the authentication is determined from an authentication table (see fig. 51) set at the time of mutual authentication.

When it is confirmed in step S929 that the public key Authentication is required and the public key Authentication is completed in step S930, or when the File access Authentication method (accessible Authentication Type) of the File Definition Block (FDB) is set to be unnecessary, then, in step S931, the Verification level required for executing the access command to the source File to be accessed (whether the Verification by the public key method is required) is confirmed by referring to the Verification method (accessible Verification Type: the Verification method specified when the access to the specific File (File) is performed) recorded in the File Definition Block (FDB) of the corresponding partition in the memory of the device (see fig. 24).

When it is confirmed in step S931 that the file access Verification Type (Acceptable Verification Type) of the File Definition Block (FDB) is set to require public key certificate Verification, it is determined in step S932 whether public key certificate Verification is completed as Verification of the required Verification level of the access command, and if the Verification is not completed, the processing required by the command is not executed and an access error is transmitted to the file access device (S934).

When it is confirmed in step S931 that the file access Verification Type (Acceptable Verification Type) of the File Definition Block (FDB) is set to require the certificate Verification of the public key system and it is determined in step S932 that the certificate Verification of the public key system is completed, or when the file access Verification Type (Acceptable Verification Type) of the File Definition Block (FDB) is set to require no certificate Verification of the public key system, 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 file access device that has received the result of the access command (S912) further determines whether or not to execute another file access (S913), and when executing another file access, repeats step S911 and subsequent steps, and ends the processing when not executing another file access.

The file access process described above is explained assuming that data specified by a certain file structure is stored in a file, but it may be configured such that data having a different file structure is stored in 1 file and the same process as the above-described sequential process for a plurality of files is executed in accordance with 1 command corresponding to 1 file.

Fig. 88 is a diagram for explaining a configuration for performing sequential processing on data within 1 file according to 1 command corresponding to 1 file.

As shown in the figure, the file is an electronic money file, and is composed of [ pull ] as money amount data, [ Log ] as usage record data, and [ Key ] as Key data for encrypting or decrypting data.

For example, as shown in fig. 88 a, a Deposit Command (Deposit Command) is specified, and the processing is configured to execute 2 steps of adding X yen to [ pull ] as money amount data in the file (S941), and further, writing a record of the addition of X yen to [ pull ] in [ Log ] as usage record data in the file (S942).

By generating a permission Command (see fig. 30) defining the Deposit Command (Deposit Command) as corresponding to the receiving class in the File Access Mode (see fig. 29) as described above, setting [ receiving class ] in the File Access Mode [ File Access Mode ] of the Access permission certificate, designating an Access permission certificate (SPT) of a compound File constituting electronic money by a File id (File id), transmitting the Access permission certificate (SPT) from the File Access device to the device, and then transmitting the Deposit amount data together with the Deposit Command (Deposit Command), the sequential processing of data in 1 File in the device as shown in fig. 88(a) can be executed.

As shown in fig. 88 b, a receipt generation command (Make ReceiptCommand) is defined, and the receipt generation command is configured to execute 3-step processing of subtracting X yen from [ pull ] as money amount data in a file (S945), writing a record obtained by subtracting X yen from [ PuTse ] in [ Log ] as usage record data in the file (S946), and signing data in [ Log ] with [ Key ] as encryption Key data and transmitting (947).

In this case, the order processing for the data in 1 File in the device shown in fig. 88(b) can be performed by generating an Access permission certificate (SPT) in which [ payment class ] is set in the File Access Mode [ File Access Mode ] of the Access permission certificate and [ payment class ] is specified by the File id (File id), ] defining the Receipt generation Command (Make ReceiptCommand) as an allowable Command (see fig. 30) corresponding to the payment class in the File Access Mode (see fig. 29), transmitting the Access permission certificate (SPT) to the device from the File Access apparatus, and then transmitting the extracted amount data together with the Receipt generation Command (Make ReceiptCommand).

As described above, when the file specified by the access permission certificate (SPT) is a compound file, the apparatus selects a processing target file specified in a command received from the access device from within the compound file and executes processing. When the data processing command from the access device is a sequential processing command including a series of plural kinds of processing, the device sequentially selects a processing target file of each command included in the sequential processing command from within the compound file designated by the access permission certificate (SPT) and executes the processing.

[ B4.7. procedure for processing various access processing methods using service license certificate (SPT) ]

In the above-described setting and registering process of the access process file using the service license certificate (SPT), mutual authentication is performed between the device and the reader/writer as the device access apparatus, which is the service license certificate (SPT) user managed by the partition manager, and file access is performed based on the service license (SPT). The mutual authentication process is performed in any one of two modes, i.e., public key mutual authentication and common key mutual authentication, and the verification process of the certificate (SPT) also performs any one of two modes, i.e., signature verification by the public key system and MAC verification by the common key system. That is, the treatment forms can be roughly classified into the following 4 types.

(A) Mutual authentication (public key), certificate (SPT) verification (public key)

(B) Mutual authentication (public key), certificate (SPT) verification (shared key)

(C) Mutual authentication (shared key), certificate (SPT) verification (shared key)

(D) Mutual authentication (shared key), certificate (SPT) verification (public key)

The above-described 4 types of processes will be briefly described with reference to the drawings, centering on data transfer processes performed by the certification authority (ca (PM)), the Partition Manager (PM), and the SPT certificate user, i.e., the reader/writer as the device access apparatus, the device, and each entity.

(A) Mutual authentication (public key), certificate (SPT) verification (public key)

First, data transfer between entities when the public key scheme is used for mutual authentication processing and the public key scheme is used for verification of certificates (SPTs) will be described with reference to fig. 89.

Data transfer is performed between the entities in the order of the sequence numbers shown in the figure. Hereinafter, the processing will be described by each number.

(1) Issuing of public key certificate (cert. PM) of Partition Manager (PM)

The public key certificate (Cert. PM) of the Partition Manager (PM) is issued by a partition supporting certification authority (CA (PAR)) through a Registration Authority (RA) according to a certificate issuing procedure in response to an issuing request from the Partition Manager (PM). In addition, since the partition manager also serves as the service license issuing device (SPT Issuer), the present configuration makes it possible to use the public key certificate of the Partition Manager (PM) as the public key certificate of the service license issuing device (SPTIssuer)

(2) Issuing of public key certificate (cert. rw) of service license User (SPT User), i.e. reader/writer (R/W) as device access means

A public key certificate (Cert. RW) of a service license User (SPT User, specifically, a reader/writer (R/W) as a device access device which issues a certificate to a device is issued by a partition associating certification authority (CA (PAR)) in accordance with a certificate issuing procedure by a Registration Authority (RA) in accordance with an issue request from the reader/writer (R/W) which is a service license User (SPTUser). In addition, the partition manager may also be structurally configured to serve as a service license User (SPT User), and in this case, the public key certificate of the Partition Manager (PM) may be used as the public key certificate of the service license User (SPT User).

(3) Generation processing of service license certificate (SPT)

The service license certificate (SPT) is generated by a service license certificate issuing apparatus (SPT Ticket issue) managed by the partition manager. In this case, in order to generate and verify a Signature by the public key method, a Signature (Signature) is generated by a secret key of a service license issuing apparatus (SPT ticket issuer) (see fig. 12) and attached to the SPT.

(4) SPT and public key certificate (Cert. PM) of partition manager as service license issuing device (SPT packet Issuer) supply to service license user (SPTUser), that is, reader/writer (R/W) as device access device

A service license certificate (SPT) issued by a service license certificate issuing apparatus (SPT TicketIssuer) managed by a partition manager is issued to a service license certificate User (SPT User), that is, a reader/writer (R/W) as a device access apparatus, together with a public key certificate (Cert. PM) of the partition manager as the service license certificate issuing apparatus (SPT TicketIssuer).

(5) Mutual authentication between a reader/writer (R/W) as a device access apparatus and a device

A device that a service license User (SPT User), i.e., a reader/writer as a device access apparatus desires to perform file access based on a service license (SPT) issued by a service license issuing apparatus (SPT packet issue), issues a public key certificate (cert.rw) of a reader/writer (R/W) as a certificate User (SPTUser), and performs mutual authentication by a public key scheme (see fig. 50).

(6) Provision of SPT and public key certificate (Cert. PM) as partition manager of service license issuing apparatus (SPT Ticket Issuer) to device

When mutual authentication between a device and a reader/writer (R/W) serving as a device access apparatus is established, the reader/writer (R/W) serving as a certificate User (SPT User) issues a service license (SPT) and a public key certificate (Cert. PM) serving as a partition manager of the service license issuing apparatus (SPT packet issue).

The device performs, on the received service license certificate (SPT), confirmation that (1) the public key certificate (CERT. pm) of the partition manager as the certificate Issuer (Ticket Issuer) is a legitimate public key Certificate (CERT) that has not been tampered, (2) the code recorded in the optional area of the public key Certificate (CERTPM) of the certificate Issuer (Ticket Issuer) coincides with (SPTIC) recorded in the fdb (file definitional block) in the device, (3) the certificate Issuer (Ticket Issuer) is not revoked, (4) it is confirmed that the certificate has not been tampered with according to the verification of the Signature (Signature) on the received certificate (SPT)), and further confirms that the identifier, the class or the Serial Number (SN), the identification name (id), and the public key certificate (pm) of the SPT User (reader/writer) recorded in the SPT certificate are recorded as identification Data (DN) The identifier, the category or the Serial Number (SN), and the identification name (DN) are matched, and the SPT user (the reader/writer as the device access apparatus) is checked by confirming the completion of the mutual authentication (see fig. 57 and 58).

(7) File access

The device accesses the processing target file according to the rule described in the service license certificate (SPT).

According to the above processing, file access can be performed in each mode of mutual authentication (public key) and certificate (SPT) verification (public key).

(B) Mutual authentication (public key), certificate (SPT) verification (shared key)

Hereinafter, data transfer between entities using a public key method for mutual authentication processing and a common key method for certificate verification (SPT) will be described with reference to fig. 90.

Data transfer is performed between the entities in the order of the sequence numbers shown in the figure. Hereinafter, the processing will be described by each number.

(1) Issuing of public key certificate (cert. rw) of service license User (SPT User), i.e. reader/writer (R/W) as device access means

A public key certificate (Cert.RW) of a reader/writer (R/W) as a device access apparatus, which is a service license User (SPT User), is issued by a Registration Authority (RA) in accordance with a certificate issuing procedure in response to an issuing request from a reader/writer (R/W), which is a service license User (SPT User), by a partition corresponding certification authority (CA (PAR)). In addition, the partition manager may also be structurally configured to serve as a service license User (SPT User), and in this case, the public key certificate of the Partition Manager (PM) may be used as the public key certificate of the service license User (SPT User).

(2) Generation processing of service license certificate (SPT)

The service license certificate (SPT) is generated by a service license certificate issuing apparatus (SPT Ticket issue) managed by the partition manager. In this case, mac (message authentication code) (see fig. 59) is added to the SPT as a check value of the common key method.

(3) SPT supply to service license credential User (SPT User), i.e., reader/writer (R/W) as device access means

A service license certificate (SPT) issued by a service license certificate issuing apparatus (SPT TicketIssuer) managed by a partition manager is issued to a reader/writer (R/W) as a service license certificate User (SPT User).

(4) Mutual authentication between a reader/writer (R/W) and a device

A device that a service license User (SPT User), i.e., a reader/writer as a device access apparatus desires to perform file access based on a service license (SPT) issued by a service license issuing apparatus (SPT packet issue), issues a public key certificate (cert.rw) of a reader/writer (R/W) as a certificate User (SPT User), and performs mutual authentication by a public key scheme (see fig. 50).

Public key certificates that may use Partition Managers (PMs)

(5) SPT provisioning to devices

When mutual authentication between a reader/writer (R/W) as a device access apparatus and a device is established, a reader/writer (R/W) as a certificate User (SPT User) issues a service license certificate (SPT) to the device. The device performs MAC verification processing on the received service license credential (SPT), verifies the SPT Issuer (SPT Issuer), further verifies whether or not the identifier, the class, or the Serial Number (SN), the identification name (DN), recorded as the identification Data (DN) of the SRT User (reader/writer as the certification User) stored in the SRT credential, matches the identifier, the class, or the Serial Number (SN), the identification name (DN), recorded as the identification Data (DN) in the public key certificate (cert.rw) of the certification User (SPT User), and verifies the SPT User (reader/writer as the device access apparatus) by confirming the completion of mutual authentication (see fig. 57 and fig. 58).

(6) File access

The device accesses the processing target file according to the rule described in the service license certificate (SPT).

According to the above processing, file access can be performed in each mode of mutual authentication (public key) and certificate (SPT) verification (common key).

(C) Mutual authentication (shared key), certificate (SPT) verification (shared key)

Hereinafter, data transfer between entities using the common key scheme for mutual authentication processing and verifying the use of the common key scheme for certificate (SPT) will be described with reference to fig. 91.

Data transfer is performed between the entities in the order of the sequence numbers shown in the figure. Hereinafter, the processing will be described by each number.

(1) Generation processing of service license certificate (SPT)

The service license certificate (SPT) is generated by a service license certificate issuing apparatus (SPT Ticket issue) managed by the partition manager. In this case, mac (message authentication code) (see fig. 59) is added to the SPT as a check value of the common key method.

(2) SPT versus service license credential User (SPT User)

A service license certificate (SPT) issued by a service license certificate issuing apparatus (SPT TicketIssuer) managed by a partition manager is issued to a service license certificate user (SPTUser) and a reader/writer (R/W) as a device access apparatus.

(3) Mutual authentication between a reader/writer (R/W) as a device access apparatus and a device

A service license User (SPT User), that is, a reader/writer as a device access apparatus, and a device that wants to create a file from a service license (SPT) issued by a service license issuing apparatus (SPT packet issue), perform mutual authentication by a common key method (see fig. 53 and 54).

(4) SPT provisioning to devices

When mutual authentication between a reader/writer (R/W) as a device access apparatus and a device is established, a service license certificate (SPT) is issued to the device by a reader/writer (R/W) which is a certificate User (SPT User). The device executes MAC verification processing on the received service license credential (SPT), verifies the SPT Issuer (SPT Issuer), further verifies whether or not the identifier of the SRT User (reader/writer as the certification User) stored in the SRT credential matches the identifier of the certification User (SPT User), and verifies the SPT User (reader/writer as the device access apparatus) by confirming completion of mutual authentication (see fig. 57 and 58).

(5) File access

The device accesses the processing target file according to the rule described in the service license certificate (SPT).

According to the above processing, file access can be performed in each mode of mutual authentication (common key) and certificate (SPT) verification (common key).

(D) Mutual authentication (shared key), certificate (SPT) verification (public key)

First, data transfer between entities using a common key scheme for mutual authentication processing and a public key scheme for certificate verification (SPT) will be described with reference to fig. 92.

Data transfer is performed between the entities in the order of the sequence numbers shown in the figure. Hereinafter, the processing will be described by each number.

(1) Issuing of public key certificate (cert. PM) of Partition Manager (PM)

The public key certificate (Cert. PM) of the Partition Manager (PM) is issued by a partition supporting certification authority (CA (PAR)) through a Registration Authority (RA) according to a certificate issuing procedure in response to an issuing request from the Partition Manager (PM). In addition, since the partition manager also serves as the service license issuing device (SPT Issuer), the present configuration makes it possible to use the public key certificate of the Partition Manager (PM) as the public key certificate of the service license issuing device (SPTIssuer)

(2) Generation processing of service license certificate (SPT)

The service license certificate (SPT) is generated by a service license certificate issuing apparatus (SPTTi packet issue) managed by the partition manager. In this case, in order to generate and verify a Signature by the public key method, a Signature (Signature) is generated by a secret key of a service license issuing apparatus (SPT ticket issuer) (see fig. 12) and attached to the SPT.

(3) SPT and public key certificate (Cert. PM) of partition manager as service license issuing device (SPT packet Issuer) supply to service license user (SPTUser), that is, reader/writer (R/W) as device access device

A service license certificate (SPT) issued by a service license certificate issuing apparatus (SPT Ticket Issuer) managed by a partition manager is issued to an apparatus (for example, a reader/writer as a device access apparatus) that issues a certificate to a device together with a public key certificate (cert. pm) of the partition manager as the service license certificate issuing apparatus (SPT Ticket Issuer).

(4) Mutual authentication between a reader/writer (R/W) as a device access apparatus and a device

A service license User (SPT User), that is, a reader/writer as a device access apparatus, and a device that wants to create a file from a service license (SPT) issued by a service license issuing apparatus (SPT packet issue), perform mutual authentication by a common key method (see fig. 53 and 54).

(5) Provision of SPT and public key certificate (Cert. PM) as partition manager of service license issuing apparatus (SPT Ticket Issuer) to device

When mutual authentication between a reader/writer (R/W) and a device is established, a service license User (SPT User, that is, the reader/writer (R/W) as a device apparatus) issues a service license (SPT) and a public key certificate (Cert. PM) as a partition manager of the service license issuing apparatus (SPT packet issue).

A device that performs, on a received service license certificate (SPT), confirmation that (1) a public key certificate (CERT. PM) of a partition manager as a certificate Issuer (Ticket Issuer) is a legitimate public key Certificate (CERT) that is not tampered, (2) a code recorded in an optional area of the public key certificate (CERT PM) of the partition manager as a certificate Issuer (Ticket Issuer) is consistent with (SPTIC) of a certificate issuing apparatus in fdb (filedefinition block) recorded in the device, (3) the certificate issuing apparatus (Ticket Issuer) is not revoked, (4) a confirmation that the certificate is not tampered according to a check of a Signature (Signature) on a received certificate (SPT)), and further, confirmation that an identifier of an SPT User (reader/writer as a certificate User) stored in the SPT certificate is consistent with an identifier of the User (SPT User), and checks the SPT user (reader/writer) by confirming the completion of the mutual authentication (see fig. 57 and 58).

(6) File access

The device accesses the processing target file according to the rule described in the service license certificate (SPT).

According to the above processing, file access can be performed in each mode of mutual authentication (common key) and certificate (SPT) verification (public key).

[ B5. data update processing of a device that uses a data update certificate (DUT) ]

Hereinafter, a data Update process using a data Update certificate (DUT) will be described.

A data Update certificate (DUT: Date Update Ticket) is an access control certificate used when Update processing of various data is performed on various data stored in a device. Data processing can be performed within the limits recorded in the DUT by using the DUT issued by a legitimate data update certificate (DUT) issuing device (Ticket issue) by a certificate user (e.g., a reader as a device access device) and accessing the device according to the steps recorded in the DUT.

As described above, the data Update certificate (DUT: Date Update packet) includes the certificate DUT (dev) for executing the Update process of the data items managed by the device manager and the certificate DUT (par) for executing the Update process of the data items managed by the partition manager (see fig. 32).

A process of performing data update on data stored in a device using a data update certificate (DUT) is explained. This is explained with reference to fig. 93 and other flowcharts that follow. In the data update process, mutual authentication processing (device authentication or partition authentication) between the device and a reader/writer as a device access apparatus that performs data update, and validity check processing of a data update certificate (DUT) are included.

The flow of the data update processing shown in fig. 93 will be described below, and in fig. 93, the left side shows the processing of the data update apparatus, and the right side shows the processing of the device (see fig. 5). The data update apparatus is an apparatus (for example, a reader/writer or a PC as an apparatus access apparatus) capable of performing data reading/writing processing on an apparatus, and corresponds to the reader/writer as the apparatus access apparatus shown in fig. 10. First, an outline of the data update processing will be described with reference to fig. 93, and then, the data update operation included in the present processing will be described in detail with reference to a flowchart of fig. 94.

First, in steps S951 and S960 of fig. 93, a mutual authentication process between a data update apparatus and a device is performed. Between 2 devices that perform data transmission and reception, it is confirmed whether the other party is a legitimate data correspondent or not, and then necessary data transfer can be performed. The mutual authentication process is a process of mutually confirming whether the partner is a legitimate data communicator. The mutual authentication processing is performed by generating a session key and performing encryption processing using the generated session key as a common key, and then transmitting data.

In the mutual authentication process, the same processes as those described in the section of the partition creation/deletion process, that is, either the device authentication or the partition authentication is performed. The authentication process is performed by either a common key authentication process or a public key authentication process. This mutual authentication processing is the same as the processing described above with reference to fig. 48 to 56, and therefore the description thereof will be omitted.

The process to be executed as the mutual authentication process is determined by data in the service license credential (SPT) to be used (see fig. 32)

Authentication Type: the mutual authentication method (public key authentication, common key authentication, or both authentication methods (Any)) of the Device (Device).

If the authentication process fails (no in S952 or S961), the following process is not executed, and the process ends as an error, indicating that the devices and apparatuses cannot be verified as being legitimate.

When the authentication process is successful, the data Update apparatus issues a data Update certificate (DUT) to the device. The data update certificate (DUT) is a certificate issued by a data update certificate (DUT) issuing apparatus (DUT issue) managed by the device manager or the partition manager. The data update certificate (DUT) is an access control certificate for the device, and has the data format structure of fig. 32 described above.

When a data update certificate (DUT) is issued to a certificate user, if the data update certificate is of a public key type, the public key certificate (CERT _ DUT) of a data update certificate (DUT) issuing apparatus (DUT issue) is also issued. The Attribute (Attribute) of the public Key certificate (CERT _ duration) of the DUT issuing apparatus coincides with the identifier (duration) of the certificate issuing apparatus code (duration _ DEV) recorded in the dkdb (pub) (device Key Definition block) or the certificate issuing apparatus code (duration _ PAR) recorded in the pkdb (pub) (partition Key Definition block).

The device that has received the data update certificate (DUT) (S962) executes the process of verifying the validity and user of the received certificate (DUT) (S963). The certificate validity verification process is executed by either MAC verification based on a common key system or signature verification process based on a public key system. The user verification is a process of verifying the legitimacy of the device (certificate user) that issued the certificate, and is executed after the mutual authentication is successful, as a process of verifying whether or not the identification data of the authentication partner matches the certificate user identifier (see fig. 32) recorded in the certificate. These processes are the same as those described with reference to fig. 57 to 59 in the above description of the process of using the partition registration certificate (PRT), and therefore, the description thereof will be omitted.

When the validity of the received certificate (DUT) and the user check process result indicates that the validity of the certificate and the user cannot be confirmed (no in S964), the device receives the data update certificate (DUT) and notifies the data update apparatus of an error (S968). If the validity of the certificate and the user can be confirmed (yes in S964), the update processing is executed on the data stored in the storage unit of the device based on the rule described in the data update certificate (DUT). This process will be described in detail later with another flowchart.

When the update process of the data executed based on the description in the data update certificate (DUT) has succeeded (yes in S966), the DUT is notified of the success (S967). If the data update process fails (no in S966), the DUT reception error is notified to the data update apparatus (S968).

The data update device receives the DUT reception result (S954), determines the DUT reception result, ends the process as an error if the DUT reception result is an error (no in S955), and transmits and receives a session termination command if the DUT reception result is a success (yes in S955) (S956, S969), discards the authentication table generated on the device side (S970), and ends the process. The authentication table is generated in the mutual authentication processing in steps S951 and S960, and has the same configuration as that described in the item of the use processing of the partition registration certificate (PRT), that is, the configuration of fig. 51.

As described above, the update process is performed on the data within the storage device using the data update certificate (DUT). Next, the data update (S965) included in the present process will be described with reference to fig. 94.

The process flow of fig. 94 is a process executed by the device that receives the data update certificate (DUT), and is executed after successful mutual authentication with the device that transmitted the data update certificate (DUT) and successful verification of the certificate.

First, in step S971, the device retrieves a version of an update Data object from the Code (Old Data Code) of the updated original Data in the Data update certificate (DUT). In the version, if the update object is a Device Manager Code (DMC), the version is recorded in the device management information block (see fig. 15), and if the update object is a Partition Manager Code (PMC), the version is recorded in the partition management information block (see fig. 20). The version of the partition registration certificate (PRT) Issuer (PRT Issuer) is included in the device definition block (see fig. 16). Version information such as the revocation list (IRL DEV, CRL DEV) is included in the revocation list. As described above, the storage address of the version information is determined according to the difference of the information, and therefore, the device can retrieve the version of the update Data object from the Code (Old Data Code) of the original Data.

Then, in step S972, the device refers to the Version condition [ Data Version Rule ] recorded in the Data update certificate (DUT) at the time of Data update, and determines whether the setting is [ Any ].

As described above, there are 3 types of Version conditions [ Data Version Rule ] for updating Data. Any indicates that Data update is possible regardless of Version (Version) conditions, and Exact indicates that Data update is possible when the Version value is the same as the value specified in the following Data Version Conditon. Older indicates that Data update can only be done when New Data Version is New. Further, when the Version condition [ Data Version rule ] is Any or Older, [ Data Version Conditon ] is not used or is ignored.

When the setting of [ Data Version Rule ] of the Data update certificate (DUT) is not [ Any ], processing is executed according to the Version condition [ Data Version Rule ]. The method comprises the steps of S973-S975.

In step S973, the version condition [ DataVersion Rule ] of the data update certificate (DUT) is referred to, and whether the setting thereof is [ EXACT ] is judged. [ EXACT ] indicates that Data can be updated only when the value specified in [ Data Version Conditon ] is the same as the value specified in the following [ Data Version Conditon ]. If the setting is [ EXACT ], in step S964, it is determined whether or not the Version of the update target Data [ Old Data ] matches the Version value recorded in [ Data Version Conditon ] of the Data update certificate (DUT). If the two are consistent, the process proceeds to the next step, and if they are not consistent, the update process is not executed and the process ends as an error.

When it is determined in step S973 that the version condition [ DataVersion Rule ] of the data update certificate (DUT) is not [ EXACT ], it is set to [ Older ]. The setting of [ Older ] means that the setting is made such that updating can be performed only when [ New Data Version ] indicating the Version of New Data [ New Data ] of the Data update certificate (DUT) is newer than the Version of the update target Data [ Old Data ]. When it is set to [ Older ], in step S975, it is determined whether or not [ New DataVersion ] indicating the version of the New Data [ New Data ] of the Data update certificate (DUT) is newer than the version of the update target Data [ Old Data ], and the process proceeds to the next step only when it is New, and if it is not New, the update process is not executed and the process ends as an error.

Next, the device, in step S976, checks the Encrypted Flag of the data update certificate (DUT). [ Encrypted Flag ] is data indicating whether or not the updated data is Encrypted (Encrypted/non-Encrypted: none). When [ Encrypted Flag ] indicates that the update target Data is unencrypted Data, in step S977, a process of replacing the New Data [ New Data ] of the Data update certificate (DUT) with the original update target Data [ Old Data ] stored in the storage unit of the device is executed, and the process is terminated. When a Version is added to the Update target Data, a process is performed in which the Version (New Data Version) of the Update Data stored in the Data Update certificate (DUT) is stored in a Version storage area set in association with the Update Data in the device.

In addition, when it is determined in step S976 that [ EncryptedFlag ] of the data update certificate (DUT) indicates that the updated data is Encrypted (Encrypted), in step S978, [ Ticket Type ] of the data update certificate (DUT) is checked. [ Ticket Type ], which is data indicating the Type (DUT (DEV)/DUT (PAR)) of the certificate (Ticket). DUT (dev) indicating that the data update certificate (DUT) is a certificate for performing update processing of data items managed by the device manager, DUT (par) indicating that the data update certificate (DUT) is a certificate for performing update processing of data items managed by the partition manager.

When the certificate Type [ Ticket Type ] indicates dut (dev), steps S979 to S982 are executed, and when dut (par) is indicated, steps S983 to S986 are executed.

When the certificate Type [ Ticket Type ] indicates DUT (DEV), in step S979, it is determined whether or not Data indicated by the Old Data Code described in the Data update certificate (DUT (DEV)) is Kdut _ DEV1 (key for MAC verification of Data update certificate (DUT)) or Kdut _ DEV2 (encryption key for Data update) stored in the device key area (see fig. 18).

When Data indicated by the Old Data Code (Code of the original Data to be updated) described in the Data update certificate (DUT (DEV)) is Kdut _ DEV1 (key for MAC verification of the Data update certificate (DUT)) or Kdut _ DEV2 (encryption key for Data update) stored in the device key area (see fig. 18), in step S980, Kdut _ DEV1 and Kdut _ DEV2, which are New Data [ New Data ] stored in the Data update certificate (DUT) (see fig. 18), are decrypted by using Kdut _ DEV4 (encryption key for Data update) stored in the device key area (see fig. 18) and rewritten on Kdut _ DEV1 and Kdut _ DEV2 stored in the device key area of the device. The Version (New Data Version) of the Data to be updated stored in the Data update certificate (dut (dev)) is stored in a Version storage area set in association with the update Data in the device, and in this case, is stored in a device key area (see fig. 18) of the device.

Next, in step S981, exchange, that is, substitution processing, of Kdut _ DEV1 (key for MAC verification of data update certificate (DUT)) and Kdut _ DEV3 (key for MAC verification of data update certificate (DUT)) stored in the device key area (see fig. 18) of the device is performed. At the same time, the process of exchanging, i.e., replacing, Kdut _ DEV2 (encryption key for data update) and Kdut _ DEV4 (encryption key for data update) is performed, and then the process is terminated.

By exchanging Kdut _ DEV1 with Kdut _ DEV3 and exchanging Kdut _ DEV2 with Kdut _ DEV4, a pair of Kdut _ DEV3 (key for MAC verification of data update certificate (DUT)) and Kdut _ DEV4 (encryption key for data update) can always be maintained as a new version of a pair of Kdut _ DEV1 (key for MAC verification of data update certificate (DUT)) and Kdut _ DEV2 (encryption key for data update), and processing for always setting rewrite target to Kdut _ DEV1 and Kdut _ DEV2 can be performed.

Then, when it is determined in step S979 that the Data indicated by the Old Data Code (the Code of the updated original Data) described in the Data update certificate (DUT (DEV)) is not the Data indicated by Kdut _ DEV1 (the key for MAC verification of the Data update certificate (DUT)) or Kdut _ DEV2 (the encryption key for Data update) stored in the device key area (see fig. 18), in step S982, the New Data [ New ] Data stored in the Data update certificate (DUT (DEV)) is decrypted by using the Kdut _ DEV2 (the encryption key for Data update) stored in the device key area (see fig. 18), and rewritten in the area indicated by the Old Data Code (the Code of the updated original Data) of the Data update certificate (DUT (DEV)). When a version is added to the update target data, a process is performed in which the version (New DataVersion) of the update data stored in the data update certificate (dut (dev)) is stored in a version storage area set in association with the update data in the device.

On the other hand, when the certificate Type [ Ticket Type ] indicates dut (par) in step S978, steps S983 to S986 are executed.

When the certificate Type [ Ticket Type ] indicates DUT (PAR), in step S983, it is determined whether or not Data indicated by the Old Data Code described in the Data update certificate (DUT (PAR)) is Kdut _ PAR1 (key for MAC verification of Data update certificate (DUT)) or Kdut _ PAR2 (encryption key for Data update) stored in the partition key area (see fig. 23).

When Data indicated by Old Data Code (Code of updated original Data) described in the Data update certificate (DUT (PAR)) is Kdut _ PAR1 (key for MAC verification of Data update certificate (DUT)) or Kdut _ PAR2 (encryption key for Data update) stored in the device key area (see fig. 18), in step S984, Kdut _ PAR1 and Kdut _ PAR2, which are New Data [ New Data ] stored in the Data update certificate (DUT (PAR)) are decrypted by using Kdut _ PAR4 (encryption key for Data update) stored in the partition key area (see fig. 23), and rewritten on Kdut _ PAR1 and Kdut _ PAR2 stored in the partition device key area of the device. The Version (New Data Version) of the update Data stored in the Data update certificate (dut (par)) is stored in a Version storage area set in association with the update Data in the device, and in this case, is stored in a partition key area (see fig. 23) of the device.

Next, in step S985, exchange, that is, replacement processing, of Kdut _ PAR1 (key for MAC verification of data update certificate (DUT)) and Kdut _ PAR3 (key for MAC verification of data update certificate (DUT)) stored in the partition key area of the device (see fig. 23) is performed. At the same time, an exchange, that is, a replacement process of Kdut _ PAR2 (encryption key for data update) and Kdut _ PAR4 (encryption key for data update) is performed, and then the process is terminated.

By the exchange process of Kdut _ PAR1 with Kdut _ PAR3 and Kdut _ PAR2 with Kdut _ PAR4, a pair of Kdut _ PAR3 (key for MAC check of data update certificate (DUT)), and Kdut _ PAR4 (encryption key for data update) can always be kept new versions than a pair of Kdut _ PAR1 (key for MAC check of data update certificate (DUT)) and Kdut _ PAR2 (encryption key for data update). And processing for always setting the rewrite target to Kdut _ PAR1 and Kdut _ PAR2 can be performed.

Then, when it is determined in step S983 that the Data indicated by the Old Data Code described in the Data update certificate (DUT (PAR)) is not Kdut _ PAR1 (key for MAC verification of Data update certificate (DUT)) or Kdut _ PAR2 (encryption key for Data update) stored in the partition key area (see fig. 23) of the device, the New Data [ New ] Data stored in the Data update certificate (DUT PAR)) is decrypted by using Kdut _ PAR2 (encryption key for Data update) stored in the partition key area (see fig. 23) of the device, and rewritten in the area indicated by the Old Data Code (Code of updated original Data) of the Data update certificate (DUT (PAR)) in step S986. When a Version is added to the update target data, a process is performed in which the Version (NewData Version) of the update data stored in the data update certificate (dut (par)) is stored in a Version storage area set in association with the update data in the device.

The above processing is a data update operation based on the data update certificate.

As can be seen from the above-described flow, when the update target data is the following data stored in the device key area or the partition area, a process different from other update processes is executed.

Kdut _ DEV1 (Key for MAC verification of data update certificate (DUT))

Kdut _ DEV2 (encryption key for data update)

Or

Kdut _ PAR1 (key for MAC verification of data update certificate (DUT))

Kdut _ PAR2 (encryption key for data update)

Fig. 95 is a diagram schematically summarizing the update processing of Kdut _ DEV1 (key for MAC verification of data update certificate (DUT)), Kdut _ DEV2 (encryption key for data update), Kdut _ PAR1 (key for MAC verification of data update certificate (DUT)), and Kdut _ PAR2 (encryption key for data update) as described above, and the processing will be described. The description is made in the order of (1) to (3) in fig. 95. Further, the processing of Kdut _ DEV1 and 2 is the same as that of Kdut _ PAR1 and 2, and therefore, the case when Kdut _ DEV1 and 2 are updated will be described.

(1) Kd _ DEV1 and kd _ DEV2, which are New Data [ New Data ], stored in the Data update certificate (DUT) are encrypted by kd _ DEV4 (encryption key for Data update) stored in the device key area (see fig. 18) of the device, then stored in the Data update certificate (DUT), and the Data update certificate (DUT) is transmitted to the device. At this time, the certificate issuers of Kdut _ DEV1, Kdut _ DEV2 may be updated, and must know Kdut _ DEV3, Kdut _ DEV 4.

(2) The device that received the Data update certificate (DUT) decrypts Kdut _ DEV1, Kdut _ DEV2, which is New Data [ New Data ], stored in the Data update certificate (DUT) with Kdut _ DEV4 (encryption key for Data update) stored in the device key area of the device and rewrites on Kdut _ DEV1, Kdut _ DEV2 already stored in the device key area of the device.

(3) Next, the device performs a replacement process of exchanging Kdut _ DEV1 (key for MAC verification of data update certificate (DUT)) newly stored in the device key area (see fig. 18) of the device with Kdut _ DEV3 (key for MAC verification of data update certificate (DUT)) previously stored. Further, a replacement process, which is an exchange between newly stored Kdut _ DEV2 (encryption key for data update) and previously stored Kdut _ DEV4 (encryption key for data update), is performed.

By exchanging Kdut _ DEV1 with Kdut _ DEV3 and exchanging Kdut _ DEV2 with Kdut _ DEV4, a new pair of a pair of Kdut _ DEV3 (key for MAC verification of data update certificate (DUT)) and a pair of Kdut _ DEV4 (encryption key for data update) can be maintained as compared with a new pair of a pair of Kdut _ DEV1 (key for MAC verification of data update certificate (DUT)) and a new pair of a Kdut _ DEV2 (encryption key for data update). That is, kd ut _ DEV1 and kd ut _ DEV2, which are keys used normally, kd ut _ DEV3 and kd ut _ DEV4, are used to update kd ut _ DEV1 and kd ut _ DEV2 under abnormal conditions and function as spare keys to be replaced with keys kd ut _ DEV1 and kd _ DEV 2.

Moreover, as a pair, Kdut _ DEV1 (key for MAC verification of data update certificate (DUT)) and Kdut _ DEV2 (encryption key for data update) are used, and as a pair, Kdut _ DEV3 (key for MAC verification of data update certificate (DUT)) and Kdut _ DEV4 (encryption key for data update) are used.

Although the present invention has been described in detail with reference to the specific embodiments, it is needless to say that a person skilled in the art may modify or substitute the embodiments without departing from the scope of the present invention. That is, the present invention is disclosed only by way of example and should not be construed as being limited thereto. For the purpose of judging the gist of the present invention, reference should be made to the scope of claims recited in the opening part of the present specification.

In addition, a series of processes described in the specification may be executed by hardware, software, or a composite structure of both. When the processing is performed by software, the program in which the processing order is recorded may be loaded into a memory of a computer incorporated in dedicated hardware and executed, or the program may be loaded into a general-purpose computer that can perform various processing and executed.

For example, the program may be recorded in advance in a hard disk or a ROM (read only memory) as a recording medium. Or, it is temporarily or permanently stored (recorded) in a removable recording medium such as a CD ROM (Compact disc ROM), an MO (magneto optical) Disk, a semiconductor memory, or the like. The removable recording medium may be provided in the form of a software package.

In addition, the program may be transferred from a download site to a computer wirelessly or transferred to a computer by wire via a LAN (Local area network) or the internet, in addition to being loaded from the above-described removable recording medium into the computer, and the program transferred in this manner may be received by the computer and loaded into a recording medium such as a built-in hard disk.

The various processes described in the specification may be executed not only in time series according to the description, but also in parallel or individually according to the processing capability of the apparatus that executes the processes or as necessary. The system in the present specification is a logical set structure of a plurality of devices, and is not limited to the case where the constituent devices are in the same housing.

Industrial applicability of the invention

As described above, according to the data access management system, the memory mount device, the data access management method, and the program storage medium of the present invention, it is possible to implement an independent management structure of data in each partition by issuing various types of access control certificates under the management of each device or partition management entity and executing processing by the memory mount device according to rules described in each certificate for access to a storage area divided into a plurality of partitions.

Further, according to the data access management system, the memory mount device, the data access management method, and the program storage medium of the present invention, since the service license certificate (SPT) which is an access control certificate in which an access mode permitted to be executed by the access device is set can be issued individually for each access device, it is possible to realize a configuration in which accesses of different types are executed for each access device.

In addition, according to the data processing system, the memory mount device, the data processing method, and the program storage medium of the present invention, it is possible to realize an independent management structure of data in each partition by issuing various types of access control certificates under the management of each device or partition management entity and executing processing by the memory mount device according to rules described in each certificate, for access to a storage area divided into a plurality of partitions.

In addition, according to the data processing system, the memory mount device, the data processing method, and the program storage medium of the present invention, the device can be set to be capable of performing partition corresponding authentication and device object authentication in accordance with any one of the designation methods of the public key and the common key, so that it is possible to perform secure data communication between the device and the access apparatus under various environments.

Further, according to the data processing system, the memory mounting device, the data processing method, and the program storage medium of the present invention, the memory mounting device determines and executes any one of the public key system and the common key system as a mutual authentication system with the access device based on a specification from the access device or a description of the received access control certificate, and also determines and executes any one of the public key system and the common key system based on the description of the received access control certificate, thereby making it possible to perform secure data communication between the device and the access device based on the form of various access control certificates under various environments.

Further, according to the data storage control system, the memory installation device, the data storage control method, and the program storage medium of the present invention, the memory installation device is configured to receive the access control certificate from the access device, and to permit the data access based on the establishment of the authentication based on the authentication rule described in the access control certificate and the confirmation of the condition for the identification data of the access device described in the access control certificate, so that it is possible to realize the access management in which the security level corresponding to the memory access processing is set by setting various authentication forms and certificate forms for each access.

In addition, according to the data storage control system, the memory mounting device, the data storage control method, and the program storage medium of the present invention, since the types and identifiers of the certificate issuing apparatus and the used apparatus are stored in the access control certificate and can be checked by the device, it is possible to realize access management at a high security level.

In addition, according to the data storage control system, the memory mount device, the data storage control method, and the program storage medium of the present invention, it is possible to implement an independent management structure of data in each partition by issuing various types of access control certificates under the management of each device or partition management entity and executing processing by the memory mount device according to rules described in each certificate, for access to a storage area divided into a plurality of partitions.

Further, according to the memory access control system, the memory mounted device, the memory access control method, and the program storage medium of the present invention, since the access processing to the plurality of data files is executed based on the plurality of access control certificates on the condition that the device authentication, which is the authentication to the memory mounted device, or the partition authentication, which is the authentication to each partition storing the data file to be accessed, is established, the authentication mode is described in the certificate generated based on the access mode. Various settings such as performing only device authentication or performing each partition authentication are possible.

Further, according to the memory access control system, the memory installation device, the memory access control method, and the program storage medium of the present invention, since the memory installation device generates a unique integrated session key from a plurality of session keys obtained as a result of a plurality of authentication processes executed under file access conditions in a plurality of different partitions, and executes an encryption process of communication data with an access device based on the integrated session key, it is not necessary to perform a process such as switching session keys when accessing files in different partitions.

Further, according to the memory access control system, the memory mount device, the memory access control method, and the program storage medium of the present invention, the processing for responding to the access request to the data file in each partition is executed on the condition that the authentication with the access device is established based on the authentication mode set for each partition, and as the authentication mode, there are at least 2 types of authentication modes of device authentication which is the authentication to the memory mount device and partition authentication which is the authentication to each partition, so that the authentication corresponding to each access certificate can be selectively executed.

Claims (31)

1. A data access management method for managing access processing to a storage data file of a storage unit by an access device to a memory mount apparatus having the storage unit capable of storing data, the data access management method characterized by: the access device receives a service license certificate (SPT) which is an access control certificate for which an allowable access mode is set for the access device from a certificate issuing device, and outputs the received service license certificate (SPT) to the memory mount device, and the memory mount device executes processing based on the access mode described in the service license certificate (SPT) after receiving the service license certificate (SPT) from the access device;

the memory installation device executes processing for responding to an access request to a stored data file, based on a description of a service license certificate (SPT) issued by a certificate issuing apparatus under the management of the partition manager and input to the memory installation device by the access apparatus as a certificate utilizing apparatus.

2. The data access management method according to claim 1, characterized in that: the method is characterized in that: the service license (SPT) includes a file identifier for identifying a data file to be accessed, and the memory mount device receives the service license (SPT) from the access device, selects a data file based on the file identifier described in the service license (SPT), and executes processing on the selected file based on the access pattern.

3. The data access management method according to claim 1, characterized in that: the service license ticket (SPT) has a structure including a plurality of file identifiers for identifying a plurality of data files to be accessed, and has a structure in which one of the plurality of file identifiers is set as a target file identifier and read or write license data corresponding to the target file is stored, and the memory-mounted device executes processing in accordance with the access mode after receiving the service license ticket (SPT) from the access device, and executes read or write processing in accordance with the read or write license data set in the service license ticket (SPT) for the target file identifier.

4. The data access management method according to claim 1, characterized in that: the service license (SPT) has a structure including a plurality of file identifiers for identifying a plurality of data files to be accessed, and has a structure in which one of the plurality of file identifiers is set as a target file identifier, read or write license data corresponding to the target file is stored, and an access mode of another data file is set as an encryption process using an encryption key stored in the data file, and the memory-mounted device receives the service license (SPT) from the access apparatus, and then executes the internal encryption process in the memory-mounted device by executing the read of the target file and the encryption process using the encryption key as a process according to the access mode.

5. The data access management method according to claim 1, characterized in that: the certificate issuing apparatus for issuing the service license (SPT) is a certificate issuing apparatus under the management of an entity for managing the storage area of the memory mounted device, and the certificate issuing apparatus individually issues the service license (SPT) in which various access modes are set for each access apparatus, thereby enabling access of different forms to be executed for each access apparatus.

6. The data access management method according to claim 1, characterized in that: a file opening table is generated in which a file identifier, which is identification data of a file for which a file opening process is executed based on a service license certificate (SPT) received in a session with an access device, is associated with an access pattern described in the service license certificate (SPT), and whether or not a command received from the access device can be executed is determined by referring to the file opening table.

7. The data access management method according to claim 1, characterized in that: the data file is stored in any one of the 1 or more partition areas.

8. The data access management method according to claim 1, characterized in that: the service license (SPT) includes mutual authentication form designation data designating a mutual authentication form to be executed between the memory mount device and an access apparatus which has outputted the certificate, and the memory mount device executes mutual authentication based on the mutual authentication form designation data of the service license (SPT) and executes processing corresponding to recording of the received certificate on condition that the authentication is established.

9. The data access management method according to claim 1, characterized in that: the service license (SPT) includes certificate verification specifying data specifying a verification form of the service license (SPT) received by the memory-mounted device, and the memory-mounted device executes a certificate verification process based on the certificate verification specifying data of the service license (SPT) and executes a process corresponding to the record of the received certificate on condition that the verification is established.

10. A data processing method of executing data processing on a storage section capable of storing data in response to an access request issued from an access device to a memory mount apparatus having the storage section, the data processing method characterized by: in the memory mount device, receiving an access control certificate having a configuration corresponding to data processing in the storage unit from the access device, performing data processing based on a rule described in the access control certificate, determining and executing a mutual authentication method with the access device based on specification of the access device or the description of the access control certificate received from the access device, determining and executing a verification method of the access control certificate based on the description of the received access control certificate, and executing an access request from the access device on condition that both the mutual authentication and the certificate verification are established;

The memory installation device executes processing for responding to an access request to a stored data file, based on a description of a service license certificate (SPT) issued by a certificate issuing apparatus under the management of the partition manager and input to the memory installation device by the access apparatus as a certificate utilizing apparatus.

11. The data processing method of claim 10, wherein: the mutual authentication method is either a public key method or a common key method, and the verification method of the access control certificate is either a public key method or a common key method.

12. The data processing method of claim 10, wherein: the access control device has a key for MAC verification for verifying the access control certificate, executes a tamper check process using the key for MAC verification when the access control certificate received from the access device is verified by a common key system, and executes a signature verification process based on a public key of the certificate issuing device acquired from a public key certificate of the certificate issuing device when the access control certificate is verified by a public key system.

13. The data processing method of claim 10, wherein: the access control device has a plurality of MAC verification keys for verifying the access control certificate, and selects a MAC verification key to be used based on information recorded in the access control certificate received from the access device.

14. The data processing method of claim 10, wherein:

including a data update certificate (DUT) that allows update processing of stored data in the storage section of the memory mount device,

has a plurality of keys for MAC verification for performing verification of the above-mentioned access control certificate,

when the update target data specified in the data update certificate (DUT) received from the access device is a MAC verification key for verifying the access control certificate, a MAC verification key that does not match the update target is selected from a plurality of MAC verification keys for verifying the access control certificate, and verification processing is performed on the received data update certificate (DUT).

15. The data processing system of claim 10, wherein:

there are 1 or more partition areas as storage areas managed by the respectively corresponding partition managers.

16. The data processing method of claim 10, wherein:

having 1 or more partition areas as storage areas managed by the respectively corresponding partition managers,

an authentication table is generated in which public key system authentication information and session keys or common key system authentication information and session keys obtained by partition authentication or device authentication performed in a session with the access device are associated with each other, and the authentication table is held during the session.

17. A data access control method for transmitting a command from an access device to a memory mounted device having a storage unit capable of storing data and executing processing on the data stored in the storage unit, the data access control method comprising: the memory mount device receiving an access control certificate configured as access control data for data stored in the storage unit from the access device, and permitting data access in accordance with an authentication establishment based on an authentication rule described in the access control certificate and a determination condition for identification data of the access device described in the access control certificate;

the memory installation device executes processing for responding to an access request to a stored data file, based on a description of a service license certificate (SPT) issued by a certificate issuing apparatus under the management of the partition manager and input to the memory installation device by the access apparatus as a certificate utilizing apparatus.

18. The data access control method of claim 17, wherein: the access control certificate includes authentication format specifying information indicating whether the authentication method is permitted, that is, one or both of a public key method and a shared key method, and the memory-attached device executes the authentication process based on the authentication format described in the access control certificate received from the access apparatus.

19. The data access control method of claim 17, wherein: the memory-mounted device executes a process of confirming that the certificate is a certificate issued by a legitimate issuing apparatus based on the type or identifier of the issuing apparatus of the access control certificate described in the access control certificate received from the access apparatus, and permits data access on condition of the confirmation.

20. The data access control method of claim 17, wherein: the memory-mounted device executes a process of confirming that the certificate is a certificate issued by a legitimate issuing apparatus based on a comparison between the type or identifier of the issuing apparatus of the access control certificate described in the access control certificate received from the access apparatus and the user information stored in the public key certificate of the issuing apparatus of the access control certificate, and permits data access on condition of the confirmation.

21. The data access control method of claim 17, wherein: the memory-mounted device executes a process of confirming that the certificate is a certificate provided by a legitimate user device on the basis of the type or identifier of the access device, which is the user device of the access control certificate, described in the access control certificate received from the access device, and permits data access on the condition that the confirmation is made.

22. The data access control method of claim 17, wherein: the memory-mounted device executes a process of confirming that the certificate is a certificate provided by a legitimate user device based on a comparison between the type or identifier of the user device, which is the access device that is the access control certificate described in the access control certificate received from the access device, and the user information stored in the public key certificate of the user device of the access control certificate, and permits data access on the condition that the confirmation is made.

23. The data access control method of claim 17, wherein: the storage unit of the memory-mounted device has 1 or more partition areas as storage areas managed by the corresponding partition managers, and the memory-mounted device generates an authentication table in which public key system authentication information and a session key or common key system authentication information and a session key obtained by partition authentication or device authentication performed in a session with the access apparatus are associated with each other.

24. A memory access control method for controlling a memory access by an access device to a memory mount device having a storage unit storing a plurality of data files, the memory access control method comprising: having 1 or more partition areas as storage areas managed by the respective corresponding partition managers, the data file being stored in any one of the 1 or more partition areas,

the access device receives an access control certificate from the access device and executes access processing to a data file based on the description of the access control certificate, and executes access processing to a plurality of data files based on a plurality of access control certificates on the condition that device authentication as authentication to the memory-mounted device or authentication to each partition storing a data file to be accessed is established as partition authentication.

25. The memory access control method of claim 24, wherein: the authentication mode that can be set for each partition is described in an access control certificate configured as access control data,

the access control certificate is received from the access device, and the authentication mode required for each partition is determined based on the description of the access control certificate.

26. The memory access control method of claim 24, wherein: access to the files in the plurality of different partitions is permitted based on the plurality of access control certificates on condition that the device authentication is established.

27. The memory access control method of claim 24, wherein: access to the files in the plurality of different partitions is permitted based on the plurality of access control certificates on the condition that all of the authentication conditions set corresponding to the different partitions, i.e., partition authentication or device authentication, have been successfully authenticated.

28. The memory access control method of claim 24, wherein: a unique integrated session key is generated from a plurality of session keys obtained as a result of a plurality of authentication processes performed under file access conditions in a plurality of different partitions, and an encryption process of communication data with the access device is performed based on the integrated session key.

29. The memory access control method of claim 24, wherein: a unique integrated session key is generated by XOR operation of session keys based on session keys acquired as a result of a plurality of authentication processes executed under file access conditions in a plurality of different partitions, and encryption processing of communication data with the access device is executed based on the integrated session key.

30. The memory access control method of claim 24, wherein: a unique session key is selected from among a plurality of session keys obtained as a result of a plurality of authentication processes executed under file access conditions in a plurality of different partitions, and an encryption process of communication data with the access device is executed based on the selected session key.

31. The memory access control method of claim 24, wherein: an authentication table is generated in which public key system authentication information and session keys or common key system authentication information and session keys obtained by partition authentication or device authentication performed with the access device are associated with each other, and the authentication table is held during the session.