JP2005130459A - Certificate setting method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a certificate setting method capable of easily and securely setting a digital certificate to a communication apparatus in the case of setting the digital certificate in response to applications of a user to the communication apparatus. <P>SOLUTION: In the case of using a certificate writer 160 to store a digital certificate being a regular public key certificate used for authentication processing at communication to the communication apparatus, a first step wherein a component A for storing a rescue public key certificate being a digital certificate issued by a private certificate authority is mounted on a body of the communication apparatus, and a second step wherein the certificate writer 160 and the communication apparatus make authentication processing using the rescue public key certificate and the certificate writer 160 stores the regular public key certificate to the communication apparatus when the authentication processing is successful, are executed in this order. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a certificate setting method for causing a communication device to store a digital certificate used for authentication processing using a certificate setting device.

  2. Description of the Related Art Conventionally, a variety of systems have been constructed by connecting a plurality of communication devices each having a communication function via a network so that communication is possible. As an example, there is a so-called electronic commerce system in which an order for a product is transmitted from a computer such as a PC functioning as a client device, and the order is received by a server device that can communicate with the order 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 addition, especially when communicating over the Internet, it is often necessary for information to pass through an irrelevant computer until it reaches the communication partner, so when sending confidential information, the contents must not be seen. There is also. 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. 19 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. 19, when performing mutual authentication according to SSL, it is necessary to first store a root key certificate, a private key, and a public key certificate in both communication apparatuses. This private key is a private key issued to each device by a certificate authority (CA). A public key certificate is digitally signed by the CA with a digital signature on the public key corresponding to the private key. It is a certificate. The root key certificate is a digital certificate obtained by attaching a digital signature to a root key corresponding to the root private key used by the CA for the digital signature.

FIG. 20 shows these relationships.
As shown in FIG. 20A, 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. The CA encrypts the hash value obtained by hashing the public key A using the root private key to indicate that the key body or bibliographic information has not been tampered with, and uses it as a digital signature for the client public key. Attached. At this time, the identification information of the root private key used for the digital signature is added to the bibliographic information of the public key A as the signature key information. The public key certificate with the digital signature is public key certificate A.

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

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

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

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

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

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

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

By performing such processing, the communication device A and the communication device B can 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 not necessary, and the processing is as shown in FIG. In this way, the communication device B cannot authenticate the communication device A, but this processing is sufficient when the communication device A only needs to authenticate the communication device B. In this case, only the root key certificate may be stored in the communication device A, and the private key A and the public key certificate A are not necessary. Further, it is not necessary for the communication device B to store the root key certificate.

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

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

By the way, when authenticating the device itself, it is necessary to store a digital certificate in advance in the device, unlike authentication for specifying an operator such as a web browser. This is also the case at the time of manufacture of the device, and if a part having a memory for storing a certificate is replaced due to damage or failure, the certificate must be stored even after replacement. Don't be.
However, encryption and authentication technologies are progressing day by day, and higher-strength encryption and authentication technologies using the encryption have been proposed and put into practical use. Such a high-strength cipher is realized by increasing the key length or adopting a higher-strength cryptographic method in the case of the public key cipher described above. When methods with such strong encryption strength are put into practical use, it is conceivable to adopt those methods in consideration of the security level.

Therefore, it is conceivable that the public key certificate corresponding to the encryption method is different depending on the communication system to which the communication device is connected, and it is not known in which communication system or communication device the device or component is used. In this state, there is a problem that it is difficult to store a public key certificate issued by an appropriate organization in advance.
In addition, even if it is clear what kind of certificate should be stored, the operator of the communication apparatus may change the authentication processing method.
In order to solve such a problem, it is conceivable to store the certificate individually in each apparatus after the user and the usage are specified. In addition, for parts having a memory for storing a certificate, it is conceivable to take measures such that the certificate is stored after the part is replaced.

FIG. 22 shows a method conventionally used for performing such individual writing to the nonvolatile storage device.
One conventionally used method is to provide a storage device write terminal 305 on a substrate pattern connected to the nonvolatile storage device 301 provided in the communication apparatus 300 as shown in FIG. This is a method in which a dedicated connector 312 which is a dedicated jig for writing is connected to perform writing from the writing device 313.
However, this method requires a dedicated jig for writing, and due to problems with the management of the jig, parts stored by OEM (Original Equipment Manufacturer) manufacturers and certificates stored after the equipment is distributed to the market There is a problem that it is difficult to enable writing necessary for repair in the case of damage.

  In addition, since the connection I / F (storage device write terminal 305) of the dedicated jig that is not used during normal operation is normally located inside the apparatus after the apparatus is completed, the dedicated connector 312 is connected here. However, there is a problem that work efficiency such as once removing the substrate is required and work efficiency is poor. There is also a risk that the device may be damaged by this work. Although it is conceivable to provide the connection I / F of the dedicated jig outside the apparatus, in this way, an I / F unnecessary for normal operation is additionally provided, leading to an increase in cost.

On the other hand, for information writing, as shown in FIG. 22B, a memory card 311 such as a PCMCIA (Personal Computer Memory Card International Association) card is used as a replaceable storage device, and this storage device is used in the communication apparatus 300. A method is also used in which a card slot 303 is provided as an interface (I / F) to be connected, and the contents of the memory card 311 connected to the card slot 303 are read by the CPU 302 and written to the nonvolatile storage device 301.
With such a method, if a memory card 311 storing an appropriate certificate is prepared, writing can be performed anywhere including OEM manufacturers and markets. However, since the memory card is a widespread general medium, it is difficult to manage security, and it is difficult to confirm the validity of the memory card 311 and to prevent the memory card 311 from being passed to an unauthorized third party. In addition, there is a problem that it is difficult to prevent a third party from illegally acquiring data from the memory card 311.

