JP4611681B2 - COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM - Google Patents

Description

The present invention includes a communication device that communicates with a counterpart device via a network, a higher-level device and a lower-level device, and a communication system that communicates between the higher-level device and the lower-level device via the network, and the counterpart via the network. The present invention relates to a communication method by a communication device that communicates with a destination device, and a program that is executed by a computer that controls a communication device that communicates with a counterpart device via a network.

  2. Description of the Related Art Conventionally, a variety of systems have been constructed by connecting a plurality of communication devices each having a communication function via a network so that communication is possible. As an example, there is a so-called electronic commerce system in which an order for a product is transmitted from a computer such as a PC (personal computer) functioning as a client device, and the order is received by a server device that can communicate with the order via the Internet. It is done. In addition, a system has also been proposed in which various electronic devices are connected via a network with the functions of a client device or a server device, and the electronic device is remotely managed by communication between them.

In constructing such a system, it is important to confirm whether a communication partner is appropriate or whether transmitted information is falsified when performing communication. In particular, in the Internet, since information often passes through an irrelevant computer until it reaches a communication partner, it is necessary to prevent the contents from being stolen when transmitting confidential information. As a communication protocol that meets such requirements, for example, a protocol called SSL (Secure Socket Layer) has been developed and widely used. By performing communication using this protocol, it is possible to combine a public key cryptosystem and a common key cryptosystem to authenticate a communication partner and to prevent tampering and eavesdropping by encrypting information. The communication partner can also authenticate the communication source device that has requested communication.
Examples of techniques related to authentication using SSL or public key cryptography include those described in Patent Document 1 and Patent Document 2.
JP 2002-353959 A JP 2002-251492 A

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

FIG. 23 shows these relationships.
As shown in FIG. 23A, the public key A includes a key body for decrypting a document encrypted using the private key A, an issuer (CA) of the public key, a validity period, and the like. Bibliographic information including information. The CA encrypts the hash value obtained by hashing the public key A using the root private key to indicate that the key body or bibliographic information has not been tampered with, and uses it as a digital signature for the client public key. Attached. 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 the digital signature is public key certificate A.

  When this public key certificate A is used for authentication processing, the digital signature included therein is decrypted using the key body of the root key, which is the public key corresponding to the root private key. If this decryption is carried out normally, it can be seen that the digital signature is certainly attached by the CA. If the hash value obtained by hashing the public key A portion matches the hash value obtained by decryption, it is understood that the key itself is not damaged or tampered. Further, if the received data can be normally decrypted using the public key A, it is understood that the data is transmitted from the owner of the private key A.

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

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

Here, it is assumed that the communication device A requests communication to the communication device B. When this request is made, the CPU of the communication device A executes a required control program, and the flowchart shown on the left side of FIG. Start processing. In step S11, a connection request is transmitted to the communication apparatus B.
On the other hand, when the CPU of the communication apparatus 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. In step S21, a first random number is generated and encrypted using the private key B. In step S22, the encrypted first random number and the public key certificate B are transmitted to the communication device A.

When receiving this, the communication apparatus A confirms the validity of the public key certificate B using the root key certificate in step S12.
If it can be confirmed, the first random number is decrypted using the public key B included in the received public key certificate B in step S13. Here, if the decryption is successful, it can be confirmed that the first random number is certainly received from the issue target of the public key certificate B.
Thereafter, in step S14, a second random number and a common key seed are generated separately. The common key seed can be created based on, for example, data exchanged through communication so far. In step S15, the second random number is encrypted using the private key A, the seed of the common key is encrypted using the public key B, and these are transmitted to the server apparatus together with the public key certificate A in step S16. The encryption of the common key seed is performed so that the apparatus other than the communication partner does not know the common key seed.
In the next step S17, a common key used for encryption of subsequent communication is generated from the seed of the common key 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 using the root key certificate in step S23. If it can be confirmed, the second random number is decrypted by using the public key A included in the received public key certificate A in step S24. Here, if the decryption is successful, it can be confirmed that the second random number is certainly received from the issue target of the public key certificate A.
Thereafter, the seed of the common key is decrypted using the private key B in step S25. With the processing so far, the type of the common key is shared between the communication device A side and the communication device B side. The common key seed is not known by any device other than the generated communication device A and the communication device B having the private key B. If the processing so far is successful, the communication device B also generates a common key used for encryption of subsequent communication from the seed of the common key obtained by decryption in step S26.

  When the processing of step S17 on the communication device A side and step S26 on the communication device B side is completed, the authentication success and the encryption method used for the subsequent communication are mutually confirmed, and the generated common key is used. The processing related to authentication is terminated assuming that subsequent communication is performed using the encryption method. Note that this confirmation includes a response indicating that the authentication from the communication apparatus B is successful. Communication can be established by the above processing, and thereafter, communication can be performed by encrypting data by the common key encryption method using the common key generated in step S17 or S26.

By performing such processing, the communication device A and the communication device B can mutually share a common key after authenticating each other, and a route for performing communication safely can be established.
However, in the above-described processing, it is not essential to encrypt the second random number with the public key A and transmit 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 is not necessary, and the processing is as shown in FIG. In this way, the communication device B cannot authenticate the communication device A, but this processing is sufficient when the communication device A only needs to authenticate the communication device B. In this case, only the root key certificate may be stored in the communication device A, and the private key A and the public key certificate A are not necessary. Further, it is not necessary for the communication device B to store the root key certificate.

By the way, in the above authentication processing, the content encrypted with the public key can be decrypted only by a device having the corresponding private key, and the content encrypted with the private key can be decrypted only by the corresponding public key. The communication partner is a device that is described as the issue destination in the public key certificate (or the user of the device is the user that is described as the issue destination in the public key certificate) ).
Also, assuming the confidentiality of the CA's root private key, the public key certificate is certified by the CA, and the CA (provider) guarantees the accuracy of the contents of the public key certificate. You can see that However, the fact that the communication partner is surely the same as the device described in the public key certificate can only be determined by trusting the guarantee of the CA that issued the public key certificate. Therefore, the reliability of CA is an important factor in ensuring communication safety by authentication using public key cryptography.

On the other hand, encryption and authentication technologies are progressing day by day, and higher-strength encryption and authentication technologies using the encryption have been proposed and put into practical use. Such a high-strength cipher is realized by increasing the key length or adopting a higher-strength cryptographic method in the case of the public key cipher described above. When methods with such strong encryption strength are put into practical use, it is conceivable to adopt those methods in consideration of the security level.
In such a case, when a digital certificate with high encryption strength is issued and started to operate on the communication system, the digital certificate stored in the communication device cannot be authenticated from the communication partner. There was a problem that it might end.

  Such a problem is to maintain security by authenticating the operator, etc., if the operator can operate the device when it becomes unable to authenticate and a new digital certificate can be set easily. It is not so serious because it can. However, other settings on the communication system may be difficult because it is difficult for the operator to set due to the user's proficiency and usage environment, or because it is not preferable for the operator to set the certificate freely. In the case where the certificate is set remotely from the communication apparatus, there is no means for maintaining security in a state where authentication cannot be performed, and this is a serious problem.

This invention is to solve such a problem, in a communication device or a communication system which is constructed by using such a communication device authenticates by using a certificate for a communication partner at the time of communication abnormality in the authentication using the certificate It is an object of the present invention to make it possible to easily recover to a state where normal authentication can be performed even in the case where a problem occurs.

In order to achieve the above object, the communication device according to the present invention is a communication device that communicates with a counterpart device via a network, and performs communication with the counterpart device when the first device received from the counterpart device. From the first certificate received from the counterpart device when the authentication by the first authenticator fails to authenticate the counterpart device using the first certificate. In the case where the second authentication unit that authenticates the counterpart device using the second certificate having the low cryptographic strength of the cipher used for the authentication process and the authentication by the second authentication unit succeed, And a transmission means for transmitting a certificate update request for requesting the update of the first certificate and a certificate for updating the first certificate to the counterpart apparatus.
Here, in the communication device, when the authentication by the second authentication unit is successful, the first certificate to be transmitted to the counterpart device is updated to a predetermined certificate management device. It is preferable to provide means for requesting the issuance of a certificate for acquiring the certificate for updating the first certificate from the certificate management apparatus.

According to another communication device of the present invention, in a communication device that communicates with a counterpart device via a network, the encryption strength of encryption used for authentication processing is lower than that of the first certificate and the first certificate. Storage means for storing a second certificate, first transmission means for transmitting the first certificate to the counterpart device when communicating with the counterpart device, and the first transmission A second transmitting means for transmitting the second certificate to the counterpart device when the authentication at the counterpart device using the first certificate transmitted by the means fails; A certificate renewal request for requesting renewal of the first certificate from the counterpart device when the authentication at the counterpart device using the second certificate transmitted by the transmission means is successful; and A certificate for renewing the first certificate is received and stored in the storage means The 憶 been the first certificate is provided with a an updating means for updating the certificate received above.

In the communication device, when the authentication with the counterpart device using the second certificate transmitted by the second transmitter is successful, the certificate of the requests from the counterpart device It is advisable to allow only update requests.
The certificate for updating the first certificate received by the updating means may be transmitted together with the certificate update request.

The communication system of the present invention includes a host device and a lower device, and in the communication system in which the host device and the lower device communicate via a network, the lower device includes a first certificate and the lower device. A storage means for storing a second certificate whose cryptographic strength is lower than that of the first certificate for authentication processing, and when communicating with the host device, the first certificate is stored in the host device. The first certificate is transmitted to the host device, and when the authentication by the host device using the first certificate transmitted by the first transmitter fails, the second certificate is sent to the host device. And when the authentication at the host device using the second certificate transmitted by the second transmitter and the second certificate transmitted by the second transmitter succeeds, the host device sends the first certificate. Certificate renewal request for requesting renewal and the first Updating means for receiving a certificate for updating a certificate from the higher-level device and updating the first certificate stored in the storage means to the received certificate; When communicating with the lower-level device, the first authentication unit that authenticates the lower-level device using the first certificate received from the lower-level device and the authentication by the first authentication unit failed. A second authentication unit that authenticates the lower-level device using the second certificate received from the lower-level device, and when the authentication by the second authentication unit is successful, the first A certificate update request for requesting a certificate update and a transmission means for transmitting a certificate for updating the first certificate to the lower-level device are provided.

