JP2005130445A - Communication apparatus, communication system, fault detecting method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a communication system capable of easily and quickly recognizing occurrence of a fault when authentication using a digital certificate is failed. <P>SOLUTION: A communication apparatus provided with a communication means and which uses two kinds of the digital certificates to authenticate a communication party in communication, authenticates the communication party by using a regular public key certificate whose valid term is shorter in the two kinds of the digital certificates (S102), uses a rescue public key certificate whose valid term is longer in the two kinds of the digital certificates to authenticate the communication party when the authentication using the regular public key certificate is failed (S106), and discriminates that the authentication using the regular public key certificate is faulty when the authentication using the rescue public key certificate is successful. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention includes a communication device that includes communication means and authenticates a communication partner using a digital certificate at the time of communication, a communication device that is a communication partner of such a communication device, and a host device that is such a communication device. The present invention relates to a communication system constituted by lower-level devices that are communication partners, an abnormality detection method for detecting an abnormality in authentication in these communication devices or communication systems, and a program for causing a computer to function as the communication device.

  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 this 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, as a third-party organization that issues such public key certificates, the owner of the private key is confirmed, the public key corresponding to the private key is digitally signed, and the public key certificate is issued Commercial services are provided by VeriSign and Baltimore, for example. Public key certificates issued by highly reliable third-party organizations in which a system for issuing public keys is strictly managed including private keys are widely used for authentication. There is also a demand for using a public key certificate issued by a highly reliable third party when performing authentication using a digital certificate.

