JP4570919B2 - COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION DEVICE CONTROL METHOD, AND PROGRAM - Google Patents

Description

This invention comprises a communication unit, a communication device for providing a certificate to authenticate the communication party during communication, by such low-order device is a communication device with a host device that the communication partner The present invention relates to a communication system, a communication apparatus control method for providing a certificate to a communication partner for authentication during communication, and a program for causing a computer to function as the communication apparatus.

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

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

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

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

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

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

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

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

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

On the communication device B side, when the communication device A receives the data transmitted in step S16, the validity of the public key certificate A is confirmed using the root key certificate in step S23. If it can be confirmed, the second random number is decrypted using the public key A included in the received public key certificate A in step S24. Here, if the decryption is successful, it can be confirmed that the second random number is surely received from the public key certificate A issue target.
Thereafter, the common key seed is decrypted using the private key B in step S25. With the processing so far, the common key seed is shared between the communication device A side and the communication device B side. The common key seed is not known by any device other than the generated communication device A and the communication device B having the private key B. If the processing so far is successful, the communication device B also generates a common key used for encryption of subsequent communication from the seed of the common key obtained by decryption in step S26.

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

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

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

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

By the way, in order to improve safety, such a third party organization sets a valid period for the public key certificate to be issued. In addition, this period is usually in units of several years and is often as short as 1 to 3 years. In the authentication process, the public key certificate whose validity period has passed is not recognized as a valid public key certificate. Therefore, it is necessary to update to a new one before this validity period expires.
This is not a problem if the user has a good understanding of updating public key certificates. However, there are cases where it is difficult for the operator to update due to the assumed skill of the user and its usage environment, or that it is not preferable for the operator to set the public key certificate freely for the operation of the apparatus. In such a case, it may be possible to update automatically.

  Therefore, in order to perform the update reliably and easily, there is a request to transmit a public key certificate from a device that can communicate with the communication device to be updated so that the communication device can automatically perform the update process. It was. In this case, since the private key is often updated together with the public key certificate, it is necessary to transmit the update certificate and key through a secure route that is not tapped or tampered with. As this route, it is conceivable to use an SSL communication route using a key before update.

  However, when performing such automatic update, it is also conceivable that the update process fails because the user turns off the power of the communication device during the update process. In this case, the certificate or key being updated may be damaged. When such a situation occurs, authentication can no longer be performed using the certificate or key, so the management device cannot reliably identify the communication device, and the certificate or key cannot be specified. It cannot be transmitted safely. Therefore, the automatic certificate renewal has a problem that when the update process fails, it may not be possible to automatically try the update process again.

In such a state, of course, authentication cannot be performed even when communication other than certificate update is performed, and thus it is impossible to perform secure communication with other devices. Therefore, if the device must be left in such a state, it will have a significant effect on the normal operation of the device. Such a problem becomes more prominent as the validity period of the certificate is short and renewal is frequently performed.
This invention is to solve such a problem, a communication unit, a communication device or a communication system which is constructed by using such a communication apparatus for providing a certificate to authenticate the communication partner when the communication An object of the present invention is to easily maintain a state where normal authentication can be received while maintaining security.

In order to achieve the above object, the communication device of the present invention provides a certificate with a plurality of addresses in order to receive authentication from the communication partner, and performs communication with the address provided with the certificate authenticated by the communication partner. In a communication apparatus having a communication means and a request execution means for performing processing according to a request received from a communication partner by the communication means, the communication means is provided with two types of certificates with different validity periods set. The first address of the plurality of addresses provides a short-term certificate having a shorter validity period among the two types of certificates, and the two types of certificates are provided at the second address . Among these, the means for providing a long-term certificate with a longer validity period is used, and when communication is performed using the second address, processing related to a request other than the request for setting the short-term certificate. In which was not carried out.

Alternatively, a certificate is provided at a plurality of addresses in order to receive authentication from the communication partner, and a communication unit that performs communication at the address provided with the certificate authenticated by the communication partner is received from the communication partner by the communication unit. In a communication apparatus having a request execution means for performing processing in response to a request, the communication means is a short-term certificate having a validity period shorter than the product life of the communication apparatus at the first address among the plurality of addresses. A certificate is provided, and the second address is a means for providing a long-term certificate that is a certificate whose validity period is longer than the product life of the communication device. When communication is performed at the second address, the short-term certificate is used. The processing related to the request other than the request related to the certificate setting is not performed .

Alternatively, a certificate is provided at a plurality of addresses in order to receive authentication from the communication partner, and a communication means for performing communication at the address provided with the certificate authenticated by the communication partner is received from the communication partner by the communication means. In a communication apparatus having a request execution means for performing processing in response to a request, the communication means is a certificate that is a certificate that does not expire during the operation of the communication apparatus at the first address among the plurality of addresses. A means for providing a long-term certificate, which is a certificate that expires during operation of the communication device at the second address, and the short-term certificate when communicating at the second address. The processing related to the request other than the request related to the document setting is not performed .

Alternatively, a certificate is provided at a plurality of addresses in order to receive authentication from the communication partner, and a communication unit that performs communication at the address provided with the certificate authenticated by the communication partner is received from the communication partner by the communication unit. In a communication device having a request execution means for performing processing in response to a request, the communication means provides a short-term certificate that is a certificate that has virtually no expiration date at the first address among the plurality of addresses. The second address is a means for providing a long-term certificate that is a certificate with an expiration date. When communication is performed at the second address, processing related to a request other than the request for setting the short-term certificate is performed. It is better not to .

In each of these communication devices to receive the certificate of the communication partner from a communication partner that provides the certificate to authenticate, provided authentication means for permitting only the subsequent communication when the authentication is successful, the request The execution means may be provided with means for updating the short-term certificate when the short-term certificate setting request is received from the communication partner.
Further, the request for setting the short-term certificate may be an acquisition request for information necessary for creating the short-term certificate and a setting request for the short-term certificate.

Furthermore, to the request execution unit, provided a predetermined process a plurality of request processing means for performing, distributing means for distributing requests according a type of the received address request to each of the request processing unit corresponding to the request, it said When communication is performed at the second address, the distribution unit does not distribute requests other than the request related to the setting of the short-term certificate to the request processing unit, thereby requesting other than the request related to the setting of the short-term certificate. It is better not to perform the process related to .
Furthermore, the request may be described as a SOAP message.
Furthermore, the authentication, to perform the authentication process in accordance with the SSL or TLS protocol may be a public key certificate using the above certificates to the authentication process.

The communication system of the present invention includes a communication means for providing a certificate of a plurality of addresses in order to authenticate the communication party and performs communication at the address provides authentication certificate to the communication partner, the communication In a communication system comprising a lower-level device having a request execution means for performing processing according to a request received from a communication partner by means, and a higher-level device serving as a communication partner of the lower-level device, the communication means of the lower-level device 2 types of certificates with different validity periods are provided, and the first address of the plurality of addresses has a shorter validity period of the two types of certificates. providing the certificate, the second address a means of effective period set among the two types of certificates provides the longer long certificate, to the lower apparatus, the upper When performing communication with a second address so as not to perform processing according to requests other than requests for setting of the short-term certificate to the host device, the communication partner using the certificate received from the communication partner Authentication means for authenticating is provided.

Also provides a certificate multiple addresses to authenticate to the communication partner, a communication means for communicating with the address that provided the authentication certificate to the communication partner is received from the communication partner by the communication unit In a communication system including a lower-level device having a request execution unit that performs processing according to a request and a higher-level device that is a communication partner of the lower-level device, the communication unit of the lower-level device is connected to the plurality of addresses. Among them, the first address provides a short-term certificate that is a certificate whose validity period is shorter than the product life of the lower-level device, and the second address is a certificate whose validity period is longer than the product life of the lower-level device. and means for providing a long-term certificate to the subordinate apparatus, when performing communication by the second address according to requests other than requests for setting of the short-term certificate process Is not performed, the above higher-level device, is provided with a authentication means for authenticating the communication partner using the certificate received from the communication partner.

In these communication systems, the above lower apparatus receives the certificate of the communication partner from a communication partner that provides the certificate to authenticate the authentication unit that allows only subsequent communication when the authentication is successful It is preferable to provide means for updating the short-term certificate when the request execution means of the lower-level device receives the short-term certificate setting request from the communication partner.
Further, the request for setting the short-term certificate may be an acquisition request for information necessary for creating the short-term certificate and a setting request for the short-term certificate.
Furthermore, the request may be described as a SOAP message.
Furthermore, the authentication performed by the authentication process in accordance with the SSL or TLS protocol may be a public key certificate using the above certificates to the authentication process.