In the communication system, when the authentication by the second authentication unit is successful in the upper device, the first certificate to be transmitted to the lower device is updated to a predetermined certificate management device. It is preferable to provide means for requesting the issuance of a certificate to do so and obtaining a certificate for updating the first certificate from the certificate management apparatus.
Further, when the lower-level device succeeds in the authentication by the higher-level device using the second certificate transmitted by the second transmission means, the certificate renewal among the requests from the higher-level device. It is advisable to allow only requests.
Further, the transmission means of the higher-level device transmits the certificate for updating the first certificate together with the certificate update request to the lower-level device, and the first means received by the update means of the lower-level device. The certificate for updating the certificate may be transmitted together with the certificate update request.

Further, the communication method of the present invention uses a first certificate received from a counterpart device when communicating with the counterpart device to a communication device that communicates with the counterpart device via a network. The first authentication procedure for authenticating the counterpart device and the encryption used for the authentication process rather than the first certificate received from the counterpart device when the authentication by the first authentication procedure fails. A second authentication procedure for authenticating the counterpart device using a second certificate having a low cryptographic strength, and updating of the first certificate when authentication by the second authentication procedure is successful And a transmission procedure for transmitting a certificate for updating the first certificate to the counterpart apparatus.

Another communication method of the present invention is a communication device for communicating with a counterpart device via a network, wherein the encryption strength of the first certificate and the encryption used for the authentication process is more than that of the first certificate. A first transmission procedure for transmitting the first certificate to the counterpart device when communicating with the counterpart device in a communication device having storage means for storing a second certificate having a low The second transmission for transmitting the second certificate to the counterpart device when the authentication with the counterpart device using the first certificate transmitted in the first transmission procedure fails. When the authentication with the counterpart device using the procedure and the second certificate transmitted in the second transmission procedure is successful, the counterpart device requests to update the first certificate. Receive a certificate renewal request and a certificate for renewing the first certificate The first certificate stored in the storage means in which to execute the update procedure for updating the certificate received above.

Further, the program of the present invention provides a first certificate received from a counterpart device when the computer that controls the communication device that communicates with the counterpart device via the network communicates with the counterpart device. A first authentication unit that authenticates the counterpart device using the first authentication unit, and the authentication process that is received from the counterpart device when the authentication by the first authentication unit fails, rather than the first certificate. A second authenticating means for authenticating the counterpart device using a second certificate having a low cryptographic strength for encryption, and the first proof when the authentication by the second authenticating means is successful. A program for causing a certificate update request to update a certificate and a certificate for updating the first certificate to function as a transmission unit that transmits the certificate to the counterpart device.

Another program of the present invention is a communication device that communicates with a counterpart device via a network, and the encryption strength of the cipher used for authentication processing is higher than that of the first certificate and the first certificate. When a computer that controls a communication device having storage means for storing a low second certificate communicates with the counterpart device, the first certificate is transmitted to the counterpart device. A second means for transmitting the second certificate to the partner device when authentication with the partner device using the first certificate transmitted by the transmitter and the first transmitter fails. When the authentication at the counterpart device using the second transmission means and the second certificate transmitted by the second transmission means is successful, the update of the first certificate from the counterpart device Certificate renewal request for requesting and renewing the first certificate Receiving the order of the certificate, a program for operating the first certificate stored in the storage means as a updating means for updating the certificate received above.

Above-mentioned communication device according to the present invention, according to the communication system or communication method, a communication apparatus or a communication system which is constructed by using such a communication device authenticates by using a certificate for a communication partner at the time of communication, even if an abnormality occurs in the authentication using the certificate can be so it can be easily restored to the state capable of performing successful authentication.
Further, according to the program of the present invention, it is possible to realize the characteristics by causing the computer to control the communication device so as to function as the communication device described above, and obtain the same effect.

Preferred embodiments of the present invention will be described below with reference to the drawings.
First, the configuration of the first embodiment of the communication apparatus according to the present invention and the communication system of the present invention configured using the communication apparatus 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, so that the higher-level device 30 and the certificate management device 20 can communicate with each other via a network. The certificate management apparatus constitutes a digital certificate management system. FIG. 1 is a functional block diagram showing the functional configuration of the higher-level device and the lower-level device, and FIG. In these drawings, illustration of portions not related to the features of this embodiment is omitted. In this specification, the digital certificate refers to digital data to which a signature for preventing forgery is attached.

In this communication system, when the upper device 30 is to communicate with the lower device 40, the lower device 40 is made a valid communication partner by an authentication process according to the SSL protocol, which is an authentication method using public key cryptography and a digital certificate. Is established, communication is established with the lower apparatus 40. 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.
Conversely, when the lower level device 40 tries to communicate with the higher level device 30, communication is performed with the higher level device 30 when the higher level device 30 is authenticated as a valid communication partner by the authentication process according to SSL. To establish. In response to the request transmitted by the lower level device 40, the higher level device 30 performs necessary processing and returns a response, thereby functioning as a client / server system.
In either case, the requesting side functions as a client, and the requested side functions as a server.

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

In such a communication system, each node of the certificate management apparatus 20, the upper apparatus 30, and the lower apparatus 40, including the communication between the upper apparatus 30 and the lower apparatus 40, is performed by RPC (remote procedure call). It is possible to transmit a “request” that is a request for processing for a method of an application program that is implemented mutually, and obtain a “response” that is a result of the 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), technology, specifications, etc. can be used.

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

  The high-order device 30 and the low-order device 40 can have various configurations depending on purposes such as remote management of devices and electronic commerce. For example, in the case of remote management, image processing devices such as printers, fax machines, copiers, scanners, digital multifunction devices, network home appliances, vending machines, medical equipment, power supply devices, air conditioning systems, gas / water / An electronic device such as an electric metering system, an automobile, or an aircraft is used as a subordinate device 40 that is a managed device, and a supervising device for collecting information from these managed devices or operating by sending commands A device 30 is conceivable.

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

FIG. 1 shows the functional configuration of the portions of the higher-level device 30 and the lower-level device 40 that are characteristic of this embodiment as described above.
First, the host device 30 includes a Hypertext Transfer Protocol Security (HTTPS) 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 uses the HTTPS protocol including authentication and encryption processing according to SSL to request communication with a device having an HTTPS server function, such as the lower level device 40, and to the communication partner. It has a function of transmitting a request (command) or data and executing an operation corresponding to the request.

On the other hand, the HTTPS server function unit 32 receives a communication request using the HTTPS protocol from a device having a function of an HTTPS client, receives a request or data from the device, and causes each unit of the device to execute an operation corresponding thereto, It has a function of returning the result as a response to the request source.
When the HTTPS client function unit 31 or the HTTPS server function unit 32 authenticates a communication partner, the authentication processing unit 33 receives a digital certificate received from the communication partner, various certificates stored in the certificate storage unit 35, It has a function of an authentication means for performing authentication processing using a private key or the like. In addition, it 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 detection means for determining that there is an abnormality in authentication using a normal public key certificate in a predetermined case.

The certificate update request unit 34, as will be described later, is a certificate transmission unit that transmits a normal public key certificate to a communication partner such as the lower level device 40 in a predetermined case, and a certificate that requests to store the certificate. And a function of updating means.
The certificate storage unit 35 stores authentication information such as various certificates and private keys, and has a function for use in authentication processing in the authentication processing unit 33. The types of these certificates and private keys, their uses, and creation methods will be described in detail later.
The functions of these units are realized by the CPU of the host device 30 executing a required control program and controlling the operations of the units of the host device 30.

Next, the lower level 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, a certificate update. A unit 48 and a command receiving unit 49 are provided.
Similar to the HTTPS client function unit 31 of the host device 30, the HTTPS client function unit 41 uses the HTTPS protocol to request communication with a device having the function of the HTTPS server, such as the host device 30, and to send a request or 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, and accepts a communication request from a device having the function of an HTTPS client and executes an operation corresponding to the received request or data in each unit of the device. And has a function of returning a response to the request source.
The function of the authentication processing unit 43 is the same as that of the authentication processing unit 33 of the higher-level device 30, but the certificate 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 a request received from the host device. When the execution is permitted, the function unit 46-49 has a function of transmitting an operation request to the function units 46 to 49 that execute an operation based on the request.

  FIG. 4 shows criteria for determining whether or not execution is possible. The criteria are the type of request and the type of digital certificate used in the authentication process in the authentication processing unit 43. As will be described in detail later, the digital certificate stored in the higher-level device 30 and the lower-level device 40 is a normal public key certificate that is a first certificate corresponding to authentication processing with higher cryptographic strength, and cryptographic strength. There is a rescue public key certificate that is a second certificate corresponding to a lower authentication process, and the request management unit 44, as shown in FIG. However, when authentication is performed using a rescue public key certificate, only the certificate renewal operation is permitted. Here, it is assumed that the certificate to be updated is only a normal public key certificate and the rescue public key certificate is not updated. Therefore, the rescue public key certificate is a certificate that is used only when a new normal public key certificate (and a private key or a root key certificate stored in association therewith) is stored in the lower level device 40. 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 has a function of a certificate storage unit used for authentication processing in the authentication processing unit 43 . . However, the stored certificate and the like are different from the certificate storage unit 35 as described later.
The state notification unit 46 has a function of making a call for notifying 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 the inquiry from the host device 30, or may be transmitted 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 apparatus 40 to the upper apparatus 30. As the contents of the notification, in addition to the operation log of the lower level device 40, for example, the count value of the image forming number counter in the case of an image forming apparatus, the measured value in the case of a weighing system, and the like can be considered. Since this notification is not urgent, it may be transmitted as a response to the inquiry from the higher-level device 30.
The certificate update unit 48 has a function of updating the certificate stored in the certificate storage unit 45 with the certificate received from the higher-level 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-described functional units 46 to 48. Examples of this operation include transmission of data stored in the lower level device 40 and control of the operation of the engine unit (not shown) as necessary.
The functions of these units are realized by the CPU of the lower level device 40 executing a required control program to control the operation of each unit of the lower level device 40. The status notification unit 46 and the log notification unit 47 are shown as specific examples of functions provided by the command receiving unit 49, and it is not essential to provide such functions.

FIG. 2 shows a functional configuration of a part that is a feature of this embodiment of the certificate management apparatus 20 as described above.
As shown in this figure, the certificate management apparatus 20 includes an HTTPS server function unit 21, an authentication processing unit 22, a certificate update unit 23, a certification key creation unit 24, a certificate issue unit 25, and a certificate management unit 26. I have.
The HTTPS server function unit 21 accepts a communication request from a device having the function of an HTTPS client, as in the HTTPS server function unit of the higher-level device 30 or the lower-level device 40, and performs an operation corresponding to the received request or data in each unit of the device. It has a function of executing and returning a response to the request source.

