Communication apparatus, communication system, and certificate transmission method and program

<u style="single">The present invention includes a communication device that communicates with a destination device via a network, a higher-level device and a lower-level device, and a communication system in which the higher-level device and the lower-level device communicate with each other via a network, and a partner via a network. The present invention relates to a communication method by a communication device that communicates with a destination device, and a program to be executed by a computer that controls a communication device that communicates with a destination device via a network.</u>

Conventionally, various systems have been constructed by connecting a plurality of communication devices each having a communication function so as to be able to communicate with each other via a network. An example of this is a so-called electronic commerce system in which an order for a product is sent from a computer such as a PC (personal computer) that functions as a client device, and the order is accepted by a server device that can communicate with the order via the Internet. Be done. In addition, a system has been proposed in which various electronic devices are provided with the functions of a client device or a server device and connected via a network to remotely manage the electronic devices by communicating with each other.

In constructing such a system, it is important to confirm whether the communication partner is appropriate or whether the transmitted information has been tampered with when performing communication. Further, especially on the Internet, information often goes through an unrelated computer before reaching the communication partner, so when transmitting confidential information, it is necessary to prevent the contents from being stolen. As a communication protocol that meets such demands, for example, a protocol called SSL (Secure Socket Layer) has been developed and is widely used. By communicating using this protocol, the public key cryptosystem and the common key cryptosystem can be combined to authenticate the communication partner, and falsification and eavesdropping can be prevented by encrypting the information. In addition, the communication partner can also authenticate the device of the communication source that has requested communication. Examples of the technology related to authentication using SSL or public key cryptography include those described in Patent Document 1 and Patent Document 2.<patcit num="1"><text>JP-A-2002-353959</text></patcit><patcit num="2"><text>Japanese Unexamined Patent Publication No. 2002-251492</text></patcit>

Here, the communication procedure when performing mutual authentication according to this SSL will be described focusing on the part of the authentication process. FIG. 22 is a diagram showing a flowchart of a process executed by each device when the communication device A and the communication device B perform mutual authentication according to SSL, together with information used for the process. As shown in FIG. 22, when performing mutual authentication according to SSL, it is first necessary to store the root key certificate and the private key and public key certificate in both communication devices. This private key is a private key issued by a certificate authority (CA) to each device, and the public key certificate is digitally signed by the CA on the public key corresponding to the private key. It is a certificate. The root key certificate is a digital certificate obtained by adding a digital signature to the root key corresponding to the root private key used by the CA for digital signature.

Figure 23 shows these relationships. As shown in Fig. 23 (a), the public key A is the key body for decrypting the document encrypted using the private key A, the CA that is the issuer of the public key, the validity period, etc. It is composed of bibliographic information including information. Then, in order to show that the key body and bibliographic information have not been tampered with, the CA encrypts the hash value obtained by hashing the public key A using the root private key and uses it as a digital signature for the client public key. Attach. At this time, the identification information of the root private key used for the digital signature is added to the bibliographic information of the public key A as the signature key information. The public key certificate with this digital signature is the public key certificate A.

When this public key certificate A is used for the authentication process, the digital signature contained therein is decrypted by using the key body of the root key, which is the public key corresponding to the root private key. If this decryption is successful, you know that the digital signature was indeed attached by the CA. Further, if the hash value obtained by hashing the public key A part and the hash value obtained by decoding match, it can be seen that the key itself has not been damaged or tampered with. Furthermore, if the received data can be normally decrypted using this public key A, it is known that the data was transmitted from the owner of the private key A.

Here, in order to perform authentication, it is necessary to store the root key in advance, and this root key is also used as a root key certificate digitally signed by the CA, as shown in Fig. 23 (b). Remember. This root key certificate is a self-signed format in which the digital signature can be decrypted with the public key included in the certificate. Then, when the root key is used, the digital signature is decrypted using the key body included in the root key certificate, and the root key is compared with the hash value obtained by hash processing. If this matches, it can be confirmed that the root key is not damaged.

The explanation of the flowchart of FIG. 22 is entered. In this figure, the arrow between the two flowcharts indicates the transfer of data, the transmitting side performs the transfer process at the step at the base of the arrow, and the receiving side processes the step at the tip of the arrow when the information is received. Shall be done. If the processing of each step is not completed normally, a response of authentication failure is returned at that point and the processing is interrupted. The same applies when an authentication failure response is received from the other party or when the process times out.

Here, it is assumed that the communication device A requests the communication device B to communicate. When this request is made, the CPU of the communication device A executes the required control program, and the flowchart shown on the left side of FIG. 22 is executed. Starts processing. Then, in step S11, a connection request is transmitted to the communication device B. On the other hand, when the CPU of the communication device B receives this connection request, it executes the required control program to start the processing of the flowchart shown on the right side of FIG. Then, in step S21, the first random number is generated, and this is encrypted using the private key B. Then, in step S22, the encrypted first random number and the public key certificate B are transmitted to the communication device A.

When the communication device A receives this, the validity of the public key certificate B is confirmed by using the root key certificate in step S12. Then, when confirmed, in step S13, the first random number is decrypted using the public key B included in the received public key certificate B. If the decryption is successful here, it can be confirmed that the first random number is certainly received from the issue target of the public key certificate B. Then, in step S14, a second random number and a common key seed are generated separately. The seed of the common key can be created, for example, based on the data exchanged in the communication so far. Then, in step S15, the second random number is encrypted using the private key A, the common key seed is encrypted using the public key B, and these are transmitted to the server device together with the public key certificate A in step S16. The encryption of the common key seed is performed so that the device other than the communication partner does not know the common key seed. Further, in the next step S17, a common key used for encryption of subsequent communication is generated from the common key seed generated in step S14.

On the communication device B side, when the communication device A receives the data transmitted in step S16, the validity of the public key certificate A is confirmed by using the root key certificate in step S23. Then, when confirmed, in step S24, the second random number is decrypted using the public key A included in the received public key certificate A. If the decryption is successful here, it can be confirmed that the second random number is certainly received from the issue target of the public key certificate A. Then, in step S25, the private key B is used to decrypt the common key seed. By the processing up to this point, the seed of the common key is shared between the communication device A side and the communication device B side. The seed of this common key is unknown to devices other than the generated communication device A and the communication device B having the private key B. If the processing up to this point is successful, the communication device B also generates a common key to be used for subsequent communication encryption from the common key seed obtained by decryption in step S26.

Then, when the processing of step S17 on the communication device A side and step S26 on the communication device B side is completed, mutual confirmation of successful authentication and the encryption method used for subsequent communication is performed, and the generated common key is used. The processing related to authentication is terminated assuming that the subsequent communication is performed by the encryption method. In addition, this confirmation shall include a response to the effect that the authentication from the communication device B was successful. Communication is established with each other by the above processing, and thereafter, using the common key generated in step S17 or S26, data can be encrypted by the common key cryptosystem and communication can be performed.

By performing such processing, the communication device A and the communication device B can authenticate each other and safely share the common key, and can establish a route for secure communication. However, in the above-mentioned process, it is not essential to encrypt the second random number with the public key A and send the public key certificate A to the communication device B. In this case, the processing of steps S23 and S24 on the communication device B side becomes unnecessary, and the processing is as shown in FIG. In this way, the communication device B cannot authenticate the communication device A, but this process is sufficient when the communication device A only needs to authenticate the communication device B. In this case, only the root key certificate needs to be stored in the communication device A, and the private key A and the public key certificate A are unnecessary. Further, it is not necessary to store the root key certificate in the communication device B.

By the way, in the above authentication process, the content encrypted with the public key can be decrypted only by the device having the corresponding private key, and the content encrypted with the private key can be decrypted only with the corresponding public key. By utilizing this, the communication partner is a device whose issuance destination is listed in the public key certificate (or the user of the device is a user whose issuance destination is listed in the public key certificate. ) Will be authenticated. In addition, the public key certificate is authenticated by the CA on the premise of the confidentiality of the root private key of the CA, and the CA (provider) guarantees the accuracy of the contents of the public key certificate. You can also see that there is. However, the fact that the communication partner is certainly the same as the device described in the public key certificate can only be judged by relying on the guarantee of the CA that issued the public key certificate. Therefore, the reliability of CA is an important factor in ensuring the security of communication by authentication using public key cryptography.

On the other hand, as a third party institution that issues such a public key certificate, the holder of the private key is confirmed, the public key corresponding to the private key is digitally signed, and the public key certificate is issued. Commercial services provided by, for example, VeriSign and Baltimore. A public key certificate issued by a highly reliable third-party organization whose system for issuing public keys, including private keys, is strictly managed is widely used for authentication. There is also a demand to use a public key certificate issued by a highly reliable third party when performing authentication using a digital certificate.

Furthermore, when using a public key certificate issued by such a third-party institution, the root key for confirming the contents of the digital signature by the major third-party institution is Internet Explorer (registered trademark) or Netscape (registered trademark). Since it is pre-embedded in a general web browser such as (registered trademark), the operator of the web browser has an advantage that it is not necessary to newly obtain and set the root key. In addition, even if the device does not have a root key set in advance, it is easy for the user to agree to the root key setting if it is from a highly reliable third-party organization, and if the root key is obtained and set A device with a public key certificate issued by the same third party has the advantage that it can be authenticated regardless of the vendor of the device itself. Therefore, when it is desired to connect a device manufactured by the company to a device manufactured by another company, it is effective to use a public key certificate issued by a third party organization. In addition, there is a request from the user side of the device to use such a public key certificate.

<p> in this way,<u style="single">Third party organization</u>The public key certificate issued by is excellent in terms of reliability, but in order to maintain its reliability, the validity period is often set relatively short, for example, 1 to 3 years. If it expires, you will need to get a new public key certificate issued. It is also possible that the operator of the communication device cancels the previous contract and concludes a contract with a new third party period. In such a case, there is a problem that the public key certificate conventionally stored in the communication device may not be authenticated by the communication partner.</p><p> Even in such a case, if the operator can easily set a new public key certificate by operating the device when the authentication cannot be received, the operator is authenticated to secure the security. It is not a serious problem because it can be retained. However, other than that on the communication system, it is difficult for the operator to set it due to the user's proficiency level and usage environment, and it is not preferable for the operator to freely set the certificate due to the operation of the device. In the case of a configuration in which a certificate is set remotely from the communication device of the above, there is no means for maintaining security in a state where authentication cannot be performed, and this point becomes a serious problem.</p><p> The present invention solves such a problem and makes a communication partner during communication.<u style="single">Certificate</u>In a communication device that authenticates using a communication device or a communication system configured by using such a communication device, it is possible to easily restore a state in which normal authentication can be performed even if there is an abnormality in authentication while maintaining security. The purpose is to do so.</p>

