JP4504083B2 - Digital certificate management system, digital certificate management apparatus, digital certificate management method, update procedure determination method and program - Google Patents

Description

  The present invention provides a certification key used for confirming the validity of a digital certificate used for authentication processing between nodes of a client / server system configured in a plurality of stages in a form in which an upper node follows a lower node. Using an update procedure determination method for determining an update procedure when updating by a digital certificate management device communicable with each node, a program for causing a computer to function as the digital certificate management device, and the update procedure determination method described above The digital certificate management apparatus configured to update the certification key according to the update procedure determined in advance and the client / server system, and the update procedure defined using the update procedure determination method The present invention relates to a digital certificate management apparatus that updates the certification key according to the above.

2. Description of the Related Art Conventionally, a client / server system is configured in which a plurality of computers such as PCs are communicably connected via a network, and at least one is a server device (server) and another at least one is a client device (client). Things have been done.
In such a client / server system, a request is transmitted from the client device to the server device, and the server device performs processing according to the request and returns a response to the client device. Such a client / server system is widely used for so-called electronic commerce in which an order request for a product is transmitted from a client device and the server device accepts the order. In addition, a system has also been proposed in which various electronic devices are connected via a network with the functions of a client device or a server device, and the electronic device is remotely managed by communication between them.

  In such a case, it is important to confirm whether the communication partner is appropriate or whether the transmitted information has been tampered with. In particular, in the Internet, since information often passes through an irrelevant computer until it reaches a communication partner, it is necessary to prevent the contents from being stolen when transmitting confidential information. As a communication protocol that meets such requirements, for example, a protocol called SSL (Secure Socket Layer) has been developed and widely used. By performing communication using this protocol, it is possible to combine a public key cryptosystem and a common key cryptosystem to authenticate a communication partner and to prevent tampering and eavesdropping by encrypting information.

Here, a communication procedure when performing an authentication process using a public key cryptosystem and a digital certificate used at that time will be described. Here, a case where the client device authenticates the server device will be described as an example.
In this case, in order to perform authentication processing, the server private key and the server public key certificate (server certificate) are stored on the server device side, and the root key certificate is stored on the client device side. Here, the server private key is a private key issued to a server device by a certificate authority (CA). The server public key certificate is a certificate obtained by adding a digital signature to the public key corresponding to the private key. In addition, the root key certificate attaches a digital signature to the root key that is the certification public key (hereinafter also referred to as “certification key”) corresponding to the root private key that is the private key for certification used by the CA for the digital signature. It is a digital certificate.

FIG. 58 shows these relationships.
As shown in FIG. 58A, the server public key includes a key body for decrypting a document encrypted using the server private key, an issuer (CA) of the public key, and an issuer (server Device) and bibliographic information including information such as an expiration date. The CA encrypts the hash value obtained by hashing the server public key using the root private key to indicate that the key body or bibliographic information has not been tampered with, and uses it as a digital signature in the server public key. Attached. At this time, the identification information of the root private key used for the digital signature is added as signature key information to the bibliographic information of the public key. The public key certificate with the digital signature is a server public key certificate.

  When this server public key certificate is used for authentication processing, the digital signature included therein is decrypted using the key body of the root key which is a public key corresponding to the root private key. If this decryption is carried out normally, it can be seen that the digital signature is certainly attached by the CA. Further, if the hash value obtained by hashing the server public key portion matches the hash value obtained by decryption, it is understood that the key itself has not been damaged or tampered. Further, if the received data can be normally decrypted using this server public key, it is understood that the data is transmitted from the server private key owner, that is, the server device. After that, referring to the bibliographic information, whether the authentication is correct or not may be determined based on the reliability of the CA, the presence / absence of registration of the server device, or the like.

  Here, in order to perform authentication, it is necessary to store a root key in advance. This root key is also a root key certificate with a digital signature attached by the CA, as shown in FIG. Remember. This root key certificate is a self-signed form in which a digital signature can be decrypted with a public key included in the root key certificate. When the root key is used, the digital signature is decrypted using the key body included in the root key certificate, and compared with the hash value obtained by hashing the root key. If they match, it can be confirmed that the root key is not damaged.

When the client device requests communication to the server device in the client / server system constituted by the client device and the server device as described above, each of these devices performs the following processing.
First, the server device generates a random number in response to a communication request from the client device, encrypts it with the server private key, and transmits the encrypted random number together with the server public key certificate to the client device.
Then, the client device that has received this confirms the validity of the received server public key certificate using the root key certificate. This includes a process of confirming that the server apparatus is an appropriate communication partner by referring to the bibliographic information as well as confirming that no damage or tampering has occurred as described above.

If the confirmation can be made, the received random number is decrypted using the server public key included in the received server public key certificate. Here, if the decryption is successful, it can be confirmed that the first random number is certainly received from the server device to which the server public key certificate is issued. Therefore, the server device can be authenticated as a valid communication partner by the above processing.
In addition, if the common key encryption key is exchanged by encrypting with the above public key or private key, the common key is exchanged safely, and a secure communication path is established by encrypting the communication contents with the common key encryption. can do.

By the way, in the public key cryptosystem, although depending on the key length, a private key can be derived from the public key over time. Once the private key is known, a third party can impersonate the owner of the private key, so authentication reliability and communication security cannot be maintained. Therefore, as described above, an increasing number of users adopt a security policy in which an expiration date is set for a key and a set of keys is updated every predetermined period. For this reason, for example, when providing a remote management system or the like using the authentication process as described above, it is necessary to guarantee to the customer that the system can update the key. The same applies to the root key and the root private key. In addition to the arrival of a predetermined expiration date, it is conceivable that the reason for renewing the key is when the leakage of a private key to a third party is found.
As a technique related to such key update, for example, a technique described in Patent Document 1 can be cited.
Japanese Patent Laid-Open No. 11-122238

However, Patent Document 1 has a description about updating a key issued to each device, but there is no description about updating a root key.
In the case of the public key cryptosystem, when a key pair issued to each device is updated, a new public key certificate corresponding to the new private key is stored in the device, and the communication partner is notified. If this is passed, the authentication process as described above can be performed without any trouble.
However, when updating the root key, the new root key cannot decrypt the digital signature attached to the previous digital certificate, so each new root key and the corresponding new root private key are used. If the public key certificate of the device is not recreated and distributed, it will hinder the execution of the authentication process (however, the private key of each device does not necessarily need to be updated).

Further, since there has been no known method for updating such a root key without hindering the authentication process, the root key cannot be securely transmitted to a device that needs to be updated via the network. Therefore, it has been necessary to deliver a root key certificate and a new public key certificate to each device through another secure route. That is, it is necessary to provide a special communication path for updating the root key.
As this route, for example, registered mail is conceivable, and a recording medium such as a memory card or a flexible disk in which certificate data is recorded is sent to the apparatus administrator by registered mail, and the administrator updates the apparatus key. A method is conceivable. However, this method can be applied only when there is an administrator who has sufficient knowledge about each device of the client and the server, and the CA side trusts the administrator of the device for processing after sending the recording medium. There was only. Therefore, if the administrator neglects or mistakes the update process, there is a problem that the authentication process cannot be performed.

On the other hand, the administrator can only judge whether the received certificate is correct or not by trusting the name of the sender described in the envelope or data, etc. There is always a danger of having the certificate stored in the device.
In addition, it is conceivable that a service provider using a CA or client / server system dispatches a service person to the location of each device to update the key. Service bases are required, which increases costs. In addition, education of service personnel, fraud prevention, and management of an administrator ID for update work are also problems. For example, when trying to adopt a simple method for manually entering authentication information, it is necessary to change the authentication information stored in each device in order to cancel the update authority for a retired serviceman. It is difficult to make such a change to a large number of devices installed in the factory.

  After all, in order to secure a secure distribution route for certificates without going through the network, there is no choice but to trust humans, leaving room for fraud. And although it can be managed to reduce this room, it will entail huge costs, and it is not possible to construct a path for distributing certificates that does not take into account the risk of fraud It was not realistic.

In addition, as a special communication path for update, a communication path using a digital certificate for update processing and a root key certificate for update processing different from the digital certificate and root key certificate used for normal communication It is also possible to prepare. However, such a method has a problem in a system in which the client device authenticates the server device.
In other words, in this case, the server device transmits a digital certificate to the client device when a connection request is received from the client device, but the server device can receive a connection request at an arbitrary timing from an unspecified number of client devices. In this case, it is difficult to appropriately determine which digital certificate for normal communication or update processing should be transmitted to the client device.

  If a determination is made, for example, it is conceivable to use a session identifier such as a source endpoint identifier, a destination endpoint identifier, or a URL (Uniform Resource Locator) at the time of a communication request. However, in order to make such a determination, the client device side is provided with a function for switching the session identifier (for example, URL) depending on whether it is normal communication or update communication, or the server device side has a source endpoint identifier and It becomes necessary to provide a function for managing the correspondence with the digital certificate to be transmitted. Providing such a function leads to an increase in cost.

Accordingly, there has been a demand to avoid providing the server device with a function of selecting a digital certificate to be transmitted to the client device based on information before the start of communication such as a session identifier. In addition, when two types of communication paths are provided using the same protocol, there is a problem that when authentication fails, it is difficult to distinguish whether it is due to a digital certificate error or a session identifier error. .
As described above, providing a special communication path for updating the root key increases the cost and burden of management, so it is desirable to update the root key safely without providing such a special communication path. There was a request.

  The present invention solves such problems, and securely updates a certification key used for confirming the validity of a digital certificate in authentication processing in a client / server system without providing a special communication path for updating. The purpose is to be able to.

  In order to achieve the above object, the update procedure determining method according to the present invention stores each node in a client / server system configured in a plurality of stages in a form in which a higher order node follows a lower order node. In the update procedure determining method for determining the update procedure when the certification key used for confirming the validity of the digital certificate used for authentication is updated by the digital certificate management apparatus capable of communicating with each of the nodes, the digital certificate On the basis of information on whether each of the nodes constituting the client / server system functions as a client or a server between the communication partner of the node and the communication partner, Is used for the above authentication by the target node that can confirm the validity using the new certification key for update and / or the new certification key. A new digital certificate for transmission is determined to include a transmission procedure for transmitting simultaneously for each node, and at that time, a procedure for creating an execution order of the transmission procedure for each of the nodes is executed. These nodes are added in the order of execution, and then each node constituting the client / server system starting from that node is set as the node of interest in order, and the node is the communication partner of the node of interest and is added in the order of execution. When there is no node, it is determined for each of the communication partners whether the node of interest functions as a client or a server when communicating with the communication partner. If the server is added after the node of interest in the order, the communication partner is In which it was to be added to the front than the eye node.

Further, the present invention stores the validity of a digital certificate used for authentication between each node by storing it in each node of a client / server system configured in a plurality of stages in such a manner that the upper node follows the lower node. In an update procedure determining method for determining an update procedure when a certification key used for confirmation is updated by a digital certificate management apparatus communicable with each of the nodes, the digital certificate management apparatus includes the client / server system. For each of the nodes constituting the node, based on the information on the communication partner of the node and whether the node functions as a client or a server, the above update procedure is performed using a new certification key for update and / or A new digital certificate that can be verified using the new certification key and is used by the target node for the above authentication It is determined to include a transmission procedure that transmits simultaneously, and at that time, a procedure for creating an execution order of the transmission procedure for each of the nodes as a work list is executed, and in the procedure, the procedure for initializing the work list, The top node among the nodes constituting the client / server system is set as the node of interest and the procedure for adding to the work list is executed, and the node that has become the node of interest is stored, and then all nodes are noted. An update procedure determination method is also provided in which the following procedures (1) and (2) are repeated until it is determined that the node has been reached.
(1) When there are subordinate nodes in the node of interest, the rank is set below the node of interest for each of the subordinate nodes, and when the node of interest uses the subordinate node as a communication partner, either the client or the server If it is a client, its lower node is added to the rear end of the work list, and if it is a server, its lower node is added to the front end of the work list. If there is a node that has the same rank as that of the node of interest and has not yet become a node of interest, if there is no such node, the above rank is lower than the node of interest and is still a node of interest To change to one of the nodes

  In such an update procedure determination method, when the digital certificate management apparatus has a lower node in the node of interest instead of the procedure (1), the rank of each of the lower nodes is subordinate to the node of interest. And determines whether the node of interest functions as a client or a server when the lower node is a communication partner. If it is a client, the lower node is immediately after the node of interest in the work list. If it is a server, a procedure for adding a subordinate node immediately before the node of interest in the work list may be executed.

The digital certificate management apparatus may repeat the following procedures (1) and (2) instead of the procedures (1) and (2).
(1) When there are subordinate nodes in the node of interest, it is determined whether each of the subordinate nodes functions as a client or a server when the node of interest uses the subordinate node as a communication partner. If the server is a server, add the lower node to the rear end of the work list. If it is a server, add the lower node to the front end of the work list. If there is a node that is not a node, change it to one of them, and if there is no such node, follow the nodes in order toward the upper level, and there is a node with a lower level node that has not yet become a target node To change to one of its subordinate nodes in case

  Further, when the digital certificate management apparatus has a lower node in the node of interest instead of the procedure (1), when the node of interest uses the lower node as a communication partner for each of the lower nodes. If it is a client, its lower node is added immediately after the node of interest in the work list, and if it is a server, its lower node is added to the attention node of the work list. You may make it perform the procedure added just before a node.

  In the update procedure determination method, the digital certificate management apparatus creates a point of interest list for determining a change destination of the node of interest, and the point-of-interest list is also initialized in a procedure for initializing the work list. In the step (2), if there is a lower node in the target node, the target node is added to the rear end of the target point list. If there is a node that is not the node of interest, change the node of interest to that node, and if not, whether or not the new node of interest is determined by the node-of-interest change procedure for deleting the node at the front end of the above point of interest list from the node of interest Repeat until the point of interest list is empty, and if the point of interest list is empty, determine that all nodes have become nodes of interest It may be.

  Alternatively, the digital certificate management apparatus creates a point-of-interest list for determining the change destination of the node of interest, initializes the point-of-interest list in the procedure for initializing the work list, and in step (2) If there is a subordinate node in the target node, the target node is added to the front end of the target point list, and then there is a node that has not yet become a target node in the lower node of the front end node of the target point list. Change the attention node to that node, and if not, change the attention node change procedure to delete the node at the front end of the attention point list from the attention point list until a new attention node is determined or the attention point list becomes empty Repeatedly, when the attention point list becomes empty, it may be determined that all nodes have become attention nodes.

Furthermore, in the node-of-interest changing procedure, if there is one node that has not yet become a node of interest among the lower nodes of the node at the front end of the point-of-interest list, when changing the node of interest to that node, The node at the front end of the attention point list may be deleted from the attention point list.
Furthermore, in each of the update procedure determination methods, the authentication between the nodes may be authentication according to an SSL or TLS protocol, and the digital certificate may be a public key certificate of each node. .

  Further, the program of the present invention provides a computer that controls a digital certificate management apparatus capable of communicating with each node of a client / server system configured in a plurality of stages in such a manner that an upper node follows a lower node. In a program for realizing a function of updating a certification key used for checking the validity of a digital certificate used for authentication between each node stored in each node of the server system, For each node that constitutes a client / server system, the above update procedure is changed to a new one for update based on the communication partner of the node and whether the node functions as a client or a server. The target node that can confirm the validity using the certification key and / or the new certification key is A procedure for realizing a function for defining a new digital certificate to be used for each node to include a transmission procedure for transmitting simultaneously for each node, and for determining the update procedure, forming a sequence for executing the transmission procedure for each node In that procedure, first, add any node in the above execution order, then start from that node and make each node that constitutes the above-mentioned client / server system one by one as the node of interest and become the communication partner of the node of interest When there is a node that is not added in the execution order, it is determined for each of the communication partners whether the node of interest functions as a client or a server when communicating with the communication partner, If it is a client, the communication partner is added after the node of interest in the execution order, and the server The communication partner is a program for executing the steps to add before the target node among the execution order if Re.

In addition, the present invention provides a computer that controls a digital certificate management apparatus capable of communicating with each node of a client / server system configured in a plurality of stages in such a manner that an upper node follows a lower node. Is stored in each node, and a program for realizing a function of updating a certification key used for confirming the validity of a digital certificate used for authentication between the nodes, and For each node that constitutes a client / server system, the above update procedure is changed to a new one for update based on the communication partner of the node and whether the node functions as a client or a server. Used for the above authentication by the target node that can confirm the validity using the certification key and / or the new certification key Of creating a new digital certificate for each node at the same time so as to include a transmission procedure for simultaneously transmitting each node, and creating an execution order of the transmission procedure for each node when determining the update procedure In the procedure, the procedure for initializing the work list and the procedure for setting the highest node among the nodes constituting the client / server system as the target node and adding to the work list are executed. Further, a program for storing the node that has become the attention node and repeatedly executing the following procedures (1) and (2) until it is determined that all the nodes have become the attention node is provided.
(1) When there are subordinate nodes in the node of interest, the rank is set below the node of interest for each of the subordinate nodes, and when the node of interest uses the subordinate node as a communication partner, either the client or the server If it is a client, its lower node is added to the rear end of the work list, and if it is a server, its lower node is added to the front end of the work list. If there is a node that has the same rank as that of the node of interest and has not yet become a node of interest, if there is no such node, the above rank is lower than the node of interest and is still a node of interest To change to one of the nodes

  In such a program, instead of the procedure (1) in the computer, when there are subordinate nodes in the node of interest, the rank is set below the node of interest for each of the subordinate nodes, and the node of interest Determines whether it functions as a client or a server when its lower node is a communication partner. If it is a client, the lower node is added immediately after the node of interest in the work list. You may make it perform the procedure which adds the subordinate node just before the said attention node in the said work list | wrist.