Furthermore, when using such a public key certificate issued by a third party organization, the root key for confirming the contents of the digital signature by the main third party organization is Internet Explorer (registered trademark) or Netscape ( Since it is embedded in a general web browser such as a registered trademark in advance, there is an advantage that the operator of the web browser does not need to obtain and set a new root key.
Even if the device does not have a root key set in advance, it is easy for the user to agree to the setting of the root key if it is of a highly reliable third party, and if the root key is obtained and set An apparatus having a public key certificate issued by the same third party has the advantage that it can be authenticated regardless of the vendor of the apparatus itself. Therefore, when it is desired to connect a device manufactured by one company to a device manufactured by another company, it is effective to use a public key certificate issued by a third party organization. There is also a demand from the user side of the apparatus to use such a public key certificate.

By the way, in order to improve safety, such a third party organization sets a valid period for the public key certificate to be issued. In addition, this period is usually several years, and is often as short as 1 to 3 years. In the above authentication process, a public key certificate whose validity period has passed is not recognized as a valid public key certificate. Therefore, it is necessary to update to a new one before the validity period expires.
However, it is conceivable that the device may be powered off or an error may occur during the update, and the update may fail and the key or certificate may be damaged. Such danger increases as the validity period of the certificate is short and renewal is frequently performed.

If the public key certificate is damaged, authentication from the communication partner cannot be performed. However, from the viewpoint of the communication partner, handling in the case of such authentication failure becomes a problem. In other words, if the other party trying to communicate with is a device that is inappropriate as the other party and does not store the appropriate key or certificate, authentication will of course fail, but the key or certificate will be used due to damage, etc. It is difficult to distinguish from the case where it becomes impossible.
In the latter case, it is necessary to quickly recover the key or certificate and return to a state where authentication is possible. However, whether the authentication failure is because the communication partner is an inappropriate device and the appropriate key or certificate is not stored from the beginning, or because the key or certificate is lost as a result of damage. Since the distinction cannot be made, it has been difficult to automatically restore only in the latter case.

Therefore, when there is an inquiry from a user of a device that is unable to receive authentication, or when it is discovered that there is a device that has not been able to communicate for a long time, the key or certificate for that device has been damaged, etc. We will take measures such as dealing with the possibility. Therefore, there has been a problem that an abnormal authentication due to a certificate breakage or the like cannot be recognized quickly, and a state in which an appropriate device cannot be authenticated as a communication partner is left for a long period of time.
The present invention solves such a problem, and a communication apparatus that authenticates a communication partner using a digital certificate at the time of communication, or an authentication using a digital certificate in a communication system configured using such a communication apparatus. The purpose is to be able to recognize this easily and promptly when an abnormality occurs.

  In order to achieve the above object, a communication apparatus according to the present invention includes a communication unit, and authenticates a communication partner using two types of digital certificates in which different valid periods are set during communication. The first authentication means for authenticating the communication partner using the short-term certificate with the shorter valid period set out of the two types of digital certificates, and the authentication by the means cannot be performed normally In addition, a second authentication unit that performs authentication using a long-term certificate having a longer valid period among the two types of digital certificates, and the short-term certificate when authentication by the unit is successful And an abnormality detecting means for determining that there is an abnormality in the authentication using the certificate.

  Further, in a communication apparatus that includes a communication unit and authenticates a communication partner using a digital certificate at the time of communication, the short-term certificate that is a digital certificate whose validity period is shorter than the product life of the communication partner is used. Authentication using a first authentication means for authenticating a communication partner and a long-term certificate that is a digital certificate having a longer validity period than the product life of the communication partner when authentication by the means is not performed normally And an abnormality detection means for determining that there is an abnormality in the authentication using the short-term certificate when the authentication by the means is successful.

  Alternatively, in a communication apparatus that includes a communication unit and authenticates a communication partner using a digital certificate during communication, the communication is performed using a short-term certificate that is a digital certificate that expires during operation of the communication partner. Authentication is performed using a first authentication means for authenticating the other party, and a long-term certificate that is a digital certificate that does not expire during the operation of the communication partner when the authentication by the means cannot be performed normally. Second authentication means to perform and abnormality detection means for judging that there is an abnormality in the authentication using the short-term certificate when authentication by the means is successful.

Alternatively, in a communication apparatus that includes a communication unit and authenticates a communication partner using a digital certificate at the time of communication, the communication partner is authenticated using a short-term certificate that is a digital certificate with an expiration date. A first authentication means, a second authentication means for authenticating using a long-term certificate which is a digital certificate having virtually no expiration date when authentication by the means is not normally performed, and authentication by the means Is provided with an abnormality detection means for determining that there is an abnormality in the authentication using the short-term certificate when the authentication is successful.
In each of the communication apparatuses, the authentication may be performed by an authentication process according to an SSL or TLS protocol, and the short-term certificate may be the public key certificate of the communication partner.
The communication apparatus according to the present invention is a communication apparatus capable of communicating with any one of the communication apparatuses described above, further including certificate storage means for storing the long-term certificate and the short-term certificate.

  Also, the communication system of the present invention is composed of a higher-level device and a lower-level device each having communication means, and at the time of communication, the higher-level device uses two types of digital certificates in which different valid periods are set. In the communication system used for authentication, a certificate storage means for storing the two types of digital certificates is provided in the lower level device, and the two types of digital certificates are used when the higher level device communicates with the lower level device. A first authentication means for authenticating using a short-term certificate having a shorter valid period of the certificate, and when the two types of digital certificates are not successfully authenticated The second authentication means that performs authentication using the long-term certificate with the longer valid period, and the authentication using the short-term certificate when the authentication by the means is successful It is provided with a an abnormality detection means for determining the normal there.

Alternatively, in a communication system that includes a higher-level device and a lower-level device each having a communication means, and the higher-level device authenticates the lower-level device using a digital certificate during communication, the lower-level device has a product of the lower-level device. Certificate storage means for storing a long-term certificate that is a digital certificate having a longer valid period than the lifetime and a short-term certificate that is a digital certificate having a shorter valid period than the product lifetime is provided, and the host device includes the certificate storage unit. A first authentication unit that performs authentication using the short-term certificate when communicating with a lower-level device; and a second authentication unit that performs authentication using the long-term certificate when authentication by the unit cannot be performed normally Authentication means and an abnormality detection means for judging that there is an abnormality in the authentication using the short-term certificate when the authentication by the means is successful.
In these communication systems, it is preferable to provide a plurality of the lower-level devices and store the same long-term certificate in the certificate storage means of all the lower-level devices.
The authentication may be performed by an authentication process according to an SSL or TLS protocol, and the short-term certificate may be a public key certificate of the lower-level device.

  In addition, the abnormality detection method of the present invention detects the above-described authentication abnormality in a communication apparatus that includes communication means and authenticates a communication partner using two types of digital certificates with different validity periods. In the anomaly detection method, when the communication device communicates with the communication partner, the first authentication is performed using the short-term certificate having the shorter valid period among the two types of digital certificates. If the authentication was not successful, the second authentication was performed using the long-term certificate with the longer valid period set out of the two types of digital certificates, and the authentication was successful. In this case, it is determined that there is an abnormality in the authentication using the short-term certificate.

Alternatively, the communication device communicates with the communication partner in the abnormality detection method of detecting an abnormality in the authentication in a communication device that includes a communication unit and authenticates the communication partner using a digital certificate at the time of communication. In addition, when the first authentication is performed using a short-term certificate that is a digital certificate whose validity period is shorter than the product life of the communication partner, and the authentication cannot be normally performed, the product life of the communication partner is exceeded. The second authentication is performed using a long-term certificate that is a digital certificate with a long validity period, and when the authentication is successful, it is determined that there is an abnormality in the authentication using the short-term certificate. is there.
In these abnormality detection methods, the authentication may be performed by an authentication process according to an SSL or TLS protocol, and the short-term certificate may be the public key certificate of the communication partner.

  In addition, the abnormality detection method of the present invention comprises two types of digital certificates, each of which is composed of a higher-level device and a lower-level device each having communication means, and the higher-level device sets a different valid period for the lower-level device during communication. In the abnormality detection method for detecting the authentication abnormality in the communication system that authenticates using the above, when the two types of digital certificates are stored in the lower-level device and the upper-level device communicates with the lower-level device, When the first authentication is performed using the short-term certificate having the shorter valid period among the two types of digital certificates and the authentication is not performed normally, the above two types of digital certificates The second authentication is performed using the long-term certificate with the longer valid period, and if the authentication is successful, it is determined that there is an abnormality in the authentication using the short-term certificate. It is obtained by way.

Alternatively, in the abnormality detection method for detecting an abnormality in the authentication in a communication system configured by a higher-level device and a lower-level device each having a communication unit, and the higher-level device authenticates the lower-level device using a digital certificate during communication The low-order device stores a long-term certificate that is a digital certificate having a validity period longer than the product life of the low-order device and a short-term certificate that is a digital certificate having a validity period shorter than the product life. When the higher-level device communicates with the lower-level device, the first authentication is performed using the short-term certificate. If the authentication cannot be normally performed, the second authentication is performed using the long-term certificate. When the authentication is successful, it is determined that there is an abnormality in the authentication using the short-term certificate.
In these abnormality detection methods, when a plurality of the lower devices are provided, the same long-term certificate may be stored in the certificate storage means of all the lower devices.
Further, the authentication may be performed by an authentication process according to an SSL or TLS protocol, and the individual certificate may be a public key certificate of the lower-level device.

  In addition, the program of the present invention causes a computer to function as a communication device that includes communication means and authenticates a communication partner using two types of digital certificates with different validity periods when performing communication. In the program, when the computer communicates with the communication partner, first authentication means for performing authentication using a short-term certificate having a shorter valid period among the two types of digital certificates, Second authentication means for performing authentication using a long-term certificate having a longer valid period among the two types of digital certificates when authentication by the means cannot be performed normally, and the means A program for functioning as an abnormality detection means for determining that there is an abnormality in the authentication using the short-term certificate when the authentication by the above is successful.

In addition, when a computer includes a communication unit and causes a communication partner to function as a communication device that authenticates a communication partner using a digital certificate when performing communication, the computer communicates with the communication partner. A first authenticating means for authenticating using a short-term certificate that is a digital certificate whose validity period is shorter than the product life of the communicating party, and when the authenticating by the means cannot be normally performed, There is an abnormality in the second authentication means that authenticates using a long-term certificate, which is a digital certificate that has a longer validity period than the product lifetime, and the authentication using the short-term certificate when authentication by that means is successful The program for functioning as an abnormality detection means to judge is included.
In these programs, the authentication may be performed by an authentication process according to an SSL or TLS protocol, and the short-term certificate may be the public key certificate of the communication partner.

  According to another aspect of the present invention, there is provided a program for causing a computer to function as a communication device capable of communicating with each communication device as a communication partner. The computer stores the long-term certificate and the short-term certificate. A program for functioning as certificate storage means is included.

According to the communication apparatus, communication system or abnormality detection method of the present invention as described above, a communication apparatus for authenticating a communication partner using a digital certificate at the time of communication, or a communication system configured using such a communication apparatus. In this case, when an abnormality occurs in authentication using a digital certificate, it can be recognized easily and promptly.
Further, according to the program of the present invention, the computer can be functioned as the above communication device to realize its characteristics, and similar effects can be obtained.

Preferred embodiments of the present invention will be described below with reference to the drawings.
First, the configuration of a first embodiment of a communication device according to the present invention and a communication system of the present invention configured using the communication device will be described. In this embodiment, a communication system is configured by the higher-level device 30 and the lower-level device 40, which are communication devices, respectively, 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 upper device and the lower 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, it is assumed that the communication 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. Further, although there is only one upper apparatus 30 for one communication system, there is a plurality of upper apparatuses 30 in the certificate management system as a result of enabling one certificate management apparatus 20 to communicate with a plurality of communication systems. It doesn't matter if you decide to do it.

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 a measuring system such as electricity, an automobile, an aircraft, etc. is used as a lower device 40 as a managed device, and a higher management 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 an individual 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 or the like used for the authentication processing is stored in the certificate storage unit 45.
The request management unit 44 has a function of determining whether or not to execute an operation based on 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 host device 30 and the lower device 40 is a short-term certificate and a public key certificate that is a public key certificate with a shorter validity period than the long-term certificate. There is a rescue certificate public key certificate that is a key certificate and a public key certificate that is a long-term certificate and has a validity period longer than the short-term certificate, and the request management unit 44, as shown in FIG. When authentication is performed using a normal public key certificate, all operations are permitted. However, when authentication is performed using a rescue public key certificate, only 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 for use in authentication processing in the authentication processing unit 33. . 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 reception 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. This is a digital certificate with a short-term 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.

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. The root key certificate has the same relationship.

  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 lower-level device normal public key certificate, and the device is identified from the identification information included in the certificate. 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 random number encrypted with the higher device normal private key transmitted when the upper device 30 is successfully authenticated. Similar authentication can be performed using the root key certificate for higher-level device authentication.
This procedure is processing when the host device 30 requests communication to the HTTPS server function unit 42 of the lower-level device 40 by the HTTPS client function unit 31, and the lower-level device 40 receives the host device 30 by the HTTPS client function unit 41. 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, the validity of the normal public key certificate is not within the validity period described in the normal public key certificate. Is not allowed. Therefore, in this case, authentication cannot be performed.
Therefore, in order to prevent such a situation from occurring, a new public key certificate for use after the expiration of the validity period should be stored in each device before the validity period of the public key certificate being used expires. Can be considered. However, if the device is turned off or stored in a warehouse without being shipped, the device cannot be accessed from the outside. Therefore, it is conceivable that the validity period will expire before a new public key certificate can be stored.

  Here, if each device can only perform authentication using a normal public key certificate (authentication using normal authentication information), a new normal public key certificate or There will be no way to send the private key and the normal root key certificate to the target device securely over the network. 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 a rescue public key issued to the lower level device by the certificate management device 20 as a 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 long-term 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 verify the validity of the low-level device authentication rescue root key. This is a digital certificate with

However, a significant difference from the regular authentication information is that the validity period of the rescue public key certificate is set longer than the validity period of the normal public key certificate.
Here, FIG. 9 shows an example of a normal public key certificate, and FIG. 10 shows an example of a rescue public key certificate.
These are public key certificates issued to the same device, with the identification information of the device as the issue destination being the same, as indicated by symbols F and I. However, the validity period of the normal public key certificate is one year from midnight on January 1, 2003 to midnight on January 1, 2004, as indicated by the symbol E. As shown by the symbol H, the valid period of the letter is 50 years from midnight on January 1, 2000 to midnight on January 1, 2050.
Further, the issuer of the certificate is the same CA of XXX, but “Regular CA” as indicated by the symbol D for the normal public key certificate and “ResumeCA” as indicated by the symbol G for the rescue public key certificate. "This is a different CA.

  Such a rescue public key certificate with a long validity period is slightly less secure than a normal public key certificate with a short validity period. However, by using such a rescue public key certificate, even if the validity period of the normal public key certificate has expired, if it is within the validity period of the rescue public key certificate, the communication partner Can be authenticated. 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, it is possible to transmit and set a new normal public key certificate to the communication partner using this communication path.

If the authentication process is performed using rescue authentication information, the validity period can be increased if only limited requests such as updating of regular authentication information such as normal public key certificates are permitted. Even if the safety is slightly lowered due to the lengthening, it does not become a big problem.
Also, considering this point, after the validity period of the rescue public key certificate has passed, if the validity period of the normal public key certificate has passed, authentication with the public key certificate can no longer be performed. Therefore, it is preferable that the rescue public key certificate has a longer validity period. 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.
It should be noted that the validity period of the normal public key certificate may be set to an appropriate period in consideration of security, but this period is shorter than the product life and the validity period expires during the operation of the device. It is often a long period.

  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 is 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, the authentication using the normal public key certificate is attempted. If this authentication fails due to the expiration of the validity period of the normal public key certificate, Authentication is attempted using a rescue public key certificate. In addition, if the lower level device 40 is an appropriate device as a communication partner and the validity period of the rescue public key certificate has not passed, authentication using the rescue public key certificate is successful. A function is provided to update the regular authentication information of the lower level device 40 when the authentication is successful.

  In other words, when the host device 30 requests communication with the lower device 40, first, a communication request is transmitted to the normal URL and authentication using the normal public key certificate is 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 as shown in FIG. 12 and constitutes normal authentication information stored in the lower level device 40. Of course, the low-level device normal public key certificate included in the renewal certificate set is within the valid period.
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. In addition, the higher-level device authentication normal root key certificate includes a root key certificate 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. 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 upper device authentication root key certificate and the lower device authentication root key). The 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 related to 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 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 the request is a communication request for a normal URL, the process proceeds to step S202, and the normal public key certificate is transmitted to the upper apparatus 30 together with the first random number encrypted with the normal private key (ordinary private key for the lower apparatus). This processing corresponds to the processing in steps S21 and S22 in FIG.