<p> In order to achieve the above object, the communication device of the present invention<u style="single">In a communication device that communicates with the other party device via a network, it is a certificate of the other party device issued by a public certificate authority received from the other party device when communicating with the other party device. Issued by the first authentication means that authenticates the other party's device using the first certificate and the private certificate authority received from the other party's device when the authentication by the first authentication means fails. When the second authentication means for authenticating the remote device using the second certificate which is the certificate of the remote device and the authentication by the second authentication means are successful, the first It is provided with a transmission means for transmitting the certificate for renewing the certificate of 1 to the destination device.</u></p><p><u style="single">In such a communication device, when the authentication by the second authentication means is successful, the first certificate to be transmitted to the destination device is renewed to the predetermined certificate management device. It is advisable to provide a means for requesting the issuance of a certificate and obtaining a certificate for renewing the first certificate from the certificate management device.</u></p><p><u style="single">Further, another communication device of the present invention is a communication device that communicates with a destination device via a network, and is a first certificate issued by a public certificate authority and a private certificate authority. When communicating with the storage means for storing the second certificate which is the certificate of the communication device issued by the above-mentioned destination device and the above-mentioned destination device, the above-mentioned first certificate is transmitted to the above-mentioned destination device. When the authentication by the destination device using the first transmission means and the first certificate transmitted by the first transmission means fails, the second certificate is sent to the destination device. When the authentication by the destination device using the second transmission means to be transmitted and the second certificate transmitted by the second transmission means is successful, the first proof from the destination device. The certificate for renewing the document is received, and the renewal means for renewing the first certificate stored in the storage means to the received certificate is provided.</u></p><p><u style="single">Further, the communication system of the present invention includes a higher-level device and a lower-level device, and is a communication system in which the higher-level device and the lower-level device communicate with each other via a network. When communicating with the upper device and a storage means for storing the first certificate which is the certificate of the lower device and the second certificate which is the certificate of the lower device issued by the private certificate authority. In the case where the first transmission means for transmitting the first certificate to the higher-level device and the authentication in the higher-level device using the first certificate transmitted by the first transmission means fail. In the case where the second transmission means for transmitting the second certificate to the higher-level device and the authentication in the higher-level device using the second certificate transmitted by the second transmission means are successful. Is provided with an renewal means for receiving a certificate for renewing the first certificate from the higher-level device and updating the first certificate stored in the storage means to the received certificate. , The first authentication means for authenticating the lower device by using the first certificate received from the lower device when communicating with the lower device, and the first authentication. When the authentication by the means fails, the second authentication means that authenticates the lower device using the second certificate received from the lower device and the authentication by the second authentication means succeeds. Is provided with a transmission means for transmitting a certificate for renewing the first certificate to the lower device.</u></p><p><u style="single">In such a communication system, when the upper device is successfully authenticated by the second authentication means, the first certificate to be transmitted to the lower device is sent to the predetermined certificate management device. It is advisable to provide a means for requesting the issuance of a certificate for renewal and obtaining a certificate for renewing the first certificate from the certificate management device.</u></p><p><u style="single">Further, the communication method of the present invention is issued by a public certificate authority received from a communication device that communicates with the other party device via a network when communicating with the other party device. When the first authentication procedure for authenticating the remote device using the first certificate which is the certificate of the remote device and the authentication by the first authentication procedure fail, the remote device According to the second authentication procedure for authenticating the remote device using the second certificate, which is the certificate of the remote device issued by the private certificate authority received from, and the second authentication procedure. When the authentication is successful, the transmission procedure of transmitting the certificate for renewing the first certificate to the destination device is executed.</u></p><p><u style="single">Further, another communication method of the present invention is a communication device that communicates with a remote device via a network, and is private with a first certificate that is a certificate of the communication device issued by a public certificate authority. When communicating with the other party device in a communication device having a storage means for storing a second certificate which is a certificate of the communication device issued by a certificate authority, the first certificate is used. When the first transmission procedure to be transmitted to the destination device and the authentication by the destination device using the first certificate transmitted in the first transmission procedure fail, the second certificate is described above. When the second transmission procedure for transmitting the message to the destination device and the authentication with the destination device using the second certificate transmitted in the second transmission procedure are successful, the destination device The certificate for renewing the first certificate is received from the above, and the renewal procedure for updating the first certificate stored in the storage means to the received certificate is executed.</u></p><p><u style="single">Further, the program of the present invention receives a computer that controls a communication device that communicates with the other party device via a network from the other party device when communicating with the other party device, by a public certificate authority. When the first authentication means for authenticating the other party device using the first certificate which is the issued certificate of the other party device and the authentication by the first authentication means fail, the above The second authentication means for authenticating the other party's device using the second certificate, which is the certificate of the other party's device issued by the private certificate authority, received from the other party's device, and the second authentication means. It is a program for functioning as a transmission means for transmitting a certificate for renewing the first certificate to the destination device when the authentication by the authentication means is successful.</u></p><p><u style="single">Further, another program of the present invention is a communication device that communicates with a remote device via a network, and is a first certificate and a private certificate issued by a public certificate authority, which are certificates of the communication device. The first proof when a computer controlling a communication device having a storage means for storing a second certificate which is a certificate of the communication device issued by a station communicates with the other party device. When the first transmission means for transmitting the document to the destination device and the authentication with the destination device using the first certificate transmitted by the first transmission means fail, the second When the second transmission means for transmitting the certificate of the above to the destination device and the authentication with the destination device using the second certificate transmitted by the second transmission means are successful, the above To receive a certificate for renewing the first certificate from the remote device and to function as an renewal means for updating the first certificate stored in the storage means to the received certificate. program.</u></p>

<p> The communication device, communication system, or communication device of the present invention as described above.<u style="single">Communication method</u>According to the communication partner<u style="single">Certificate</u>In a communication device that authenticates using a communication device or a communication system configured by using such a communication device, it is possible to easily restore a state in which normal authentication can be performed even if there is an abnormality in authentication while maintaining security. Can be done. Further, according to the program of the present invention, the computer can be made to function as the above-mentioned communication device to realize its features, and the same effect can be obtained.</p>

Hereinafter, preferred embodiments of the present invention will be described with reference to the drawings. First, the configuration of the communication device according to the present invention and the first embodiment of the communication system of the present invention configured by using the communication device will be described. In this embodiment, a communication system is configured by the higher-level device 30 and the lower-level device 40, which are communication devices, respectively, and the higher-level device 30 and the certificate management device 20 are made communicable via a network to form a communication system and the communication system. A digital certificate management system is configured by a certificate management device. FIG. 1 shows a functional block diagram showing the functional configurations of the upper device and the lower device, and FIG. 2 shows the functional configurations of the parts related to the features of this embodiment of the certificate management device. In these figures, illustration of parts not related to the features of this embodiment is omitted. In this specification, the digital certificate refers to digital data with a signature to prevent forgery.

In this communication system, when the upper device 30 tries to communicate with the lower device 40, the upper device 30 communicates with the lower device 40 as a legitimate communication partner by an authentication process according to the SSL protocol, which is an authentication method using public key cryptography and a digital certificate. When authenticated as, communication is established with the lower device 40. Then, in response to the request transmitted by the higher-level device 30, the lower-level device 40 performs necessary processing and returns a response, thereby functioning as a client-server system. On the contrary, when the lower device 40 tries to communicate with the upper device 30, when the upper device 30 is authenticated as a legitimate communication partner by the authentication process according to SSL, the communication with the upper device 30 is also performed. I am trying to establish. Then, the higher-level device 30 performs necessary processing and returns a response to the request transmitted by the lower-level device 40, thereby functioning as a client-server system. In both cases, it is assumed that the side requesting communication functions as a client and the side requesting communication functions as a server.

The certificate management device 20 is a device that issues and manages the digital certificate used for the above-mentioned mutual authentication, and corresponds to a CA. Although only one lower device 40 is shown in FIGS. 1 and 2, a plurality of lower devices 40 can be provided as shown in FIG. 21.

In such a communication system, each node of the certificate management device 20, the upper device 30, and the lower device 40, including the communication between the upper device 30 and the lower device 40 described above, is subjected to RPC (remote procedure call). It is possible to send a "request" that is a processing request for a method of an application program to be implemented by each other and obtain a "response" that is the result of this requested processing. In order to realize this 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. Known protocols (communication standards), technologies, specifications, etc. can be used.

Next, the configuration and functions of each device constituting this communication system will be described in more detail. FIG. 3 is a block diagram showing the hardware configuration of the certificate management device 20 shown in FIG. As shown in this figure, the certificate management device 20 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 device 20 by executing various control programs stored in the ROM 12 and the HDD 14, and realizes functions such as creation and management of a digital certificate. As the hardware of the certificate management device 20, a known computer can be appropriately adopted. Of course, other hardware may be added if necessary.

The upper device 30 and the lower device 40 can be configured in various ways depending on the purpose of remote control of the device, electronic commerce, and the like. For example, in the case of remote management, image processing devices such as printers, fax devices, copiers, scanners, and digital multifunction devices, network home appliances, vending machines, medical devices, power supplies, air conditioning systems, gas / water / Electronic devices such as electric weighing systems, automobiles, and aircraft are designated as lower-level devices 40 that are managed devices, and management devices for collecting information from these managed devices and sending commands to operate them are higher-level devices. It is conceivable to use device 30.

However, the upper device 30 and the lower device 40 each include at least a communication I / F for communicating with an external device via a CPU, ROM, RAM, and a network, and a storage means for storing information necessary for authentication processing. By executing the required control program stored in the ROM or the like by the CPU, the apparatus can realize each function related to the features of this embodiment. For this communication, various communication lines (communication paths) capable of constructing a network can be adopted regardless of whether they are wired or wireless. The same applies to communication with the certificate management device 20.

As described above, FIG. 1 shows the functional configurations of the upper device 30 and the lower device 40, which are characteristic parts of this embodiment. First, the host device 30 includes an HTTPS (Hypertext Transfer Protocol Security) client function unit 31, an HTTPS server function unit 32, an authentication processing unit 33, a certificate update request unit 34, and a certificate storage unit 35. The HTTPS client function unit 31 requests communication from a device having an HTTPS server function such as a lower device 40 using an HTTPS protocol including authentication and encryption processing according to SSL, and also to a communication partner. It has a function to send a request (command) or data and execute an operation according to it.

On the other hand, the HTTPS server function unit 32 receives a communication request using the HTTPS protocol from a device having an HTTPS client function, receives the request or data from the device, and causes each part of the device to execute an operation corresponding to the request or data. It has a function to return the result as a response to the requester. The authentication processing unit 33 includes digital certificates received from the communication partner when the HTTPS client function unit 31 and the HTTPS server function unit 32 authenticate the communication partner, and various certificates stored in the certificate storage unit 35. It has the function of an authentication means that performs authentication processing using a private key or the like. It also has a function of transmitting a digital certificate stored in the certificate storage unit 35 to the communication partner via the HTTPS client function unit 31 and the HTTPS server function unit 32 in order to request authentication from the communication partner. Further, as will be described later, it also has a function of an abnormality detecting means for determining that there is an abnormality in authentication using a normal public key certificate in a predetermined case.

As will be described later, the certificate renewal request unit 34 is a certificate transmission means for transmitting a normal public key certificate to a communication partner such as a lower device 40 in a predetermined case, and a certificate requesting that the certificate be stored. It has the function of an update means. The certificate storage unit 35 has a function of storing authentication information such as various certificates and private keys and using the authentication processing unit 33 for authentication processing. The types of these various certificates and private keys, their uses, and their creation methods will be described in detail later. Then, the functions of each of these parts are realized by the CPU of the higher-level device 30 executing a required control program to control the operation of each part of the higher-level device 30.