Alternatively, the computer may be caused to repeatedly execute the following procedures (1) and (2) instead of the procedures (1) and (2).
(1) When there are subordinate nodes in the node of interest, it is determined whether each of the subordinate nodes functions as a client or a server when the node of interest uses the subordinate node as a communication partner. If the server is a server, add the lower node to the rear end of the work list. If it is a server, add the lower node to the front end of the work list. If there is a node that is not a node, change it to one of them, and if there is no such node, follow the nodes in order toward the upper level, and there is a node with a lower level node that has not yet become a target node To change to one of its subordinate nodes in case

  Further, if there is a lower node in the target node instead of the procedure (1) in the computer, for each lower node, when the target node makes the lower node a communication partner, the client and server If it is a client, its lower node is added immediately after the node of interest in the work list, and if it is a server, its lower node is added immediately before the node of interest in the work list. You may make it perform the procedure to add.

  Further, in the above program, the computer realizes a function of creating a point of interest list for determining a change destination of the node of interest, and initializes the point of interest list in a procedure for initializing the work list, In step (2), if there is a lower node in the node of interest, the node of interest is added to the rear end of the point of interest list, and then the node of interest is still a lower node of the node at the front end of the point of interest list. If there is a node that is not, the attention node is changed to that node, and if not, the attention node changing procedure for deleting the node at the front end of the attention point list from the attention point list is performed. Repeat until the list of points is empty, and when the list of points of interest is empty, it is determined that all nodes have become nodes of interest. It may further include the order of the program.

  Alternatively, the computer realizes a function of creating a point of interest list for determining a change destination of the node of interest, and initializes the point of interest list in the procedure of initializing the work list, and the procedure (2) In the case where there is a lower node in the target node, the target node is added to the front end of the target point list, and then a node that is not a target node among the lower nodes of the front end node of the target point list is If there is a new attention node, the attention node list is emptied by changing the attention node changing procedure to change the attention node to that node if there is, or to delete the node at the front end of the attention point list from the attention point list. Until the above list of attention points is empty, and a program for determining that all nodes have become attention nodes It may be included in La.

  Further, in each of the above programs, the authentication may be authentication according to an SSL or TLS protocol, and the digital certificate may be a public key certificate of each node.

  The digital certificate management system according to the present invention is a client / server system that is configured in a plurality of stages so that an upper node follows a lower node, and performs authentication using a digital certificate between the nodes. In the digital certificate management system in which a digital certificate management device communicable with each node is connected, the digital certificate management device confirms the validity of the digital certificate used by each node for the authentication. Information about whether to function as a client or a server between the communication partner of the node and the communication partner of each node constituting the client / server system. Based on the above, update order control means for controlling the certification key update procedure by the certification key update means is provided. Means for obtaining a new certification key for updating in the key updating means, means for obtaining a new digital certificate for use in the authentication, the validity of which can be confirmed using the new certification key, A transmission means for transmitting the new digital certificate for the node and / or the new certification key to the corresponding node, and the update order control means is determined using any one of the update procedure determination methods described above It is a means for performing the control according to the update procedure.

  The digital certificate management apparatus according to the present invention comprises a client / server system configured in a plurality of stages in such a manner that an upper node follows a lower node, and performs authentication using a digital certificate between the nodes. In a digital certificate management apparatus communicable with each node constituting, a certification key update means for updating a certification key for confirming the validity of the digital certificate used by each node for the authentication, and the client For each node constituting the server system, the certification key update procedure by the certification key update means is performed based on the communication partner of the node and whether the node functions as a client or a server. An update order control means for controlling is provided, and a means for acquiring a new certification key for updating and a new certification key are used as the certification key updating means. Means for obtaining a new digital certificate for use in the authentication that can be verified, and transmission for transmitting the new digital certificate and / or the new certification key for each of the nodes to a corresponding node. And the update order control means is a means for performing the control according to an update procedure determined using any one of the update procedure determination methods described above.

According to the update procedure determination method of the present invention as described above, an appropriate procedure of update processing for updating the certification key used for confirming the validity of the digital certificate in the authentication processing in the client / server system is determined. Therefore, by causing an appropriate update device to perform the update process according to this procedure, the certification key can be updated safely without providing a special communication path for update.
In addition, according to the digital certificate management system and the digital certificate management apparatus of the present invention, the certification key can be updated as described above in an appropriate procedure, so that the same effect as described above can be obtained. it can.
Further, according to the program of the present invention, the digital certificate management apparatus can be controlled by a computer to realize the characteristics of such a digital certificate management apparatus, and the same effect can be obtained.

Preferred embodiments of the present invention will be described below with reference to the drawings.
[First Embodiment: FIGS. 1 to 9]
First, a configuration of a first embodiment of a digital certificate management system according to the present invention, which is constituted by a certificate management device which is a digital certificate management device according to the present invention, and a client and a server constituting a client / server system. explain. In this embodiment, each client and server constitutes a client / server system, and this embodiment is an example in which the present invention is applied to the most basic system. FIG. 2 is a functional block diagram showing a functional configuration of a part that is a feature of this embodiment of each apparatus constituting the digital certificate management system. In FIG. 2, illustration of portions not related to the features of this embodiment is omitted.

As shown in FIG. 2, the digital certificate management system includes a certificate management device 10, a server device 30, and a client device 40.
When the client device (client) 40 and the server device (server) 30 authenticate each other as a valid communication partner by an authentication process using SSL, which is an authentication method using public key cryptography and a digital certificate, they communicate with each other. I try to establish it. As described later, this authentication may be mutual authentication in which each other authenticates each other or one-way authentication in which one authenticates the other. In response to the request transmitted by the client device 40, the server device 30 performs a necessary process and returns a response, thereby functioning as a client / server system. The certificate management apparatus 10 is an apparatus for issuing a digital certificate used for the authentication process and managing or updating the digital certificate, and corresponds to a CA.

  In an actual system, the server device 30 may have a client function, or the client device 40 may have a server function. The server device 30 may function as a client and transmit a request to the client device 40 functioning as a server. In such a case, if an operation according to a modified example described later is performed, Good. Therefore, here, a device functioning as a server in a root key update process described later is referred to as a server device, and a device functioning as a client is referred to as a client device.

  In such a digital certificate management system, each node of the certificate management device 10, the server device 30, and the client device 40, including transmission from the client device 40 to the server device 30, is performed by RPC (remote procedure call). In addition, a “request” that is a request for a process for a method of an application program to be mounted on each other can be transmitted, and a “response” that is a result of the requested process can be acquired.

That is, the server device 30 or the client device 40 can generate a request to the certificate management device 10 and deliver it to the certificate management device 10 to obtain a response to the request. A request to the client / server system side is generated and delivered to the server device 30 to obtain a response to the request. This request includes causing the server device 30 to transmit various requests to the client device 40 and obtaining a response from the client device 40 via the server device 30.
In order to realize RPC, SOAP (Simple Object Access Protocol), HTTP (Hyper Text Transfer Protocol), FTP (File Transfer Protocol), COM (Component Object Model), CORBA (Common Object Request Broker Architecture), etc. are known. Protocols (communication standards), technology, specifications, etc. can be used.

The transmission / reception data transmission / reception model is shown in the conceptual diagram of FIG.
(A) is a case where a request for the client device 40 has occurred in the certificate management device 10. In this case, the certificate management apparatus 10 generates a management apparatus side request a, and the client apparatus 40 that receives the request via the server apparatus 30 returns a response a to the request. Note that (A) shows a case in which not only the response a but also a response delay notification a ′ is returned. When the client device 40 receives the management device side request a via the server device 30 and determines that the response to the request cannot be returned immediately, it notifies the response delay notification and temporarily disconnects the connection state. This is because the response to the request is delivered again at the next connection.
Here, since the server device 30 cannot request the client device 40 to communicate, a request to be transmitted from the server device 30 to the client device 40 is connected from the client device 40 to the server device 30. If there is a request, it will be sent as a response to this.

  (B) is a case where a request for the certificate management apparatus 10 has occurred in the client apparatus 40. In this case, the client device 40 generates a client device side request b, and the certificate management device 10 that has received the request b via the server device 30 returns a response b to the request. Even in the case of (B), the response delay notification b ′ is returned in the same manner as in the case of (A) when the response cannot be returned immediately.

Next, the configuration and function of each device constituting the digital certificate management system will be described in more detail.
FIG. 1 is a block diagram showing a hardware configuration of the certificate management apparatus shown in FIG. As shown in this figure, the certificate management apparatus 10 includes a CPU 11, a ROM 12, a RAM 13, an HDD 14, and a communication interface (I / F) 15, which are connected by a system bus 16. Then, the CPU 11 controls the operation of the certificate management apparatus 10 by executing various control programs stored in the ROM 12 and the HDD 14, and as will be described later, each means (certification key update means, update order) according to the present invention. Control means, transmission means, and other means).
As hardware of the certificate management apparatus 10, a known computer can be adopted as appropriate. Of course, other hardware may be added as necessary.

  The client device and the server device constituting the client / server system can have various configurations depending on purposes such as remote management of the device and electronic commerce. For example, in the case of remote management, image processing devices such as printers, fax machines, copiers, scanners, digital multifunction devices, network home appliances, vending machines, medical equipment, power supply devices, air conditioning systems, gas / water / An electronic device such as an electric metering system, an automobile, or an aircraft is a server device that is a managed device, and a client device is a management device that collects information from these managed devices or sends commands to operate. It can be considered.

However, each of the client device and the server device includes at least a CPU, a ROM, a RAM, a communication I / F for communicating with an external device via a network, and storage means for storing information necessary for authentication processing. It is assumed that the device can function as a client or a server by executing a required control program stored in a ROM or the like.
Note that various communication lines (communication paths) capable of constructing a network can be adopted for this communication regardless of wired or wireless. The same applies to communication with the certificate management apparatus 10.

As described above, FIG. 2 shows the functional configuration of the part of each embodiment that is a feature of this embodiment.
First, the certificate management apparatus 10 includes a certification key creation unit 21, a certificate issuance unit 22, a certificate management unit 23, a certificate update unit 24, a communication function unit 25, a configuration storage unit 26, and an update order control unit 27. I have.
The certification key creation unit 21 has a root private key, which is a private key for certification used for creating a digital signature, and a certification public key (certification corresponding to the root private key for confirming the validity of the digital certificate). It has a function of a certification key creation means for creating a root key that is a key.

The certificate issuing unit 22 attaches a digital signature to the client public key and server public key, which are authentication information used for authentication processing between the server device 30 and the client device 40, and is a client public key certificate that is a digital certificate. Certificate issuing means for issuing a certificate and a server public key certificate. The function of the certificate issuing unit 22 is also used to create a client public key, a client private key, a server public key, a server private key, and a root key certificate that is a digital certificate with a digital signature attached to the root key. It is.
The certificate management unit 23 has a function of a certificate management unit that manages the digital certificate issued by the certificate issuing unit 22, the root private key used to create the certificate, and the root key corresponding to the root private key. These certificates and keys are stored together with information such as the expiration date, issue destination, ID, and presence / absence of update.

  When updating the root key, the certificate updating unit 24 creates a new root private key (new root private key) and a corresponding new root key (new root key) for each valid root private key. Are created by the certification key creation unit 21 and have a function of certification key update means for updating them. Further, upon this update, a new client public key certificate (new client public key certificate) digitally signed using a new root private key to the certificate issuing unit 22, a new server public key certificate (new server) Public key certificate) and a new root key certificate (new root key certificate) are issued, and these are transmitted to the server device 30 and the client device 40 by the communication function unit 25. It also has a function for requesting an update of. Although details will be described later, the update order control unit 27 manages the procedures and progress of each process necessary for the update.

The communication function unit 25 has a function of communicating with an external device via a network, and transmits necessary data to the server device 30 and the client device 40 according to an instruction from the certificate update unit 24, and receives received data. To the certificate renewal unit 24.
The configuration storage unit 26 has at least communication partners of the nodes (here, the server device 30 and the client device 40) constituting the client / server system that is the object of which the certificate management device 10 manages digital certificates. And information on whether to function as a client or a server with the communication partner, and has a function of a configuration storage means. Here, it is also assumed that private nodes, public key certificates, and root key certificate IDs used by each node for mutual authentication, and information on the update status of the keys and certificates are also stored.

The update order control unit 27 determines a key or certificate update procedure by the certificate update unit 24 based on the information stored in the configuration storage unit 26 when the root key needs to be updated. The certificate update unit 24 performs an update operation and functions as an update order control unit that controls the update operation.
The functions of these units are realized by the CPU 11 shown in FIG. 1 executing a required control program and controlling the operations of the units of the certificate management apparatus 10.

On the other hand, the server device 30 includes a certificate storage unit 31, a communication function unit 32, and a server function unit 33.
The certificate storage unit 31 has a function of storing keys used for SSL authentication processing. For example, when performing mutual authentication, the certificate storage unit 31 stores a root key certificate, a server private key, and a server public key certificate.
The communication function unit 32 has a function of communicating with an external device via a network, passes received data to the server function unit 33, and transmits data to the external device in accordance with an instruction from the server function unit 33.

The server function unit 33 has a function as a server that performs a required process on the request received from the client device 40 and returns a response. Further, as will be described in detail below, in response to a request for certificate update or the like received from the certificate management apparatus 10, a required process is performed and a response is returned.
The functions of these units are realized by the CPU of the server device 30 executing a required control program and controlling the operations of the units of the server device 30.

The client device 40 includes a certificate storage unit 41, a communication function unit 42, and a client function unit 43.
The certificate storage unit 41 has a function of storing keys used for SSL authentication processing. For example, when performing mutual authentication, the certificate storage unit 41 stores a root key certificate, a client private key, and a client public key certificate.
The communication function unit 42 has a function of communicating with an external device via a network, passes received data to the client function unit 43, and transmits data to the external device in accordance with an instruction from the client function unit 43.

The client function unit 43 transmits a required request to the server device 30 triggered by an operation from the user, a state change detected by a sensor (not shown), or a predetermined time measured by a timer (not shown). When a response to this is received from 30, it has a function as a client that performs processing according to the content. Further, as will be described in detail below, when a request for certificate renewal or the like from the certificate management apparatus 10 is received as a response, a required process is performed and a response is returned.
The functions of these units are realized by the CPU of the client device 40 executing a required control program and controlling the operations of the units of the client device 40.

In this digital certificate management apparatus, the certificate management apparatus 10 can communicate directly only with the server apparatus 30 among the apparatuses constituting the client / server system. A request from the certificate management apparatus 10 to the client apparatus 40 is as follows. The server device 30 relays and sends it. The same applies to the response from the client device 40 to the certificate management device 10.
The server device 30 and the client device 40 store the initial root key at the time of shipment from the factory or at the same time, at least before the user starts the authentication process. At this time, both the public key certificate and the private key may be stored.

Next, a root key update process, which is a process related to the feature of this embodiment in the digital certificate management system shown in FIG. 2 having such basic functions, and a configuration necessary for the process will be described.
In the communication process between the server apparatus 30 and the client apparatus 40 described in the sequence diagram used in the following description, although not shown individually, an authentication process by SSL is performed before a secure communication path is established. Only when the authentication is successful, the data is transferred through the communication path secured by the SSL. A feature of this embodiment is that the root key certificate can be updated so as not to hinder the authentication processing. The same applies to the following embodiments.
Here, the communication between the certificate management apparatus 10 and the server apparatus 30 is performed via a communication path such as a direct communication line that can ensure safety (no data tampering or wiretapping).

Here, first, a communication procedure when the authentication process is performed using the above-described SSL will be described. As this authentication process, mutual authentication in which each other authenticates each other and one-way authentication in which one authenticates the other can be considered, and either method may be adopted in each embodiment. explain.
FIG. 4 is a diagram illustrating a flowchart of processing executed in each device when the client device and the server device perform mutual authentication by SSL, together with information used for the processing.
As shown in FIG. 4, when performing mutual authentication by SSL, first, a root key certificate, a client private key, and a client public key certificate (client certificate) are stored on the client device 40 side. The client private key is a private key issued to the client device 40 by the certificate management device 10. The client public key certificate is a certificate obtained by adding a digital signature to the public key corresponding to the private key by the certificate management apparatus 10. The root key certificate is a root key that is a certification public key (hereinafter also referred to as “certification key”) corresponding to a root private key that is a private key for certification used by the certificate management apparatus 10 for digital signature. This is a digital certificate with a digital signature.

Further, a root key certificate, a server private key, and a server public key certificate (server certificate) are stored on the server device 30 side. The server private key and the server public key certificate are a private key and a public key certificate issued to the server device 30 by the certificate management device 10. Here, it is assumed that the same certificate management apparatus 10 issues a certificate using the same root private key to the client apparatus 40 and the server apparatus 30, and therefore the root key certificate is the client apparatus 40 and the server apparatus 30. It becomes common.
The relationship between these keys and certificates is as described with reference to FIG. 58 in the background art section.

  The description of the flowchart begins. In FIG. 4, the arrow between the two flowcharts indicates data transfer, the transmission side performs the transfer process at the step at the base of the arrow, and the reception side receives the information, the process at the tip of the arrow Shall be performed. In addition, if the process of each step is not completed normally, an authentication failure response is returned at that time and the process is interrupted. The same applies to the case where an authentication failure response is received from the other party or the process times out.

When the CPU of the client device 40 requests the server device 30 to perform communication, the CPU of the client device 40 starts the processing of the flowchart shown on the left side of FIG. 4 by executing a required control program. In step S11, a connection request is transmitted to the server device.
On the other hand, when receiving the connection request, the CPU of the server device 30 starts the processing of the flowchart shown on the right side of FIG. 4 by executing a required control program. In step S21, a first random number is generated, and this is encrypted using the server private key. In step S22, the encrypted first random number and server public key certificate are transmitted to the client device 40.