Further, the communication device control method of the present invention causes the communication device to provide a certificate with a plurality of addresses in order to receive authentication from the communication partner, and communicates with the address provided with the certificate authenticated to the communication partner. In the communication device control method for performing processing according to a request received from a communication partner in the communication, the communication device is provided with two types of certificates having different validity periods, Among the plurality of addresses, the first address provides a short-term certificate having a shorter valid period among the two types of certificates , and the second address sets the two types of certificates. to provide long-term certificate validity period that is longer is, as in the case of performing communication with the second address does not perform processing according to requests other than requests for setting of the short-term certificate Those were.

Also, let the communication device provide certificates with a plurality of addresses in order to receive authentication from the communication partner, perform communication at the address provided with the certificate authenticated by the communication partner, and receive from the communication partner in that communication a method of controlling a communication device to perform the on demand process, to the communication device, the short-term certificate validity period than the product life of the communication device in the first address of the plurality of addresses is a short certificate A long-term certificate, which is a certificate whose validity period is longer than the product life of the communication device at the second address, and when the communication is performed at the second address, the short-term certificate Processing related to requests other than requests related to settings is not performed .

Allow the control method of the communication apparatus, to the communication device, the certificate is received to perform the authentication from the communication partner that provided the certificate of the communication partner, and the subsequent communication only if the authentication is successful The short-term certificate may be updated when the short-term certificate setting request is received from the communication partner.
Further, the request for setting the short-term certificate may be an acquisition request for information necessary for creating the short-term certificate and a setting request for the short-term certificate.
Furthermore, the request may be described as a SOAP message.
Furthermore, the authentication is performed by the authentication process in accordance with the SSL or TLS protocol may be a public key certificate using the above certificates to the authentication process.

The program of the present invention, a communication unit of the computer to provide a certificate multiple addresses to authenticate to the communication partner, communicating at the address provides authentication certificate to the communication partner, In the program for causing the communication means to function as a request execution means that performs processing according to a request received from a communication partner, the communication means provides two types of certificates with different validity periods, Among the plurality of addresses, the first address provides a short-term certificate having a shorter valid period among the two types of certificates , and the second address sets one of the two types of certificates. and means effective period being to provide a longer long certificates, further, the computer is, the short-term certificate when performing communication by the second address Those including a program for not to perform the processing according to requests other than requests for writing settings.

In addition, a computer provides a certificate with a plurality of addresses in order to receive authentication from a communication partner, and communicates with the address provided with the certificate authenticated by the communication partner, and a communication partner by the communication unit. In the program for functioning as request execution means for performing processing according to the request received from the first address among the plurality of addresses, the valid period is longer than the product life of the apparatus including the computer. providing short-term certificate is a short certificate, the second address a means of providing a long-term certificate is valid period is longer certificate than the product life of the device provided with the computer, further, the computer, not treated according to requests other than requests for setting of the short-term certificate when communicating with said second address It is those, including a program to to.
In these programs, the computer is authenticated by receiving the certificate of the communication partner from the communication partner providing the certificate, and functions as an authentication unit that permits subsequent communication only when the authentication is successful. It is preferable that the request execution means includes a function for updating the short-term certificate when receiving the short-term certificate setting request from the communication partner.
Further, the request for setting the short-term certificate may be an acquisition request for information necessary for creating the short-term certificate and a setting request for the short-term certificate.
Furthermore, the request may be described as a SOAP message.
Furthermore, the authentication may be performed by an authentication process according to an SSL or TLS protocol, and the certificate may be a public key certificate used for the authentication process.

According to the communication device, the communication system, or the control method of the communication device of the present invention as described above, a communication device that includes a communication unit and provides a certificate to receive authentication from a communication partner during communication or such a communication device. In a communication system configured using a communication device, it is possible to easily maintain a state in which normal authentication can be received while maintaining security.
Further, according to the program of the present invention, the computer can be functioned as the above communication device to realize its characteristics, and similar effects can be obtained.

Preferred embodiments of the present invention will be described below with reference to the drawings.
First, the configuration of an embodiment of a communication apparatus according to the present invention and a communication system according to the present invention configured using the communication apparatus 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, via a network 30. The subordinate device 20 is an embodiment of the communication device of the present invention. The host device 10 is also a communication device having a communication function.
As the network 30, various communication lines (communication paths) capable of constructing a network can be adopted regardless of wired or wireless. Although only one subordinate device 20 is shown here, it is possible to provide a plurality of subordinate devices 20 in the communication system as shown in FIG.

Such a communication system will be described first from the hardware configuration of the upper apparatus 10 and the lower apparatus 20. The hardware configurations of the upper level device 10 and the lower level device 20 are simply as shown in FIG.
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. The CPU 11 executes various control programs stored in the ROM 12 and the HDD 14 to control the operation of the host device 10 and realize functions such as authentication of the communication partner and digital certificate update of the lower device 20. Yes. In this specification, the digital certificate refers to digital data to which a signature for preventing forgery is attached.

The lower level device 20 also includes a CPU 21, ROM 22, RAM 23, HDD 24, and communication interface (I / F) 25 as in the case of the higher level device 10, and these are connected by a system bus 26. The CPU 21 executes various control programs stored in the ROM 22 and the HDD 24 as necessary, and controls the apparatus, whereby various means such as communication means, prohibition means, authentication means, request execution means, distribution means, and the like. The function as can be realized.
In this communication system, it is needless to say that the upper device 10 and the lower device 20 can take various configurations according to the purpose of remote management, electronic commerce, and the like. And as a hardware of the high-order apparatus 10 and the low-order apparatus 20, a well-known computer can also be employ | adopted suitably. Of course, other hardware may be added as necessary, and the upper device 10 and the lower device 20 do not need to have the same configuration.

Next, a communication system in this communication system will be described. FIG. 3 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 lower device 20, it first requests the lower device 20 for communication. Then, when the lower apparatus 20 is authenticated as a valid communication partner by the authentication process according to the SSL protocol as described with reference to FIG. To establish. This authentication process is called an SSL handshake. However, mutual authentication as shown in FIG. 24 is not essential, and one-way authentication as shown in FIG. 26 may be used.
In this process, the lower-level device 20 transmits its own public key certificate to the higher-level device 10 and receives authentication. When performing mutual authentication, the upper device 10 also transmits its public key certificate to the lower device 20 for authentication, but this authentication is not performed for one-way authentication. In the case of mutual authentication, the CPU of the lower level device 20 functions as an authentication unit when performing authentication using the public key certificate received from the higher level device 10.