Furthermore, in order to prevent impersonation of the device, for digital certificates, it is necessary to prevent exchange, reading, and registration by malicious users, and it is necessary to prohibit updates of digital certificates by general users. It is also difficult to confirm authority when setting a certificate using the memory card 311.
An object of the present invention is to solve such a problem and to easily and safely set such a certificate when setting a digital certificate corresponding to a user's use in a communication apparatus. To do.

  To achieve the above object, the certificate setting method of the present invention is a certificate setting method in which a digital certificate used for authentication processing is stored in a communication device using the certificate setting device. A component storing a second certificate, which is a digital certificate corresponding to an authentication process whose encryption strength is weaker than that of the first certificate, which is a digital certificate to be set by the above, is attached to the main body of the communication apparatus. When the first procedure, the certificate setting device, and the communication device perform authentication processing using the second certificate and the processing is successful, the certificate setting device sends the communication device to the communication device. The second procedure for storing the first certificate is executed in this order.

In such a certificate setting method, after the first procedure, an inspection procedure for inspecting the quality of the communication device is executed, and the second procedure is executed for a device that has passed the inspection. Good.
Further, in the second procedure, the first certificate may be stored from an interface exposed to the outside of the communication device main body.
Furthermore, the interface may be a connector for connecting an Ethernet standard communication cable.
Furthermore, the authentication process may be an authentication process according to an SSL or TLS protocol.

  According to the certificate setting method of the present invention as described above, such a certificate can be set easily and safely when a digital certificate with a short validity period is set in the communication device. .

The best mode for carrying out the present invention will be described below with reference to the drawings.
First, a configuration example of a communication system configured by using a lower-level device that is a communication device to which the certificate setting method of the present invention is applied and a higher-level device that is also a communication device and is a communication partner of the lower-level device will be described. .
FIG. 1 is a block diagram showing the configuration of the communication system.
As shown in FIG. 1, this communication system is configured by connecting a higher-level device 10 and a lower-level device 20, which are communication devices each having communication means, via a network 30.
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 to control the apparatus, thereby realizing functions as various means such as communication means and certificate setting means. ing. For the communication I / F 25, for example, an interface including a connector for connecting an Ethernet (registered trademark) communication cable is provided so that the lower level device 20 can be connected to a LAN (local area network). Just do it.
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, as a part related to the feature of this embodiment in the communication system, a functional configuration of a part related to the certificate setting of the upper apparatus 10 and the lower apparatus 20 is shown in FIG. These functions related to the host device 10 are realized by the CPU 11 of the host device 10 executing a necessary control program stored in the ROM 12 or the HDD 14, and these functions related to the host device 20 are This is realized by the CPU 21 of the lower-level device 20 executing a required control program stored in the ROM 22, the HDD 24, or the like.

As shown in FIG. 3, the host device 10 includes an HTTPS (Hypertext Transfer Protocol Security) client function unit 31, an HTTPS server function unit 32, an authentication processing unit 33, a certificate update request unit 34, and a certificate storage unit 35. ing.
The HTTPS client function unit 31 uses the HTTPS protocol including authentication and encryption processing according to SSL to request communication with a device having the function of an HTTPS server such as the lower level device 20 and to the communication partner. It has a function of transmitting a request (command) or data and executing an operation corresponding to the request.

On the other hand, the HTTPS server function unit 32 receives a communication request using the HTTPS protocol from a device having a function of an HTTPS client, receives a request or data from the device, and causes each unit of the device to execute an operation corresponding thereto, It has a function of returning the result as a response to the request source.
When the HTTPS client function unit 31 or the HTTPS server function unit 32 authenticates a communication partner, the authentication processing unit 33 receives a digital certificate received from the communication partner, various certificates stored in the certificate storage unit 35, It has a function of an authentication means for performing authentication processing using a private key or the like. In addition, it has a function of transmitting a digital certificate stored in the certificate storage unit 35 to the communication partner via the HTTPS client function unit 31 and the HTTPS server function unit 32 in order to request authentication from the communication partner.

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

On the other hand, the lower level device 20 includes an HTTPS client function unit 41, an HTTPS server function unit 42, an authentication processing unit 43, a request management unit 44, a certificate storage unit 45, a status notification unit 46, a log notification unit 47, a certificate setting unit. 48 and a command receiving unit 49.
Similar to the HTTPS client function unit 31 of the higher level device 10, the HTTPS client function unit 41 uses the HTTPS protocol to request communication with a device having the function of an HTTPS server, such as the higher level device 10, It has a function to execute an operation according to data or the like.

The HTTPS server function unit 42 is also the same as the HTTPS server function unit 32 of the upper level device 10, accepts a communication request from a device having the function of an HTTPS client, and executes an operation corresponding to the received request or data in each unit of the device. And has a function of returning a response to the request source.
The function of the authentication processing unit 43 is the same as that of the authentication processing unit 33 of the upper level device 10, but the certificate used for the authentication processing is stored in the certificate storage unit 45.
The request management unit 44 has a function of determining whether or not an operation based on a request received from the higher-level device 10 can be executed. When the execution is permitted, the function unit 46-49 has a function of transmitting an operation request to the function units 46 to 49 that execute an operation based on the request.

  FIG. 4 shows criteria for determining whether or not execution is possible. The criteria are the type of request and the type of digital certificate used in the authentication process in the authentication processing unit 43. The digital certificate stored in the higher level device 10 and the lower level device 20 will be described in detail later, but a normal public key certificate that is a first certificate corresponding to authentication processing with higher cryptographic strength, and cryptographic strength. In the case where there is a rescue public key certificate that is a second certificate corresponding to a lower authentication process, the request management unit 44 performs an authentication process using a normal public key certificate as shown in FIG. Although all operations are permitted, only authentication setting operations are permitted when authentication processing using a rescue public key certificate is performed. Therefore, the rescue public key certificate is a certificate used only when a new normal public key certificate is stored in the lower level device 20.

The certificate storage unit 45 stores authentication information such as various certificates and private keys in the same manner as the certificate storage unit 35 of the higher-level device 10, and functions as a certificate storage unit used for authentication processing in the authentication processing unit 43. Have. However, the stored certificate and the like are different from the certificate storage unit 35 as described later.
The state notification unit 46 has a function of making a call for notifying the upper device 10 of the state of the lower device 20 when an abnormality is detected or an instruction is given by the user. This notification may be transmitted as a response to the inquiry from the higher-level device 10 or may be transmitted by requesting communication from the HTTPS client function unit 41 to the higher-level device 10.

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