Upon receiving this, the client device 40 confirms the validity of the server public key certificate using the root key certificate in step S12. This includes processing for confirming that the server device 30 is an appropriate communication partner by referring to the bibliographic information as well as confirming that there is no damage or tampering.
If it can be confirmed, in step S13, the first random number is decrypted using the server public key included in the received server public key certificate. If the decryption is successful, it can be confirmed that the first random number has been received from the server device 30 that is the server public key certificate issuance target. Then, the server device 30 is authenticated as a valid communication partner.

  Thereafter, in step S14, a second random number and a third random number are generated separately. In step S15, the second random number is encrypted using the client private key, and the third random number is encrypted using the server public key. In step S16, these are transmitted to the server device 30 together with the client public key certificate. . The encryption of the third random number is performed so that the random number is not known to devices other than the server device 30.

  Upon receiving this, the server device 30 confirms the validity of the client public key certificate using the root key certificate in step S23. This also includes processing for confirming that the client device 40 is an appropriate communication partner, as in step S12. If it can be confirmed, in step S24, the second random number is decrypted using the client public key included in the received client public key certificate. Here, if the decryption is successful, it can be confirmed that the second random number is certainly received from the client device 40 that is the client public key certificate issuance target. Then, the client device 40 is authenticated as a valid communication partner.

  Thereafter, in step S25, the third random number is decrypted using the server private key. Through the processing so far, the first to third random numbers common to the server side and the client side are shared. And at least the third random number is not known by any device other than the generated client device 40 and the server device 30 having the server private key. If the processing so far is successful, a response of successful authentication is returned to the client device 40 in step S26.

When this is received, the client device 40 generates a common key from the first to third random numbers in step S17, and ends the authentication process as being used for subsequent communication encryption. On the server device 30 side, the same processing is performed in step S27 and the process is terminated. Then, communication is established with the above processing, and thereafter, communication is performed by encrypting data by the common key encryption method using the common key generated in step S17 or S27.
By performing such processing, the client device 40 and the server device 30 can securely exchange a common key after mutually authenticating each other, and can securely communicate with a certain partner.

In the case of one-way authentication, the process shown in FIG. 4 can be simplified as shown in FIG. That is, in this case, it is not essential to encrypt the second random number with the client private key and send the public key certificate A to the communication device B. In this case, the processing of steps S23 and S24 on the server device 30 side is not necessary. In this way, the server device 30 cannot authenticate the client device 40, but this processing is sufficient when the client device 40 only needs to authenticate the server device 30.
In this case, only the root key certificate may be stored in the client device 40, and the client private key and the client public key certificate are unnecessary. Further, it is not necessary for the server device 30 to store the root key certificate. Therefore, in this case, the update process of each root key certificate described below can be simplified to the process of updating only the root key certificate of the client device 40 and the server public key certificate of the server device 30. .

Next, the description will proceed to the update process of the root key certificate. In the root key update process described here, the processes shown in the sequence diagrams of FIGS. 6 to 9 are executed in this order. The processes shown in the following drawings are performed by the CPUs of the certificate management apparatus 10, the server apparatus 30, and the client apparatus 40 by executing a required control program.
When the certificate management apparatus 10 of this digital certificate management system detects the reason for updating the root key, it starts the processing shown in the sequence diagram of FIG.

First, the root key certificate creation process is shown as process S in the sequence diagram of FIG.
In this process, the certificate management apparatus 10 creates a new root private key / root key pair for a valid root private key in step S101. Here, the “valid” root private key means the root private key currently used for authentication processing in the client / server system. More precisely, the root private key is used to sign a digital signature. It is assumed that the attached certificate is stored in the server device 30 or the client device 40 in a state used for authentication processing. Whether or not the private key created in the past is valid is stored in the configuration storage unit 26, the expiration date of the public key certificate and the root key certificate stored in the certificate management unit 23, information on whether or not to update the certificate. Judgment is based on information such as the ID information of the public key certificate and root key certificate used by each node and the identification information of the root private key used for the digital signature included in the certificate. be able to. Also, the previous key that should be replaced with the new key will be referred to as the “old” key. The same applies to certificates.

In the next step S102, a digital signature using the previous root private key is attached to the new root key created in step S101, and a distribution root key certificate which is a first certification key certificate is created.
Further, in step S103, a digital signature using the new root private key is attached to the new root key created in step S101 to create a new root key certificate as a second certification key certificate.
The above is the root key certificate creation process.

Then, the process 1 shown in the sequence diagram of FIG. 7 is performed.
Here, first, in step S111, the certificate management apparatus 10 attaches a digital signature using the new root private key to the client public key issued to the client apparatus 40, and obtains a new client public key certificate. create. Since the client private key is not updated, it is not necessary to update the client public key itself.

In step S112, the certificate management apparatus 10 sends the distribution root key certificate created in step S102 of FIG. 6, the new root key certificate created in step S103 of FIG. Along with the new client public key certificate created in S111, an update request transmission request for transmitting an update request for these to the client device 40 is transmitted.
In response to this, the server device 30 transmits the distribution root key certificate and its update request to the client device 40, but cannot send a transmission request from the server device 30 side. Therefore, the client device 40 periodically transmits a communication request to the server device 30 at a predetermined timing to request communication (S113), and in response to this, a distribution root key certificate and its update request Is transmitted (S114).

  The client device 40 transmits a communication request or connection request to the server device 30 as an HTTP request, and transmits a request or data to be transmitted from the server device 30 to the client device 40 as an HTTP response that is a response thereto. Good. In this way, even when the client device 40 is installed inside the firewall, data can be transferred from the server device 30 to the client device 40 beyond this.

Means beyond the firewall are not limited to this, and it is also conceivable to use, for example, SMTP (Simple Mail Transfer Protocol) to transmit a mail in which data to be transmitted is described or attached. However, HTTP is superior in terms of reliability.
Through the above process, each certificate and its update request are transmitted from the certificate management apparatus 10 to the client apparatus 40 via the server apparatus 30, and the process of step S112 is the process of the transmission procedure. In this process, the CPU 11 of the certificate management apparatus 10 functions as a transmission unit.

Upon receiving this request, the client device 40 confirms the validity of the distribution root key certificate using the previous root key certificate in step S115. As described above, the distribution root key certificate has a digital signature using the previous root private key, so the contents are stored using the previous root key included in the previous root key certificate. It is possible to confirm that it has been decrypted and has been issued by the certificate management apparatus 10. At this time, as described with reference to FIG. 73 in the section of the prior art, it can also be confirmed that the root key is not damaged or falsified. Therefore, by using such a distribution root key certificate, the legitimacy of the received root key can be confirmed without manual intervention.
If this can be confirmed, the distribution root key certificate is stored in the certificate storage unit 31 in the next step S116.

In step S117, the validity of the new root key certificate is confirmed using the distribution root key certificate. As described above, since the digital signature using the new root private key is attached to the new root key certificate, the contents are decrypted using the new root key included in the distribution root key certificate, It can be confirmed that the certificate has been issued by the certificate management apparatus 10.
If this can be confirmed, the new root key certificate is stored in the certificate storage unit 31 in the next step S118. At this point, the distribution root key may be deleted, but it is stored here. Accordingly, three root key certificates are stored in the certificate storage unit 31.

  When performing authentication processing in this state, when verifying the validity of the received public key certificate, the authentication is attempted using the previous root key certificate and the new root key certificate in sequence, and either of the root keys is verified. If the confirmation is successful using the certificate, the validity is confirmed. Accordingly, it is possible to confirm the validity of a digital certificate with a digital signature using either the old or new root private key.

In step S119, the validity of the new client public key certificate is confirmed using the new root key certificate stored in step S118. As described above, since the new client public key certificate has a digital signature using the new root private key, the contents are decrypted using the new root key included in the new root key certificate. It can be confirmed that the certificate has been issued to the client device 40 by the certificate management device 10. If this can be confirmed, the new client public key certificate is stored in the certificate storage unit 41 in the next step S120.
In steps S115 to S120 described above, the CPU of the client device 40 functions as a client-side update unit.

At this time, the previous client public key certificate is not yet deleted. Therefore, the certificate storage unit 41 stores two client public key certificates. When authentication processing is performed in this state and a public key certificate is transmitted to a communication partner, first, a new public key certificate is transmitted.
In this case, if the communication partner has already stored the new root key (as a distribution root key certificate or a new root key certificate), the digital signature of the new public key certificate can be decrypted. Can receive. On the other hand, if the communication partner has not yet stored the new root key, the digital signature of the new public key certificate cannot be decrypted, and a response indicating that the authentication has failed is received. However, even in this case, if the communication is requested again and the previous public key certificate is transmitted at this time, the digital signature attached to the previous root key can be decrypted, so that the authentication can be performed without any problem. Can receive.

Therefore, if two public key certificates are stored, some overhead may occur when the communication partner does not store the new root key, but the authentication process can be performed without any problem. Since the public key bodies included in the two public key certificates are the same, the decryption of the data encrypted using the client private key is the same regardless of which public key certificate is used. It can be carried out.
Here, since the new root key is not stored in the server device 30 yet, the server device 30 cannot decrypt the digital signature of the new public key certificate and receives a response indicating that the authentication has failed. However, as described above, if communication is requested again and the previous public key certificate is transmitted at this time, the digital signature attached thereto can be decrypted by the previous root key, so that authentication can be performed without any problem. Can do it.

Note that the processing in steps S119 and S120 may be performed before the processing in steps S117 and S118. In this case, the validity is confirmed in step S119 using the distribution root key certificate.
Thereafter, in step S121, the client device 40 returns a result notification to the certificate management device 10 as a response to the update request. If the storage of each certificate has been successful, that fact indicates that it has failed for some reason. Tell that. This result notification is information indicating that at least the client device 40 has received the distribution root key certificate, the new root key certificate, and the new client public key certificate. The following result notifications have the same meaning. The result notification is first transmitted to the server device 30, and the server device 30 transmits it to the certificate management device in step S122.

Subsequently, the process 2 shown in the sequence diagram of FIG. 8 is performed.
Here, first, in step S123, the certificate management apparatus 10 creates a new server public key certificate by attaching a digital signature using the new root private key to the server public key issued to the client apparatus 40. To do. The fact that the server public key itself does not need to be updated is similar to the case of the client public key described above.

In step S124, the certificate management apparatus 10 sends the server apparatus 30 the distribution root key certificate created in step S102 in FIG. 6, the new root key certificate created in step S103 in FIG. An update request for these is sent together with the new server public key certificate created in step S123. The process of step S124 is also a transmission procedure process. In this process, the CPU 11 of the certificate management apparatus 10 functions as a transmission unit.
Upon receiving this request, the server device 30 confirms the validity of the distribution root key certificate using the previous root key certificate in steps S125 and S126, as in steps S115 and S116 of FIG. If this can be confirmed, the distribution root key certificate is stored in the certificate storage unit 31. At this time, the previous root key certificate is not deleted yet.

In step S127, the validity of the new root key certificate is confirmed using the stored distribution root key certificate in the same manner as in step S117 of FIG. If this can be confirmed, the new root key certificate is stored in the certificate storage unit 31 in the next step S128, and the distribution root key certificate and the previous root key certificate are discarded.
In this case, the digital certificate with the digital signature using the conventional root private key cannot be decrypted. At this point, the client device 40 has already stored the new client public key certificate. The confirmation of the public key certificate sent from the client device 40 is not hindered, and the authentication process is not hindered. Therefore, the conventional root key is unnecessary, and the processing procedure becomes simpler if it is discarded here rather than making a request for discarding again. Of course, the certificate management apparatus 10 may make a request for discarding again and discard the request when the request is received.

Next, in steps S129 and S130, as in steps S119 and S120 in FIG. 7, the validity of the new server public key certificate is confirmed using the new root key certificate. The public key certificate is stored in the certificate storage unit 31. However, here, the new server public key certificate is replaced with the previous server public key certificate.
In steps S125 to S130 described above, the CPU of the server device 30 functions as a server-side update unit.

Here, in the case of the server device 30, unlike the case of the client device 40, when the new public key certificate is stored, it is replaced with this instead of being added to the previous one. explain.
In the case of the server device 30, the public key certificate is transmitted to the client device 40 when there is a connection request from the client device 40, but if a plurality of server public key certificates are stored, One of them will be selected and transmitted. If the server public key certificate that cannot decrypt the digital certificate is transmitted on the client device 40 side, the authentication fails. For example, when the client device 40 transmits a new server public key certificate before storing the new root key.

  Even if it fails, there is an idea that the next server public key certificate should be sent when there is a next connection request, but it can receive a connection request from an unspecified number of client devices at any time In the case of a server device, it is not realistic to select a server public key certificate to be transmitted for each client device. In addition, it is difficult to properly select the server public key certificate to be transmitted first because the server device usually does not know what the client device is until authentication is completed. Therefore, it is necessary to store only one server public key certificate in the server device and always transmit this when a connection request is received from the client device.

For this reason, the server device 30 deletes the previous server public key certificate when the new server public key certificate is stored, but this is performed before the client device 40 stores the new root key. If this happens, the digital signature of the server public key certificate cannot be decrypted on the client device side, and authentication processing cannot be performed. Therefore, the process for storing the public key certificate in the server apparatus 30 needs to be performed after the process for storing the new root key in the client apparatus is completed.
Here, since the new root key is already stored in the client device 40 at the time of step S130, there is no problem in the authentication process if the new server public key certificate is stored in the server device 30.

Note that the processing in steps S129 and S130 may be performed before the processing in steps S127 and S128. In this case, confirmation of validity in step S129 is performed using the distribution root key certificate.
The server device 30 then returns a result notification as a response to the update request to the certificate management device 10 in step S131.
With the processing shown in FIG. 8, the root key update processing is completed on the server device 30 side.

Thereafter, the process 3 shown in the sequence diagram of FIG. 9 is performed.
Here, first, in step S132, the certificate management apparatus 10 requests the server apparatus 30 to transmit to the client apparatus 40 an old key discard request that requests the server apparatus 30 to discard an unnecessary digital certificate. Send a request. In response to this, the server device 30 transmits an old key discard request as a response to the communication request (S133) from the client device 40 (S134), as in steps S113 and S114 of FIG. .
Through the above processing, the old key discard request is transmitted from the certificate management apparatus 10 to the client apparatus 40 via the server apparatus 30.

Upon receiving this request, the client device 40 discards the distribution root key certificate, the previous root key certificate, and the previous client public key certificate stored in the certificate storage unit 41 in step S135. . At this time, since the new root key certificate and the new server public key certificate are stored in the server device 30, even if these certificates are deleted, the authentication process is not affected. Rather, since these certificates are no longer used for authentication processing, they should be deleted to save storage space.
Thereafter, the client device 40 returns a result notification as a response to the update request to the certificate management device 10 in step S136. This is first transmitted to the server device 30, and the server device 30 manages the certificate in step S137. Transmit to the device 10.
Thus, the root key update process is completed.

  Each of the processes 1 to 3 can be completed when the certificate management apparatus 10 receives a successful response to the transmitted request. As described above, this response also includes information indicating that the transmitted certificate or the like has been received. If an update failure response is received or if the process times out, the same process may be tried again, but if the process fails for a predetermined number of times, the entire update process may have failed.

  Here, as shown in FIG. 8 and the like, when the certificate management apparatus 10 transmits an update request to the server apparatus 30, the server apparatus 30 completes storage of the received certificate and the like, and notifies the result notification. Explained how to return. However, as shown in FIG. 10 (illustration of steps S126 to S129 is omitted), when the server device 30 receives an update request, a reception response may be immediately returned (S124 ′). In this case, the reception response in step S124 ′ becomes information indicating that the update request and the distribution root key certificate transmitted by the certificate management apparatus 10 have been normally received. In addition, the result notification in step S131 is information that conveys the success or failure of the update and the cause thereof. In response to this result notification, the certificate management apparatus 10 may return a reception response (S131 ′). In this way, the server apparatus 30 can also grasp that the result notification has been received normally by the certificate management apparatus 10.

The communication procedure between the server device 30 and the client device 40 is the same procedure. When any request is received, a reception response is immediately returned to the transmission source, and the result notification is also received. In such a case, a reception response should be immediately returned to the transmission source. FIG. 11 shows a sequence in which the above concept is adopted in the sequence shown in FIG. However, illustration of steps S116 to S119 is omitted.
Note that the reception response in step S114 ′ is information indicating that the client device 40 has received the update request, the distribution root key certificate, etc., but the sequence simply adopts the above concept in the sequence shown in FIG. Then, this information is not transmitted to the certificate management apparatus 10 until the server apparatus 30 notifies the result of step S122.
Therefore, as indicated by a broken line in FIG. 11, after receiving a reception response from the client device 40, the server device 30 may notify the certificate management device 10 of only transmission success / failure as a transmission result notification. Good. In this way, success or failure of transmission to the client device 40 can be promptly notified to the certificate management device 10.

In addition, when the result notification is performed as described above, in the execution timing management of each process, when there is a reception response from the transmission destination such as a certificate, the storage and setting of the certificate is not delayed at the transmission destination. It is also possible to proceed to the previous stage with the prediction that it will proceed. Specifically, even if the process 1 is not completely completed, if there is a transmission result notification as shown in step SA of FIG. 11, the process 1 is determined to be completed and the start time of the process 2 is determined. You may do it. Even if the processing 2 is not completed, if there is a reception response as shown in step S124 ′ in FIG. 10, it is assumed that the processing 2 is completed and the start time of the processing 3 is determined. Also good.
10 and FIG. 11 only show modified examples of the sequences of FIG. 8 and FIG. 7, respectively. However, the above concept includes those shown in the following examples and modified examples. It can be applied to all processes and sequences.

  In this digital certificate management system, the root key can be automatically controlled without greatly affecting the authentication process between the server apparatus 30 and the client apparatus 40 by performing the root key update process in such a procedure. Can be updated. Also, authentication is performed using the previous (before update) root key and public key certificate to secure a communication path by SSL, and a new root key and new public key certificate for update are transmitted through the communication path. be able to. Further, after the update is completed, authentication using the new root key or new public key certificate can be performed so that a communication path by SSL can be secured. Therefore, by using such a digital certificate management system, the root key can be updated without preparing a special communication path for updating the root key. The system can be operated at low cost. This also applies to each of the subsequent embodiments.

  In addition, it is necessary to provide a separate secure communication path between the certificate management apparatus 10 and the server apparatus 30. This is because, for example, renewal of a public key certificate due to expiration, etc. A common communication path may be used for processing normally required. In addition, since such a communication path only needs to be provided between the certificate management apparatus 10 and only one apparatus, there is no particular burden. When the certificate management apparatus 10 and the server apparatus 30 are physically close to each other, it is easy to provide such a path by connecting with a dedicated cable, and this embodiment is preferable in such a case. It can be said that it is a thing.