The function of the authentication processing unit 22 is the same as that of the authentication processing unit of the higher-level device 30 and the lower-level device 40. However, the certificate used for the authentication processing is stored in the certificate management unit 26. Types, uses and functions will be described later.
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 issuance unit 25 when a normal certificate issuance request is received from the higher-level device 30. The certificate management unit 26 has a function of transmitting it to the host device 30 via the HTTPS server function unit 21.

The certification key creation unit 24 has a root private key that is a certification private key used for creating a digital signature, and a certification public key (certification corresponding to the root private key for confirming the validity of the digital certificate). It has a function of a certification key creation means for creating a root key that is a key.
The certificate issuing unit 25 has a function of issuing a public key used for authentication processing according to the SSL protocol and a private key corresponding thereto to the certificate management apparatus 20 itself, the upper apparatus 30, and the lower apparatus 40. Further, a function of certificate issuing means for issuing a public key certificate which is a digital certificate by attaching a digital signature to each issued public key using the root private key created by the certification key creation unit 24. Have. Also, issuing a root key certificate with a digital signature attached to the root key is a function of the certificate issuing unit 25.

The certificate management unit 26 has a function of a certificate management unit that manages the digital certificate issued by the certificate issuing unit 25, the root private key used to create the certificate, and the root key corresponding to the root private key. These certificates and keys are stored together with information such as the expiration date, issue destination, ID, and presence / absence of update. In addition, the certificate and private key issued to itself have a function for use in authentication processing in the authentication processing unit 22.
The functions of these units are realized by the CPU of the certificate management device 20 executing a required control program to control the operations of the units of the certificate management device 20.

Next, characteristics and applications of each certificate and key used by each device described above for authentication processing will be described. 5A shows the types of certificates and keys stored in the certificate storage unit 45 of the lower level device 40, and FIG. 5B shows the certificates stored in the certificate storage unit 35 of the higher level device 30. It is a figure which shows the kind of book and a key. FIG. 6 is a diagram showing certificates and keys stored in the certificate management unit 26 of the certificate management apparatus 20 that are used for authentication processing in the certificate management apparatus 20.
The upper apparatus 30, the lower apparatus 40, and the certificate management apparatus 20 store regular authentication information and rescue authentication information roughly. Each of the regular authentication information and the rescue authentication information is composed of a public key certificate and a private key that are authentication information about itself, and a root key certificate that is authentication information about the communication partner.
Then, during normal communication, each device performs mutual authentication of the procedure as shown in FIG. 22 according to SSL or one-way authentication as shown in FIG. 24 using regular authentication information.

Further, for example, the low-level device normal public key certificate is a digital signature that can be verified with the normal public key issued by the certificate management device 20 to the low-level device 40 using the low-level device authentication normal root key. Is a digital certificate and corresponds to the first certificate.
Here, for example, the format of the public key certificate shown in FIG. 7 can be used. In addition to the public key itself, the issuer of the certificate, the expiration date of the certificate, the subject to be certified (the certificate Information such as the issuer's device or user) is described. Specifically, for example, X. The public key certificate created according to this format can be as shown in FIG. 8, for example.
In this example, A indicates CA identification information, and C indicates identification information of a certificate issuing device. These include information such as location, name, machine number or code, respectively. B indicates the effective period, and the effective period is designated by the start date and time and the end date and time. Further, D indicates the length of the public key included in the public key certificate (here, 1024 bits), and E indicates the algorithm (here, “md5WithRSAEncryption”) used by the CA for the digital signature.

Also, the private private key for the lower level device is a private key corresponding to the above normal public key, and the normal root key certificate for lower level device authentication is the root private key corresponding to itself as the normal root key for lower level device authentication. It is a digital certificate with a digital signature that can be verified by itself.
Even when a plurality of lower-level devices 40 are provided, the digital signature attached to the normal public key of each device is attached using the same root private key, and the normal root key certificate necessary for validity verification is made common. However, the normal public key included in the normal public key certificate and the private key corresponding thereto differ from device to device.
The normal public key certificate for the host device, the normal private key for the host device, and the normal root key certificate for the host device authentication have the same relationship, and the normal public key certificate for CA, the normal private key for CA, and the normal for CA authentication The root key certificate has the same relationship.
In order to enable each device to check the validity of public key certificates issued by a plurality of certificate authorities, it may be possible to store root key certificates corresponding to the respective certificate authorities. .

  For example, when the upper device 30 and the lower device 40 perform mutual authentication, in response to a communication request from the upper device 30, the lower device 40 uses the first private key for the lower device encrypted. The random number is transmitted to the higher-level device 30 together with the normal public key certificate for the lower-level device. The higher-level device 30 side first confirms the legitimacy of the lower-level device normal public key certificate (not damaged or tampered) using the lower-level device authentication normal root key certificate. The first random number is decrypted 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 surely the issuance destination of the normal public key certificate for the lower-level device. Can be identified. Then, the success or failure of authentication can be determined according to whether or not the identified device is suitable as a communication partner.

The lower device 40 also receives and stores the upper device normal public key certificate and the upper device normal private key encrypted random number transmitted when authentication is successful on the upper device 30 side. Similar authentication can be performed using the root key certificate for higher-level device authentication.
This procedure is a process in the case where the upper apparatus 30 requests communication to the HTTPS server function section 42 of the lower apparatus 40 by the HTTPS client function section 31, and the lower apparatus 40 uses the HTTPS client function section 41 to perform the communication. When the communication is requested to the HTTPS server function unit 32, the certificate and key to be used are the same, but the processes of the upper apparatus 30 and the lower apparatus 40 are reversed.
The same applies to the processing when the host device 30 and the certificate management device 20 communicate.

By the way, as described above, when each device receives a normal public key certificate from a communication partner, a root key (certificate) for confirming the validity of the public key certificate issued by the issuing certificate authority. ) Cannot be confirmed, the validity of the received normal public key certificate cannot be confirmed. Therefore, in this case, authentication cannot be performed.
If each device does not have a function (such as a module for realizing encryption / decryption) for authenticating with a normal public key certificate received from the communication partner, it goes without saying that the normal public key Certificate authentication is not possible. Such as when the certificate used for authentication processing is switched in the host device 30 or when the lower device 40 is connected to a communication system including the host device 30 using a certificate from a certificate authority different from the previous one. It is possible that a situation will occur.
This is because which authentication method is adopted and which certificate authority issues a certificate is appropriately determined by the operator of the communication system in consideration of various conditions. When a new method with high darkness intensity is put into practical use, it is conceivable that such a method is appropriately adopted at the discretion of the operator.

Here, if each device can only perform authentication using normal public key certificates (authentication using normal authentication information), authentication processing is not supported in this way, and the validity of the certificate can be confirmed. In such a situation, there is no way to send a normal public key certificate, a normal private key, and a normal root key certificate that can be used to the target device securely over the network. Become.
In addition, if the certificate expires without automatic renewal due to the device being turned off, or the certificate is damaged due to the power being turned off during the update process, etc. In such a case, a similar problem occurs.

  However, each communication device constituting the communication system of this embodiment stores rescue authentication information in order to cope with such a situation, and authenticates the communication partner using two different types of digital certificates. To be able to. Then, by using the rescue authentication information, a new normal public key certificate or the like can be safely transmitted to a necessary apparatus via the network.

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

Here, FIG. 9 shows an example of the normal public key certificate of the lower level apparatus 40, and FIG. 10 shows an example of the rescue public key certificate of the lower level apparatus 40.
These are public key certificates that have the same identification information of the issue destination device and are issued to the same device, as indicated by symbols H and M. In the normal public key certificate, the key length of the public key is 2048 bits as indicated by symbol I, whereas in the rescue public key certificate, the key length of the public key is 1024 bits as indicated by symbol N.

In other words, in a normal public key certificate, security is strengthened corresponding to an authentication process with higher encryption strength (here, an authentication process using a 2048-bit public key or a private key), while in a rescue public key certificate, Thus, authentication processing with lower encryption strength (here, authentication processing using a 1024-bit public key or private key) is made to correspond. In this way, even if the communication system does not support authentication processing with high encryption strength, if an appropriate root key certificate is stored in each device that can constitute the communication system, the rescue can be performed. Authentication processing using a public key certificate can be performed.
If such authentication is successful, the common key is shared with the communication partner as described above, and a secure communication path using common key encryption can be provided. Therefore, using this communication path, a new normal public key certificate suitable for the environment at the time of communication can be transmitted to the communication partner and set.

It should be noted that the encryption strength and the contents of the authentication process in the rescue public key certificate are assumed to use the lower-level device 40 even in consideration of the export regulations, the contents of the authentication process prevailing in each region, and the like. Authentication is performed by an authentication process that can be commonly used in various environments. By doing so, the rescue public key certificate (including the rescue authentication information) is used as authentication information for securing an emergency communication path when the authentication process using the normal public key certificate cannot be performed. Can be used.
Here, although the algorithm used for the digital signature is common to the normal public key certificate and the rescue public key certificate, they may be different.

  In addition, a rescue public key certificate that supports authentication processing with low encryption strength may be less secure and reliable than a normal public key certificate that supports authentication processing with high encryption strength. However, if authentication processing is performed using rescue authentication information, if only limited requests such as updating regular authentication information including normal public key certificates are permitted, this point will be It won't be a big problem.

Here, returning to the description of FIG. 9 and FIG. 10, in these two public key certificates, in the normal public key certificate, the issuer of the certificate is represented by the symbol “F” as “PublicCA” of YYY. On the other hand, in the rescue public key certificate, as indicated by the symbol K, “private CA” of XXX is used, and the issuer is set to a different CA. “PublicCA” corresponds to a public certificate authority, and “PrivateCA” corresponds to a private certificate authority.
A public certificate authority is a certificate authority that has been widely trusted by the public, a certificate authority that has been publicly recognized as reliable, a certificate authority that is legally recognized as having a valid certificate, etc. It shall refer to a certificate authority that can issue certificates that can be used effectively. Commercial services for issuing public key certificates by such public certificate authorities are provided by third party organizations such as VeriSign and Baltimore. In addition, the private certificate authority is not a certificate whose reliability is widely recognized, and it is assumed that the certificate issued is not generally valid. Here, the private certificate authority is provided by XXX, which is the manufacturer of the issuing device.

Since public key certificates issued by public certificate authorities are strictly managed and widely accepted for safety and reliability, it is recommended to use such certificates as normal public key certificates. . However, since public key certificates issued by public certificate authorities require strict management and security, certificates that can be used in various environments, such as rescue public key certificates, must be issued. Can be difficult and expensive.
On the other hand, since private certificate authorities can specify the specifications of certificates relatively freely, they can be used in various environments by reducing 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.