On the host device 30 side, when this response is received or when a predetermined time has elapsed, the process proceeds to step S102 to 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 processes of steps S101 and S102, the CPU of the higher-level device 30 functions as a first authentication unit.
In step S103, it is determined whether or not the authentication is successful. If the authentication is successful, the process proceeds to step S112, where the common key seed is transmitted to the lower level device 40, and the common key is created and used for the subsequent communication. To. This processing corresponds to the processing in steps S14 to S17 in FIG.

On the lower level device 40 side, after transmitting the normal public key certificate in step S202, the lower level device 40 waits for this transmission in step S203. Go ahead and create a common key to use for future communications. If an authentication failure response is returned or no response is received from the host device 30 within a predetermined time, it is determined that the authentication has failed, and the process is terminated. These processes correspond to steps S23 to S27 in FIG. 22 or steps S25 to S27 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 S113, and a response is waited for in step S114. In step S115, it is determined whether or not all the requests have been transmitted. If any request remains, the process returns to step S113 to repeat the process. If all have been transmitted, the process proceeds to step S116 to disconnect the communication and end the process. .

  On the lower device 40 side, after step S204, the process proceeds to step S205, where it is determined whether or not a request has been received from the higher device 30, and if it is received, processing according to the request is performed in step S206 to Returns a response. In step S207, it is determined whether there is information to be notified to the higher-level device 30, and if there is, the notification is transmitted in step S208. Then, in step S209, it is determined whether or not the host device 30 has disconnected communication. If not disconnected, the process returns to step S205 to repeat the process. If disconnected, the process ends.