Next, a communication method between the higher-level device 10 and the lower-level device 20 in this communication system will be described. FIG. 5 is an explanatory diagram showing an outline of the communication method.
In this communication system, when the host device 10 intends to communicate with the 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. 19 or FIG. To establish. This authentication process is called an SSL handshake. However, the mutual authentication as shown in FIG. 19 is not essential, and the one-way authentication as shown in FIG. 21 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.

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

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. Conversely, there is a case where the lower level device 20 requests communication to the higher level device 10 and functions as a client / server system in which the lower level device 20 is a client and the higher level device 10 is a server.
In order to realize RPC, in addition to the above-described technology, known protocols (communication standards) such as FTP (File Transfer Protocol), COM (Component Object Model), CORBA (Common Object Request Broker Architecture), technology, 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. 6A shows the types of certificates and keys stored as authentication information by the lower level device 20 in FIG. 6A, and FIG. 6B shows the types of certificates and keys stored as authentication information by the higher level device 10 in FIG. FIG.
As shown in FIG. 6, the upper level device 10 and the lower level device 20 shown in FIG. 1 roughly store normal authentication information and rescue authentication information. Each of these pieces of authentication information includes a public key certificate and a private key that are authentication information relating to itself, and a root key certificate that is authentication information relating to a communication partner.

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

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

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.
Also, in order to enable each device to confirm the validity of public key certificates issued by a plurality of certificate authorities, it may be possible to store a root key certificate corresponding to each certificate authority. .

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

  By the way, these public key certificates and private keys are stored in a rewritable nonvolatile storage means such as a flash memory constituting the ROM 22 or the RAM 23. Accordingly, when a part including such storage means is replaced due to damage or the like, the stored public key certificate or private key is removed together with the removed old part. In such a case, in order to enable authentication using the normal public key certificate again (authentication using the normal certificate set), it is necessary to store the removed certificate and key again.

  Here, if each device can only perform authentication using a normal public key certificate, a new normal public key certificate or the like can be safely passed through the network 30 in a state where this authentication cannot be performed. There will be no way to send to. However, each device constituting this communication system stores rescue authentication information in order to cope with such a situation, and by using this, the communication partner can be authenticated 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 necessary apparatus via the network 30.

  The rescue authentication information has substantially the same configuration as the normal authentication information. For example, the rescue public key certificate for the lower level device is a digital certificate in which the rescue public key issued by the CA to the lower level device is attached with a digital signature that can be verified using the higher level device authentication rescue root key. Yes, corresponding to the second certificate. The higher-level device rescue private key is a private key corresponding to the rescue public key, and the lower-level device authentication rescue root key certificate is a digital signature that can be used to confirm the validity of the lower-level device authentication rescue root key. This is a digital certificate with The rescue public key certificate, the rescue private key, and the rescue root key certificate are collectively called a rescue certificate set. The same applies to the rescue authentication information stored on the host device 10 side.

Here, FIG. 9 shows an example of a normal public key certificate, and FIG. 10 shows an example of a rescue public key certificate.
These are public key certificates that are set in the same device and used for authentication processing. However, in the normal public key certificate, the key length of the public key is 2048 bits as indicated by the symbol I, whereas in the rescue public key certificate, the key length of the public key is 1024 bits as indicated by the symbol N. .

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

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

  If the rescue authentication information is stored in advance at the time of manufacturing a part having a certificate storage area, if the host device 10 supports authentication using the rescue public key certificate, the communication partner Can be authenticated. If such authentication is successful, the common key is shared with the communication partner as described above, and a secure communication path using common key encryption can be provided. Accordingly, it is possible to transmit and set a new normal public key certificate (including normal authentication information) using this communication path.

Note that a user configuring a communication system using the lower level device 20 does not necessarily correspond to the higher level device 10 for authentication using the rescue public key certificate. However, by supporting authentication using a rescue public key certificate, it becomes possible to use a function that allows a new normal public key certificate to be set safely and remotely on the replaced part as described above. The user also has the advantage of making the rescue public key certificate available.
Therefore, even when the host device 10 does not support authentication using the rescue public key certificate at first and the rescue authentication information cannot be used, the rescue authentication information is provided to all replacement parts having the certificate storage area. It is also conceivable to store the information so that the host device 10 can correspond to authentication using a rescue public key certificate afterwards. Even in such a case, the normal authentication information can be set in the secure communication path established by performing the authentication using the rescue public key certificate to the lower device 20 whose parts have been replaced after the correspondence of the higher device 10. it can.

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

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

A public key certificate issued by a public certificate authority is strictly managed, and its safety and reliability are generally accepted. Good. However, since public key certificates issued by public certificate authorities require strict management and security, certificates that can be used in various environments, such as rescue public key certificates, must be issued. Can be difficult and expensive.
On the other hand, since private certificate authorities can specify the specifications of certificates relatively freely, they can be used in various environments by reducing encryption strength and avoiding the latest and less popular authentication processing algorithms. It is also possible to issue a certificate that can be used for Also, 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. Therefore, a certificate issued by a private certificate authority is adopted as the rescue public key certificate.
The rescue public key certificate issued by the private certificate authority may be inferior in safety and reliability when compared to the normal public key certificate issued by the public certificate authority. If the function permitted when the authentication process is performed using the rescue authentication information is limited, this point is not a big problem.

Returning to the description of FIG. 9 and FIG. 10, 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 G. While it is one year from midnight on January 1, 2004, in the rescue public key certificate, as indicated by the symbol L, from midnight on January 1, 2000 to midnight on January 1, 2050 For 50 years.
In other words, if a public certificate authority issues a normal public key certificate, the manufacturer or user of the device cannot set the validity period freely, and the validity period is set short for safety reasons. It is normal. On the other hand, if the rescue authentication information is issued by the private certificate authority, the manufacturer of the apparatus can freely determine the validity period. Therefore, the validity period is set longer than the normal public key certificate in this way.
In this way, since the effective period is long, a situation in which it becomes unusable due to expiration of the effective period is unlikely to occur. Therefore, even if the rescue authentication information is stored in advance when manufacturing a part with a certificate storage area, the part is stocked for a long period of time and can be quickly dealt with when replacement is necessary. can do.

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