If the above authentication is successful, the upper level apparatus 10 generates a request that is a request for processing for the method of the application program implemented by the lower level apparatus 20 as a SOAP message described in the XML format that is a structured language format, and HTTP ( The HTTP request 40 is transmitted to the lower level device 20 according to Hyper Text Transfer Protocol. Such a request is called RPC (Remote Procedure Call).
Then, the lower level device 20 executes processing according to the content of the request, generates a response SOAP message, and transmits it as an HTTP response 50 to the higher level device 10. Here, these requests and responses are encrypted and transmitted using a common key shared in the SSL handshake process to ensure communication safety.

Also, with these requests and responses, this communication system functions as a client / server system in which the upper apparatus 10 is a client and the lower apparatus 20 is a server.
In order to realize RPC, in addition to the above-described techniques, known protocols (communication standards) such as FTP (File Transfer Protocol), COM (Component Object Model), CORBA (Common Object Request Broker Architecture), techniques, Specifications can be used.

Next, the characteristics and applications of each certificate and key, which are authentication information used by the above-described upper apparatus 10 and lower apparatus 20 for the above-described authentication process, will be described. 4A shows the type of certificate and key stored as authentication information in the higher level apparatus 10 in FIG. 4A, and FIG. 4B shows the type of certificate and key stored in the lower level apparatus 20 as authentication information. FIG.
As shown in FIG. 4, the upper level device 10 and the lower level device 20 shown in FIG. 1 roughly store regular authentication information and rescue authentication information. Each of the regular authentication information and the rescue authentication information is composed of a public key certificate and a private key that are authentication information about itself, and a root key certificate that is authentication information about the communication partner.

Further, for example, the low-level device normal public key certificate has a digital signature that can be validated using the low-level device authentication normal root key to the normal public key issued by the certificate management device to the low-level device 20. It is a digital certificate attached and corresponds to a short-term certificate.
Here, for example, the format of the public key certificate shown in FIG. 5 can be used. In addition to the public key itself, the issuer of the certificate, the expiration date of the certificate, the subject to be certified (the certificate Information such as the issuer's device or user) is described. Specifically, for example, X. The public key certificate created according to this format can be as shown in FIG. 6, for example.
In this example, A indicates CA identification information, and C indicates identification information of a certificate issuing device. These include information such as location, name, machine number or code, respectively. B indicates the effective period, and the effective period is designated by the start date and time and the end date and time.

Also, the private private key for the lower level device is a private key corresponding to the above normal public key, and the normal root key certificate for lower level device authentication is the root private key corresponding to itself as the normal root key for lower level device authentication. It is a digital certificate with a digital signature that can be verified by itself.
Even when a plurality of lower-level devices 20 are provided, the digital signature attached to the normal public key of each device is attached using the same root private key, and the normal root key certificate necessary for validity verification is made common. However, the normal public key included in the normal public key certificate and the private key corresponding thereto differ from device to device.
The higher-level device normal public key certificate, the higher-level device normal private key, and the higher-level device authentication normal root key certificate have the same relationship.

For example, when the upper device 10 and the lower device 20 perform mutual authentication using the regular authentication information, the lower device 20 uses the lower device normal private key in response to a communication request from the upper device 10. The encrypted first random number is transmitted to the upper apparatus 10 together with the lower apparatus normal public key certificate. The upper device 10 side first confirms the validity (not damaged or tampered) of the lower device normal public key certificate using the lower device authentication normal root key certificate, and if this can be confirmed. The first random number is decrypted 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 issuance destination of the lower-level device normal public key certificate, and the device is identified from the identification information included in the certificate. Can be identified. Then, the success or failure of authentication can be determined according to whether or not the identified device is suitable as a communication partner.
The lower device 20 also receives and stores the higher-level device normal public key certificate and the random number encrypted with the higher-level device normal private key that are transmitted when the higher-level device 10 is successfully authenticated. The same authentication can be performed by using the higher-level device authentication root key certificate.

By the way, these public key certificates and private keys are regularly updated. However, as described in the section of the disclosure of the invention, the certificate or key is damaged due to failure of update, Authentication using a normal public key certificate (authentication using a normal certificate set) cannot be performed because the validity period of the public key certificate expired before it could not be renewed because the power was not turned on. May end up. In addition, the public key certificate or the private key may be lost due to replacement of a part that stores the public key certificate. In such a case, in order to enable the authentication using the normal public key certificate again, it is necessary to store the damaged certificate and key again.
Here, if each device can only perform authentication using a normal public key certificate, a new normal public key certificate or the like can be safely passed through the network 30 in a state where this authentication cannot be performed. There will be no way to send to. However, each communication device constituting the communication system of this embodiment stores rescue authentication information in order to cope with such a situation, and authenticates the communication partner using two different types of digital certificates. To be able to. Then, by using the rescue authentication information, a new normal public key certificate or the like can be safely transmitted / received to / from a required apparatus via the network.

  The rescue authentication information has substantially the same configuration as the regular authentication information. For example, the rescue public key certificate for the lower device is a long-term certificate, and the rescue public key issued by the CA to the lower device is It is a digital certificate with a digital signature that can be verified using a rescue root key for subordinate device authentication. The rescue private key for subordinate devices is a private key corresponding to the rescue public key, and a rescue route for subordinate device authentication. The key certificate is a digital certificate in which a low-level device authentication rescue root key is attached with a digital signature that can be validated by itself.

However, the main 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. 7 shows an example of a normal public key certificate, and FIG. 8 shows an example of a rescue public key certificate.
These are public key certificates issued to the same device, with the identification information of the device as the issue destination being the same, as indicated by symbols F and I. However, the validity period of the normal public key certificate is one year from midnight on January 1, 2003 to midnight on January 1, 2004, as indicated by symbol E. The valid period of the book is 50 years from midnight on January 1, 2000 to midnight on January 1, 2050, as indicated by the symbol H.
Further, the issuer of the certificate is the same CA of XXX, but “Regular CA” as indicated by the symbol D for the normal public key certificate and “ResumeCA” as indicated by the symbol G for the rescue public key certificate. "This is a different CA.

  Such a rescue public key certificate with a long validity period is slightly less secure than a normal public key certificate with a short validity period. However, since such a rescue public key certificate does not need to be updated frequently due to its long expiration date, it is unlikely to become unusable due to breakage. Of course, it is difficult to cause a situation where it becomes unusable due to expiration. Therefore, even if the normal public key certificate becomes unusable by using such a rescue public key certificate, if the rescue public key certificate is usable, It can be authenticated. If such authentication is successful, the common key is shared with the communication partner as described above, and a secure communication path using common key encryption can be provided. Therefore, a new normal public key certificate can be transmitted / received to / from a communication partner using this communication path and set.

If the authentication process is performed using rescue authentication information, the validity period can be increased if only limited requests such as updating of regular authentication information such as normal public key certificates are permitted. Even if the safety is slightly lowered due to the lengthening, it does not become a big problem.
In consideration of this point, it is necessary to update the rescue public key certificate after the validity period of the rescue public key certificate elapses. Therefore, it is preferable that the validity period of the rescue public key certificate is long. Specifically, for example, an effective period longer than the product life of the device to be stored may be set. The product life is an assumed operation period or an assumed operation period of the apparatus, and can be determined from a use period assumed at the time of development, an assumed useful life, a quality assurance period of the apparatus, and the like.
In addition, if the validity period of the rescue public key certificate is set longer than the period during which it is assumed that the rescue public key certificate can be operated normally while maintaining the equipment, the rescue public key certificate will expire during the operation of the equipment. It can be said that there is no certificate. Accordingly, during operation of the apparatus, it is possible to always maintain a state where authentication using the rescue public key certificate (authentication using the rescue certificate set) is possible. In addition, since it is not necessary to update the rescue public key certificate, it is possible to prevent damage during the update.

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

  By the way, the lower level device 20 functioning as a server cannot identify the other party who has requested communication during the SSL handshake, and therefore basically transmits the same public key certificate to all the other parties. However, in this communication system, it is necessary to use a normal public key certificate and a rescue public key certificate properly depending on the situation. Therefore, the configuration for proper use will be described with reference to FIG. FIG. 9 is a diagram illustrating an example of a URL (Uniform Resource Locator) used for specifying a communication destination address when a client requests communication from a server.

In this communication system, the lower level apparatus 20 accepts communication requests at a plurality of addresses, and provides a public key certificate corresponding to the address at which the communication request is accepted. For example, when a communication request is received at the first address indicated by the URL “https://123.45.67.89:10000” (normal processing URL), the low-level device normal public key certificate is transmitted to the request source. When a communication request is received at the second address indicated by the URL “https://123.45.67.90:10001” (rescue URL), a low-level device rescue public key certificate is transmitted. .
By doing in this way, the one low-order apparatus 20 can distinguish a communication request, and can use the public key certificate for a SSL handshake process as needed.
The host device 10 functioning as a client can naturally know to which address of the lower device 20 the communication request has been sent, so when performing mutual authentication, select an appropriate public key certificate corresponding to the address. Can be sent.

  As shown in FIG. 9, the URL includes information indicating the host, information indicating the port of the host, and information indicating the URL path. The information indicating the URL path is included in the HTTP request including the SOAP message that is transmitted when the SSL handshake is successful, as indicated by reference numeral 41 in FIG. I can't refer to it. Therefore, when an address for identifying a communication request receiving port is expressed by a URL, it is distinguished by a combination of an IP (Internet Protocol) address that is information indicating a host and a port number that indicates the port of the host. become. Of course, it may be possible to distinguish only one of the IP address and the port number. In this case, common information can be used for the other.

  As described above, in this communication system, when authentication using the normal public key certificate is basically performed between the upper level device 10 and the lower level device 20, the system becomes inoperable due to damage or the like. However, authentication using a rescue public key certificate can be performed to secure a secure communication path. This is because even with authentication using a rescue public key certificate, the common key can be exchanged as in the case of the normal public key certificate. Then, by sending and storing the regular authentication information for update from the upper level device 10 to the lower level device 20 using this communication path, it is possible to return to the state in which authentication using the regular authentication information is possible.

As described above, in this communication system, it is possible to easily maintain a state in which normal authentication can be received by using rescue authentication information in addition to regular authentication information. However, as described above, the rescue authentication information including the rescue public key certificate is not updated and the same information is stored in all devices of the same rank. The impact on safety is large.
Therefore, in order to minimize this influence, in this communication system, functions that can be executed when an SSL handshake is performed using a rescue public key certificate are limited as much as possible. Then, if a new normal public key certificate is stored in the lower level device 20, an SSL handshake using the normal public key certificate becomes possible again. When using a rescue public key certificate, It is sufficient to permit only the processing for storing the new normal public key certificate in the lower level device 20.

  Therefore, in this communication system, when communication is performed with a rescue URL that performs an SSL handshake using a rescue public key certificate, processing other than processing related to setting of a normal public key certificate is prohibited in the lower level device 20. By doing so, high security can be realized while sufficiently maintaining the effect of using the rescue public key certificate. This is a feature of this embodiment.

Next, an outline of the configuration and operation method of this communication system for realizing such features will be described with reference to FIG. FIG. 10 is a diagram for explaining the configuration and operation method.
In this communication system, at the normal time, as shown in (a), when the higher-level device 10 issues a communication request to the normal processing URL of the lower-level device 20 and the authentication using the normal public key certificate is successful, the lower-level device 20 Requests are sent to and various functions are used.

Although details will be described later, at this time, in the lower level device 20, the HTTP daemon that controls the communication by HTTP receives the requested HTTP request, and the first distribution unit 410 distributes the request to the second according to the URL that received the HTTP request. It distributes to one of the parts 421 and 422. Here, since it is received by the normal process URL, it is distributed to the second distribution part 421 for the normal process URL.
Then, the normal processing URL second distribution unit 421 distributes the processing related to the request to the function corresponding to the type of the request and executes it, and thereafter returns an HTTP response as a response to the upper level device 10 through the reverse route. By such processing, the lower-level device 20 performs an operation in response to a request from the higher-level device 10. When the request is received by the normal process URL, there is no particular restriction on the operation according to the request.

Since the normal public key certificate used for authentication when communication is performed using the normal process URL includes the identification information of the lower-level device 20, if the SSL handshake is performed using this certificate, the communication partner in this process Can be identified.
Therefore, compared with the case where identification information is acquired by another command after the SSL handshake, “spoofing” of the communication partner can be effectively prevented. Also, even if a private key is leaked, a third party who obtains it illegally cannot be used as a device for which a private key is issued, and if the key of that device is updated, Since such “spoofing” can be prevented, high communication safety can be obtained.
In addition, when the higher level device 10 manages the lower level device 20, the management target device can be identified by the identification information included in the normal public key certificate, and the management operation can be performed. Compared to the case, the management operation can be smoothly performed by a simple process.

However, as shown in (b), when the normal public key certificate stored in the lower-level device 20 is damaged and the normal certificate cannot be transmitted, the authentication process fails. In this case, the upper device 10 cannot use the functions of the lower device 20 as it is. Therefore, a communication request is made to the rescue URL, and authentication using the rescue public key certificate is performed. If this is successful, a request for setting a normal certificate is made to the lower level device 20, and the normal public key certificate is updated using the certificate setting function.
When the request is received by the rescue URL, the request is distributed from the first distribution unit 410 to the second distribution unit 422 for rescue URL. Then, the rescue URL second distribution unit 422 distributes the processing related to the request to the function corresponding to the type of request and executes this, but at this time, only the request related to the setting of the normal public key certificate is distributed, Other requests are not distributed. Therefore, in this case, processing related to a request other than the request related to the setting of the normal public key certificate is prohibited.

If such a process is performed and a normal normal public key certificate can be set in the lower level apparatus 20, communication with the normal process URL becomes possible again as shown in (a).
Therefore, even when the normal public key certificate is damaged, it is possible to quickly return to the normal state and always maintain a state where authentication using the normal public key certificate is possible. This means that a state in which normal authentication can always be received can be maintained from the lower device 20 side. Further, it is not necessary to manually perform these processes, and such an effect can be easily obtained.

In practice, the upper level device 10 acquires the identification information from the lower level device 20 and updates it to the CA (not shown) when updating the normal public key certificate. A certificate is issued and acquired, and this is transmitted to the lower level device 20 together with the certificate setting request and stored. Alternatively, it is conceivable that the host device 10 has a CA function and issues a certificate by itself.
Further, when issuing a normal public key certificate to be stored in the lower level device 20, the public key body and the corresponding private key in the certificate may be newly generated. If the key issued to the user is managed, the key may be used as it is. Also, when issuing a certificate for renewal, it is possible to issue a new root private key and upgrade the public key certificate.

  Next, a functional configuration for realizing the above processing in the lower level device 20 will be described with reference to FIG. FIG. 11 is a functional block diagram showing a functional configuration of the lower level device 20 for executing an operation according to the content of the request received from the higher level device 10 and returning a response. Note that each unit and each function appearing in the following description is realized by the CPU executing appropriate software.

  As shown in FIG. 11, the lower-level device 20 includes an HTTP daemon 331, a first distribution unit 410, a normal processing URL second distribution unit 421, a rescue URL second distribution unit 422, and various functions 380. The various functions 380 include a unique information acquisition function 381 and a certificate setting function 387. These sections and functions correspond to the sections and functions shown in FIG.

  Among these units, first, the HTTP daemon 331 controls communication by HTTP and executes SSL handshake processing. And it has the function to pass the HTTP request received after the SSL handshake is successful to the first distribution unit 410 together with the received URL information. This URL can be recognized by a TCP (Transmission Control Protocol) connection request when an HTTP request is received. This HTTP daemon 331 implements the function of the communication means.

  Although only one first distribution unit 410 is shown here, a plurality of applications (applications) provide various functions in the lower-level device 20, and requests for functions provided by the applications for each application are provided. You may provide the 1st distribution part for performing this distribution. In this case, the HTTP daemon 331 distributes the HTTP request to each first distribution unit according to the URL path included in each request.

  The first distribution unit 410 has a function of distributing a request (command) based on a SOAP message received as an HTTP request by the HTTP daemon 331 to each of the second distribution units 421 and 422 according to the URL that received the request. Here, as shown in FIG. 12, the lower level device 20 stores a table in which the request distribution destination by the first distribution unit 410 is shown for each URL, and the first distribution unit 410 refers to this to determine the distribution destination. decide. Accordingly, here, the request received by the normal process URL is distributed to the second distribution part 421 for normal process URL, and the request received by the rescue URL is distributed to the second distribution part 422 for rescue URL.

Each of the second distribution units 421 and 422 includes an XML processor, analyzes the syntax of the XML of the HTML body in the HTTP request according to the request, and shows the relationship between the tags described in XML in a tree structure. It has a function of converting into DOM (Document Object Model) tree format data. The data in the DOM tree format is data in the configuration data format indicating the configuration of the request message. In this case, each of the second distribution units 421 and 422 of the lower level device 20 has a function as message conversion means.
Each of the second distribution units 421 and 422 also includes an XML serializer, and conversely has a function of converting DOM tree format data into XML format data.

  Further, each of the second distribution units 421 and 422 analyzes the generated DOM tree format data, extracts the request type data, and sets the header information of the HTTP request in the function corresponding to the data among the various functions 380. Along with the collected HTTP header information, the above DOM format data is distributed and functions as a second distribution means for requesting processing related to the request.

Here, this distribution rule is different between the normal processing URL second distribution unit 421 and the rescue URL second distribution unit 422, which will be described later.
As the request type data, for example, the name of the child node of the “Body” node indicating the SOAP body in the DOM tree can be considered. Further, URI (Uniform Resource Identifiers) included in the SOAPAction header of the HTTP request related to the request may be used. This information is included in the above HTTP header information.

  Various functions 380 correspond to request execution means, and each function included therein is a request processing means, and is a function provided by software for performing processing according to the received request. Then, the process is started by the normal processing URL second distribution unit 421 or the rescue URL second distribution unit 422, executes the logic according to the received data, and returns the result to the second distribution unit that is the processing request source. .

Also, the data in the DOM tree format passed from each of the second distribution units 421 and 422 is analyzed, and this is converted into a data format that can be processed in a program language in which the logic of each function included in the various functions 380 is described. It also has a function and a function of converting the result data, which is the execution result of the program, into DOM tree format data. Here, the logic of each function included in the various functions 380 is described in C language, and this data format is C language structure data.
The specific functions 380 are not shown in the figure except for the specific information acquisition function 381 and the certificate setting function 387, but each function is provided corresponding to the type of request.

For example, the functions classified into the unique information acquisition function 381 include information (including identification information) unique to the lower level device 20 such as an ID (model number), a model name, a firmware version, an option configuration, and a certificate version. If separate requests are prepared to instruct the execution of these functions, the software related to the execution of these functions should be provided as a program that is called separately. I have to.
The function provided by the certificate setting function is the setting of a normal public key certificate. However, this setting is performed by setting the entire certificate set constituting the regular authentication information in the lower level device 20.

Other functions included in the various functions 380 include, for example, a status acquisition function that allows the request source to acquire status information of the lower-level device 20, a log information acquisition function that also acquires log information, and a setting value information. The setting value information acquisition function to be performed, the setting value change function to change the setting value of the lower level device 20, the adjustment execution function to perform the adjustment operation of the lower level device 20, etc. can be considered. What is necessary is just to determine suitably according to the structure of 20 and the relationship with the high-order apparatus 10. FIG.
Although not shown, a plurality of applications executed by the lower-level device 20 may provide a function set such as various functions 380 according to the functions of the applications.

By the way, in this lower level apparatus 20, the normal process URL second distribution unit 421 distributes all requests having the corresponding function to the function. However, the rescue URL second distribution unit 422 distributes only the request related to the setting of the normal public key certificate to the function, as indicated by the thick line in FIG. When another request is accepted, a response is returned assuming that there is no corresponding function.
And here, the request for the setting of the normal public key certificate is the request for obtaining the information necessary for creating the normal public key certificate (including the description of information) and the request for setting the normal public key certificate. Among the specific information acquisition function 381, the function corresponding to the ID, the model name, and the certificate version function and the certificate setting function 387 are used. However, it is also conceivable that other requests are also handled as requests related to the setting of the public key certificate, and conversely, requests for acquiring these information are not handled as requests related to the setting of the public key certificate. Specifically, what kind of request is handled as a request related to the setting of a normal public key certificate may be finally determined appropriately by the system designer.

As shown in FIG. 13, for such distribution, a table of request types and distribution destinations is provided for each second distribution unit, and each second distribution unit performs distribution with reference to a table corresponding to itself. By doing so, it can be realized. Requests not listed in the table may be handled as having no corresponding function.
As a result, when the lower-level device 20 receives a request from the normal processing URL, processing relating to all requests is permitted, whereas when a request is received from the rescue URL, the request is first Although it reaches the rescue URL second distribution unit 422 from the distribution unit 410, processing other than the request related to the setting of the normal public key certificate is not distributed to the function, and as a result, the processing is prohibited. The first sorting unit 410 and the rescue URL second sorting unit 422 implement the function of a prohibiting unit.
In order to prohibit processing related to requests to other applications, when a request is received with a rescue URL, the HTTP daemon 331 does not pass the request to any application other than the application that sets the normal public key certificate. You can do it. Further, a second normal processing URL distribution unit and a second rescue URL distribution unit may be provided for each application, and the latter may not perform distribution to each function at all.

  By the prohibition means as described above, when communication is performed with a rescue URL that performs an SSL handshake using a rescue public key certificate, processing other than processing related to setting of a normal public key certificate is prohibited. Can do. And while maintaining the effects of using a rescue public key certificate sufficiently, this minimizes the impact of a leaked rescue public key certificate or corresponding private key, etc. Can be realized.

  Next, processing executed in the lower order apparatus 20 having the configuration shown in FIG. 11 will be described with reference to FIGS. 14 and 15. FIG. 14 is a flowchart showing processing performed when the lower level apparatus 20 receives a communication request, and FIG. 15 is a flowchart showing subsequent processing. These processes are processes related to the control method of the communication apparatus of the present invention. Here, in order to simplify the description, a process in the case of performing one-way authentication as illustrated in FIG. 26 in which the communication partner only authenticates the lower-level device 20 is illustrated. However, it goes without saying that bidirectional authentication as shown in FIG. 24 may be performed.

The CPU of the lower level device 20 always executes the HTTP daemon 331, and when this receives a communication request from another device, the CPU 20 starts the processing shown in the flowchart of FIG.
In this process, first, in step S101, it is determined whether or not the URL for which the communication request has been received is a normal process URL. If it is a normal processing URL, the process proceeds to step S102, and the normal public key certificate for the lower device is transmitted to the communication partner (requester of the communication request) together with the first random number encrypted with the normal private key for the lower device. Request authentication. That is, in this case, a normal public key certificate is provided to the communication partner. This processing corresponds to the processing in steps S21 and S22 in FIG.

Thereafter, the process proceeds to step S106 and waits for a response from the communication partner. If the communication partner is not authenticated, the process is terminated without permitting the subsequent communication. If the communication partner is authenticated, the process proceeds to step S107. A common key is created from the seed of the common key received in the authentication process. These processes correspond to the processes in steps S25 and S26 in FIG.
In step S108, it waits for reception of a request by an HTTP request from the communication partner, and if received, the process proceeds to step S109, and the request is transferred to the first distribution unit 410 together with the received URL information. The processing so far is processing by the HTTP daemon 331.

If the URL is not a normal process URL in step S101, the process proceeds to step S103 to determine whether the URL for which the communication request has been received is a rescue URL. If it is a rescue URL, the process proceeds to step S104, where the lower-level apparatus rescue public key certificate is transmitted to the communication partner together with the first random number encrypted with the lower-level apparatus rescue private key to request authentication. That is, in this case, a rescue public key certificate is provided to the communication partner. This processing also corresponds to the processing in steps S21 and S22 in FIG.
Then, the process proceeds to step S106 and the subsequent steps, and up to step S109, the same processing as when the normal public key certificate is provided is performed. If it is not a rescue URL in step S103, it is a communication request for a URL for which communication is not accepted, so an error process is performed in step S105 and the process is terminated.

Next, the process after step S110 is demonstrated.
The first distribution unit 410 to which the request is passed in step S109 refers to the table as illustrated in FIG. 12 and determines a distribution destination according to the received URL. In step S111, the request received by the normal process URL is transferred to the second distribution part 421 for normal process URL, and the request received by the rescue URL is transferred to the second distribution part 422 for rescue URL in step S112.
After steps S111 and S112, the process proceeds to steps S113 and S116 in FIG. 15, respectively, and the second distribution unit analyzes the SOAP envelope corresponding to the HTML body of the request received as the HTTP request and displays the structure in the DOM tree format data. Create This process is performed in the same way in either of the second distribution units.

Then, the process proceeds to steps S114 and S117, respectively, and the second distribution unit distributes the request to the function corresponding to the type of request in the various functions 380, and requests processing related to the request. At this time, the request is passed to the function as HTTP header information and DOM tree format data. Further, the normal processing URL second distribution unit 421 distributes to any of the various functions 380, but the rescue URL second distribution unit 422 distributes only a request related to the setting of the normal public key certificate. . As shown in FIG. 13, if the two second distribution units use different tables for the correspondence relationship between the request type and the function of the distribution destination as shown in FIG. 13, the processing procedure itself is the same. Can be a thing.
After this distribution, the process proceeds to steps S115 and S118, respectively, to determine whether the distribution is successful, that is, whether there is a distribution destination corresponding to the type of request in the table. If it is successful, the process proceeds to step S119 in both steps.

In the next step S119, the function to which the request has been distributed analyzes the DOM tree of the request and converts the parameters contained therein into C language structure data. In step S120, the logic of the function is executed, and the result is generated as structure data. Thereafter, in step S121, the structure data is converted into a DOM tree and returned as a response to the second distribution unit. At this time, the result is returned to the second distribution unit that distributes the request to the function.
In step S122, the second distributing unit converts the DOM tree into response data using an XML-formatted SOAP message by using an XML serializer (not shown), and returns the response to the request transmission source as an HTTP response by the HTTP daemon 331. End the process.

On the other hand, if the distribution has failed in step S115 or S118, the second distribution unit that attempted the distribution uses the DOM tree of error information (SOAP Fault) indicating that the request of that type is not supported in step S123. Is converted into XML-format response data in step S124, which is returned as an HTTP response to the request source by the HTTP daemon 331, and the process is terminated.
It is necessary to distinguish the second distribution unit for the normal process URL and the rescue URL up to the procedure of distributing the request to the function. In the process of returning a response, the function for the normal process URL and the rescue URL Are exactly the same. Therefore, in step S119 and subsequent steps, these are shown without distinction.

Next, an example of a processing sequence by the processing shown in the flowcharts of FIGS. 14 and 15 will be described with reference to FIG. FIG. 16 is a sequence diagram showing this processing sequence, and shows processing when the lower level apparatus 20 receives a request with the normal processing URL.
In this example, the SSL handshake process is not shown, but when the upper apparatus 10 transmits a request to the normal process URL of the lower apparatus 20 as an HTTP request thereafter, the HTTP daemon 331 accepts the request (S201). . This request is described as a SOAP message, and the HTTP daemon 331 passes the received request to the first distribution unit 410 together with information (for example, an IP address and a port number) indicating the received URL to request a distribution process (S202). .

  Then, the first distribution unit 410 refers to the table as shown in FIG. 12 based on the information, and determines a request distribution destination according to the URL that received the request (S203). Here, since the URL is a normal process URL and the distribution destination is the second distribution unit 421 for normal process URL, the request is distributed here and a subsequent process is requested (S204). In response to this, the normal processing URL second distribution unit 421 converts the requested SOAP message into DOM tree format data (S205), determines a distribution destination according to the type of request (S206), DOM tree format data is passed to the function 38x to request processing (S207).

Then, the function 38x converts the data in the DOM tree format into structure data that can be processed by logic (S208), executes the logic using this as an argument and performs processing related to the request (S209), and the structure of the processing result The data is converted into data in the DOM tree format (S210), and the data is transferred to the normal processing URL second distribution unit 421 that has requested the processing (S211).
The normal process URL second distribution unit 421 that has received this data converts it into a response SOAP message (S212), and transmits it as an HTTP response to the host device 10 via the HTTP daemon 331 (S213, S214). ).
The above is the processing when the request is received with the normal processing URL.

  When the request is received with the rescue URL, almost the same processing is performed, but the distribution destination by the first distribution unit 410 is the second distribution unit 422 for the rescue URL. Then, the second distribution unit for rescue URL 422 distributes only the request related to the setting of the normal public key certificate to the function 38x, and processes other requests as having no distribution destination. Therefore, when the request is received with the normal processing URL and when the request is received with the rescue URL, the process of almost the same procedure is performed. As a result, when the request is received with the rescue URL, the normal public key certificate is obtained. Processing related to requests other than requests related to document settings can be prohibited.

Next, an example of an HTTP request for a request transmitted from the upper apparatus 10 to the lower apparatus 20 and an HTTP response of a response returned from the lower apparatus 20 to the upper apparatus 10 will be described with reference to FIGS.
First, FIG. 17 shows an example of an HTTP request for a certificate setting request transmitted from the upper apparatus 10 to the rescue URL of the lower apparatus 20.
As described above, this HTTP request is a SOAP message in accordance with SOAP, and a SOAPAction header 61 is added to the end of the HTTP header. The contents thereafter are the SOAP envelope, and the contents of the request are described in the SOAP body included therein. Here, information indicating that the request is a certificate setting request is described in an element indicated by reference numeral 62 immediately below Body. Below that, a parameter 63 indicating the certificate version, a parameter 64 indicating the certificate encryption password, and a parameter 65 indicating the Base64-encoded data obtained by encrypting the certificate to be set are described. The request type can be found by referring to the element 62 or the end of the SOAPAction header 61, and the second distribution unit performs a function distribution process according to this information.

FIG. 18 shows an example of an HTTP response as a response to such an HTTP request.
This HTTP response is also a SOAP message, and includes an HTTP header and a SOAP envelope. In the SOAP body, an element 71 indicates the type of request executed and an element 72 indicates that the execution result is “success”. If the update can be attempted but fails, the content of the element 72 becomes “NG”.

FIG. 19 shows another example of an HTTP request transmitted from the upper apparatus 10 to the rescue URL of the lower apparatus 20.
This HTTP request is also a SOAP message and makes a status acquisition request. Then, as the type of request is different from the case of FIG. 17, the end of the SOAPAction header 81 and the contents of the SOAP body are different from the example shown in FIG. Here, only the element 82 indicating that the request is a status acquisition request is described below the SOAP body, and other parameters are not described.

  FIG. 20 shows an example of an HTTP response as a response to such an HTTP request. Since the status acquisition request is a request that is not distributed to a function when received by a rescue URL, such a command does not exist. The response will be returned as a SOAP Fault. In the SOAP body, information indicating that is described as element 91.

According to the communication system, such as has been described above, even when the regular public key certificate has become unusable by damage or expiration, etc., through the network when the authentication using the rescue public key certificate has succeeded Since this can be set, it is possible to maintain a state in which the lower-level device 20 can always receive normal authentication. Further, this process does not require manual intervention, and such an effect can be easily obtained. In addition, when communication is performed with a rescue URL that performs an SSL handshake using a rescue public key certificate, processing other than processing related to setting of a normal public key certificate is prohibited. High security can be achieved by minimizing the impact of a rescue public key certificate or corresponding private key leaking while maintaining the effects of using the certificate.
If mutual authentication is performed between the lower level device 20 and the higher level device 10 when setting the normal public key certificate, the lower level device 20 receives the normal public key certificate from an inappropriate device. Can be prevented from being stored, and communication safety can be further improved.

[Modification: FIGS. 21 and 22]
Next, a modification of the above-described embodiment will be described.
First, FIG. 21 shows a modification of the functional configuration of the lower level device 20.
In the above-described embodiment, the example in which the functional configuration of the lower level device 20 for executing an operation according to the content of the request received from the higher level device 10 and returning a response is as shown in FIG. 11 has been described. May be as shown in FIG. That is, the mediation daemon 332, the HTTP connection management unit 342, and the HTTP service execution unit 343 may be provided.

In this case, data transfer between the first distribution unit 410 and the HTTP daemon 331 is performed via the HTTP service execution unit 343, and the HTTP service execution unit 343 further includes operation requests regarding functions provided by the various functions 380. Only the POST method that is considered to be transferred to the first distribution unit 410. Further, the intermediation daemon 332 receives a notification regarding communication connection / disconnection from the HTTP daemon 331 and transmits the notification to the HTTP connection management unit 342, and the HTTP connection management unit 342 responds to this notification to the HTTP service execution unit 343 with the HTTP daemon 331. To get an HTTP request.
By adopting such a configuration and providing a plurality of threads corresponding to the HTTP service execution unit 343, a plurality of requests from the host device 10 can be processed in parallel by a single application (process). The response performance with respect to can be improved. The applicant of this case has applied for a patent in the past regarding such technology (Japanese Patent Application No. 2003-81246).

Here, an example has been described in which a plurality of second distribution units are provided and a request is distributed to an appropriate second distribution unit according to the URL received by the first distribution unit 410.
However, for example, only one second distribution unit is provided, and the second distribution unit has the function of the first distribution unit 410, and one second distribution unit is configured according to both the received URL and the request type. It is also possible to distribute requests to functions. In this case, for example, a table in which a request distribution destination is defined for each combination of the received URL and the request type as shown in FIG. 22 is stored, and an HTTP header is added to the function of the distribution destination with reference to this table. Information and DOM tree format data may be distributed.
In this way, the number of program modules can be reduced. However, in the configuration of the embodiment shown in FIG. 11, it is not necessary to pass URL information from the second distribution unit first, so that the configuration shown in FIG. It can be said that it is excellent.

In addition, although an example has been described here in which each function is provided with a function for converting a DOM tree into structure data or a structure data into a DOM tree, a handler for performing such conversion separately from each function. May be provided. In this way, data can be passed to each function in a format that can be directly processed by the function program, so that each function program can be developed without knowledge of SOAP or XML. Can do.
Moreover, although the example which provides the function which converts the SOAP message described in XML in the 2nd distribution part into a DOM tree, or the function which converts a DOM tree into a SOAP message was demonstrated here, it is also essential to do so. Absent. If a program for each function is created so that the SOAP message can be directly handled, the first distribution unit 410 refers to a table as shown in FIG. 22 so that the SOAP request related to the request is directly distributed to each function. It is also possible to do.

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

  Therefore, there is a demand for manufacturing and selling a device that stores a certificate having a low security strength, and subsequently storing a certificate having a high security strength in accordance with the usage environment. For example, for example, the system operator may devise various authentication processing contents or select a highly reliable CA to improve security. When moving from one system to another system (including the case where the setting is simply changed), it may be necessary to replace the certificate used for normal authentication processing. In addition, it is possible that a defect is found in a high-security certificate later and it is necessary to change the authentication processing method.

  In such a case, by using the processing of the above-described embodiment, it is possible to secure a communication path using a relatively low security certificate that can be commonly used in various environments. When communication is performed using the authentication address to be used, if the processing other than the processing related to the setting of the high security certificate is prohibited, the effect of using the low security certificate is sufficiently maintained, High security can be achieved as a whole by minimizing the impact of a low-security certificate or corresponding private key leaking.

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

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

In this way, since the rescue authentication information is common to all devices of the same rank, it is possible to store information corresponding to the rank determined according to the model when the device is manufactured. In other words, it is not information with device identification information, so it is not necessary to prepare and store individual certificates for each device with an identification number after completing the inspection process. Can be memorized by simple work. For example, the rescue authentication information is included in the master of the control program, and the rescue authentication information is stored together when the control program is copied to the apparatus.
If a sufficiently long validity period is set for the rescue public key certificate, it is not necessary to update the rescue authentication information after that, so it is difficult to break, and as described above, the validity period of the normal public key certificate has passed. Thus, even when the authentication using the normal public key certificate cannot be performed, the authentication using the rescue public key certificate included in the rescue authentication information can be maintained.

In this case, since the rescue public key certificate does not include the device identification information, even when authentication using the rescue public key certificate is performed, it is not possible to specifically identify the communication partner device. . However, some information about the communication partner can be obtained.
That is, for example, a certain vendor has a low-level device rescue authentication information (low-level device rescue public key certificate, low-level device rescue private key, and high-level device authentication rescue root key) for all devices corresponding to the low-level device 20 among its own products. Certificate) is stored, and all the devices corresponding to the higher level device 10 that is the communication partner of the higher level device rescue authentication information (high level device rescue public key certificate, higher level device rescue private key and lower level device authentication rescue) If the root device 20 is stored, if the authentication process is successful, the lower level device 20 can provide a public key certificate that can be verified with the host device rescue root key certificate stored in itself. It can be recognized that the sending partner is the host device 10 of the same vendor, and conversely, the host device 10 also stores itself. Partner which has transmitted the public key certificate that can verify the validity skew root key certificate can recognize that it is a lower-level apparatus 20 of the same vendor.