On the other hand, if the authentication fails in step S103 in the process on the host device 30 side, the cause of the authentication failure is that the public key certificate has expired and the version of the public key certificate matches the root key certificate. It was attached to the public key certificate that the public key certificate was damaged, the public key certificate was not sent, or was trying to communicate with an unrelated device in the first place. It is conceivable that the identification information is from a device that is inappropriate as a communication partner. Then, in the next step S104, it is determined whether or not the cause is that the expiration date of the public key certificate has expired. If this determination is NO, the process ends.
This is because the processing after step S105 is processing for storing a new normal public key certificate in the communication partner when the validity period of the normal public key certificate has expired. Note that if the cause of the authentication failure in step S103 is that the version of the public key certificate does not match or that a normal public key certificate has not been transmitted, etc., a countermeasure corresponding to the cause can be considered. However, since this process is not directly related to the feature of this embodiment, the description thereof is omitted.

On the other hand, if the determination in step S104 is YES, the process proceeds to step S105, and this time, a communication request is transmitted to the rescue URL of the lower level device 40.
In this case, the lower-level device 40 starts the process shown in the flowchart of FIG. 14 again, but the determination in step S201 is a rescue URL, and the process proceeds to step S210, where the rescue public key certificate for the lower-level device is assigned to the rescue private It is transmitted to the host device 30 together with the first random number encrypted with the key (the rescue device private key for the lower device). This process also corresponds to the process of steps S21 and S22 of FIG. 22 or FIG. 24 as in the case of step S202. In the processes of steps S105 and S106, the CPU of the host device 30 functions as a second authentication unit.

  On the host device 30 side, when the certificate and the random number transmitted by the lower device 40 in step S210 are received in step S106, 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 step S103. In addition, when not receiving within predetermined time after step S105, you may make it handle as an authentication failure. In the processes of steps S105 and S106, the CPU of the host device 30 functions as an authentication unit.

