Certificate setting method

The present invention is a certificate setting method for storing a certificate used for authentication processing in a communication device using a certificate setting device.<u style="single">And a certificate setting device that stores the certificate used for authentication processing in the communication device.</u>Regarding.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<p> By the way, such a third party organization sets a validity period for the public key certificate to be issued in order to improve security. In addition, this period is usually in units of several years, and is often as short as 1 to 3 years. Then, in the above authentication process, the public key certificate whose validity period has expired is not recognized as a legitimate public key certificate. Therefore, it is necessary to update to a new one before this validity period expires.</p><p> Here, when authenticating the device itself, it is necessary to store the digital certificate in the device in advance, unlike the authentication that identifies the operator such as a web browser. This is also the case at the time of manufacturing the device, and when a part having a memory for storing the certificate is replaced due to damage or defect, the certificate must be stored even after the replacement. Must be. However, when adopting a certificate with a short validity period as described above, if this is stored in the device or replacement parts in advance, the expiration date of the certificate will be valid while it is stocked in a warehouse or the like before shipping. There was a problem that it could be cut off. Then, when the expiration date has expired, the device will no longer be able to receive certification, and if it is a replacement part, the attached device should be in a state where it can be certified. Can no longer be done. In order to solve such a problem, it is conceivable to store the certificate individually in each device immediately before shipment. Further, for a part having a memory for storing a certificate, it is conceivable to take measures such as storing the certificate after exchanging the part.</p><p> Therefore, FIG. 22 shows a method conventionally used for performing such individual writing to the non-volatile storage device. As shown in FIG. 22 (a), one of the conventionally used methods is to provide a storage device write terminal 305 on the board pattern connected to the non-volatile storage device 301 provided in the communication device 300. This is a method of writing from the writing device 313 by connecting the dedicated connector 312, which is a dedicated jig for writing, to this. However, this method requires a dedicated jig for writing, and due to jig management problems, parts that are written by an OEM (Original Equipment Manufacturer) manufacturer or that store a certificate after the device is distributed on the market. There was a problem that it was difficult to enable the writing necessary for repair when the device was damaged.</p><p> Also, the connection I / F (storage device write terminal 305) of the dedicated jig, which is not used during normal operation, is usually located inside the device after the device is completed, so connect the dedicated connector 312 here. Has a problem that work efficiency is poor because troublesome work such as removing the board is required once. There is also a risk that the device will be damaged by this work. It is conceivable to provide a connection I / F for a dedicated jig on the outside of the device, but if this is done, an additional I / F that is unnecessary for normal operation will be provided, leading to an increase in cost.</p><p> On the other hand, for writing information, as shown in FIG. 22 (b), a memory card 311 such as a PCMCIA (Personal Computer Memory Card International Association) card is used as an replaceable storage device, and this storage device is used in the communication device 300. A method is also used in which a card slot 303 is provided as an interface (I / F) to be connected, and the contents of the memory card 311 connected to the card slot 303 are read by the CPU 302 and written to the non-volatile storage device 301. With this method, if you prepare a memory card 311 that stores an appropriate certificate, you can write to it anywhere, including OEM manufacturers and the market. However, since the memory card is a widely used and general medium, it is difficult to manage the security, and it is necessary to confirm the validity of the memory card 311 and to prevent the memory card 311 from being passed on to an unauthorized third party. In addition, there is a problem that it is difficult to prevent a third party from illegally acquiring data from the memory card 311.</p><p> Furthermore, in order to prevent spoofing of the device, it is necessary to prevent malicious users from exchanging, reading, and registering digital certificates, and it is necessary to prohibit general users from renewing digital certificates. It is also difficult to confirm the authority when setting a certificate using a memory card 311. The present invention solves such a problem and has a short validity period for a communication device.<u style="single">Certificate</u>The purpose is to make it easy and secure to set such a certificate.</p>

<p> In order to achieve the above object, the certificate setting method of the present invention is used for the communication device and the authentication process.<u style="single">Certificate</u>In the certificate setting method that stores the certificate using the certificate setting device<u style="single">When the communication device receives a communication request to the first address, a long-term certificate that has a longer validity period than the short-term certificate that should be set by the certificate setting device is used. When there is a communication request to a second address different from the first address after performing the existing authentication process, the above is performed between the first means of performing the authentication process using the short-term certificate and the communication partner. When authentication processing using a long-term certificate is performed, a second means of validating only the certificate setting request that requires the storage of the short-term certificate among the requests from the communication partner is provided. And the above-mentioned certificate setting device to send a communication request to the above-mentioned first address of the above-mentioned communication device storing the above-mentioned long-term certificate.</u>The above communication device<u style="single">With</u>Perform authentication processing using the above long-term certificate<u style="single">Let's authenticate</u>If the process is successful, the above communication device<u style="single">On the other hand</u>, Above short-term certificate<u style="single">And the second step of sending the above certificate setup request requesting that the short-term certificate be remembered.</u>It is something like that.<u style="single">In such a certificate setting method, when the second means provided in the communication device is used for authentication processing using the long-term certificate with the communication partner, among the requests from the communication partner, In addition to the certificate setting request, the identification information transmission request for transmitting the identification information of the communication device to the communication partner is also used as a means for enabling the identification information transmission request, and in the second procedure, the certificate setting device is the communication device. The short-term certificate to be transmitted to the communication device may be a certificate with the identification information transmitted by the communication device in response to the identification information transmission request sent by the certificate setting device to the communication device.</u></p><p> Also,<u style="single">Another method of setting a certificate of the present invention is</u>Used for authentication processing for communication devices<u style="single">Certificate</u>In the certificate setting method to memorize using the certificate setting device<u style="single">、</u>With the above certificate setting device<u style="single">, Stores a long-term certificate, which is a certificate whose validity period is longer than the product life of the above communication device.</u>When the communication device performs an authentication process using the long-term certificate and the process is successful, the certificate setting device is used for the communication device, and the validity period is shorter than the product life of the communication device.<u style="single">Certificate</u>Remember the short-term certificate<u style="single">To let</u>It was done.</p><p> Also used for authentication processing in communication devices<u style="single">Certificate</u>In the certificate setting method to memorize using the certificate setting device<u style="single">、</u>With the above certificate setting device<u style="single">, Stores a long-term certificate, which is a certificate that does not expire during the operation of the above communication device.</u>When the communication device performs an authentication process using the long-term certificate and the process is successful, the certificate setting device expires to the communication device during the operation of the communication device.<u style="single">Certificate</u>Remember the short-term certificate<u style="single">To let</u>It was done.</p><p> Further, in the certificate setting method of storing the certificate used for the authentication process in the communication device by using the certificate setting device, the above certificate setting device and<u style="single">An expiration date has been set that has virtually no expiration date</u>When the communication device that stores the long-term certificate, which is a certificate, performs an authentication process using the long-term certificate and the process is successful, the certificate setting device sends the communication device an expiration date. It is designed to memorize a short-term certificate that is a certain certificate.</p><p> In each of these certificate setting methods, the inspection procedure for inspecting the quality of the communication device that stores the long-term certificate is executed, and the second procedure is executed for the device that has passed the inspection. It is good to set it to. Further, the certificate setting device may store the short-term certificate from an interface exposed to the outside of the communication device main body. Further, the interface may be a connector for connecting an Ethernet standard communication cable. Furthermore, the above authentication process may be an authentication process according to an SSL or TLS protocol.<u style="single">Further, the certificate setting device of the present invention is a certificate setting device that stores a certificate used for authentication processing in a communication device, and when the communication device requests communication to a first address, the certificate setting device is used. Authentication processing is performed using a long-term certificate, which is a certificate with a longer validity period than a short-term certificate, which is a certificate to be set by the certificate setting device, and communication is performed to a second address different from the first address. When there is a request, the first means of performing the authentication process using the short-term certificate and the communication partner when the authentication process using the long-term certificate is performed between the communication partner It is a communication device provided with a second means for validating only the certificate setting request requesting the storage of the short-term certificate among the requests, and the long-term certificate is stored in the certificate setting device. A means for transmitting a communication request to the first address of the communication device and performing an authentication process using the long-term certificate with the communication device, and when the authentication process is successful, the communication The device is provided with a means for transmitting the short-term certificate and the certificate setting request requesting that the short-term certificate be stored.</u><u style="single">Alternatively, in a certificate setting device that stores a certificate used for authentication processing in a communication device, the communication device stores a long-term certificate that is a certificate having a validity period longer than the product life of the communication device. A means for performing an authentication process using the long-term certificate between the two, and if the process is successful, a short-term certificate, which is a certificate whose validity period is shorter than the product life of the communication device, is provided to the communication device. It is provided with a means for memorizing.</u><u style="single">Alternatively, in a certificate setting device that stores a certificate used for authentication processing in a communication device, the communication device stores a long-term certificate that is a certificate that does not expire during the operation of the communication device. Means for performing authentication processing using the long-term certificate between the two, and if the processing is successful, the communication device stores a short-term certificate which is a certificate that expires during the operation of the communication device. It is provided with a means for making the user.</u><u style="single">Alternatively, in the certificate setting device that stores the certificate used for the authentication process in the communication device, the above-mentioned communication device that stores a long-term certificate that is a certificate with an expiration date that has virtually no expiration date. A means for performing an authentication process using the long-term certificate and a means for storing a short-term certificate, which is a certificate with an expiration date, in the communication device when the process is successful are provided. It is a thing.</u></p>