And if such authentication is successful, it is possible to share a common key with a communication partner as described above and provide a secure communication path using common key encryption. It is also possible to specify a communication partner by exchanging
It is also conceivable that the identification information of the device is not included in the normal public key certificate as well. Even if it does in this way, the safety | security higher than a rescue public key certificate can be acquired by the part for which an expiration date is short.

Further, in the above-described embodiment, an example in which the upper device 10 and the lower device 20 perform authentication according to SSL as described with reference to FIG. 24 or FIG. 26 has been described. However, even if this authentication is not necessarily such, this embodiment is effective.
TLS (Transport Layer Security) improved from SSL is also known, but it is naturally applicable to the case where authentication processing based on this protocol is performed.
Also, the request description format is not limited to the SOAP message. By accepting requests as information written in such a structured language format, data versatility can be improved and data formats can be designed and modified easily. Is also possible.

  Moreover, although embodiment mentioned above demonstrated the example which provides CA separately from the high-order apparatus 10, providing this and this integrally is not prevented. In this case, components such as a CPU, ROM, and RAM for realizing the CA function may be provided independently. However, the CPU, ROM, RAM, etc. of the host device 10 are used, and appropriate software for the CPU is installed. You may make it function as CA by making it perform.

Furthermore, although it has already been described that the higher-level device 10 and the lower-level device 20 can have various configurations depending on the purpose, in this case, the types of functions included in the various functions 380 are the types of devices and It can be determined appropriately according to the configuration, and if the processing related to the request other than the request related to the setting of the normal public key certificate is prohibited when the communication partner is authenticated by the rescue public key certificate, the above-described implementation The effect as in the case of the form can be obtained. Requests to be excluded from prohibition are not limited to requests related to normal public key certificate settings, and some functions are used when authentication is performed using a rescue public key certificate with relatively low security. It is also conceivable to perform a function restriction that restricts the function.
Specific examples of the upper device 10 and the lower device 20 include, for example, image processing devices such as printers, FAX devices, copiers, scanners, digital multifunction devices, network home appliances, vending machines, medical devices in a remote management system. , A power supply device, an air conditioning system, a metering system for gas, water, electricity, etc., a communication device provided with a communication function in an automobile, an aircraft, etc., is a subordinate device 20 that is a managed device, and collects information from these managed devices It is conceivable that the management device for sending a command and operating it is the host device 10.