In step S107, it is determined whether or not the authentication is successful. If the authentication is successful, the process proceeds to step S108 where the shared key seed is transmitted to the lower level device 40 and a 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 S103 and S112.
The lower device 40 waits for this transmission in step S211 after step S210, and if it receives the shared key seed, it determines that it has been authenticated by the higher device 30, proceeds to step S212, creates a common key, and thereafter To use for communication. If an authentication failure response is returned or no response is received from the host device 30 within a predetermined time, it is determined that the authentication has failed, and the process is terminated. These processes correspond to the processes in steps S23 to S27 in FIG. 22 or steps S25 to S27 in FIG. 24, as in steps S203 and S204.

  On the other hand, since the authentication using the rescue public key certificate is successful in step S107, the upper device 30 side can determine that the lower device 40 is an appropriate device as a communication partner. In step S109 following step S108 in order to update the certificate, necessary information is transmitted to the certificate management apparatus 20 to create a new certificate set for update, and this is acquired. Will be described in detail later.

Upon acquiring the new certificate set from the certificate management apparatus 20, the upper apparatus 30 transmits the new certificate set together with the certificate update request to the lower apparatus 40 in step S110, and stores the stored normal authentication information as the new certificate set. Request to update the contents of the certificate set. In this process, the CPU of the host device 30 functions as a certificate transmission unit.
Then, in step S111, the process waits for a response from the lower apparatus 40 and proceeds to step S116, disconnects the 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 S103 to 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 S212, the reception of the request is waited at step S213, and when the request is received, the process proceeds to step S214. Then, as described with reference to FIG. 4, the request management unit 44 of the lower level device 40 performs authentication using the rescue public key certificate (authenticated using the rescue public key certificate). Since only the certificate renewal operation is permitted, it is determined whether or not the request received in step S213 is a certificate renewal request. If it is not a certificate renewal request, the request is ignored and the process returns to step S213 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 S214, the process proceeds to step S215, 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. In step S216, the update result is notified to the transmission source as a response, 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, an example of processing when the validity period of the lower-level apparatus normal public key certificate stored in the lower-level apparatus 40 has passed is shown.

  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 perform authentication processing. Here, the received low-level device normal public key certificate has passed the validity period, and therefore it is determined that the authentication has failed (S303). Then, an authentication failure response is returned to the lower level device 40 (S304).