<p> The certificate setting method of the present invention as described above.<u style="single">And certificate setting device</u>According to this, when a certificate having a short validity period is set in a communication device, such a certificate can be set easily and safely.</p>

Hereinafter, the best mode for carrying out the present invention will be described with reference to the drawings. First, a configuration example of a communication system configured by using a lower device which is a communication device to which the certificate setting method of the present invention is applied and a higher device which is also a communication device and is a communication partner of the lower device will be described. .. FIG. 1 is a block diagram showing the configuration of the communication system. As shown in FIG. 1, this communication system is configured by connecting a higher-level device 10 and a lower-level device 20, which are communication devices each having a communication means, by a network 30. As the network 30, various communication lines (communication paths) capable of constructing a network can be adopted regardless of whether they are wired or wireless. Further, although only one lower device 20 is shown here, it is possible to provide a plurality of lower devices 20 in the communication system as shown in FIG.

First, such a communication system will be described from the hardware configuration of the upper device 10 and the lower device 20. The hardware configuration of the upper device 10 and the lower device 20 is as shown in FIG. 2 in a simplified manner. As shown in this figure, the host device 10 includes a CPU 11, a ROM 12, a RAM 13, an HDD 14, and a communication interface (I / F) 15, which are connected by a system bus 16. Then, the CPU 11 controls the operation of the upper device 10 by executing various control programs stored in the ROM 12 and the HDD 14, and realizes functions such as authentication of the communication partner and renewal of the digital certificate of the lower device 20. There is. In this specification, the digital certificate refers to digital data with a signature to prevent forgery.

The lower device 20 also has a CPU 21, ROM 22, RAM 23, HDD 24, and communication interface (I / F) 25 as in the case of the higher device 10, and these are connected by the system bus 26. The CPU 21 executes various control programs stored in the ROM 22 and the HDD 24 as necessary to control the device, thereby realizing functions as various means such as a communication means and a certificate setting means. ing. Regarding the communication I / F25, for example, in order to enable the lower device 20 to be connected to a LAN (local area network), an interface including a connector for connecting an Ethernet (registered trademark) standard communication cable is provided. Just do it. Of course, in this communication system, the upper device 10 and the lower device 20 can have various configurations according to the purpose of remote management, electronic commerce, and the like. Then, as the hardware of the upper device 10 and the lower device 20, a known computer can be appropriately adopted. Of course, other hardware may be added as needed, and the upper device 10 and the lower device 20 do not have to have the same configuration.

Next, as a part related to the feature of this embodiment of this communication system, the functional configuration of the part related to the setting of the certificate of the upper device 10 and the lower device 20 is shown in FIG. These functions related to the higher-level device 10 are realized by executing the required control program stored in the ROM 12 or HDD 14 by the CPU 11 of the higher-level device 10, and these functions related to the lower-level device 20 are This is realized by executing the required control program stored in the ROM 22, HDD 24, etc. by the CPU 21 of the lower device 20.

As shown in FIG. 3, the host device 10 includes an HTTPS (Hypertext Transfer Protocol Security) client function unit 31, an HTTPS server function unit 32, an authentication processing unit 33, a certificate renewal request unit 34, and a certificate storage unit 35. ing. The HTTPS client function unit 31 requests communication from a device having an HTTPS server function such as a lower device 20 by using an HTTPS protocol including authentication and encryption processing according to SSL, and also to a communication partner. It has a function to send a request (command) or data and execute an operation according to it.

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

As will be described later, the certificate renewal requesting unit 34 has a function of transmitting a normal public key certificate to a communication partner such as a lower device 20 and requesting that the public key certificate be stored in a predetermined case. The certificate to be transmitted here is issued by transmitting necessary information to the certificate management device (CA) 50 outside the communication system. The certificate storage unit 35 has a function of storing authentication information such as various certificates and private keys and using the authentication processing unit 33 for authentication processing. The types of these various certificates and private keys, their uses, and their creation methods will be described in detail later.

On the other hand, the lower device 20 includes an HTTPS client function unit 41, an HTTPS server function unit 42, an authentication processing unit 43, a request management unit 44, a certificate storage unit 45, a status notification unit 46, a log notification unit 47, and a certificate setting unit. 48, Equipped with command receiver 49. Similar to the HTTPS client function unit 31 of the host device 10, the HTTPS client function section 41 uses the HTTPS protocol to request communication from a device having an HTTPS server function such as the host device 10 and a request to transmit. 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 10, receives a communication request from a device having an HTTPS client function, and executes an operation according to the received request and data to each part of the device. It has a function to make the requester return a response to the requester. The function of the authentication processing unit 43 is the same as that of the authentication processing unit 33 of the higher-level device 10, but the certificate or the like used for the authentication processing is stored in the certificate storage unit 45. The request management unit 44 has a function of determining whether or not to execute an operation based on the request received from the higher-level device 10. Then, when the execution is permitted, it also has a function of transmitting an operation request to the function units 46 to 49 that execute the operation based on the request.