In the processing procedures shown in FIGS. 6 to 9, the feature of this embodiment is that the server device 30 first stores the public key certificate, and at least the client device 40 stores the new root key. This is a point to be executed after the processing to be performed, that is, after a response indicating that at least the distribution root key certificate has been received from the client device 40.
As described above in the description of steps S129 and S130 in FIG. 8, it is inconvenient to store two public key certificates at the same time for the server device 30. Therefore, when storing a new server public key certificate, Even if such rewriting is performed, the authentication process will not be hindered after the new root key is stored in the client device 40.

In this embodiment, since the new client public key certificate is stored in the client device 40 before the server device 30 stores the new root key, the communication until the server device 30 stores the new root key. There is an overhead due to the server device 30 being unable to decrypt the digital signature of the new client public key certificate.
In order to prevent overhead, the new root key is stored in both the server device 30 and the client device 40, and then the new public key certificate is stored in each of the server device 30 and the client device 40. It is also possible to discard each previous root key or public key certificate after this is completed. However, if this is done, a total of six request transmissions from the certificate management device 10 to the server device 30 (or the client device 40 via the server device 30) are required.

However, according to the procedure used in this embodiment, the root key update process can be performed only by transmitting a total of three requests. Therefore, there is an effect that the management of the processing procedure and the design of the program are easy. When the number of server devices and client devices to update the root key certificate is large, this effect becomes even greater, and this embodiment is effective.
Further, in the processing 1 and processing 2, if the validity of each certificate is confirmed and the necessary items are stored in a lump, the number of accesses to the nonvolatile memory storing the certificate can be reduced, and processing can be performed. It is possible to reduce the load and speed up the processing.

  Note that discarding the previous root key certificate, distribution root key certificate, and public key certificate is not an indispensable process, but if these are stored indefinitely, the storage capacity is wasted. Become. For storing keys and certificates, it is preferable to use a highly reliable storage means, and therefore the cost per capacity is high, which is a big problem. Further, since the distribution root key certificate is not in a self-signed form, it is necessary to refer to the previous root key certificate when used, and the processing efficiency is poor. Therefore, these certificates should be promptly discarded when they are no longer needed.

In addition, once the root key is stored, it is generally not necessary to transmit it to the outside, and subsequent damage or tampering is unlikely. Therefore, it is also possible to store only the key portion instead of the root key certificate. In such a case, it is only necessary to store the new root key included in the distribution root key certificate, so there is no need to separately transmit the new root key certificate from the certificate management apparatus 10. Further, instead of discarding unnecessary root key certificates, it is only necessary to discard the previous root key.
Furthermore, when using a root key, it is possible not to check the digital signature, but in this case there is no need to send a new root key certificate separately, and an unnecessary root key certificate is required. Only the previous root key certificate needs to be discarded when the certificate is discarded.

  In this embodiment, the example in which the transmission from the server device 30 to the client device 40 is performed as a response to the communication request from the client device 40 has been described. However, the server device 30 can also function as a client, and the client device 40 may function as a server, and by these functions, data and requests may be transmitted directly from the server apparatus 30 to the client apparatus 40. In such a case, a communication request by the client device 40 is not necessary. This also applies to the following embodiments.

[Modification of First Embodiment: FIG. 12]
Next, a modification of the above-described first embodiment will be described.
This modification is the same as in the first embodiment described above in that the client / server system is configured by each one client and server, but the apparatus that is the direct communication partner of the certificate management apparatus 10 is the same. The client device 40 is different from the first embodiment.
The functional configuration of each device constituting the digital certificate management system of this modification is shown in the functional block diagram of FIG. 12 corresponding to FIG. In this figure, parts corresponding to those in FIG.

  As can be seen from this figure, in this modification, the client device 40 is also provided with a server function unit 44. The server function unit 44 has a function as a server that performs a required process on the received request and returns a response, and is provided for communication with the certificate management apparatus 10. If the client device 40 has only the client function unit 43, it is necessary to wait for a communication request from the client device 40 when transmitting data, a request, or the like from the certificate management device 10 to the client device 40.

  However, the root key update process is not frequently performed, for example, once a year. For this reason, when the client device 40 periodically transmits a communication request to the certificate management device 10. Most communication will be wasted. Therefore, a server function unit 44 is provided in the client device 40 so that communication can be requested from the certificate management device 10 side. The function of the server function unit 44 is also realized by the CPU of the client device 40 executing a required control program and controlling the operation of each unit of the client device 40.

  However, the client device 40 always functions as a client in relation to the server device 30 constituting the client / server system. Therefore, when mediating communication from the certificate management device 10 to the server device 30, the server function unit 44 receives the data and request received from the certificate management device 10 by the communication function unit 42, and this is received by the client function. Passed to the unit 43, communication with the server device 30 is requested based on an instruction from the client function unit 43 and transmitted to the server device 30. When a response from the server device 30 is returned to the certificate management device 10, the process is reversed.

Although the sequence of the root key update process is changed in accordance with these changes, a request for the client device 40 can be directly transmitted from the certificate management device 10, and a request for the server device 30 is transmitted via the client device 40. Is different from the case of the first embodiment in that transmission can be performed without waiting for a communication request. Then, the distribution root key certificate, the new root key certificate, and the new client public key certificate are transmitted and stored in the client device 40, and then these certificates are transmitted and stored in the server device 30. The procedure for discarding the previous certificate and the distribution root key certificate and then discarding the unnecessary certificate in the client device 40 is the same.
Therefore, although detailed illustration of the processing sequence is omitted, the configuration of this modified example also has a great influence on the authentication processing between the server device 30 and the client device 40, as in the case of the first embodiment described above. Therefore, the root key can be updated by automatic control, and the authentication process by SSL in the client / server system can be operated at a low cost.

[Second Embodiment: FIGS. 13 to 37]
Next, a second embodiment of the digital certificate management system according to the present invention, comprising a certificate management device which is a digital certificate management device according to the present invention, and a client device and a server device constituting a client / server system. The configuration of the form will be described.
In this digital certificate management system, as shown in FIG. 13, the client / server system is configured in a plurality of stages in such a form that the upper node follows the lower node. That is, the node O that is the direct communication partner of the certificate management apparatus is the highest node, the node X and the node Y that are the communication counterparts of the node O are located below it, and the node that is the communication partner of the node X A and node B are located in the lower order, node C and node D, which are the communication partners of node Y, are located in the lower order, and so on, and seven of O, X, Y, A, B, C and D A client / server system is configured by nodes.

Each of these nodes includes a public key certificate, which is a digital certificate issued to the node, and a root key for confirming the validity of the public key certificate sent from the communication partner. The root key certificate is stored, and communication is established when the other party is authenticated as a valid communication party by SSL authentication processing using these. Here, it is assumed that the initial root key is stored in each node at the time of factory shipment or at the same time, at least before the user starts the operation of the authentication process. At this time, both the public key certificate and the private key may be stored.
Here, it is assumed that, except for the node O, the authentication processing standard is set so that direct communication cannot be performed except between the nodes indicated by arrows in the drawing. However, each node can perform communication with a node that is not a direct communication partner or the certificate management apparatus 10 with each node in between, and can perform such mediation.

In this case, when each node other than the node O communicates with the certificate management apparatus 10, the node O always acts as an intermediary, and the availability of the communication depends on the node O. When there is such a relationship, the node O is referred to as a higher node than other nodes. Similarly, the node X is a higher order node than the nodes A and B. For the lower nodes, the reverse relationship with the upper nodes is assumed. That is, nodes C and D are lower-order nodes than node Y. Further, an upper node serving as a direct communication partner is simply referred to as an “upper node”, and a lower node serving as a direct communication partner is simply referred to as a “lower node”.
In such a client / server system, each node functions as either a client or a server when communicating with a communication partner. As described in the first embodiment, the client is the side that issues a connection request for communication, and the server is the side that returns a response to it.
In this case, it is assumed that one server is a structural unit that returns one public key certificate to a client in order to perform authentication processing when a connection request is made from the client. For example, it is possible to make common hardware function as multiple servers using functions such as a virtual server, and use different public key certificates for each server. Each public key certificate is considered to be a separate server, and the same hardware is treated as functioning as a plurality of nodes.

In this embodiment, as shown in FIG. 13, when the node O and the node X communicate with each other, the node O functions as a client and the node X functions as a server. However, the node X functions as a client when communicating with the node A, and at this time, the node A functions as a server. Thus, depending on the communication partner, some nodes may function as both a server and a client.
Although not included in the configuration shown in FIG. 13, only one of the server and the client functions as a client when communicating with any node, or functions as a server when communicated with any node. There can also be a node that functions as:

Although not included in the configuration shown in FIG. 13, there may be a configuration in which the functions of the nodes are switched in some cases in communication between the nodes. That is, even when communicating with the same node, it may function as a server when there is one node, and may function as a client at other times.
However, in this embodiment, when an update procedure is determined as described later, a function when a certain node communicates with the same communication partner needs to be uniquely determined. Therefore, in the above case, it is necessary to select one of the functions automatically or manually, and handle the communication as only one of the functions and perform the root key update process. In this case, it is preferable to select the function of the higher-level node that becomes the client. As will be described later, since data can be transmitted from the client to the server without waiting for a communication request, when transmitting a request from the certificate management apparatus 10 to the target node, time loss due to waiting for the communication request is reduced. This is because it can be done.

Note that the authentication process when the function that was not selected is used may not be temporarily established during the update process. Even in such a case, the authentication process when the function that is selected is used is a problem. Because it can be executed without interruption, communication will not be interrupted. Further, when the update is completed for both nodes, the authentication process can be performed again with both functions.
Therefore, in consideration of the fact that the description becomes complicated when considering the case where the function of the node is switched in this way, the following description will be given without considering such a case, but the present invention has a function depending on the case as described above. It should be emphasized that this is applicable even when there are nodes to be replaced.
In any case, when communicating, when one node functions as a server, the other functions as a client, and vice versa.

Regarding the function and configuration of each node, the certificate management apparatus 10 is the same as the certificate management apparatus 10 described with reference to FIG. 2 in the first embodiment, and functions only as a node and a client that function only as a server. Similarly, the nodes to be performed are the same as the server device 30 or the client device 40, respectively.
However, even when the highest node functions only as a client in relation to the lower nodes, communication with the certificate management apparatus 10 is performed in the same manner as the client apparatus 40 described with reference to FIG. 12 in the modification of the first embodiment. Functions as a server. The node functioning as both the server and the client also has the same function as that of the client device 40 shown in FIG. 12, but the server function unit 44 is also used for communication with nodes other than the certificate management device 10, The client function unit 43 is different from the modified example in that the client function unit 43 may perform an operation of receiving a certificate or the like and storing it in the certificate storage unit 41.

FIG. 14 shows a storage format of information of each node constituting the client / server system in the configuration storage unit 26 of the certificate management apparatus 10 in this digital certificate management system. As shown in this figure, the configuration storage unit 26 first stores a node ID, a node state, and the number of generations for each node. Further, together with the ID of each node that is a communication partner of the node, information indicating whether to function as a client or a server when communicating with the communication partner, and information of a route key used when communicating with the communication partner The link state information indicating the progress of the update procedure determination process in the communication partner is stored.
Here, the “communication partner” refers to a partner that performs communication after performing an authentication process, as indicated by an arrow in FIG. The “link” refers to a communication path between a certain node and another node that is a communication partner of the node, and here, when communicating with the ID of the node that is a communication partner and the communication partner. The contents are indicated by information indicating whether the client or server functions.

The “number of generations” is a numerical value that relatively represents the upper and lower ranks of the above-described nodes, and can also be referred to as “order”. Here, it is assumed that the highest node that is the direct communication partner of the certificate management apparatus 10 increases by 1, and every time one node is inserted between the certificate management apparatus 10 and 1 each. And the higher the number of generations, the lower the ranking. However, this information is not indispensable, and it is only necessary to identify whether or not the certificate management apparatus 10 is a direct communication partner.
These pieces of information are configuration information.

Although not shown, the root key certificate and public key certificate ID held by each node may be stored together with the expiration date as information of each node.
Note that “node state” and “link state” are information used in processing related to the update order determination method of the present invention, which will be described later, and are used for sequentially rewriting and indicating the progress of the processing according to the progress of the processing. The “node state” is information indicating how much the processing for the node having the information has progressed, and has the states of “unprocessed”, “added”, and “attentioned”. It changes in order. The “link status” is information indicating how far the process of tracing the subordinate node at the link destination has progressed from the node having the information. The status of “unprocessed”, “waiting for processing”, “processed” It usually changes in this order. A more detailed description of these pieces of information will be described later together with the description of the update order determination process.

FIG. 15 shows a specific example of information stored in the format shown in FIG. Here, an example is shown in which information regarding each node shown in FIG. 13 is stored. However, the node state and link state are all “unprocessed”.
That is, with respect to the node O, “node O” is stored as the node ID as shown in (a), and “1” is stored as the generation number because it is the direct communication partner of the certificate management apparatus 10. And the information of the node X and the node Y is each memorize | stored as information of the low-order node used as a communicating party. Further, since the node O functions as a client when communicating with the node X, this fact is stored, and “root key A” is stored here as information on the root key to be used. Further, since the node O functions as a server when communicating with the node Y, it stores that fact and also stores “root key A” as information on the root key to be used.

For each of the other nodes X, Y, A to D, information as shown in FIGS. 15B to 15G is stored in the same manner. For these nodes, only information on lower nodes is stored as communication partner information. This is because the information related to communication with the upper node is already stored on the upper node side, and the server / client distinction can be derived from the information, so that it is not necessary to newly store it on the lower node side.
If information on the upper node is also stored, it is possible to know all the nodes that are communication partners of the node only by referring to the information on the target node, but only information on the lower node is stored. As a result, the storage capacity of information can be suppressed. However, whichever form it takes, the information about the communication partner of each node and whether it functions as a client or a server between the communication partners can be stored. A certification key update procedure can be defined.

  In order to collect the information as shown in FIG. 15 in the certificate management apparatus 10, each node, as information relating to itself, either a lower-level node that is a communication partner or a client or a server when communicating with that node Information about whether to function as a communication partner, and root key information used when communicating with the communication partner, and when each node communicates with the certificate management device 10 for the first time, the certificate management device from each node 10 may be notified of such information. Further, it is preferable to notify the certificate management apparatus 10 promptly even when there is a change. Then, the certificate management apparatus 10 may determine the number of generations and necessity of updating the root key for each node based on the information notified from each node, and set the information.

In addition, since the information on the number of generations changes according to changes in the connection relationship and communication partner of each node, as described later, it is reset at least every time the root key update process is performed. . However, if there is a change in the generation number “1” node, the change is immediately reflected manually or automatically.
In some cases, the root key used for the authentication process may be different for each node. In this case, the update process is performed for each group using a common root key. That is, by applying the first to third embodiments and their modifications including those described later for each group, the update process can be performed independently for each group.

Next, referring to FIG. 16, as in the case of the digital certificate management system according to the second embodiment shown in FIG. A communication procedure for transmitting a request from the certificate management apparatus 10 to each node in the system will be described. FIG. 16 is a sequence diagram for explaining this communication procedure.
In FIG. 16, as an example, a request is sent from the certificate management apparatus 10 to the lowest node T in the client / server system including five nodes from the highest node P to the lowest node T. The processing sequence from the execution of the processing corresponding to the request to the reception of the response is shown. Whether each node functions as a client or a server when communicating with other nodes is indicated by a symbol C or S below the node name. This process is performed by the certificate management apparatus 10 and the CPU of each node executing a required control program.

  As shown in this figure, when the certificate management apparatus 10 tries to make an operation request to the node T, the communication path to the node T is determined with reference to the information stored in the configuration storage unit 26 ( Here, P → Q → R → S → T), first, a request transmission request addressed to the node T is transmitted to the highest node P (S201). This request is for requesting the node T as a transmission destination to perform an operation request and an operation of transmitting necessary information toward the transmission destination.

Here, since the node T is not a node that is a communication partner of the node P, information indicating a communication path to the node T on the certificate management apparatus 10 side may be included in the transmission request. However, if each node stores information on the communication partner for at least a node lower than itself, a subsequent communication path can be searched using only destination information.
The node P that has received the request transmission request addressed to the node T returns a response delay notification to the certificate management apparatus 10 when determining that the response cannot be returned in a short time based on the processing contents and the communication path. The communication is disconnected (S202). If it is determined that a response can be returned in a short time, the process proceeds as it is. Then, the communication path to the node T is traced, and a request transmission request addressed to the node T is transmitted to the next node Q (S203). Since the node P functions as a client when communicating with the node Q, the node P can request this communication and perform this transmission.

Similarly to the case of the node P, the node Q that has received this also returns a response delay notification when it is determined that a response cannot be returned in a short time (S204). A request transmission request addressed to the node E is transmitted to the next node R following the communication path up to (S205).
Similarly, the node R returns a response delay notification when necessary (S206), follows the communication path to the node T, and transmits a request transmission request addressed to the node T to the next node S. However, since the node R functions as a server when communicating with the node S, it waits for a communication request (S207) from the node S and transmits it as a response to this, as in steps S113 and S114 of FIG. (S208).