Next, the lower device 40 includes an HTTPS client function unit 41, an HTTPS server function unit 42, an authentication processing unit 43, a request management unit 44, a certificate storage unit 45, a status notification unit 46, a log notification unit 47, and a certificate update. It has a unit 48 and a command receiving unit 49. Similar to the HTTPS client function unit 31 of the host device 30, the HTTPS client function section 41 uses the HTTPS protocol to request communication from a device having an HTTPS server function such as the host device 30, and also to request transmission. It has a function to execute an operation according to data or the like.

The HTTPS server function unit 42 is also the same as the HTTPS server function unit 32 of the host device 30, receives a communication request from a device having an HTTPS client function, and executes an operation according to the received request and data to each part of the device. It has a function to make the requester return a response to the requester. The function of the authentication processing unit 43 is the same as that of the authentication processing unit 33 of the host device 30, but the certificate or the like used for the authentication processing is stored in the certificate storage unit 45. The request management unit 44 has a function of determining whether or not to execute an operation based on the request received from the host device. Then, when the execution is permitted, it also has a function of transmitting an operation request to the function units 46 to 49 that execute the operation based on the request.

FIG. 4 shows the judgment criteria for whether or not this execution is possible. The judgment criteria are the type of request and the type of digital certificate used for the authentication processing in the authentication processing unit 43. The digital certificate stored in the upper device 30 and the lower device 40 is a first certificate and a public certificate issued by the public certification authority, which is the first certification authority, although details will be described later. There is a normal public key certificate and a rescue public key certificate which is a second certificate and a private certificate issued by a private certification authority which is a second certification authority. As shown, normally all operations are permitted when authentication is performed using a public key certificate, but only certificate renewal operations are permitted when authentication is performed using a rescue public key certificate. There is. Here, the certificate to be renewed is usually only the public key certificate, and the rescue public key certificate is not renewed. Therefore, the rescue public key certificate is a certificate used only when the lower device 40 stores a new normal public key certificate (and a private key or root key certificate to be stored accompanying the private key certificate). Become.

The certificate storage unit 45 stores authentication information such as various certificates and private keys in the same manner as the certificate storage unit 35 of the host device, and is an authentication processing unit.<u style="single">43</u>It has the function of a certificate storage means to be used for the authentication process in. However, the stored certificate or the like is different from the certificate storage unit 35 as described later. The status notification unit 46 has a function of making a call to notify the upper device 30 of the state of the lower device 40 when an abnormality is detected or an instruction is given by the user. This notification may be transmitted as a response to an inquiry from the host device 30, or may be sent by requesting communication from the HTTPS client function unit 41 to the host device.

The log notification unit 47 has a function of notifying the log from the lower device 40 to the higher device 30. As the content of the notification, in addition to the operation log of the lower device 40, for example, the count value of the image forming number counter in the case of the image forming device, the measuring value thereof in the case of the measuring system, and the like can be considered. Since this notification is not urgent, it may be sent as a response to an inquiry from the host device 30. The certificate renewal unit 48 has a function of renewing the certificate or the like stored in the certificate storage unit 45 by the certificate or the like received from the host device 30. The command receiving unit 49 has a function of executing an operation corresponding to a request related to a function other than the above-mentioned functional units 46 to 48. Examples of this operation include transmission of data stored in the lower device 40 and control of the operation of the engine unit (not shown) as needed. The functions of each of these parts are realized by the CPU of the lower device 40 executing a required control program to control the operation of each part of the lower device 40. The status notification unit 46 and the log notification unit 47 are shown as specific examples of the functions provided by the command reception unit 49, and it is not essential to provide such functions.

Further, as described above, FIG. 2 shows the functional configuration of the characteristic portion of the certificate management device 20 according to this embodiment. As shown in this figure, the certificate management device 20 includes an HTTPS server function unit 21, an authentication processing unit 22, a certificate renewal unit 23, a certificate key creation unit 24, a certificate issuing unit 25, and a certificate management unit 26. I have. Like the HTTPS server function unit of the upper device 30 and the lower device 40, the HTTPS server function unit 21 receives a communication request from a device having an HTTPS client function, and performs an operation according to the received request and data to each unit of the device. It has a function to execute and return a response to the requester.

The function of the authentication processing unit 22 is the same as that of the authentication processing unit of the upper device 30 and the lower device 40, but the certificate or the like used for the authentication processing is stored in the certificate management unit 26. The types, uses and functions will be described later. When the higher-level device 30 requests the normal certificate issuance, the certificate renewal unit 23 issues a new normal public key certificate of the target lower-level device 40 to the certification key creation unit 24 and the certificate issuing unit 25. It has a function of transmitting this from the certificate management unit 26 to the host device 30 via the HTTPS server function unit 21.

The proof key creation unit 24 includes a root private key, which is a proof private key used for creating a digital signature, and a root private key and a corresponding proof public key (certification) for confirming the validity of the digital certificate. It has the function of a key creation means for proof that creates a root key that is a key). The certificate issuing unit 25 has a function of issuing a public key used for authentication processing according to the SSL protocol and a corresponding private key to the certificate management device 20 itself, the upper device 30 and the lower device 40. Furthermore, the function of the certificate issuing means for issuing the public key certificate, which is a digital certificate, is added by digitally signing each issued public key using the root private key created by the certification key creation unit 24. Have. Issuing a root key certificate with a digital signature attached to the root key is also a function of this certificate issuing unit 25.

The certificate management unit 26 has a function of a certificate management means for managing a digital certificate issued by the certificate issuing unit 25, a root private key used for creating the digital certificate, and a root key corresponding to the root private key. Then, these certificates and keys are stored together with information such as the expiration date, the issue destination, the ID, and the presence / absence of renewal. In addition, the certificate and private key issued to itself also have a function to be used for authentication processing in the authentication processing unit 22. The functions of each of these parts are realized by the CPU of the certificate management device 20 executing a required control program to control the operation of each part of the certificate management device 20.

Next, the characteristics and uses of each certificate and key used by each of the above-mentioned devices for the authentication process will be described. FIG. 5 shows the types of certificates and keys stored in the certificate storage unit 45 of the lower device 40 in (a), and the proof stored in the certificate storage unit 35 of the upper device 30 in (b). It is a figure which shows the type of a calligraphy and a key. Further, FIG. 6 is a diagram showing the certificates and keys stored in the certificate management unit 26 of the certificate management device 20 that are used for the authentication process in the certificate management device 20. The upper device 30, the lower device 40, and the certificate management device 20 are roughly divided into formal authentication information and rescue authentication information. Then, these regular authentication information and rescue authentication information are composed of a public key certificate and a private key, which are authentication information about oneself, and a root key certificate, which is authentication information about a communication partner, respectively. Then, each device performs mutual authentication of the procedure as shown in FIG. 22 or one-way authentication as shown in FIG. 24 according to SSL by using the regular authentication information during normal communication.

Further, for example, the normal public key certificate for the lower device is a digital signature that can confirm the validity of the normal public key issued by the certificate management device 20 to the lower device 40 by using the normal root key for authentication of the lower device. It is a digital certificate with a mark and corresponds to a public certificate. Here, it is assumed that the certificate management device 20 corresponds to a public certificate authority or a device used by a public certificate authority for issuing and managing certificates. In addition, a public certificate authority is a certificate authority that is widely recognized as reliable, such as the third-party organization explained in the background technology section, or a certificate authority that is publicly recognized as reliable, legally. It shall refer to a certificate authority that can issue a certificate that is generally accepted, such as a certificate authority whose validity of the certificate is recognized. A public certificate authority is a certificate authority operated by an operator different from the certificate user.

Here, as the format of the public key certificate, for example, the one shown in FIG. 7 can be used, and in addition to the public key itself, the issuer of the certificate, the expiration date of the certificate, and the object to be certified (of the certificate). Information such as the issuing device or user) is described. Specifically, it can be created according to a format called X.509, for example, and the public key certificate created according to this format is as shown in FIG. 8, for example. In this example, A indicates the identification information of the CA, and C indicates the identification information of the device to which the certificate is issued. Each of these includes information such as location, name, machine number or code. In addition, B indicates the validity period, and the validity period is specified by the start date and time and the end date and time.

Further, the normal private key for the lower device uses the private key corresponding to the above-mentioned normal public key, and the normal root key certificate for lower device authentication uses the root private key corresponding to itself for the normal root key for lower device authentication. It is a digital certificate with a digital signature that can be verified by itself. Even if a plurality of lower-level devices 40 are provided, the digital signature attached to the ordinary public key of each device is attached using the same root private key, and the ordinary root key certificate required for validity confirmation is shared. However, the normal public key included in the normal public key certificate and the corresponding private key are different for each device. The same relationship applies to the normal public key certificate for higher-level devices, the normal private key for higher-level devices, and the normal root key certificate for higher-level device authentication. The root key certificate has a similar relationship. It is also conceivable to store the root key certificate corresponding to each public certificate authority in each device so that the validity of the public key certificate issued by multiple public certificate authorities can be confirmed. Be done.

Then, for example, when the upper device 30 and the lower device 40 perform mutual authentication, the lower device 40 is the first encrypted using the normal private key for the lower device in response to the communication request from the upper device 30. A random number is sent to the upper device 30 together with the normal public key certificate for the lower device. On the upper device 30 side, first confirm the validity (not damaged or tampered with) of this lower device normal public key certificate using the lower device authentication normal root key certificate, and if this can be confirmed, Decrypt the first random number with the public key included here. If this decryption is successful, the higher-level device 30 can recognize that the lower-level device 40 of the communication partner is certainly the issuer of the normal public key certificate for the lower-level device, and the device is selected from the identification information contained in the certificate. Can be identified. Then, the success or failure of the authentication can be determined depending on whether or not the specified device is suitable as a communication partner.

In addition, the lower device 40 also receives and stores the normal public key certificate for the higher device and the random number encrypted with the normal private key for the higher device, which are sent when the authentication is successful on the higher device 30 side. Similar authentication can be performed using the root key certificate for higher-level device authentication. Note that this procedure is a process when the higher-level device 30 requests communication from the HTTPS server function unit 42 of the lower-level device 40 by the HTTPS client function unit 31, and the lower-level device 40 is the process when the lower-level device 40 requests communication from the HTTPS server function unit 42 of the lower-level device 40. When requesting communication from the HTTPS server function unit 32 of the above, the certificate and key used are the same, but the processing of the upper device 30 and the lower device 40 is reversed. The same applies to the processing when the host device 30 and the certificate management device 20 communicate with each other.

By the way, as already mentioned, when each device receives a normal public key certificate from the communication partner, the root key (certificate) for confirming the validity of the public key certificate issued by the certificate authority of the issuer. ) Is not remembered, the validity of the received public key certificate cannot be confirmed. Therefore, in this case, authentication cannot be performed. In addition, if each device does not have a function (module for realizing encryption / decryption, etc.) for authenticating with the ordinary public key certificate received from the communication partner, the ordinary public key is of course the same. It is not possible to authenticate with a certificate. When the certificate used for the authentication process is switched in the upper device 30, or the lower device 40 is connected to a communication system including the upper device 30 which uses a certificate of a certificate authority different from the previous one, such a case occurs. It is possible that a situation may occur. This is because the operator of the communication system appropriately determines which public certificate authority corresponds to the certificate issued in consideration of various conditions.