FIG. 4 shows the judgment criteria for whether or not this execution is possible. The judgment criteria are the type of request and the type of digital certificate used for the authentication processing in the authentication processing unit 43. The digital certificate stored in the upper device 10 and the lower device 20 will be described in detail later, but is a public key certificate that is a short-term certificate and has a shorter validity period than the long-term certificate. There are a key certificate and a rescue public key certificate, which is a long-term certificate and a public key certificate with a longer validity period than the short-term certificate. Normally, when the authentication process using the public key certificate is performed, all operations are permitted, but when the authentication process using the rescue public key certificate is performed, only the certificate setting operation is permitted. Therefore, the rescue public key certificate is a certificate used only when the lower device 20 stores a new normal public key certificate.

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 10, and is an authentication processing unit.<u style="single">43</u>It has the function of a certificate storage means to be used for the authentication process in. However, the stored certificates, etc. will be described later.<u style="single">Authentication processing department</u>Different from 33. The status notification unit 46 has a function of making a call to notify the upper device 10 of the state of the lower device 20 when an abnormality is detected or an instruction is given by the user. This notification may be transmitted as a response to an inquiry from the host device 10, or may be sent by requesting communication from the HTTPS client function unit 41 to the host device 10.

The log notification unit 47 has a function of notifying the log from the lower device 20 to the higher device 10. As the content of the notification, in addition to the operation log of the lower device 20, for example, the count value of the image forming number counter in the case of the image forming device, the measuring value thereof in the case of the measuring system, and the like can be considered. Since this notification is not urgent, it may be sent as a response to an inquiry from the host device 10. The certificate setting unit 48 has a function of a certificate setting means for setting and updating the certificate or the like stored in the certificate storage unit 45 by the ordinary public key certificate or the like received from the host device 10 and described later. The command receiving unit 49 has a function of executing an operation corresponding to a request related to a function other than the above-mentioned functional units 46 to 48. Examples of this operation include transmission of data stored in the lower device 20 and control of the operation of the engine unit as needed. The status notification unit 46 and the log notification unit 47 are shown as specific examples of the functions provided by the command reception unit 49, and it is not essential to provide such functions.

Next, a communication method between the upper device 10 and the lower device 20 in this communication system will be described. FIG. 5 is an explanatory diagram showing an outline of the communication method. In this communication system, when the host device 10 intends to communicate with the host device 20, it first requests the host device 20 to communicate. Then, when the lower device 20 is authenticated as a legitimate communication partner by the authentication process according to the SSL protocol as described with reference to FIG. 19 or 21 in the section of the prior art, communication with the lower device 20 is performed. I am trying to establish. This authentication process is called the SSL handshake. However, mutual authentication as shown in FIG. 19 is not essential, and one-way authentication as shown in FIG. 21 may be used. In this process, the lower device 20 sends its own public key certificate to the higher device 10 to be authenticated. Then, in the case of mutual authentication, the upper device 10 also sends its own public key certificate to the lower device 20 to be authenticated, but in the case of one-way authentication, this authentication is not performed.

When the above authentication is successful, the higher-level device 10 generates a request for processing the method of the application program implemented by the lower-level device 20 as a SOAP message 60 described in the structured language format XML format, and HTTP. It is sent to the lower device 20 as an HTTP request according to (Hyper Text Transfer Protocol). Such a request is called RPC (Remote Procedure Call). Then, the lower device 20 executes a process according to the content of this request, generates the result as a SOAP message 70 of the response, and sends it to the higher device 10 as an HTTP response. Here, these requests and responses are encrypted and transmitted using the common key exchanged in the processing of the SSL handshake to ensure the security of communication.

Further, by these requests and responses, this communication system functions as a client-server system in which the upper device 10 is a client and the lower device 20 is a server. On the contrary, there is a case where the lower device 20 requests communication from the upper device 10 and functions as a client / server system in which the lower device 20 is a client and the upper device 10 is a server. In addition to the above technologies, known protocols (communication standards), technologies, such as FTP (File Transfer Protocol), COM (Component Object Model), and CORBA (Common Object Request Broker Architecture), are required to realize RPC. Specifications etc. can be used.

Next, the characteristics and uses of each certificate and key, which are the authentication information used by the above-mentioned upper device 10 and the above-mentioned lower device 20 for the above-mentioned authentication process, will be described. In FIG. 6, (a) shows the types of certificates and keys stored in the lower device 20 as authentication information, and (b) shows the types of certificates and keys stored in the upper device 10 as authentication information. It is a figure which shows. As shown in FIG. 6, the upper device 10 and the lower device 20 shown in FIG. 1 roughly store normal authentication information and rescue authentication information. Each of these authentication information is composed of a public key certificate and a private key, which are authentication information about oneself, and a root key certificate, which is authentication information about a communication partner.