In addition, a program according to the present invention provides a digital certificate with a plurality of addresses to authenticate a computer to a communication partner, and performs communication with an address provided with the digital certificate authenticated to the communication partner. The above-described effects can be obtained by causing a computer to execute such a program.
Such a program may be stored in a storage means such as a ROM or HDD provided in the computer from the beginning, but a non-volatile recording such as a CD-ROM or flexible disk, SRAM, EEPROM, memory card or the like as a recording medium. It can also be recorded on a medium (memory) and provided. Each procedure described above can be executed by installing a program recorded in the memory in a computer and causing the CPU to execute the program, or causing the CPU to read and execute the program from the memory.
Furthermore, it is also possible to download and execute an external device that is connected to a network and includes a recording medium that records the program, or an external device that stores the program in the storage unit.

As described above, according to the communication device, communication system, communication device control method, or program of the present invention, a communication device that includes a communication unit and provides a certificate to authenticate a communication partner during communication. When a communication system is configured using the above, it is possible to easily maintain a state in which normal authentication can be received while maintaining security. Therefore, the operation of the communication system can be performed with high reliability.

It is a block diagram which shows the structure of embodiment of the communication system of this invention comprised using the communication apparatus of embodiment of this invention. It is a block diagram which shows the hardware constitutions of the high-order apparatus shown in FIG. It is explanatory drawing which shows the outline | summary of the communication system in the communication system shown in FIG. It is a figure which shows the kind of the certificate and key which the high-order apparatus shown in FIG. 1 and the low-order apparatus have memorize | stored as authentication information. It is a figure for demonstrating the example of a format of a normal public key certificate. It is a figure which shows the example of the general public key certificate produced according to the format described in FIG. Similarly, it is a figure which shows the example of a normal public key certificate for contrast with a rescue public key certificate. Similarly, it is a figure which shows the example of a rescue public key certificate for contrasting with a normal public key certificate. It is a figure which shows the example of URL used for designation | designated of a communication destination, when a client requests | requires communication to a server. It is a figure for demonstrating the structure and operating system of the communication system shown in FIG.