Here, if each device can only perform authentication using a normal public key certificate (authentication using normal authentication information), the validity of the certificate cannot be confirmed in this way, or authentication processing is supported. In the absence, even if you try to set a usable normal public key certificate, normal private key, normal root key certificate, etc., there is no way to securely send them to the target device via the network. Become. Also, if the power of the device is turned off and the certificate cannot be automatically renewed and the certificate expires, or if the power is turned off during the renewal process and the certificate is damaged. In addition, authentication cannot be performed, but a similar problem occurs in such a case.

However, each communication device constituting the communication system of this embodiment stores rescue authentication information in order to deal with such a situation, and authenticates the communication partner using two different types of digital certificates. I am trying to do it. Then, by using the rescue authentication information, a new ordinary public key certificate or the like can be safely transmitted to the necessary device via the network.

This rescue authentication information has almost the same structure as the regular authentication information. For example, the rescue public key certificate for the lower device is the rescue public key issued by the certificate management device 20 to the lower device, and the lower device. It is a digital certificate with a digital signature that can be verified using the rescue root key for authentication, and corresponds to a private certificate. In addition, the rescue private key for the lower device is the private key corresponding to the rescue public key, and the rescue root key certificate for lower device authentication is a digital signature that can be used to confirm the validity of the rescue root key for lower device authentication. It is a digital certificate with.

However, the major difference from the regular authentication information is that the rescue public key certificate is a public key certificate issued by a private certificate authority. A private certificate authority is a certificate authority that is not widely recognized for its reliability and that the certificate issued is not generally accepted. For example, it is a certificate authority operated by a certificate user, and a certificate authority operated by the company to manage the certificates used in the company. Certificates issued by such certificate authorities are usually considered to be less reliable than certificates issued by public certificate authorities, but private certificate authorities are designed by the installer for security and convenience. Since it can be operated according to its own policy, it also has the advantage that it is easy to issue a certificate suitable for the purpose. Moreover, even a private certificate authority can provide a certificate with relatively high security if security is taken into consideration.

Here, FIG. 9 shows an example of the normal public key certificate of the lower device 40, and FIG. 10 shows an example of the rescue public key certificate of the lower device 40. These are public key certificates that have the same identification information of the issuing device and are issued to the same device, as indicated by reference numerals F and I. However, the issuer of the certificate usually uses YYY's "Public CA" as shown by the code D for the public key certificate, while XXX's "Private CA" as shown by the code G for the rescue public key certificate. It is a different CA. "Public CA" corresponds to a public certificate authority, and "Private CA" corresponds to a private certificate authority. Also, here, the private certificate authority is set up by XXX, which is the manufacturer of the issuing device. Then, the rescue authentication information including such a rescue public key certificate is prepared, and the content of the rescue authentication information is the lower device 40 even if the export regulation and the content of the authentication process widely used in each region are taken into consideration. It is preferable that authentication can be performed by an authentication process that can be commonly used in various environments where is expected to be used.

In this way, it is possible to authenticate the communication partner with the rescue public key certificate even in an environment where authentication using the public key certificate cannot normally be performed. Then, if such authentication is successful, a secure communication path using the common key cryptography can be provided by sharing the common key with the communication partner as described above. Therefore, using this communication path, it is possible to send a new public key certificate suitable for the environment at the time of communication to the communication partner and set it. In addition, since public key certificates issued by public certificate authorities require strict management and security, it may be difficult to issue certificates that can be used in common in various environments as described above. Yes, it costs money. However, if it is a private certificate authority, the specifications of the certificate can be set relatively freely, so it is common in various environments by lowering the encryption strength and avoiding the latest and less popular authentication processing algorithms. It is also possible to issue a certificate that can be used for. In addition, if the device manufacturer itself provides a private certificate authority, it is possible to issue a certificate at low cost. Furthermore, for example, even if the manufacturer of the lower device 40 and the upper device 30 are different, or the operator of the communication system makes various customizations, the rescue public key certificate is provided free of charge. It will also be easier to encourage manufacturers and operators to support authentication using rescue public key certificates.

The rescue public key certificate issued by the private certificate authority may be inferior in security and reliability to the ordinary public key certificate issued by the public certificate authority. However, if the authentication process is performed using the rescue authentication information and only limited requests such as the update of the regular authentication information such as the normal public key certificate are allowed to be executed, this point can be achieved. It's not a big problem.

Here, returning to the explanation of FIGS. 9 and 10, in these two public key certificates, the validity period of the normal public key certificate is as shown by the symbol E from midnight on January 1, 2003. While it is one year until midnight on January 1, 2004, in the rescue public key certificate, from midnight on January 1, 2000 to midnight on January 1, 2050, as indicated by the sign H. It is said to be 50 years. That is, since the public key certificate is usually issued by a public certificate authority, the manufacturer or user of the device cannot freely set the validity period, and the validity period is set short in consideration of safety. It is usually done. Therefore, it is necessary to renew the certificate within the validity period. In a device that needs to automatically renew the certificate, as described above, there is a risk of the certificate being damaged due to the renewal deadline being exceeded or an abnormality at the time of renewal.

On the other hand, if the rescue authentication information is positioned as the authentication information for securing an emergency communication path when the normal public key certificate cannot be used for authentication, after the validity period of the rescue public key certificate has elapsed, Usually, when the validity period of the public key certificate has expired, it is no longer possible to authenticate with the public key certificate. Therefore, it is preferable that the rescue public key certificate has a long validity period. In addition, if renewal is required, there is a risk that the deadline will be overdue or damaged, so it is preferable that renewal is not necessary.

Specifically, for example, it is preferable to set an effective period longer than the product life of the storage device. This product life is an assumed operating period or an estimated operating period of the device, and can be determined from the expected usage period, the estimated useful life, the quality assurance period of the device, and the like at the time of development. Also, if the validity period of the rescue public key certificate is set longer than the period expected to be able to operate normally while maintaining the device, the rescue public key certificate will expire during the operation of the device. It can be said that there is no certificate. Therefore, during the operation of the device, it is possible to maintain a state in which authentication using the rescue public key certificate (authentication using the rescue authentication information) is always possible. Moreover, since it is not necessary to renew the rescue public key certificate, it is possible to prevent damage during renewal.

Further, it is even better if the effective period is set to be extremely longer than the above-mentioned product life and the operating period of the device. In the example shown in Figure 10, the validity period is set to 50 years, which is considered sufficient for a normal device, but this means that the maximum validity period that can be set according to the X.509 format is 50 years. Therefore, it goes without saying that a longer period, for example, 100 years or several hundred years, may be set just by doing this. When the validity period is set in this way, the end of the validity period is simply stated by the format request of the public key certificate, and it can be considered that the rescue public key certificate has virtually no expiration date. it can. In addition, depending on the target device, it may be possible to think in the same way even if the validity period is about 20 years, 30 years or less. Furthermore, even if the validity period of the rescue public key certificate is shorter than the product life, if it is longer than the validity period of the normal public key certificate, the rescue public will be released for a certain period after the validity period of the normal public key certificate has elapsed. It is possible to obtain the effect of being able to maintain a state in which authentication using a key certificate is possible.

Then, in the rescue public key certificate issued by the private certificate authority, the validity period may be set appropriately by the issuer, so that it is possible to set the validity period so as to meet these requests. In addition, although the public key certificate with a long validity period is slightly inferior in security to the public key certificate with a short validity period, as described above, the rescue public key certificate was used for authentication. This can be avoided by limiting the actions that are allowed to be performed in some cases. In addition, if an emergency communication path can be secured with such a rescue public key certificate, even if a normal certificate with a short validity period is used, it will be inconvenient due to expiration or damage at the time of renewal. Even for devices that are difficult to manually renew and have to rely on automatic renewal, the certificate issued by a highly reliable public certificate authority is valid. It can be utilized.

As described above, if the rescue public key certificate is stored in each communication device that can configure the communication system, authentication using the normal public key certificate cannot be performed normally (failed). In addition, by attempting authentication using the rescue public key certificate for the same communication partner, it is possible to determine whether or not there is an abnormality in the authentication using the normal public key certificate. In other words, if the authentication using the rescue public key certificate is successful, it is known that the device is supposed to be the communication partner, so the reason why the authentication could not be performed normally is that the public key certificate is usually used. It can be judged that the authentication used is abnormal.

Also, if the authentication using the rescue public key certificate fails, it is known that the other party is a device that is not supposed to be the communication partner, so the reason why the authentication using the normal public key certificate could not be performed normally is. It can be determined that the authentication has not occurred because the communication partner was inappropriate. One of the features of this embodiment is that such a judgment is made by using two types of digital certificates, a normal public key certificate and a rescue public key certificate. It should be noted that the cause of the authentication failure may be a communication failure, but in this case, since an abnormality is found at the stage of receiving the certificate, etc., distinguish it from the case where the content of the certificate, etc. is inappropriate. Can be done.

By the way, when performing authentication processing according to the SSL protocol, the server cannot know the status of the client when the client requests communication, so it is inevitably assigned to a specific URL (Uniform Resource Locator). It will always return the same public key certificate when accessed. Therefore, basically, one device has a plurality of public key certificates, and the communication partner selects and sends an appropriate one according to the type of public key certificate to be used for authentication. It is not possible. However, in each of the devices shown in FIGS. 1 and 2, a special configuration is adopted so that the normal public key certificate and the rescue public key certificate can be used properly depending on the case.

Therefore, next, the configuration for proper use will be described with reference to FIG. Although FIG. 11 shows only the upper device 30 and the lower device 40, the same configuration can be applied to the certificate management device 20. As mentioned above, the server can basically only return a specific public key certificate to the client requesting communication. However, if the address that accepts the communication request is different, it is possible to return a different public key certificate for each address. This address can be determined, for example, by a URL.

Therefore, here, as shown in FIG. 11, the upper device 30 and the lower device 40 are provided with a normal URL for authentication using the normal public key certificate and a rescue URL for authentication using the rescue public key certificate, respectively, for communication. The side that requests (the side that functions as a client) selectively specifies one of the URLs according to the type of authentication requested and sends the communication request. By changing the IP address and port number (either one of them is acceptable), these URLs can be treated as URLs of logically different devices even if they are physically the same device URL. ing. That is, it is for realizing the function of a so-called virtual server.

In this case, the side requesting communication (the side that functions as a server) distinguishes the certificate to be returned by the URL that received the communication request, and returns the normal public key certificate if it is accepted by the normal URL. , Rescue public key certificate can be returned when accepted by rescue URL. In addition, since the client requesting communication knows to which URL the communication request was sent, when performing mutual authentication, it is possible to select and send an appropriate public key certificate according to that URL. it can.

Then, when the upper device 30 tries to authenticate the lower device 40, it first sends a communication request to the normal URL and tries to authenticate using the normal public key certificate, but if this fails, this time rescue. A communication request is sent to the URL to perform authentication using the rescue public key certificate. Then, if this is successful, the certificate set for renewal is obtained from the certificate management device 20 and sent to the lower device 40 to request that it be stored. Even in the case of authentication using the rescue public key certificate, sharing of the common key is possible in the same way as in the case of the normal public key certificate, so the transmission of the certificate set is encrypted using the shared common key. It can be done safely.