Further, for example, the normal public key certificate for the lower device is a digital signature that can confirm the validity of the normal public key issued by the certificate management device 50 to the lower device 20 by using the normal root key for authentication of the lower device. It is a digital certificate with a mark and corresponds to a short-term certificate. Here, as the format of the public key certificate, for example, the one shown in FIG. 7 can be used, and the public key certificate can be used. other things, issuer and expiration date of the certificate, subject as evidenced (Certificate Information such as the device or user to whom the issue is issued is described. Specifically, it can be created according to a format called X.509, for example, and the public key certificate created according to this format is as shown in FIG. 8, for example. In this example, A indicates the identification information of the CA, and C indicates the identification information of the device to which the certificate is issued. Each of these includes information such as location, name, machine number or code. In addition, B indicates the validity period, and the validity period is specified by the start date and time and the end date and time.

It is not essential to include the machine number information in the identification information attached to the public key certificate only for the purpose of identifying the device, but here, the identification information should include the same information as the machine number information. This is to meet the demands of operating a communication system. That is, when this communication system is used for device management, the device is often specified by the machine number information, but when the identification information does not include the machine number information, the higher-level device 10 side uses the identification information. It becomes necessary to separately manage the correspondence with the machine number information as a table or the like. When performing such management, it is necessary to add data every time a new lower device 20 is produced, and the number of lower devices 20 may be tens of thousands, hundreds of thousands, or more. Therefore, it becomes necessary to manage a very large amount of data, which increases the management burden. However, if the identification information attached to the public key certificate includes the same information as the machine number information, the machine number of the communication partner can be directly specified in the authentication process. Therefore, by doing so, it is not necessary to manage the correspondence between the identification information attached to the public key certificate and the machine number information, and the management burden can be reduced. Of course, it is not necessary to describe such machine number information in the certificate, and conversely, information such as the model number of the lower device 20 and registered users may also be described.

Further, the normal private key for the lower device uses the private key corresponding to the above-mentioned normal public key, and the normal root key certificate for lower device authentication uses the root private key corresponding to itself for the normal root key for lower device authentication. It is a digital certificate with a digital signature that can be verified by itself. Even if a plurality of lower devices 20 are provided, the digital signature attached to the ordinary public key of each device is attached using the same root private key, and the ordinary root key certificate required for validity confirmation is shared. However, the normal public key included in the normal public key certificate and the corresponding private key are different for each device. The same relationship applies to the normal public key certificate for the higher-level device, the normal private key for the higher-level device, and the normal root key certificate for authentication of the higher-level device.

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

By the way, these public key certificates and private keys are stored in a rewritable non-volatile storage means such as a flash memory constituting ROM22 or RAM23. Therefore, when replacing a part including such a storage means due to damage or the like, the stored public key certificate or private key is removed together with the removed old part. In such a case, in order to enable authentication using the normal public key certificate (authentication using the normal certificate set) again, it is necessary to memorize the removed certificate or key again.

Here, assuming that each device can only authenticate using a normal public key certificate, in a state where this authentication cannot be performed, a new normal public key certificate or the like can be safely applied to the target device via the network 30. There is no way to send it to. However, each device constituting this communication system stores rescue authentication information in order to deal with such a situation, and by using this, the communication partner is authenticated using two different types of digital certificates. I am trying to be able to do it. Then, by using the rescue authentication information, it is possible to securely send and receive a new ordinary public key certificate or the like to the necessary device via the network 30.

However, the major 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 that have the same identification information of the issuing device and are issued to the same device, as indicated by reference numerals F and I. However, the 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 code E, while the rescue public key certificate is valid. As indicated by the symbol H, the validity period of the book is 50 years from midnight on January 1, 2000 to midnight on January 1, 2050. The issuer of the certificate is the CA of the same xxx company, but the normal public key certificate is indicated by the code G as "Regular CA", and the rescue public key certificate is indicated by the code D as "Rescue CA". It is a different CA.

Such a rescue public key certificate with a long validity period is slightly inferior in security to a normal public key certificate with a short validity period. However, since such a rescue public key certificate has a long expiration date, it is unlikely that it will become unusable due to the expiration date. Therefore, if the rescue authentication information is stored in advance at the time of manufacturing the component including the certificate storage area, the communication partner can be authenticated within the valid period of the rescue public key certificate. Then, if such authentication is successful, a secure communication path using the common key cryptography can be provided by sharing the common key with the communication partner as described above. Therefore, using this communication path, it is possible to send and receive a new public key certificate to and from the communication partner and set it. Therefore, it is possible to stock parts for a long period of time and promptly respond to the need for replacement.

In addition, when the authentication process is performed using the rescue authentication information, if only a limited request such as the update of the regular authentication information such as the normal public key certificate is allowed to be executed, the validity period can be set. Even if the safety is slightly reduced due to the lengthening, it is not a big problem. In addition, considering this point, it is necessary to set the rescue public key certificate again after the validity period of the rescue public key certificate has elapsed. Therefore, it is preferable that the rescue public key certificate has a long validity period. Specifically, for example, it is preferable to set an effective period longer than the product life of the storage device. This product life is an assumed operating period or an estimated operating period of the device, and can be determined from the expected usage period, the estimated useful life, the quality assurance period of the device, and the like at the time of development. Also, if the validity period of the rescue public key certificate is set longer than the period expected to be able to operate normally while maintaining the device, the rescue public key certificate will expire during the operation of the device. It can be said that there is no certificate. Therefore, during the operation of the device, it is possible to maintain a state in which authentication using the rescue public key certificate (authentication using the rescue certificate set) is always possible. Therefore, for devices and parts manufactured by storing the rescue public key certificate once, the expiration date of this certificate does not expire during stock and it is not necessary to renew it.

Further, it is even better if the effective period is set to be extremely longer than the above-mentioned product life and the operating period of the device. In the example shown in Figure 8, the validity period is set to 50 years, which is considered sufficient for a normal device, but this means that the maximum validity period that can be set according to the X.509 format is 50 years. Therefore, it goes without saying that a longer period, for example, 100 years or hundreds of years, may be set just by doing this. When the validity period is set in this way, the end of the validity period is simply stated by the format request of the public key certificate, and it can be considered that the rescue public key certificate has virtually no expiration date. it can. In addition, depending on the target device, it may be possible to think in the same way even if the validity period is about 20 years, 30 years or less. Furthermore, even if the validity period of the rescue public key certificate is shorter than the product life, if it is longer than the validity period of the normal public key certificate, the device or component is better than the case where the normal public key certificate is stored. It is possible to obtain the effect of extending the stockable period of. Normally, the validity period of the public key certificate may be set as appropriate in consideration of security, but this period is shorter than the product life and the expiration date is such that the device expires during operation. Often becomes.

Further, here, the device identification information is not described in the bibliographic information of the rescue public key certificate, and the devices of the same rank (in the example shown in FIG. 1 or FIG. 20, the ranks of the upper device and the lower device are different. All of them can store the same rescue public key certificate (assuming they exist). In this case, since it is not necessary to distinguish each device of the same rank individually, the rescue public key included in the certificate and the corresponding rescue private key may be completely common. Since all the rescue public key certificates of the communication partner are the same, the root key certificate is common to all the devices that are the communication partners of the device of a certain rank. That is, even if a plurality of lower devices 20 are provided, the same rescue authentication information is stored in all the lower devices 20. This also applies to the rescue authentication information of the host device 10. Then, in order to unify the data format with the normal public key certificate, in the example shown in FIG. 10, 0 is described as the machine number of the issuing device to indicate that it is a rescue public key certificate. .. It is also possible to indicate this by leaving the "Subject" item blank.

It is not essential to do this, but if the rescue authentication information can be shared by all devices of the same rank, the part will be installed when the part with the certificate storage area is manufactured. It is possible to uniformly store the items corresponding to the ranks determined according to the model of the device. If the component stores such rescue authentication information and does not normally store the authentication information, it can be used in common regardless of the device identification information because the device identification information is not required at the time of manufacturing. It can be produced as a part.

If the rescue public key certificate is not attached with the device identification information, the device of the communication partner cannot be specifically specified even if the rescue public key certificate is used for authentication. .. However, some information about the communication partner can be obtained. That is, for example, a vendor stores the rescue certificate set for the lower device in all the devices corresponding to the lower device 20 among the company's products, and rescues the rescue certificate set for the higher device in all the devices corresponding to the higher device 10 which is the communication partner. If the certificate set is stored, if the authentication is successful, the lower device 20 has sent a public key certificate that can be verified with the rescue root key certificate for higher device authentication that it remembers. It can recognize that the other party is the higher-level device 10 of the same vendor, and conversely, the higher-level device 10 also sends a public key certificate that can confirm the validity with the rescue root key certificate for lower-level device authentication that it remembers. It can be recognized that the other party is a lower device 20 of the same vendor.

Therefore, it is possible to make a certain degree of judgment as to whether or not the device requesting communication or the device requesting communication is an appropriate device as a communication partner even if the identification information cannot be referred to. Then, if such authentication is successful, the common key can be shared with the communication partner and a secure communication path using the common key cryptography can be provided as described above. It is also possible to exchange and identify the communication partner.

By the way, since the lower device 20 that functions as a server cannot identify the other party who requested the communication during the SSL handshake, basically, the same public key certificate is sent to all the other parties. However, in this communication system, it is necessary to use the normal public key certificate and the rescue public key properly depending on the situation. Therefore, next, the configuration for proper use will be described with reference to FIG. In the SSL protocol, the server cannot know the status of the client when the client requests communication, so inevitably, the same public key is used whenever a specific URL (Uniform Resource Locator) is accessed. You will provide the certificate. Therefore, basically, it is not possible to have a plurality of ordinary public key certificates and select and send an appropriate one according to the type of the ordinary root key certificate possessed by the communication partner. However, if the address that accepts the communication request is different, it is possible to return a different public key certificate for each address. This address can be determined, for example, by a URL.

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

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

Therefore, in this communication system, even if the upper device 10 and the lower device 20 basically perform authentication using a public key certificate and are removed by exchanging parts, a new one is used. It is possible to secure a secure communication path by performing authentication using the rescue public key certificate stored in the parts after the parts are mounted. This is because even in the case of authentication using the rescue public key certificate, the common key can be shared in the same manner as in the case of the normal public key certificate. Then, by transmitting and storing the normal authentication information for setting from the upper device 10 to the lower device 20 using this communication path, it is possible to return to the state where the authentication using the normal authentication information is possible again.

Also, even with authentication using a rescue public key certificate, the other party's device can be identified to some extent as described above, so for example, the normal public key certificate should be sent only to the device manufactured by the company. It is possible to impose restrictions such as the above, and it is possible to prevent the public key certificate from being sent to an unauthorized device and stored. As described above, in this communication system, by using the rescue authentication information in addition to the normal authentication information, even if it becomes necessary to replace the part that stores the certificate required for the authentication, it can be easily and promptly performed. It can be easily restored to a state where normal authentication can be performed.

The authentication information shown in FIG. 6 must be stored when the upper device 10 and the lower device 20 perform mutual authentication, but the lower device 20 functions as a server and the upper device 10 is used. When only one-way authentication for authenticating the lower device 20 is performed, it is not necessary to memorize some certificates and the like. For both the normal authentication information and the rescue authentication information, the lower device 20 does not require the root key certificate for higher device authentication, and the higher device 10 requires the higher device public key certificate and the higher device private key. Is no longer needed. Further, in the lower device 20, the storage area for storing the above-mentioned normal certificate set and rescue certificate set may be provided on a common component, and this is used here. As this component, for example, a memory card or memory unit equipped with flash memory or NVRAM constituting ROM 22 or RAM 23, or a CPU board equipped with a rewritable non-volatile memory together with CPU 21 can be considered. The same applies to the host device 10.

Next, a part provided with a storage area for such a certificate set and a manufacturing process of the lower device 20 equipped with the part will be described. In this manufacturing process, a normal certificate set is set in the lower device 20 according to the embodiment of the certificate setting method of the present invention. First, FIG. 12 shows an outline of these manufacturing processes. In this figure, the part related to the setting of the certificate set is mainly shown, and the other parts are shown in a greatly simplified manner.

As shown in this figure, when the lower device 20 is manufactured, the component A provided with the storage area of the certificate set is first manufactured in the component manufacturing process. In this process, the component A is assembled and inspected. As for the inspection contents here, when the component A is a CPU board, it is conceivable to inspect whether or not each chip provided on the board can be accessed from the CPU. After that, the software copying device 130 in the factory writes the rescue certificate set for the lower device 20 together with the software used for controlling the lower device 20 to be stored in the component A. At this point, it is not possible to establish a secure communication path over the network between the software copying device 130 and component A, and the rescue certificate set has a greater impact if leaked than the normal certificate set. , Writing should be done directly using a dedicated jig. When the part A is completed and distributed as a part, it will be packed and shipped. Here, if the device identification information is not described in the rescue public key certificate, the rescue certificate set to be written is determined according to the model and rank of the device to which the part A is mounted. You can store it in 130. Further, when the component A is a standardized memory card or the like, it may not be necessary to assemble it.

On the other hand, when the part A is used for manufacturing the lower device 20, the rescue certificate set is written, and the part A that stores the rescue certificate set is sent to the product assembly process, and the main body of the lower device 20 being assembled. Attach it to the part. In this embodiment, this procedure corresponds to the first procedure. Then, after the assembly of the lower device 20 is completed, the functional inspection is performed to inspect the quality. As the inspection content here, it is conceivable to inspect whether or not the CPU on the CPU board can access a device outside the board, for example, a communication I / F25 or the like. In this embodiment, this procedure corresponds to an inspection procedure.

Then, a machine number is assigned to the device that has passed the inspection. After that, prepare a normal certificate set that includes the machine number as device identification information in the normal public key certificate, store it in the lower device 20 by the certificate writing device 160, and also store the machine number information and initial setting values of the device. It is memorized in this process. In this embodiment, this procedure corresponds to the second procedure. After that, the appearance is inspected, packed and shipped. The lower device 20 can be manufactured by the above steps. Further, although the rescue certificate set to be stored is different, the higher-level device 10 can be manufactured by the same process. The parts manufacturing process and the product assembly process are often performed in separate factories.

Further, FIG. 13 shows an explanatory diagram of a process of storing each certificate set in the component A. As shown in this figure, the part A stores only the rescue certificate set in the part manufacturing process, and usually does not store the certificate set. Then, in this state, it is completed as a part that can be used as both a part used for assembling a new device in the product assembly process and a replacement part (service part) for a device sold on the market. Then, when the part A is attached to the device in the product assembly process at the device assembly factory, the device passes the inspection, the machine number is given to the device, and then the certificate is a certificate setting device. The writer 160 usually writes and sets the certificate set. At this time, the machine number of the device to be written is input from the machine number information input device 161 to the certificate writing device 160, and the certificate writing device 160 acquires a normal certificate set including the machine number information as identification information. Will be written. This normal certificate set is issued by the certificate management device 50, which is a CA that manages the normal public key certificate.

At this time, after connecting the certificate writing device 160 and the lower device 20, communication is requested from the certificate writing device 160 to the rescue URL of the lower device 20, and the rescue certificate set stored in the lower device 20 is stored. Use to perform SSL authentication processing. Then, when the certificate writing device 160 authenticates that the lower device 20 is a legitimate device, it sends a normal certificate set together with a certificate setting request so that it can be written to the normal certificate set storage area of part A. There is. That is, the certificate writing device 160 and the lower device 20 communicate using the rescue public key certificate, and the certificate writing device 160 stores the normal certificate set in the lower device 20 by the communication.

Here, the flowchart of FIG. 14 shows the process executed on the lower device 20 side when writing the normal certificate set. When the communication partner requests communication from the rescue URL, the lower device 20 starts the process shown in the flowchart of FIG. In this process, first, in step S201, the rescue public key certificate for the lower device is encrypted with the rescue private key for the lower device in order to be authenticated by the communication partner (here, the certificate writing device 160). Send to the communication partner with a random number. This process corresponds to the process of steps S21 and S22 of FIG.

When the communication partner receives the certificate and the random number transmitted by the lower device 20, the communication partner performs the authentication process using the certificate and the random number, and returns the result as a response. If the authentication is successful, the seed of the common key is transmitted to the lower device 20 and the common key is created to be used for the subsequent communication. For the authentication here, the rescue root key certificate for subordinate device authentication is used, and this process corresponds to the process of steps S12 to S17 in FIG. Upon receiving this authentication result, the lower device 20 determines whether or not the authentication was successful in step S202, and if it fails, the process ends as it is, but if it succeeds, the lower device 20 proceeds to step S203 and receives the common key. Create a common key using the seeds of and use it for subsequent communication. These processes correspond to the processes of steps S25 and S26 in FIG.

After that, the process waits for the request to be received in step S204, and when the request is received, the process proceeds to step S205. Then, as described with reference to FIG. 4, the requirements management unit 44 of the lower device 20 permits only the certificate setting operation when the authentication is performed using the rescue public key certificate. Therefore, it is determined whether or not the request received in step S205 is a certificate setting request. If it is not a certificate setting request, the request is ignored and the process returns to step S204 to wait for the next request. Here, a response to the effect that the request cannot be accepted may be returned.

If the certificate setting request is made in step S205, the process proceeds to step S206 to store the certificate set received (obtained from the communication partner) together with the certificate setting request in the normal certificate set storage area of part A, and FIG. ) Is set in the normal certificate set shown in). In this process, the CPU of the lower device 20<u style="single">21</u>Functions as a certificate setting means. After that, in step S207, the setting result is notified to the sender as a response, and the process ends. By performing such processing by the subordinate device 20, the certificate writing device 160 can perform at least a minimum confirmation that the subordinate device 20 is a write target of the normal certificate set, and thus is completely different. It is possible to prevent a situation in which a normal certificate set is accidentally sent to the device and improve the security of the certificate setting.