Further, for example, even when the manufacturer is different between the lower level device 40 and the higher level device 30, or the operator of the communication system performs various customizations, the rescue public key certificate is provided free of charge, etc. It becomes easy to encourage manufacturers and operators to support authentication using rescue public key certificates. Therefore, a certificate issued by a private certificate authority is adopted as the rescue public key certificate.
The rescue public key certificate issued by the private certificate authority may be inferior in safety and reliability when compared to the normal public key certificate issued by the public certificate authority. If the function permitted when the authentication process is performed using the rescue authentication information is limited, this is not a big problem.

Returning to the description of FIG. 9 and FIG. 10 again, in these two public key certificates, the normal public key certificate has a valid period from midnight on January 1, 2003, as indicated by symbol G. While one year from midnight on January 1, 2004 is assumed, in the rescue public key certificate, as indicated by the symbol L, from midnight on January 1, 2000 to midnight on January 1, 2050 For 50 years.
In other words, since a public certificate is usually issued by a public certificate authority, the manufacturer or user of the device cannot set the validity period freely, and the validity period is set short for safety reasons. It is usually done. Therefore, it is necessary to renew the certificate within the validity period. In an apparatus that needs to automatically renew a certificate, there is a risk of the certificate being damaged due to an overdue update period or an abnormality at the time of renewal.

  On the other hand, if the rescue authentication information is positioned as authentication information for securing an emergency communication path when authentication using the normal public key certificate cannot be performed, the rescue public key certificate will expire after the expiration date. Since it is no longer possible to authenticate with the public key certificate when the validity period of the normal public key certificate has passed, it is preferable that the rescue public key certificate has a longer validity period. Also, if an update is necessary, there is still a risk of overdue or damage, so it is preferable that the update is unnecessary.

Specifically, for example, an effective period longer than the product life of the device to be stored may be set. The product life is an assumed operation period or an assumed operation period of the apparatus, and can be determined from a use period assumed at the time of development, an assumed useful life, a quality assurance period of the apparatus, and the like.
In addition, if the validity period of the rescue public key certificate is set longer than the period during which it is assumed that the rescue public key certificate can be operated normally while maintaining the equipment, the rescue public key certificate will expire during the operation of the equipment. It can be said that there is no certificate. Therefore, during operation of the apparatus, it is possible to always maintain a state where authentication using the rescue public key certificate (authentication using the rescue authentication information) is possible. In addition, since it is not necessary to update the rescue public key certificate, it is possible to prevent damage during the update.

It is even better if an effective period that is much longer than the product life and the operation period of the apparatus is determined. In the example shown in FIG. 10, the validity period is set to 50 years, and this level is considered sufficient for a normal device. Since the maximum valid period that can be set according to the 509 format is 50 years, it is a matter of course that a longer period, for example, 100 years or hundreds of years may be set only by doing this. When the validity period is set in this way, the end of the validity period is simply described by a request in the format of the public key certificate, and the validity period of the rescue public key certificate is considered to be virtually unlimited. it can. In addition, depending on the target device, even when it is valid for about 20 years, 30 years or less, it may be considered in the same way.
Furthermore, even if the validity period of the rescue public key certificate is shorter than the product lifetime, if the validity period of the normal public key certificate is longer, the rescue public key certificate will be released for a certain period after the validity period of the normal public key certificate expires. It is possible to obtain an effect that it is possible to maintain a state where authentication using a key certificate is possible.

If the private certificate authority issues the rescue public key certificate, the validity period may be determined as appropriate by the issuer. Therefore, it is possible to determine the validity period to meet these requests. In addition, the public key certificate with a long validity period is slightly less secure than the public key certificate with a short validity period, but as described above, authentication was performed using the rescue public key certificate. By restricting the operations that are allowed to execute in this case, this point can be prevented from becoming a big problem.
Also, if an emergency communication path can be secured by using such a rescue public key certificate, even if a normal certificate with a high encryption strength and a short validity period is used, the authentication method is not supported. In addition, it is possible to minimize inconvenience due to expiration or damage during renewal, and even if the device is difficult to manually renew the certificate and has to rely on automatic renewal, the encryption strength is highly effective. A highly reliable certificate with a short period can be used effectively.

As described above, if the rescue public key certificate is stored in each communication device that can constitute 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 can be seen that the other party is the device assumed as the communication partner. It can be determined that there is an abnormality in the authentication used.

Also, if authentication using the rescue public key certificate fails, it can be seen that the other party is a device that is not supposed to be the communication partner, so the authentication using the normal public key certificate could not be performed normally. It can be determined that an abnormality has not occurred in the authentication because the communication partner was inappropriate. One of the features of this embodiment is that such a determination is made using two types of digital certificates, a normal public key certificate and a rescue public key certificate.
In addition, communication failure can be considered as a cause of authentication failure, but in this case, since the abnormality is known at the stage of receiving the certificate, etc., it should be distinguished from the case where the contents of the certificate etc. are inappropriate. Can do.

  By the way, when performing authentication processing according to the SSL protocol, the server cannot know the state of the client when a communication request is made from the client, and therefore, inevitably, a specific URL (Uniform Resource Locator) is used. When accessed, it always returns the same public key certificate. Therefore, basically, a single device has a plurality of public key certificates, and a communication partner selects and transmits an appropriate one according to the type of public key certificate to be used for authentication. It is not possible. However, in each apparatus 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 according to circumstances.

Therefore, next, the configuration for proper use will be described with reference to FIG. Although only the upper device 30 and the lower device 40 are shown in FIG. 11, the certificate management device 20 can have the same configuration.
As described above, the server can basically return only a specific public key certificate to a client requesting communication. However, when the address for receiving a communication request is different, a different public key certificate can be returned for each address. This address can be determined by a URL, for example.

  Therefore, as shown in FIG. 11, the upper device 30 and the lower device 40 are each provided with a normal URL that performs authentication using the normal public key certificate and a rescue URL that performs authentication using the rescue public key certificate. Is requested to selectively specify one of the URLs according to the type of authentication requested, and send a communication request. By changing the IP address or port number (whichever is acceptable), these URLs can be handled as URLs of physically different devices even if they are physically the same device URLs. ing. That is, it is for realizing the function of a so-called virtual server.

In this case, the communication request side (the side functioning 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 received by the normal URL. When the rescue URL is accepted, the rescue public key certificate can be returned.
Since the client requesting communication knows to which URL the communication request has been sent, when performing mutual authentication, an appropriate public key certificate corresponding to the URL may be selected and transmitted. it can.

  When the upper device 30 tries to authenticate the lower device 40, first, a communication request is transmitted to the normal URL and authentication using the normal public key certificate is attempted. If this fails, the rescue is now performed. A communication request is transmitted to the URL to perform authentication using the rescue public key certificate. If this is successful, an update certificate set is obtained from the certificate management apparatus 20 and transmitted to the lower apparatus 40 to request storage thereof. Even with authentication using a rescue public key certificate, the common key can be shared in the same way as with a normal public key certificate. Therefore, the certificate set must be 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 higher-level device authentication normal root key certificate 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 is a waste. Therefore, even when the lower level device 40 stores a normal public key certificate issued by a CA different from the CA supported by the higher level device 30, the higher level device 30 corresponds to the certificate set for update. The lower-level apparatus normal public key certificate issued by the CA and the upper-level apparatus authentication normal root key certificate are included. Therefore, a certificate or the like that can be used for authentication processing using an authentication method that can be used by the host device 30 is included.
Note that the public key body in the lower-level device normal public key certificate and the lower-level device normal private key are not only newly generated but also issued to the lower-level device 40 in the past by the certificate management device 20. If you manage the key, you can use it as it is. Also, when issuing a certificate set for renewal, a new root private key is issued, and the public key certificate is upgraded (a public key with a digital signature attached to the public key using the new root private key) It is conceivable to issue a certificate).

On the other hand, when receiving the request to store the certificate, the lower level device 40 causes the certificate update unit 48 to store the received certificate set in the certificate storage unit 45 and stores the previous regular authentication information. I try to update it.
If this update is performed normally, the low-level device 40 will again store the normal public key certificate within the valid period, and the authentication using the normal public key certificate can be performed. Therefore, after this, it is only necessary to perform communication using authentication using a 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 upper device authentication and the normal key for lower device authentication). The root key certificate may be the same). This is because the identification information of the device is attached to the public key certificate, so if the validity can be confirmed using the root key certificate, the device model and model number will be referred to by referring to the identification information. This is because it can be identified.

Next, processing relating to abnormality detection and certificate update using two types of certificates, such as a normal public key certificate and a 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 necessary control programs, respectively, and are processing according to the embodiment of the abnormality detection method and certificate transmission method of the present invention.
Note that these flowcharts show processing in a case where the upper device 30 requests the lower device 40 to communicate. Further, for the sake of simplicity of explanation, only the part in which the higher level device 30 authenticates the lower level device 40 using the public key certificate received from the lower level device 40 is shown as the authentication process (as shown in FIG. 24). However, it is also possible to send a public key certificate from the higher-level device 30 to the lower-level device 40 to perform bidirectional authentication as shown in FIG. Of course.

  When the host device 30 sends a request or notification to the lower device 40 or makes a communication request to receive a request or notification from the lower device 40, the host device 30 starts the processing shown in the flowchart of FIG. First, in step S101, a communication request is transmitted to the normal URL of the lower level 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.

Upon receiving the communication request, the lower level device 40 starts the processing shown in the flowchart of FIG. 14 and determines whether the URL requested for communication is a normal URL or a rescue URL in step S201.
If it is a communication request for a normal URL, the process proceeds to step S202 to determine whether or not a normal normal public key certificate is stored. Normally, as shown in FIG. 5 (a), a normal public key certificate (ordinary public key certificate for lower-level devices) should be stored, but it was accidentally erased or damaged during the update. This determination may be NO if the public key certificate is not stored at the time of product shipment. Even if the valid period has expired, if a normal public key certificate that is formally normal is stored, the determination in step S202 may be YES.

If stored in step S202, the normal public key certificate is transmitted to the higher-level device 30 together with the first random number encrypted with the normal private key (lower-level device normal private key) in step S203. This processing corresponds to the processing in steps S21 and S22 in FIG.
If not stored in step S202, a response indicating that the normal public key certificate cannot be transmitted is returned in step S211 and the process is terminated.

On the higher-level device 30 side, when either of these responses is received or when a predetermined time has elapsed, the process proceeds to step S102 to determine whether or not the lower-level device 40 has transmitted the public key certificate. And if it has transmitted, it will progress to step S103 and will perform an authentication process. For this authentication, a normal root key certificate for subordinate device authentication is used, and this processing corresponds to the processing in steps S12 and S13 in FIG. 22 or FIG. In the processing of steps S101 to S103, the CPU of the higher-level device 30 functions as a first authentication unit.
In step S104, it is determined whether or not the authentication is successful. If the authentication is successful, the process proceeds to step S113, where the common key seed is transmitted to the lower level device 40, and the common key is created and used for subsequent communication. To. This processing corresponds to the processing in steps S14 to S17 in FIG.