The configuration of this certificate set is shown in FIG. Of these, the root private key used to create the lower-level device normal public key certificate corresponds to the root key included in the lower-level device authentication normal root key certificate stored in the higher-level device 30 at the time of acquisition. The normal root key certificate for higher-level device authentication includes a root key that can confirm the validity of the digital signature attached to the higher-level device normal public key certificate that is also stored in the higher-level device 30. It's a crap. Therefore, even if the lower device 40 stores a normal public key certificate issued by a CA different from the CA supported by the higher device 30, the higher device 30 supports the certificate set for renewal. It will include the normal public key certificate for lower-level devices and the normal root key certificate for higher-level device authentication issued by the CA. The public key body in the normal public key certificate for the lower device and the normal private key for the lower device are not only newly generated, but also issued to the lower device 40 in the past by the certificate management device 20. If you manage the key, you can use the key as it is. In addition, when issuing a certificate set for renewal, a new root private key is issued, and the version of the public key certificate is upgraded (the public key is digitally signed using the new root private key). It is also possible to issue a certificate).

On the other hand, when the lower device 40 receives a request to store the above certificate, the received certificate set is stored in the certificate storage unit 45 by the certificate renewal unit 48, and the previous regular authentication information is stored in the certificate storage unit 45. I try to update it. If this update is performed normally, the lower device 40 will store the normal public key certificate within the valid period again, and the authentication using the normal public key certificate can be performed. Therefore, after that, the communication may be executed by performing the authentication using the normal public key certificate.

In the authentication information shown in FIGS. 5 and 6, the same root key certificate may be used regardless of the authentication target (for example, the normal root key certificate for higher-level device authentication and the normal root key certificate for lower-level device authentication). The root key certificate may be the same). This is because the public key certificate has the identification information of the device, so if the validity can be confirmed using the root key certificate, then the model and machine number of the device can be determined by referring to the identification information. This is because it can be identified.

Next, processing related to abnormality detection and certificate renewal using these two types of certificates, the normal public key certificate and the rescue public key certificate, will be described. The flowchart of FIG. 13 shows the processing on the upper device 30 side, and the flowchart of FIG. 14 shows the processing on the lower device 40 side. These processes are performed by the CPUs of the higher-level device 30 and the lower-level device 40 by executing the required control programs, respectively, and are the processes according to the embodiment of the abnormality detection method and the certificate transmission method of the present invention. In these flowcharts, the processing when the higher-level device 30 requests communication from the lower-level device 40 is shown. Further, for the sake of simplicity, only the part where the upper device 30 authenticates the lower device 40 using the public key certificate received from the lower device 40 is shown as the authentication process (as shown in FIG. 24). The process for one-way authentication is shown), but the public key certificate may be sent from the upper device 30 to the lower device 40 to perform two-way authentication as shown in FIG. Of course.

When the higher-level device 30 sends a request or notification to the lower-level device 40 or makes a communication request to receive the request or notification from the lower-level device 40, the higher-level device 30 starts the process shown in the flowchart of FIG. First, in step S101, a communication request is sent to the normal URL of the lower device 40. It is assumed that the host device 30 stores a normal URL and a rescue URL as communication request destinations for all devices that are communication partners.

Then, when the lower device 40 receives the communication request, it starts the process shown in the flowchart of FIG. 14, and determines in step S201 whether the URL for which the communication request has been made is a normal URL or a rescue URL. Then, if it is a communication request to the normal URL, the process proceeds to step S202 to determine whether or not the normal normal public key certificate is stored. Normally, as shown in Fig. 5 (a), the normal public key certificate (normal public key certificate for lower-level devices) should be stored, but it was accidentally erased or damaged during renewal. In some cases, this judgment may be NO if the public key certificate is not normally stored at the time of product shipment. Even if the validity period has expired, the judgment in step S202 may be YES as long as the public key certificate that is formally normal is stored.

Then, if it is stored in step S202, the normal public key certificate is transmitted to the upper device 30 together with the first random number encrypted with the normal private key (normal private key for the lower device) in step S203. This process corresponds to the process of steps S21 and S22 of FIG. 22 or FIG. If it is not stored in step S202, the process ends with a response that the normal public key certificate cannot be sent in step S211.

The host device 30 receives any of these responses, or after a predetermined time elapses, proceeds to step S102 to determine whether the host device 40 has transmitted the public key certificate. Then, if it has been transmitted, the process proceeds to step S103 to perform the authentication process. For the authentication here, the normal root key certificate for subordinate device authentication is used, and this process corresponds to the process of steps S12 and S13 of FIG. 22 or FIG. 24. Further, in the processing of steps S101 to S103, the CPU of the host device 30 functions as the first authentication means. Then, it is determined in step S104 whether or not the authentication is successful, and if it is successful, the process proceeds to step S113 to send the seed of the common key to the lower device 40 and create the common key to be used for the subsequent communication. To. This process corresponds to the process of steps S14 to S17 of FIG. 22 or FIG. 24.

On the lower device 40 side, if the normal public key certificate is transmitted in step S203, the transmission is waited in step S204, and if the common key seed is received, it is determined that the higher device 30 has authenticated, and step S205. Proceed to to create a common key and use it for subsequent communication. These processes correspond to the processes of steps S23 to S26 of FIG. 22 or steps S25 and S26 of FIG. 24. Further, on the upper device 30 side, after step S113, a request (command) is transmitted to the lower device 40 together with necessary data in step S114, and the response is waited in step S115. Then, it is determined in step S116 whether or not all the requests have been transmitted, and if it still remains, the process returns to step S114 and the process is repeated. If all the requests have been transmitted, the process proceeds to step S117 to disconnect the communication and end the process. ..

On the lower device 40 side, after step S205, the process proceeds to step S206 to determine whether or not a request has been received from the higher device 30, and if so, the higher device 30 performs processing according to the request in step S207. Returns a response. Further, in step S208, it is determined whether or not there is information to be notified to the higher-level device 30 such as a call or periodic notification, and if so, the notification is transmitted in step S209. Then, in step S210, it is determined whether or not the host device 30 has disconnected the communication, and if it is not disconnected, the process returns to step S206 to repeat the process, but if it is disconnected, the process ends.

On the other hand, when the authentication fails in step S104 in the processing on the upper device 30 side, the cause of the authentication failure is that the CA that issued the public key certificate did not match the root key certificate and the validity could not be confirmed. The public key certificate version did not match the root key certificate and its validity could not be confirmed, the public key certificate had expired, the public key certificate was damaged, and the device had nothing to do with it in the first place. It is probable that the identification information attached to the public key certificate that was trying to communicate was that of an inappropriate device as the communication partner. Then, in the next step S105, it is determined whether or not the cause is that the identification information attached to the public key certificate is that of an inappropriate device as a communication partner, and if this determination is YES, the process is performed. finish. It may be better to end the process at this point for other reasons as well. For example, if there is no response to the communication request in step S101, or if a response indicating that the authentication process is not supported is returned, the communication partner may be a device that has nothing to do with the host device 30. Therefore, in such a case, the process may be terminated at the time of step S105.

The process after step S106 is a process of grasping the cause when authentication using a public key certificate cannot be performed normally and storing an appropriate digital certificate in the communication partner when necessary. If the cause of the authentication failure in step S104 is that the identification information is inappropriate, it is clear that the certificate and authentication process were normal, so there is no need to reconfirm. This is because the situation does not improve even if the certificate is renewed, and it is not necessary to perform the processing after step S106. In this case, it is advisable not to request communication from the URL to which the communication request was sent in step S101.

On the other hand, if the judgment in step S105 is NO, it is considered that the authentication process could not be performed normally because the public key certificate was not appropriate. Perform processing. The same applies when the lower device 40 does not send the public key certificate in step S102. In step S106, since it is known that communication with a normal URL is not possible, a communication request is sent to the rescue URL of the lower device 40 this time.

In this case, the lower device 40 starts the process shown in the flowchart of FIG. 14 again, but the judgment in step S201 becomes the rescue URL, and the process proceeds to step S212 to obtain the rescue public key certificate for the lower device privately owned by the rescue. It is sent to the upper device 30 together with the first random number encrypted with the key (rescue private key for the lower device). This process also corresponds to the process of steps S21 and S22 of FIG. 22 or FIG. 24, as in the case of step S203. Unlike the normal public key certificate, the rescue public key certificate can be prevented from being renewed after being stored at the time of manufacturing the device by extending the validity period. If it is a suitable device, it should remember a suitable device.

On the upper device 30 side, when the lower device 40 receives the certificate and the random number transmitted in step S212 in step S107, the authentication process is performed using this. The rescue root key certificate for subordinate device authentication is used for the authentication here, and this process corresponds to the process of steps S12 and S13 of FIG. 22 or FIG. 24 as in the case of steps S102 and S103. If it is not received within a predetermined time after step S106, it may be treated as an authentication failure. Further, in the processing of steps S106 and S107, the CPU of the host device 30 functions as a second authentication means.

Then, it is determined in step S108 whether or not the authentication is successful, and if it is successful, the process proceeds to step S109 to send the seed of the common key to the lower device 40 and create a common key to be used for subsequent communication. To. These processes correspond to the processes of steps S14 to S17 of FIG. 22 or 24, as in the case of steps S104 and S114. On the lower device 40 side, after step S212, this transmission is waited in step S213, and if the seed of the common key is received, it is determined that the higher device 30 has authenticated, and the process proceeds to step S214 to create the common key. To be used for communication. These processes correspond to the processes of steps S23 to S26 of FIG. 22 or the processes of steps S25 and S26 of FIG. 24, as in the case of steps S204 and S205.

On the other hand, on the upper device 30 side, since the authentication using the rescue public key certificate is successful in step S108, it is determined that there is an abnormality in the authentication using the normal public key certificate with the lower device 40. In the process of step S108, the CPU of the host device 30 also functions as an abnormality detection means. Then, in order to renew the certificate of the lower device 40, in step S109 and then step S110, the necessary information is transmitted to the certificate management device 20 to create a new certificate set for renewal, and the certificate is acquired. However, a description of this process will be described in detail later.

When the higher-level device 30 acquires the new certificate set from the certificate management device 20, it sends the new certificate set to the lower-level device 40 together with the certificate renewal request in step S111, and stores (or does not exist) the new certificate set. ) Request to update the legitimate credentials to the contents of the new certificate set. In this process, the CPU of the host device 30 functions as a certificate transmission means. Then, in step S112, the process proceeds to step S117 after waiting for a response from the lower device 40, disconnects the communication, and ends the process. If you want to send the request etc. that you were trying to send at the beginning, you can start the process again, but at this point it should be possible to authenticate with the public key certificate, so from step S104 to S113 It is possible to proceed and send a request to the lower device 40 in the subsequent processing to execute the operation related to this.

On the other hand, on the lower device 40 side, after step S214, the reception of the request is waited in step S215, and when the request is received, the process proceeds to step S216. Then, as described with reference to FIG. 4, the requirements management unit 44 of the lower device 40 permits only the certificate renewal operation when the authentication is performed using the rescue public key certificate. Therefore, it is determined whether or not the request received in step S216 is a certificate renewal request. If it is not a certificate renewal request, the request is ignored and the process returns to step S215 to wait for the next request. Here, a response to the effect that the request cannot be accepted may be returned. If the certificate renewal request is made in step S216, the process proceeds to step S217 to store the new certificate set received together with the certificate renewal request in the certificate storage unit 45 and store the regular authentication information shown in FIG. 5 (a). The content is updated, and in step S218, the update result is notified to the sender as a response, and the process ends.

