JP4611676B2 - COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM - Google Patents
COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM Download PDFInfo
- Publication number
- JP4611676B2 JP4611676B2 JP2004198624A JP2004198624A JP4611676B2 JP 4611676 B2 JP4611676 B2 JP 4611676B2 JP 2004198624 A JP2004198624 A JP 2004198624A JP 2004198624 A JP2004198624 A JP 2004198624A JP 4611676 B2 JP4611676 B2 JP 4611676B2
- Authority
- JP
- Japan
- Prior art keywords
- certificate
- authentication
- communication
- counterpart
- updating
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000004891 communication Methods 0.000 title claims description 350
- 238000000034 method Methods 0.000 title claims description 135
- PWPJGUXAGUPAHP-UHFFFAOYSA-N lufenuron Chemical compound C1=C(Cl)C(OC(F)(F)C(C(F)(F)F)F)=CC(Cl)=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F PWPJGUXAGUPAHP-UHFFFAOYSA-N 0.000 title 1
- 238000003860 storage Methods 0.000 claims description 47
- 230000005540 biological transmission Effects 0.000 claims description 43
- 238000012545 processing Methods 0.000 description 110
- 230000006870 function Effects 0.000 description 101
- 230000008569 process Effects 0.000 description 92
- 230000004044 response Effects 0.000 description 46
- 230000005856 abnormality Effects 0.000 description 41
- 238000010586 diagram Methods 0.000 description 12
- 238000004519 manufacturing process Methods 0.000 description 7
- 238000001514 detection method Methods 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012546 transfer Methods 0.000 description 5
- 230000002159 abnormal effect Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000011084 recovery Methods 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 235000019687 Lamb Nutrition 0.000 description 1
- 238000004378 air conditioning Methods 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000005611 electricity Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
- 238000005303 weighing Methods 0.000 description 1
Images
Description
この発明は、ネットワークを介して相手先装置と通信を行う通信装置、上位装置と下位装置とを備え、その上位装置と下位装置とがネットワークを介して通信を行う通信システム、ネットワークを介して相手先装置と通信を行う通信装置による通信方法、およびネットワークを介して相手先装置と通信を行う通信装置を制御するコンピュータに実行させるプログラムに関する。The present invention includes a communication device that communicates with a counterpart device via a network, a higher-level device and a lower-level device, and a communication system that communicates between the higher-level device and the lower-level device via the network, and the counterpart via the network. The present invention relates to a communication method by a communication device that communicates with a destination device, and a program that is executed by a computer that controls a communication device that communicates with a counterpart device via a network.
従来から、それぞれ通信機能を備えた複数の通信装置をネットワークを介して通信可能に接続し、様々なシステムを構築することが行われている。その一例としては、クライアント装置として機能するPC等のコンピュータから商品の注文を送信し、これとインターネットを介して通信可能なサーバ装置においてその注文を受け付けるといった、いわゆる電子商取引システムが挙げられる。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。 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.
このようなシステムを構築する上では、通信を行う際に、通信相手が適切か、あるいは送信されてくる情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばSSL(Secure Socket Layer)と呼ばれるプロトコルが開発されており、広く用いられている。このプロトコルを用いて通信を行うことにより、公開鍵暗号方式と共通鍵暗号方式とを組み合わせ、通信相手の認証を行うと共に、情報の暗号化により改竄及び盗聴の防止を図ることができる。また、通信相手の側でも、通信を要求してきた通信元の装置を認証することができる。
このようなSSLや公開鍵暗号を用いた認証に関連する技術としては、例えば特許文献1及び特許文献2に記載のものが挙げられる。
Examples of techniques related to authentication using SSL or public key cryptography include those described in Patent Document 1 and Patent Document 2.
ここで、このSSLに従った相互認証を行う場合の通信手順について、認証処理の部分に焦点を当てて説明する。図19は、通信装置Aと通信装置BとがSSLに従った相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図19に示すように、SSLに従った相互認証を行う際には、まず双方の通信装置にルート鍵証明書及び、私有鍵と公開鍵証明書を記憶させておく必要がある。この私有鍵は、認証局(CA:certificate authority)が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にCAがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、CAがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。
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.
図20にこれらの関係を示す。
図20(a)に示すように、公開鍵Aは、私有鍵Aを用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者(CA)や有効期限等の情報を含む書誌情報とによって構成される。そして、CAは、鍵本体や書誌情報が改竄されていないことを示すため、公開鍵Aをハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名としてクライアント公開鍵に付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Aの書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、公開鍵証明書Aである。
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.
この公開鍵証明書Aを認証処理に用いる場合には、ここに含まれるデジタル署名を、ルート私有鍵と対応する公開鍵であるルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば、デジタル署名が確かにCAによって付されたことがわかる。また、公開鍵Aの部分をハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とが一致すれば、鍵自体も損傷や改竄を受けていないことがわかる。さらに、受信したデータをこの公開鍵Aを用いて正常に復号化できれば、そのデータは、私有鍵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.
ここで、認証を行うためには、ルート鍵を予め記憶しておく必要があるが、このルート鍵も、図20(b)に示すように、CAがデジタル署名を付したルート鍵証明書として記憶しておく。このルート鍵証明書は、自身に含まれる公開鍵でデジタル署名を復号化可能な、自己署名形式である。そして、ルート鍵を使用する際に、そのルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し、ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば、ルート鍵が破損等していないことを確認できるのである。 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.
図19のフローチャートの説明に入る。なお、この図において、2本のフローチャート間の矢印は、データの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また、各ステップの処理が正常に完了しなかった場合には、その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合、処理がタイムアウトした場合等も同様である。 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.
ここでは、通信装置Aが通信装置Bに通信を要求するものとするが、この要求を行う場合、通信装置AのCPUは、所要の制御プログラムを実行することにより、図19の左側に示すフローチャートの処理を開始する。そして、ステップS11で通信装置Bに対して接続要求を送信する。
一方通信装置BのCPUは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図19の右側に示すフローチャートの処理を開始する。そして、ステップS21で第1の乱数を生成し、これを私有鍵Bを用いて暗号化する。そして、ステップS22でその暗号化した第1の乱数と公開鍵証明書Bとを通信装置Aに送信する。
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.
通信装置A側では、これを受信すると、ステップS12でルート鍵証明書を用いて公開鍵証明書Bの正当性を確認する。
そして確認ができると、ステップS13で、受信した公開鍵証明書Bに含まれる公開鍵Bを用いて第1の乱数を復号化する。ここで復号化が成功すれば、第1の乱数は確かに公開鍵証明書Bの発行対象から受信したものだと確認できる。
その後、ステップS14でこれとは別に第2の乱数及び共通鍵の種を生成する。共通鍵の種は、例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして、ステップS15で第2の乱数を私有鍵Aを用いて暗号化し、共通鍵の種を公開鍵Bを用いて暗号化し、ステップS16でこれらを公開鍵証明書Aと共にサーバ装置に送信する。共通鍵の種の暗号化は、通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。
また、次のステップS17では、ステップS14で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
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.
通信装置B側では、通信装置AがステップS16で送信してくるデータを受信すると、ステップS23でルート鍵証明書を用いて公開鍵証明書Aの正当性を確認する。そして確認ができると、ステップS24で、受信した公開鍵証明書Aに含まれる公開鍵Aを用いて第2の乱数を復号化する。ここで復号化が成功すれば、第2の乱数は確かに公開鍵証明書Aの発行対象から受信したものだと確認できる。
その後、ステップS25で私有鍵Bを用いて共通鍵の種を復号化する。ここまでの処理で、通信装置A側と通信装置B側に共通鍵の種が共有されたことになる。そして、この共通鍵の種は、生成した通信装置Aと、私有鍵Bを持つ通信装置B以外の装置が知ることはない。ここまでの処理が成功すると、通信装置B側でもステップS26で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
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.
そして、通信装置A側のステップS17と通信装置B側のステップS26の処理が終了すると、相互に認証の成功と以後の通信に使用する暗号化方式とを確認し、生成した共通鍵を用いてその暗号化方式で以後の通信を行うものとして認証に関する処理を終了する。なお、この確認には、通信装置Bからの認証が成功した旨の応答も含むものとする。以上の処理によって互いに通信を確立し、以後はステップS17又は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.
このような処理を行うことにより、通信装置Aと通信装置Bが安全に共通鍵を交換することができ、通信を安全に行う経路を確立することができる。
ただし、上述した処理において、第2の乱数を私有鍵Aで暗号化し、公開鍵証明書Aを通信装置Bに送信することは必須ではない。この場合、通信装置B側のステップS23及びS24の処理は不要になり、処理は図21に示すようになる。このようにすると、通信装置Bが通信装置Aを認証することはできないが、通信装置Aが通信装置Bを認証するだけでよい場合にはこの処理で十分である。そしてこの場合には、通信装置Aに記憶させるのはルート鍵証明書のみでよく、私有鍵A及び公開鍵証明書Aは不要である。また、通信装置Bにはルート鍵証明書を記憶させる必要はない。
By performing such processing, the communication device A and the communication device B can securely exchange 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 private 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.
ところで、上述したような認証処理を行う場合、認証の基準には2通りのレベルが考えられる。第1のレベルは、通信相手の機器が、同一のベンダーから供給された機器であるか、一定のテストに合格した機器であるか等、一定の基準を満たす機器か否かを判断するものであり、第2のレベルは、通信相手の機器の個体を特定するものである。
そして、第1のレベルの認証を行う場合は、一定の基準を満たす機器に共通の公開鍵証明書と私有鍵のセットを記憶させておき、SSL通信の際にこれを用いて認証を行い、通信相手が確かにその公開鍵証明書の発行対象の装置であると確認できればよい。従って、機器固有の識別情報(ID)等を交換する必要はない。
また、第2のレベルの認証を行う場合でも、例えば上記の第1のレベルの認証の場合と同様な鍵を用いて安全な通信経路を確立した後で、通信相手を特定するためにIDを送信させ、これを用いて認証を行うことができる。
By the way, when the authentication process as described above is performed, there are two levels of authentication standards. The first level is to determine whether the communication partner device is a device supplied from the same vendor or a device that meets a certain standard, such as a device that has passed a certain test. Yes, the second level specifies the individual device of the communication partner.
When performing the first level authentication, a set of public key certificate and private key common to devices satisfying a certain standard is stored, and authentication is performed using this in SSL communication. It suffices if it is possible to confirm that the communication partner is indeed the device for which the public key certificate is issued. Therefore, it is not necessary to exchange device-specific identification information (ID) or the like.
Even in the case of performing the second level authentication, for example, after establishing a secure communication path using the same key as in the case of the above first level authentication, the ID is used to identify the communication partner. It can be sent and used for authentication.
しかし、これらの認証方式では、共通の公開鍵証明書と私有鍵が漏洩すると、これを取得した第3者はIDのわかる機器ならどの機器にでも成りすませてしまうため、著しく通信の安全が損われる。また、全ての機器の鍵を更新しなければ通信の安全は回復できず、この作業は多大な労力を要するものであった。
そして、この問題を解決するためには、公開鍵証明書と私有鍵を装置毎に発行し、公開鍵証明書の書誌情報に装置のIDを記載し、公開鍵証明書の正当性を確認する際に書誌情報に含まれるIDも参照して、その証明書を送信してきた相手(証明書の発行対象の装置)が適当な通信相手であることを確認するようにすることが考えられる。このようにした場合には、装置毎に異なった公開鍵証明書と私有鍵のペアを記憶させるため、1つの機器の鍵が漏洩したとしても、その機器にしかなりすますことはできず、また、その機器の鍵を更新してしまえば、通信を再び安全な状態に保つことができる。
However, in these authentication methods, if a common public key certificate and a private key are leaked, the third party who obtains the certificate can impersonate any device whose ID is known. Is called. In addition, communication security cannot be recovered unless the keys of all the devices are updated, and this work requires a great deal of labor.
In order to solve this problem, a public key certificate and a private key are issued for each device, the device ID is described in the bibliographic information of the public key certificate, and the validity of the public key certificate is confirmed. At this time, referring to the ID included in the bibliographic information, it may be possible to confirm that the other party (the certificate issuance target apparatus) that transmitted the certificate is an appropriate communication party. In this case, since a different public key certificate and private key pair is stored for each device, even if the key of one device is leaked, it can not be used for that device. If the key of the device is updated, communication can be kept secure again.
しかし、このようにした場合でも、鍵が破損等により使用不能になったりした場合の復旧処理については問題が残る。すなわち、このような場合にはSSLに従った認証処理を正常に行うことができないので、復旧を要する通信装置に対する安全な通信経路を確保することができない。
従って、新たな鍵を安全に配布するためには、鍵を記録媒体に記録して装置の設置先に郵送する等する必要がある。そして、このような場合の更新は人手で行う必要があるため、装置の設置先にある程度装置に精通した人がいる必要があるし、いたとしても更新を怠る可能性もあるため、復旧作業に時間がかかる上信頼性が低いという問題があった。
However, even in this case, there remains a problem with the recovery process when the key becomes unusable due to damage or the like. That is, in such a case, authentication processing according to SSL cannot be performed normally, and a safe communication path for a communication device that needs to be restored cannot be secured.
Therefore, in order to safely distribute a new key, it is necessary to record the key on a recording medium and mail it to the installation location of the apparatus. In such a case, it is necessary to update manually.Therefore, it is necessary that there is a person who is familiar with the device to some extent at the installation location of the device. There was a problem that it took time and was not reliable.
また、新たな公開鍵証明書にも当然装置のIDを記載するわけであるし、機器やユーザの特定にも使用するIDが復旧時に変わってしまうことは好ましくない。従って、新たな公開鍵証明書を記録した記録媒体を予め用意しておくことはできず、更新が必要な装置が判明してから必要に応じて作成することになる。従って極めて効率の悪い生産体制を強いられることになるという問題もあった。
この発明は、このような問題を解決し、通信の際に通信相手を証明書を用いて認証する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、セキュリティを維持しながら、認証に異常があった場合でも正常な認証が行える状態に容易に回復させることができるようにすることを目的とする。
In addition, the ID of the device is naturally described in the new public key certificate, and it is not preferable that the ID used for specifying the device or user changes at the time of recovery. Therefore, a recording medium on which a new public key certificate is recorded cannot be prepared in advance, and is created as necessary after an apparatus that needs to be updated is identified. Therefore, there was a problem that the production system would be forced to be extremely inefficient.
This invention is to solve such a problem, in a communication device or a communication system which is constructed by using such a communication device authenticates by using a certificate for a communication partner at the time of communication, while maintaining security, authentication It is an object of the present invention to enable easy recovery to a state where normal authentication can be performed even if there is an abnormality in the system.
上記の目的を達成するため、この発明の通信装置は、ネットワークを介して相手先装置と通信を行う通信装置において、上記相手先装置と通信を行う場合に、その相手先装置から受信したその相手先装置を一意に特定するための識別情報を含む第1の証明書を用いてその相手先装置の認証を行う第1の認証手段と、上記第1の認証手段による認証が失敗した場合に、上記相手先装置から受信した、その相手先装置を一意に特定するための識別情報を含まない第2の証明書を用いてその相手先装置の認証を行う第2の認証手段と、上記第2の認証手段による認証が成功した場合に、上記第1の証明書の更新を要求する証明書更新要求及び上記第1の証明書を更新するための証明書を上記相手先装置へ送信する送信手段とを設けたものである。
このような通信装置において、上記第2の認証手段による認証が成功した場合に、所定の証明書管理装置に対して、上記相手先装置へ送信する、上記第1の証明書を更新するための証明書の発行を要求し、その証明書管理装置からその第1の証明書を更新するための証明書を取得する手段を設けるとよい。
さらに、上記相手先装置を一意に特定するための識別情報が、上記相手先装置の機番であるとよい。
In order to achieve the above object, the communication device of the present invention is a communication device that communicates with a partner device via a network, and communicates with the partner device when the partner device receives the partner device. A first authentication unit that authenticates the counterpart device using a first certificate that includes identification information for uniquely identifying the destination device, and when the authentication by the first authentication unit fails, Second authentication means for authenticating the counterpart device using the second certificate received from the counterpart device and not including identification information for uniquely identifying the counterpart device; and the second A transmitting means for transmitting a certificate update request for requesting the update of the first certificate and a certificate for updating the first certificate to the counterpart device when the authentication by the authenticating means is successful. Are provided.
In such a communication device, when the authentication by the second authentication means is successful, the first certificate to be transmitted to the counterpart device to the predetermined certificate management device is updated. Means may be provided for requesting issuance of a certificate and obtaining a certificate for updating the first certificate from the certificate management apparatus.
Furthermore, the identification information for uniquely specifying the counterpart device may be a machine number of the counterpart device.
また、この発明の別の通信装置は、ネットワークを介して相手先装置と通信を行う通信装置において、その通信装置を一意に特定するための識別情報を含む第1の証明書と、その通信装置を一意に特定するための識別情報を含まない第2の証明書とを記憶する記憶手段と、上記相手先装置と通信を行う場合に、上記第1の証明書を上記相手先装置へ送信する第1の送信手段と、上記第1の送信手段が送信した上記第1の証明書を用いた上記相手先装置での認証が失敗した場合に、上記第2の証明書を上記相手先装置へ送信する第2の送信手段と、上記第2の送信手段が送信した上記第2の証明書を用いた上記相手先装置での認証が成功した場合に、上記相手先装置から上記第1の証明書の更新を要求する証明書更新要求及び上記第1の証明書を更新するための証明書を上記相手先装置から受信し、上記記憶手段に記憶された上記第1の証明書を上記受信した証明書に更新する更新手段とを設けたものである。According to another aspect of the present invention, there is provided a first certificate including identification information for uniquely identifying a communication device that communicates with a counterpart device via a network, and the communication device. Storage means for storing a second certificate that does not include identification information for uniquely identifying the first certificate, and when communicating with the counterpart device, the first certificate is transmitted to the counterpart device. When authentication at the counterpart device using the first transmission means and the first certificate transmitted by the first transmission means fails, the second certificate is sent to the counterpart device. When the authentication at the partner apparatus using the second transmitting means for transmitting and the second certificate transmitted by the second transmitting means is successful, the partner apparatus transmits the first certification. Certificate renewal request to request certificate renewal and the first certificate Certificates for updating received from the destination apparatus, in which the first certificate is stored in the memory means is provided and updating means for updating the certificate received above.
このような通信装置において、上記第2の送信手段が送信した上記第2の証明書を用いた上記相手先装置での認証が成功した場合に、上記相手先装置からの要求のうち、上記証明書更新要求のみを許可するようにするとよい。In such a communication apparatus, when the authentication with the counterpart apparatus using the second certificate transmitted by the second transmission means is successful, the certification among the requests from the counterpart apparatus. It is advisable to allow only document update requests.
さらに、上記更新手段が受信する上記第1の証明書を更新するための証明書を、上記証明書更新要求と共に送信されてくるものとするとよい。Furthermore, it is preferable that a certificate for updating the first certificate received by the updating unit is transmitted together with the certificate update request.
さらに、上記通信装置を一意に特定するための識別情報が、上記通信装置の機番であるとよい。Furthermore, the identification information for uniquely specifying the communication device may be a device number of the communication device.
また、この発明の通信システムは、上位装置と下位装置とを備え、上記上位装置と上記下位装置とがネットワークを介して通信を行う通信システムにおいて、上記下位装置に、上記下位装置を一意に特定するための識別情報を含む第1の証明書と、上記下位装置を一意に特定するための識別情報を含まない第2の証明書とを記憶する記憶手段と、上記上位装置と通信を行う場合に、上記第1の証明書を上記上位装置へ送信する第1の送信手段と、上記第1の送信手段が送信した上記第1の証明書を用いた上記上位装置での認証が失敗した場合に、上記第2の証明書を上記上位装置へ送信する第2の送信手段と、上記第2の送信手段が送信した上記第2の証明書を用いた上記上位装置での認証が成功した場合に、上記上位装置から上記第1の証明書の更新を要求する証明書更新要求及び上記第1の証明書を更新するための証明書を上記上位装置から受信し、上記記憶手段に記憶された上記第1の証明書を上記受信した証明書に更新する更新手段とを設け、上記上位装置に、上記下位装置と通信を行う場合に、その下位装置から受信した上記第1の証明書を用いてその下位装置の認証を行う第1の認証手段と、上記第1の認証手段による認証が失敗した場合に、上記下位装置から受信した上記第2の証明書を用いてその下位装置の認証を行う第2の認証手段と、上記第2の認証手段による認証が成功した場合に、上記第1の証明書の更新を要求する証明書更新要求及び上記第1の証明書を更新するための証明書を上記下位装置へ送信する送信手段とを設けたものである。The communication system of the present invention comprises a host device and a lower device, and in the communication system in which the host device and the lower device communicate via a network, the lower device is uniquely identified in the lower device. In the case of performing communication with the upper apparatus, storage means for storing a first certificate including identification information for identifying the second certificate and a second certificate not including identification information for uniquely identifying the lower apparatus In addition, the first transmission means for transmitting the first certificate to the higher-level device and the authentication at the higher-level device using the first certificate transmitted by the first transmission means have failed. And second authentication means for transmitting the second certificate to the higher-level device and authentication with the higher-level device using the second certificate transmitted by the second transmission means. Next, the first proof is sent from the host device. A certificate renewal request for requesting renewal of a certificate and a certificate for renewing the first certificate are received from the host device, and the first certificate stored in the storage means is received. A first means for authenticating the lower-level device using the first certificate received from the lower-level device when the higher-level device communicates with the lower-level device. An authentication unit; a second authentication unit that authenticates the lower-level device using the second certificate received from the lower-level device when authentication by the first authentication unit fails; and the second Transmitting means for transmitting a certificate update request for requesting the update of the first certificate and a certificate for updating the first certificate to the lower-level device when the authentication by the authentication means is successful. Is provided.
このような通信システムにおいて、上記上位装置に、上記第2の認証手段による認証が成功した場合に、所定の証明書管理装置に対して、上記下位装置へ送信する、上記第1の証明書を更新するための証明書の発行を要求し、その証明書管理装置からその第1の証明書を更新するための証明書を取得する手段を設けるとよい。In such a communication system, when the authentication by the second authentication unit is successful, the first certificate transmitted to the lower device is transmitted to the lower device when the authentication by the second authentication unit is successful. Means may be provided for requesting issuance of a certificate for renewal and obtaining a certificate for renewing the first certificate from the certificate management apparatus.
さらに、上記下位装置が、上記第2の送信手段が送信した上記第2の証明書を用いた上記上位装置での認証が成功した場合に、上記上位装置からの要求のうち、上記証明書更新要求のみを許可するようにするとよい。Further, when the lower-level device succeeds in the authentication by the higher-level device using the second certificate transmitted by the second transmission means, the certificate renewal among the requests from the higher-level device. It is advisable to allow only requests.
さらに、上記上位装置の送信手段が、上記証明書更新要求と共に上記第1の証明書を更新するための証明書を上記下位装置へ送信し、上記下位装置の上記更新手段が受信する上記第1の証明書を更新するための証明書が、上記証明書更新要求と共に送信されてくるものであるとよい。Further, the transmission means of the higher-level device transmits the certificate for updating the first certificate together with the certificate update request to the lower-level device, and the first means received by the update means of the lower-level device. The certificate for updating the certificate may be transmitted together with the certificate update request.
さらにまた、上記下位装置を一意に特定するための識別情報が、上記下位装置の機番であるとよい。Furthermore, the identification information for uniquely identifying the lower device may be the machine number of the lower device.
また、この発明の通信方法は、ネットワークを介して相手先装置と通信を行う通信装置に、上記相手先装置と通信を行う場合に、その相手先装置から受信したその相手先装置を一意に特定するための識別情報を含む第1の証明書を用いてその相手先装置の認証を行う第1の認証手順と、上記第1の認証手順による認証が失敗した場合に、上記相手先装置から受信した、上記相手先装置を一意に特定するための識別情報を含まない第2の証明書を用いてその相手先装置の認証を行う第2の認証手順と、上記第2の認証手順による認証が成功した場合に、上記第1の証明書の更新を要求する証明書更新要求及び上記第1の証明書を更新するための証明書を上記相手先装置へ送信する送信手順とを実行させるものである。In addition, the communication method of the present invention uniquely identifies a partner device received from the partner device when communicating with the partner device to a communication device that communicates with the partner device via a network. A first authentication procedure for authenticating the counterpart device using a first certificate including identification information to be received, and reception from the counterpart device when authentication by the first authentication procedure fails A second authentication procedure for authenticating the counterpart device using a second certificate that does not include identification information for uniquely identifying the counterpart device, and authentication by the second authentication procedure. When successful, a certificate update request for updating the first certificate and a transmission procedure for transmitting a certificate for updating the first certificate to the counterpart device are executed. is there.
また、この発明の別の通信方法は、ネットワークを介して相手先装置と通信を行う通信装置であって、その通信装置を一意に特定するための識別情報を含む第1の証明書と、その通信装置を一意に特定するための識別情報を含まない第2の証明書とを記憶する記憶手段を有する通信装置に、上記相手先装置と通信を行う場合に、上記第1の証明書を上記相手先装置へ送信する第1の送信手順と、上記第1の送信手順で送信した上記第1の証明書を用いた上記相手先装置での認証が失敗した場合に、上記第2の証明書を上記相手先装置へ送信する第2の送信手順と、上記第2の送信手順で送信した上記第2の証明書を用いた上記相手先装置での認証が成功した場合に、上記相手先装置から上記第1の証明書の更新を要求する証明書更新要求及び上記第1の証明書を更新するための証明書を上記相手先装置から受信し、上記記憶手段に記憶された上記第1の証明書を上記受信した証明書に更新する更新手順とを実行させるものである。Another communication method of the present invention is a communication device that communicates with a counterpart device via a network, the first certificate including identification information for uniquely identifying the communication device, When communicating with the counterpart device to a communication device having a storage means for storing a second certificate that does not include identification information for uniquely identifying the communication device, the first certificate is The first certificate that is sent to the counterpart device and the second certificate when authentication with the counterpart device using the first certificate that is sent in the first procedure fails When the authentication at the counterpart device using the second certificate transmitted by the second transmission procedure and the second certificate transmitted by the second transmission procedure is successful. A certificate renewal request for requesting renewal of the first certificate from Receiving a certificate for updating the first certificate from the counterpart device, and executing an update procedure for updating the first certificate stored in the storage means to the received certificate. Is.
また、この発明のプログラムは、ネットワークを介して相手先装置と通信を行う通信装置を制御するコンピュータを、上記相手先装置と通信を行う場合に、その相手先装置から受信したその相手先装置を一意に特定するための識別情報を含む第1の証明書を用いてその相手先装置の認証を行う第1の認証手段と、上記第1の認証手段による認証が失敗した場合に、上記相手先装置から受信した、上記相手先装置を一意に特定するための識別情報を含まない第2の証明書を用いてその相手先装置の認証を行う第2の認証手段と、上記第2の認証手段による認証が成功した場合に、上記第1の証明書の更新を要求する証明書更新要求及び上記第1の証明書を更新するための証明書を上記相手先装置へ送信する送信手段として機能させるためのプログラムである。In addition, the program of the present invention, when communicating with the other party device, a computer that controls the communication device that communicates with the other party device via the network, the destination device received from the other party device. A first authentication unit that authenticates the counterpart device using a first certificate that includes identification information for uniquely identifying the destination device, and the destination when the authentication by the first authentication unit fails Second authentication means for authenticating the counterpart device using a second certificate that does not contain identification information for uniquely identifying the counterpart device received from the device; and the second authentication means When the authentication by the authentication is successful, it functions as a transmission means for transmitting a certificate update request for updating the first certificate and a certificate for updating the first certificate to the counterpart device. Pro for It is a lamb.
また、この発明の別のプログラムは、ネットワークを介して相手先装置と通信を行う通信装置であって、その通信装置を一意に特定するための識別情報を含む第1の証明書と、その通信装置を一意に特定するための識別情報を含まない第2の証明書とを記憶する記憶手段を有する通信装置を制御するコンピュータを、上記相手先装置と通信を行う場合に、上記第1の証明書を上記相手先装置へ送信する第1の送信手段と、上記第1の送信手段が送信した上記第1の証明書を用いた上記相手先装置での認証が失敗した場合に、上記第2の証明書を上記相手先装置へ送信する第2の送信手段と、上記第2の送信手段が送信した上記第2の証明書を用いた上記相手先装置での認証が成功した場合に、上記相手先装置から上記第1の証明書の更新を要求する証明書更新要求及び上記第1の証明書を更新するための証明書を上記相手先装置から受信し、上記記憶手段に記憶された上記第1の証明書を上記受信した証明書に更新する更新手段として機能させるためのプログラムである。Another program of the present invention is a communication device that communicates with a counterpart device via a network, the first certificate including identification information for uniquely identifying the communication device, and the communication When a computer that controls a communication device having storage means for storing a second certificate that does not include identification information for uniquely identifying the device communicates with the counterpart device, the first certificate The first transmission means for transmitting the certificate to the counterpart device and the second request when the authentication at the counterpart device using the first certificate transmitted by the first transmission means fails. The second transmission unit that transmits the certificate of the second party to the counterpart device, and when the authentication at the counterpart device using the second certificate transmitted by the second transmission unit is successful, Requires renewal of the first certificate from the other device A certificate update request to be performed and a certificate for updating the first certificate are received from the counterpart apparatus, and the first certificate stored in the storage unit is updated to the received certificate. It is a program for functioning as update means.
以上のようなこの発明の通信装置、通信システム、または通信方法によれば、通信の際に通信相手を証明書を用いて認証する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、セキュリティを維持しながら、認証に異常があった場合でも正常な認証が行える状態に容易に回復させることができるようにすることができる。また、この発明のプログラムによれば、コンピュータに通信装置を制御させることにより上記の通信装置として機能させてその特徴を実現し、同様な効果を得ることができる。 Above-mentioned communication device according to the present invention, according to the communication system or communication method, a communication apparatus or a communication system which is constructed by using such a communication device authenticates by using a certificate for a communication partner at the time of communication Thus, it is possible to easily recover to a state where normal authentication can be performed even if there is an abnormality in authentication while maintaining security. Further, according to the program of the present invention, it is possible to realize the characteristics by causing the computer to control the communication device so as to function as the communication device described above, and obtain the same effect.
以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明による通信装置と、その通信装置を用いて構成したこの発明の通信システムの第1の実施形態の構成について説明する。この実施形態においては、それぞれ通信装置である上位装置30及び下位装置40によって通信システムを構成し、上位装置30と証明書管理装置20とをネットワークを介して通信可能な状態にして、通信システムと証明書管理装置とによってデジタル証明書管理システムを構成している。図1にその上位装置及び下位装置の、図2に証明書管理装置の、それぞれこの実施形態の特徴に関連する部分の機能構成を示す機能ブロック図を示す。これらの図において、この実施形態の特徴と関連しない部分の図示は省略している。なお、この明細書において、デジタル証明書とは、偽造されないようにするための署名が付されたデジタルデータを指すものとする。
Preferred embodiments of the present invention will be described below with reference to the drawings.
First, the configuration of the first embodiment of the communication apparatus according to the present invention and the communication system of the present invention configured using the communication apparatus will be described. In this embodiment, a communication system is configured by the higher-
この通信システムにおいて、上位装置30は、下位装置40と通信を行おうとする場合、公開鍵暗号とデジタル証明書を用いる認証方式であるSSLプロトコルに従った認証処理によって下位装置40を正当な通信相手として認証した場合に、下位装置40との間で通信を確立させるようにしている。そして、上位装置30が送信した要求に対し、下位装置40が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。
逆に、下位装置40が上位装置30と通信を行おうとする場合にも、同じくSSLに従った認証処理によって上位装置30を正当な通信相手として認証した場合に、上位装置30との間で通信を確立させるようにしている。そして、下位装置40が送信した要求に対し、上位装置30が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。
どちらの場合も、通信を要求する側がクライアント、要求される側がサーバとして機能するものとする。
In this communication system, when the
Conversely, when the
In either case, the requesting side functions as a client, and the requested side functions as a server.
また、証明書管理装置20は、上記の相互認証に用いるデジタル証明書を発行及び管理する装置であり、CAに相当する。
なお、図1及び図2において、下位装置40は1つしか示していないが、図18に示すように下位装置40を複数設けることも可能である。また、上位装置30は1つの通信システムについて1つのみであるが、1つの証明書管理装置20を複数の通信システムと通信可能とした結果、証明書管理システム内に複数の上位装置30が存在することになっても構わない。
The
1 and 2, only one
このような通信システムにおいて、上述の上位装置30と下位装置40との間の通信も含め、証明書管理装置20,上位装置30,下位装置40の各ノードは、RPC(remote procedure call)により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「要求」を送信し、この依頼された処理の結果である「応答」を取得することができるようになっている。
この、RPCを実現するためには、SOAP(Simple Object Access Protocol),HTTP(Hyper Text Transfer Protocol),FTP(File Transfer Protocol),COM(Component Object Model),CORBA(Common Object Request Broker Architecture)等の既知のプロトコル(通信規格),技術,仕様などを利用することができる。
In such a communication system, each node of the
In order to realize this RPC, SOAP (Simple Object Access Protocol), HTTP (Hyper Text Transfer Protocol), FTP (File Transfer Protocol), COM (Component Object Model), CORBA (Common Object Request Broker Architecture), etc. Known protocols (communication standards), technology, specifications, etc. can be used.
次に、この通信システムを構成する各装置の構成と機能についてより詳細に説明する。
図3は、図2に示した証明書管理装置20のハードウェア構成を示すブロック図である。この図に示す通り、証明書管理装置20は、CPU11,ROM12,RAM13,HDD14,通信インタフェース(I/F)15を備え、これらがシステムバス16によって接続されている。そして、CPU11がROM12やHDD14に記憶している各種制御プログラムを実行することによってこの証明書管理装置20の動作を制御し、デジタル証明書の作成や管理等の機能を実現させている。
なお、証明書管理装置20のハードウェアとしては、適宜公知のコンピュータを採用することができる。もちろん、必要に応じて他のハードウェアを付加してもよい。
Next, the configuration and function of each device constituting this communication system will be described in more detail.
FIG. 3 is a block diagram showing a hardware configuration of the
As the hardware of the
上位装置30及び下位装置40については、装置の遠隔管理,電子商取引等の目的に応じて種々の構成をとることができる。例えば、遠隔管理の場合には、プリンタ,FAX装置,コピー機,スキャナ,デジタル複合機等の画像処理装置を始め、ネットワーク家電,自動販売機,医療機器,電源装置,空調システム,ガス・水道・電気等の計量システム、自動車、航空機等の電子装置を被管理装置である下位装置40とし、これらの被管理装置から情報を収集したり、コマンドを送って動作させたりするための管理装置を上位装置30とすることが考えられる。
The high-
しかし、上位装置30及び下位装置40は、少なくともそれぞれCPU,ROM,RAM,ネットワークを介して外部装置と通信するための通信I/F、および認証処理に必要な情報を記憶する記憶手段を備え、CPUがROM等に記憶した所要の制御プログラムを実行することにより、装置にこの実施形態の特徴に係る各機能を実現させることができるものとする。
なお、この通信には、有線,無線を問わず、ネットワークを構築可能な各種通信回線(通信経路)を採用することができる。証明書管理装置20との間の通信についても同様である。
However, the
Note that various communication lines (communication paths) capable of constructing a network can be adopted for this communication regardless of wired or wireless. The same applies to communication with the
図1には、上述のように、上位装置30及び下位装置40のこの実施形態の特徴となる部分の機能構成を示している。
まず、上位装置30には、HTTPS(Hypertext Transfer Protocol Security)クライアント機能部31,HTTPSサーバ機能部32,認証処理部33,証明書更新要求部34,証明書記憶部35を備えている。
HTTPSクライアント機能部31は、SSLに従った認証や暗号化の処理を含むHTTPSプロトコルを用いて下位装置40等のHTTPSサーバの機能を有する装置に対して通信を要求すると共に、通信相手に対して要求(コマンド)やデータを送信してそれに応じた動作を実行させる機能を有する。
FIG. 1 shows the functional configuration of the portions of the higher-
First, the
The HTTPS
一方、HTTPSサーバ機能部32は、HTTPSクライアントの機能を有する装置からのHTTPSプロトコルを用いた通信要求を受け付け、その装置から要求やデータを受信してそれに応じた動作を装置の各部に実行させ、その結果を応答として要求元に返す機能を有する。
認証処理部33は、HTTPSクライアント機能部31やHTTPSサーバ機能部32が通信相手を認証する際に、通信相手から受信したデジタル証明書や、証明書記憶部35に記憶している各種証明書、私有鍵等を用いて認証処理を行う認証手段の機能を有する。また、通信相手に認証を要求するために証明書記憶部35に記憶しているデジタル証明書をHTTPSクライアント機能部31やHTTPSサーバ機能部32を介して通信相手に送信する機能も有する。さらに、後述するように所定の場合に個別証明書を用いた認証に異常があると判断する異常検知手段の機能も有する。
On the other hand, the HTTPS
When the HTTPS
証明書更新要求部34は、後述するように所定の場合に下位装置40等の通信相手に対して個別証明書を送信する個別証明書送信手段と、さらにこれを記憶するよう要求する個別証明書更新手段の機能とを有する。
証明書記憶部35は、各種の証明書や私有鍵等の認証情報を記憶し、認証処理部33における認証処理に供する機能を有する。これらの各種証明書や私有鍵の種類及びその用途や作成方法については後に詳述する。
そして、これらの各部の機能は、上位装置30のCPUが所要の制御プログラムを実行して上位装置30の各部の動作を制御することにより実現される。
The certificate
The
The functions of these units are realized by the CPU of the
次に、下位装置40には、HTTPSクライアント機能部41,HTTPSサーバ機能部42,認証処理部43,要求管理部44,証明書記憶部45,状態通知部46,ログ通知部47,証明書更新部48,コマンド受信部49を備えている。
HTTPSクライアント機能部41は、上位装置30のHTTPSクライアント機能部31と同様に、HTTPSプロトコルを用いて上位装置30等のHTTPSサーバの機能を有する装置に対して通信を要求すると共に、送信する要求やデータ等に応じた動作を実行させる機能を有する。
Next, the
Similar to the HTTPS
HTTPSサーバ機能部42も、上位装置30のHTTPSサーバ機能部32と同様であり、HTTPSクライアントの機能を有する装置からの通信要求を受け付け、受信した要求やデータに応じた動作を装置の各部に実行させ、要求元に応答を返す機能を有する。
認証処理部43の機能も、上位装置30の認証処理部33と同様であるが、認証処理に使用する証明書等は、証明書記憶部45に記憶しているものである。
要求管理部44は、上位装置から受信した要求について、その要求に基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、その要求に基づいた動作を実行する機能部46〜49に対して動作要求を伝える機能も有する。
The HTTPS
The function of the
The
図4にこの実行可否の判断基準を示すが、その判断基準は、要求の種類及び認証処理部43において認証処理に使用したデジタル証明書の種類である。上位装置30及び下位装置40が記憶しているデジタル証明書には、詳細は後述するが、個別証明書であり装置(自機)の識別情報が付された公開鍵証明書である個別公開鍵証明書と、共通証明書であり装置の識別情報が付されていない公開鍵証明書である共通公開鍵証明書があり、要求管理部44は、図4に示すように、個別証明書による認証を行った場合には全ての動作を許可するが、共通証明書による認証を行った場合には証明書の更新動作のみを許可するようにしている。従って、共通証明書は、下位装置40に新たな個別証明書を記憶させる場合のみに使用する証明書ということになる。
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
証明書記憶部45は、上位装置の証明書記憶部35と同様に各種の証明書や私有鍵等の認証情報を記憶し、認証処理部43における認証処理に供する証明書記憶手段の機能を有する。ただし、記憶している証明書等は、後述するように認証処理部33とは異なる。
状態通知部46は、異常を検知したりユーザによる指示があったりした場合に上位装置30に対して下位装置40の状態を通知するコールを行う機能を有する。この通知は、上位装置30からの問い合わせに対する応答として送信してもよいし、HTTPSクライアント機能部41から上位装置に通信を要求して送信してもよい。
The
The
ログ通知部47は、下位装置40から上位装置30へのログの通知を行う機能を有する。その通知の内容としては、下位装置40の動作ログの他、例えば画像形成装置であれば画像形成枚数カウンタのカウント値、計量システムであればその計量値等が考えられる。この通知は緊急を要さないので、上位装置30からの問い合わせに対する応答として送信するとよい。
証明書更新部48は、上位装置30から受信した証明書等によって証明書記憶部45に記憶している証明書等を更新する機能を有する。
コマンド受信部49は、上述した各機能部46〜48以外の機能に係る要求に対応する動作を実行する機能を有する。この動作としては、例えば下位装置40が記憶しているデータの送信や、必要に応じて図示を省略したエンジン部の動作を制御することが挙げられる。
そして、これらの各部の機能は、下位装置40のCPUが所要の制御プログラムを実行して上位装置40の各部の動作を制御することにより実現される。なお、状態通知部46やログ通知部47は、コマンド受信部49が提供する機能の具体例として示したものであり、これらのような機能を設けることは必須ではない。
The
The
The
The functions of these units are realized by the CPU of the
また図2には、上述のように、証明書管理装置20のこの実施形態の特徴となる部分の機能構成を示している。
この図に示すように、証明書管理装置20は、HTTPSサーバ機能部21,認証処理部22,証明書更新部23,証明用鍵作成部24,証明書発行部25,証明書管理部26を備えている。
HTTPSサーバ機能部21は、上位装置30や下位装置40のHTTPSサーバ機能部と同様、HTTPSクライアントの機能を有する装置からの通信要求を受け付け、受信した要求やデータに応じた動作を装置の各部に実行させ、要求元に応答を返す機能を有する。
FIG. 2 shows a functional configuration of a part that is a feature of this embodiment of the
As shown in this figure, the
The HTTPS
認証処理部22の機能も、上位装置30や下位装置40の認証処理部と同様であるが、認証処理に使用する証明書等は、証明書管理部26に記憶しているものであり、この種類及び用途や機能については後述する。
証明書更新部23は、上位装置30から個別証明書発行依頼があった場合に、証明用鍵作成部24や証明書発行部25に対象の下位装置40の新たな個別証明書を発行させ、これを証明書管理部26からHTTPSサーバ機能部21を介して上位装置30に送信させる機能を有する。
The function of the
The
証明用鍵作成部24は、デジタル署名の作成に用いる証明用私有鍵であるルート私有鍵と、そのデジタル証明書の正当性を確認するための、ルート私有鍵と対応する証明用公開鍵(証明鍵)であるルート鍵とを作成する証明用鍵作成手段の機能を有する。
証明書発行部25は、証明書管理装置20自身及び上位装置30と下位装置40とに対してSSLプロトコルに従った認証処理に用いる公開鍵及びこれと対応する私有鍵を発行する機能を有する。そしてさらに、それぞれ発行した公開鍵に証明用鍵作成部24で作成したルート私有鍵を用いてデジタル署名を付して、デジタル証明書である公開鍵証明書を発行する証明書発行手段の機能を有する。また、ルート鍵にデジタル署名を付したルート鍵証明書の発行もこの証明書発行部25の機能である。
The certification
The
証明書管理部26は、証明書発行部25が発行したデジタル証明書、その作成に用いたルート私有鍵、およびそのルート私有鍵と対応するルート鍵を管理する証明書管理手段の機能を有する。そして、これらの証明書や鍵を、その有効期限や発行先、ID、更新の有無等の情報と共に記憶する。また、自身に対して発行した証明書や私有鍵については、認証処理部22における認証処理に供する機能も有する。
そして、これらの各部の機能は、証明書管理装置20のCPUが所要の制御プログラムを実行して証明書管理装置20の各部の動作を制御することにより実現される。
The
The functions of these units are realized by the CPU of the
次に、上述した各装置が認証処理に用いる各証明書や鍵の特性及び用途について説明する。図5は、(a)に上位装置30の証明書記憶部35に記憶している証明書及び鍵の種類を示し、(b)に下位装置40の証明書記憶部45に記憶している証明書及び鍵の種類を示す図である。また、図6は証明書管理装置20の証明書管理部26に記憶している証明書及び鍵のうち、証明書管理装置20における認証処理に用いるものを示す図である。
上位装置30,下位装置40,証明書管理装置20は、大きく分けて正規認証情報とレスキュー認証情報を記憶している。そして、これらの正規認証情報とレスキュー認証情報は、それぞれ自分に関する認証情報である公開鍵証明書及び私有鍵と、通信相手に関する認証情報であるルート鍵証明書とによって構成される。
そして、各装置は、通常の通信時は正規認証情報を用いてSSLに従った図19に示したような手順の相互認証あるいは図21に示したような片方向認証を行う。
Next, characteristics and applications of each certificate and key used by each device described above for authentication processing will be described. FIG. 5A shows the types of certificates and keys stored in the
The
Then, during normal communication, each device performs mutual authentication in the procedure as shown in FIG. 19 according to SSL or one-way authentication as shown in FIG. 21 using regular authentication information.
また、例えば下位装置用個別公開鍵証明書は、証明書管理装置20が下位装置40に対して発行した個別公開鍵に、下位装置認証用個別ルート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。図7にその構成を示すが、この下位装置用個別公開鍵証明書は、書誌情報に発行対象である下位装置40の識別情報として下位装置40の機番情報を含むものである。この他に、下位装置40の機種番号や登録ユーザ等の情報も含めるようにしてもよい。
Further, for example, the individual device public key certificate for the lower-level device is a digital signature that can confirm the validity of the individual public key issued by the
また、下位装置用個別私有鍵はその個別公開鍵と対応する私有鍵、下位装置認証用個別ルート鍵証明書は、下位装置認証用個別ルート鍵に自身と対応するルート私有鍵を用いて自身で正当性を確認可能なデジタル署名を付したデジタル証明書である。そして、下位装置40を複数設けた場合でも、各装置の個別公開鍵に付すデジタル署名は同じルート私有鍵を用いて付し、正当性確認に必要な個別ルート鍵証明書は共通にする。しかし、個別公開鍵証明書に含まれる個別公開鍵やこれと対応する私有鍵は、装置毎に異なる。
上位装置用個別公開鍵証明書と上位装置用個別私有鍵と上位装置認証用個別ルート鍵証明書も同様な関係であり、CA用個別公開鍵証明書とCA用個別私有鍵とCA認証用個別ルート鍵証明書も同様な関係である。
The private private key for the lower level device is a private key corresponding to the individual public key, and the individual root key certificate for lower level device authentication is the root private key corresponding to itself for the individual root key for lower level device authentication. It is a digital certificate with a digital signature that can be verified. Even when a plurality of lower-
The individual public key certificate for the host device, the individual private key for the host device, and the individual root key certificate for the host device authentication have the same relationship, and the individual public key certificate for CA, the individual private key for CA, and the individual certificate for CA authentication The root key certificate has the same relationship.
そして、例えば上位装置30と下位装置40とが相互認証を行う場合には、上位装置30からの通信要求に応じて、下位装置40は下位装置用個別私有鍵を用いて暗号化した第1の乱数を下位装置用個別公開鍵証明書と共に上位装置30に送信する。上位装置30側では下位装置認証用個別ルート鍵証明書を用いてまずこの下位装置用個別公開鍵証明書の正当性(損傷や改竄を受けていないこと)を確認し、これが確認できた場合にここに含まれる公開鍵で第1の乱数を復号化する。この復号化が成功した場合に、上位装置30は通信相手の下位装置40が確かに下位装置用個別公開鍵証明書の発行先であると認識でき、その証明書に含まれる識別情報から装置を特定することができる。そして、特定した装置が通信相手としてふさわしいか否かに応じて認証の成功と失敗を決定することができる。
For example, when the
また、下位装置40側でも、上位装置30側で認証が成功した場合に送信されてくる上位装置用個別公開鍵証明書及び上位装置用個別私有鍵で暗号化された乱数を受信し、記憶している上位装置認証用ルート鍵証明書を用いて同様な認証を行うことができる。
なお、この手順は上位装置30がHTTPSクライアント機能部31によって下位装置40のHTTPSサーバ機能部42に対して通信を要求する場合の処理であり、下位装置40がHTTPSクライアント機能部41によって上位装置30のHTTPSサーバ機能部32に対して通信を要求する場合には、使用する証明書や鍵は同じであるが、上位装置30と下位装置40の処理が逆になる。
上位装置30と証明書管理装置20とが通信する場合の処理についても同様である。
Further, the
This procedure is processing when the
The same applies to the processing when the
ところで、ここまでの説明から明らかなように、各装置が通信相手に対して個別公開鍵証明書を送信した場合でも、通信相手がその個別公開鍵証明書と対応する個別ルート鍵証明書を記憶していなければ、個別公開鍵証明書の正当性を確認することができない。ひいては、認証を行うことができない。
一方でルート鍵とルート私有鍵のペアは、安全性を保つため、有効期限を設け、所定期間毎に更新するものである。また、ルート私有鍵の漏洩が発覚した場合等にも更新を行う。そしてこの更新を行う場合、更新すべきルート私有鍵を用いたデジタル署名を付してある全ての公開鍵証明書について、新たなルート私有鍵を用いたデジタル署名を付した新たな公開鍵証明書を作成し、各発行先に配布して従前の公開鍵証明書と置きかえる。また、同時に新たなルート私有鍵と対応する新たなルート鍵証明書を作成して各発行先の通信相手となる全ての装置に配布する。
By the way, as is clear from the above description, even when each device transmits an individual public key certificate to the communication partner, the communication partner stores the individual root key certificate corresponding to the individual public key certificate. Otherwise, the validity of the individual public key certificate cannot be confirmed. As a result, authentication cannot be performed.
On the other hand, the pair of the root key and the root private key has an expiration date and is updated every predetermined period in order to maintain safety. It is also updated when a root private key leak is detected. When this update is performed, a new public key certificate with a digital signature using a new root private key is added to all public key certificates with a digital signature using the root private key to be updated. And distribute it to each issuer to replace the previous public key certificate. At the same time, a new root key certificate corresponding to the new private root key is created and distributed to all devices that are communication partners of each issue destination.
なお、このようにルート鍵及びルート私有鍵を更新する場合には、各装置の公開鍵及び私有鍵自体を更新する必要はなく、デジタル署名のみを作成し直せばよい。そこで、以下の説明において、ルート鍵及びルート私有鍵の更新を証明書のバージョンアップと呼び、公開鍵証明書及びルート鍵証明書は、デジタル署名の作成に使用したルート私有鍵の種類に応じたバージョンの証明書と呼ぶことにする。装置の公開鍵及び秘密鍵を更新する場合には、ルート鍵及びルート私有鍵は変更しないので、公開鍵証明書の内容は変化してもバージョンは変化しない。 When updating the root key and the root private key in this way, it is not necessary to update the public key and private key of each device, and only the digital signature needs to be recreated. Therefore, in the following explanation, updating the root key and root private key is called certificate upgrade, and the public key certificate and root key certificate depend on the type of root private key used to create the digital signature. Call it the version certificate. When updating the public key and private key of the device, the root key and the root private key are not changed, so the version does not change even if the contents of the public key certificate change.
ところで、このバージョンアップに伴う更新が全て正常に完了すれば、各装置は通信相手から受信する新たな個別公開鍵証明書の正当性を新たな個別ルート鍵証明書を用いて確認することができるので、認証及び通信に支障はない。
しかしながら、例えば個別ルート鍵の更新時にネットワークに接続されていなかった等の理由により、個別公開鍵証明書あるいは個別ルート鍵証明書の更新がなされなかった装置については、認証が正常に行えなくなり、通信ができなくなってしまう。これは、個別ルート鍵が更新された装置はもはや従前の個別ルート鍵証明書は記憶していないので、従前の個別公開鍵証明書の正当性を確認できなくなっているからである。また逆に、従前の個別ルート鍵しか記憶していない装置は、新たな個別公開鍵証明書の正当性を確認することができないため、証明書が更新されていない装置の側でも、更新されている装置を認証することができない状態になる。
By the way, if all the updates accompanying this version upgrade are completed normally, each device can confirm the validity of the new individual public key certificate received from the communication partner using the new individual root key certificate. Therefore, there is no problem in authentication and communication.
However, for devices that have not been updated with the individual public key certificate or individual root key certificate due to reasons such as not being connected to the network at the time of updating the individual root key, for example, authentication cannot be performed normally and communication is not possible. Will not be able to. This is because the device with the updated individual root key no longer stores the previous individual root key certificate, and thus cannot verify the validity of the previous individual public key certificate. Conversely, a device that only stores the previous individual root key cannot check the validity of the new individual public key certificate, so it is updated even on the device side where the certificate has not been updated. A device that cannot be authenticated is entered.
このような事態を防止するためには、個別ルート鍵を更新する場合でも従前の個別ルート鍵証明書を残しておくことも考えられなくはない。しかし、過去の全ての個別ルート鍵証明書を記憶しておくと記憶容量の増加につながる。そして、証明書の記憶には信頼性の高い記憶手段が必要でありコストが高いことを考えると、将来に亘って全てのルート鍵証明書を記憶できるだけの容量を用意することは、コスト面で問題がある。また、各装置が数多くの証明書を管理して認証に必要な証明書を適切に選択する必要が生じ、処理が複雑になるため、このような構成は現実的ではない。 In order to prevent such a situation, it is not considered that the previous individual root key certificate is left even when the individual root key is updated. However, storing all past individual root key certificates leads to an increase in storage capacity. Considering the fact that a highly reliable storage means is required for storing certificates and the cost is high, it is necessary to prepare a capacity that can store all the root key certificates in the future. There's a problem. Further, since each device needs to manage a large number of certificates and appropriately select a certificate necessary for authentication, and the processing becomes complicated, such a configuration is not practical.
また公開鍵証明書についても、SSLプロトコルにおいては、サーバは、クライアントから通信要求があった時点ではクライアントの状態を知ることができないため、必然的に、特定のURL(Uniform Resource Locator)にアクセスされた場合には常に同じ公開鍵証明書を返すことになる。従って、個別公開鍵証明書を複数持ち、通信相手の持つ個別ルート鍵証明書の種類に合わせて適当なものを選択して送信するといった構成を取ることはできない。サーバ側に個別公開鍵証明書の種類と同じだけの数のURLを設け、アクセスされたURLに応じて異なる個別公開鍵証明書を送信するようにすることは可能であるが、過去及び将来に使用されるルート鍵証明書の全てと対応する個別公開鍵証明書を使用可能とすることは、上述のルート鍵証明書の場合と同様、現実的ではない。
証明書管理装置20の場合は、証明書管理部26に過去に発行した証明書や鍵を全て記憶しておくが、この場合でも、これら全てを認証に使用できるようにすることは、あまり現実的ではない。
As for the public key certificate, in the SSL protocol, the server cannot know the state of the client when a communication request is made from the client. Therefore, a specific URL (Uniform Resource Locator) is inevitably accessed. Will always return the same public key certificate. Therefore, it is not possible to adopt a configuration in which a plurality of individual public key certificates are provided and an appropriate one is selected and transmitted according to the type of individual root key certificate possessed by the communication partner. It is possible to provide the same number of URLs as the types of individual public key certificates on the server side, and send different individual public key certificates according to the accessed URL. As in the case of the above-described root key certificate, it is not realistic to enable use of individual public key certificates corresponding to all of the root key certificates used.
In the case of the
また、認証が行えなくなる原因としては、上記のほか、証明書の更新の失敗による証明書の破損等も考えられるが、この場合には通信相手に従前の証明書を記憶させておいたとしても、対応は不可能である。
従って、上記のように個別公開鍵証明書を用いた認証が行えなくなっている装置を通信可能な状態にするためには、その装置に、通信相手が記憶している個別ルート鍵証明書と対応する個別公開鍵証明書及び、通信相手が記憶している個別公開鍵証明書と対応する個別ルート鍵証明書を記憶させる必要がある。
In addition to the above, the cause of the failure to authenticate may be a certificate damage due to a failed certificate update. In this case, even if the previous certificate is stored in the communication partner The correspondence is impossible.
Therefore, in order to make a device that can no longer be authenticated using an individual public key certificate as described above in a communicable state, the device corresponds to the individual root key certificate stored in the communication partner. It is necessary to store the individual public key certificate and the individual root key certificate corresponding to the individual public key certificate stored in the communication partner.
ここで、各装置が個別公開鍵証明書を用いた認証しか行えないとすると、この認証が行えなくなっている状態では、新たな個別公開鍵証明書や個別ルート鍵証明書をネットワークを介して安全に対象の装置に送信する方法はないことになる。しかし、この実施形態の通信システムを構成する各通信装置は、このような事態に対処するためにレスキュー認証情報を記憶しており、これを用いることにより、ネットワークを介して必要な装置に個別公開鍵証明書等を安全に送信できるようにしている。 Here, if each device can only perform authentication using an individual public key certificate, a new individual public key certificate or individual root key certificate can be securely transmitted via the network in a state where this authentication cannot be performed. There is no way to transmit to the target device. However, each communication device constituting the communication system of this embodiment stores rescue authentication information in order to cope with such a situation, and by using this, it is individually disclosed to necessary devices via the network. Key certificates etc. can be sent safely.
このレスキュー認証情報は、正規認証情報と概ね同様な構成となっており、例えば下位装置用共通公開鍵証明書は、証明書管理装置20が下位装置に対して発行した共通公開鍵に、下位装置認証用共通ルート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書であり、下位装置用共通私有鍵はその共通公開鍵と対応する私有鍵、下位装置認証用共通ルート鍵証明書は、下位装置認証用共通ルート鍵に自身を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。
The rescue authentication information has substantially the same configuration as the regular authentication information. For example, the low-level apparatus common public key certificate is assigned to the common public key issued by the
しかし、正規認証情報と大きく異なる点は、共通公開鍵証明書の書誌情報には装置の識別情報が含まれておらず、同じ階位の装置(図1及び図2に示した例では、証明書管理装置,上位装置,下位装置の階位が存在するものとする)には、全て同じ共通公開鍵証明書を記憶させる点である。この場合、同じ階位の各装置を個別に区別する必要がないので、証明書に含まれる共通公開鍵及びこれと対応する共通私有鍵も含めて、全く共通のものでよい。そして、通信相手の共通公開鍵証明書が全て同じであることから、ルート鍵証明書については、ある階位の装置の通信相手となる全ての装置について共通となる。すなわち、図18に示すように下位装置を複数設けた場合でも、全ての下位装置に同じレスキュー認証情報を記憶させることになる。 However, the main difference from the regular authentication information is that the bibliographic information of the common public key certificate does not include the device identification information, and the same rank device (in the example shown in FIGS. The same common public key certificate is stored in the document management device, the upper device, and the lower device). In this case, since it is not necessary to individually distinguish the devices at the same rank, the devices including the common public key included in the certificate and the common private key corresponding thereto may be completely common. Since all of the common public key certificates of the communication partners are the same, the root key certificate is common to all the devices that are communication partners of a certain rank device. That is, even when a plurality of lower devices are provided as shown in FIG. 18, the same rescue authentication information is stored in all the lower devices.
これは、上位装置30のレスキュー認証情報や証明書管理装置20のレスキュー認証情報についても同様である。
なお、個別公開鍵証明書とデータ形式を統一化する場合には、例えば図7に示した形式において機番として0を記載して共通公開鍵証明書であることを示すこと等も考えられる。
The same applies to the rescue authentication information of the
In the case of unifying the individual public key certificate and the data format, for example, it may be possible to describe the common public key certificate by writing 0 as the device number in the format shown in FIG.
このようなレスキュー認証情報は、同じ階位の装置について全て共通であるという特性から、装置の製造時にその機種に応じて定まる階位に応じたものを記憶させてしまうことができる。すなわち、装置の識別情報を付した情報ではないため、検査工程を終了して識別番号を付した各装置に対してそれぞれ個別の証明書を用意して記憶させる必要はなく、多数の装置に対して単純作業によって記憶させることができる。例えば、制御プログラムのマスタにレスキュー認証情報を含めておき、制御プログラムを装置にコピーする際にレスキュー認証情報も共に記憶させる等である。
そして、その後レスキュー認証情報を更新しないようにすれば、上記のように正規認証情報の更新が行えなかったり破損してしまったりして個別公開鍵証明書による認証が行えなくなった場合でも、レスキュー認証情報に含まれる共通公開鍵証明書を用いた認証は可能な状態を保つことができる。
Such rescue authentication information can be stored according to the rank determined according to the model at the time of manufacture of the device because of the characteristic that all the devices of the same rank are common. In other words, it is not information with device identification information, so it is not necessary to prepare and store individual certificates for each device with an identification number after completing the inspection process. Can be memorized by simple work. For example, rescue authentication information is included in the master of the control program, and the rescue authentication information is stored together when the control program is copied to the apparatus.
If you do not update the rescue authentication information after that, even if the regular authentication information cannot be updated or is damaged as described above, even if the authentication with the individual public key certificate cannot be performed, the rescue authentication Authentication using the common public key certificate included in the information can be kept possible.
ここで、共通公開鍵証明書には装置の識別情報を付していないため、共通公開鍵証明書を用いた認証を行った場合でも、通信相手の装置を具体的に特定することはできない。しかし、通信相手についてある程度の情報は得ることができる。
すなわち、例えばあるベンダーが自社製品のうち下位装置40に該当する装置全てに下位装置用のレスキュー認証情報(下位装置用共通公開鍵証明書,下位装置用共通私有鍵及び上位装置認証用共通ルート鍵証明書)を記憶させ、その通信相手となる上位装置30に該当する装置全てに上位装置用のレスキュー認証情報(上位装置用共通公開鍵証明書,上位装置用共通私有鍵及び下位装置認証用共通ルート鍵証明書)を記憶させておけば、下位装置40は、自己の記憶している上位装置認証用共通ルート鍵証明書で正当性を確認できる公開鍵証明書を送信してくる相手が同じベンダーの上位装置30であることを認識できるし、逆に上位装置30も自己の記憶している共通ルート鍵証明書で正当性を確認できる公開鍵証明書を送信してくる相手は同じベンダーの下位装置40であることを認識できる。
Here, since the identification information of the device is not attached to the common public key certificate, even if authentication using the common public key certificate is performed, the device of the communication partner cannot be specifically specified. However, some information about the communication partner can be obtained.
That is, for example, a certain vendor applies to all devices corresponding to the
そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を交換して共通鍵暗号を用いた安全な通信経路を設けることができるので、その後機種機番情報等を交換して通信相手を特定することも可能である。また、証明書管理装置20と上位装置30の間についても同様なことが可能である。
従って、個別公開鍵証明書を用いた認証が正常に行えなかった(失敗した)場合に、同じ通信相手に対して共通公開鍵証明書を用いた認証を試みることにより、個別公開鍵証明書を用いた認証における異常の有無を判断することができる。
すなわち、共通公開鍵証明書を用いた認証が成功すれば、相手が通信相手として想定している装置であることがわかるので、それでも認証が正常に行えなかったのは、個別公開鍵証明書を用いた認証に異常があるためと判断できる。
And if such authentication is successful, it is possible to establish a secure communication path using common key encryption by exchanging the common key with the communication partner as described above, and then the model number information etc. It is also possible to specify a communication partner by exchanging. The same can be done between the
Therefore, when the authentication using the individual public key certificate cannot be normally performed (failed), the individual public key certificate is obtained by attempting the authentication using the common public key certificate for the same communication partner. Whether there is an abnormality in the used authentication can be determined.
That is, if the authentication using the common public key certificate is successful, it can be understood that the other party is the device that is assumed as the communication partner. It can be determined that there is an abnormality in the authentication used.
また、共通公開鍵証明書を用いた認証が失敗すれば、相手が通信相手として想定していない装置であることがわかるので、個別公開鍵証明書を用いた認証が正常に行えなかったのは通信相手が不適切だったからで、認証に異常が発生したわけではないと判断できる。個別公開鍵証明書と共通公開鍵証明書の2種類のデジタル証明書を利用してこのような判断を行う点が、この実施形態の特徴の1つである。
なお、認証が失敗する原因としては通信の障害も考えられるが、この場合には証明書等の受信の段階で異常がわかるため、証明書等の内容が不適切だった場合とは区別することができる。
Also, if the authentication using the common public key certificate fails, it can be seen that the other party is not supposed to be the communication partner, so the authentication using the individual public key certificate could not be performed normally. It can be determined that an abnormality has not occurred in the authentication because the communication partner was inappropriate. One of the features of this embodiment is that such a determination is made using two types of digital certificates, that is, an individual public key certificate and a common public key certificate.
In addition, communication failure can be considered as a cause of authentication failure, but in this case, since the abnormality is known at the stage of receiving the certificate, etc., it should be distinguished from the case where the contents of the certificate etc. are inappropriate. Can do.
ここで、図1及び図2に示した各装置が個別公開鍵証明書と共通公開鍵証明書とを使い分けるための構成を、図8に示す。図8には上位装置30と下位装置40のみを示すが、証明書管理装置20についても同様な構成が可能である。
上述した通り、サーバは通信を要求してくるクライアントに対して特定の公開鍵証明書しか返すことができない。しかし、通信要求に係るURLが異なる場合には、URL毎に異なる公開鍵証明書を返すことも可能である。
Here, FIG. 8 shows a configuration for each apparatus shown in FIGS. 1 and 2 to use the individual public key certificate and the common public key certificate properly. Although FIG. 8 shows only the
As described above, the server can return only a specific public key certificate to a client requesting communication. However, if the URLs related to the communication request are different, different public key certificates can be returned for each URL.
従ってここでは、図8に示すように、上位装置30及び下位装置40にそれぞれ、個別公開鍵証明書による認証を行う通常URLと共通公開鍵証明書による認証を行うレスキューURLとを設け、通信を要求する側(クライアントとして機能する側)が、要求する認証の種類に応じていずれかのURLを選択的に指定して通信要求を送るようにしている。これらのURLは、IPアドレスやポート番号(いずれか一方でもよい)を変えることにより、物理的には同じ装置のURLであっても、論理的には異なる装置のURLとして取り扱うことができるようにしている。すなわち、いわゆるバーチャルサーバの機能を実現するためのものである。
Therefore, as shown in FIG. 8, the
このようにした場合、通信を要求される側(サーバとして機能する側)は、返す証明書を通信要求を受け付けたURLによって区別し、通常URLで受け付けた場合には個別公開鍵証明書を返し、レスキューURLで受け付けた場合には共通公開鍵証明書を返すことができる。
なお、通信を要求するクライアントの側では、どのURLに対して通信要求を送ったかがわかるので、相互認証を行う場合にはURLに応じた適切な公開鍵証明書を選択して送信することができる。
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 returns the individual public key certificate when it is received as a normal URL. When the rescue URL is accepted, the common public key certificate can be returned.
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. .
ところで、上記のように共通公開鍵証明書を用いた認証の成功によって個別公開鍵証明書を用いた認証に異常があると判断した場合、その異常の原因としては、通信相手の正規認証情報が通信要求元の正規認証情報と対応していないか、あるいは通信相手の正規認証情報が破損していることが考えられる。共通公開鍵証明書を用いた認証が成功しているため、通信や認証処理シーケンス自体の異常は考えにくいためである。
そこで、図1及び図2に示した通信システムにおいては、上位装置30に、共通公開鍵証明書を用いた認証が成功した場合に下位装置40の正規認証情報を更新する機能を設けている。この点も、この実施形態の特徴である。
By the way, when it is determined that there is an abnormality in the authentication using the individual public key certificate due to the success of the authentication using the common public key certificate as described above, the cause of the abnormality is the normal authentication information of the communication partner. It can be considered that it does not correspond to the regular authentication information of the communication request source, or that the regular authentication information of the communication partner is damaged. This is because the authentication using the common public key certificate has been successful, and it is difficult to think of an abnormality in the communication and the authentication processing sequence itself.
Therefore, in the communication system shown in FIGS. 1 and 2, the
すなわち、上位装置30は下位装置40に対して通信を要求する場合、まず通常URLに通信要求を送信して個別公開鍵証明書を用いた認証を行うが、これが失敗した場合に、今度はレスキューURLに通信要求を送信して共通公開鍵証明書を用いた認証を行う。そして、これが成功した場合、更新用(あるいは新規記憶用)の証明書セットを証明書管理装置20から取得し、下位装置40に送信してこれを記憶するよう要求するようにしている。共通公開鍵証明書を用いた認証であっても、共通鍵の交換は個別公開鍵証明書の場合と同様に可能であるから、証明書セットの送信は交換した共通鍵を用いて暗号化して安全に行うことができる。
In other words, when the
なお、この証明書セットの構成は図9に示すものである。そして、このうち下位装置用個別公開鍵証明書の作成に用いるルート私有鍵は、取得の時点で上位装置30に記憶している下位装置認証用個別ルート鍵証明書に含まれるルート鍵と対応するものであるし、上位装置認証用個別ルート鍵証明書は、同じく上位装置30に記憶している上位装置用個別公開鍵証明書に付されているデジタル署名の正当性を確認できるルート鍵証明書を含むものである。従って、下位装置40に、古いルート私有鍵を用いて作成された個別公開鍵証明書が記憶されていた場合には、更新用の証明書セットには新しいルート私有鍵を用いて作成された新しいバージョンの下位装置用公開鍵証明書や、新しいバージョンの上位装置認証用個別ルート鍵証明書が含まれることになる。
なお、下位装置用個別公開鍵証明書中の公開鍵本体や、下位装置用個別私有鍵については、新たに生成してもよいが、証明書管理装置20において、過去に下位装置40に対して発行した鍵を管理しているのであれば、その鍵をそのまま使うようにしてもよい。また、更新用の証明書セットを発行する際に、ルート私有鍵を新たに発行し、公開鍵証明書のバージョンアップを行うようにすることも考えられる。
The configuration of this certificate set is shown in FIG. Of these, the root private key used to create the individual public key certificate for the lower apparatus corresponds to the root key included in the individual root key certificate for lower apparatus authentication stored in the
Note that the public key body in the individual public key certificate for the lower level device and the individual private key for the lower level device may be newly generated. If the issued key is managed, the key may be used as it is. Also, when issuing a certificate set for renewal, it is possible to issue a new root private key and upgrade the public key certificate.
一方、下位装置40は、上記の要求を受けた場合に、受信した証明書セットを証明書更新部48によって証明書記憶部45に記憶させ、従前の正規認証情報を更新するようにしている。
この更新が正常に行われれば、上位装置30と下位装置40とには互いに個別公開鍵証明書の正当性を確認可能な個別ルート鍵証明書が記憶されることになり、個別公開鍵証明書を用いた認証を行うことができる状態になる。従ってこの後は、個別公開鍵証明書を用いた認証を行って通信を実行するようにすればよい。
On the other hand, when the
If this update is carried out normally, the
なお、図5及び図6に示した認証情報において、個別ルート鍵証明書は認証対象によらず同じものを用いるようにしてもよい(例えば上位装置認証用ルート鍵証明書と下位装置認証用ルート鍵証明書が同じものでもよい)。これは、個別証明書には装置の識別情報が付されているため、ルート鍵証明書を用いてその正当性を確認できれば、あとはその識別情報を参照して装置の機種や階位を特定できるためである。一方、共通証明書には装置の識別情報が付されていないため、その種類の区別は特定のルート鍵証明書で正当性を確認できるか否かによって行うことになる。従って、共通ルート鍵証明書は区別すべき認証対象のグループ毎に異なるようにするとよい。 In the authentication information shown in FIG. 5 and FIG. 6, the same individual root key certificate may be used regardless of the authentication target (for example, the upper device authentication root key certificate and the lower device authentication route). The key certificate may be the same). This is because the identification information of the device is attached to the individual certificate, so if the validity can be confirmed using the root key certificate, the device model and rank are identified with reference to the identification information. This is because it can. On the other hand, since the identification information of the apparatus is not attached to the common certificate, the type is distinguished depending on whether the validity can be confirmed with a specific root key certificate. Therefore, the common root key certificate may be different for each group to be authenticated.
次に、このような個別証明書と共通証明書の2種類の証明書を用いた異常の検出及び証明書の更新に関する処理について説明する。図10のフローチャートに上位装置30側の処理を、図11のフローチャートに下位装置40側の処理を示す。これらの処理は、上位装置30及び下位装置40のCPUがそれぞれ所要の制御プログラムを実行して行うものであり、この発明の異常検知方法及び証明書送信方法に係る処理である。
なお、これらのフローチャートにおいては、上位装置30が下位装置40に対して通信を要求する場合の処理を示している。また、説明を簡単にするため、認証処理としては上位装置30が下位装置40から受信した公開鍵証明書を用いて下位装置40を認証する部分のみを示している(図21に示したような片方向認証を行う場合の処理を示している)が、上位装置30から下位装置40にも公開鍵証明書を送信し、図19に示したような双方向認証を行うようにしてもよいことはもちろんである。
Next, processing related to abnormality detection and certificate update using two types of certificates, such as individual certificates and common certificates, will be described. The flowchart of FIG. 10 shows the processing on the
Note that these flowcharts show processing in a case where the
上位装置30は、下位装置40に対して要求や通知を送信したり、下位装置40からの要求や通知を受け取るために通信要求を行ったりする場合、図10のフローチャートに示す処理を開始し、まずステップS101で下位装置40の通常URLに対して通信要求を送信する。なお、上位装置30は通信相手となる装置全てについて、通信要求先として通常URLとレスキューURLとを記憶しているものとする。
When the
そして、下位装置40は、通信要求を受けると図11のフローチャートに示す処理を開始し、ステップS201で通信要求のあったURLが通常URLかレスキューURLかを判断する。
そして、通常URLへの通信要求であれば、ステップS202に進んで個別公開鍵証明書を記憶しているか否か判断する。通常は図5(a)に示したように個別公開鍵証明書(下位装置個別公開鍵証明書)を記憶しているはずであるが、更新時に誤って消去されてしまったり、製品出荷時に個別公開鍵証明書を記憶させていなかったりした場合には、この判断がNOになる場合もある。
Upon receiving the communication request, the
If it is a communication request for a normal URL, the process proceeds to step S202 to determine whether or not the individual public key certificate is stored. Normally, the individual public key certificate (subordinate device individual public key certificate) should be stored as shown in Fig. 5 (a), but it may be deleted by mistake when updated, or individually at the time of product shipment. If the public key certificate is not stored, this determination may be NO.
ステップS202で記憶していれば、ステップS203で個別公開鍵証明書を個別私有鍵(下位装置個別私有鍵)で暗号化した第1の乱数と共に上位装置30に送信する。この処理は、図19又は図21のステップS21及びS22の処理に相当する。
また、ステップS202で記憶していなければ、ステップS211で個別証明書を送信できない旨の応答を返して処理を終了する。
If stored in step S202, the individual public key certificate is transmitted to the
If not stored in step S202, a response indicating that the individual certificate cannot be transmitted is returned in step S211 and the process ends.
上位装置30側では、これらのいずれかの応答を受け取るか、あるいは所定時間経過すると、ステップS102に進んで下位装置40が公開鍵証明書を送信してきたか否か判断する。そして、送信してきていれば、ステップS103に進んで認証処理を行う。ここでの認証には、下位装置認証用個別ルート鍵証明書を使用し、この処理は、図19又は図21のステップS12及びS13の処理に相当する。また、ステップS101乃至S103の処理において、上位装置30のCPUが第1の認証手段として機能する。
そして、ステップS104で認証が成功したか否か判断し、成功していればステップS113に進んで共通鍵の種を下位装置40に送信すると共に共通鍵を作成して以後の通信に使用するようにする。この処理は、図19又は図21のステップS14乃至S17の処理に相当する。
On the higher-
In step S104, it is determined whether or not the authentication is successful. If the authentication is successful, the process proceeds to step S113, where the common key seed is transmitted to the
下位装置40側では、ステップS203で個別公開鍵証明書を送信した場合にはステップS204でこの送信を待ち、共通鍵の種を受信した場合には上位装置30に認証されたと判断し、ステップS205に進んで共通鍵を作成して以後の通信に使用するようにする。これらの処理は、図19のステップS23乃至S26あるいは図21のステップS25及びS26の処理に相当する。
また、上位装置30側では、ステップS113の後、ステップS114で下位装置40に対して要求(コマンド)を必要なデータと共に送信し、ステップS115でその応答を待つ。そして、ステップS116で要求を全て送信したか否か判断し、まだ残っていればステップS114に戻って処理を繰り返し、全て送信していればステップS117に進んで通信を切断して処理を終了する。
On the
On the
下位装置40側では、ステップS205の後はステップS206に進んで上位装置30から要求を受信したか否か判断し、受信した場合にはステップS207で要求に応じた処理を行って上位装置30に応答を返す。また、ステップS208ではコールや定期通知等の上位装置30に通知すべき情報をがあるか否かを判断し、あればステップS209で通知を送信する。そして、ステップS210で上位装置30が通信を切断したか否か判断し、切断していなければステップS206に戻って処理を繰り返すが、切断していれば処理を終了する。
On the
一方、上位装置30側の処理においてステップS104で認証が失敗した場合、認証失敗の原因としては、公開鍵証明書バージョンがルート鍵証明書と合わずに正当性が確認できなかった、公開鍵証明書の有効期限が切れていた、公開鍵証明書が破損していた、そもそも全く関係ない装置と通信しようとしていた、公開鍵証明書に付された識別情報が通信相手として不適切な装置のものであった等が考えられる。
そして、次のステップS105では、その原因が公開鍵証明書に付された識別情報が通信相手として不適切な装置のものであったためか否かを判断し、この判断がYESであれば処理を終了する。なお、その他の原因でもこの時点で処理を終了してしまうようにする方がよい場合も考えられる。例えば、ステップS101での通信要求に全く応答がなかった場合や、認証処理に対応していない旨の応答を返してきた場合には、通信相手は上位装置30と全く関係ない装置であることが考えられるので、このような場合にはステップS105の時点で処理を終了させてしまうようにしてもよい。
On the other hand, when the authentication fails in step S104 in the process on the
Then, in the next step S105, it is determined whether or not the cause is that the identification information attached to the public key certificate is that of an inappropriate device as a communication partner. If this determination is YES, processing is performed. finish. Note that there may be a case where it is better to end the processing at this point for other reasons. For example, if there is no response to the communication request in step S101, or if a response indicating that the authentication process is not supported is returned, the communication partner may be a device that has nothing to do with the
ステップS106以降の処理は、個別公開鍵証明書を用いた認証が正常に行えなかった場合にその原因を把握して必要な場合に通信相手に適当なデジタル証明書を記憶させる処理であるところ、ステップS104での認証失敗の原因が識別情報が不適切なものであったことであれば、証明書や認証処理の課程が正常であったことは明らかであるので、改めて確認を行う必要はなく、また証明書を更新したとしても状況が改善することもなく、ステップS106以降の処理を行う必要がないためである。この場合、ステップS101で通信要求を送信したURLには以後通信を要求しないようにするとよい。 The processing after step S106 is processing for grasping the cause when authentication using the individual public key certificate cannot be normally performed and storing an appropriate digital certificate in the communication partner when necessary. If the cause of the authentication failure in step S104 is that the identification information is inappropriate, it is clear that the certificate and the authentication process were normal, so there is no need to confirm again. In addition, even if the certificate is updated, the situation does not improve, and it is not necessary to perform the processing after step S106. In this case, it is preferable that communication is not requested thereafter for the URL to which a communication request is transmitted in step S101.
一方、ステップS105の判断がNOである場合には、公開鍵証明書が適当なものでなかったため認証処理が正常に行えなかったと考えられるため、その原因を把握すべくステップS106に進んで以降の処理を行う。ステップS102で下位装置40が公開鍵証明書を送信してこなかった場合も同様である。
ステップS106では、通常URLでの通信ができないことがわかっているので、今度は下位装置40のレスキューURLに対して通信要求を送信する。
On the other hand, if the determination in step S105 is NO, it is considered that the authentication process could not be performed normally because the public key certificate was not appropriate, and the process proceeds to step S106 to grasp the cause. Process. The same applies to the case where the
In step S106, since it is known that communication using the normal URL is not possible, a communication request is transmitted to the rescue URL of the
この場合には、下位装置40は改めて図11のフローチャートに示した処理を開始するが、ステップS201の判断はレスキューURLとなり、ステップS212に進んで、下位装置用共通公開鍵証明書を、共通私有鍵(下位装置用共通私有鍵)で暗号化した第1の乱数と共に上位装置30に送信する。この処理も、ステップS203の場合と同様図19又は図21のステップS21及びS22の処理に相当する。共通公開鍵証明書は、個別公開鍵証明書と異なり、装置の製造時に記憶させた後は更新しないので、下位装置40として適当な装置であれば必ず適当なものを記憶しているはずである。記憶手段が破損した場合等はこの限りではないが、この場合でも同じ共通公開鍵証明書を記憶させた部品に交換すればよい。共通公開鍵証明書は装置毎に異なるものではないので、このような交換部品を用意することは容易である。
In this case, the lower-
上位装置30側では、ステップS107で下位装置40がステップS212で送信した証明書と乱数を受信すると、これを用いて認証処理を行う。ここでの認証には、下位装置認証用共通ルート鍵証明書を使用し、この処理は、ステップS102及びS103の場合と同様、図19又は図21のステップS12及びS13の処理に相当する。なお、ステップS106の後所定時間内に受信しない場合には認証失敗として取り扱うようにしてもよい。また、ステップS106及びS107の処理において、上位装置30のCPUが第2の認証手段として機能する。
On the
そして、ステップS108で認証が成功したか否か判断し、成功していればステップS109に進んで共通鍵の種を下位装置40に送信すると共に共通鍵を作成して以後の通信に使用するようにする。これらの処理は、ステップS104及びS114の場合と同様、図19又は図21のステップS14乃至S17の処理に相当する。
下位装置40側では、ステップS212の後ステップS213でこの送信を待ち、共通鍵の種を受信した場合には上位装置30に認証されたと判断し、ステップS214に進んで共通鍵を作成して以後の通信に使用するようにする。これらの処理は、ステップS204及びS205の場合と同様、図19のステップS23乃至S26あるいは図21のステップS25及びS26の処理に相当する。
In step S108, it is determined whether or not the authentication is successful. If the authentication is successful, the process proceeds to step S109 where the common key seed is transmitted to the
The
一方、上位装置30側では、ステップS108で共通公開鍵証明書を用いた認証が成功したことにより、下位装置40との間の個別公開鍵証明書を用いた認証に異常があると判断する。このステップS108の処理において、上位装置30のCPUが異常検知手段としても機能する。そして、下位装置40の証明書を更新すべく、ステップS109の次にステップS110で、証明書管理装置20に必要な情報を送信して更新用の新証明書セットを作成させ、これを取得するが、この処理の説明については後に詳述する。
On the other hand, the higher-
上位装置30は、証明書管理装置20から新証明書セットを取得すると、ステップS111で下位装置40に証明書更新要求と共にその新証明書セットを送信し、記憶している(あるいは存在しなかった)正規認証情報を、新証明書セットの内容に更新するよう要求する。この処理において、上位装置30のCPUが個別証明書送信手段として機能する。
そして、ステップS112で下位装置40からの応答を待ってステップS117に進み、通信を切断して処理を終了する。始めに送信しようとしていた要求等を送信する場合には、再度処理を開始すればよいが、この時点では個別公開鍵証明書による認証が可能になっているはずであるので、ステップS104からS113に進み、以降の処理で下位装置40に要求を送信してこれに係る動作を実行させることが可能である。
When acquiring the new certificate set from the
Then, in step S112, the process waits for a response from the
一方、下位装置40側では、ステップS214の後はステップS215で要求の受信を待ち、要求を受信するとステップS216に進む。そして、図4を用いて説明したように、下位装置40の要求管理部44は、共通公開鍵証明書を用いた認証を行った場合には、証明書更新動作のみを許可するようにしているので、ステップS216で受信した要求が証明書更新要求か否かを判断する。そして、証明書更新要求でなければその要求は無視してステップS215に戻って次の要求を待つ。ここで、要求を受け付けられない旨の応答を返すようにしてもよい。
ステップS216で証明書更新要求であれば、ステップS217に進んで証明書更新要求と共に受信した新証明書セットを証明書記憶部45に記憶させて図5(a)に示した正規認証情報をその内容に更新し、ステップS218で更新結果を応答として送信元に通知して処理を終了する。
On the other hand, on the
If it is a certificate renewal request in step S216, the process proceeds to step S217, the new certificate set received together with the certificate renewal request is stored in the
次に、上位装置30及び下位装置40が図10及び図11に示した処理を実行する場合の処理シーケンスの例を、証明書管理装置20における処理も含めて説明する。図12及び図13にこの処理シーケンスを示す。なおここでは、下位装置40に記憶している下位装置用個別公開鍵証明書のバージョンが古く、上位装置30に記憶している下位装置認証用個別ルート鍵証明書を用いて正当性が確認できない状態になっていた場合の処理例を示す。
Next, an example of a processing sequence in the case where the higher-
この例においては、まず上位装置30が、HTTPSクライアント機能部31を対下位装置クライアントとして機能させて、下位装置40の通常URLに通信要求を送信する(S301)。この場合、下位装置40側で要求を受けるのはHTTPSサーバ機能部42であり、認証処理部43にこの要求を伝える。また、下位装置40は個別証明書を用いた認証を要求されたことになる。そして認証処理部43は、SSLプロトコルに従い、証明書記憶部45に記憶している下位装置用個別私有鍵で暗号化した乱数と共に、同じく証明書記憶部45に記憶している下位装置用個別公開鍵証明書を上位装置30に返す(S302)。
In this example, first, the higher-
上位装置30側では、これを認証処理部33に渡して認証処理を行うが、ここでは受信した下位装置用個別公開鍵証明書は、証明書記憶部35に記憶している下位装置認証用個別ルート鍵証明書とバージョンが異なり、このルート鍵証明書を用いて正当性を確認できないため、認証失敗と判断し(S303)、下位装置40に対して認証失敗応答を返す(S304)。ただしこの時点では、上位装置30は、通信を要求した相手が本当に下位装置40であるか否かは認識できていない。
そして、認証失敗の原因が公開鍵証明書の正当性が確認できなかったことであるので、通信を要求した通常URLに係る装置が通信相手として適当でありうる装置であるか否かを調査するため、レスキューURLに通信要求を送信する(S305)。
On the
Since the cause of the authentication failure is that the validity of the public key certificate could not be confirmed, it is investigated whether the device related to the normal URL that requested communication is a device that can be suitable as a communication partner. Therefore, a communication request is transmitted to the rescue URL (S305).
下位装置40側では、この要求はステップS301の場合と同様に認証処理部43に伝えられるが、今度は下位装置40は共通証明書を用いた認証を要求されたことになる。そして認証処理部43は、SSLプロトコルに従い、証明書記憶部45に記憶している下位装置用共通私有鍵で暗号化した乱数と共に、同じく証明書記憶部45に記憶している下位装置用共通公開鍵証明書を上位装置30に返す(S306)。
上位装置30側では、これを認証処理部33に渡して認証処理を行うが、ここでは下位装置40は上位装置30の通信相手となりうる装置であるから、下位装置用共通公開鍵証明書は上位装置30に記憶している下位装置認証用ルート鍵証明書を用いて正当性を確認できるものであり、かつ乱数の復号化も問題なく行うことができ、認証成功と判断する(S307)。
On the
On the higher-
そして上位装置30は、片方向認証の場合には下位装置用共通公開鍵証明書に含まれる公開鍵で暗号化した共通鍵の種を下位装置40のレスキューURLに返す(S308)。相互認証を行う場合には、ここで第2の乱数を証明書記憶部35に記憶している上位装置用共通私有鍵を用いて暗号化し、上位装置用共通公開鍵証明書と共に返す。
In the case of one-way authentication, the
下位装置40は、これを認証処理部43に渡して共通鍵の種を下位装置用共通私有鍵を用いて復号化し、相互認証の場合にはさらに上位装置用共通公開鍵証明書の正当性を上位装置認証用ルート鍵証明書を用いて確認した後第2の乱数をここに含まれる公開鍵を用いて復号化することによって認証処理を行う。そして、ここではこれらを正常に行うことができるので、認証成功と判断し(S309)、上位装置30に認証成功応答を返す(S310)。そしてその後、上位装置30と下位装置40はステップS308で送受信した共通鍵の種を用いて共通鍵を生成する(図示省略)。
The
一方、上位装置30は、ステップS310の応答を受信すると、ステップS301で通信を要求した相手は正当な通信相手でありうる装置であり、通信や認証処理の課程には特に異常がないことがわかる。また一方で、ステップS303において、認証処理が失敗したのは通信異常等のためでなく、下位装置40から受信した個別公開鍵証明書の正当性を確認できなかったことはわかっているから、個別公開鍵証明書を用いた認証が失敗したのは、下位装置40が記憶しているべき証明書の異常に起因して認証に異常が発生しているためであると判断する(S311)。すなわち、本来個別公開鍵証明書を用いた認証が成功するはずの装置であるので、証明書に異常がある(又は証明書を記憶していない)ために認証が失敗していると判断する。
On the other hand, when the
そして、図13に示す続きの処理に進み、HTTPSクライアント機能部31を対CAクライアントとして機能させて、証明書管理装置20に対して個別証明書発行要求と共に下位装置40の機番,IPアドレス及びMACアドレスを送信して、下位装置40用の新たな証明書セットの作成を要求する(S312)。
なお、ここで証明書管理装置20に送信する情報は、通信相手の情報として上位装置30が予め記憶しておくようにしてもよいし、共通公開鍵証明書による認証が成功した後で下位装置40に送信させて取得するようにしてもよい。また、証明書セットは図9に示した各証明書及び私有鍵を含むが、片方向認証を行う場合には上位装置認証用個別ルート鍵証明書は必要ない。また、図示は省略したが、上位装置30と証明書管理装置20とが通信する場合も、上位装置30と下位装置40とが通信する場合と同様、個別証明書を用いてSSLプロトコルに従った認証処理を行い、安全な通信経路を確立してから要求等を送信するものとする。
Then, the processing proceeds to the subsequent processing shown in FIG. 13, by causing the HTTPS
Here, the information to be transmitted to the
証明書管理装置20は、ステップS312の要求を受けると、証明書セット及びその設定要求を作成する(S313)が、証明書管理装置20は上位装置30が記憶している下位装置認証用個別ルート鍵証明書のバージョンを管理しているので、このルート鍵証明書で正当性を確認可能なデジタル署名を付し、下位装置40の識別情報として機番を含む個別公開鍵証明書を作成することができる。この場合において、証明書管理装置20が、上位装置30から受信した機番とIPアドレス及びMACアドレスを、自身が管理している情報と照合し、個別公開鍵証明書の発行先が適切な装置であることを確認できるようにしてもよい。
また、証明書管理装置20は下位装置40に対して発行した公開鍵や私有鍵も記憶していることから、これらの鍵自体は更新せず、デジタル署名のみを変更して新たな証明書を作成することも可能である。また、上位装置30に対して発行した上位装置個別公開鍵証明書に付したデジタル署名のバージョンも管理しているので、このデジタル署名の正当性を確認できるような上位装置認証用個別ルート鍵証明書を作成することができる。このとき、デジタル署名に用いるルート私有鍵を新たに生成し、ルート鍵証明書の更新も同時に行うようにしてもよいことは、上述した通りである。そして、ここで作成した新たな各証明書及び鍵も、それまでの証明書等と同様、証明書管理部26に記憶させて管理する。
Upon receiving the request in step S312, the
Further, since the
上位装置30は、ステップS312の要求を送信した後、証明書の作成が完了した頃に証明書管理装置20に対して通信要求を行い、証明書管理装置20から上位装置30への要求の有無を問い合わせる(S314)。このとき、ステップS313の処理が完了していれば、証明書管理装置20は通信要求に対する応答として、証明書設定要求と共に、新証明書セット,これを記憶させる下位装置40のIPアドレス及びMACアドレスを上位装置30に返す(S315)。すなわち、上位装置30は証明書設定要求と共に、下位装置40に記憶させるべき新証明書セットを取得することができる。
After transmitting the request in step S312, the
上位装置30はこの要求を受けると、指定されたIPアドレスのレスキューURLに対して証明書更新要求と共に新証明書セットを送信する(S316)。このとき、まず送信先からMACアドレスを取得し、証明書設定要求に記載されていたMACアドレスと一致していることを確認してから新証明書セットを送信するようにしてもよい。
一方、下位装置40は受信した証明書更新要求をHTTPSサーバ機能部42から要求管理部44に伝え、要求管理部44が証明書更新部48に証明書更新処理を実行させて、証明書記憶部45に記憶している正規認証情報を受信した新証明書セットの内容に更新する(S317)。そして、更新処理の結果を示す証明書更新要求応答を上位装置30に返し(S318)、上位装置30はその応答を基に証明書管理装置20に証明書設定要求に対する応答を返す(S319)。そして以上で一旦処理を終了する。
なお、上位装置30と下位装置40との間の通信は、ステップS310の後で一旦切断し、ステップS316の送信を行う際に改めてレスキューURLに対して通信要求を送信して認証を行うようにするとよい。
Upon receiving this request, the
On the other hand, the
Note that the communication between the higher-
ところで、これ以降の処理は図10及び図11のフローチャートでは図示を省略したが、以上のような証明書の更新が終了すると、下位装置40は、HTTPSクライアント機能部41を対上位装置クライアントとして機能させ、上位装置30の通常URLに対して通信要求を送信する。そして、更新処理の結果を通知する証明書更新結果通知と共に、機番,IPアドレス,更新後の証明書セットのバージョン情報を通知する(S321)。上位装置30は、この通知に対して応答を返す(S322)。この通信の際には個別公開鍵証明書を用いた認証を行うが、新証明書セットに含まれる証明書を用いれば、この認証は問題なく行うことができる。
By the way, although the subsequent processing is not shown in the flowcharts of FIGS. 10 and 11, when the certificate update as described above is completed, the lower-
さらに、上位装置30は、ステップS321の通知を受けると、下位装置の通常URLに対して通信要求を送信し、下位装置40の再検索を行う(S331)。これは、上位装置30側から通信を要求する際にも個別証明書を用いた認証が成功し、通信が正常に行えることを確認するためのものである。下位装置40はこれに対して応答を返す(S332)。
この応答を受信すると、上位装置30は証明書の更新が成功し、その結果個別証明書を用いた認証の異常が解消したことを確認でき、ステップS321で受信した証明書更新結果通知及びその付属情報を証明書管理装置20に送信して更新処理が成功したことを通知する(S333)。証明書管理装置20はこれに対して応答を返す(S334)。
Further, upon receiving the notification in step S321, the higher-
Upon receiving this response, the
図1及び図2に示した通信システムにおいては、下位装置40における正規認証情報を構成する証明書のバージョンが上位装置30のそれと合わずに認証が正常に行えない場合、以上の処理により、下位装置の証明書を更新して認証が正常に行えるようにしている。
In the communication system shown in FIG. 1 and FIG. 2, when the version of the certificate constituting the regular authentication information in the
また、上述した構成を有する上位装置30と下位装置40が以上ような処理を実行することにより、通常の場合は通信を要求する場合に個別公開鍵証明書を用いた認証を行い、通信相手を特定して認証を行い、SSLによる安全な通信経路を確立できる一方、個別公開鍵証明書を用いた認証が正常に行えなかった場合には、共通公開鍵証明書を用いた認証を行い、これが成功した場合に個別公開鍵証明書を用いた認証の失敗は認証の異常が原因であると判断できる。従って、速やかに異常の解消に向けた動作を行うことができる。
また、共通公開鍵証明書を用いた認証のみが成功した場合には、下位装置用公開鍵証明書を始めとする、下位装置40に記憶している正規認証情報の異常が原因であると推測できるため、共通公開鍵証明書を用いた認証が成功した場合に上位装置30が新証明書セットを取得して下位装置40に送信し、正規認証情報を更新させることにより、速やかに異常の解消を図ることができる。
In addition, when the
Also, if only the authentication using the common public key certificate succeeds, it is assumed that the cause is an abnormality of the regular authentication information stored in the
さらに、共通公開鍵証明書を用いた認証により、送信先が通信相手として適当な装置であることを確認してから新証明書セットを送信することができるので、証明書セットを誤って不適当な装置に記憶させてしまうことがない。相互認証を行う場合には、下位装置40側でも、新証明書セットの送信元が上位装置30であることを確認して受信することができるので、正規認証情報として不正な証明書を記憶してしまうことがない。さらにまた、個別公開鍵証明書を用いた認証が行えない場合でも共通公開鍵証明書を用いた認証が可能であることから、新証明書セットをSSLを用いた安全な通信経路で送信することができるので、内容が第3者に漏れることがなく、セキュリティを維持できる。
In addition, the new certificate set can be sent after confirming that the destination is an appropriate device as the communication partner by authentication using the common public key certificate. It will not be stored in a new device. When mutual authentication is performed, the
また、下位装置40が、共通公開鍵証明書を用いて認証した相手からの要求は、証明書の更新要求以外は受け付けないようにしているので、その他の情報については、個別公開鍵証明書によって認証した適当な通信相手のみにアクセスを許可することができ、共通公開鍵証明書によって通信相手を特定できなくても重要な情報に不正にアクセスされることを防止できる。
Further, since the lower-
〔実施形態の変形例:図14乃至図17〕
次に、上述した実施形態についての種々の変形例について説明する。
ここまでの説明では、個別証明書を用いた認証が正常に行えず、共通証明書を用いた認証が成功した場合に下位装置40の正規認証情報を更新する例について説明した。ここで下位装置40の正規認証情報を更新するようにしたのは、この実施形態の通信システムにおいて上位装置30は1つであるのに対し、下位装置40は上位装置30に複数接続可能であり、着脱も可能であることから、下位装置40の方が管理を行い難く、そのためバージョン不一致等の異常も発生しやすいためである。また、上位装置30の正規認証情報を更新してしまうと、共通証明書で認証した下位装置40以外の下位装置に対する認証に不具合が生じてしまう可能性が高いためでもある。
[Modifications of Embodiment: FIGS. 14 to 17]
Next, various modifications of the above-described embodiment will be described.
In the description so far, the example has been described in which the authentication using the individual certificate cannot be normally performed and the normal authentication information of the
しかし、上位装置30の正規認証情報に異常がある場合も考えられることから、下位装置40の正規認証情報を更新しても認証の異常が解消しない場合には、上位装置30は自身の正規認証情報の更新を試みるようにしてもよい。また、上位装置30が自身の正規認証情報に異常があることを検知した場合には、初めから自身の正規認証情報の更新を試みるようにするとよい。
However, since there may be an abnormality in the normal authentication information of the higher-
この場合の処理シーケンスの例を図14に示す。
この場合には、まずHTTPSクライアント機能部31を対CAクライアントとして機能させて、証明書管理装置20に対して個別証明書発行要求と共に自身の機番情報を送信して、自身用の新たな証明書セットの作成を要求する(S401)。このときも個別証明書を用いてSSLプロトコルに従った認証処理を行い、安全な通信経路を確立してから要求等を送信するが、上位装置30の正規認証情報に異常があることから、この認証が正常に行えない場合も考えられる。図示は省略するが、このような場合には、証明書管理装置20のレスキューURLにアクセスして共通証明書を用いた認証を行うようにする。
An example of the processing sequence in this case is shown in FIG.
In this case, first, the HTTPS
証明書管理装置20は、ステップS401の要求を受けると、証明書セット及びその設定要求を作成する(S402)が、証明書管理装置20は上位装置30に対して発行した公開鍵及び私有鍵や、過去に使用した全てのバージョンのルート私有鍵及びルート鍵を記憶しているため、どのバージョンの証明書でも作成することができるが、最新バージョンの証明書を作成するようにするとよい。そして、ここで作成した新たな各証明書及び鍵も、それまでの証明書等と同様、証明書管理部26に記憶させて管理する。
Upon receiving the request in step S401, the
上位装置30は、ステップS401の要求を送信した後、証明書の作成が完了した頃に証明書管理装置20に対して通信要求を行い、証明書管理装置20から上位装置30への要求の有無を問い合わせる(S403)。このとき、ステップS402の処理が完了していれば、証明書管理装置20は通信要求に対する応答として、証明書設定要求と共に新証明書セットを上位装置30に返す(S404)。
上位装置30はこの要求を受けると、証明書記憶部45に記憶している正規認証情報を受信した新証明書セットの内容に更新し(S405)、更新処理の結果を示す証明書更新要求応答を証明書管理装置20に返す(S406)。証明書管理装置20はこれに対して応答を受信した旨の通知を返す(S407)。
After transmitting the request in step S401, the higher-
Upon receiving this request, the
以上の処理によって、下位装置40の場合と同様に上位装置30の正規認証情報を更新することができるが、この更新によって個別証明書が変更されるため、更新前に個別証明書を用いた認証が行えていた下位装置40との間で、この認証が正常に行えなくなってしまった可能性がある。そこで、各下位装置40の通常URLに対して通信を要求し、下位装置の再検索を行うようにしている(S408)。そして、下位装置40が応答として送信してくる個別証明書を用いて認証を行い、この認証が正常に行えなかった下位装置40については、図12及び図13のステップS305以下と同様な処理を行って個別証明書を含む正規認証情報を更新する(S409)。
With the above processing, the regular authentication information of the higher-
全ての下位装置40に対してこのような検索と更新が終了すると、上位装置30は再び全ての下位装置40を個別証明書を用いて認証できる状態になる。従って、このような処理を行うことにより、個別証明書を用いた認証の異常が上位装置30の正規認証情報の異常に起因する場合でも、この異常を解消することができる。
また、図13のステップS408以降に示したような再検索は、上位装置30の証明書更新とは無関係に行ってもよい。このような処理により、定期的に個別証明書を用いた認証の成否を確認し、異常があった場合には下位装置40の個別証明書を更新して通信システムの各装置が個別証明書を用いて通信相手を認証可能な状態を保つことができる。
When such searching and updating for all the
Further, the re-search as shown after step S408 in FIG. 13 may be performed regardless of the certificate update of the higher-
さらに、通信相手として記憶している装置のIPアドレスだけでなく、定められたIPアドレスの範囲全てに対してこの検索を行うようにすれば、新たな下位装置40が接続された場合でも、自動的に検出して個別証明書を用いた認証が可能な状態にすることができる。製造時に下位装置40に個別証明書が記憶されていなかった場合でも、共通証明書を用いた認証が成功すれば、証明書管理装置20にその下位装置に対する個別証明書を発行させ、記憶させることができる。
Furthermore, if this search is performed not only on the IP address of the device stored as the communication partner but also on the entire range of the specified IP address, even when a new
従って、このような検索を用いれば、工場での製造時には下位装置40にレスキュー認証情報のみを記憶させて出荷しておき、装置が顧客先に設置され、上位装置30と接続した後でネットワークを介して正規認証情報を配布してこれを記憶させるといったことも可能となる。
なお、この検索によって個別証明書を用いた認証に異常がある装置を発見した場合には、ただちに個別証明書の更新(又は新規記憶)を行うので、このような検索は、下位装置40に新たな個別証明書を記憶させる動作の一部であると考えることができる。
Therefore, if such a search is used, only the rescue authentication information is stored in the
If a device having an abnormality in authentication using an individual certificate is found by this search, the individual certificate is immediately updated (or newly stored). It can be considered that this is a part of the operation of storing the individual certificate.
また、上述した実施形態では、通信の要求を上位装置30から下位装置40に対して行う例について説明したが、このようにすることは必須ではない。すなわち、下位装置40から上位装置30に対して通信を行う場合でも、同様な処理が可能である。
図15乃至図17に、このようにする場合の、図12と対応する部分の処理シーケンスを示す。ただし、図15乃至図17においては、シーケンスを図12の場合よりも簡略化して示している。
In the above-described embodiment, an example in which a communication request is made from the higher-
FIGS. 15 to 17 show a processing sequence of a portion corresponding to FIG. 12 in such a case. However, in FIGS. 15 to 17, the sequence is shown more simplified than in the case of FIG. 12.
まず、図15には、個別公開鍵証明書を用いた認証を行う場合も、共通公開鍵証明書を用いた認証を行う場合も、下位装置40から上位装置30に対して通信を要求するようにする場合の例を示している。
この場合、下位装置40が上位装置30と通常の通信を行うべく、通常URLに通信を要求すると(S501)、これに応じて上位装置30と下位装置40との間で個別公開鍵証明書を用いた認証処理を行う(S502)。
First, FIG. 15 shows that the
In this case, when the
この認証処理は、図19に示したような相互認証であっても、片方向認証であっても構わないが、少なくとも、上位装置30が下位装置40の公開鍵証明書を用いて下位装置40を認証するものとする。そして、この例では下位装置40がクライアントに該当するため、片方向認証を行う場合の処理は、図21に示したものとは若干異なることになるが、下位装置40が自身の私有鍵で乱数を暗号化して公開鍵証明書と共に上位装置30に送信し、上位装置30側で公開鍵証明書の正当性を確認した上で乱数を復号化して認証を行うという点では同様な処理を行えばよい。
This authentication process may be mutual authentication as shown in FIG. 19 or one-way authentication, but at least the
そして、上位装置30がステップS502での認証が失敗したと判断すると(S503)、下位装置40に認証失敗応答を返す(S504)。すると、この応答を受けた下位装置40が、次は上位装置30のレスキューURLに対して通信を要求する(S505)。そして、共通公開鍵証明書を用いた認証処理を行い(S506)、上位装置30が認証成功と判断すると(S507)、図12のステップS311の場合と同様、個別公開鍵証明書を用いた認証が失敗したのは、下位装置40が記憶しているべき証明書の異常に起因して認証に異常が発生しているためであると判断する(S508)。そして、図13に示した処理を実行して下位装置40の正規認証情報を更新する。
When the
また、図16には、個別公開鍵証明書を用いた認証を行う場合には下位装置40から上位装置30に対して通信を要求し、共通公開鍵証明書を用いた認証を行う場合には、上位装置30から下位装置40に対して通信を要求するようにする場合の例を示している。
この場合、ステップS511〜S514の処理は、図15のステップS501〜S504の場合と同様であるが、上位装置30は、下位装置40に認証失敗応答を返すと、その後下位装置40のレスキューURLに対して通信を要求する(S515)。そして、共通公開鍵証明書を用いた認証処理を行い(S516)、認証成功と判断すると(S517)、図12のステップS311の場合と同様、個別公開鍵証明書を用いた認証が失敗したのは、下位装置40が記憶しているべき証明書の異常に起因して認証に異常が発生しているためであると判断する(S518)。そして、図13に示した処理を実行して下位装置40の正規認証情報を更新する。
Also, in FIG. 16, when performing authentication using the individual public key certificate, the
In this case, the processing in steps S511 to S514 is the same as that in steps S501 to S504 in FIG. 15, but when the
また、図17には、逆に個別公開鍵証明書を用いた認証を行う場合には上位装置30から下位装置40に対して通信を要求し、共通公開鍵証明書を用いた認証を行う場合には、下位装置40から上位装置30に対して通信を要求するようにする場合の例を示している。
この場合、上位装置30が下位装置40と通常の通信を行うべく、通常URLに通信を要求すると(S521)、これに応じて上位装置30と下位装置40との間で個別公開鍵証明書を用いた認証処理を行う(S522)。認証処理の内容については、図19に示したような相互認証でも図21に示したような片方向認証でもよい。
Also, in FIG. 17, when performing authentication using an individual public key certificate, the
In this case, when the
そして、上位装置30がステップS522での認証が失敗したと判断すると(S523)、下位装置40に認証失敗応答を送信する(S524)。そして、下位装置40は、この応答を受信すると、上位装置30のレスキューURLに対して通信を要求する(S525)。そして、共通公開鍵証明書を用いた認証処理を行い(S526)、上位装置30が認証成功と判断すると(S527)、図12のステップS311の場合と同様、個別公開鍵証明書を用いた認証が失敗したのは、下位装置40が記憶しているべき証明書の異常に起因して認証に異常が発生しているためであると判断する(S528)。そして、図13に示した処理を実行して下位装置40の正規認証情報を更新する。
When the
以上のような図15乃至図17のいずれに示したシーケンスを採用した場合でも、上述した実施形態の場合と同様、個別公開鍵証明書を用いた認証が失敗した場合に共通公開鍵証明書を用いた認証を行い、これが成功した場合に個別公開鍵証明書を用いた認証の失敗は認証の異常が原因であると判断できる。従って、上位装置30が新証明書セットを取得して下位装置40に送信し、正規認証情報を更新させることにより、速やかに異常の解消を図ることができる。
Even when any of the sequences shown in FIG. 15 to FIG. 17 as described above is adopted, the common public key certificate is used when the authentication using the individual public key certificate fails as in the case of the above-described embodiment. If the authentication used is successful and the authentication succeeds, it can be determined that the authentication failure using the individual public key certificate is caused by an abnormal authentication. Accordingly, the
また、どちらの装置が通信要求を行うかを、場合に応じて変えることができるようにしてもよい。例えば、個別公開鍵証明書を用いた認証が失敗した場合に上位装置30が下位装置40のレスキューURLに通信を要求するようにしたり、個別公開鍵証明書を用いた認証が失敗した旨の応答を受信した場合に下位装置40が上位装置30のレスキューURLに通信を要求したりするようにすれば、初めの通常URLへの通信をどちらの装置から行ったとしても、以後の処理を同じように進めることができる。
なお、新証明書セットの送信に係る図13のステップS316の通信も、下位装置40側から通信要求を行い、上位装置30側からその通信要求に応じて証明書更新要求を送信するようにしてもよい。
Further, it may be possible to change which device makes a communication request according to circumstances. For example, when the authentication using the individual public key certificate fails, the
Note that the communication in step S316 of FIG. 13 related to the transmission of the new certificate set is also performed by making a communication request from the
ところで、上述した実施形態においては、証明書管理装置20は1つである例について説明した。しかしながら、個別証明書と共通証明書とでは用途も機能も異なるため、これらの証明書は別々の証明書管理装置が発行するようにするとよい。
すなわち、共通証明書は一度作成したら更新しないため、共通ルート私有鍵が漏洩すると通信の安全性維持が著しく困難になるので、秘密保持を特に厳重に行う必要がある。一方で、各装置について個別に異なる証明書を作成して記憶させる必要はない。そこで、安全性を重視し、例えば証明書を記憶させる工程を有する工場のみと専用線で通信可能なような、外部からアクセス不能な証明書管理装置を用いるとよい。
Incidentally, in the above-described embodiment, an example in which there is one
In other words, since the common certificate is not updated once it is created, if the common root private key is leaked, it becomes extremely difficult to maintain the security of communication, so it is necessary to maintain confidentiality particularly strictly. On the other hand, it is not necessary to create and store different certificates for each device individually. For this reason, it is preferable to use a certificate management apparatus that cannot be accessed from the outside and that can communicate with only a factory having a process for storing certificates, for example, with a dedicated line, with an emphasis on safety.
一方、個別証明書は必要に応じて更新できるため、個別ルート私有鍵が漏洩したとしても、これを更新すれば通信の安全性を保つことができる。そして、装置毎に個別に証明書を作成して記憶させる必要があることから、インターネット等のオープンネットワークに接続した証明書管理装置を用いるとよい。
なお、証明書管理装置をさらに細分化し、下位装置用の証明書を発行する証明書管理装置,上位装置用の証明書を発行する証明書管理装置,各証明書管理装置の証明書を発行する証明書管理装置等、証明書を発行する対象の装置の階位に応じて証明書管理装置を分けるようにしてもよい。
On the other hand, since the individual certificate can be updated as necessary, even if the individual root private key is leaked, the security of the communication can be maintained by updating it. Since it is necessary to create and store a certificate for each device individually, a certificate management device connected to an open network such as the Internet may be used.
The certificate management device is further subdivided to issue a certificate management device that issues a certificate for a lower device, a certificate management device that issues a certificate for a higher device, and issues a certificate for each certificate management device. You may make it divide a certificate management apparatus according to the rank of the apparatus which issues a certificate, such as a certificate management apparatus.
また、上述の実施形態で説明した証明書送信方法は、通信装置を工場で製造する際の、各装置に個別証明書を記憶させる工程でも使用することができる。すなわち、個別証明書の設定に用いる冶具を上位装置、製造工程において共通証明書を書き込まれた通信装置を下位装置として機能させ、冶具が通信装置を共通証明書を用いて認証し、これが成功した場合に通信装置に個別証明書を記憶させるようにすればよい。このようにすれば、誤った製品に個別証明書を記憶させてしまったり、製品の成りすましによって証明書を不正に取得されたりすることを防止できる。
さらに、通信装置の側でも冶具を共通証明書を用いて認証し、これが成功した場合に個別証明書を受け入れるようにすれば、冶具のなりすましによって不正な証明書を記憶させられることを防止できる。
The certificate transmission method described in the above embodiment can also be used in the process of storing individual certificates in each device when the communication device is manufactured in a factory. That is, the jig used for setting the individual certificate functions as a higher-level device, the communication device in which the common certificate was written in the manufacturing process functions as the lower-level device, and the jig authenticated the communication device using the common certificate. In such a case, the individual certificate may be stored in the communication device. In this way, it is possible to prevent the individual certificate from being stored in the wrong product or the certificate from being illegally acquired due to product impersonation.
Further, if the jig is authenticated by using the common certificate on the communication device side and an individual certificate is accepted when this is successful, it is possible to prevent an illegal certificate from being stored by impersonating the jig.
また、上述した実施形態では、装置の識別情報が付された個別証明書と、装置の識別情報が付されていない共通証明書とを用いる例について説明したが、前者はセキュリティ強度が高い証明書、後者はセキュリティ強度が低い証明書と捉えることもできる。
一般に、セキュリティ強度が高い証明書には、多くの情報を記載する必要があったり、輸出制限があったり特殊な認証処理プログラムが必要であったりして利用可能な環境が限られていたりするため、全ての装置に同じように記憶させて認証処理に用いることが難しい場合がある。一方で、セキュリティ強度が低い証明書であれば、このような制限が少なく、全ての装置に同じように記憶させて認証処理に用いることが比較的容易であると考えられる。
In the above-described embodiment, the example using the individual certificate with the device identification information and the common certificate without the device identification information has been described. The former is a certificate with high security strength. The latter can be regarded as a certificate with 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.
そこで、セキュリティ強度が低い証明書を記憶させた装置を製造・販売した上で、利用環境に合わせてセキュリティ強度が高い証明書を事後的に記憶させることができるようにしたいという要求がある。このような場合に、上述した実施形態の処理を利用し、セキュリティの高い証明書を用いた認証が失敗した場合にセキュリティの低い証明書を用いた認証を行い、これが成功した場合にセキュリティの高い証明書を用いた認証の失敗は認証の異常が原因であると判断して、上位装置30がセキュリティの高い証明書を含む証明書セットを取得して下位装置40に送信し、これを記憶させることにより、ある程度の安全性を確保しながら、顧客先に設置した後の装置に利用シーンに合った証明書を記憶させることも可能となる。
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. In such a case, using the processing of the above-described embodiment, if authentication using a high-security certificate fails, authentication using a low-security certificate is performed, and if this succeeds, high-security is performed. It is determined that the authentication failure using the certificate is caused by an authentication error, and the higher-
また、上述した実施形態では、上位装置30と下位装置40あるいは証明書管理装置20が、図19あるいは図21を用いて説明したようなSSLに従った認証を行う場合の例について説明した。しかし、この認証が必ずしもこのようなものでなくてもこの実施形態は効果を発揮する。
SSLを改良したTLS(Transport Layer Security)も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。
In the above-described embodiment, the example has been described in which the higher-
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.
また、上述した実施形態では、証明書管理装置20を上位装置30と別に設ける例について説明したが、これと一体として設けることを妨げるものではない。この場合、証明書管理装置20の機能を実現するためのCPU,ROM,RAM等の部品を独立して設けてもよいが、上位装置30のCPU,ROM,RAM等を使用し、そのCPUに適当なソフトウェアを実行させることにより、証明書管理装置20として機能させるようにしてもよい。
In the above-described embodiment, the example in which the
このような場合において、証明書管理装置20と、これと一体になっている上位装置30との間の通信には、ハードウェアを証明書管理装置20として機能させるためのプロセスと、ハードウェアを上位装置30として機能させるためのプロセスとの間のプロセス間通信を含むものとする。
さらに、上述した各実施形態では、証明書管理装置20がルート鍵やデジタル証明書を自ら作成する例について説明したが、図2に示した証明用鍵作成部24や証明書発行部25の機能を証明書管理装置20とは別の装置に設け、証明書管理装置20がその装置からルート鍵やデジタル証明書の供給を受けてこれらを取得するようにしてもよい。
In such a case, for communication between the
Further, in each of the above-described embodiments, the example in which the
また、この発明によるプログラムは、コンピュータを、通信手段を備え、通信の際に通信相手をデジタル証明書を用いて認証する通信装置である、上位装置30あるいは下位装置40のような装置として機能させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
The program according to the present invention causes a computer to function as an apparatus such as the
このようなプログラムは、はじめからコンピュータに備えるROMあるいはHDD等の記憶手段に格納しておいてもよいが、記録媒体であるCD−ROMあるいはフレキシブルディスク,SRAM,EEPROM,メモリカード等の不揮発性記録媒体(メモリ)に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてCPUに実行させるか、CPUにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
Such a program may be stored in a storage means such as a ROM or HDD provided in the computer from the beginning, but a non-volatile recording such as a CD-ROM or flexible disk, SRAM, EEPROM, memory card or the like as a recording medium. It can also be recorded on a medium (memory) and provided. Each procedure described above can be executed by installing a program recorded in the memory in a computer and causing the CPU to execute the program, or causing the CPU to read and execute the program from the memory.
Furthermore, it is also possible to download and execute an external device that is connected to a network and includes a recording medium that records the program, or an external device that stores the program in the storage unit.
以上説明してきた通り、この発明の通信装置、通信システム、通信方法あるいはプログラムによれば、通信の際に通信相手を証明書を用いて認証する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、セキュリティを維持しながら、認証に異常があった場合でも正常な認証が行える状態に容易に回復させることができるようにすることができる。
従って、この発明を、このような通信システム又は、通信システムを構成する通信装置に適用することにより、セキュリティの高い通信システムを構成することができる。
As has been described above, the communication apparatus of the present invention, a communication system, according to the communication method or program, and the communication partner by using a certificate when communicating constructed using a communication device or such a communication apparatus authenticating In a communication system, it is possible to easily restore a state in which normal authentication can be performed even when there is an abnormality in authentication while maintaining security.
Accordingly, the present invention, such a communication system or, by applying to a communication device constituting the communication system, it is possible to construct a high-security communication system.
11…CPU、12…ROM、13…RAM、14…HDD、15…通信I/F、
16…システムバス、20…証明書管理装置、
21,32,42…HTTPSサーバ機能部、22,33,43…認証処理部、
23,48…証明書更新部、24…証明用鍵作成部、25…証明書発行部、
26…証明書管理部、30…上位装置、31,41…HTTPSクライアント機能部、
34…証明書更新要求部、35,45…証明書記憶部、40…下位装置、
44…要求管理部、46…状態通知部、47…ログ通知部、49…コマンド受信部
11 ... CPU, 12 ... ROM, 13 ... RAM, 14 ... HDD, 15 ... communication I / F,
16 ... system bus, 20 ... certificate management device,
21, 32, 42 ... HTTPS server function unit, 22, 33, 43 ... authentication processing unit,
23, 48 ... certificate renewal unit, 24 ... certification key creation unit, 25 ... certificate issuing unit,
26 ... Certificate management unit, 30 ... Host device, 31, 41 ... HTTPS client function unit,
34 ... Certificate update request unit, 35, 45 ... Certificate storage unit, 40 ... Subordinate device,
44 ... request management unit, 46 ... status notification unit, 47 ... log notification unit, 49 ... command reception unit
Claims (16)
前記相手先装置と通信を行う場合に、該相手先装置から受信した該相手先装置を一意に特定するための識別情報を含む第1の証明書を用いて該相手先装置の認証を行う第1の認証手段と、When communicating with the counterpart device, the first device authenticates the counterpart device using a first certificate that includes identification information for uniquely identifying the counterpart device received from the counterpart device. 1 authentication means;
前記第1の認証手段による認証が失敗した場合に、前記相手先装置から受信した、該相手先装置を一意に特定するための識別情報を含まない第2の証明書を用いて該相手先装置の認証を行う第2の認証手段と、When the authentication by the first authentication unit fails, the counterpart device is received by using the second certificate that is received from the counterpart device and does not include identification information for uniquely identifying the counterpart device. A second authentication means for authenticating
前記第2の認証手段による認証が成功した場合に、前記第1の証明書の更新を要求する証明書更新要求及び前記第1の証明書を更新するための証明書を前記相手先装置へ送信する送信手段とを設けたことを特徴とする通信装置。When authentication by the second authentication unit is successful, a certificate update request for updating the first certificate and a certificate for updating the first certificate are transmitted to the counterpart device. And a transmission means.
前記第2の認証手段による認証が成功した場合に、所定の証明書管理装置に対して、前記相手先装置へ送信する、前記第1の証明書を更新するための証明書の発行を要求し、該証明書管理装置から該第1の証明書を更新するための証明書を取得する手段を設けたことを特徴とする通信装置。When authentication by the second authentication means is successful, a request is made to issue a certificate for updating the first certificate to be sent to the counterpart device to a predetermined certificate management device. A communication apparatus comprising means for obtaining a certificate for updating the first certificate from the certificate management apparatus.
前記相手先装置を一意に特定するための識別情報は、前記相手先装置の機番であることを特徴とする通信装置。The identification information for uniquely identifying the counterpart device is a machine number of the counterpart device.
当該通信装置を一意に特定するための識別情報を含む第1の証明書と、当該通信装置を一意に特定するための識別情報を含まない第2の証明書とを記憶する記憶手段と、Storage means for storing a first certificate including identification information for uniquely identifying the communication device and a second certificate not including identification information for uniquely identifying the communication device;
前記相手先装置と通信を行う場合に、前記第1の証明書を前記相手先装置へ送信する第1の送信手段と、A first transmission means for transmitting the first certificate to the counterpart device when communicating with the counterpart device;
前記第1の送信手段が送信した前記第1の証明書を用いた前記相手先装置での認証が失敗した場合に、前記第2の証明書を前記相手先装置へ送信する第2の送信手段と、Second transmitting means for transmitting the second certificate to the counterpart device when authentication with the counterpart device using the first certificate transmitted by the first transmitter means fails. When,
前記第2の送信手段が送信した前記第2の証明書を用いた前記相手先装置での認証が成功した場合に、前記相手先装置から前記第1の証明書の更新を要求する証明書更新要求及び前記第1の証明書を更新するための証明書を受信し、前記記憶手段に記憶された前記第1の証明書を前記受信した証明書に更新する更新手段とを設けたことを特徴とする通信装置。Certificate update requesting renewal of the first certificate from the counterpart device when the authentication at the counterpart device using the second certificate transmitted by the second transmitter is successful. Update means for receiving a request and a certificate for updating the first certificate, and updating the first certificate stored in the storage means to the received certificate is provided. A communication device.
前記第2の送信手段が送信した前記第2の証明書を用いた前記相手先装置での認証が成功した場合に、前記相手先装置からの要求のうち、前記証明書更新要求のみを許可することを特徴とする通信装置。Allow only the certificate update request among the requests from the counterpart device when the authentication at the counterpart device using the second certificate transmitted by the second transmission means is successful. A communication device.
前記更新手段が受信する前記第1の証明書を更新するための証明書は、前記証明書更新要求と共に送信されてくるものであることを特徴とする通信装置。A communication apparatus, wherein a certificate for updating the first certificate received by the updating means is transmitted together with the certificate update request.
当該通信装置を一意に特定するための識別情報は、当該通信装置の機番であることを特徴とする通信装置。The identification information for uniquely identifying the communication device is a device number of the communication device.
前記下位装置に、In the subordinate device,
前記下位装置を一意に特定するための識別情報を含む第1の証明書と、前記下位装置を一意に特定するための識別情報を含まない第2の証明書とを記憶する記憶手段と、Storage means for storing a first certificate including identification information for uniquely identifying the lower-level device and a second certificate not including identification information for uniquely identifying the lower-level device;
前記上位装置と通信を行う場合に、前記第1の証明書を前記上位装置へ送信する第1の送信手段と、First communication means for transmitting the first certificate to the host device when communicating with the host device;
前記第1の送信手段が送信した前記第1の証明書を用いた前記上位装置での認証が失敗した場合に、前記第2の証明書を前記上位装置へ送信する第2の送信手段と、A second transmission unit configured to transmit the second certificate to the higher-level device when authentication by the higher-level device using the first certificate transmitted by the first transmission unit fails;
前記第2の送信手段が送信した前記第2の証明書を用いた前記上位装置での認証が成功した場合に、前記上位装置から前記第1の証明書の更新を要求する証明書更新要求及び前記第1の証明書を更新するための証明書を受信し、前記記憶手段に記憶された前記第1の証明書を前記受信した証明書に更新する更新手段とを設け、A certificate renewal request for requesting renewal of the first certificate from the high order apparatus when the authentication at the high order apparatus using the second certificate transmitted by the second sending means is successful; and Updating means for receiving a certificate for updating the first certificate and updating the first certificate stored in the storage means to the received certificate;
前記上位装置に、In the host device,
前記下位装置と通信を行う場合に、該下位装置から受信した前記第1の証明書を用いて該下位装置の認証を行う第1の認証手段と、A first authentication means for authenticating the lower-level device using the first certificate received from the lower-level device when communicating with the lower-level device;
前記第1の認証手段による認証が失敗した場合に、前記下位装置から受信した前記第2の証明書を用いて該下位装置の認証を行う第2の認証手段と、A second authentication unit that authenticates the lower-level device using the second certificate received from the lower-level device when authentication by the first authentication unit fails;
前記第2の認証手段による認証が成功した場合に、前記第1の証明書の更新を要求する証明書更新要求及び前記第1の証明書を更新するための証明書を前記下位装置へ送信する送信手段とを設けたことを特徴とする通信システム。When authentication by the second authentication unit is successful, a certificate update request for updating the first certificate and a certificate for updating the first certificate are transmitted to the lower-level device. A communication system comprising a transmission unit.
前記上位装置に、前記第2の認証手段による認証が成功した場合に、所定の証明書管理装置に対して、前記下位装置へ送信する、前記第1の証明書を更新するための証明書の発行を要求し、該証明書管理装置から該第1の証明書を更新するための証明書を取得する手段を設けたことを特徴とする通信システム。When the authentication by the second authentication means is successful in the higher-level device, a certificate for updating the first certificate to be transmitted to the lower-level device to a predetermined certificate management device A communication system comprising means for requesting issuance and obtaining a certificate for updating the first certificate from the certificate management apparatus.
前記下位装置は、前記第2の送信手段が送信した前記第2の証明書を用いた前記上位装置での認証が成功した場合に、前記上位装置からの要求のうち、前記証明書更新要求のみを許可することを特徴とする通信システム。The lower device, when the authentication with the upper device using the second certificate transmitted by the second transmission means is successful, only the certificate update request among the requests from the upper device. A communication system characterized by allowing
前記上位装置の送信手段は、前記証明書更新要求と共に前記第1の証明書を更新するための証明書を前記下位装置へ送信し、The transmission means of the upper device transmits a certificate for updating the first certificate together with the certificate update request to the lower device,
前記下位装置の前記更新手段が受信する前記第1の証明書を更新するための証明書は、前記証明書更新要求と共に送信されてくるものであることを特徴とする通信システム。A communication system, wherein a certificate for updating the first certificate received by the updating unit of the lower-level device is transmitted together with the certificate update request.
前記下位装置を一意に特定するための識別情報は、前記下位装置の機番であることを特徴とする通信システム。The identification information for uniquely identifying the lower device is a machine number of the lower device.
前記相手先装置と通信を行う場合に、該相手先装置から受信した該相手先装置を一意に特定するための識別情報を含む第1の証明書を用いて該相手先装置の認証を行う第1の認証手順と、When communicating with the counterpart device, the first device authenticates the counterpart device using a first certificate that includes identification information for uniquely identifying the counterpart device received from the counterpart device. 1 authentication procedure;
前記第1の認証手順による認証が失敗した場合に、前記相手先装置から受信した、該相手先装置を一意に特定するための識別情報を含まない第2の証明書を用いて該相手先装置の認証を行う第2の認証手順と、When the authentication by the first authentication procedure fails, the counterpart device is received using the second certificate that does not include the identification information for uniquely identifying the counterpart device received from the counterpart device. A second authentication procedure for authenticating
前記第2の認証手順による認証が成功した場合に、前記第1の証明書の更新を要求する証明書更新要求及び前記第1の証明書を更新するための証明書を前記相手先装置へ送信する送信手順とを実行させることを特徴とする通信方法。When authentication by the second authentication procedure is successful, a certificate update request for updating the first certificate and a certificate for updating the first certificate are transmitted to the counterpart device. A communication method characterized by causing a transmission procedure to be executed.
前記相手先装置と通信を行う場合に、前記第1の証明書を前記相手先装置へ送信する第1の送信手順と、A first transmission procedure for transmitting the first certificate to the counterpart device when communicating with the counterpart device;
前記第1の送信手順で送信した前記第1の証明書を用いた前記相手先装置での認証が失敗した場合に、前記第2の証明書を前記相手先装置へ送信する第2の送信手順と、A second transmission procedure for transmitting the second certificate to the counterpart device when authentication with the counterpart device using the first certificate transmitted in the first transmission procedure fails. When,
前記第2の送信手順で送信した前記第2の証明書を用いた前記相手先装置での認証が成功した場合に、前記相手先装置から前記第1の証明書の更新を要求する証明書更新要求及び前記第1の証明書を更新するための証明書を受信し、前記記憶手段に記憶された前記第1の証明書を前記受信した証明書に更新する更新手順とを実行させることを特徴とする通信方法。Certificate update requesting update of the first certificate from the counterpart device when the authentication at the counterpart device using the second certificate transmitted in the second transmission procedure is successful Receiving a request and a certificate for updating the first certificate, and executing an update procedure for updating the first certificate stored in the storage means to the received certificate. Communication method.
前記相手先装置と通信を行う場合に、該相手先装置から受信した該相手先装置を一意に特定するための識別情報を含む第1の証明書を用いて該相手先装置の認証を行う第1の認証手段と、When communicating with the counterpart device, the first device authenticates the counterpart device using a first certificate that includes identification information for uniquely identifying the counterpart device received from the counterpart device. 1 authentication means;
前記第1の認証手段による認証が失敗した場合に、前記相手先装置から受信した、該相手先装置を一意に特定するための識別情報を含まない第2の証明書を用いて該相手先装置の認証を行う第2の認証手段と、When the authentication by the first authentication unit fails, the counterpart device is received by using the second certificate that is received from the counterpart device and does not include identification information for uniquely identifying the counterpart device. A second authentication means for authenticating
前記第2の認証手段による認証が成功した場合に、前記第1の証明書の更新を要求する証明書更新要求及び前記第1の証明書を更新するための証明書を前記相手先装置へ送信する送信手段として機能させるためのプログラム。When authentication by the second authentication unit is successful, a certificate update request for requesting the update of the first certificate and a certificate for updating the first certificate are transmitted to the counterpart device. A program for functioning as a transmission means.
前記相手先装置と通信を行う場合に、前記第1の証明書を前記相手先装置へ送信する第1の送信手段と、A first transmission means for transmitting the first certificate to the counterpart device when communicating with the counterpart device;
前記第1の送信手段が送信した前記第1の証明書を用いた前記相手先装置での認証が失敗した場合に、前記第2の証明書を前記相手先装置へ送信する第2の送信手段と、Second transmitting means for transmitting the second certificate to the counterpart device when authentication with the counterpart device using the first certificate transmitted by the first transmitter means fails. When,
前記第2の送信手段が送信した前記第2の証明書を用いた前記相手先装置での認証が成功した場合に、前記相手先装置から前記第1の証明書の更新を要求する証明書更新要求及び前記第1の証明書を更新するための証明書を受信し、前記記憶手段に記憶された前記第1の証明書を前記受信した証明書に更新する更新手段として機能させるためのプログラム。Certificate update requesting renewal of the first certificate from the counterpart device when the authentication at the counterpart device using the second certificate transmitted by the second transmitter is successful. A program for receiving a request and a certificate for updating the first certificate, and causing the first certificate stored in the storage unit to function as an updating unit that updates the received certificate.
Priority Applications (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004198624A JP4611676B2 (en) | 2003-07-25 | 2004-07-05 | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM |
EP04254424A EP1501239B8 (en) | 2003-07-25 | 2004-07-23 | Authentication system and method using individualized and non-individualized certificates |
EP06011791A EP1693983B1 (en) | 2003-07-25 | 2004-07-23 | Authentication system and method using individualized and non-individualized certificates |
DE602004002044T DE602004002044T2 (en) | 2003-07-25 | 2004-07-23 | Authentication system and procedures using individualized and non-individualized certificates |
DE602004008667T DE602004008667T2 (en) | 2003-07-25 | 2004-07-23 | Authentication system and procedures using individualized and non-individualized certificates |
US10/896,900 US7694333B2 (en) | 2003-07-25 | 2004-07-23 | Communication apparatus, communication system, certificate transmission method, anomaly detection method and a program therefor |
US12/693,911 US8578466B2 (en) | 2003-07-25 | 2010-01-26 | Communication apparatus, communication system, certificate transmission method, anomaly detection method and a program therefor |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003201638 | 2003-07-25 | ||
JP2004198624A JP4611676B2 (en) | 2003-07-25 | 2004-07-05 | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2005065236A JP2005065236A (en) | 2005-03-10 |
JP4611676B2 true JP4611676B2 (en) | 2011-01-12 |
Family
ID=34379810
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004198624A Expired - Lifetime JP4611676B2 (en) | 2003-07-25 | 2004-07-05 | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4611676B2 (en) |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4611679B2 (en) * | 2003-07-25 | 2011-01-12 | 株式会社リコー | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM |
JP5464794B2 (en) * | 2006-07-24 | 2014-04-09 | コニカミノルタ株式会社 | Network management method and network management system |
JP2008165613A (en) * | 2006-12-28 | 2008-07-17 | N-Crypt Lab Inc | Authentication system, authentication device, authentication method, user device, and data processing method |
JP5082767B2 (en) * | 2007-10-26 | 2012-11-28 | 富士電機リテイルシステムズ株式会社 | Control equipment |
JP6099599B2 (en) * | 2014-07-08 | 2017-03-22 | 三菱電機株式会社 | Equipment management system, equipment management apparatus, equipment management method, and program |
JP6786830B2 (en) * | 2016-03-18 | 2020-11-18 | 株式会社リコー | Certificate management system, certificate management method and program |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5781723A (en) * | 1996-06-03 | 1998-07-14 | Microsoft Corporation | System and method for self-identifying a portable information device to a computing unit |
JP2001094553A (en) * | 1999-09-22 | 2001-04-06 | Nippon Telegr & Teleph Corp <Ntt> | Method and device for anonymous authentication |
JP2001326632A (en) * | 2000-05-17 | 2001-11-22 | Fujitsu Ltd | Distribution group management system and method |
JP2002229949A (en) * | 2001-02-02 | 2002-08-16 | Dainippon Printing Co Ltd | Portable information processing equipment |
JP2002287629A (en) * | 2001-03-26 | 2002-10-04 | Toppan Printing Co Ltd | Electronic device, information update system in electronic device, information update method and program therefor |
JP2003006161A (en) * | 2001-06-20 | 2003-01-10 | Mitsubishi Electric Corp | Server for providing service to client computer, and method and program for providing service |
JP2003503963A (en) * | 1999-06-30 | 2003-01-28 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Dynamic connection to multiple origin servers with transcoding proxy |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH05336108A (en) * | 1992-06-04 | 1993-12-17 | Toshiba Corp | Radio communication system |
JPH06268638A (en) * | 1993-03-10 | 1994-09-22 | Nippon Telegr & Teleph Corp <Ntt> | Terminal certification control method |
JPH10336170A (en) * | 1997-05-29 | 1998-12-18 | Mitsubishi Electric Corp | Public key verifying device |
-
2004
- 2004-07-05 JP JP2004198624A patent/JP4611676B2/en not_active Expired - Lifetime
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5781723A (en) * | 1996-06-03 | 1998-07-14 | Microsoft Corporation | System and method for self-identifying a portable information device to a computing unit |
JP2003503963A (en) * | 1999-06-30 | 2003-01-28 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Dynamic connection to multiple origin servers with transcoding proxy |
JP2001094553A (en) * | 1999-09-22 | 2001-04-06 | Nippon Telegr & Teleph Corp <Ntt> | Method and device for anonymous authentication |
JP2001326632A (en) * | 2000-05-17 | 2001-11-22 | Fujitsu Ltd | Distribution group management system and method |
JP2002229949A (en) * | 2001-02-02 | 2002-08-16 | Dainippon Printing Co Ltd | Portable information processing equipment |
JP2002287629A (en) * | 2001-03-26 | 2002-10-04 | Toppan Printing Co Ltd | Electronic device, information update system in electronic device, information update method and program therefor |
JP2003006161A (en) * | 2001-06-20 | 2003-01-10 | Mitsubishi Electric Corp | Server for providing service to client computer, and method and program for providing service |
Also Published As
Publication number | Publication date |
---|---|
JP2005065236A (en) | 2005-03-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4555175B2 (en) | Examination device, communication system, examination method, program, and recording medium | |
JP4712325B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
EP1521426B1 (en) | Communication apparatus, communication system, certificate transmission method and program | |
JP4607567B2 (en) | Certificate transfer method, certificate transfer apparatus, certificate transfer system, program, and recording medium | |
EP1501239B1 (en) | Authentication system and method using individualized and non-individualized certificates | |
JP4576210B2 (en) | Certificate transfer device, certificate transfer system, certificate transfer method, program, and recording medium | |
JP4758095B2 (en) | Certificate invalidation device, communication device, certificate invalidation system, program, and recording medium | |
JP4509678B2 (en) | Certificate setting method | |
JP4611680B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
JP4611679B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
JP4611676B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
JP4504130B2 (en) | Communication apparatus, communication system, certificate transmission method and program | |
JP4657642B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
JP4509675B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, AND COMMUNICATION METHOD | |
JP4611678B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
JP4583833B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
JP4657643B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
JP4671638B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
JP4778210B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
JP4712330B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
JP4712326B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
JP4611681B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM | |
JP5434956B2 (en) | Certificate invalidation device, certificate invalidation system, program, and recording medium | |
JP4542848B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION DEVICE CONTROL METHOD, AND PROGRAM | |
JP4570919B2 (en) | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION DEVICE CONTROL METHOD, AND PROGRAM |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20061218 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100420 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100621 |
|
RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20100621 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20101012 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20101014 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131022 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4611676 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
EXPY | Cancellation because of completion of term |