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

Description

  The present invention comprises a communication device that includes communication means and provides a digital certificate for receiving authentication at the time of communication, a lower device that is such a communication device, and a higher device that is the communication partner. The present invention relates to a communication system, a communication apparatus control method for providing a digital 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.

  As described above, the public key certificate issued by the third party organization is excellent in terms of reliability, but in order to maintain the reliability, the validity period is relatively short, for example, 1 to 3 years. It is often set and it is necessary to receive a new public key certificate when the expiration date expires. It is also conceivable that the operator of the communication device discards the previous contract and enters into a contract with a new third party period. In such a case, there is a problem that the public key certificate stored in the communication device may not be able to receive authentication from the communication partner.

Even in such a case, if the operator can easily set a new public key certificate by operating the device at the time when authentication is not possible, the operator can be authenticated, etc. Is not a serious problem. However, other settings on the communication system may be difficult because it is difficult for the operator to set due to the user's proficiency and usage environment, or because it is not preferable for the operator to set the certificate freely. When a certificate is set remotely from the communication device, there is no means for maintaining security in a state where authentication cannot be performed, and this is a serious problem.
The present invention solves such a problem, and includes a communication means, and a communication device that provides a digital certificate for receiving authentication at the time of communication, or a communication system configured using such a communication device It is an object of the present invention 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 digital certificate with a plurality of addresses in order to receive authentication from a communication partner, and communicates with the address provided with the digital certificate authenticated by the communication partner. And a request execution unit that performs processing according to a request received from a communication partner by the communication unit. The communication unit is configured to perform public authentication at a first address among the plurality of addresses. A public certificate, which is a digital certificate issued by a station, is provided, and a private certificate, which is a digital certificate issued by a private certificate authority, is provided at a second address, and communication is performed at the second address. If you do this, set up prohibition means to prohibit processing related to requests other than those related to public certificate settings. Those were.

In such a communication device, authentication is performed by receiving the digital certificate of the communication partner from the communication partner that provided the digital certificate, and only when the authentication is successful, an authentication unit that permits subsequent communication is provided, The request execution means may be provided with means for updating the public certificate when the public certificate setting request is received from the communication partner.
Further, the request relating to the setting of the public certificate may be an acquisition request for information necessary for creating the public certificate and a setting request for the public certificate.

Furthermore, the request execution means is provided with a plurality of request processing means for performing predetermined processing corresponding to the request, and is provided with a distribution means for distributing the request to the request processing means according to the received address and the type of request, The prohibiting means may be a means for prohibiting the processing by preventing a request other than a predetermined request from being distributed to the request processing means depending on the address at which the distributing means performs the communication.
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 digital certificate may be a public key certificate used for the authentication process.

  Further, the communication system of the present invention provides a digital certificate with 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 digital certificate authenticated by the communication partner; In a communication system comprising a lower-level device having a request execution unit that performs processing according to a request received from a communication partner by the communication unit, and a higher-level device that is a communication partner of the lower-level device, the lower-level device The communication means provides a public certificate which is a digital certificate issued by a public certificate authority at a first address among the plurality of addresses, and a digital certificate issued by a private certificate authority at a second address. As a means to provide a private certificate, when communicating with the lower-level device using the second address Provides a prohibition means for prohibiting processing related to a request other than the request relating to the setting of the public certificate, and an authentication means for authenticating the communication partner using the digital certificate received from the communication partner is provided in the host device. It is a thing.

In such a communication system, the lower-level device receives the digital certificate of the communication partner from the communication partner that provided the digital certificate, performs authentication, and permits subsequent communication only when the authentication is successful. An authentication unit may be provided, and a unit for updating the public certificate when the request execution unit of the lower-level device receives the public certificate setting request from a communication partner.
Further, the request relating to the setting of the public certificate may be an acquisition request for information necessary for creating the public certificate and a setting request for the public 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 digital certificate may be a public key certificate used for the authentication process.

  Further, the communication device control method of the present invention causes the communication device to provide a digital certificate with a plurality of addresses in order to receive authentication from the communication partner, and at the address provided with the digital certificate authenticated to the communication partner. In a communication device control method for performing communication and performing processing according to a request received from a communication partner in the communication, the communication device is issued by a public certificate authority at the first address among the plurality of addresses. A public certificate that is a digital certificate, a private certificate that is a digital certificate issued by a private certificate authority at the second address, and the communication at the second address Processing related to requests other than requests related to public certificate settings is prohibited.