Further, the rescue certificate set may be stored on the certificate writing device 160 side as well, and mutual authentication may be performed with the lower device 20 in the authentication process. The rescue certificate set used in this case is the same as that stored in the upper device 10, and the authentication process on the lower device 20 side also corresponds to the process shown in FIG. Then, in this way, even on the lower device 20 side, it is possible to prevent the normal certificate set sent from the invalid certificate writing device from being set. Even if the certificate writing device 160 only sends the rescue public key certificate to the lower device 20 and is authenticated, this effect can be obtained, and between the certificate writing device 160 and the lower device 20. It is also possible to establish a secure communication path by SSL. Further, regarding the communication request, it is conceivable that the lower device 20 side makes a communication request to the certificate writing device 160. Even in this case, the certificate writing device 160 and the lower device 20 perform the authentication process using the rescue public key certificate, and if this is successful, the certificate writing device 160 sends the normal public key certificate to the lower device 20. It is the same as the case of the above-mentioned processing.

On the other hand, in FIG. 13, when the part A is shipped as a service part and mounted on the lower device 20 (market machine) operating at the installation site, it is usually certified by the lower device 20 and the corresponding upper device 10. The book set will be written. At this time, the machine number of the device to be written is input from the machine number information input device 171 to the higher-level device 10, and the higher-level device 10 inputs the normal certificate set including the machine number information as identification information to the certificate management device 50. It will be issued, acquired, and set in the lower device 20. The identification information such as the machine number of the lower device 20 may be transmitted from the lower device 20 to the higher device 10 in response to a request from the higher device 10.