Next, an example of the processing sequence when the higher-level device 30 and the lower-level device 40 execute the processes shown in FIGS. 13 and 14 will be described including the processing in the certificate management device 20. This processing sequence is shown in FIGS. 15 and 16. Here, the validity of the lower-level device normal public key certificate stored in the lower-level device 40 cannot be confirmed by using the lower-level device authentication normal root key certificate stored in the higher-level device 30. An example of processing in the case of The reason for this may be, for example, that the normal public key certificate for the lower device is a certificate issued by a CA that the higher device 30 does not support.

In this example, the higher-level device 30 first causes the HTTPS client function unit 31 to function as a subordinate device client, and sends a communication request to the normal URL of the lower-level device 40 (S301). In this case, it is the HTTPS server function unit 42 that receives the request on the lower device 40 side, and transmits this request to the authentication processing unit 43. In addition, the lower device 40 is usually required to authenticate using a public key certificate. Then, according to the SSL protocol, the authentication processing unit 43, together with the random number encrypted with the normal private key for the lower device stored in the certificate storage unit 45, is normally open to the public for the lower device also stored in the certificate storage unit 45. The key certificate is returned to the host device 30 (S302).

On the higher-level device 30 side, this is passed to the authentication processing unit 33 for authentication processing, but the validity of the certificate received using the lower-level device authentication normal root key certificate stored in the certificate storage unit 35 is performed. Is not confirmed, so it is determined that the authentication has failed (S303), and an authentication failure response is returned to the lower device 40 (S304). However, at this point, the higher-level device 30 cannot recognize whether or not the other party requesting communication is really the lower-level device 40. Then, since the cause of the authentication failure is that the validity of the public key certificate could not be confirmed, it is investigated whether or not the device related to the normal URL that requested communication is a device that can be suitable as a communication partner. Therefore, a communication request is sent to the rescue URL (S305).

On the lower device 40 side, this request is transmitted to the authentication processing unit 43 as in the case of step S301, but this time, the lower device 40 is requested to authenticate using the rescue public key certificate. Then, according to the SSL protocol, the authentication processing unit 43 publishes the rescue for the lower device stored in the certificate storage unit 45 together with the random number encrypted with the private key for the lower device, which is also stored in the certificate storage unit 45. The key certificate is returned to the host device 30 (S306). On the upper device 30 side, this is passed to the authentication processing unit 33 for authentication processing, but since the lower device 40 is a device that can be a communication partner of the upper device 30, the rescue public key certificate for the lower device is higher. The validity can be confirmed by using the rescue root key certificate for subordinate device authentication stored in the device 30, and the random numbers can be decrypted without any problem, and it is judged that the authentication is successful (S307).

Then, in the case of one-way authentication, the upper device 30 returns the seed of the common key encrypted with the public key included in the rescue public key certificate for the lower device to the rescue URL of the lower device 40 (S308). When performing mutual authentication, the second random number is encrypted using the rescue private key for the higher device stored in the certificate storage unit 35, and returned together with the rescue public key certificate for the higher device.

The lower device 40 passes this to the authentication processing unit 43 to decrypt the seed of the common key using the rescue private key for the lower device, and in the case of mutual authentication, further verifies the validity of the rescue public key certificate for the higher device. After confirming using the root key certificate for higher-level device authentication, the authentication process is performed by decrypting the second random number using the public key included here. Then, since these can be performed normally here, it is determined that the authentication is successful (S309), and the authentication success response is returned to the host device 30 (S310). After that, the upper device 30 and the lower device 40 generate a common key using the seed of the common key transmitted and received in step S308 (not shown).

On the other hand, when the host device 30 receives the response in step S310, it can be seen that the party requesting communication in step S301 is a device that can be a legitimate communication partner, and that there is no particular abnormality in the communication or authentication processing process. .. On the other hand, in step S303, the authentication process failed not because of a communication error or the like, but because it is known that the validity of the normal public key certificate received from the lower device 40 could not be confirmed. It is determined that the authentication using the public key certificate fails because the authentication error has occurred due to the error of the certificate that should be stored in the lower device 40 (S311). That is, since it is a device that should normally succeed in authentication using a public key certificate, it is determined that the authentication has failed because the certificate is abnormal (or the certificate is not stored).

Then, the process proceeds to the continuation shown in FIG. 16, and the HTTPS client function unit 31 is made to function as a management device client, and the certificate management device 20 is requested to issue a normal certificate and the machine number and IP address of the lower device 40. And send the MAC address to request the creation of a new certificate set for the subordinate device 40 (S312). The certificate management device 20 for transmitting the request here is a certificate management device 20 for issuing a public key certificate whose validity can be confirmed by the higher-level device 30. Then, it may be the same CA as the CA that issued the public key certificate transmitted by the lower device 40 during the authentication process, or it may be a different CA.

Further, the information transmitted to the certificate management device 20 here may be stored in advance by the host device 30 as information of the communication partner, or may be stored in advance by the host device 30 after the authentication by the rescue public key certificate is successful. You may send it to 40 to get it. The certificate set includes each certificate and private key shown in FIG. 12, but a normal root key certificate for higher-level device authentication is not required for one-way authentication. In addition, although not shown, when the higher-level device 30 and the certificate management device 20 communicate with each other, the SSL protocol is usually used using the public key certificate as in the case where the higher-level device 30 and the lower-level device 40 communicate with each other. The authentication process shall be performed in accordance with this, and the request, etc. shall be transmitted after establishing a secure communication path.

When the certificate management device 20 receives the request in step S312, it creates a certificate set and its setting request (S313), but the public key certificate included in the certificate set created here is naturally within the valid period. belongs to. For example, the validity period starts from the time of creation and ends after a predetermined period. In addition, since the certificate management device 20 manages the version of the normal root key certificate for lower device authentication stored in the upper device 30, a digital signature that can confirm the validity of the root key certificate is attached. However, a normal public key certificate including the machine number can be created as the identification information of the lower device 40. In this case, the certificate management device 20 collates the machine number, IP address, and MAC address received from the host device 30 with the information managed by itself, and the device to which the public key certificate is usually issued is appropriate. It may be possible to confirm that.

Also, if the public key and private key issued by the certificate management device 20 to the lower device 40 are also remembered, these keys themselves are not updated, only the digital signature is changed to create a new certificate. It is also possible to do. In addition, since the version of the digital signature attached to the higher-level device normal public key certificate issued to the higher-level device 30 is managed, the higher-level device authentication normal root key that can confirm the validity of this digital signature is managed. You can create a certificate. At this time, a new root private key used for digital signature may be newly generated, and the root key certificate may be renewed at the same time. Then, each new certificate and key created here are stored and managed in the certificate management unit 26.

After transmitting the request in step S312, the host device 30 makes a communication request to the certificate management device 20 when the creation of the certificate is completed, and whether or not there is a request from the certificate management device 20 to the host device 30. Inquire (S314). At this time, if the process of step S313 is completed, the certificate management device 20 responds to the communication request with the certificate setting request, the new certificate set, and the IP address and MAC address of the lower device 40 for storing the new certificate set. Is returned to the host device 30 (S315). That is, the higher-level device 30 can acquire a new certificate set to be stored in the lower-level device 40 together with the certificate setting request.

Upon receiving this request, the host device 30 sends a new certificate set with a certificate renewal request to the rescue URL of the specified IP address (S316). At this time, the MAC address may be first obtained from the destination, and the new certificate set may be transmitted after confirming that the MAC address matches the MAC address described in the certificate setting request. On the other hand, the lower device 40 transmits the received certificate renewal request from the HTTPS server function unit 42 to the request management unit 44, and the request management unit 44 causes the certificate renewal unit 48 to execute the certificate renewal process, and the certificate storage unit Update the contents of the new certificate set that received the formal authentication information stored in 45 (S317). Then, a certificate renewal request response indicating the result of the renewal process is returned to the higher-level device 30 (S318), and the higher-level device 30 returns a response to the certificate setting request to the certificate management device 20 based on the response (S319). And the process is finished once. Note that the communication between the higher-level device 30 and the lower-level device 40 is temporarily disconnected after step S310, and when the transmission in step S316 is performed, a communication request is sent to the rescue URL again for authentication. It is good to do it.

By the way, the subsequent processing is omitted in the flowcharts of FIGS. 13 and 14, but when the above certificate renewal is completed, the lower device 40 functions the HTTPS client function unit 41 as the higher device client. And send a communication request to the normal URL of the host device 30. Then, along with the certificate renewal result notification that notifies the result of the renewal process, the machine number, IP address, and version information of the renewed certificate set are notified (S321). The host device 30 returns a response to this notification (S322). In this communication, authentication using a public key certificate is usually performed, but if the certificate included in the new certificate set is used, this authentication can be performed without any problem.

Further, when the higher-level device 30 receives the notification in step S321, it sends a communication request to the normal URL of the lower-level device and re-searches the lower-level device 40 (S331). This is for confirming that the authentication using the normal public key certificate is successful and the communication can be performed normally even when the higher-level device 30 requests the communication. Subordinate device 40 returns a response to this (S332). Upon receiving this response, the host device 30 can confirm that the certificate has been successfully renewed, and as a result, the authentication error using the normal certificate has been resolved. Information is sent to the certificate management device 20 to notify that the update process was successful (S333). The certificate management device 20 returns a response to this (S334).

In the communication systems shown in FIGS. 1 and 2, if the version of the certificate constituting the regular authentication information in the lower device 40 does not match that of the higher device 30 and the authentication cannot be performed normally, the lower device 40 is subjected to the above processing. The certificate of the device is renewed so that the authentication can be performed normally. In addition, the higher-level device 30 and the lower-level device 40 having the above-described configuration execute the above processing to perform authentication using a normal public key certificate when requesting communication in a normal case, and a communication partner. Is possible to establish a secure communication path by SSL by identifying and authenticating, but if authentication using a normal public key certificate cannot be performed normally, a rescue public key certificate issued by a private certificate authority If this is successful, it can be determined that the failure of the authentication using the normal public key certificate is caused by the abnormality of the authentication. Therefore, it is possible to promptly perform an operation for resolving the abnormality. If only the authentication using the rescue public key certificate is successful, it is said that the cause is an abnormality in the regular authentication information stored in the lower device 40, including the normal public key certificate for the lower device. Since it can be guessed, when the authentication using the rescue public key certificate is successful, the upper device 30 acquires a new certificate set and sends it to the lower device 40 to update the normal authentication information, so that the abnormality is promptly abnormal. It can be resolved.

Rescue public key certificates issued by such private certificate authorities are slightly less reliable in the general public than ordinary public key certificates issued by public certificate authorities, but they are fairly secure. Sex can be secured. By preparing such a certificate, it can be placed in an environment where authentication with the set normal public key certificate cannot be used, or the normal public key certificate can be used due to damage or expiration. Even if it disappears, there is an effect that a secure communication path using common key cryptography can be secured if the rescue public key certificate can be used. And if it is a private certificate authority, it will issue a rescue public key certificate that can be used in a wide range of environments, has a long validity period, does not expire, does not require renewal, and can prevent damage at the time of renewal. be able to.