In such a communication device control method, the communication device is made to receive and authenticate the digital certificate of the communication partner from the communication partner that provided the digital certificate, and only when the authentication succeeds. It is preferable to allow communication and update the public certificate when the public certificate setting request is received from the communication partner.
Further, the request relating to the setting of the public certificate may be an acquisition request for information necessary for creating the public certificate and a setting request for the public 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 digital certificate may be a public key certificate used for the authentication process.

  Further, the program of the present invention provides a communication means for providing a digital certificate with a plurality of addresses in order to authenticate a computer to a communication partner and performing communication with an address provided with the digital certificate authenticated by the communication partner. And a program for causing the communication means to function as a request execution means for performing processing according to a request received from a communication partner, the communication means is issued by a public certificate authority at the first address among the plurality of addresses. And a means for providing a public certificate, which is a digital certificate issued by a private certificate authority at a second address, and further comprising: If communication is performed using an address, the request for setting the public certificate is not included. It is obtained to include the program for functioning as a prohibiting means for prohibiting the process according to the request.

In such a program, the computer further performs authentication by receiving the digital certificate of the communication partner from the communication partner that provided the digital certificate, and permits subsequent communication only when the authentication is successful. It is preferable that the request execution unit includes a function for updating the public certificate when a request for setting the public certificate is received from the communication partner, including a program for causing the authentication unit to function.
Further, the request relating to the setting of the public certificate may be an acquisition request for information necessary for creating the public certificate and a setting request for the public 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 digital certificate may be a public key certificate used for the authentication process.

According to the communication apparatus, the communication system, or the control method of the communication apparatus of the present invention as described above, a communication apparatus that includes a communication unit and provides a digital certificate to receive authentication from a communication partner at the time of communication. In a communication system configured using such 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 the same effect 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 verified 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 public certificate. Here, the public certificate authority is a certificate authority that has been widely recognized by the public, such as the third-party organization described in the background section, or a certificate authority or law that has been publicly recognized as reliable. A certificate authority that can issue a certificate that is generally accepted, such as a certificate authority whose certificate is valid. The public certificate authority is a certificate authority operated by an operator different from the certificate user.

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.
In addition, in order to enable each device to check the validity of public key certificates issued by a plurality of public certificate authorities, it is also possible to store a root key certificate corresponding to each public certificate authority. Conceivable.

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, as described above, when each device receives a normal public key certificate from a communication partner, a root key (certificate) for confirming the validity of the public key certificate issued by the issuing certificate authority. ) Is not stored, the validity of the received normal public key certificate cannot be confirmed. Therefore, in this case, authentication cannot be performed.
If each device does not have a function (such as a module for realizing encryption / decryption) for authenticating with the normal public key certificate received from the communication partner, naturally, the normal public key is used. Certificate authentication is not possible. Such a situation occurs when the host device 10 switches the certificate used for authentication processing, or when the lower device 20 is connected to the host device 10 that uses a certificate from a different certificate authority than before. It is also possible. This is because the operator of the communication system appropriately determines the certificate issued by which public certificate authority corresponds in consideration of various conditions.

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

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

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