At this time, communication is requested from the higher-level device 10 to the rescue URL of the lower-level device 20, and the rescue certificate set stored in the lower-level device 20 is used to perform SSL authentication processing. Then, when the upper device 10 authenticates that the lower device 20 is a legitimate device, the normal certificate set is transmitted and set in the normal certificate set storage area of the component A. In this case, the higher-level device 10 functions as a certificate setting device, performs authentication processing using the rescue public key certificate with the lower-level device 20, and if the authentication processing is successful, the lower-level device 20 is assigned. Normally, the certificate set will be stored. In this case, the processing performed on the lower device 20 side is the same as that shown in the flowchart of FIG. Of course, mutual authentication may be performed. The effect of this is the same as when writing with the certificate writing device 160, but after shipping, you do not know what kind of device it will be connected to, and the safety will be improved compared to in a factory where the connection target is limited. It can be said that the demand for is strong. It is also possible to adopt one-way authentication in which the upper device 10 is authenticated by the lower device 20. Further, the lower device 20 may make a communication request to the higher device 10 as in the case of writing by the certificate writing device 160 described above.

As is clear from the above description, according to the method described here, the lower device 20 stores the normal certificate set in the same procedure at the time of production at the factory and at the time of parts replacement in the market. be able to. In addition, authentication is performed using the rescue certificate set stored in the component in advance, and if this is successful, the normal certificate set is stored, so communication via the communication I / F 25, which is a normal network I / F, is performed. Can also be used to safely set the normal certificate set to the subordinate device 20. Therefore, it is not necessary to provide a special I / F for setting the certificate in the lower device 20, and the cost can be reduced.

In addition, since the validity period of the rescue public key certificate is at least longer than the validity period of the normal public key certificate, as described above, the stockable period of parts and devices is longer than when the normal public key certificate is stored. You can get the effect that you can extend. In addition, as shown in Fig. 13, after storing the normal certificate set in the product assembly process, it seems that the normal public key certificate has expired before it is shipped or installed in the user environment. Even in such a case, as long as the rescue public key certificate is valid, the new normal certificate set can be safely set again by the same procedure as in the case of parts replacement of the market machine. Therefore, even if the normal certificate set is set in the manufacturing process, the stockable period of the completed device can be extended.

Further, since the network I / F is an I / F that is used even during the normal operation of the lower device 20, it is usually provided in a state of being exposed to the outside of the device main body. Therefore, by using such an I / F, it is possible to facilitate the work related to the certificate setting at the time of manufacturing the device. And since no special jigs or I / Fs are usually used when setting the public key certificate, it should be set as easily as when it is manufactured at the vendor's own factory even after distribution to the OEM manufacturer or the market. Can be done. On the other hand, when the rescue certificate set is stored in the parts, it can be directly performed by using a dedicated jig, so that the safety can be ensured without any particular authentication or the like. At the component stage, it is easy to install the I / F of the dedicated jig at a position where it is easy to connect, so there is no inconvenience even if the dedicated jig is used.

Even if the lower device 20 stores the normal public key certificate (as part of the normal certificate set) with the machine number information as the device identification information, the machine number is still used. In order to prevent missing numbers, it is common to attach the device to a device that has been assembled and has passed the quality inspection. Therefore, if the public key certificate including the machine number information is to be stored in the manufacturing process of the device, it is necessary to perform the assembly in a completely completed state. In such a case, the interface (network I / F) normally used in the lower device 20 is used.<u style="single">PHY</u>The effect of memorizing through) is particularly large. Due to design, function, and cost constraints, it is difficult to provide a connection port for a special interface so that it is in a position and configuration that is easy to work with when the device has been assembled.