On the lower device 40 side, if the normal public key certificate is transmitted in step S203, the transmission waits in step S204, and if the common key seed is received, it is determined that the upper device 30 has been authenticated, and step S205 Proceed to to create a common key and use it for subsequent communications. These processes correspond to steps S23 to S26 in FIG. 22 or steps S25 and S26 in FIG.
On the host device 30 side, after step S113, a request (command) is transmitted to the lower device 40 together with necessary data in step S114, and a response is waited in step S115. Then, in step S116, it is determined whether or not all requests have been transmitted. If any request remains, the process returns to step S114 to repeat the process, and if all 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 upper device 30, and if received, the processing according to the request is performed in step S207 to the upper device 30. Returns a response. In step S208, it is determined whether there is information to be notified to the higher-level device 30, such as a call or a periodic notification. If there is information, the notification is transmitted in step S209. In step S210, it is determined whether or not the host device 30 has disconnected the communication. If the communication has not been disconnected, the process returns to step S206 to repeat the process. If the communication has been disconnected, the process ends.

On the other hand, if the authentication fails in step S104 in the process on the host device 30 side, the cause of the authentication failure is the public that did not correspond to the authentication processing method using the public key certificate received by the host device 30. The public key certificate that the CA that issued the key certificate did not match with the root key certificate and the validity could not be confirmed, and the public key certificate version did not match the root key certificate and the validity could not be confirmed The identification information attached to the public key certificate was not suitable as a communication partner, and the public key certificate was damaged or was trying to communicate with an unrelated device in the first place. It is conceivable.
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. If this determination is YES, processing is performed. finish. Note that there may be a case where it is better to end the processing at this point for other reasons. 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. In such a case, the process may be terminated at the time of step S105.

  The processing after step S106 is processing for storing the appropriate digital certificate in the communication partner when it is necessary to grasp the cause when authentication using the normal public key certificate cannot be performed normally. If the cause of the authentication failure in step S104 is that the identification information is inappropriate, it is clear that the certificate and the authentication process were normal, so there is no need to confirm again. In addition, even if the certificate is updated, the situation does not improve, and it is not necessary to perform the processing after step S106. In this case, it is preferable that communication is not requested thereafter for the URL to which a communication request is transmitted in step S101.

On the other hand, if the determination 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, and the process proceeds to step S106 to grasp the cause. Process. The same applies to the case where the lower level apparatus 40 has not transmitted the public key certificate in step S102.
In step S106, since it is known that communication using the normal URL is not possible, a communication request is transmitted to the rescue URL of the lower level device 40 this time.

  In this case, the lower-level device 40 starts the processing shown in the flowchart of FIG. 14 again, but the determination in step S201 is a rescue URL, and the process proceeds to step S212, where the rescue public key certificate for the lower-level device is assigned to the rescue private It is transmitted to the upper apparatus 30 together with the first random number encrypted with the key (rescue private key for the lower apparatus). This process also corresponds to the processes 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 updated after being stored at the time of manufacture of the device if the validity period is lengthened. If it is an appropriate device, an appropriate device should be stored.

  On the host device 30 side, when the certificate and the random number transmitted by the lower device 40 in step S212 are received in step S107, authentication processing is performed using them. For this authentication, a rescue root key certificate for subordinate device authentication is used, and this processing corresponds to the processing in steps S12 and S13 in FIG. 22 or FIG. 24 as in the case of steps S102 and S103. In addition, when not receiving within predetermined time after step S106, you may make it handle 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 unit.

In step S108, it is determined whether or not the authentication is successful. If the authentication is successful, the process proceeds to step S109 where the common key seed is transmitted to the lower level device 40 and the common key is created and used for subsequent communication. To. These processes correspond to the processes in steps S14 to S17 in FIG. 22 or 24 as in the case of steps S104 and S114.
The lower device 40 waits for this transmission in step S213 after step S212. If the common key seed is received, the lower device 40 determines that it has been authenticated by the upper device 30 and proceeds to step S214 to create a common key. To use for communication. These processes correspond to the processes in steps S23 to S26 in FIG. 22 or steps S25 and S26 in FIG. 24, as in steps S204 and S205.

  On the other hand, the higher-level device 30 determines that there is an abnormality in the authentication using the normal public key certificate with the lower level device 40 due to the successful authentication using the rescue public key certificate in step S108. In the process of step S108, the CPU of the host device 30 also functions as an abnormality detection unit. Then, in order to update the certificate of the lower level device 40, in step S110 after step S109, necessary information is transmitted to the certificate management device 20 to create a new certificate set for update, and this is acquired. However, this process will be described later in detail.

When acquiring the new certificate set from the certificate management apparatus 20, the upper level apparatus 30 transmits the new certificate set together with the certificate update request to the lower level apparatus 40 in step S111 and stores it (or did not exist). ) Request to update the regular authentication information to the contents of the new certificate set. In this process, the CPU of the host device 30 functions as a certificate transmission unit.
Then, in step S112, the process waits for a response from the lower level device 40, proceeds to step S117, disconnects communication, and ends the process. When transmitting a request or the like to be transmitted at the beginning, it is sufficient to start the process again. At this point, since authentication with a normal public key certificate should be possible, the process goes from step S104 to step S113. Then, it is possible to send a request to the lower level device 40 and execute an operation related thereto in the subsequent processing.

On the other hand, on the lower device 40 side, after step S214, the process waits for reception of a request in step S215. When the request is received, the process proceeds to step S216. As described with reference to FIG. 4, the request management unit 44 of the lower-level device 40 permits only the certificate update operation when authentication using the rescue public key certificate is performed. Therefore, it is determined whether or not the request received in step S216 is a certificate update 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 indicating that the request cannot be accepted may be returned.
If it is a certificate renewal request in step S216, the process proceeds to step S217, the new certificate set received together with the certificate renewal request is stored in the certificate storage unit 45, and the regular authentication information shown in FIG. The contents are updated, and the update result is notified to the transmission source as a response in step S218, and the process is terminated.

  Next, an example of a processing sequence in the case where the higher-level device 30 and the lower-level device 40 execute the processing illustrated in FIGS. 13 and 14 will be described including processing in the certificate management device 20. FIG. 15 and FIG. 16 show this processing sequence. Here, a processing example when the lower level apparatus normal public key certificate stored in the lower level apparatus 40 cannot be handled by the authentication process that can be executed by the higher level apparatus 30 is shown. As this cause, for example, it is conceivable that the lower-level device normal public key certificate is a certificate including a public key having a key length that cannot be handled by the higher-level device 30.

  In this example, first, the higher-level device 30 causes the HTTPS client function unit 31 to function as a lower-level device client and transmits 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 apparatus 40 side, and transmits this request to the authentication processing unit 43. Further, the subordinate apparatus 40 is requested to authenticate using the normal public key certificate. Then, the authentication processing unit 43 follows the SSL protocol, and the lower device normal disclosure stored in the certificate storage unit 45 together with the random number encrypted with the lower device normal private key stored in the certificate storage unit 45. The key certificate is returned to the higher-level device 30 (S302).

On the host device 30 side, this is passed to the authentication processing unit 33 to attempt authentication processing. However, since the authentication processing unit 33 cannot perform authentication processing using the received normal public key certificate for the lower device, authentication failure has occurred. (S303), an authentication failure response is returned to the lower level device 40 (S304). However, at this time, the higher-level device 30 cannot recognize whether or not the other party that requested the communication is really the lower-level device 40.
Since the cause of the authentication failure is that the validity of the public key certificate could not be confirmed, it is investigated whether 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 transmitted to the rescue URL (S305).