Furthermore, by authenticating with the rescue public key certificate, it is possible to send the new certificate set after confirming that the destination is an appropriate device as the communication partner, so the certificate set is erroneously inappropriate. It will not be stored in a device. When performing mutual authentication, the lower device 40 can also confirm that the source of the new certificate set is the higher device 30 and receive it, so an invalid certificate is stored as regular authentication information. It never ends up. Furthermore, even if authentication using the normal public key certificate cannot be performed, authentication using the rescue public key certificate is possible, so the new certificate set should be sent via a secure communication path using SSL. Because it can be done, the contents will not be leaked to a third party and security can be maintained.

In addition, since the lower device 40 does not accept requests from the other party authenticated using the rescue public key certificate other than the certificate renewal request, other information is usually obtained by using the public key certificate. Access can be granted only to the appropriate authenticated communication partner, and even if the rescue private key is illegally obtained within the validity period of the rescue public key certificate, important information can be illegally accessed. Can be prevented. Then, according to this embodiment, the public key certificate can be automatically renewed, so that this embodiment is for a device such as a cable television in which the certificate cannot be renewed by the operator at the installation destination. It is particularly effective when applied to a communication device whose communication partner is a set-top box, an image forming device which is a target of remote maintenance, or a communication system including such a communication device.

[Modified examples of embodiments: FIGS. 17 to 20] Next, various modifications of the above-described embodiment will be described. In the explanation so far, an example has been described in which the normal authentication information of the lower device 40 is updated when the authentication using the normal public key certificate cannot be performed normally and the authentication using the rescue public key certificate is successful. Here, the reason why the regular authentication information of the lower device 40 is updated is that in the communication system of this embodiment, a plurality of lower devices 40 can be connected to the upper device 30 and can be attached to and detached from the lower device 30. This is because 40 is more difficult to manage, and as a result, environmental changes that make it impossible to use the set normal public key certificate are likely to occur. However, since it is possible that such an environmental change may occur in the higher-level device 30 or the certification authority used by the higher-level device 30 may be changed, the higher-level device 30 attempts to update its own regular authentication information when it recognizes this. You may do so.

An example of the processing sequence in this case is shown in FIG. In this case, first, the HTTPS client function unit 31 is made to function as a CA client, and its own machine number information is sent to the certificate management device 20 together with the normal certificate issuance request to provide a new certificate for itself. Request the creation of a book set (S401). At this time as well, the authentication process is normally performed according to the SSL protocol using the public key certificate, and the request etc. is sent after establishing a secure communication path, but since the regular authentication information of the host device 30 is abnormal. , It is possible that this authentication cannot be performed normally. Although not shown, in such a case, the rescue URL of the certificate management device 20 is accessed to perform authentication using the rescue public key certificate.

Upon receiving the request in step S401, the certificate management device 20 creates a certificate set and its setting request (S402), but the public key and private key issued by the certificate management device 20 to the higher-level device 30 You can create any version of the certificate as long as you remember all the versions of the root private key and root key used in the past, but it is better to create the latest version of the certificate. Then, each new certificate and key created here are also stored and managed in the certificate management unit 26 in the same manner as the previous certificates and the like.

After transmitting the request in step S401, the higher-level device 30 makes a communication request to the certificate management device 20 when the creation of the certificate is completed, and whether or not there is a request from the certificate management device 20 to the higher-level device 30. Inquire (S403). At this time, if the process of step S402 is completed, the certificate management device 20 returns the new certificate set to the host device 30 together with the certificate renewal request as a response to the communication request (S404). When the host device 30 receives this request, it updates the contents of the new certificate set that received the regular authentication information stored in the certificate storage unit 45 (S405), and responds to the certificate renewal request indicating the result of the renewal process. Is returned to certificate management device 20 (S406). The certificate management device 20 returns a notification that a response has been received (S407).

By the above processing, the regular authentication information of the upper device 30 can be updated as in the case of the lower device 40, but since the normal public key certificate is changed by this update, the normal public key certificate is changed before the update. There is a possibility that this authentication cannot be performed normally with the lower device 40 that has been authenticated using. Therefore, communication is requested for the normal URL of each lower device 40, and the lower device is searched again (S408). Then, authentication is performed using the normal public key certificate sent by the lower device 40 as a response, and the lower device 40 for which this authentication could not be performed normally is the same as in steps S305 and subsequent steps of FIGS. 15 and 16. Performs processing to update the legitimate credentials, including the regular public key certificate (S409).

When such a search and update for all the lower devices 40 are completed, the upper device 30 is ready to authenticate all the lower devices 40 again using the normal public key certificate. Therefore, by performing such a process, even if the abnormality of the authentication using the normal public key certificate is caused by the abnormality of the regular authentication information of the higher-level device 30, this abnormality can be eliminated. Further, the re-search as shown in step S408 and subsequent steps in FIG. 17 may be performed independently of the certificate renewal of the host device 30. Through such processing, the success or failure of authentication using the normal public key certificate is periodically checked, and if there is an abnormality, the normal public key certificate of the lower device 40 is updated and each device of the communication system operates. It is possible to maintain a state in which the communication partner can be authenticated using a normal public key certificate.

Furthermore, if this search is performed not only for the IP address of the device stored as the communication partner but also for the entire range of the defined IP address, even if a new lower device 40 is connected, it will be automatically performed. It can be detected and authenticated using a normal public key certificate. Even if the subordinate device 40 does not store the normal public key certificate at the time of manufacture, if the authentication using the rescue public key certificate is successful, the certificate management device 20 will be provided with the normal public key certificate for the subordinate device. Can be issued and memorized.

Therefore, if such a search is used, only the rescue authentication information is stored in the lower device 40 at the time of manufacturing at the factory and shipped, and after the device is installed at the customer's site and connected to the higher device 30, the network is connected. It is also possible to distribute the formal authentication information via the system and store it. If a device with an abnormality in authentication using the normal public key certificate is found by this search, the normal public key certificate is immediately renewed (or newly stored), so such a search is subordinate. It can be considered as part of the operation of storing a new public key certificate in the device 40.

Further, in the above-described embodiment, an example in which a communication request is made from the upper device 30 to the lower device 40 has been described, but it is not essential to do so. That is, the same processing can be performed even when communication is performed from the lower device 40 to the higher device 30. 18 to 20 show the processing sequence of the portion corresponding to FIG. 15 in this case. However, in FIGS. 18 to 20, the sequence is shown in a simplified manner as compared with the case of FIG.

First, in FIG. 18, communication is requested from the lower device 40 to the upper device 30 regardless of whether the authentication is performed using the normal public key certificate or the rescue public key certificate. An example of the case is shown. In this case, when the lower device 40 requests communication from the normal URL in order to perform normal communication with the upper device 30 (S501), a normal public key certificate is issued between the upper device 30 and the lower device 40 accordingly. Perform the authentication process used (S502).

This authentication process may be mutual authentication as shown in FIG. 22 or one-way authentication, but at least the upper device 30 uses the public key certificate of the lower device 40 to use the lower device 40. Shall be authenticated. Since the lower device 40 corresponds to the client in this example, the process for performing one-way authentication is slightly different from that shown in FIG. 24, but the lower device 40 uses its own private key to generate random numbers. Is encrypted and sent to the higher-level device 30 together with the public key certificate, and after confirming the validity of the public key certificate on the higher-level device 30 side, the random number is decrypted and authentication is performed. Good.

Then, when the upper device 30 determines that the authentication in step S502 has failed (S503), it returns an authentication failure response to the lower device 40 (S504). Then, the lower device 40 that receives this response next requests communication from the rescue URL of the higher device 30 (S505). Then, the authentication process using the rescue public key certificate is performed (S506), and when the host device 30 determines that the authentication is successful (S507), the authentication using the normal public key certificate is performed as in the case of step S311 in FIG. Is determined to have failed because the authentication error has occurred due to an error in the certificate that should be stored in the lower device 40 (S508). Then, the process shown in FIG. 16 is executed to update the regular authentication information of the lower device 40.

Further, FIG. 19 shows that communication is requested from the lower device 40 to the upper device 30 when performing authentication using the normal public key certificate, and when performing authentication using the rescue public key certificate. , An example of requesting communication from the upper device 30 to the lower device 40 is shown. In this case, the processing of steps S511 to S514 is the same as that of steps S501 to S504 of FIG. 18, but when the upper device 30 returns an authentication failure response to the lower device 40, it is subsequently sent to the rescue URL of the lower device 40. Request communication to (S515). Then, when the authentication process using the rescue public key certificate is performed (S516) and the authentication is judged to be successful (S517), the authentication using the normal public key certificate fails as in the case of step S311 in FIG. Determines that the authentication error has occurred due to the certificate error that should be stored in the lower device 40 (S518). Then, the process shown in FIG. 16 is executed to update the regular authentication information of the lower device 40.

Further, in FIG. 20, conversely, when performing authentication using a normal public key certificate, communication is requested from the upper device 30 to the lower device 40, and authentication using the rescue public key certificate is performed. Shows an example in which communication is requested from the lower device 40 to the higher device 30. In this case, when the upper device 30 requests communication from the normal URL in order to perform normal communication with the lower device 40 (S521), a normal public key certificate is issued between the upper device 30 and the lower device 40 accordingly. Perform the authentication process used (S522). Regarding the content of the authentication process, mutual authentication as shown in FIG. 22 or one-way authentication as shown in FIG. 24 may be used.

Then, when the upper device 30 determines that the authentication in step S522 has failed (S523), it sends an authentication failure response to the lower device 40 (S524). Then, when the lower device 40 receives this response, it requests communication from the rescue URL of the higher device 30 (S525). Then, the authentication process using the rescue public key certificate is performed (S526), and when the host device 30 determines that the authentication is successful (S527), the authentication using the normal public key certificate is performed as in the case of step S311 in FIG. Is determined to have failed because the authentication error has occurred due to an error in the certificate that should be stored in the lower device 40 (S528). Then, the process shown in FIG. 16 is executed to update the regular authentication information of the lower device 40.

Regardless of the sequence shown in any of FIGS. 18 to 20 as described above, the rescue public key certificate is used when the authentication using the normal public key certificate fails, as in the case of the above-described embodiment. If the authentication is successful, it can be determined that the failure of the authentication using the public key certificate is caused by the abnormality of the authentication. Therefore, the higher-level device 30 acquires the new certificate set and sends it to the lower-level device 40 to update the regular authentication information, so that the abnormality can be quickly resolved.

Further, which device makes the communication request may be changed depending on the case. For example, when the authentication using the normal public key certificate fails, the upper device 30 requests communication from the rescue URL of the lower device 40, or the response that the authentication using the normal public key certificate fails. If the lower device 40 requests communication from the rescue URL of the higher device 30 when the message is received, the subsequent processing is the same regardless of which device performs the communication to the first normal URL. You can proceed to. For the communication in step S316 of FIG. 16 related to the transmission of the new certificate set, the lower device 40 side makes a communication request, and the upper device 30 side sends a certificate renewal request in response to the communication request. May be good.

Further, in the above-described embodiment, the CA of the third party organization is requested to issue the certificate directly from the higher-level device 30, and the certificate is issued from the certificate management device 20 once via the certificate management device 20. A method of requesting is also conceivable. In addition, since the rescue public key certificate has a long validity period, it is extremely difficult to maintain the security of communication if the rescue root private key is leaked, so it is necessary to maintain confidentiality particularly strictly. Therefore, with an emphasis on security, it is preferable to use a certificate management device that cannot be accessed from the outside, for example, which can communicate with only a factory having a process of storing a certificate by a dedicated line. In addition, a certificate management device that issues a certificate for a lower device, a certificate management device that issues a certificate for a higher device, a certificate management device that issues a certificate for each certificate management device, etc. The certificate management device may be divided according to the type of the device to be issued.