Since the cause of the authentication failure is that the validity period of the public key certificate has passed, a communication request is transmitted to the rescue URL in order to attempt authentication with a certificate having a longer validity period (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 for authentication processing. If the lower-level device 40 is a device that can serve as a communication partner and the validity period of the rescue public key certificate has not passed, authentication succeeds. (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, and in the case of mutual authentication, 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 of step S310, the partner who requested communication in step S301 is a device that can be a valid communication partner although the validity period of the normal public key certificate has passed. Judgment is made (S311).
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 subordinate 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 information to be 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. Furthermore, as described above, the root private key used for the digital signature may be newly generated at this time, and the root key certificate may be updated at the same time. 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 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, when 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 re-searches the lower-level device 40 (S331). This is for confirming that the authentication using the normal public key certificate is successful and the communication can be 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 higher-level device 30 can confirm that the certificate has been successfully updated, and that the lower-level device 40 has again stored the normal public key certificate within the valid period. The certificate update result received in step S321 The notification and its attached information are 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 authentication cannot be normally performed because the validity period of the public key certificate constituting the regular authentication information in the lower-level device 40 has passed, The certificate of the lower device is updated so that the 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 using SSL can be established, but if authentication using a normal public key certificate is not performed normally, a rescue public key with a longer validity period is set. If authentication is performed using a certificate and the authentication is successful, the higher-level device 30 acquires a new certificate set and transmits it to the lower-level device 40 to update the regular authentication information. A normal public key certificate within the valid period can be set so that normal authentication can be performed.

  Such a rescue public key certificate with a long validity period is slightly inferior in security as compared with a normal public key certificate with a short validity period, but can ensure a considerable degree of security. And by preparing such a certificate, even if the normal public key certificate expires, if it is within the validity period of the rescue public key certificate, the common key encryption is used. There is an effect that a secure communication path can be secured.

  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 the 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. Here, the regular authentication information of the lower device 40 is updated. In the communication system of this embodiment, there is one upper device 30, but a plurality of lower devices 40 can be connected to the higher device 30. This is because the subordinate device 40 is harder to manage because it can be attached and detached, and therefore the normal public key certificate is likely to expire.
However, since there is a possibility that the normal public key certificate expires in the host device 30, the host device 30 may attempt to update its own regular authentication information when it recognizes this.

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). At this time, since the normal public key certificate of the higher-level device 30 has expired, it is not possible to receive authentication using this when performing mutual authentication. Therefore, the rescue URL of the certificate management apparatus 20 is accessed to perform authentication using the rescue public key certificate. If the host device 30 only authenticates the certificate management device 20, authentication using a normal public key certificate is possible.

Upon receiving the request in step S401, the certificate management apparatus 20 creates a certificate set and its setting request (S402). Of course, the public key certificate included in the certificate set created here is within the valid period. belongs to.
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 of step S402 is completed, the certificate management apparatus 20 returns a new certificate set together with the certificate setting 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.

  Further, in the above-described embodiment, the example in which the authentication using the normal public key certificate is performed when the upper apparatus 30 tries to transmit a request to the lower apparatus 40 has been described. Communication may be requested for the normal URL of the device 40 to search for lower devices. For the lower-level device 40 that has not been able to perform the authentication normally due to the expiration of the normal public key certificate, the same processing as in step S305 and subsequent steps in FIG. 15 and FIG. If the information is updated, the regular public key certificate is periodically checked to see if it has expired. If the valid period has expired, the regular public key certificate of the lower level device 40 is updated and communication is performed. Each device of the system can maintain a state in which the communication partner can be authenticated using the 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 stored in the lower level device 40 at the time of manufacture has expired before being connected to the communication system, if the authentication using the rescue public key certificate is successful, the certificate The document management apparatus 20 can issue a new normal public key certificate for the lower apparatus 40 and store it in the lower apparatus 40.
Note that if the subordinate device 40 whose valid period of the normal public key certificate has expired is found by this search, the normal public key certificate is immediately updated. It can be considered as part of the operation of updating the public key certificate.

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 to the 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 upper device 30 determines that the authentication in step S502 has failed due to the expiration of the normal public key certificate (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 upper apparatus 30 determines that the authentication is successful (S507), the lower apparatus 40 performs the normal public key certificate as in step S311 of FIG. It is determined that it is possible to be a legitimate communication partner although the expiration date of is expired (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 when it is determined that the authentication is successful (S517), as in step S311 of FIG. However, it is determined that it is possible to be a valid communication partner (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 40 requests communication to the normal URL to perform normal communication with the lower device 30 (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 due to the expiration of the normal public key certificate (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 higher level apparatus 30 determines that the authentication is successful (S527), the lower level apparatus 40 uses the normal public key certificate as in step S311 of FIG. However, it is determined that it is possible to be a valid communication partner (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 authentication using the normal public key certificate fails due to the expiration of the normal public key certificate, as in the case of the above-described embodiment. In this case, authentication using the rescue public key certificate is performed, and if this is successful, the lower-level device 40 can determine that the normal public key certificate has expired but can be a valid communication partner. Therefore, the higher-level device 30 acquires a new certificate set, transmits it to the lower-level device 40, and updates the regular authentication information, so that a normal public key certificate within the valid period can be easily set safely and automatically. , Can be able to perform normal authentication.

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. 13 related 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.

By the way, in the above-described embodiment, the example in which the CA of the same vendor issues the normal public key certificate and the rescue public key certificate has been described. However, as explained in the section of the prior art, it is preferable to request the issuance of a normal public key certificate from a highly reliable third party CA. Such a normal public key certificate issued by a CA often has a short validity period. However, according to the above-described embodiment, a normal public key certificate can be obtained even after the validity period of the normal public key certificate has passed. Since it can be updated safely and automatically, the problem due to the short validity period can be solved. The communication system can be operated by using authentication using a public key certificate with a high external trust issued by a highly reliable third party CA.
In this case, the CA of the third-party organization requests the issuance of a certificate directly from the host device 30 and also requests the issuance of a certificate from the certificate management device 20 through the certificate management device 20 once. A method to do this is also conceivable.

Further, the rescue public key certificate may be issued by the vendor of the higher-level device 30 or the lower-level device 40 with its own CA so that the validity period can be freely determined. In addition, since the rescue public key certificate has a long validity period, if the rescue root private key is leaked, it is extremely difficult to maintain the safety of communication. Therefore, it is necessary to strictly maintain confidentiality. 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.
Certificate management devices that issue certificates for lower devices, certificate management devices that issue certificates for higher devices, certificate management devices that issue certificates for each certificate management device, etc. Certificate management devices may be divided according to the type of device to be issued.
However, it is not essential for separate CAs to issue the normal public key certificate and the rescue public key certificate, and a common CA may be issued.

In the above-described embodiment, an example using a normal public key certificate with a short validity period and a rescue public key certificate with a long validity period has been described. The former is a certificate with a high security strength, and the latter is a security strength. Can be seen as a relatively low certificate.
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 for the system operator to improve the security by devising the contents of authentication processing in various ways. In such a case, a certain device is moved from one system to another system (simply set) (Including the case of only changing the password), 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. The failure of authentication using a certificate is determined to be caused by an abnormality in authentication, and the upper device 30 acquires a certificate set including a high-security certificate, transmits the certificate set to the lower 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 upper device 30 accesses the rescue URL of the lower device 40 when the authentication process using the normal public key certificate fails because the normal public key certificate of the lower device 40 has expired. The example of performing the process related to the update of the regular authentication information has been described. However, similar processing may be performed when the authentication processing fails for other reasons. That is, in step S104 of FIG. 13, the process may proceed to step S105 and subsequent steps for other reasons.
Even in this case, if the authentication process using the rescue public key certificate is successful, it can be understood that the other party who requested the communication can be a legitimate one. Then, the reason why the authentication process using the normal public key certificate has failed is that the authentication is abnormal due to the abnormality of the certificate that should be stored in the lower level device 40. It can be judged. Therefore, in this case, if new normal authentication information is transmitted to the lower level device 40 and the normal authentication information is updated, the abnormality can be quickly resolved and authentication using the normal public key certificate can be performed again. It is thought that it can be in a state. In this case, the CPU of the host device 30 also functions as an abnormality detection unit in the process of step S107 of FIG.

However, the cause of the authentication process failure is that the identification information attached to the public key certificate is from an inappropriate device as the communication partner, there is no response to the communication request, or the authentication process is not supported If a response to this effect is returned, the communication partner is considered to be a device that has nothing to do with the host device 30. In such a case, the rescue URL may not be accessed. .
Further, when the validity period of the normal public key certificate has not expired (for example, when it is damaged within the time limit), the certificate management device 20 uses the public key or private key issued to the lower device 40 in the past. If managed, the key may be used as it is.

  In the above-described embodiment, the example in which the identification information of the device is also described in the rescue public key certificate has been described. However, the rescue public key certificate does not include the identification information of the device, and devices of the same rank (see FIG. 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 rescue private key corresponding thereto 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 a certain rank device. 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 normal public key certificate and data format, for example, in the format shown in FIG. 9, 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, the 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.

Here, since the rescue public key certificate is not attached with device identification information, even when authentication using the rescue public key certificate is performed, the communication partner device cannot be specifically identified. 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, the lower level device rescue public information (the lower level device rescue public key certificate, the lower level device rescue private key, and the 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, safety | security can be improved rather than a rescue public key certificate by the part for which an expiration date is short.

  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 described above, if the communication device, communication system, abnormality detection method or program of the present invention is used, a communication device for authenticating a communication partner using a digital certificate at the time of communication or such a communication device is used. In the configured communication system, when an abnormality occurs in authentication using a digital certificate, it can be easily and quickly recognized.
Therefore, a communication system with high security can be configured by applying the present invention to such a communication system or a communication apparatus constituting such a 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 (21)

A communication apparatus that includes a communication unit and authenticates a communication partner using two types of digital certificates in which different valid periods are set during communication,
A first authentication means for authenticating the communication partner using a short-term certificate having a shorter effective period of the two types of digital certificates;
A second authentication means for performing authentication using a long-term certificate having a longer valid period among the two types of digital certificates when authentication by the means cannot be performed normally;
A communication apparatus, comprising: an abnormality detection unit that determines that there is an abnormality in authentication using the short-term certificate when authentication by the unit is successful. A communication device comprising a communication means for authenticating a communication partner using a digital certificate during communication,
First authentication means for authenticating the communication partner using a short-term certificate that is a digital certificate having a validity period shorter than the product life of the communication partner;
A second authentication means for performing authentication using a long-term certificate that is a digital certificate having a validity period longer than the product life of the communication partner when authentication by the means cannot be performed normally;
A communication apparatus, comprising: an abnormality detection unit that determines that there is an abnormality in authentication using the short-term certificate when authentication by the unit is successful. A communication device comprising a communication means for authenticating a communication partner using a digital certificate during communication,
First authentication means for authenticating the communication partner using a short-term certificate that is a digital certificate that expires during operation of the communication partner;
Second authentication means for performing authentication using a long-term certificate that is a digital certificate that does not expire during the operation of the communication partner when authentication by the means cannot be performed normally;
A communication apparatus, comprising: an abnormality detection unit that determines that there is an abnormality in authentication using the short-term certificate when authentication by the unit is successful. A communication device comprising a communication means for authenticating a communication partner using a digital certificate during communication,
First authentication means for authenticating the communication partner using a short-term certificate that is a digital certificate with an expiration date;
A second authentication unit that performs authentication using a long-term certificate that is a digital certificate that has virtually no expiration date when the authentication by the unit cannot be performed normally;
A communication apparatus, comprising: an abnormality detection unit that determines that there is an abnormality in authentication using the short-term certificate when authentication by the unit is successful. The communication device according to any one of claims 1 to 4,
The authentication is performed by an authentication process according to the SSL or TLS protocol,
The communication device, wherein the short-term certificate is a public key certificate of the communication partner. A communication device capable of communicating with the communication device according to any one of claims 1 to 5,
A communication apparatus comprising certificate storage means for storing the long-term certificate and the short-term certificate. A communication system that includes a higher-level device and a lower-level device each having a communication means, and in which the higher-level device authenticates the lower-level device using two types of digital certificates with different validity periods set. ,
In the subordinate device,
Providing certificate storage means for storing the two types of digital certificates;
In the host device,
A first authentication unit that performs authentication using a short-term certificate having a shorter effective period of the two types of digital certificates when communicating with the lower-level device;
A second authentication means for performing authentication using a long-term certificate having a longer valid period among the two types of digital certificates when authentication by the means cannot be performed normally;
A communication system, comprising: an anomaly detecting means for judging that the authentication using the short-term certificate is abnormal when the authentication by the means is successful. A communication system that includes a higher-level device and a lower-level device each having communication means, and that the higher-level device authenticates the lower-level device using a digital certificate during communication,
In the subordinate device,
A certificate storage means for storing a long-term certificate that is a digital certificate having a longer validity period than the product lifetime of the lower-level device and a short-term certificate that is a digital certificate having a shorter validity period than the product lifetime;
In the host device,
First authentication means for performing authentication using the short-term certificate when communicating with the lower-level device;
Second authentication means for performing authentication using the long-term certificate when the authentication by the means cannot be performed normally;
A communication system, comprising: an anomaly detecting means for judging that the authentication using the short-term certificate is abnormal when the authentication by the means is successful. The communication system according to claim 7 or 8,
A communication system, wherein a plurality of the lower-level devices are provided, and the same long-term certificate is stored in certificate storage means of all the lower-level devices. A communication system according to any one of claims 7 to 9,
The authentication is performed by an authentication process according to the SSL or TLS protocol,
The short-term certificate is a public key certificate of the lower-level device. In a communication apparatus comprising a communication means and authenticating a communication partner using two types of digital certificates with different valid periods during communication, an abnormality detection method for detecting the authentication abnormality,
When the communication device communicates with the communication partner, the first authentication is performed using a short-term certificate having a shorter valid period among the two types of digital certificates, and the authentication is normal. If the authentication is successful, the second authentication is performed using a long-term certificate having a longer valid period set out of the two types of digital certificates. An abnormality detection method characterized in that it is determined that there is an abnormality in authentication using. In a communication apparatus comprising a communication means and authenticating a communication partner using a digital certificate at the time of communication, an abnormality detection method for detecting an abnormality in the authentication,
When the communication device communicates with the communication partner, the first authentication is performed using a short-term certificate that is a digital certificate having a validity period shorter than the product life of the communication partner, and the authentication can be normally performed. If the authentication is successful, the second authentication is performed using a long-term certificate that is a digital certificate whose lifetime is longer than the product life of the communication partner, and the authentication using the short-term certificate is performed when the authentication is successful An abnormality detection method characterized by determining that there is an abnormality. The abnormality detection method according to claim 11 or 12,
The authentication is performed by an authentication process according to the SSL or TLS protocol,
The abnormality detection method, wherein the short-term certificate is a public key certificate of the communication partner. In the communication system, which is constituted by a higher-level device and a lower-level device each having a communication means, and in which the higher-level device authenticates the lower-level device using two types of digital certificates in which different valid periods are set, An abnormality detection method for detecting an authentication abnormality,
Storing the two types of digital certificates in the lower-level device;
When the higher-level device communicates with the lower-level device, the first authentication is performed using the short-term certificate having the shorter valid period among the two types of digital certificates, and the authentication is normal. If the authentication is successful, the second authentication is performed using a long-term certificate having a longer valid period set out of the two types of digital certificates. An abnormality detection method characterized in that it is determined that there is an abnormality in authentication using. This is an abnormality detection method for detecting an abnormality in authentication in a communication system that includes a higher-level device and a lower-level device each having communication means, and in which the higher-level device authenticates the lower-level device using a digital certificate during communication. And
The lower-level device stores a long-term certificate that is a digital certificate having a longer validity period than the product lifetime of the lower-level device and a short-term certificate that is a digital certificate having a shorter validity period than the product lifetime,
When the upper device communicates with the lower device, the first authentication is performed using the short-term certificate, and the second authentication is performed using the long-term certificate when the authentication cannot be normally performed. And detecting that there is an abnormality in the authentication using the short-term certificate when the authentication is successful. The abnormality detection method according to claim 14 or 15,
An abnormality detection method characterized by storing the same long-term certificate in certificate storage means of all the lower-level devices when a plurality of the lower-level devices are provided. The abnormality detection method according to any one of claims 14 to 16,
The authentication is performed by an authentication process according to the SSL or TLS protocol,
The abnormality detection method, wherein the individual certificate is a public key certificate of the lower-level device. A program for causing a computer to function as a communication apparatus that includes communication means and authenticates a communication partner using two types of digital certificates with different validity periods when performing communication,
First authentication means for performing authentication using a short-term certificate having a shorter valid period among the two types of digital certificates when the computer communicates with the communication partner;
A second authentication means for performing authentication using a long-term certificate having a longer valid period among the two types of digital certificates when authentication by the means cannot be performed normally;
A program comprising: a program for functioning as an abnormality detection unit that determines that there is an abnormality in authentication using the short-term certificate when authentication by the unit is successful. A program comprising a communication means for causing a computer to function as a communication device that authenticates a communication partner using a digital certificate when performing communication,
First authentication means for performing authentication using a short-term certificate, which is a digital certificate having a validity period shorter than the product lifetime of the communication partner when the computer communicates with the communication partner;
A second authentication means for performing authentication using a long-term certificate that is a digital certificate having a validity period longer than the product life of the communication partner when authentication by the means cannot be performed normally;
A program comprising: a program for functioning as an abnormality detection unit that determines that there is an abnormality in authentication using the short-term certificate when authentication by the unit is successful. The program according to claim 18 or 19, wherein
The authentication is performed by an authentication process according to the SSL or TLS protocol,
The program, wherein the short-term certificate is a public key certificate of the communication partner. A program for causing a computer to function as a communication device capable of communicating with the communication device according to any one of claims 1 to 5 as a communication partner,
A program comprising a program for causing the computer to function as certificate storage means for storing the long-term certificate and the short-term certificate.

Images