However, the major difference from the regular authentication information is that the rescue public key certificate is a public key certificate issued by a private certificate authority. A private certificate authority is a certificate authority whose certificate is not generally accepted, and is not widely accepted. Further, it is a certificate authority operated by a certificate user, for example, a certificate authority operated by the company in order to manage a certificate used in the company.
Certificates issued by such certificate authorities are generally considered to be less reliable than certificates issued by public certificate authorities, but private certificate authorities are not considered by installers in consideration of safety and convenience. Since it can be operated according to its own policy, there is also an advantage that it is easy to issue a certificate suitable for the application. Even in the case of a private certificate authority, if security is taken into consideration, it is possible to provide a certificate with relatively high security.

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 issuer of the certificate normally uses “PublicCA” of YYY as shown by the symbol D for the public key certificate, while “PublicCA” of XXX as shown by the symbol G of the rescue public key certificate. "This is a different CA. “PublicCA” corresponds to a public certificate authority, and “PrivateCA” corresponds to a private certificate authority. Here, the private certificate authority is provided by XXX, which is the manufacturer of the issuing device.
Then, rescue authentication information including such a rescue public key certificate is prepared, and even if the contents of the rescue authentication information are considered in terms of export restrictions, the contents of authentication processing that is prevalent in each region, etc. It is preferable that authentication can be performed by an authentication process that can be commonly used in various environments assumed to be used.

In this way, the communication partner can be authenticated by the rescue public key certificate even in an environment where authentication using the normal public key certificate cannot be performed. If such authentication is successful, the common key is shared with the communication partner as described above, and a secure communication path using common key encryption can be provided. Therefore, using this communication path, a new normal public key certificate suitable for the environment at the time of communication can be transmitted to the communication partner and set.
In addition, since public key certificates issued by public certificate authorities require strict management and security, it may be difficult to issue certificates that can be used in various environments as described above. Yes, it costs money. However, since private certificate authorities can specify the specifications of certificates relatively freely, they can be used in various environments by reducing encryption strength and avoiding the latest and less popular authentication processing algorithms. It is also possible to issue a certificate that can be used for If the device manufacturer itself provides a private certificate authority, it is possible to issue a certificate at a low cost. Further, for example, even when the lower-level device 20 and the higher-level device 10 have different manufacturers, or the communication system operator performs various customizations, the rescue public key certificate is provided free of charge, etc. It becomes easy to encourage manufacturers and operators to support authentication using rescue public key certificates.

  Note that the rescue public key certificate issued by the private certificate authority may be inferior in safety and reliability as compared to the normal public key certificate issued by the public certificate authority. However, if authentication processing is performed using rescue authentication information, if only limited requests such as updating of regular authentication information including normal public key certificates are allowed, the private certificate authority Even if the security is slightly reduced due to the use of the certificate issued by, there is no big problem.

Here, returning to the description of FIG. 7 and FIG. 8, in these two public key certificates, the normal public key certificate has an effective period from midnight on January 1, 2003 as indicated by the symbol E. While it is one year from midnight on January 1, 2004, in the rescue public key certificate, as indicated by the symbol H, from midnight on January 1, 2000 to midnight on January 1, 2050 For 50 years.
In other words, since a public certificate is usually issued by a public certificate authority, the manufacturer or user of the device cannot freely set the validity period, and the validity period is set short for safety reasons. It is usually done. Therefore, it is necessary to renew the certificate within the validity period. In an apparatus that requires automatic certificate renewal, there is a risk of damage to the certificate due to overdue of the renewal deadline or abnormality during renewal as described above.

On the other hand, if the rescue authentication information is positioned as authentication information for securing an emergency communication path when authentication using the normal public key certificate cannot be performed, the rescue public key certificate will expire after the expiration date. Since it is necessary to update the rescue public key certificate, 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.

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

  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, if the private certificate authority issues rescue authentication information including a rescue public key certificate under conditions suitable for securing an emergency communication path, it is safer than regular authentication information. It may be slightly inferior in nature.
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, if the lower level device 20 is placed in an environment that cannot be supported by the authentication using the set normal public key certificate, or if the normal public key certificate becomes unusable due to damage, expiration, etc. Since the normal public key certificate with which the device 10 can confirm the validity cannot be transmitted, the authentication process fails as shown in FIG. 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 if the lower level device 20 is placed in an environment that cannot be supported by the authentication using the set normal public key certificate, or even if the normal public key certificate becomes unusable due to damage or expiration, the rescue release In an environment where the key certificate can be used, it is possible to quickly return to a normal state and maintain a state where authentication using a normal public key certificate is possible. That is, it is possible to maintain a state in which the lower level device 20 can receive normal authentication. 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 public CA (not shown) when updating the normal public key certificate. A processing procedure is performed in which a certificate is issued and acquired, and is transmitted to the lower-level device 20 and stored together with a certificate setting request. The public CA is a public CA that issues a certificate that can be used in the authentication process performed by the higher-level device 10, and the public CA that has issued the normal public key certificate that the lower-level device 20 has previously stored. May be different.

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.
Also, when using a public key certificate issued by a public CA, rather than requesting the public CA to issue a certificate directly from the host device 10 and entrusting the certificate management to the CA, It is preferable that the host device 10 has a function for managing issued certificates, or the host device 10 requests the CA to issue a certificate via a device that manages certificates issued therebetween.

  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 setting the normal public key certificate is a request for obtaining information necessary for creating a normal public key certificate (including information description) and a request for setting the normal public key certificate. Among the specific information acquisition function 381, the functions corresponding to the ID, model name, and certificate version information, and the certificate setting function 387. 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 as described above, even when the normal public key certificate becomes unusable due to damage, expiration, etc., if authentication using the rescue public key certificate succeeds, Therefore, it is possible to maintain a state in which the lower apparatus 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.