The node S that has received the request transmission request addressed to the node T extracts the request and information to be transmitted to the node T from the request transmission request addressed to the node T, and transmits the request to the node T. (S209).
Upon receiving this request, the node T performs corresponding processing (such as digital certificate update) in step S210 and returns a response (S211). Since the request includes the information of the transmission source and the node T can recognize that the response should be returned to the certificate management apparatus 10, the certificate management apparatus 10 is designated as the response transmission destination. Transmit to a certain node S. Then, the node S transmits this to the higher-order node R (S212).

The node R also transmits to the upper node Q. However, if the response delay notification in step S206 is performed, the communication is temporarily cut off and communication cannot be requested from the node R side. It waits for a request (S213) and transmits it as a response (S214). When the response delay notification is not performed, this can be transmitted as a response to the request transmission request for the node T. The same applies to transmission from the node Q to the node P and from the node P to the certificate management apparatus 10 (S215 to S218).
Through the above processing, the certificate management apparatus 10 can send a request to the lowest node T to perform an operation, receive a response, and know the success or failure of the operation.

In addition, although the example in the case of performing the request | requirement with respect to the node T was demonstrated here, a request | requirement can be similarly transmitted also to the node in the middle, and a response can be acquired. A request transmission request may be made up to a node immediately above the target node, and an operation request may be transmitted from the node to the target node. Even when the number of nodes and the client / server relationship between the nodes change, the same operation can be performed by changing the procedure accordingly.
Here, in order to simplify the description, an example in which each node has one (or 0) lower node has been described. However, as in the example shown in FIG. Even if it exists, if the transmission destination of the operation request is defined as one node, a transmission path that sequentially follows the nodes can be determined. Thereafter, the same processing as in the example described with reference to FIG. 16 is performed. be able to.

Next, root key update processing in this digital certificate management system will be described.
In this process, after executing the process S described with reference to FIG. 6 in the first embodiment, the processes 11 and 12 shown in FIGS. 17 and 18 are executed in the order described later. First, the processing contents shown in the sequence diagrams of FIGS. 17 and 18 will be described, and then the execution order will be described with reference to FIG. These processes are performed by the certificate management apparatus 10 and the CPU of each node executing a required control program.

First, the certificate storage processing of each node is shown as processing 11 in the sequence diagram of FIG. This process is performed for each node, and the part of request transmission from the certificate management apparatus 10 to the target node and the result notification differ depending on the target node. It is assumed that the process is appropriately performed according to the procedure described above, and only general description is given here.
In this process, first, in step S311, the certificate management apparatus 10 creates a new public key certificate by attaching a digital signature using the new root private key to the public key issued to the target node. Note that the new root private key is the one created in step S101 of FIG. Further, since the private key of the target node is not updated, it is not necessary to update the public key itself.

In step S312, the certificate management apparatus 10 sends the distribution root key certificate created in step S102 of FIG. 6 and the new root key certificate created in step S103 of FIG. Along with the new public key certificate created in step S311, an update request transmission request for transmitting an update request for these to the target node is transmitted.
Then, each node corresponding to the communication path to the target node sequentially transmits a transmission request according to the procedure described with reference to FIG. When this request reaches a node immediately above the target node, the node transmits each certificate and update request related to the transmission request to the target node (S314). In this case, when the transmission source functions as a server in relation to the target node, it is transmitted as a response to the communication request (S313) from the target node.

If the target node is the highest node, the certificate management apparatus 10 directly transmits each certificate and an update request for these certificates to the node.
Through the above processing, each certificate and the update request for them are transmitted from the certificate management apparatus 10 to the target node (if any) via the upper node, and step S312 is a transmission procedure. In this processing, the CPU 11 of the certificate management apparatus 10 functions as a transmission unit.

Upon receiving this request, the target node confirms the validity of the distribution root key certificate in steps S315 and S316 using the previous root key certificate, as in steps S115 and S116 of FIG. If this can be confirmed, the distribution root key certificate is stored in the certificate storage unit. At this time, the previous root key certificate is not deleted yet.
Further, in step S317, as in the case of step S117 of FIG. 7, the validity of the new root key certificate is confirmed using the stored distribution root key certificate. If this can be confirmed, the new root key certificate is stored in the certificate storage unit in the next step S318. At this point, the distribution root key may be deleted, but it is stored here.

Next, in steps S319 and S320, as in the case of steps S119 and S120 of FIG. 7, the validity of the new public key certificate of the target node is confirmed. Store in the storage unit. However, since the new root key certificate is already stored here, the validity of the new public key certificate can be performed using the new root key certificate instead of the distribution root key certificate. In steps S315 to S320 described above, the CPU of the target node functions as an updating unit.
By the way, the handling of the previous public key certificate when storing the new public key certificate in step S320 differs depending on the function of the target node, as shown in Table 1.

First, when functioning only as a client, the previous public key certificate is not yet deleted at this point. Accordingly, the certificate storage unit stores two client public key certificates. Then, as described in step S120 of FIG. 7, when a public key certificate is transmitted to a communication partner, a new public key certificate is first transmitted, and when a response indicating that the authentication has failed is received, Request communication again and send the previous public key certificate. In this way, authentication can be performed without any problem regardless of whether the new root key certificate is stored in the communication partner.
On the other hand, if the server functions only as a server, the previous public key certificate is discarded in step S320. This is because the server must always transmit the same public key certificate to the client as described in the description of step S130 in FIG.

However, when functioning as both a client and a server, if the previous public key certificate is discarded in the same manner, communication with the client functioning until the communication partner stores the new root key certificate is performed. It will cause trouble. Therefore, if the server functions as a server but does not discard it, it is set not to use the previous public key certificate, and is used only when it functions as a client and authentication with the new public key certificate fails. To.
Note that the processing in steps S319 and S320 may be performed before the processing in steps S317 and S318. In this case, the validity is confirmed in step S319 using the distribution root key certificate.

Thereafter, in step S321, the target node returns a result notification to the certificate management apparatus 10 as a response to the update request, which is transmitted to the certificate management apparatus 10 via each upper node (S322). However, if the target node is the highest node, it is transmitted directly to the certificate management apparatus 10.
The above is the certificate storing process of each node.

Next, the old key discard processing of each node is shown as processing 12 in the sequence diagram of FIG. This processing is also performed for each node, but only general description is given here as in the case of processing 11.
Here, first, in step S331, the certificate management apparatus 10 sends an old key discard request transmission requesting the highest node to transmit an old key discard request for discarding an unnecessary digital certificate to the target node. Send a request. Then, each node corresponding to the communication path to the target node sequentially transmits a transmission request according to the procedure described with reference to FIG. When this request reaches a node immediately above the target node, the node transmits an old key discard request to the target node (S333). In this case, when the transmission source functions as a server in relation to the target node, it is transmitted as a response to the communication request (S332) from the target node.
If the target node is the highest node, the certificate management apparatus 10 directly transmits an old key discard request to that node.
With the above processing, the old key discard request is transmitted from the certificate management apparatus 10 to the target node via the upper node (if any).

Upon receiving this request, the target node discards the distribution root key certificate and the previous root key certificate stored in the certificate storage unit in step S334, and at the time of step S320 in FIG. If not discarded, the previous client public key certificate is also discarded.
Thereafter, in step S335, the target node returns a result notification as a response to the update request to the certificate management apparatus 10, which is transmitted to the certificate management apparatus 10 via each higher-level node (S336). However, if the target node is the highest node, it is transmitted directly to the certificate management apparatus 10.
The above is the old key discard processing of each node.

  The execution timing of the certificate creation process (process S), certificate storage process (process 11), and old key discard process (process 12) is as shown in FIG. That is, when updating the root key, first, the process S shown in FIG. 6 is executed, then the process 11 is executed for each node, and then the process 12 is executed for each node. Then, the process 11 is sequentially performed for each node from the first to the last in the order determined by the processes shown in FIGS. 20 and 21 to be described later according to the configuration of the client / server system. The order in which they are performed is the main feature of this embodiment.

If it says from a conclusion, the execution order of the process 11 with respect to each node will determine the process 11 for a node that functions as a server (including those that function as both a client and a server) as a client when it becomes a communication partner of that node. This is an order that satisfies the condition that the process 11 is completed after all the functioning nodes are completed.
In the case of functioning as a server, it has been described above that when a new public key certificate is stored, the previous public key certificate is not used for authentication processing. If the root key (new root key certificate or distribution root key certificate) is stored before being stored, the authentication process cannot be performed.

Therefore, the process of sending a new public key certificate to the node functioning as a server and requesting the storage of the new public key certificate is performed by receiving a new certification key from all the nodes functioning as clients when the node becomes a communication partner of the node. Although it is necessary to perform the processing after the response indicating that it has been stored, in the processing 11, since the new root key certificate and the new public key certificate are simultaneously transmitted and stored in a series of processing, as described above. It is necessary to execute in the correct order.
However, if the above condition is satisfied, it is not essential to wait for the start of the process for the next node until the process for the previous node is completed. Also, it is not essential to perform the new public key certificate creation process in step S311 in FIG. 17 immediately before the transmission process in step S312. It is only necessary that the new public key certificate is prepared before the transmission process. . For example, all new public key certificates to be transmitted to each node may be created in process S.
Such an update procedure is created and managed based on the configuration information stored in the configuration storage unit 26 by the update order control unit 27 of the certificate management apparatus 10. The creation of the update procedure is a process related to the update procedure determination method of the present invention.

FIG. 20 and FIG. 21 show a flowchart of the process for creating the execution order of the process 11 which is the storage procedure for each node in the process for creating the update procedure.
In this process, an initialization process is first performed in step S401, the highest node is identified with reference to the information stored in the configuration storage unit 26, and the generation number information for other nodes is cleared. In addition, the state is set to “unprocessed” for all nodes and links. Further, the highest node can be specified on the assumption that the device with which it directly communicates is the highest node.
Then, a work list for storing the execution order of the process 11 and an attention point list (to be described later) for determining a node of interest when the work list is created are also initialized. A new empty list may be created.
In step S402, the highest node is set as the attention node and added to the work list, and the node state is set to “attention finished”. This “attention finished” is data indicating that the node has already become a noticed node.

In the next step S403, it is determined whether or not there is a link whose link state is “unprocessed” with reference to information on the node of interest. If there is, one link is selected from them, and the process proceeds to step S404, and the process up to step S410 or the process of step S411 is performed on the link. At this time, when there are a plurality of candidates, the link in which the upper node functions as a client may be preferentially selected, but may be selected in an arbitrary order.
In step S404, with respect to the link selected in step S403, information about the link destination lower node is referred to, and it is determined whether or not the node state of the lower node is “unprocessed”. If “unprocessed”, the process advances to step S405 to set the generation number of the lower node to the generation number + 1 of the target node.

  In the next step S406, it is determined whether or not the node of interest functions as a client when the link destination lower node is a communication partner, that is, whether or not the link is a client-to-server link. This determination can be made with reference to the configuration information about the node of interest. When the node of interest functions as a client (in the case of YES), it is necessary to perform the process 11 for the lower node after the process 11 for the node of interest. Add to the end (rear) of the work list. Conversely, if the target node functions as a server (in the case of NO), it is necessary to perform the process 11 for the lower node before the process 11 for the target node. Is added to the front end (front side) of the work list.

After step S407 or step S408, the process proceeds to step S409, where the link state is set to “waiting for processing”, and then in step S410, the node state of the lower node added to the work list is set to “added”.
Here, “waiting for processing” is information indicating that a link has been followed to add the lower node to the work list, but it is necessary to follow the link again in order to make the lower node a target node later. is there. “Added” is information indicating that the node has already been added to the work list.
After the end of step S410, the process returns to step S403 to repeat the process.
If the determination in step S404 is no, the process proceeds to step S411 to set the link state to “processed”, and the process returns to step S403 to repeat the process. Here, “processed” is information indicating that it is no longer necessary to follow the link.

According to the above definition, the lower-level node ahead of the link whose link state is “unprocessed” has not been referred to yet, and the node state should be “unprocessed”. However, if there is a common lower node that communicates with multiple upper nodes, follow the link from one upper node, add the lower node to the work list, and the node status of the lower node becomes "Added" Even if the lower-level node is the target node, and the node status of the lower-level node becomes “focused”, the link status of the link from another higher-level node to the lower-level node may be “unprocessed” is there. In such a case, the determination in step S404 is NO. Therefore, in order to prevent double processing for a common lower node in such a case, links other than the first traced link are set to “processed” without any processing. It is.
The above process is repeated, and if there is no link whose link state is “unprocessed” for the node of interest or there is no such link from the beginning, the determination in step S403 is NO, and the process proceeds to step S412 in FIG.

In step S412, it is determined whether or not there is a subordinate node in the target node. If there is a lower node, the process proceeds to step S413, the target node is added to the rear end of the target point list, and the process proceeds to step S414. If not, the process proceeds to step S414 as it is.
Here, the point of interest list is a list in which data of nodes that need to be traced later or referred to as a node of interest by referring to a link is stacked. Is not added to the attention list because there is no node to be added to the work list below the node and it is no longer necessary to refer to the information of the node.
In the next step S414, it is determined whether or not there is a node in the attention point list. If there is, the process advances to step S415 to delete the node at the front end from the attention point list and refer to the information of the node.

In step S416, it is determined whether or not the node state of the node is “focused”. If it is not “focused”, the node is not yet the focused node, so the process proceeds to step S420, and the node is focused. As a node, the node of interest is changed to that node, and the node state is set to “attentioned” to indicate that it has become the node of interest. Then, the process returns to step S403 in FIG.
On the other hand, if the node has been “attentioned” in step S416, the node has already become the node of interest, and the process proceeds to step S417 without setting it as the node of interest again. Then, a link whose link status is not “processed” is searched for the node, and it is determined whether or not such a link has been found.

If found, the process proceeds to step S418, and the node being referred to is added to the front end of the attention point list for later reference again. In step S419, for one of the links found in step S417, the link state is set to “processed”, and the lower node ahead of the link is added to the front end of the attention point list, and the flow returns to step S414. Repeat the process.
Here, the node added to the work list in step S419 is the lower node after the link whose link status is set to “waiting for processing” in step S409 of FIG. 20, that is, the node status is “added” in step S410. Is a subordinate node that is not yet a target node. Therefore, when this node is at the front end of the attention point list and is referred to in step S415, the determination in step S416 is always NO, and the attention node is changed to this node.

In addition, since the change destination of the attention node is always determined in this procedure in this process, the subordinate node of the link whose link state is set to “processed” in step S419 is determined as the attention node in step S420. And the node state is changed to “focused”.
In this case, the node at the front end of the attention point list first deleted in step S415 is added to the front end as before in step S418, and the lower node added to the front end in step S419 is the next node after returning to step S414. Since it is deleted in step S415, the content of the attention point list is not substantially changed. Accordingly, in the subsequent steps up to step S420, when there is a node that has not yet become the attention node among the lower nodes of the node at the front end of the attention point list, the processing for changing the attention node to that node has been performed.

If there is no link that has not been “processed” in step S417, the process returns to step S414 as it is, and the processing is repeated. However, this is because the node below the node at the front end of the attention point list is still the attention node. This is a case where there is no node that has not been deleted. In this case, since the node deleted in step S415 is not restored, the process of deleting the node at the front end of the point-of-interest list from the list has been performed.
The above processing is repeated, and when all nodes become attention nodes, the attention point list becomes empty. In this case, the determination in step S414 is NO, and it is determined that all nodes have become attention nodes, and the processing ends. To do.
Through the above processing, the execution order of the processing 11 that satisfies the above-described conditions can be created as a work list.
In the above-described processing, the processing related to the number of generations is not essential.

Here, an example of creating a work list by the above-described processing when the client / server system has the configuration shown in FIG. 13 will be described with reference to FIGS. FIG. 22 to FIG. 39 are diagrams showing the state of the configuration information, the work list, and the attention point list at various points in the work list creation process.
When creating a work list, first, initialization processing is performed in step S401 of FIG. The highest node is identified as node O from the configuration information, and the initial state of information for each node is obtained by deleting information on the number of generations other than node O, which is the highest node, from the state shown in FIG. In step S402, this node is set as the attention node, added to the work list, and the node state is set to “attention already”. In step S403, since there is a link whose link status is “unprocessed”, the link to the node X is first selected and the process proceeds.

Since the node status of the node X is “unprocessed”, the determination in step S404 is YES, and in step S405, “2” is set to 1 + 1 as the generation number of the node X. When the node O communicates with the node X, Since it functions as a client, node X is added to the end of the work list in step S407. In step S409, the link state of the link from the node O to the node X is set to “waiting for processing”, and in step S410, the node state of the node X is set to “added”.
Then, the process returns to step S403, but since the link to the node Y is still “unprocessed”, the same process is performed for this link. However, since the node O functions as a server when communicating with the node Y, the node Y is added to the front end of the work list in step S408.

Next, when returning to step S403, since there is no “unprocessed” link, the process proceeds to step S412 in FIG. Since node O, which is the node of interest, has lower nodes, node O is added to the point of interest list in step S413, and the flow proceeds to step S414. In the processing so far, the information about the nodes O, X, and Y is changed as shown in FIG. 22, and the information about the other nodes is not changed from the initial state. The work list and attention point list have the contents shown in FIG.
Next, in step S414, since there is a node in the attention point list, the process proceeds to step S415, and the node O at the front end is deleted from the list and the information of the node O is referred to. Then, since the node state of the node O is “focused” as shown in FIG. 22, the process proceeds from step S416 to S417. Further, since the link to either node X or Y is not “processed”, the process proceeds to step S418, and the node O being referred from step S415 is added to the front end of the attention point list. If it is determined in step S419 that the process is to be performed on the link to the node X, the node X is added to the front end of the attention point list and the link state of the link is set to “processed”.

  In the processing so far, the information about the node O is changed as shown in FIG. 24, and the information about the other nodes is not changed from the time of FIG. The work list and attention point list have the contents shown in FIG. In FIG. 25, nodes surrounded by a broken line are nodes deleted from the attention point list, and a node described as “added” is a new list from the state shown in the previous figure (here, FIG. 23). Indicates the added node. The same applies to the following corresponding drawings. For example, FIG. 25 shows that node O is deleted from the state shown in FIG. 23 and node O and node X are added, and the attention point list includes node X and node O in this order. Yes.