Further, in the above-described embodiment, an example using a normal public key certificate issued by a public certificate authority and a rescue public key certificate issued by a private certificate authority has been described, but the former is a proof with high security strength. The latter can be regarded as a certificate with relatively low security strength. In general, a certificate with high security strength needs to contain a lot of information, export restrictions, and a special authentication processing program are required, so the available environment is limited. , It may be difficult to store in all devices in the same way and use it for authentication processing. On the other hand, if the certificate has low security strength, such restrictions are few, and it is considered that it is relatively easy to store the certificate in all devices in the same way and use it for the authentication process.

Therefore, there is a demand to manufacture and sell a device that stores a certificate with low security strength, and then to be able to store a certificate with high security strength after the fact according to the usage environment. For example, it is conceivable that the system operator may devise various authentication processing contents or select a highly reliable CA to improve security. In such a case, one device is used as one system. When moving from to another system (including the case of simply changing the settings), it may be necessary to replace the certificate used for normal authentication processing. In addition, it is possible that a defect will be discovered later in a highly secure certificate and it will be necessary to change the authentication processing method. In such a case, using the process of the above-described embodiment, if the authentication using the high security certificate fails, the authentication using the low security certificate is performed, and if this succeeds, the high security is performed. It is determined that the failure of authentication using the certificate is caused by an authentication error, and the upper device 30 acquires a certificate set containing a highly secure certificate, sends it to the lower device 40, and stores it. This makes it possible to store a certificate suitable for the usage scene in the device after it is installed at the customer's site while ensuring a certain degree of security.

Further, in the above-described embodiment, an example in which the upper device 30 and the lower device 40 or the certificate management device 20 perform authentication according to SSL as described with reference to FIG. 22 or FIG. 24 has been described. However, even if this authentication is not necessarily such, the effect as in the above-described embodiment can be obtained. TLS (Transport Layer Security), which is an improved version of SSL, is also known, but it can of course be applied when performing authentication processing based on this protocol.

Further, in the above-described embodiment, an example in which the certificate management device 20 is provided separately from the higher-level device 30 has been described, but it does not prevent the certificate management device 20 from being provided integrally with the higher-level device 30. In this case, parts such as CPU, ROM, RAM, etc. for realizing the functions of the certificate management device 20 may be provided independently, but the CPU, ROM, RAM, etc. of the host device 30 are used, and the CPU is used. The certificate management device 20 may be made to function by executing appropriate software.

In such a case, for communication between the certificate management device 20 and the higher-level device 30 integrated with the certificate management device 20, the process for making the hardware function as the certificate management device 20 and the hardware are required. It shall include interprocess communication with the process for functioning as the host device 30. Further, in each of the above-described embodiments, an example in which the certificate management device 20 creates a root key or a digital certificate by itself has been described, but the functions of the certificate key creation unit 24 and the certificate issuing unit 25 shown in FIG. 2 have been described. May be provided in a device different from the certificate management device 20, and the certificate management device 20 may receive the root key and the digital certificate from the device and acquire them.

Further, in the above-described embodiment, an example in which the identification information of the device is described in the rescue public key certificate has been described, but the device identification information of the device is not included in the rescue public key certificate, and the devices of the same rank (FIG. In the example shown in 1 and FIG. 2, it is assumed that the certificate management device, the upper device, and the lower device have the same rank), and the same rescue public key certificate may be stored. In this case, since it is not necessary to distinguish each device of the same rank individually, the rescue public key included in the certificate and the corresponding rescue private key may be completely common. Since all the rescue public key certificates of the communication partner are the same, the root key certificate is common to all the devices that are the communication partners of the device of a certain rank. That is, even when a plurality of lower devices are provided as shown in FIG. 21, the same rescue authentication information is stored in all the lower devices.

This also applies to the rescue authentication information of the host device 30 and the rescue authentication information of the certificate management device 20. When unifying the data format with the normal public key certificate, for example, in the format shown in Fig. 8, leave the "Subject" item blank, or enter only the vendor name and enter 0 as the machine number. It is also possible to show that it is a rescue public key certificate.

In this way, the rescue authentication information is common to all devices of the same rank, so that it is possible to store the rescue authentication information according to the rank determined according to the model at the time of manufacturing the device. That is, since it is not information with device identification information, it is not necessary to prepare and store an individual certificate for each device with an identification number after completing the inspection process, and for a large number of devices. It can be memorized by simple work. For example, the rescue authentication information is included in the master of the control program, and the rescue authentication information is also stored when the control program is copied to the device. Then, if the rescue public key certificate has a sufficiently long validity period, there is no need to update the rescue authentication information after that, and as described above, the validity period of the normal public key certificate has passed and the normal public key certificate has passed. Even if the written authentication cannot be performed, the authentication using the rescue public key certificate included in the rescue authentication information can be maintained.

In this case, since the rescue public key certificate does not include the device identification information, the device of the communication partner cannot be specifically specified even when the rescue public key certificate is used for authentication. .. However, some information about the communication partner can be obtained. That is, for example, a vendor has rescue authentication information for a lower device (rescue public key certificate for a lower device, rescue private key for a lower device, and rescue root key for authentication of a higher device) for all devices corresponding to the lower device 40 among its own products. (Certificate) is stored, and rescue authentication information for the higher-level device (rescue public key certificate for the higher-level device, rescue private key for the higher-level device, and rescue for lower-level device authentication) is stored in all the devices corresponding to the higher-level device 30 that is the communication partner. If the root key certificate) is stored, the lower device 40 can confirm the validity with the rescue root key certificate for higher device authentication that it remembers when the authentication process is successful. It can recognize that the sender is the higher-level device 30 of the same vendor, and conversely, the higher-level device 30 has also sent a public key certificate that can be verified with the rescue root key certificate that it remembers. It can be recognized that the other party is a lower device 40 of the same vendor.

Then, if such authentication is successful, the common key can be shared with the communication partner and a secure communication path using the common key cryptography can be provided as described above. It is also possible to identify the communication partner by exchanging. The same can be done between the certificate management device 20 and the host device 30. As for the ordinary public key certificate, if the public certificate authority provides such a service, it is also conceivable that the device identification information is not included. Even if this is done, it is considered to be highly reliable because it is issued by a public certificate authority. In addition, if the validity period is shorter than that of the rescue public key certificate, the security can be improved as much as that of the rescue public key certificate. Nor is it prevented that a private certificate authority issues a regular public key certificate (including legitimate credentials).

Further, the program according to the present invention is a communication device provided with a communication means and authenticates a communication partner using a digital certificate at the time of communication, or a communication device serving as the communication partner, which is a higher-level device 30 or a lower-level device. It is a program for functioning as a device such as 40, and the above-mentioned effect can be obtained by causing a computer to execute such a program.

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

As described above, the communication device, communication system, and communication system of the present invention.<u style="single">Communication method</u>Alternatively, if you use a program, you can communicate with the other party when communicating.<u style="single">Certificate</u>When there is an abnormality in authentication while maintaining security in a communication device that authenticates using, a communication device that is a communication partner of such a communication device, or a communication system configured by using such a communication device. However, it can be easily restored to a state where normal authentication can be performed. Therefore, by applying the present invention to such a communication system or a communication device constituting such a communication system, it is possible to configure a communication system having a high degree of freedom while maintaining security.

<figref num="1">It is a functional block diagram which shows the functional structure of the part related to the feature of this invention about the upper device and the lower device which are the embodiment of the communication device of this invention which constitute the communication system which is an embodiment of this invention.</figref><figref num="2">FIG. 5 is a functional block diagram showing a functional configuration of a portion related to the features of the present invention with respect to the certificate management device capable of communicating with the host device shown in FIG.</figref><figref num="3">It is a block diagram which shows the hardware configuration of the certificate management apparatus shown in FIG. 1 and FIG.</figref><figref num="4">It is a figure for demonstrating the judgment criteria of permission / disapproval of a request in the requirement management part of the lower apparatus shown in FIG. 1 and FIG.</figref><figref num="5">It is a figure for demonstrating the authentication information stored in the upper device and the lower device shown in FIGS. 1 and 2.</figref><figref num="6">It is also a figure for demonstrating the authentication information stored in the certificate management apparatus.</figref><figref num="7">It is a figure for demonstrating the format example of a normal public key certificate.</figref><figref num="8">It is a figure which shows the example of the general public key certificate created according to the format shown in FIG.</figref><figref num="9">Similarly, it is a figure which shows an example of a normal public key certificate for comparison with a rescue public key certificate.</figref><figref num="10">Similarly, it is a figure which shows an example of a rescue public key certificate for comparison with a normal public key certificate.</figref>

<figref num="11">It is a figure for demonstrating the structure for the upper device and the lower device shown in FIGS. 1 and 2 to use a normal public key certificate and a rescue public key certificate properly.</figref><figref num="12">FIG. 5 is a diagram showing a configuration example of a certificate set transmitted from a higher-level device to a lower-level device when updating the regular authentication information of a lower-level device in the communication system shown in FIGS. 1 and 2.</figref><figref num="13">It is a flowchart which shows an example of the process performed by a higher-level device among the process related to the renewal of a certificate using two types of certificates, a normal public key certificate and a rescue public key certificate, in the communication system.</figref><figref num="14">It is also the flowchart which shows the example of the processing performed by the lower-level device.</figref><figref num="15">It is a figure which shows the example of the processing sequence when the processing shown in FIG. 13 and FIG. 14 is executed in the communication system.</figref><figref num="16">It is a figure which shows the continuation.</figref><figref num="17">It is a figure which shows the example of the processing sequence when the higher-order device updates its own regular authentication information in the communication system.</figref><figref num="18">It is a figure which shows the modification of the processing sequence shown in FIG. 15 in a simplified manner.</figref><figref num="19">It is a figure which shows still another modification.</figref><figref num="20">It is a figure which shows still another modification.</figref><figref num="21">It is a figure for demonstrating the configuration in the case where a plurality of lower-order devices are provided about the communication system.</figref><figref num="22">It is a figure which shows the flowchart of the process executed in each device when two communication devices perform mutual authentication according to SSL, together with the information used for the process.</figref><figref num="23">It is a figure for demonstrating the relationship between the root key, the root private key, and the public key certificate in the authentication process shown in FIG.</figref><figref num="24">It is a figure corresponding to FIG. 22 which shows the process performed in each device when two communication devices perform one-way authentication according to SSL.</figref>

Code description

11: CPU 12: ROM 13: RAM 14: HDD 15: Communication I / F 16: System bus 20: Certificate management device 21,32,42: HTTPS server function part 22,33,43: Authentication processing department 23,48: Certificate renewal department 24: Certificate key creation department 25: Certificate Issuing Department 26: Certificate Management Department 30: Upper device 31,41: HTTPS client function part 34: Certificate renewal request unit 35,45: Certificate storage unit 40: Subordinate device 44: Requirements management department 46: Status notification unit 47: Log notification unit 49: Command receiver