In addition, the rescue public key certificate issued by the private certificate authority is slightly less reliable than the public key certificate issued by the public certificate authority. it can. By preparing such a certificate, it can be placed in an environment that cannot be handled by the authentication using the set normal public key certificate, or the normal public key certificate can be used due to damage or expiration. Even if it is lost, there is an effect that a secure communication path using the common key cryptography can be secured in an environment where the rescue public key certificate can be used. And if it is a private certificate authority, a rescue public key certificate that can be used in a wide range of environments, has a long validity period, does not expire, and can be prevented from being renewed and damaged at the time of renewal is issued. be able to.
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.

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

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

  In such a case, 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 the communication partner by exchanging.
It should be noted that the normal public key certificate may not include the device identification information as long as the public certificate authority provides such a service. Even if it does in this way, it is considered that the reliability is high because it is issued by a public certificate authority. Further, if the validity period is shorter than that of the rescue public key certificate, the security can be improved as much as that of the rescue public key certificate.
Further, the validity period of the normal public key certificate and the rescue public key certificate is not particularly limited to the above-described relationship. Furthermore, the type of certificate authority is also regarded as one element of security level, and the normal public key certificate and rescue public key are determined according to the validity period, presence / absence of device identification information, encryption strength of authentication processing using the certificate, etc. It is also possible to make a difference between certificates.

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.

  In the above-described embodiment, an example in which the CA is provided separately from the host device 10 has been described. However, the configuration in which these are integrated is not excluded. 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, the communication device includes a communication unit and provides a digital certificate for authenticating the communication partner during communication. When configuring a communication system using an apparatus, 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.

Explanation of symbols

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 (21)