Next, the process returns to step S414, proceeds to step S415, deletes the node X at the front end of the attention point list, and refers to the information. Since the node state of the node X is “added” as shown in FIG. 22, the process proceeds from step S416 to step S420, the node of interest is changed to the node X, and the node state is changed to “attentioned”. .
Then, the process returns to step S403 in FIG. 20 to repeat the process, and add node A and node B, which are lower nodes of node X, to the work list and set the link status of the links to these nodes to “waiting for processing”. The node state of the node is “added”. At this time, since node X functions as a client when communicating with node A, node A is added to the end of the work list, and node X functions as a server when communicating with node B. Add to the front of the work list. When these processes are completed and there is no “unprocessed” link in the node X that is the target node, the process proceeds from step S403 to step S412 in FIG. 21 again. Since the node X includes lower nodes, the node X is added to the rear end of the attention point list in step S413.

  In the processing so far, the information about the nodes X, A, and B has been changed as shown in FIGS. 26A to 26C, and the information about the other nodes has not changed from the time of FIG. The work list and attention point list have the contents shown in FIG. In step S413, node X is added to the rear end of the list of points of interest, so that the processing for the lower node of node X is performed later, and it is the same generation as another lower node of node O, that is, node X. The node that has not yet become the attention node is searched first.

Next, the process proceeds from step S414 to step S415, the node O at the front end is deleted from the attention point list again, and the information of the node O is referenced. Since the node state of the node O is “attention already” as shown in FIG. 24 at this time, the process proceeds from step S416 to S417. Since the link to the node Y is not “processed”, the process advances to step S418 to add the node O to the front end of the attention point list. In step S419, the link to the node Y is processed, the node Y is added to the front end of the attention point list, and the link state of the link is set to “processed”.
In the processing so far, the information about the node O is changed as shown in FIG. 28, and the information about the other nodes is not changed from the time of FIG. The work list and attention point list have the contents shown in FIG.

Next, the process returns to step S414 again, proceeds to step S415, deletes the node Y at the front end of the attention point list, and refers to the information. Then, since the node state of the node Y is “added” as shown in FIG. 22, the process proceeds from step S416 to step S420, the node of interest is changed to the node Y, and the node state is changed to “attentioned”. change.
Then, the process returns to step S403 in FIG. 20 to repeat the process, and add node C and node D, which are subordinate nodes of node Y, to the work list and set the link status of the links to these nodes to “waiting for processing”. The node state of the node is “added”. At this time, since node Y functions as a client when communicating with node C, node C is added to the end of the work list, and node Y functions as a server when communicating with node D, so node D Add to the front of the work list. When these processes are completed and there is no “unprocessed” link in the node Y that is the target node, the process proceeds from step S403 to step S412 in FIG. 21 again. Since the node Y has lower nodes, the node Y is added to the rear end of the attention point list in step S413.

  In the processing so far, the information about the nodes Y, C, and D is changed as shown in FIGS. 30A to 30C, and the information about the other nodes is not changed from the time of FIG. The work list and the attention point list have the contents shown in FIG.

  Next, the process proceeds from step S414 to step S415, the node O at the front end is deleted from the attention point list again, and the information of the node O is referred to. Since the node state of the node O is “attention already” as shown in FIG. 28 at this point, the process proceeds from step S416 to S417. However, since there is no link that is not “processed” anymore, the process directly returns to step S414 and is no longer added to the attention point list. At this point, the work list and the attention point list have the contents shown in FIG.

However, since there are still nodes in the attention point list, the node X at the front end is deleted from the list and the information is referred to in step S415. Since the node status of the node X is “attention focused” as shown in FIG. 26 at this time, the process proceeds from step S416 to S417. Since neither of the links to the nodes A and B is “processed”, the process proceeds to step S418, and the node X is added to the front end of the attention point list. In step S419, if processing is performed on the link to the node A, the node A is added to the front end of the attention point list, and the link state of the link is set to “processed”.
In the processing so far, the information about the node X is changed as shown in FIG. 33, and the information about the other nodes is not changed from the time of FIG. The work list and attention point list have the contents shown in FIG.

Next, the process returns to step S414 again, proceeds to step S415, deletes node A at the front end of the attention point list, and refers to the information. Then, since the node state of the node A is “added” as shown in FIG. 26, the process proceeds from step S416 to step S420, the node of interest is changed to the node A, and the node state is changed to “attentioned”. .
Then, the process returns to step S403 in FIG. 20, but since node A does not have a link to a lower node in the first place, the process proceeds to step S412 as it is. Since node A has no lower nodes, the process proceeds to step S414 without adding it to the attention point list.
In the processing so far, the information about the node A is changed as shown in FIG. 35, and the information about the other nodes is not changed from the time of FIG. The work list and the attention point list have the contents shown in FIG.
Thereafter, the same processing is repeated until the attention point list becomes empty, but there is no node to be added to the work list thereafter, and this is a process for confirming this.

Therefore, only changes in the attention point list are shown in FIG. 37, and detailed description thereof is omitted. In FIG. 37, every time the process reaches step S414, a change in the attention point list up to that point is shown.
After the time point shown in FIG. 36, since the link to the node B is not “processed” for the node X at the front end, the node X and the node B are added to the front end of the attention point list (1), B becomes the next node of interest. However, since there is no lower node in node B, the process returns to step S414 as it is (2). Then, the process from step S415 is performed again on the node X. However, since there is no link that is not “processed”, the process returns to step S414 as it is (3).

Subsequently, the process from step S415 onward for node Y is performed, and the node C ahead of the link whose link state is “waiting for processing” is set as the next node of interest (4, 5). The process returns to step S414. The same applies when node D is set as the next node of interest (6, 7). If there is no link that is not “processed” for node Y, no node will be added even if node Y is deleted from the point of interest list, and the point of interest list will be empty (8), thus ending the process. To do.
The work list is completed as described above. In this state, the information about each node is as shown in FIGS. 38A to 38G. The node states of all the nodes are “focused” and the link states of all the links are “processed”. "It has become. Further, the work list and the attention point list have the contents shown in FIG. 39, and the work list has not changed from the state shown in FIG. 36, but the attention point list is empty.
Therefore, the execution order of the process 11 is the order of D → B → Y → O → X → A → C as shown in the completed work list. This order satisfies the condition that processing for a node functioning as a server is performed after processing for all of the nodes functioning as clients when it becomes a communication partner of that node.

Note that the node of interest is changed in the order of O → X → Y → A → B → C → D, starting from the topmost O as described above. Therefore, if there is a node that has the same rank as the target node and is not yet the target node, the target node is preferentially changed to that node. Is changed to one of the nodes below the node of interest and not yet the node of interest.
The attention node can be changed in this order because the attention node is added to the rear end of the attention point list in step S413 in FIG. 21, and another lower node viewed from the upper node than the lower node of the attention node. This is because the search is made with the next node of interest as the first node of interest. As this process is repeated, nodes of the same generation as the node of interest are accumulated in the point of interest list, and after all nodes of the same generation have become nodes of interest, the next generation nodes are sequentially searched to become nodes of interest. It can be done.

If the execution order of the process 11 is created as described above, the process S is executed before that, and then the process 12 is executed for each node in an arbitrary order, for example, in ascending order of the number of generations, the route Appropriate processing procedures for key updates can be defined. In this case, the old key discard request transmission request for each node other than the highest node and the old key discard request for the highest node are combined into one document and transmitted to the highest node so that an execution request is transmitted to each node. It can also be.
Note that the process 12 may be started if the process 11 is not necessarily completed for all nodes, but has been completed for at least the target node and all nodes that are communication partners of the node. Absent. This is because if the new root key and the new public key certificate are stored in all the nodes that are communication partners, the root key and the public key certificate before the authentication process are no longer necessary.

By performing the processing as described above, even when the client / server system is configured in a plurality of stages in a form in which the upper node follows the lower node, each node is the same as in the case of the first embodiment described above. The root key can be updated by automatic control without greatly affecting the authentication process between the two.
Therefore, by using such a digital certificate management system, it is possible to update the root key without preparing a special communication path for updating the root key. The system can be operated at low cost.

  Each process shown in the flowchart of FIG. 19 can be completed when a response indicating that the update is successful is received in response to the update request. Further, it may be completed when a reception response or a transmission result notification as described with reference to FIGS. 10 and 11 is received. If an update failure response is received or if the process times out, the same process may be tried again, but if the process fails for a predetermined number of times, the entire update process may have failed. When performing the root key update process according to the above-described procedure, the authentication process by SSL can be performed at any point of the process between the nodes that are communication partners, and thus the update process is interrupted in the middle. Even if this happens, there is no major hindrance to communication between the nodes. Therefore, even if the update process fails, it takes no time to specify the cause of the failure and then perform the update process again. The same applies to the subsequent embodiments.

In addition, in the update procedure of this embodiment, as in the case of the first embodiment, some communication overhead occurs, but there is an effect that the management of the processing procedure and the design of the program are easy. This effect becomes more significant when the number of nodes to update the root key certificate is large, and this embodiment is effective.
Further, this embodiment is not limited to the case where the configuration of the client / server system is as shown in FIG. 13, but when the upper node is configured in a plurality of stages in a format in which the lower node follows the lower node, the number of nodes and The present invention can be applied regardless of the function of the client / server of each node. If the information about each node is stored in the format shown in FIG. 14, an appropriate update procedure can be determined by the processing shown in FIG. 20 and FIG. By performing update processing accordingly, the root key can be updated by automatic control without greatly affecting the authentication processing between the nodes. The same applies to the modified example described later and the third embodiment.

[Modification of Second Embodiment: FIGS. 40 to 42]
Next, a modification of the above-described second embodiment will be described.
First, in the process shown in the flowchart of FIG. 21, if the process of step S421 is added between step S417 and step S418 as shown in FIG. 40, the number of loops in the update order determination process can be reduced.
Specifically, when only one link whose link state is not “processed” is found as a result of the search in step S417, the process proceeds from step S421 to step S419 without adding the currently referenced node to the attention point list. To do so. In such a case, if the link status of the link is set to “processed” in step S419, there will be no link whose link status is not “processed” in the referenced node, and it is necessary to refer to the same node again. This is because there is not.
In such a case, first, after deleting the node at the front end from the attention point list in step S415 and referring to the information of that node, only the lower node is added to the attention point list, and then the process returns to step S414. In the next step S415, this lower node is deleted. As a result, when the attention node is changed to the lower node, a process of deleting the node at the front end of the attention point list from the attention point list is performed. .

FIG. 41 shows the transition of the attention point list when the above-described modification is applied to the processing of the portion described with reference to FIG. 37 in the second embodiment. Also in this figure, as in the case of FIG. 37, every time the process reaches immediately before step S414, the state of the attention point list at that time is shown.
In the processing of this part, when the processing of step S416 and subsequent steps is performed on the front-end node X after the state shown in FIG. 36, since the link that is not “processed” is only to the node B, only the node B Is added to the front end of the attention point list, and the node X is not added (1). The point that node B becomes the next attention node is the same as in FIG. 37, but when there is no lower node and the process returns to step S414, only the node Y is included in the attention point list. (2). Next, the process from step S415 onward for node Y is performed, and the node C ahead of the link whose link state is “waiting for processing” is set as the next node of interest (3, 4), but there is no lower node as well. Therefore, the process returns to step S414 as it is.

After that, when the processing after step S416 is performed on the node Y, the link that is not “processed” is only to the node D. Therefore, only the node D is added to the front end of the attention point list, and the node Y is not added. (5). Therefore, if there is no lower node in node D and the process returns to step S414 as it is, the point of interest list is empty (6), and the process is terminated.
As described above, by applying the modification example, the process of step S414 and the subsequent steps is repeated 8 times, and the process can be shortened to reduce the processing load for determining the update order.

As another modification, when a new node is added to the work list, it may be added immediately before or after the node of interest instead of the front end or the rear end of the list. In this way, the work list is created as shown in FIG.
That is, when the top node is first added to the work list (1) and when the top node is the target node and its lower nodes are added to the work list (2), there is no difference from the above case, but the subsequent nodes The work list at the time point (3) when X is the attention node and its lower node is added to the work list and the time point (4) when the lower node is added to the work list after node Y is the attention node is shown in FIG. Different from that shown in FIG. Even if the nodes A to D become nodes of interest thereafter, a new node is not added to the work list, so the work list that is finally completed is also shown in FIG. 42 (4).

Even in this case, the update order in the completed work list is performed after the processing for the node functioning as the server is completed for all of the nodes functioning as clients when the node is the communication partner of the node. This condition is satisfied. Therefore, it can be said that there is no single appropriate update order. In addition, depending on the function when the node of interest communicates with the lower node, if the node of interest functions as a server, the lower node is added to an arbitrary position before the node of interest in the work list. When the node of interest functions as a client, a lower node may be added at an arbitrary position after the node of interest in the work list.
In addition, regarding the attention point list, it is not essential to create such a list, and the attention node may be changed in the above-described order by some processing. Such processing can also be realized using, for example, recursive calling of processing. Also, it is not essential that the work list be created in the form of a list, and any form may be used as long as the certificate management apparatus 10 can recognize the execution order of transmission procedures for each node.

[Third Embodiment: FIGS. 43 to 49]
Next, a third embodiment of the digital certificate management system according to the present invention, which is constituted by a certificate management device which is a digital certificate management device according to the present invention, and a client device and a server device constituting a client / server system, is described. The configuration of the form will be described.
In this digital certificate management system, the configurations of the client / server system and the certificate management apparatus are the same as those in the second embodiment, and only the work list creation procedure is different from that in the second embodiment. Only this point will be described. The update procedure in this embodiment is also created and managed by the update order control unit 27 of the certificate management apparatus 10 based on the configuration information stored in the configuration storage unit 26. The creation of this update procedure is also the present invention. This is processing related to the update procedure determination method.

In this embodiment, in the process of creating the execution order of the processes 11, the process shown in FIG. 43 is executed instead of the process of FIG. 21 in the second embodiment. That is, when the determination in step S403 in FIG. 20 is NO, the process proceeds to step S412 in FIG. 43, and after step S420 in FIG. 43, the process proceeds to step S403 in FIG. In the process shown in FIG. 43, the process of step S422 is performed instead of step S413, and the process of step S421 is performed between step S417 and step S418 as described in the above modification. The only difference is the processing shown in FIG.
The step S422 differs from the second embodiment in that the position where the attention node is added to the attention point list is not the rear end but the front end when there is a lower node in the attention node. The processing in the third embodiment is almost the same as in the second embodiment. However, because of this, the order of change of the node of interest when creating the update procedure is greatly different. This point will be described below using an example of creating a work list in this embodiment.

FIGS. 44 to 49 are diagrams showing information of each node, the work list, and the attention point list at various points in the process of creating the work list.
Also in this embodiment, the configuration of the client / server system is as shown in FIG. 13, and the initial state of information about each node is the same as that in the second embodiment. Then, when creating a work list, the processing starts from step S401 in FIG. Thereafter, the node O and the subordinate nodes X and Y are added to the work list first with the highest node O as the attention node, and then the nodes A and B of the subordinate nodes are added to the work list with the node X as the attention node. This process is the same as in the case of the second embodiment. At this time, the information about the node O is shown in FIG. 24, the information about the nodes X, A, and B is shown in FIG. 26, and the information about the node Y is shown in FIG. It ’s right.

  Then, after adding the nodes A and B to the work list, if there is no “unprocessed” link in the node X that is the node of interest, the process proceeds from step S403 in FIG. 20 to step S412 in FIG. Since there is a lower node, it is added to the front end of the attention point list in step S422. The work list and attention point list at this time are as shown in FIG. In this state, since the node of interest is at the front end of the work list, in the processing from step S414, the lower node is searched first, not the same generation of the node of interest.

Next, the process proceeds from step S414 to S415, the node X at the front end is deleted from the list, and the information of the node X is referred to. Since the node state of the node X is “attentioned” as shown in FIG. 26, the process proceeds from step S416 to S417, and since there are two links that are not “processed”, the process proceeds from step S421 to S418. Add to the front end of the list of points of interest. In step S419, if processing is performed on the link to the node A, the node A is added to the front end of the attention point list, and the link state of the link is set to “processed”.
In the processing so far, the information about the node X is changed as shown in FIG. 45, and the information about the other nodes is not changed from the time of FIG. The work list and the attention point list have the contents shown in FIG.

  Next, the process returns to step S414, proceeds to step S415, deletes node A at the front end of the attention point list, and refers to the information. Then, since the node state of the node A is “added” as shown in FIG. 26, the process proceeds from step S416 to step S420, the node of interest is changed to the node A, and the node state is changed to “attentioned”. . Then, the process returns to step S403 in FIG. 20, but since node A does not have a link to a lower node in the first place, the process proceeds to step S412 as it is. Since node A has no lower nodes, the process proceeds to step S414 without adding it to the attention point list. In the processing so far, the attention point list has the contents shown in FIG. The work list has not changed from the state shown in FIG.