It is even better if an effective period that is much longer than the product life and the operation period of the apparatus is determined. In the example shown in FIG. 10, the validity period is set to 50 years, and this level is considered sufficient for a normal device. Since the maximum valid period that can be set according to the 509 format is 50 years, it is a matter of course that a longer period, for example, 100 years or hundreds of years may be set only by doing this. When the validity period is set in this way, the end of the validity period is simply described by a request in the format of the public key certificate, and the validity period of the rescue public key certificate is considered to be virtually unlimited. it can. In addition, depending on the target device, even when it is valid for about 20 years, 30 years or less, it may be considered in the same way.
Furthermore, even if the validity period of the rescue public key certificate is shorter than the lifetime of the product, if it is longer than the validity period of the normal public key certificate, the device or component is more than the case where the normal public key certificate is stored. It is possible to obtain an effect that the stockable period of the product can be extended.
Normally, the operator of the certificate authority that issues the public key certificate determines an appropriate period in consideration of security, but as mentioned above, this period is shorter than the product lifetime, Often, the period of validity expires during operation of the device.

Also, here, the device identification information is not described in the bibliographic information of the rescue public key certificate, and the devices of the same rank (in the example shown in FIG. 1 or FIG. The same rescue public key certificate can be stored in all of them. 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 20 are provided, the same rescue authentication information is stored in all the lower devices 20.
The same applies to the rescue authentication information of the host device 10.
In order to unify the data format with the normal public key certificate, in the example shown in FIG. 10, 0 is entered as the machine number of the issue destination device to indicate that it is a rescue public key certificate. . It is also possible to indicate this by leaving the “Subject” item blank.

  Although it is not essential to do so, if the rescue authentication information can be made common to all devices of the same rank in this way, the component is mounted when the component having the certificate storage area is manufactured. What corresponds to the rank determined according to the model of the apparatus can be stored uniformly. And if such rescue authentication information is memorized, and it is a part that does not normally memorize authentication information, since it does not require device identification information at the time of manufacture, it can be used in common regardless of device identification information. Can be produced as a part.

If the rescue public key certificate is not attached with device identification information, the communication partner device cannot be specifically identified even if authentication is performed using the rescue public key certificate. . However, some information about the communication partner can be obtained.
That is, for example, a certain vendor stores a rescue certificate set for a lower-level device in all devices corresponding to the lower-level device 20 among its products, and rescues for a higher-level device in all devices corresponding to the higher-level device 10 that is the communication partner. If the certificate set is stored, if the authentication is successful, the lower-level device 20 has transmitted a public key certificate that can be confirmed by the higher-level device authentication rescue root key certificate stored in itself. Recognize that the other party is the higher level device 10 of the same vendor, and the higher level device 10 also sends a public key certificate that can be confirmed by the rescue root key certificate for lower device authentication stored in itself. It can be recognized that the other party is the lower-level device 20 of the same vendor.

Accordingly, it is possible to make a certain degree of determination as to whether or not the identification information can be referred to whether or not the apparatus that has requested communication or the apparatus that has requested communication is an appropriate apparatus as a communication partner.
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.

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 properly according to the situation. Therefore, the configuration for proper use will be described with reference to FIG.
In the SSL protocol, the server cannot know the state of the client when a communication request is made from the client. Therefore, the server always has the same public key whenever a specific URL (Uniform Resource Locator) is accessed. You will provide a certificate. Therefore, basically, it is not possible to adopt a configuration in which there are a plurality of normal public key certificates and an appropriate one selected according to the type of the normal root key certificate of the communication partner is transmitted. However, when the address for receiving a communication request is different, a different public key certificate can be returned for each address. This address can be determined by a URL, for example.

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

In this case, the communication request side (the side functioning as a server) distinguishes the certificate to be returned according to the URL that received the communication request, and provides the normal public key certificate when it is received with the normal URL. When the rescue URL is accepted, a rescue public key certificate can be provided.
Since the client requesting communication knows to which URL the communication request has been sent, when performing mutual authentication, an appropriate public key certificate corresponding to the URL can be selected and transmitted. .

  Therefore, in this communication system, even when authentication is performed using a normal public key certificate between the upper level device 10 and the lower level device 20 and this is removed by exchanging parts, After a correct part is mounted, authentication using a rescue public key certificate stored in the part can be performed to secure a safe communication path. This is because even with authentication using a rescue public key certificate, a common key can be shared in the same way as with a normal public key certificate. Then, by sending and storing normal authentication information for setting from the upper level device 10 to the lower level device 20 using this communication path, it is possible to return to a state where authentication using the normal authentication information can be performed again.

In addition, even with authentication using a rescue public key certificate, the partner device can be specified to some extent as described above. For example, a normal public key certificate is transmitted only to a device manufactured by the company. It is possible to prevent the transmission of a normal public key certificate to an unauthorized device and store it.
As described above, in this communication system, the rescue authentication information is used in addition to the normal authentication information, so that even when it is necessary to replace a part storing a certificate necessary for authentication, it is easy and quick. It can be easily restored to a state where normal authentication can be performed. Therefore, even a device that is difficult to manually update a certificate and must rely on automatic updating can effectively use a certificate corresponding to an authentication process with high encryption strength.

The authentication information shown in FIG. 6 needs to be stored entirely when the upper device 10 and the lower device 20 perform mutual authentication. However, the lower device 20 functions as a server, and the upper device 10 However, when only one-way authentication for authenticating the lower level device 20 is performed, it is not necessary to store some certificates. For both the normal authentication information and the rescue authentication information, the lower apparatus 20 does not require the upper apparatus authentication root key certificate, and the upper apparatus 10 has the upper apparatus public key certificate and the upper apparatus private key. Is no longer necessary.
Further, in the lower level device 20, the storage area for storing the above-described normal certificate set and rescue certificate set may be provided on a common component. As this component, for example, a memory card or memory unit including a flash memory or NVRAM that constitutes the ROM 22 or RAM 23, or a CPU board equipped with a nonvolatile memory that can be rewritten together with the CPU 21 can be considered. The same applies to the host device 10.

Next, the manufacturing process of the component provided with such a certificate set storage area and the subordinate apparatus 20 mounted with the component will be described. In this manufacturing process, a normal certificate set is set in the lower level device 20 according to the embodiment of the certificate setting method of the present invention.
First, an outline of these manufacturing steps is shown in FIG. In this figure, the part relating to the setting of the certificate set is mainly shown, and the other parts are shown greatly simplified.

As shown in this figure, when manufacturing the subordinate device 20, the part A having the certificate set storage area is first manufactured in the part manufacturing process. In this process, the part A is assembled and inspected. The inspection content here may be to inspect whether or not each chip provided on the board can be accessed from the CPU when the component A is a CPU board.
Thereafter, the software copy device 130 in the factory writes the rescue certificate set for the lower level device 20 together with the software used for controlling the lower level device 20 to be stored in the part A. At this time, it is not possible to provide a secure communication path via the network between the software copying apparatus 130 and the component A, and the effect of the leakage certificate set is greater than that of the normal certificate set. The writing may be performed directly using a dedicated jig.
When the part A is completed as described above and is distributed as a part, it is packaged and shipped.
Here, when the identification information of the device is not described in the rescue public key certificate, the rescue certificate set to be written is determined according to the model and rank of the device on which the component A is mounted. 130 may be stored. Further, when the component A is a standardized memory card or the like, it may not be necessary to assemble it.

  On the other hand, when the part A is used for manufacturing the subordinate apparatus 20, the rescue certificate set is written, the stored part A is sent to the product assembling process, and the main body of the subordinate apparatus 20 that is being assembled. Attach to the part. In this embodiment, this procedure corresponds to the first procedure. Then, after the assembly of the subordinate device 20 is completed, the function is inspected to inspect the quality. As an inspection content here, it can be considered to inspect whether or not a device on the CPU board can access a device outside the board, for example, the communication I / F 25. In this embodiment, this procedure corresponds to the inspection procedure.

And a machine number is provided to the apparatus which passed the inspection. Thereafter, the device number information and initial setting values of the device are stored in the lower device 20. When it is known what normal certificate set should be stored, the certificate writing device 160 stores the normal certificate set in the lower level device 20. In this embodiment, this procedure corresponds to the second procedure. Then, the appearance is inspected, packed and shipped.
The subordinate device 20 can be manufactured through the above steps. Further, although the rescue certificate set to be stored is different, the host device 10 can also be manufactured in the same process. The component manufacturing process and the product assembly process are often performed in separate factories.

FIG. 13 is an explanatory diagram of a process for storing each certificate set in the component A.
As shown in this figure, in the part A, only the rescue certificate set is stored in the part manufacturing process, and the normal certificate set is not stored. In this state, the product is completed as a part that can be used for both the part used for assembling a new apparatus in the product assembly process and the replacement part (service part) for the apparatus already sold in the market.
And when manufacturing a device in response to an order from a user in a factory, the user who uses the device and the communication system to which the device is connected are known at the stage where the device number is given. In some cases. In such a case, a normal certificate set suitable for the use environment can be set at the stage of device manufacture.

Therefore, in such a case, when the part A is mounted on the device in the product assembly process at the device assembly factory, the certificate is set after the device passes the inspection and the device number is assigned. The normal certificate set is written and set by the certificate writing device 160 which is a device.
At this time, the device number of the device to be written is input from the device number information input device 161 to the certificate writing device 160, and the certificate writing device 160 acquires a normal certificate set including the information of the device number as identification information. Will write. This normal certificate set is issued by the certificate management device 50. The certificate management device 50 is a CA that issues a certificate corresponding to the authentication process performed by the host device 10 during normal communication in the communication system to which the target lower device 20 is to be connected.

  When using a public key certificate issued by a public CA, the certificate writing device 160 requests the public CA to issue a certificate directly, and leaves the management of the certificate to the CA. The certificate writing device 160 has a function for managing issued certificates, or the certificate writing device 160 requests the CA to issue a certificate via a device that manages the issued certificates. Such a configuration is preferable. In particular, since it is possible to obtain certificates from a plurality of CAs in a factory, it can be said that such a configuration is preferable even when the CA is not a public CA.

  When the certificate writing device 160 sets a normal certificate set in the lower device 20, the certificate writing device 160 and the lower device 20 are connected to each other, and then the rescue URL of the lower device 20 from the certificate writing device 160 is connected. Communication is requested, and SSL processing is performed using the rescue certificate set stored in the lower level device 20. When the certificate writing device 160 authenticates that the lower-level device 20 is a valid device, the normal certificate set is transmitted together with the certificate setting request so as to be written in the normal certificate set storage area of the part A. Yes. That is, the certificate writing device 160 and the lower device 20 perform communication using the rescue public key certificate, and the certificate writing device 160 stores the normal certificate set in the lower device 20 through the communication.

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

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

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

If it is a certificate setting request in step S205, the process proceeds to step S206, and the certificate set received together with the certificate setting request (obtained from the communication partner) is stored in the normal certificate set storage area of the part A, and FIG. Set the contents of the normal certificate set shown in In this process, the CPU 21 of the lower level device 20 functions as a certificate setting unit.
Thereafter, in step S207, the setting result is notified to the transmission source as a response, and the process is terminated.
Since the lower level device 20 executes such processing, the certificate writing device 160 can perform at least a minimum confirmation that the lower level device 20 is the target of writing the normal certificate set. It is possible to prevent a situation in which the normal certificate set is erroneously transmitted to the apparatus, and improve the security of the certificate setting.

Also, the rescue certificate set may be stored on the certificate writing device 160 side, and mutual authentication may be performed with the lower level device 20 in the authentication process. The rescue certificate set used in this case is the same as that stored in the higher-level device 10, and the authentication processing on the lower-level device 20 side also corresponds to the processing shown in FIG. In this way, it is possible to prevent the lower device 20 from setting a normal certificate set sent from an unauthorized certificate writing device.
Note that this effect can be obtained even if the certificate writing device 160 simply sends a rescue public key certificate to the lower level device 20 and is authenticated, and the certificate writing device 160 can obtain the effect between the certificate writing device 160 and the lower level device 20. It is also possible to establish a secure communication path using SSL.

It is also conceivable to make a communication request to the certificate writing device 160 from the lower device 20 side. Even in this case, the certificate writing device 160 and the lower-level device 20 perform authentication processing using the rescue public key certificate, and if this is successful, the certificate writing device 160 transmits the normal public key certificate to the lower-level device 20. This setting is the same as in the above-described processing.
In addition, when sending a normal certificate set, if necessary, send the software necessary for authentication processing using the public key certificate and private key included in the normal certificate set. The apparatus 20 may be set.

On the other hand, in FIG. 13, when the part A is shipped as a service part and mounted on the lower level device 20 (market machine) that is operating at the installation destination, it is usually proved by the higher level device 10 corresponding to the lower level device 20. A set of documents will be written. At this time, the device number of the device to be written is input from the device number information input device 171 to the host device 10, and the host device 10 stores a normal certificate set including the information of the device number as identification information in the certificate management device 50. This is issued, acquired, and set in the lower level device 20. The identification information such as the machine number of the lower level device 20 may be transmitted from the lower level device 20 to the higher level device 10 in response to a request from the higher level device 10.
The certificate management device 50 is a CA that issues a certificate corresponding to an authentication process performed by the host device 10 during normal communication. A configuration in which a function for managing issued certificates is provided in the host device 10 or the host device 10 requests the CA to issue a certificate via a device that manages certificates issued therebetween. What is preferable is the same as in the case of the certificate writing device 160 described above.

  When the higher level device 10 sets a normal certificate set in the lower level device 20, the higher level device 10 requests communication to the rescue URL of the lower level device 20, and sets the rescue certificate set stored in the lower level device 20. The authentication process using SSL is performed. When the higher level device 10 authenticates that the lower level device 20 is a valid device, a normal certificate set is transmitted and set in the normal certificate set storage area of the component A. In this case, the higher-level device 10 functions as a certificate setting device, performs authentication processing using the rescue public key certificate with the lower-level device 20, and if the authentication processing is successful, the lower-level device 20 Usually, the certificate set is stored.

In this case, the processing performed on the lower level device 20 side is the same as that shown in the flowchart of FIG. Of course, mutual authentication may be performed. The effect of this is the same as the case of writing by the certificate writing device 160, but the safety after shipping that does not know what device is connected is improved compared to the factory where the connection target is limited. The demand is strong. Note that one-way authentication in which the upper device 10 authenticates to the lower device 20 may be employed. Further, the lower device 20 may make a communication request to the higher device 10 as in the case of writing by the certificate writing device 160 described above.
As described above, when the normal certificate set is set in the market machine, the step of mounting the part A on the lower level device 20 is the first procedure, and the step of storing the normal certificate set in the lower level device 20 is the second step. Applicable to the procedure. Further, when the normal certificate set of the lower level device 20 cannot be set at the factory, only the rescue certificate set is stored in the part A and shipped, and the second procedure is executed at the installation site as described above. The normal certificate set can be stored.

As is clear from the above description, according to the method described here, the lower-level device 20 stores the normal certificate set in the same procedure at the time of production at the factory and at the time of parts replacement in the market. be able to.
Further, authentication is performed using a rescue certificate set stored in advance in the component, and if this is successful, the normal certificate set is stored, so communication via the communication I / F 25 which is a normal network I / F. Even if is used, the normal certificate set can be safely set in the subordinate apparatus 20. Accordingly, it is not necessary to provide a special I / F for certificate setting in the lower level device 20, and the cost can be reduced.
And by making the rescue public key certificate compatible with authentication processing with low encryption strength, it is possible to issue a certificate that can be used in common regardless of the usage environment of the device at the installation site, export restrictions, etc. This makes it possible to manage the manufacturing process and inventory easily because there is no need to make separate devices and parts according to the environment and region in which it is used, and costs can be reduced in this respect as well.

  Also, if the validity period of the rescue public key certificate is at least longer than the validity period of the normal public key certificate, as described above, parts and devices can be stocked more than when the normal public key certificate is stored. The effect that the period can be extended can be obtained. Further, as shown in FIG. 13, after the normal certificate set is stored in the product assembly process, the normal public key certificate has expired before being shipped or installed in the user environment. Even in such a case, as long as the rescue public key certificate is within the valid period, a new normal certificate set can be safely set again by the same procedure as in the case of parts replacement of a market machine. Therefore, even when a normal certificate set is set in the manufacturing process, the stockable period of the completed device can be extended.

Further, since the network I / F is an I / F that is used even during normal operation of the lower level device 20, it is usually provided in a state of being exposed to the outside of the device main body. Therefore, by using such an I / F, it is possible to facilitate work related to certificate setting at the time of manufacturing the device. And since special jigs and I / F are not used for setting the public key certificate, it is easy to set the same as when manufacturing at the vendor's own factory even after distribution to the OEM manufacturer or the market. Can do.
On the other hand, when the rescue certificate set is stored in the part, it can be directly performed using a dedicated jig, and thus safety can be ensured without performing authentication or the like. Since it is easy to provide the I / F of the dedicated jig at a position where connection is easy at the part stage, there is no problem even if the dedicated jig is used.

  Even when the lower device 20 stores the normal public key certificate with the device number information added as device identification information (as part of the normal certificate set), the device number is In order to prevent the occurrence of missing numbers, it is common to attach to a device that has been assembled and passed a quality inspection. Therefore, if the public key certificate including the machine number information is stored in the manufacturing process of the apparatus, it is necessary to perform the assembly in a state where all the assembly is completed. In such a case, the effect of storing via an interface (for example, PHY which is a network I / F) normally used in the lower level device 20 is particularly great. This is because it is difficult to provide a special interface connection port so that it can be easily operated and configured in a state where the assembly of the apparatus is completed due to restrictions on design, function, and cost.

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

Further, since the use and function are different between the normal public key certificate and the rescue public key certificate, it is preferable that these certificates are issued by different CAs as shown in FIG.
That is, since the same rescue public key certificate is stored in all the devices of the same rank, if the rescue root private key is leaked, it becomes extremely difficult to maintain security, so it is necessary to maintain confidentiality particularly strictly. On the other hand, it is not necessary to normally create and store different certificates for each device. Therefore, it is preferable to use a CA that places importance on safety and is inaccessible from the outside. If it is a private CA, it is easy to prepare a CA that satisfies such conditions.

On the other hand, since the normal public key certificate can be updated as necessary, even if the normal root private key is leaked, the security can be maintained by updating it. And since it is necessary to create and memorize | store a certificate separately for every apparatus, it is good to use CA connected to open networks, such as the internet.
Further, the CA is further subdivided so that the CA is divided according to the rank of the device to which the certificate is issued, such as the CA that issues the certificate for the lower device and the CA that issues the certificate for the higher device. Also good.
It is also possible to use digital certificates of completely different formats for the normal certificate set and the rescue certificate set.

Next, equipment used for setting the normal certificate set in the lower level apparatus 20 in the above-described product assembly process will be described. FIG. 15 is a block diagram showing the schematic configuration.
As shown in this figure, a production management system 140, a communication terminal 150, and a certificate writing device 160 are installed as equipment for setting a normal certificate set in a production factory E that performs a product assembly process.
The production management system 140 manages the daily production quantity of devices such as the upper device 10 and the lower device 20.

The communication terminal 150 includes a certificate database (DB) 154a, an input device 156, and a display device 157. Then, from the production management system 140, information on the number of productions by model for that day and information on the number to be assigned (here, information including the model code and serial number) is acquired. Also, based on the information, the certificate management device 50, which is the CA that issues the normal public key certificate scheduled to be used by the device with the device number, is issued a normal certificate set to be stored in the device scheduled to be produced. This is obtained and stored in the certificate DB 154a. Note that the CA that issues the normal public key certificate may differ from machine number to machine number, and the factory must set the normal certificate set because the CA cannot be specified or the factory cannot communicate with an appropriate CA. It is also conceivable to store information not to be performed.
The certificate writing device 160 includes a machine number information input device 161, and accepts an input of the machine number of the device being produced from the machine number information input device 161 when the device is produced. When this is input, a normal certificate set corresponding to the machine number is obtained from the communication terminal 150, transmitted to the corresponding device, and stored in the non-volatile memory of the device. Let the region set. When the subordinate device 20 is produced, the storage area provided for the part A is set.

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

Each certificate writing device 160 has a device number information input I / F 162 (162a, 162b) for connecting to the device number information input device 161 (161a, 161b), and a device to be produced (the host device 10). And a writing I / F 165 (165a, 165b) for connection to the lower device 20).
In such a production line, for example, when producing the low-order apparatus 20, when assigning an identification number to the apparatus that has passed the quality inspection, a rating nameplate is affixed. An example of this rating nameplate is shown in FIG. 17, and the device name of the apparatus is described on the rating nameplate together with information such as rated voltage and power consumption. Further, a bar code BC indicating the information of the machine number is also described.