It is a figure which shows the function structure in a low-order apparatus for performing the operation | movement according to the content of the request | requirement received from the high-order apparatus, and returning a response. It is a figure which shows the example of the table which prescribed | regulated the distribution destination of the request | requirement by a 1st distribution part for every URL. It is a figure which shows the example of the table which prescribed | regulated the relationship between the kind of request | requirement about each 2nd distribution part, and a distribution destination. It is a flowchart which shows the process performed when the low-order apparatus shown in FIG. 1 receives a communication request. It is a flowchart which shows the subsequent process. It is a sequence diagram which shows the example of a processing sequence when the low-order apparatus shown in FIG. 1 receives the request | requirement by normal process URL. FIG. 2 is a diagram illustrating an example of an HTTP request for a certificate setting request transmitted from a higher-level device to a rescue URL of a lower-level device in the communication system illustrated in FIG. 1. It is a figure which shows the example of the HTTP response of a response with respect to the HTTP request shown in FIG. It is a figure which shows the example of the HTTP request different from FIG. 17 transmitted to the rescue URL of a low-order apparatus from a high-order apparatus. It is a figure which shows the example of the HTTP response of a response with respect to the HTTP request shown in FIG.

It is a figure which shows the modification of the function structure of the low-order apparatus shown in FIG. It is a figure which shows the example of the table which a 2nd distribution part refers in the modification of embodiment of this invention. It is a figure for demonstrating the structure at the time of providing the low-order apparatus with respect to the communication system shown in FIG. It is a figure which shows the flowchart of the process performed in each apparatus when two communication apparatuses perform mutual authentication according to SSL with the information used for the process. FIG. 25 is a diagram for describing a relationship among a root key, a root private key, and a public key certificate in the authentication process illustrated in FIG. 24. It is a figure corresponding to FIG. 24 which shows the process performed in each apparatus when two communication apparatuses perform one-way authentication according to SSL.