Next, the process proceeds from step S414 to S415, the node X at the front end of the attention point list is deleted, and the information is referred to. Since there is no lower node in node A, the node is traced upward to search for a node having a lower node that has not yet become a target node.
Since the node state of the node X is “focused” as shown in FIG. 45, the process proceeds from step S416 to S417. Since there is only one link to node B that is not “processed”, steps S421 to S418 are skipped and the process proceeds to step S419, where node B is added to the front end of the point of interest list and the link status of the link is changed to “ Set to Processed. In the processing so far, the attention point list has the contents shown in FIG. The work list has not changed from the state shown in FIG.
Next, this node B becomes the node of interest, but the node B also has no link to a lower node, so the process returns from step S403 to step S412 as it is. Then, the process proceeds to step S414 without adding the node B to the attention point list. In the process so far, the attention point list has the contents shown in FIG.

Next, the process proceeds from step S414 to S415, and the node O at the front end of the attention point list is deleted and the information is referred to. Since there is no lower node that has not yet become the attention node in the node B or the upper node X, a node having a lower node that has not yet become the attention node is searched for for the upper node.
Then, since the node state of the node O is “focused” as shown in FIG. 24, the process proceeds from step S416 to S417, and since there is only one link to the node Y that is not “processed”, from step S421. In step S418, the process skips to step S419, where the node Y is added to the front end of the attention point list and the link state of the link is set to “processed”. With the processing so far, the attention point list has the contents shown in FIG.

Next, the node Y at the front end of the attention point list is deleted and the information is referred to. However, the node state of the node Y is “added” as shown in FIG. Become a node. That is, the nodes are sequentially traced from the previous node of interest B to the upper level, and the lower node of the node O having the lower node that has not yet become the target node becomes the next target node. Then, nodes C and D in which the node state is “unprocessed” are added to the work list by the processing after step S403 in FIG. In the processing so far, the work list and the point of interest list each have the contents shown in FIG.
All nodes are now added to the work list. However, since this is not known during processing, the same processing is repeated until the attention point list becomes empty. The subsequent changes in the attention point list are as shown in FIG. FIG. 49 shows the state of the attention point list at that time each time the process reaches step S414.

  After the state shown in FIG. 48, since the two links to the nodes C and D are not “processed” for the node Y at the front end, the node Y is added to the front end of the attention list, and the node first Similarly, C is added (1), and the node C becomes the next node of interest. However, since node C has no lower nodes, the process returns to step S414 as it is (2). Then, the process from step S415 is performed again on the node Y, but this time, since there is only one link to the node D that is not “processed”, only the node D is added to the front end of the attention point list (3). . Then, the node D becomes the next node of interest, but the node D does not have a lower node, so the process returns to the step S414 as it is (4). Since the attention point list is empty at this point, the process is terminated.

  Thus, the work list is completed, and processing 11 is performed in the order of D → B → Y → O → X → A → C as shown in FIG. This order is the same as that described in the second embodiment as a result, but the node of interest starts from the topmost O as described above, and O → X → A → B → Y → C → D. It is changed in the order. Therefore, if there is a node that is a lower node of the target node and not yet the target node, the target node is changed to one of the nodes, and if there is no such node, the nodes are sequentially traced upward. When there is a node having a lower node that has not yet become a target node, the node is changed to one of the lower nodes.

  The attention node can be changed in this order because the attention node is added to the front end of the attention point list in step S422 in FIG. 43, and the lower node of the attention node is preceded by another lower node viewed from the upper node. This is because the next attention node is searched. Then, as this process is repeated, the nodes traced from the highest node to the lower nodes are accumulated in the attention point list. Therefore, after the lowest node that does not have a lower node becomes the attention node, it is possible to sequentially search higher nodes based on the attention point list to find another lower node that has not yet become the attention node. It is.

If the execution order of the process 11 is created as described above, the process S is executed before that, and then the process 12 is executed for each node in any order, for example, in ascending order of the number of generations, the first As in the case of the second embodiment, an appropriate processing procedure for updating the root key can be determined, and the same effect can be obtained.
In this case, the processing in step S421 may not be performed as in the second embodiment, and other modifications similar to those in the second embodiment may be applied.

[Characteristics of the second and third embodiments: FIGS. 50 to 54]
In the description of the digital certificate management system of the second and third embodiments described above, the case where the configuration of the client / server system is as shown in FIG. 13 has been described. The work list became the same, and the length of the attention list during processing was similar. However, when the configuration of the client / server system becomes complicated, these processes give different results, and thereby produce different effects.

  Here, the processing for creating a work list in the procedure described in the second and third embodiments described above for the digital certificate management system having the configuration shown in FIG. 50 will be described, and these embodiments will be individually described. The characteristic which has is demonstrated. In this digital certificate management system, the client / server system is composed of 13 nodes over 4 generations. The communication partner of each node and whether it functions as a client or a server when communicating with the communication partner are indicated by arrows and symbols “S” and “C” as in the case of FIG. Further, the configuration information about each of these nodes is stored in the configuration storage unit 26 of the certificate management apparatus 10 in the format shown in FIG. 14, but the illustration thereof is omitted because of the large number of nodes.

First, for the client / server system having such a configuration, a flow of processing when a work list is created by the processing described in the second embodiment will be described. However, in order to shorten the process, it is assumed that the process of step S421 illustrated in FIG. 40 is performed as in the above-described modification.
The flow of this process is shown in FIGS. In these drawings, the contents of the attention point list and work list being processed and the attention node are shown in order, step S301 is the state at the time of step S402 in FIG. 20, and the subsequent steps are the processing in FIG. Each time step S414 is reached, the current state is shown. In the attention point list and the work list, one letter of the alphabet represents one node (for example, “A” is node A), and the underlined character is information added compared to the time of the previous step, Lower case letters indicate information that has been deleted compared to the time of the previous step.

  As can be seen from these figures, when the processing described in the second embodiment is performed, the node of interest is O → X → Y → A → B → C → D → E → F → G → H → I → It changes in the order of J. Therefore, if there is a node of the same generation that is not the target node, that node is first set as the target node, and after all the nodes of the same generation have become the target node, the lower level node is set as the target node. In order to do this, when a node of a certain generation is determined as a node of interest sequentially, the node of that generation is accumulated in the point of interest list, and its lower nodes are referenced later. Therefore, the maximum length of the attention point list is about the number of nodes of the generation having the largest number of nodes other than the lowest node.

  On the other hand, since nodes of the same generation are sequentially determined as nodes of interest, nodes of the same generation are arranged together in the work list. In the example shown here, the fourth generation J, H, G, E and C, F, I are collected, and the third generation D, B, A, C are also arranged in a small number. ing. Since nodes of the same generation do not directly communicate with each other, the processing for the next node can be started without waiting for the completion of the processing for the previous node with respect to these nodes arranged together. Therefore, the throughput when performing the root key update process can be improved.

  Note that the context of nodes that are not directly communicable, such as node E and node G, in the work list is not particularly problematic. This is the same even when the node E and the node G can communicate with a common upper node. Since both the node E and the node G function as clients when communicating with the upper node, the node E and the node G are positioned before the upper node in the work list. Depends on the order of performing the update order determination process. The order in which the update order determination process is performed usually depends on the description order of the node information. Accordingly, it is also possible to cope with the creation of a work list in which the nodes are arranged at close positions by collectively describing information on nodes that are desired to be updated together. Also by doing this, as in the case described above, the throughput in the case of performing the root key update process can be improved.

Next, the flow of processing when creating a work list by the processing described in the third embodiment will be described. The flow of this process is shown in FIGS. 53 and 54, and the meanings of the symbols shown are the same as those in FIGS.
As can be seen from these figures, when the processing described in the third embodiment is performed, the node of interest is O → X → A → E → F → B → G → Y → C → H → D → I → It changes in the order of J. Accordingly, the lower node is first traced to be the attention node, and when the lowest node is reached, the lower node is returned to the upper node and another lower node that has not yet become the attention node is regarded as the attention node. In order to do this, when the lower nodes are traced in order and set as the attention node, the traced route is accumulated in the attention point list and later returned to refer to the lower node. ing. Therefore, the maximum length of the attention point list is about the number of generations of the lowest node.

  For example, when applying this embodiment to updating a root key in a remote management system by a client / server system or an electronic commerce system, there is a system that can communicate between one management device and many terminal devices. In such a case, it is possible that the same generation of devices may reach several thousand or tens of thousands of devices. However, even in such a case, since the number of generations does not normally become such a number, according to the processing described in the third embodiment, the attention point list can be shortened, and the work area required for the processing can be reduced. The amount can be reduced.

[Other Modifications of Each Embodiment described above: FIGS. 55 to 57]
In each of the embodiments described above, an example has been described in which the client device 40 and the server device 30 or each node performs an authentication process using SSL as described with reference to FIG. 4 or FIG. However, even if this authentication process is not necessarily such, this embodiment is effective.
TLS (Transport Layer Security) improved from SSL is also known, but it is naturally applicable to the case where authentication processing based on this protocol is performed.

  In the above-described embodiment, the example in which the certificate management apparatus 10 is provided separately from the nodes constituting the client / server system has been described, but this does not prevent the certificate management apparatus 10 from being provided integrally therewith. In this case, components such as a CPU, a ROM, and a RAM for realizing the function of the certificate management apparatus 10 may be provided independently. The certificate management apparatus 10 may be caused to function by causing the CPU to execute appropriate software.

In such a case, for communication between the certificate management apparatus 10 and a node integrated with the certificate management apparatus 10, a process for causing the hardware to function as the certificate management apparatus 10 and the hardware are connected to the node. Inter-process communication with a process for functioning as
Furthermore, in each of the above-described embodiments, the certificate management device 10 has created an example of creating a certificate key or a digital certificate and acquiring the certificate key, but the certificate key creating unit 21 illustrated in FIGS. 2 and 12 has been described. And the function of the certificate issuing unit 22 may be provided in an apparatus different from the certificate management apparatus 10 so that the certificate management apparatus 10 obtains the certificate key and the digital certificate supplied from the apparatus. Good.

  The certificate management apparatus 10 may be configured to directly communicate with a plurality of nodes. However, even in such a case, it is preferable to select one of the nodes directly serving as communication partners to be the highest node and to determine the route key update procedure based on this. In this way, the communication sequence shown in each sequence diagram becomes different as the certificate management apparatus 10 can directly communicate with a plurality of nodes. It is the same as the case of the form. Even if it does in this way, the effect of each embodiment mentioned above can be acquired.

Further, in the modification of the first embodiment, when performing communication between the certificate management device 10 and the client device 40, authentication processing by SSL can be performed. The same applies to the case where the uppermost node functions as a client when communicating with a lower node in the second and third embodiments or modifications thereof.
To do this, as shown in FIG. 55, the client device 40 (the highest node) has a client private key, a client public key certificate, and a root key used for authentication processing with the server device 30 (lower node). Apart from the certificate (as described in the embodiment), another set of private key, public key certificate and root key certificate ("second client private key", "second client public key certificate") And “second root key certificate”), and these may be used for authentication processing with the certificate management apparatus 10.

In this case, the certificate management apparatus 10 also stores the management apparatus private key, the management apparatus public key certificate, and the second root key certificate, and uses them for the authentication process. The contents of the second client public key certificate and the management apparatus public key certificate can be confirmed by the second root key included in the second root key certificate. That is, the digital signature is attached using the root private key (second root private key) corresponding to the second root key.
In this way, the authentication process between the certificate management apparatus 10 and the client apparatus 40 and the authentication process between the client apparatus 40 and the server apparatus 30 can be performed completely independently.

As described with reference to FIG. 12, the client device 40 in the modification of the first embodiment is communicated with the certificate management device 10 by the server function unit 44, and communicated with the server device 30 by the client function unit 43. This is performed via the communication function unit 42. Accordingly, the communication requested from the certificate management apparatus 10 and the communication requested from the server apparatus 30 can be clearly distinguished, so that authentication processing using different keys and certificates is performed between them. Can be done.
In such a case, even if the root key certificate or public key certificate used for the authentication process between the client device 40 and the server device 30 is updated in response to a request from the certificate management device 10, the certificate management There is no effect on the authentication process between the device 10 and the client device 40.

If the update process is performed according to the procedure described in each embodiment, the update process can be performed without greatly affecting the authentication process between the client apparatus 40 and the server apparatus 30, as described above. It can be said that the root key can be updated while maintaining the authentication process between the nodes by adopting the configuration shown in FIG.
When the second root key certificate is to be updated, update processing may be performed according to the procedure of any of the above-described embodiments using the certificate management apparatus 10 as a client and the client apparatus 40 as a server. Even if such update processing is performed, there is no influence on the authentication processing between the client device 40 and the server device 30.

  Further, in each of the above-described embodiments, the example in which the root key certificate and the public key certificate stored in all the nodes necessary for each node to perform mutual authentication has been described. However, if one-way authentication as shown in FIG. 5 is performed, only a root key certificate is given to a node functioning only as a client, and only a public key certificate and a private key are assigned to a node functioning only as a server. It is enough if you remember it. The node functioning as both the client and the server stores all the root key certificate, public key certificate, and private key. However, if the root key certificate is also stored in a node that functions only as a server, it can be stored after the validity of the new public key certificate is confirmed when the root key is updated. it can.

In this case, the root key certificate update process shown in the second and third embodiments and the modified examples may be modified as follows.
That is, for the node that functions only as a client, the certificate storage process shown in FIG. 19 is replaced with the process 11 ′ shown in FIG. 56 or the process 11 ″ shown in FIG. 57, instead of the process 11 shown in FIG. You just have to do it.

The process 11 ′ shown in FIG. 56 is such that a new public key certificate is not generated and transmitted because there is no need to store the public key certificate in a node that functions only as a client. Accordingly, the processing 11 ′ has no processing corresponding to step S311 in the processing 11, and the new public key certificate is not transmitted in steps S312 ′ and S314 ′. The processing corresponding to step S319 and step S320, which is a process of storing the new public key certificate on the target node side, is also not performed.
By performing such processing, the new root key certificate can be transmitted and stored in a node that functions only as a client.

On the other hand, in the process 11 ″ shown in FIG. 57, the new public key certificate is generated and transmitted as in the case of the process 11, but the new public key certificate is ignored at the target node. Therefore, the process 11 ″ is obtained by simply deleting steps S319 and S320 from the process 11. Even with such processing, the new root key certificate can be transmitted and stored in a node that functions only as a client.
When such a process is adopted, the process in the certificate management apparatus 10 and the upper node can be shared with the case where the target node functions as only a server or functions as both a client and a server. Therefore, although the new public key certificate is created / transmitted unnecessarily, the management of the update processing procedure can be simplified.

  Note that the node functioning as only the server and the node functioning as both the client and the server store both the root key certificate and the public key certificate, so the process 11 shown in FIG. 17 is performed. If the root key certificate is not stored in the node functioning only as the server, it is only necessary to transmit the new public key certificate and the update request (transmission request) in steps S312 and S314, and in steps S315 to S318 in the target node. No processing is necessary.

Even in this case, the execution order of the process 11, 11 ′ or 11 ″ with respect to each node is determined by the update order determination process as described in the second and third embodiments or the modifications thereof. As in the case of each embodiment or modification, the root key can be updated by automatic control without greatly affecting the authentication process between the nodes.
It goes without saying that such a modification can be applied to the first embodiment as well.

Of course, the techniques described in the above embodiments and modifications may be used in combination.
The program according to the present invention is used for authentication processing between each node of the client / server system to a computer capable of communicating directly or indirectly with a plurality of devices constituting the client / server system via a network. A program for realizing a function of updating a certification key used for confirming the validity of a digital certificate, storing configuration information, and processing as described in each of the above embodiments based on this program The above-described effects can be obtained by causing a computer to execute a program for realizing a function for determining the update procedure of the certification key.

Such a program may be stored in a storage means such as a ROM or HDD provided in the computer from the beginning, but a non-volatile recording such as a CD-ROM or flexible disk, SRAM, EEPROM, memory card or the like as a recording medium. It can also be recorded on a medium (memory) and provided. Each procedure described above can be executed by installing a program recorded in the memory in a computer and causing the CPU to execute the program, or causing the CPU to read and execute the program from the memory.
Furthermore, it is also possible to download and execute an external device that is connected to a network and includes a recording medium that records the program, or an external device that stores the program in the storage unit.

As described above, by using the update procedure determination method, program, digital certificate management system, and digital certificate management apparatus of the present invention, the validity of the digital certificate is confirmed by the authentication process in the client / server system. Therefore, it is possible to safely update the certification key used for this purpose without providing a special communication path for updating.
Therefore, by applying the present invention to management of a certificate used for authentication processing in a client / server system, a system capable of updating the authentication public key safely can be provided at low cost.

It is a block diagram which shows the hardware constitutions of the certificate management apparatus which is embodiment of the digital certificate management apparatus of this invention. It is a functional block diagram which shows the function structure of the part which becomes the characteristic of this invention of each apparatus which comprises 1st Embodiment of the digital certificate management system of this invention. It is a conceptual diagram which shows the data transmission / reception model in the digital certificate management system shown in FIG. It is a figure which shows the flowchart of the process performed in each apparatus at the time of a client apparatus and a server apparatus performing mutual authentication by SSL with the information used for the process. It is a figure which shows the flowchart of the process performed in each apparatus at the time of a client apparatus and a server apparatus performing one-way authentication by SSL with the information used for the process. FIG. 3 is a sequence diagram showing a part of root key update processing in the digital certificate management system shown in FIG. 2. FIG. 7 is a sequence diagram showing processing subsequent to FIG. 6. FIG. 8 is a sequence diagram showing processing subsequent to FIG. 7. FIG. 9 is a sequence diagram illustrating processing subsequent to FIG. 8. It is a figure which shows the modification of the sequence shown in FIG.