In the normal certificate set setting process, first, the certificate writing device 160 is connected to the setting target lower-level device 20 using an Ethernet standard cross cable as the writing I / F 165. The reason why the cross cable is used is that each device to be produced has the same IP address as an initial value, and when the LAN is connected to the certificate writing device 160, the IP address is duplicated.
Subsequently, a bar code reader is used as the machine number information input device 161, the bar code BC on the rated nameplate is read, and the machine number information of the device to be worked is input to the certificate writing device 160. Then, the certificate writing device 160 obtains a normal certificate set corresponding to the machine number from the communication terminal 150 and transmits it to the lower level device 20 connected via the writing I / F 165 to be provided in the component A of the device. The normal certificate set storage area is set. When information indicating that no certificate is set is stored in the certificate DB 154a, the normal certificate set is not set.
Through the above operations and processing, each subordinate device 20 to be produced is stored with its machine number information as device identification information, and a normal public key certificate to be used by the device of that machine number is stored with a simple operation. Can be made.

In the embodiment described above, an example in which authentication according to SSL as described with reference to FIG. 19 or FIG. 21 is performed between each device including the upper device 10 and the lower device 20 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.

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

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

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

In the above-described embodiment, the example in which the identification information of the device is described in the normal public key certificate has been described, but the identification information of the device is not included in the normal public key certificate. All of the same normal public key certificates may be stored. Even if you do this, you can share a common key with a communication partner and provide a secure communication path using common key cryptography, and then identify the communication partner by exchanging machine number information etc. This is the same as in the case of the rescue public key certificate. And even if it does in this way, it is thought that safety | security is high because the encryption strength of the corresponding | compatible authentication process is high. Also, if a public key certificate issued by a public CA is used, or if the validity period is made shorter than that of the rescue public key certificate, the security can be improved more than 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 encryption strength of the corresponding authentication process is also regarded as one element of security level, and the normal public key certificate and the rescue disclosure are made depending on the validity period, presence / absence of device identification information, type of CA issuing the certificate, etc. It is also possible to make a difference between key certificates.