DESCRIPTION OF SYMBOLS 10 ... Host apparatus, 11 ... CPU, 12 ... ROM, 13 ... RAM, 14 ... HDD,
15 ... Communication I / F, 16 ... System bus, 20 ... Subordinate device, 30 ... Network,
40 ... HTTP request, 50 ... HTTP response,
331 ... HTTP daemon, 380 ... various functions, 410 ... first distribution unit,
421 ... Normal processing URL second distribution unit, 422 ... Rescue URL second distribution unit

Claims (27)

Providing a certificate by a plurality of addresses in order to authenticate the communication partner, a communication means for communicating with the address that provided the authentication certificate to said communication partner, the request received from the communication partner by the communication unit A communication device having request execution means for performing processing according to
The communication means provides two types of certificates having different validity periods, and the validity period set of the two types of certificates is short at the first address among the plurality of addresses. Means for providing a short-term certificate of one of the two types, and a second address for providing a long-term certificate having a longer valid period of the two types of certificates ,
A communication apparatus characterized in that, when communication is performed using the second address, processing related to a request other than a request related to setting of the short-term certificate is not performed . Providing a certificate by a plurality of addresses in order to authenticate the communication partner, a communication means for communicating with the address that provided the authentication certificate to said communication partner, the request received from the communication partner by the communication unit A communication device having request execution means for performing processing according to
It said communication means, wherein in the first address of the plurality of addresses provides a short-term certificate validity period than the product life of the communication device is a short certificate, the second address product life of the communication device lifetime than are means for providing a long-term certificate is a long certificate,
A communication apparatus characterized in that, when communication is performed using the second address, processing related to a request other than a request related to setting of the short-term certificate is not performed . Providing a certificate by a plurality of addresses in order to authenticate the communication partner, a communication means for communicating with the address that provided the authentication certificate to said communication partner, the request received from the communication partner by the communication unit A communication device having request execution means for performing processing according to
Said communication means, wherein in the first address of the plurality of addresses provides a short-term certificate is a certificate expire during the operation of the communication device expires, the second address during operation of the communication device A means of providing a long-term certificate that is a certificate that does not expire ,
A communication apparatus characterized in that, when communication is performed using the second address, processing related to a request other than a request related to setting of the short-term certificate is not performed . Providing a certificate by a plurality of addresses in order to authenticate the communication partner, a communication means for communicating with the address that provided the authentication certificate to said communication partner, the request received from the communication partner by the communication unit A communication device having request execution means for performing processing according to
The communication means provides a short-term certificate that is a certificate that has a validity period at a first address among the plurality of addresses, and a long-term certificate that is a certificate that has no validity period at a second address. Means to provide
A communication apparatus, comprising: a prohibiting unit that prohibits processing related to a request other than a request related to setting of the short-term certificate when communication is performed using the second address. The communication device according to any one of claims 1 to 4, wherein
It authenticates receiving a certificate of the communication partner from a communication partner that provides the certificate, provided authentication means for permitting only the subsequent communication if the authentication is successful,
The communication apparatus, wherein the request execution means is provided with means for updating the short-term certificate when the short-term certificate setting request is received from the communication partner. The communication device according to any one of claims 1 to 5,
The request relating to the setting of the short-term certificate is an acquisition request for information necessary for creating the short-term certificate and a setting request for the short-term certificate. The communication device according to any one of claims 1 to 6,
The request execution means includes a plurality of request processing means for performing predetermined processing corresponding to the request,
A distribution unit that distributes the request to each of the request processing units according to the received address and the type of request;
When communication is performed using the second address, the distribution unit does not distribute requests other than requests related to the setting of the short-term certificate to the request processing unit . communication device being characterized in that so as not to perform processing according to the request. The communication device according to any one of claims 1 to 7,
The communication apparatus, wherein the request is described as a SOAP message. The communication device according to any one of claims 1 to 8,
The authentication is performed by an authentication process according to an SSL or TLS protocol,
The communication apparatus according to claim 1, wherein the certificate is a public key certificate used for the authentication process. Providing a certificate by a plurality of addresses in order to authenticate the communication partner, a communication means for communicating with the address that provided the authentication certificate to said communication partner, the request received from the communication partner by the communication unit A communication system comprising a lower-level device having a request execution means for performing processing according to a higher-level device serving as a communication partner of the lower-level device,
The communication means of the lower level device provides two types of certificates with different validity periods, and the first address among the plurality of addresses is set out of the two types of certificates . A means for providing a short-term certificate having a shorter validity period, and providing a long-term certificate having a longer validity period set out of the two types of certificates at the second address;
The lower device, when communicating with said second address so as not to perform processing according to requests other than requests for setting of the short-term certificate,
A communication system characterized in that the host device is provided with authentication means for authenticating a communication partner using a certificate received from the communication partner. Providing a certificate by a plurality of addresses in order to authenticate the communication partner, a communication means for communicating with the address that provided the authentication certificate to said communication partner, the request received from the communication partner by the communication unit A communication system comprising a lower-level device having a request execution means for performing processing according to a higher-level device serving as a communication partner of the lower-level device,
The communication means of the lower unit, wherein the plurality of first addresses of the address provides short-term certificate is valid period is short certificate than the product life of the lower device in the second address the lower A means of providing a long-term certificate, which is a certificate whose validity period is longer than the product lifetime of the device,
Do not perform processing related to requests other than requests related to the setting of the short-term certificate when communicating with the lower-level device using the second address,
A communication system characterized in that the host device is provided with authentication means for authenticating a communication partner using a certificate received from the communication partner. The communication system according to claim 10 or 11,
The lower device performs authentication from the provided communication partner receives the certificate of the communicating party the certificate, provided authentication means for permitting only the subsequent communication if the authentication is successful,
A communication system, characterized in that said request execution means of said subordinate device is provided with means for updating said short-term certificate when said short-term certificate setting request is received from a communication partner. The communication system according to any one of claims 10 to 12,
The request relating to the setting of the short-term certificate is an acquisition request for information necessary for creating the short-term certificate and a setting request for the short-term certificate. A communication system according to any one of claims 10 to 13,
The communication system according to claim 1, wherein the request is described as a SOAP message. The communication system according to any one of claims 10 to 14,
The authentication is performed by an authentication process according to an SSL or TLS protocol,
The communication system, wherein the certificate is a public key certificate used for the authentication process. A request received from a communication partner in the communication by causing the communication device to provide a certificate with a plurality of addresses in order to be authenticated by the communication partner, and to perform communication with the address provided with the certificate authenticated to the communication partner. A communication device control method for performing processing according to
The communication apparatus is provided with two types of certificates having different validity periods, and the first address of the plurality of addresses has a validity period set of the two types of certificates. The short-term certificate of the shorter one is provided, and the long-term certificate having the longer valid period among the two types of certificates is provided at the second address,
A method for controlling a communication apparatus, wherein when performing communication using the second address, processing related to a request other than a request related to setting of the short-term certificate is not performed . A request received from a communication partner in the communication by causing the communication device to provide a certificate with a plurality of addresses in order to be authenticated by the communication partner, and to perform communication with the address provided with the certificate authenticated to the communication partner. A communication device control method for performing processing according to
The communication device is provided with a short-term certificate that is a certificate whose validity period is shorter than the product life of the communication device at the first address among the plurality of addresses, and the product life of the communication device at the second address. to provide long-term certificate is valid period is longer certificates than,
A method for controlling a communication apparatus, wherein when performing communication using the second address, processing related to a request other than a request related to setting of the short-term certificate is not performed . A communication device control method according to claim 16 or 17,
Furthermore, in the communication device, the certificate from the provided communication partner by receiving a certificate of the communication counterpart to perform the authentication, so as to permit only subsequent communication if the authentication is successful,
The communication control method, characterized in that for updating the short-term certificate when receiving the setting request of the short-term certificate from the communicating party. A communication device control method according to any one of claims 16 to 18, comprising:
The request for setting the short-term certificate is a request for acquiring information necessary for creating the short-term certificate and a request for setting the short-term certificate. A method for controlling a communication device according to any one of claims 16 to 19, comprising:
The method for controlling a communication apparatus, wherein the request is described as a SOAP message. A communication device control method according to any one of claims 16 to 20, comprising:
The authentication is performed by an authentication process according to an SSL or TLS protocol,
The method of controlling a communication apparatus, wherein the certificate is a public key certificate used for the authentication process. The computer provides a certificate multiple addresses to authenticate to the communication partner, a communication means for communicating with the address that provided the authentication certificate to said communication partner, received from the communication counterpart by said communication means A program for functioning as a request execution means for performing processing according to the requested request,
The communication means provides two types of certificates having different validity periods, and the validity period set of the two types of certificates is short at the first address among the plurality of addresses. Means for providing a short-term certificate of one of the two types, and a second address for providing a long-term certificate having a longer valid period of the two types of certificates ,
Furthermore, the program the computer, when performing communication by said second address, characterized in that it comprises a program for not to perform the processing according to requests other than requests for setting of the short-term certificate. The computer provides a certificate multiple addresses to authenticate to the communication partner, a communication means for communicating with the address that provided the authentication certificate to said communication partner, received from the communication counterpart by said communication means A program for functioning as a request execution means for performing processing according to the requested request,
It said communication means, wherein in the plurality of first addresses of the address provides short-term certificate validity period than the product life of the device comprising the computer is a short certificate, the second address comprises the computer A means of providing a long-term certificate, which is a certificate whose validity period is longer than the product lifetime of the device,
Furthermore, the program the computer, when performing communication by said second address, characterized in that it comprises a program for not to perform the processing according to requests other than requests for setting of the short-term certificate. The program according to claim 22 or 23,
Furthermore, the computer, the certificate from the provided communication partner receives the certificate of the communication partner to authenticate a program to function as an authentication device that only allows subsequent communication if the authentication is successful Including
The program according to claim 1, wherein the request execution means is provided with a function of updating the short-term certificate when a request for setting the short-term certificate is received from the communication partner. A program according to any one of claims 22 to 24,
The request relating to the setting of the short-term certificate is an acquisition request for information necessary for creating the short-term certificate and a setting request for the short-term certificate. A program according to any one of claims 22 to 25,
The program characterized in that the request is described as a SOAP message. A program according to any one of claims 22 to 26,
The authentication is performed by an authentication process according to an SSL or TLS protocol,
The certificate program, which is a public key certificate used for the authentication process.

Images