A communication unit that provides a digital certificate with a plurality of addresses to receive authentication from a communication partner, and communicates with the address that provides the digital certificate authenticated by the communication partner, and received from the communication partner by the communication unit A communication device having request execution means for performing processing according to a request,
The communication means provides a public certificate which is a digital certificate issued by a public certificate authority at a first address among the plurality of addresses, and a digital certificate issued by a private certificate authority at a second address. Is a means of providing a private certificate that is
A communication apparatus, comprising: a prohibition unit that prohibits processing related to a request other than a request related to setting of the public certificate when communication is performed using the second address. The communication device according to claim 1,
An authentication unit that performs authentication by receiving the digital certificate of the communication partner from the communication partner that provided the digital certificate, and permits subsequent communication only when the authentication is successful,
A communication apparatus characterized in that said request execution means is provided with means for updating said public certificate when said public certificate setting request is received from said communication partner. The communication device according to claim 1 or 2,
The request relating to the setting of the public certificate is an acquisition request for information necessary for creating the public certificate and a setting request for the public certificate. The communication device according to any one of claims 1 to 3,
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;
The prohibiting unit is a unit that prohibits the processing by preventing a request other than a predetermined request from being distributed to the request processing unit depending on an address with which the distributing unit performs the communication. A communication device. The communication device according to any one of claims 1 to 4, wherein
The communication apparatus, wherein the request is described as a SOAP message. The communication device according to any one of claims 1 to 5,
The authentication is performed by an authentication process according to an SSL or TLS protocol,
The communication apparatus, wherein the digital certificate is a public key certificate used for the authentication process. A communication unit that provides a digital certificate with a plurality of addresses to receive authentication from a communication partner, and communicates with the address that provides the digital certificate authenticated by the communication partner, and 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 request, and a higher-level device that is a communication partner of the lower-level device,
The communication means of the subordinate device provides a public certificate that is a digital certificate issued by a public certificate authority at a first address among the plurality of addresses, and is issued by a private certificate authority at a second address. Is a means to provide a private certificate that is a digital certificate,
Providing a prohibition means for prohibiting processing related to a request other than a request related to setting of the public certificate when the lower-level device performs communication 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 digital certificate received from the communication partner. The communication system according to claim 7, wherein
The lower device is provided with authentication means for receiving and authenticating the digital certificate of the communication partner from the communication partner providing the digital certificate, and permitting subsequent communication only when the authentication is successful,
A communication system, characterized in that the request execution means of the lower-level device is provided with means for updating the public certificate when the public certificate setting request is received from a communication partner. The communication system according to claim 7 or 8,
The request relating to the setting of the public certificate is an acquisition request for information necessary for creating the public certificate and a setting request for the public certificate. A communication system according to any one of claims 7 to 9,
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 7 to 10,
The authentication is performed by an authentication process according to an SSL or TLS protocol,
The communication system, wherein the digital certificate is a public key certificate used for the authentication process. Let the communication device provide a digital certificate with a plurality of addresses in order to receive authentication from the communication partner, perform communication with the address provided with the digital certificate authenticated by the communication partner, and receive from the communication partner in the communication A method for controlling a communication device that performs processing according to a requested request,
The communication apparatus is provided with a public certificate which is a digital certificate issued by a public certificate authority at a first address among the plurality of addresses, and a digital certificate issued by a private certificate authority at a second address. Provide a private certificate that is
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 public certificate is prohibited. A communication device control method according to claim 12, comprising:
Further, the communication device is allowed to perform authentication by receiving the digital certificate of the communication partner from the communication partner that provided the digital certificate, and permit subsequent communication only when the authentication is successful,
A control method for a communication apparatus, comprising: updating a public certificate when a public certificate setting request is received from a communication partner. A method for controlling a communication device according to claim 12 or 13,
The request for setting the public certificate includes an acquisition request for information necessary for creating the public certificate and a request for setting the public certificate. A method for controlling a communication device according to any one of claims 12 to 14,
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 12 to 15,
The authentication is performed by an authentication process according to an SSL or TLS protocol,
The method for controlling a communication apparatus, wherein the digital certificate is a public key certificate used for the authentication process. A communication means for providing a digital certificate with a plurality of addresses in order to authenticate the computer with a communication partner, and communicating with the address provided with the digital certificate authenticated by the communication partner; A program for functioning as a request execution means for performing processing according to a request received from
The communication means provides a public certificate which is a digital certificate issued by a public certificate authority at a first address among the plurality of addresses, and a digital certificate issued by a private certificate authority at a second address. Is a means of providing a private certificate that is
And a program for causing the computer to function as a prohibiting unit that prohibits processing related to a request other than the request related to the setting of the public certificate when performing communication using the second address. program. A program according to claim 17,
Furthermore, the computer receives the digital certificate of the communication partner from the communication partner that provided the digital certificate, performs authentication, and functions as an authentication unit that permits subsequent communication only when the authentication is successful. Including the program
The program according to claim 1, wherein the request execution unit is provided with a function of updating the public certificate when the public certificate setting request is received from the communication partner. The program according to claim 17 or 18, comprising:
The program relating to the setting of the public certificate is an acquisition request for information necessary for creating the public certificate and a setting request for the public certificate. A program according to any one of claims 17 to 19,
The program characterized in that the request is described as a SOAP message. A program according to any one of claims 17 to 20,
The authentication is performed by an authentication process according to an SSL or TLS protocol,
The digital certificate is a public key certificate used for the authentication process.

Images