In the above-described embodiment, the example in which the certificate management device 50 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, a ROM, and a RAM for realizing the function of the certificate management device 50 may be provided independently. The certificate management apparatus 50 may be caused to function by executing appropriate software.
In such a case, for communication between the certificate management device 50 and the higher-level device 10 integrated therewith, a process for causing the hardware to function as the certificate management device 50, and hardware It is assumed that inter-process communication with a process for causing the host apparatus 10 to function is included.

  Furthermore, in the above-described embodiment, an example in which the certificate management device 50 creates a root key or a digital certificate by itself has been described. However, the certificate management device 50 specializes in managing keys and certificates, and other devices. You may make it acquire these by receiving supply of a root key and a digital certificate from.

  Further, in the above-described embodiment, the communication system is configured by only the upper device 10 and the lower device 20, but the present invention can also be applied to a configuration including other devices. For example, an intermediary device that mediates communication between the higher-level device 10 and the lower-level device 20 may be provided, and the higher-level device 10 and the lower-level device 20 may exchange requests and responses via the mediation device. Alternatively, a device higher than the host device 10 may be provided. In this case, if the higher-level device 10 is regarded as a “lower-level device” and the higher-level device is regarded as a “high-level device”, these devices can be handled in the same manner as in the above-described embodiment.