It is a figure which shows the modification of the sequence shown in FIG. It is a functional block diagram which shows the function structure of the part which becomes the characteristic of this invention of each apparatus which comprises the modification of 1st Embodiment of the digital certificate management system of this invention. It is a block diagram which shows the relationship of each apparatus which comprises 2nd Embodiment of the digital certificate management system of this invention. It is a figure which shows the example of the storage format of the information of each node memorize | stored in the structure memory | storage part shown in FIG. FIG. 15 is a diagram illustrating a description example when information is described in the format illustrated in FIG. 14 for each node configuring the client / server system in the digital certificate management system illustrated in FIG. 13. It is a sequence diagram for demonstrating the communication procedure at the time of transmitting a request | requirement with respect to a low-order node from a certificate management apparatus. FIG. 14 is a sequence diagram showing certificate storage processing for each node in the root key update processing in the digital certificate management system shown in FIG. 13. Similarly, it is a sequence diagram showing an old key discard process for each node. It is a figure which shows the execution order of each process shown in the sequence diagram of FIG.6, FIG.17 and FIG.18 in the root key update process of 2nd Embodiment. It is a flowchart which shows a part of process which produces the execution order of the certificate memory | storage process with respect to each node as a work list among the preparation processes of the update procedure regarding the root key update process of 2nd Embodiment.

FIG. 21 is a flowchart illustrating processing subsequent to FIG. 20. FIG. FIG. 22 is a diagram illustrating the contents of information about nodes O, X, and Y at a certain point in time when the processing illustrated in FIGS. 20 and 21 is being performed. It is a figure which shows the state of the work list | wrist and an attention point list | wrist in the same time as FIG. It is a figure which shows the content of the information regarding the node O at a certain time after the time of FIG. FIG. 25 is a diagram showing changes in the work list and the point of interest list from the time point shown in FIG. 23 to the same time point as in FIG. 24. It is a figure which respectively shows the content of the information about the nodes X, A, and B at a certain time after the time of FIG. FIG. 26 is a diagram showing changes in the work list and the attention point list from the time point shown in FIG. 25 to the same time point as in FIG. 26. It is a figure which shows the content of the information regarding the node O at a certain time after the time of FIG. It is a figure which shows the change of the work list | wrist and the attention point list | wrist from the time shown in FIG. 27 to the same time as FIG. It is a figure which respectively shows the content of the information about the nodes Y, C, and D at a certain time after the time of FIG.

It is a figure which shows the change of the work list | wrist and the attention point list | wrist from the time shown in FIG. 29 to the same time as FIG. It is a figure which shows the change of the work list | wrist and the attention point list | wrist from the time shown in FIG. 30 to a certain time after that. It is a figure which shows the content of the information regarding the node X at a certain time after the time of FIG. It is a figure which shows the change of the work list | wrist and the attention point list | wrist from the time shown in FIG. 32 to the same time as FIG. It is a figure which shows the content of the information about the node A at a certain time after the time of FIG. It is a figure which shows the change of the work list | wrist and the attention point list | wrist from the time shown in FIG. 34 to the same time as FIG. It is a figure which shows the change of the attention point list after the time shown in FIG. 36 later on. It is a figure which shows the content of the information about each node at the time of a work list being completed. It is a figure which shows the contents of the work list and the attention point list when the work list is completed. It is a flowchart which shows the part which changes the process shown in FIG. 21 among the preparation processes of the update procedure in the modification of 2nd Embodiment.

It is a figure which shows the change of the attention point list | wrist of the part corresponding to FIG. 37 later on when the process shown in FIG. 40 is performed. It is a figure which shows the creation process of the work list | wrist at the time of performing the preparation process of the update procedure in another modification of 2nd Embodiment. It is a flowchart which shows a part of process which produces the execution order of the certificate memory | storage process with respect to each node among the preparation processes of the update procedure regarding the root key update process of 3rd Embodiment. It is a figure which shows the state of the work list | wrist and an attention point list | wrist in the time of performing said process. FIG. 45 is a diagram illustrating the content of information regarding a node X at a certain time after the time illustrated in FIG. 44. It is a figure which shows the change of the work list | wrist from the time shown in FIG. 44 to the same time as FIG. 45, and an attention point list | wrist. It is a figure which shows the change of the attention point list after the time shown in FIG. 46 later on. It is a figure which shows the change of the work list | wrist and the attention point list | wrist from the time shown to FIG. 47 (4) to a certain time after it. It is a figure which shows the change of the attention point list after the time shown in FIG. 48 later on. It is a block diagram which shows the relationship of each apparatus in the structural example different from FIG. 13 of the digital certificate management system of this invention.

In the digital certificate management system having the configuration shown in FIG. 50, when the work list is created by the same processing as in the modification of the second embodiment, the changes in the attention point list, the attention node, and the work list are performed in order. It is a figure shown later. It is a figure which shows the continuation of FIG. FIG. 52 is a diagram corresponding to FIG. 51, showing changes in the attention point list, the attention node, and the work list step by step when a work list is created by the same process as in the third embodiment. It is a figure which shows the continuation of FIG. It is a figure for demonstrating the storage state of a key and a certificate, and the root key update process in that case in another modification of each embodiment. FIG. 18 is a sequence diagram illustrating a modification of the certificate storage process illustrated in FIG. 17 that is executed when a modification of each embodiment is applied. It is a sequence diagram which shows the other example. It is a figure for demonstrating the relationship between the root key, root private key, and server public key in the authentication process using a public key cryptosystem.

Explanation of symbols

10: Certificate management device 11: CPU
12: ROM 13: RAM
14: HDD 15: Communication I / F
16: System bus 21: Certificate key generation unit 22: Certificate issuing unit 23: Certificate management unit 24: Certificate update unit 25, 32, 42: Communication function unit 30: Server device 31, 41: Certificate storage unit 33, 44: Server function unit 40: Client device 43: Client function unit

Claims (19)

A certificate used to confirm the validity of a digital certificate used for authentication between each node in a client / server system configured in multiple stages in a format in which the upper node follows the lower node. An update procedure determining method for determining an update procedure when a key is updated by a digital certificate management apparatus capable of communicating with each of the nodes,
The digital certificate management device is
For each node constituting the client / server system, the update procedure is performed based on the communication partner of the node and information on whether the node functions as a client or a server. It is determined to include a transmission procedure for simultaneously transmitting a new certificate key and / or a new digital certificate that can be verified using the new certificate key and that is used by the target node for the authentication. ,
At that time, execute the procedure of creating the execution order of the transmission procedure for each node,
First, add any of the nodes in the execution order, and then start each node constituting the client / server system in turn as a node of interest and add to the node of communication with the node of interest and in the order of execution If there is a node that is not connected, for each of the communication partners, it is determined whether the node of interest functions as a client or a server when communicating with the communication partner. A method for determining an update procedure, wherein the update procedure is added after the node of interest in the execution order, and if it is a server, the communication partner is added before the node of interest in the execution order. A certificate used to confirm the validity of a digital certificate used for authentication between each node in a client / server system configured in multiple stages in a format in which the upper node follows the lower node. An update procedure determining method for determining an update procedure when a key is updated by a digital certificate management apparatus capable of communicating with each of the nodes,
The digital certificate management device is
For each node constituting the client / server system, the update procedure is performed based on the communication partner of the node and information on whether the node functions as a client or a server. It is determined to include a transmission procedure for simultaneously transmitting a new certificate key and / or a new digital certificate that can be verified using the new certificate key and that is used by the target node for the authentication. ,
At that time, execute a procedure of creating an execution order of the transmission procedure for each node as a work list,
A step of initializing the work list, and a step of setting the highest node among the nodes constituting the client / server system as a target node and adding to the work list,
A method for determining an update procedure, characterized in that a node that has become a node of interest is stored, and thereafter the following procedures (1) and (2) are repeated until it is determined that all nodes have become nodes of interest.
(1) When there is a subordinate node in the node of interest, the rank is set below the node of interest for each of the subordinate nodes, and when the node of interest uses the subordinate node as a communication partner, either client or server (2) Procedure for adding the lower node to the rear end of the work list if it is a client, and adding the lower node to the front end of the work list if it is a server (2) If there is a node that has the same rank as that of the node of interest and has not yet become a node of interest, if there is no such node, the rank is lower than the node of interest and is still the node of interest To change to one of the nodes An update procedure determination method according to claim 2, comprising:
The digital certificate management device replaces the procedure (1) with
When there are subordinate nodes in the target node, the rank is set to the subordinate of the target node for each of the subordinate nodes, and the target node functions as either a client or a server when the subordinate node is the communication partner. If it is a client, its lower node is added immediately after the node of interest in the work list, and if it is a server, its lower node is added immediately before the node of interest in the work list. An update procedure determination method characterized by being executed. An update procedure determination method according to claim 2, comprising:
The digital certificate management device is
An updating procedure determination method characterized by repeating the following procedures (1) and (2) instead of the procedures (1) and (2).
(1) When there are subordinate nodes in the node of interest, it is determined whether each of the subordinate nodes functions as a client or a server when the node of interest uses the subordinate node as a communication partner. If the server is a server, add the lower node to the rear end of the work list, and if it is a server, add the sub node to the front end of the work list. If there is a node that is not a node, change it to one of them, and if there is no such node, follow the nodes in order toward the upper level, and there is a node with a lower level node that has not yet become a target node To change to one of its subordinate nodes in case An update procedure determination method according to claim 4,
The digital certificate management device replaces the procedure (1) with
When there are subordinate nodes in the target node, it is determined for each of the subordinate nodes whether the target node functions as a client or a server when the subordinate node is the communication partner. A node is added immediately after the node of interest in the work list, and if it is a server, a procedure for adding a subordinate node immediately before the node of interest in the work list is executed. Procedure decision method. The update procedure determination method according to claim 2 or 3,
The digital certificate management device is
Create a point of interest list for determining the change destination of the node of interest;
In the procedure for initializing the work list, the attention point list is also initialized,
In the procedure (2),
If the node of interest has a lower node, add the node of interest to the end of the list of points of interest;
After that, if there is a node that is not a target node yet in the lower node of the front end node of the target point list, the target node is changed to that node, and if not, the front end node of the target point list is changed from the target point list. The attention node changing procedure to be deleted is repeated until a new attention node is determined or the attention point list becomes empty,
An update procedure determination method, characterized in that, when the attention point list becomes empty, it is determined that all nodes have become attention nodes. The update procedure determination method according to claim 4 or 5,
The digital certificate management device is
Create a point of interest list for determining the change destination of the node of interest;
In the procedure for initializing the work list, the attention point list is also initialized,
In the procedure (2),
If there is a lower node in the node of interest, add the node of interest to the front end of the list of points of interest;
After that, if there is a node that is not a target node yet in the lower node of the front end node of the target point list, the target node is changed to that node, and if not, the front end node of the target point list is changed from the target point list. The attention node changing procedure to be deleted is repeated until a new attention node is determined or the attention point list becomes empty,
An update procedure determination method, characterized in that, when the attention point list becomes empty, it is determined that all nodes have become attention nodes. The update procedure determination method according to claim 6 or 7,
In the node-of-interest changing procedure, if there is one node that is not yet the node of interest among the lower nodes of the node at the front end of the point-of-interest list, A method for determining an update procedure, wherein a node at the front end of a point list is deleted from the point of interest list. An update procedure determination method according to any one of claims 1 to 8,
The authentication between the nodes is an authentication according to an SSL or TLS protocol,
The digital certificate is a public key certificate of each of the nodes, respectively. To a computer that controls a digital certificate management device that can communicate with each node of a client / server system configured in a plurality of stages in a form in which an upper node follows a lower node,
A program for realizing a function of storing a certificate key used for confirming the validity of a digital certificate used for authentication between each node stored in each node of the client / server system,
In the computer,
For each node constituting the client / server system, the update procedure is performed based on the communication partner of the node and information on whether the node functions as a client or a server. A new certification key and / or a new digital certificate that can be verified using the new certification key and used by the target node for the authentication are defined to include a transmission procedure for simultaneously transmitting each node. Realize the function,
In determining the update procedure, the procedure for creating the execution order of the transmission procedure for each node is executed,
First, add any of the nodes in the execution order, and then start each node constituting the client / server system in turn as a node of interest and add to the node of communication with the node of interest and in the order of execution If there is a node that is not connected, for each of the communication partners, it is determined whether the node of interest functions as a client or a server when communicating with the communication partner. A program that is added after the node of interest in the execution order and that executes a procedure for adding a communication partner before the node of interest in the execution order if it is a server. To a computer that controls a digital certificate management device that can communicate with each node of a client / server system configured in a plurality of stages in a form in which an upper node follows a lower node,
A program for realizing a function of storing a certificate key used for confirming the validity of a digital certificate used for authentication between each node stored in each node of the client / server system,
In the computer,
For each node constituting the client / server system, the update procedure is performed based on the communication partner of the node and information on whether the node functions as a client or a server. A new certification key and / or a new digital certificate that can be verified using the new certification key and used by the target node for the authentication are defined to include a transmission procedure for simultaneously transmitting each node. Realize the function,
When defining the update procedure, the procedure for creating the execution order of the transmission procedure for each node as a work list is executed,
A step of initializing the work list, and a step of setting the highest node among the nodes constituting the client / server system as a node of interest and adding to the work list,
Furthermore, a program for storing nodes that have become nodes of interest and repeatedly executing the following procedures (1) and (2) until it is determined that all nodes have subsequently become nodes of interest.
(1) When there is a subordinate node in the node of interest, the rank is set below the node of interest for each of the subordinate nodes, and when the node of interest uses the subordinate node as a communication partner, either client or server (2) Procedure for adding the lower node to the rear end of the work list if it is a client, and adding the lower node to the front end of the work list if it is a server (2) If there is a node that has the same rank as that of the node of interest and has not yet become a node of interest, if there is no such node, the rank is lower than the node of interest and is still the node of interest To change to one of the nodes The program according to claim 11, wherein
Instead of the procedure (1), the computer
When there are subordinate nodes in the target node, the rank is set to the subordinate of the target node for each of the subordinate nodes, and the target node functions as either a client or a server when the subordinate node is the communication partner. If it is a client, its lower node is added immediately after the node of interest in the work list, and if it is a server, its lower node is added immediately before the node of interest in the work list. A program to be executed. The program according to claim 11, wherein
In the computer,
A program for repeatedly executing the following procedures (1) and (2) instead of the procedures (1) and (2).
(1) When there are subordinate nodes in the node of interest, it is determined whether each of the subordinate nodes functions as a client or a server when the node of interest uses the subordinate node as a communication partner. If the server is a server, add the lower node to the rear end of the work list, and if it is a server, add the sub node to the front end of the work list. If there is a node that is not a node, change it to one of them, and if there is no such node, follow the nodes in order toward the upper level, and there is a node with a lower level node that has not yet become a target node To change to one of its subordinate nodes in case 14. The program according to claim 13, wherein
Instead of the procedure (1), the computer
When there are subordinate nodes in the target node, it is determined for each of the subordinate nodes whether the target node functions as a client or a server when the subordinate node is the communication partner. A program for adding a node immediately after the node of interest in the work list and adding a lower node of the work list immediately before the node of interest in the work list. A program according to claim 11 or 12,
In the computer,
Realizing a function of creating a list of points of interest for determining a change destination of the node of interest;
In the procedure for initializing the work list, the attention point list is also initialized,
In the procedure (2),
If there is a lower node in the node of interest, the node of interest is added to the end of the list of points of interest;
After that, if there is a node that is not a target node yet in the lower node of the front end node of the target point list, the target node is changed to that node, and if not, the front end node of the target point list is changed from the target point list. The attention node changing procedure to be deleted is repeated until a new attention node is determined or the attention point list is empty,
A program further comprising a program for determining that all nodes have become attention nodes when the attention point list becomes empty. The program according to claim 13 or 14,
In the computer,
Realizing a function of creating a list of points of interest for determining a change destination of the node of interest;
In the procedure for initializing the work list, the attention point list is also initialized,
In the procedure (2),
If there is a lower node in the node of interest, the node of interest is added to the front end of the list of points of interest;
After that, if there is a node that is not a target node yet in the lower node of the front end node of the target point list, the target node is changed to that node, and if not, the front end node of the target point list is changed from the target point list. The attention node changing procedure to be deleted is repeated until a new attention node is determined or the attention point list is empty,
A program further comprising a program for determining that all nodes have become attention nodes when the attention point list becomes empty. A program according to any one of claims 10 to 16,
The authentication is authentication according to a protocol of SSL or TLS,
The digital certificate is a public key certificate of each node, respectively. Digital certificate management capable of communicating with each node in a client / server system in which a higher level node follows a lower level node and is configured in a plurality of stages and performs authentication using a digital certificate between the nodes. A digital certificate management system connected with devices,
In the digital certificate management device,
A certification key updating means for updating a certification key for confirming the validity of the digital certificate used by each node for the authentication;
For each node constituting the client / server system, based on the communication partner of the node and information on whether it functions as a client or a server between the communication partner, An update order control means for controlling the update procedure;
In the certification key update means,
Means for obtaining a new certification key for renewal;
Means for obtaining a new digital certificate for use in the authentication, the validity of which can be confirmed using the new certification key;
Transmitting means for transmitting the new digital certificate and / or the new certification key for each node to the corresponding node, respectively.
10. The digital certificate management system according to claim 1, wherein the update order control means is means for performing the control according to an update procedure determined using the update procedure determination method according to any one of claims 1 to 9. Digital certificate management that can be communicated with each node that constitutes a client / server system in which a higher level node follows a lower level node and is configured in multiple stages, and each node authenticates using a digital certificate. A device,
A certification key updating means for updating a certification key for confirming the validity of the digital certificate used by each node for the authentication;
For each node constituting the client / server system, based on the communication partner of the node and information on whether it functions as a client or a server between the communication partner, An update order control means for controlling the update procedure;
In the certification key update means,
Means for obtaining a new certification key for renewal;
Means for obtaining a new digital certificate for use in the authentication, the validity of which can be confirmed using the new certification key;
Transmitting means for transmitting the new digital certificate and / or the new certification key for each node to the corresponding node, respectively.
10. A digital certificate management apparatus, wherein the update order control means is means for performing the control according to an update procedure determined using the update procedure determining method according to any one of claims 1 to 9.

Images