Then, in the lower device 20 described here, since it is possible to write the normal certificate set via the network, the Ethernet exposed to the outside of the device body even after the assembly of the device is completed. It is possible to connect to the certificate writing device 160 via the connection I / F of the network cable such as the standard, and to perform the writing work of the normal certificate set. Therefore, efficient work can be performed with a small number of man-hours, and there is extremely little risk of damage to the device during work. Further, since the communication can be encrypted in this writing process, the normal certificate set can be safely stored. It is not essential to connect the certificate writing device 160 and the lower device 20 via this network I / F. Even when other I / Fs are used, the security of the certificate setting is improved by performing authentication using the rescue public key certificate stored in the parts when setting the normal public key certificate. be able to. Further, when information other than the machine number, for example, a unique ID is used as the device identification information, it is not essential to store the normal public key certificate after the quality inspection. However, if the device is stored after the quality inspection, it is possible to prevent the device that stores the certificate from failing the quality inspection and causing a missing number in the identification information. Therefore, certificate management becomes easy.

In addition, since the use and function of the normal public key certificate and the rescue public key certificate are different, it is preferable that these certificates are issued by different CAs as shown in FIG. That is, since the rescue public key certificate stores the same thing in all devices of the same rank, it becomes extremely difficult to maintain security if the rescue root private key is leaked, so it is necessary to maintain confidentiality particularly strictly. On the other hand, it is not usually necessary to create and store different certificates for each device. Therefore, it is advisable to attach importance to safety and use a CA that cannot be accessed from the outside.

On the other hand, since the normal public key certificate can be renewed as needed, even if the normal root private key is leaked, security can be maintained by renewing it. Since it is necessary to individually create and store a certificate for each device, it is preferable to use a CA connected to an open network such as the Internet. The CA is further subdivided, and the CA is divided according to the rank of the device to which the certificate is issued, such as the CA that issues the certificate of the lower device and the CA that issues the certificate for the higher device. May be good. It is also possible to use digital certificates with completely different formats for the normal public key certificate and the rescue public key certificate.

Next, the equipment usually used to set the certificate set in the lower device 20 in the above-mentioned product assembly process will be described. FIG. 15 is a block diagram showing a schematic configuration thereof. As shown in this figure, in the production factory E where the product assembly process is performed, a production control system 140, a communication terminal 150, and a certificate writing device 160 are usually installed as equipment for setting a certificate set. Then, the production control system 140 manages the daily production number of devices such as the upper device 10 and the lower device 20.

The communication terminal 150 includes a certificate database (DB) 154a, an input device 156, and a display device 157. Then, information on the number of units produced for each model and the model number to be assigned (here, information including the model code and serial number) is acquired from the production control system 140. In addition, based on that information, the certificate management device 50, which is the CA that issues the normal public key certificate, issues a normal certificate set to be stored in the device to be produced, obtains this, and makes the certificate DB154a. Remember. The certificate writing device 160 includes a machine number information input device 161 and receives input of the machine number of the device being produced from the machine number information input device 161 at the time of production of the device. Then, when this is input, the normal certificate set corresponding to the machine number is obtained from the communication terminal 150, transmitted to the corresponding device, and stored in the non-volatile memory of the device. Set in the area. When the lower device 20 is produced, it is set in the storage area provided in the component A.

Next, FIG. 16 shows an outline of the situation around the communication terminal 150 and the certificate writing device 160 in the production factory E. In the production factory E, the communication terminal 150 is installed in the administrator room F in consideration of security. Then, the administrator room F locks the door G so that only a specific administrator can enter, and the communication terminal 150 can be operated only when a specific ID and password are entered. I have to. Further, in this example, the production factory E is provided with the production line 1001 of the upper device 10 and the production line 1002 of the lower device 20. Then, a certificate writing device 160 (160a, 160b) is installed for each production line.

Each of the certificate writing devices 160 has an I / F 162 (162a, 162b) for inputting machine number information for connecting to the machine number information input device 161 (161a, 161b), and a device for producing (upper device 10). And the writing I / F 165 (165a, 165b) for connecting to the lower device 20) is connected, respectively. In such a production line, for example, in the case of producing the lower device 20, a rated name plate is affixed when assigning an identification number to a device that has passed the quality inspection. An example of this rated name plate is shown in FIG. 17, and the rated name plate shows the model number of the device together with information such as rated voltage and power consumption. In addition, the barcode BC showing the information of this machine number is also described.

Then, in the normal certificate set setting process, first, the certificate writing device 160 and the lower device 20 to be set are connected using an Ethernet standard crossover cable as the writing I / F 165. The reason why the cross cable is used here is that each device produced has the same IP address as the initial value, and when the certificate writing device 160 and the LAN connection are made, the IP addresses are duplicated. Subsequently, a bar code reader is used as the machine number information input device 161, the bar code BC on the rating plate is read, and the machine number information of the device to be worked is input to the certificate writing device 160. Then, the certificate writing device 160 obtains the normal certificate set corresponding to the machine number from the communication terminal 150, transmits it to the lower device 20 connected via the writing I / F 165, and provides it in the component A of the device. Set in the normal certificate set storage area. Through the above work and processing, each lower-level device 20 to be produced can easily store a normal public key certificate in which the machine number information is attached as device identification information.

In the embodiment described above, an example in which authentication according to SSL as described with reference to FIG. 19 or 21 is performed between each device including the upper device 10 and the lower device 20 has been described. .. However, this embodiment is effective even if this certification is not necessarily such. TLS (Transport Layer Security), which is an improved version of SSL, is also known, but it can of course be applied when performing authentication processing based on this protocol.

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

Therefore, there is a demand to manufacture and sell a device that stores a certificate with low security strength, and then to be able to store a certificate with high security strength after the fact according to the usage environment. For example, it is conceivable that the system operator may devise various authentication processing contents or select a highly reliable CA to improve security. In such a case, one device is used as one system. When moving from to another system (including the case of simply changing the settings), it may be necessary to replace the certificate used for normal authentication processing. In addition, it is possible that a defect will be discovered later in a highly secure certificate and it will be necessary to change the authentication processing method.

In such a case, using the configuration of the above-described embodiment, a component storing a certificate having low security strength is attached to the communication device, and then the certificate is used with the certificate setting device. When the authentication process is performed and the process is successful, the certificate setting device stores the certificate with high security strength in the communication device, so that the certificate with high security strength can be obtained after the device is manufactured or shipped. Even if it is set after the fact, it can be set easily and safely. In addition, by storing a certificate with relatively low security that can be commonly used in various environments in the parts and devices to be manufactured, the parts can be commonly used in various environments. Therefore, the supply of parts and devices becomes easy.

Further, in the above-described embodiment, an example in which the device identification information is described in the normal public key certificate has been described, but the device identification information is not included in the normal public key certificate, and the devices of the same rank are included in the device. All the same public key certificates may be stored. Even if this is done, it is still possible to identify the communication partner by sharing the common key with the communication partner and establishing a secure communication path using common key cryptography, and then exchanging model machine number information and the like. What is possible is the same as for the rescue public key certificate. Even if this is done, it is possible to obtain higher security than the rescue public key certificate because the expiration date is short.

Further, in the above-described embodiment, an example in which the certificate management device 50 is provided separately from the higher-level device 10 has been described, but it does not prevent the certificate management device 50 from being provided integrally with the higher-level device 10. In this case, parts such as CPU, ROM, RAM, etc. for realizing the functions of the certificate management device 50 may be provided independently, but the CPU, ROM, RAM, etc. of the higher-level device 10 are used, and the CPU is used. It may be made to function as the certificate management device 50 by executing appropriate software. In such a case, for communication between the certificate management device 50 and the higher-level device 10 integrated with the certificate management device 50, a process for making the hardware function as the certificate management device 50 and the hardware are required. It shall include interprocess communication with the process for functioning as the host device 10.