Conventionally, an image processing apparatus such as a printer having a communication function, a facsimile (FAX) apparatus, a digital copying machine, a scanner apparatus, a digital multi-function apparatus or the like is a managed apparatus, and a management apparatus capable of communicating with these managed apparatuses. Has proposed a remote management system for remotely managing these managed devices.
For example, an image processing apparatus provided with an image forming unit generally forms an image on plain paper using a photoreceptor electrostatic process. From a mechanism that performs such a photoreceptor electrostatic process, The rate of occurrence of trouble (abnormality) is high, and a maintenance management service system is adopted because of the necessity of periodic overhaul to maintain performance.
For the purpose of enhancing this maintenance management, as a remote management system in which the image forming apparatus is a managed apparatus, a communication device is provided inside or outside the image forming apparatus and installed in the image forming apparatus and a service center (management center). A management apparatus that has been connected to the management apparatus via a public line (telephone line) and that notifies the management apparatus when an abnormality occurs in the image forming apparatus has already been developed and operated.

The above-described embodiment can also be applied to the case where a digital certificate is set for a managed device in such a remote management system. In this case, the managed device is a lower-level device and manages the managed device. In addition, a device in a user environment that collects information on a plurality of managed devices may be a higher-level device.
When performing remote management, since there is often no operator of the management apparatus near the managed apparatus, it is necessary to specify the managed apparatus by communication. Then, a mechanism for guaranteeing that the managed device specified by communication is surely the device is required. Therefore, as described in the above embodiment, the normal public key certificate can be easily set at the time of manufacture and after installation in the user environment, and authentication using the normal public key certificate can be easily and reliably operated. The effect of making it possible is great.

  Remote management targets are not limited to image processing devices, such as network home appliances, vending machines, medical equipment, power supply devices, air conditioning systems, gas / water / electricity measuring systems, automobiles, aircraft, general-purpose computers, etc. A communication device in which various electronic devices have a communication function can be considered as a managed device. However, it goes without saying that the lower level device 20 is not limited to the managed device in the remote management system.

  As described above, according to the certificate setting method of the present invention, such a certificate can be set easily and securely when a digital certificate corresponding to the user's application is set in the communication device. Can be. Therefore, it is possible to easily manufacture a communication device using a digital certificate with device identification information and to operate the communication system with high reliability.