On the lower device 40 side, this request is transmitted to the authentication processing unit 43 as in 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 discloses the low-level device rescue release stored in the certificate storage unit 45 together with the random number encrypted with the low-level device rescue private key stored in the certificate storage unit 45. The key certificate is returned to the higher-level device 30 (S306).
On the higher-level device 30 side, this is passed to the authentication processing unit 33 to perform authentication processing. Here, since the lower-level device 40 is a device that can be a communication partner of the higher-level device 30, the rescue public key certificate for the lower-level device is authenticated. The processing unit 33 is of a format that can be handled in the authentication process, and can be verified using the lower-level device authentication rescue root key certificate stored in the higher-level device 30. Decryption can be performed without any problem, and it is determined that the authentication is successful (S307).

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

  The lower level device 40 passes this to the authentication processing unit 43 to decrypt the common key seed using the lower level device rescue private key. In the case of mutual authentication, the lower level device 40 further verifies the validity of the higher level device rescue public key certificate. After confirming using the root key certificate for host device authentication, authentication processing is performed by decrypting the second random number using the public key included therein. Since these operations can be normally performed here, it is determined that the authentication is successful (S309), and an 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 common key seed 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 partner who requested communication in step S301 can be a legitimate communication partner, and there is no abnormality in the course of communication and authentication processing. . On the other hand, in step S303, it is known that the authentication process failed not because of a communication abnormality or the like, and because it is known that the normal public key certificate received from the lower-level device 40 could not be handled in the authentication process. It is determined that the authentication using the key certificate has failed because an abnormality has occurred in the authentication due to the abnormality of the certificate that should be stored in the lower level device 40 (S311). In other words, it is a device that should normally succeed in authentication using a normal public key certificate, so there is an abnormality in the certificate (the certificate format and the encryption method adopted are It is determined that the authentication has failed because the certificate is not stored.

  Then, the processing proceeds to the subsequent processing shown in FIG. 16, causing the HTTPS client function unit 31 to function as a management device client, and the machine number and IP address of the lower level device 40 together with the normal certificate issuance request to the certificate management device 20. And the MAC address are transmitted to request creation of a new certificate set for the lower-level device 40 (S312). Here, the certificate management apparatus 20 that transmits the request is a certificate management apparatus 20 that issues a public key certificate that can be handled by the host apparatus 30 in the authentication process. Then, it may be the same CA as the CA that issued the public key certificate transmitted by the lower level device 40 during the authentication process or may be a different CA.

  The information transmitted to the certificate management device 20 may be stored in advance by the higher-level device 30 as communication partner information, or the lower-level device after successful authentication using the rescue public key certificate. You may make it acquire by transmitting to 40. The certificate set includes each certificate and private key shown in FIG. 12. However, when performing one-way authentication, a normal root key certificate for host device authentication is not necessary. Although not shown, when the host device 30 and the certificate management device 20 communicate with each other, the normal public key certificate is used for the SSL protocol as in the case where the host device 30 and the lower device 40 communicate. It is assumed that a request or the like is transmitted after the authentication process is performed and a secure communication path is established.

Upon receiving the request in step S312, the certificate management apparatus 20 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 creation time and ends after a predetermined period.
Since the certificate management apparatus 20 manages the version of the normal root key certificate for lower-level apparatus authentication stored in the higher-level apparatus 30, a digital signature that can confirm the correctness is attached with this root key certificate. Then, a normal public key certificate including a machine number as identification information of the lower device 40 can be created. In this case, the certificate management device 20 compares the machine number, IP address, and MAC address received from the host device 30 with the information managed by the certificate management device 20, and the device to which the normal public key certificate is issued is appropriate. It may be possible to confirm that this is true.

  If the certificate management device 20 also stores the public key and private key issued to the lower device 40, these keys themselves are not updated, and only a digital signature is changed to create a new certificate. It is also possible to do. Also, 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 You can create a certificate. At this time, a root private key used for the digital signature may be newly generated, and the root key certificate may be updated at the same time. Each new certificate and key created here is 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 certificate creation is completed, and whether there is a request from the certificate management device 20 to the host device 30. (S314). At this time, if the process of step S313 is completed, the certificate management apparatus 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-level apparatus 40 that stores the new certificate set. Is returned to the host device 30 (S315). That is, the upper apparatus 30 can acquire a new certificate set to be stored in the lower apparatus 40 together with the certificate setting request.

Upon receiving this request, the host device 30 transmits a new certificate set together with a certificate update request to the rescue URL of the designated IP address (S316). At this time, first, the MAC address may be acquired from the transmission destination, and the new certificate set may be transmitted after confirming that it matches the MAC address described in the certificate setting request.
On the other hand, the lower level device 40 transmits the received certificate update request from the HTTPS server function unit 42 to the request management unit 44, and the request management unit 44 causes the certificate update unit 48 to execute the certificate update process, and the certificate storage unit The regular authentication information stored in 45 is updated to the contents of the received new certificate set (S317). Then, a certificate update request response indicating the result of the update process is returned to the host device 30 (S318), and the host device 30 returns a response to the certificate setting request to the certificate management device 20 based on the response (S319). Then, the process is temporarily terminated.
Note that the communication between the higher-level device 30 and the lower-level device 40 is temporarily disconnected after step S310, and authentication is performed by transmitting a communication request to the rescue URL again when performing transmission in step S316. Good.

  By the way, although the subsequent processing is not shown in the flowcharts of FIGS. 13 and 14, when the certificate update as described above is completed, the lower-level device 40 functions as the HTTPS client function unit 41 as the client for the higher-level device. The communication request is transmitted to the normal URL of the higher-level device 30. Then, along with the certificate update result notification for notifying the result of the update process, the machine number, IP address, and version information of the updated certificate set are notified (S321). The host device 30 returns a response to this notification (S322). In this communication, authentication is normally performed using a public key certificate. However, if a certificate included in the new certificate set is used, this authentication can be performed without any problem.

Further, upon receiving the notification in step S321, the higher-level device 30 transmits a communication request to the normal URL of the lower-level device and performs a re-search for 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 normally performed even when communication is requested from the host device 30 side. The lower device 40 returns a response to this (S332).
Upon receiving this response, the host device 30 can confirm that the certificate update has succeeded, and as a result, the abnormality in authentication using the normal certificate has been resolved, and the certificate update result notification received in step S321 and its attachment Information is transmitted to the certificate management apparatus 20 to notify that the update process has been successful (S333). In response to this, the certificate management apparatus 20 returns a response (S334).

In the communication system shown in FIG. 1 and FIG. 2, when the version of the certificate constituting the regular authentication information in the lower level device 40 does not match that of the higher level device 30 and authentication cannot be performed normally, The device certificate is updated so that authentication can be performed normally.
In addition, when the host device 30 and the host device 40 having the above-described configuration execute the above processing, authentication is performed using a normal public key certificate when communication is normally requested, and the communication partner Can be established and a secure communication path can be established by SSL, but if authentication using a normal public key certificate is not successful, the encryption strength is higher than that of a normal public key certificate. Authentication using a rescue public key certificate that supports low authentication processing and can perform authentication processing in a wide range of environments. If this succeeds, authentication failure using a normal public key certificate is an authentication error. Can be determined to be the cause. Therefore, it is possible to quickly perform an operation for eliminating the abnormality.
Further, if only the authentication using the rescue public key certificate is successful, it is caused by an abnormality in the regular authentication information stored in the lower level device 40 including the normal public key certificate for the lower level device. Therefore, when authentication using the rescue public key certificate is successful, the higher-level device 30 acquires a new certificate set and sends it to the lower-level device 40 to update the normal authentication information. It can be solved.

  Rescue public key certificates that support authentication processing with a relatively low encryption strength are slightly less secure than normal public key certificates that support authentication processing with high encryption strength, but a considerable degree Can be secured. By preparing such a certificate, it can be placed in an environment that cannot be handled by the authentication using the set normal public key certificate, or the normal public key certificate can be used due to damage or expiration. Even if it is lost, there is an effect that a secure communication path using the common key cryptography can be secured in an environment where the rescue public key certificate can be used. Also, if it is a private certificate authority, a rescue public key certificate is issued that can be used in a wide range of environments, has a long validity period, does not expire, and does not require renewal and can prevent damage during renewal be able to.

  In addition, the authentication using the rescue public key certificate makes it possible to send a new certificate set after confirming that the destination is an appropriate device as a communication partner. It will not be stored in a new device. When mutual authentication is performed, the lower device 40 can also receive the new certificate set after confirming that the transmission source of the new certificate set is the upper device 30, so that an invalid certificate is stored as regular authentication information. There is no end. Furthermore, since authentication using a rescue public key certificate is possible even when authentication using a normal public key certificate cannot be performed, a new certificate set must be transmitted over a secure communication path using SSL. Therefore, the contents are not leaked to a third party, and security can be maintained.

Further, since the lower-level device 40 does not accept a request from the other party authenticated by using the rescue public key certificate, other than the certificate update request, other information is determined by the normal public key certificate. Access can be granted only to the appropriate communication partner who has been authenticated. Even if the rescue private key is illegally acquired within the validity period of the rescue public key certificate, important information is illegally accessed. Can be prevented.
According to this embodiment, since the public key certificate can be automatically updated, this embodiment can be applied to a device that cannot be updated by an operator at the installation site, such as a cable TV. The present invention is particularly effective when applied to a communication device having a communication partner such as a set-top box or an image forming device to be remotely maintained, or a communication system including such a communication device.

[Modifications of Embodiment: FIGS. 17 to 20]
Next, various modifications of the above-described embodiment will be described.
In the description so far, the example in which the normal authentication information of the lower level device 40 is updated when the authentication using the normal public key certificate cannot be normally performed and the authentication using the rescue public key certificate is successful has been described. The reason why the regular authentication information of the lower level device 40 is updated here is that, in the communication system of this embodiment, a plurality of lower level devices 40 can be connected to the higher level device 30 and can be attached and detached. This is because the number 40 is more difficult to manage, and the environment is likely to change so that the set normal public key certificate cannot be used.
However, since there are cases where the environment changes in the host device 30 or the encryption strength or the authentication processing method used by the host device 30 is changed, the host device 30 recognizes the normal authentication. An attempt to update information may be made.

An example of the processing sequence in this case is shown in FIG.
In this case, first, the HTTPS client function unit 31 is caused to function as an anti-CA client, and its own machine number information is transmitted to the certificate management apparatus 20 together with the normal certificate issuance request. The creation of a document set is requested (S401). Even at this time, authentication processing according to the SSL protocol is performed using a normal public key certificate, and a request or the like is transmitted after establishing a secure communication path. However, there is an abnormality in the regular authentication information of the host device 30. In some cases, this authentication cannot be performed normally. Although illustration is omitted, in such a case, the rescue URL of the certificate management apparatus 20 is accessed and authentication using the rescue public key certificate is performed.

  Upon receiving the request in step S401, the certificate management apparatus 20 creates a certificate set and its setting request (S402), but the public key and private key issued by the certificate management apparatus 20 to the host apparatus 30 Any version of the certificate can be created as long as all versions of the private root key and root key used in the past are stored, but the latest version of the certificate may be created. The new certificates and keys created here are also stored and managed in the certificate management unit 26 as in the case of 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 certificate creation is completed, and whether there is a request from the certificate management device 20 to the higher-level device 30. (S403). At this time, if the process in step S402 is completed, the certificate management apparatus 20 returns a new certificate set together with the certificate update request to the host apparatus 30 as a response to the communication request (S404).
Upon receiving this request, the host device 30 updates the regular authentication information stored in the certificate storage unit 45 to the content of the received new certificate set (S405), and a certificate update request response indicating the result of the update process. Is returned to the certificate management apparatus 20 (S406). In response to this, the certificate management apparatus 20 returns a notification that a response has been received (S407).

  Through the above processing, the regular authentication information of the higher-level device 30 can be updated as in the case of the lower-level device 40. However, since the normal public key certificate is changed by this update, the normal public key certificate is not updated before the update. There is a possibility that this authentication cannot be normally performed with the lower-level device 40 that has been able to perform authentication using the. Therefore, communication is requested for the normal URL of each subordinate device 40, and the subordinate device is re-searched (S408). Then, authentication is performed using the normal public key certificate transmitted as a response by the lower level device 40. For the lower level device 40 in which this authentication cannot be normally performed, the same as in step S305 and subsequent steps in FIG. 15 and FIG. The regular authentication information including the normal public key certificate is updated by performing processing (S409).

When such search and update for all the lower devices 40 are completed, the upper device 30 is again in a state where it can authenticate all the lower devices 40 using the normal public key certificate. Therefore, by performing such processing, even when an abnormality in authentication using the normal public key certificate is caused by an abnormality in the regular authentication information of the host device 30, this abnormality can be resolved.
Also, FIG.
The re-search as shown in and after step S408 may be performed regardless of the certificate update of the higher-level device 30. Through such processing, the success or failure of the authentication using the normal public key certificate is periodically checked, and when there is an abnormality, the normal public key certificate of the lower level device 40 is updated and each device of the communication system It is possible to maintain a state in which a communication partner can be authenticated using a normal public key certificate.

  Furthermore, if this search is performed not only on the IP address of the device stored as the communication partner but also on the entire range of the specified IP address, even when a new subordinate device 40 is connected, Can be detected and authentication using a normal public key certificate is possible. Even if the normal public key certificate is not stored in the lower level device 40 at the time of manufacture, if the authentication using the rescue public key certificate is successful, the certificate management device 20 receives the normal public key certificate for the lower level device. Can be issued and stored.

Therefore, if such a search is used, only the rescue authentication information is stored in the lower level device 40 at the time of manufacture in the factory and shipped, and the network is installed after the device is installed at the customer site and connected to the higher level device 30. It is also possible to distribute regular authentication information through the storage 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 updated (or newly stored). This can be considered as part of the operation of storing a new normal public key certificate in the device 40.

In the above-described embodiment, an example in which a communication request is made from the higher-level device 30 to the lower-level device 40 has been described. However, this is not essential. That is, similar processing is possible even when communication is performed from the lower device 40 to the higher device 30.
18 to 20 show the processing sequence of the part corresponding to FIG. 15 in such a case. However, in FIG. 18 to FIG. 20, the sequence is shown more simplified than in the case of FIG.

First, FIG. 18 shows that the lower level device 40 requests communication to the higher level 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 level device 40 requests communication with a normal URL so as to perform normal communication with the higher level device 30 (S501), a normal public key certificate is sent between the higher level device 30 and the lower level device 40 accordingly. The used authentication process is performed (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. In this example, since the lower-level device 40 corresponds to the client, the processing in the case of performing one-way authentication is slightly different from that shown in FIG. 24. However, the lower-level device 40 uses its own private key to generate a random number. Is transmitted to the host device 30 together with the public key certificate, and after verifying the validity of the public key certificate on the host device 30 side, the random number is decrypted and authenticated. Good.

  When the host 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 low order apparatus 40 that has received this response next requests communication with the rescue URL of the high order apparatus 30 (S505). Then, an 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 step S311 of FIG. Is determined to be due to an abnormality in authentication due to an abnormality in the certificate that should be stored in the lower level device 40 (S508). Then, the process shown in FIG. 16 is executed to update the regular authentication information of the lower level device 40.

Further, FIG. 19 shows that when the authentication using the normal public key certificate is performed, the lower apparatus 40 requests communication to the upper apparatus 30, and when the authentication using the rescue public key certificate is performed. An example in which communication is requested from the upper apparatus 30 to the lower apparatus 40 is shown.
In this case, the processing in steps S511 to S514 is the same as in the case of steps S501 to S504 in FIG. 18, but when the upper device 30 returns an authentication failure response to the lower device 40, the higher device 30 then enters the rescue URL of the lower device 40. Communication is requested to the terminal (S515). Then, an authentication process using the rescue public key certificate is performed (S516), and if it is determined that the authentication is successful (S517), the authentication using the normal public key certificate has failed as in step S311 of FIG. Determines that there is an abnormality in authentication due to an abnormality in the certificate that should be stored in the lower level device 40 (S518). Then, the process shown in FIG. 13 is executed to update the regular authentication information of the lower device 40.

Also, in FIG. 20, in the case of performing authentication using a normal public key certificate, the host device 30 requests communication to the lower device 40 and performs authentication using the rescue public key certificate. Shows an example in which communication is requested from the lower level device 40 to the higher level device 30.
In this case, when the host device 30 requests communication to a normal URL so as to perform normal communication with the lower device 40 (S521), a normal public key certificate is sent between the host device 30 and the lower device 40 accordingly. The used authentication process is performed (S522). The contents of the authentication process may be mutual authentication as shown in FIG. 22 or one-way authentication as shown in FIG.

  When the upper device 30 determines that the authentication in step S522 has failed (S523), an authentication failure response is transmitted to the lower device 40 (S524). When the lower device 40 receives this response, the lower device 40 requests communication to the rescue URL of the upper device 30 (S525). Then, an 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 step S311 of FIG. It is determined that the authentication failed due to an abnormality in authentication due to an abnormality in the certificate that should be stored in the lower level device 40 (S528). Then, the process shown in FIG. 16 is executed to update the regular authentication information of the lower level device 40.

  Even when any of the sequences shown in FIGS. 18 to 20 as described above is adopted, the rescue public key certificate is used when the authentication using the normal public key certificate fails as in the above-described embodiment. If the authentication used is successful and the authentication succeeds, it can be determined that the authentication failure using the normal public key certificate is caused by an abnormal authentication. Accordingly, the upper device 30 acquires a new certificate set, transmits it to the lower device 40, and updates the regular authentication information, so that the abnormality can be quickly resolved.

Further, it may be possible to change which device makes a communication request according to circumstances. For example, when the authentication using the normal public key certificate fails, the upper apparatus 30 requests communication to the rescue URL of the lower apparatus 40, or a response that the authentication using the normal public key certificate has failed. If the lower-level device 40 requests communication to the rescue URL of the higher-level device 30, the subsequent processing is the same regardless of which device is used for communication to the first normal URL. Can proceed.
Note that the communication in step S316 of FIG. 16 relating to the transmission of the new certificate set is also performed by making a communication request from the lower apparatus 40 side and transmitting a certificate update request in response to the communication request from the upper apparatus 30 side. Also good.

Further, in each of the above-described embodiments, the example in which the certificate management apparatus 20 creates a root key and a digital certificate by itself has been described, but the functions of the certification key creation unit 24 and the certificate issue unit 25 illustrated in FIG. May be provided in a device different from the certificate management device 20, and the certificate management device 20 may obtain a root key and a digital certificate from the device.
In particular, when using a public key certificate issued by a public certificate authority, the host apparatus 30 directly requests the public certificate authority to issue a certificate, and the certificate management is also the certificate authority. A configuration in which a certificate authority is requested to issue a certificate via a device that manages certificates issued in between is preferable to leaving it to the device 20.

In addition, since the rescue public key certificate has a long validity period, if the rescue root private key is leaked, it becomes extremely difficult to maintain the safety of communication. Therefore, it is necessary to maintain confidentiality particularly strictly. For this reason, it is preferable to use a certificate management apparatus that cannot be accessed from the outside and that can communicate with only a factory having a process for storing certificates, for example, with a dedicated line, with an emphasis on safety.
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. Certificate management devices may be divided according to the type of device to be issued.

Further, in the above-described embodiment, the example using the normal public key certificate corresponding to the authentication process with higher encryption strength and the rescue public key certificate corresponding to the authentication process with lower encryption strength has been described. Can be regarded as a certificate with high security strength, and the latter as a certificate with relatively low security strength.
Generally, a certificate with high security strength needs to contain a lot of information, and there are restrictions on exports or special authentication processing programs, so the usable environment is limited. In some cases, it is difficult to store all devices in the same way and use them for authentication processing. On the other hand, if the certificate has a low security strength, there are few such restrictions, and it is considered that it is relatively easy to store the same in all devices and use it for the authentication process.

Therefore, there is a demand for manufacturing and selling a device that stores a certificate having a low security strength, and subsequently storing a certificate having a high security strength in accordance with the usage environment. For example, it may be possible to improve security by devising various authentication processing contents or selecting a highly reliable CA by the system operator. When moving from the system to another system (including the case of simply changing the setting), it may be necessary to replace the certificate used for normal authentication processing. In addition, it is possible that a defect is found in a high-security certificate later and it is necessary to change the authentication processing method.
In such a case, using the processing of the above-described embodiment, if authentication using a high-security certificate fails, authentication using a low-security certificate is performed, and if this succeeds, high-security is performed. It is determined that the authentication failure using the certificate is caused by an authentication error, and the higher-level device 30 acquires a certificate set including a high-security certificate, transmits the certificate set to the lower-level device 40, and stores this certificate set. As a result, it is possible to store a certificate suitable for the use scene in the apparatus after being installed at the customer site while ensuring a certain degree of safety.

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 performs 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 effects as in the above-described embodiment can be obtained.
TLS (Transport Layer Security) improved from SSL is also known, but it is naturally applicable to the case where authentication processing based on this protocol is performed.

  In the above-described embodiment, the example in which the certificate management device 20 is provided separately from the host device 30 has been described, but this does not prevent the certificate management device 20 from being provided integrally therewith. In this case, components such as a CPU, a ROM, and a RAM for realizing the function of the certificate management device 20 may be provided independently. The certificate management apparatus 20 may be caused 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 therewith, a process for causing the hardware to function as the certificate management device 20, and hardware are included. It is assumed that inter-process communication with a process for causing the host device 30 to function is included.
Further, in each of the above-described embodiments, the example in which the certificate management apparatus 20 creates a root key and a digital certificate by itself has been described, but the functions of the certification key creation unit 24 and the certificate issue unit 25 illustrated in FIG. May be provided in a device different from the certificate management device 20, and the certificate management device 20 may obtain a root key and a digital certificate from the device.

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

The same applies to the rescue authentication information of the host device 30 and the rescue authentication information of the certificate management device 20.
In order to unify the data format with the normal public key certificate, for example, in the format shown in FIG. 8, the “Subject” item is left blank, or only the vendor name is entered and 0 is entered as the machine number. It may be possible to indicate that the certificate is a rescue public key certificate.

In this way, since the rescue authentication information is common to all devices of the same rank, it is possible to store information corresponding to the rank determined according to the model when the device is manufactured. In other words, it is not information with device identification information, so it is not necessary to prepare and store individual certificates for each device with an identification number after completing the inspection process. Can be memorized by simple work. For example, rescue authentication information is included in the master of the control program, and the rescue authentication information is stored together when the control program is copied to the apparatus.
If you set a sufficiently long validity period for the rescue public key certificate, you do not need to update the rescue authentication information after that, and the normal public key certificate expires as described above. Even when authentication by certificate cannot be performed, 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 communication partner device cannot be specifically identified 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 certain vendor applies to all devices corresponding to the lower level device 40 among its own products to the lower level device rescue authentication information (lower level device rescue public key certificate, lower level device rescue private key and higher level device authentication rescue root key). Certificate) is stored, and all the devices corresponding to the higher-level device 30 that is the communication partner of the higher-level device rescue authentication information (high-level device rescue public key certificate, higher-level device rescue private key, and lower-level device authentication rescue) If the root device 40 is stored, if the authentication process is successful, the lower level device 40 obtains a public key certificate whose validity can be confirmed with the stored higher level device authentication rescue root key certificate. It is possible to recognize that the sending partner is the host device 30 of the same vendor, and conversely, the host device 30 also stores itself. Partner which has transmitted the public key certificate that can verify the validity skew root key certificate can recognize that it is a lower-level device 40 of the same vendor.

And if such authentication is successful, it is possible to share a common key with a communication partner as described above and provide a secure communication path using common key encryption. It is also possible to specify a communication partner by exchanging. The same can be done between the certificate management device 20 and the host device 30.
It is also conceivable that the identification information of the device is not included in the normal public key certificate as well. Even if it does in this way, it is thought that security is high because the encryption strength of the corresponding authentication processing is high. Further, if the validity period is shorter than that of the rescue public key certificate, it is possible to increase the security compared to the rescue public key certificate.
Further, the validity period of the normal public key certificate and the rescue public key certificate and the certificate authority that issues them are not particularly limited to the above-described relationship. Conversely, the encryption strength is also considered as one element of security level, and the difference between the normal public key certificate and the rescue public key certificate is determined depending on the certificate authority, validity period, presence / absence of device identification information, etc. It is also possible.

  Further, the program according to the present invention includes a high-order device 30 or a low-order device, which is a communication device that includes a computer and includes a communication unit and authenticates a communication partner using a digital certificate at the time of communication or a communication device serving as the communication partner. 40 is a program for causing the computer to function as an apparatus 40. By causing the computer to execute such a program, the above-described effects can be obtained.

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

As has been described above, the communication apparatus of the present invention, a communication system, using the communication method or program, and the communication partner by using a certificate when communicating constructed using a communication device or such a communication apparatus authenticating in the communication system, it is possible to be able to be easily restored to the state capable of performing normal authentication in case the abnormality in the authentication using the certificate has occurred.
Accordingly, the present invention, such a communication system or, by applying to a communication device constituting the communication system, it is possible to construct a high-security communication system.

It is a functional block diagram which shows the function structure of the part relevant to the characteristic of this invention about the high-order apparatus and low-order apparatus which are the embodiment of the communication apparatus of this invention which comprises the communication system which is embodiment of this invention. FIG. 2 is a functional block diagram showing a functional configuration of a part related to the feature of the present invention with respect to the certificate management apparatus capable of communicating with the host apparatus shown in FIG. 1. FIG. 3 is a block diagram illustrating a hardware configuration of the certificate management apparatus illustrated in FIGS. 1 and 2. FIG. 3 is a diagram for explaining criteria for determining whether a request is permitted or not in the request management unit of the lower-level device illustrated in FIGS. 1 and 2; FIG. 3 is a diagram for describing authentication information stored in a higher-level device and a lower-level device illustrated in FIGS. 1 and 2. It is a figure for demonstrating the authentication information which a certificate management apparatus similarly memorize | stores. It is a figure for demonstrating the example of a format of a normal public key certificate. It is a figure which shows the example of the general public key certificate produced according to the format described in FIG. Similarly, it is a figure which shows the example of a normal public key certificate for contrast with a rescue public key certificate. Similarly, it is a figure which shows the example of a rescue public key certificate for contrasting with a normal public key certificate.

FIG. 3 is a diagram for explaining a configuration for a host device and a lower device shown in FIGS. 1 and 2 to use a normal public key certificate and a rescue public key certificate properly. FIG. 3 is a diagram illustrating a configuration example of a certificate set that is transmitted from a higher-level device to a lower-level device when updating the regular authentication information of the lower-level device in the communication system illustrated in FIGS. 1 and 2. It is a flowchart which shows the example of the process which a high-order apparatus performs among the processes regarding the update of the certificate using two types of certificates, a normal public key certificate and a rescue public key certificate, in the communication system. It is a flowchart which shows the example of the process which a low-order apparatus similarly performs. It is a figure which shows the example of a process sequence at the time of performing the process shown in FIG.13 and FIG.14 in the communication system. It is a figure which shows the continuation. It is a figure which shows the example of a process sequence in case the high-order apparatus updates its own regular authentication information in the communication system. FIG. 16 is a simplified diagram showing a modification of the processing sequence shown in FIG. 15. It is a figure which shows the further another modification. It is a figure which shows the further another modification. It is a figure for demonstrating the structure at the time of providing the low-order apparatus with respect to the communication system. It is a figure which shows the flowchart of the process performed in each apparatus when two communication apparatuses perform mutual authentication according to SSL with the information used for the process. It is a figure for demonstrating the relationship between the root key, root private key, and public key certificate in the authentication process shown in FIG. It is a figure corresponding to FIG. 22 which shows the process performed in each apparatus when two communication apparatuses perform one-way authentication according to SSL.

Explanation of symbols

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 unit 22, 33, 43: Authentication processing unit 23, 48: Certificate update unit 24: Certification key generation unit 25: Certificate issuing unit 26: Certificate management unit 30: High-order device 31, 41: HTTPS client function unit 34: Certificate update request unit 35, 45: Certificate storage unit 40: Low-order device 44: Request management unit 46: Status notification unit 47: Log notification unit 49: Command reception unit

Claims (13)

A communication device that communicates with a partner device via a network,
A first authentication means for authenticating the counterpart device using the first certificate received from the counterpart device when communicating with the counterpart device;
When the authentication by the first authentication unit fails, the other party is received using the second certificate received from the counterpart apparatus and having a lower cryptographic strength than the first certificate. A second authentication means for authenticating the destination device;
When authentication by the second authentication unit is successful, a certificate update request for updating the first certificate and a certificate for updating the first certificate are transmitted to the counterpart device. And a transmission means. The communication device according to claim 1,
When authentication by the second authentication means is successful, a request is made to issue a certificate for updating the first certificate to be sent to the counterpart device to a predetermined certificate management device. A communication apparatus comprising means for obtaining a certificate for updating the first certificate from the certificate management apparatus. A communication device that communicates with a partner device via a network,
Storage means for storing a first certificate and a second certificate having a cryptographic strength lower than that of the first certificate for use in authentication processing;
A first transmission means for transmitting the first certificate to the counterpart device when communicating with the counterpart device;
Second transmitting means for transmitting the second certificate to the counterpart device when authentication with the counterpart device using the first certificate transmitted by the first transmitter means fails. When,
Certificate update requesting renewal of the first certificate from the counterpart device when the authentication at the counterpart device using the second certificate transmitted by the second transmitter is successful. Update means for receiving a request and a certificate for updating the first certificate, and updating the first certificate stored in the storage means to the received certificate is provided. A communication device. The communication device according to claim 3,
Allow only the certificate update request among the requests from the counterpart device when the authentication at the counterpart device using the second certificate transmitted by the second transmission means is successful. A communication device. The communication device according to claim 3 or 4,
A communication apparatus, wherein a certificate for updating the first certificate received by the updating means is transmitted together with the certificate update request. A communication system comprising an upper device and a lower device, wherein the upper device and the lower device communicate via a network,
In the subordinate device,
Storage means for storing a first certificate and a second certificate having a cryptographic strength lower than that of the first certificate for use in authentication processing;
First communication means for transmitting the first certificate to the host device when communicating with the host device;
A second transmission unit configured to transmit the second certificate to the higher-level device when authentication by the higher-level device using the first certificate transmitted by the first transmission unit fails;
A certificate renewal request for requesting renewal of the first certificate from the high order apparatus when the authentication at the high order apparatus using the second certificate transmitted by the second sending means is successful; and Updating means for receiving a certificate for updating the first certificate and updating the first certificate stored in the storage means to the received certificate;
In the host device,
A first authentication means for authenticating the lower-level device using the first certificate received from the lower-level device when communicating with the lower-level device;
A second authentication unit that authenticates the lower-level device using the second certificate received from the lower-level device when authentication by the first authentication unit fails;
When authentication by the second authentication unit is successful, a certificate update request for updating the first certificate and a certificate for updating the first certificate are transmitted to the lower-level device. A communication system comprising a transmission unit. The communication system according to claim 6,
When the authentication by the second authentication means is successful in the higher-level device, a certificate for updating the first certificate to be transmitted to the lower-level device to a predetermined certificate management device A communication system comprising means for requesting issuance and obtaining a certificate for updating the first certificate from the certificate management apparatus. The communication system according to claim 6 or 7,
The lower device, when the authentication with the upper device using the second certificate transmitted by the second transmission means is successful, only the certificate update request among the requests from the upper device. A communication system characterized by allowing A communication system according to any one of claims 6 to 8,
The transmission means of the upper device transmits a certificate for updating the first certificate together with the certificate update request to the lower device,
A communication system, wherein a certificate for updating the first certificate received by the updating unit of the lower-level device is transmitted together with the certificate update request. To the communication device that communicates with the other device via the network,
A first authentication procedure for authenticating the counterpart device using the first certificate received from the counterpart device when communicating with the counterpart device;
When the authentication by the first authentication procedure fails, the other party is received by using the second certificate received from the partner apparatus and having a lower cryptographic strength than that of the first certificate. A second authentication procedure for authenticating the destination device;
When authentication by the second authentication procedure is successful, a certificate update request for updating the first certificate and a certificate for updating the first certificate are transmitted to the counterpart device. A communication method characterized by causing a transmission procedure to be executed. A communication device that communicates with a counterpart device via a network, and stores a first certificate and a second certificate having a cryptographic strength lower than that of the first certificate. In a communication device having storage means,
A first transmission procedure for transmitting the first certificate to the counterpart device when communicating with the counterpart device;
A second transmission procedure for transmitting the second certificate to the counterpart device when authentication with the counterpart device using the first certificate transmitted in the first transmission procedure fails. When,
Certificate update requesting update of the first certificate from the counterpart device when the authentication at the counterpart device using the second certificate transmitted in the second transmission procedure is successful Receiving a request and a certificate for updating the first certificate, and executing an update procedure for updating the first certificate stored in the storage means to the received certificate. Communication method. A computer that controls a communication device that communicates with a partner device via a network;
A first authentication means for authenticating the counterpart device using the first certificate received from the counterpart device when communicating with the counterpart device;
When the authentication by the first authentication unit fails, the other party is received using the second certificate received from the counterpart apparatus and having a lower cryptographic strength than the first certificate. A second authentication means for authenticating the destination device;
When authentication by the second authentication unit is successful, a certificate update request for requesting the update of the first certificate and a certificate for updating the first certificate are transmitted to the counterpart device. A program for functioning as a transmission means. A communication device that communicates with a counterpart device via a network, and stores a first certificate and a second certificate having a cryptographic strength lower than that of the first certificate. A computer for controlling a communication device having storage means;
A first transmission means for transmitting the first certificate to the counterpart device when communicating with the counterpart device;
Second transmitting means for transmitting the second certificate to the counterpart device when authentication with the counterpart device using the first certificate transmitted by the first transmitter means fails. When,
Certificate update requesting renewal of the first certificate from the counterpart device when the authentication at the counterpart device using the second certificate transmitted by the second transmitter is successful. A program for receiving a request and a certificate for updating the first certificate, and causing the first certificate stored in the storage unit to function as an updating unit that updates the received certificate.

Images