Further, in the above-described embodiment, an example in which the certificate management device 50 creates a root key or a digital certificate by itself has been described, but the certificate management device 50 specializes in managing keys and certificates and is another device. You may obtain a root key or digital certificate from the company.

Further, in the above-described embodiment, the communication system is configured by only the upper device 10 and the lower device 20, but it can also be applied to the case where the communication system is configured by including other devices. For example, an intermediary device that mediates communication between the upper device 10 and the lower device 20 may be provided, and the upper device 10 and the lower device 20 may send and receive requests and responses via this intermediary device. Alternatively, a higher-level device of the higher-level device 10 may be provided. In this case, if the higher-level device 10 is regarded as the "lower-level device" and the higher-level device is regarded as the "upper-level device", these devices can be handled in the same manner as in the above-described embodiment.

In addition, conventionally, image processing devices such as printers, facsimile (FAX) devices, digital copiers, scanner devices, and digital multifunction devices equipped with communication functions have been used as managed devices, and management devices capable of communicating with these managed devices. Has proposed a remote management system for remotely managing these managed devices. For example, in an image processing device provided with an image forming means, an image is generally formed on plain paper by using a photoconductor electrostatic process, but from a mechanism for performing such a photoconductor electrostatic process, Due to the high rate of troubles (abnormalities) and the need for regular overhauls to maintain performance, we have adopted a maintenance management service system. Then, for the purpose of enhancing this maintenance management, as a remote management system in which the image forming apparatus is a managed device, a communication device is provided inside or outside the image forming apparatus and installed in the image forming apparatus and the service center (management center). A system has already been developed and operated in which the management device is connected to the management device via a public line (telephone line) and the management device is notified when an abnormality occurs in the image forming device.

The above-described embodiment is also applicable to the case where a digital certificate is set for the managed device in such a remote management system. In this case, the managed device is a subordinate device and the managed device is managed. A device that collects information on a plurality of managed devices in the user environment may be used as a host device. In the case of remote management, since there is often no operator of the management device near the managed device, it is necessary to identify the managed device by communication. Then, a mechanism for guaranteeing that the managed device identified by communication is certainly the device is required. Therefore, as described in the above-described embodiment, the normal public key certificate can be easily set at the time of manufacturing and after installation in the user environment, and the authentication using the normal public key certificate can be easily operated with high reliability. The effect of being able to do it is great.

The target of remote management is not limited to image processing equipment, but network home appliances, vending machines, medical equipment, power supply equipment, air conditioning systems, measurement systems for gas, water, electricity, etc., automobiles, aircraft, general-purpose computers, etc. It is conceivable to use a communication device in which various electronic devices have a communication function as a managed device. However, it goes without saying that the lower device 20 is not limited to the managed device in the remote management system.

As described above, the certificate setting method of the present invention.<u style="single">And certificate setting device</u>According to this, when a certificate having a short validity period is set in a communication device, such a certificate can be set easily and safely. Therefore, it is possible to easily manufacture a communication device and operate a communication system using a certificate with identification information of the device with high reliability.

<figref num="1">It is a block diagram which shows the configuration example of the communication system including the lower-order device which is the communication device which applies the certificate setting method of this invention.</figref><figref num="2">It is a block diagram which shows the hardware configuration of the upper device and the lower device shown in FIG.</figref><figref num="3">Similarly, it is a functional block diagram which shows the functional structure of the part related to the remote management of the upper device and the lower device, and the setting of a certificate.</figref><figref num="4">It is a figure which shows the judgment criteria of whether or not the operation can be executed in the requirements management part shown in FIG.</figref><figref num="5">FIG. 5 is an explanatory diagram showing an outline of a communication method between a higher-level device and a lower-level device in the communication system shown in FIG.</figref><figref num="6">It is a figure for demonstrating the authentication information stored in the upper device and the lower device shown in FIG.</figref><figref num="7">It is a figure for demonstrating the format example of a normal public key certificate.</figref><figref num="8">It is a figure which shows the example of the general public key certificate created according to the format shown in FIG.</figref><figref num="9">Similarly, it is a figure which shows an example of a normal public key certificate for comparison with a rescue public key certificate.</figref><figref num="10">Similarly, it is a figure which shows an example of a rescue public key certificate for comparison with a normal public key certificate.</figref><figref num="11">It is a figure for demonstrating the structure for the upper device and the lower device shown in FIG. 1 to use a normal public key certificate and a rescue public key certificate properly.</figref><figref num="12">It is a figure which shows the outline of the manufacturing process of the component A provided with the storage area of the certificate, and the lower device to which the component A is mounted.</figref><figref num="13">It is a figure for demonstrating the process of storing each certificate set in the part A.</figref>

<figref num="14">It is a flowchart which shows the process to execute on the lower device side when writing a normal certificate set to a lower device in the process shown in FIG.</figref><figref num="15">It is a figure which shows the outline of the equipment usually used to set a certificate set to a lower device in the product assembly process shown in FIGS. 12 and 13.</figref><figref num="16">It is a figure which shows the outline of the situation around the communication terminal and the certificate writing apparatus shown in FIG. 15 in a production factory.</figref><figref num="17">It is a figure which shows the example of the rated name plate which is attached when the identification number is given to the apparatus which passed the functional inspection.</figref><figref num="18">It is a figure for demonstrating the configuration in the case where a plurality of lower-order devices are provided about the communication system shown in FIG.</figref><figref num="19">It is a figure which shows the flowchart of the process executed in each device when two communication devices perform mutual authentication according to SSL, together with the information used for the process.</figref><figref num="20">It is a figure for demonstrating the relationship between the root key, the root private key, and the public key certificate in the authentication process shown in FIG.</figref><figref num="21">It is a figure corresponding to FIG. 19 which shows the process performed in each device when two communication devices perform one-way authentication according to SSL.</figref><figref num="22">It is a figure for demonstrating the method conventionally used for writing ordinary information into a non-volatile storage device.</figref>

Code description

10 ... high-end device, 11 ... CPU, 12 ... ROM, 13 ... RAM, 14 ... HDD, 15 ... Communication I / F, 16 ... System bus, 20 ... Subordinate device, 31,41 ... HTTPS client function part, 32,42 ... HTTPS server function part, 33,43 ... Authentication Processing Department, 34 ... Certificate Renewal Request Department, 35,45 ... Certificate Storage Department, 44 ... Requirements Management Department, 46 ... Status Notification Department, 47 ... Log Notification Department, 48 ... Certificate Setting Department, 49 ... Command receiver, 50 ... Certificate management device, 60, 70 ... SOAP message, 140 ... Production control system, 150 ... Communication terminal, 154a ... Certificate DB, 156 ... input device, 157 ... display device, 160 ... certificate writing device, 161 ... Machine number information input device, 162 ... I / F for machine number information input, 165 ... Writing I / F, BC ... Barcode, E ... Production factory, F ... Administrator's room, G ... Door