It is a block diagram which shows the structural example of the communication system containing the low-order apparatus which is a communication apparatus to which the certificate setting method of this invention is applied. It is a block diagram which shows the hardware constitutions of the high-order apparatus and low-order apparatus shown in FIG. It is a functional block diagram which shows the function structure of the part similarly related to the remote management of a high-order apparatus and a low-order apparatus, and the setting of a certificate. FIG. 4 is a diagram illustrating a criterion for determining whether or not to execute an operation in the request management unit illustrated in FIG. 3. It is explanatory drawing which shows the outline | summary of the communication system between the high-order apparatus and low-order apparatus in the communication system shown in FIG. It is a figure for demonstrating the authentication information which a high-order apparatus and a low-order apparatus shown in FIG. 1 memorize | store. It is a figure for demonstrating the example of a format of a normal public key certificate. It is a figure which shows the example of the general public key certificate produced according to the format described in FIG. Similarly, it is a figure which shows the example of a normal public key certificate for contrast with a rescue public key certificate. Similarly, it is a figure which shows the example of a rescue public key certificate for contrasting with a normal public key certificate.

FIG. 2 is a diagram for explaining a configuration for a higher-level device and a lower-level device shown in FIG. 1 to use a normal public key certificate and a rescue public key certificate properly. It is a figure which shows the outline of the manufacturing process of the component A which provides the memory | storage area | region of a certificate, and the low-order apparatus with which the component A was mounted | worn. It is a figure for demonstrating the process which memorize | stores each certificate set in the component A. FIG. It is a flowchart which shows the process performed by the low-order apparatus side when writing a normal certificate set in a low-order apparatus in the process shown in FIG. It is a figure which shows the outline of the equipment used in order to set a normal certificate set to a low-order apparatus in the product assembly process shown in FIG.12 and FIG.13. It is a figure which shows the outline of the condition of the periphery of the communication terminal and certificate writing apparatus which were shown in FIG. 15 in a production factory. It is a figure which shows the example of the rating nameplate stuck when giving an identification number to the apparatus which passed the function test | inspection. 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. It is a figure for demonstrating the relationship between the root key in the authentication process shown in FIG. 19, a root private key, and a public key certificate. It is a figure corresponding to FIG. 19 which shows the process performed in each apparatus when two communication apparatuses perform one-way authentication according to SSL. It is a figure for demonstrating the method conventionally used in order to write normal information in a non-volatile storage device.

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,
31, 41 ... HTTPS client function unit, 32, 42 ... HTTPS server function unit,
33, 43 ... authentication processing unit, 34 ... certificate update request unit, 35, 45 ... certificate storage unit,
44 ... request management unit, 46 ... status notification unit, 47 ... log notification unit, 48 ... certificate setting unit,
49 ... Command receiving unit, 50 ... Certificate management device, 60, 70 ... SOAP message,
140 ... Production management system, 150 ... Communication terminal, 154a ... Certificate DB,
156 ... Input device, 157 ... Display device, 160 ... Certificate writing device,
161 ... Machine number information input device, 162 ... I / F for machine number information input,
165 ... I / F for writing, BC ... Bar code, E ... Production factory, F ... Administrator room, G ... Door

Claims (5)

A certificate setting method for causing a communication device to store a digital certificate used for authentication processing using a certificate setting device,
A component storing a second certificate, which is a digital certificate corresponding to an authentication process whose cryptographic strength is weaker than that of the first certificate, which is a digital certificate to be set by the certificate setting device, is the communication device. A first procedure for attaching to the main body of
When the certificate setting device and the communication device perform authentication processing using the second certificate and the processing is successful, the certificate setting device sends the first certificate to the communication device. A second procedure to memorize,
A certificate setting method, which is executed in this order. The certificate setting method according to claim 1,
A certificate setting method, wherein after the first procedure, an inspection procedure for inspecting the quality of the communication device is executed, and the second procedure is executed for a device that has passed the inspection. The certificate setting method according to claim 1 or 2,
In the second procedure, the first certificate is stored from an interface exposed to the outside of the communication device main body. The certificate setting method according to claim 3,
The certificate setting method, wherein the interface is a connector for connecting an Ethernet standard communication cable. The certificate setting method according to any one of claims 1 to 4,
The certificate setting method, wherein the authentication process is an authentication process according to an SSL or TLS protocol.

Images