JP4555175B2 - 審査装置、通信システム、審査方法、プログラム及び記録媒体 - Google Patents

Description

この発明は、公開鍵暗号を用いた認証処理を行う通信装置を審査する審査装置及び審査方法、上記のような審査装置と審査対象の通信装置とを備えた通信システム、コンピュータを上記のような審査装置として機能させるためのプログラム、およびそのようなプログラムを記録したコンピュータ読み取り可能な記録媒体に関する。

従来から、それぞれ通信機能を備えた複数の通信装置をネットワークを介して通信可能に接続し、様々なシステムを構築することが行われている。その一例としては、クライアント装置として機能するＰＣ（パーソナルコンピュータ）等のコンピュータから商品の注文を送信し、これとインターネットを介して通信可能なサーバ装置においてその注文を受け付けるといった、いわゆる電子商取引システムが挙げられる。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。

このようなシステムを構築する上では、通信を行う際に、通信相手が適切か、あるいは送信されてくる情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばＳＳＬ（Secure Socket Layer）と呼ばれるプロトコルが開発されており、広く用いられている。このプロトコルを用いて通信を行うことにより、公開鍵暗号方式と共通鍵暗号方式とを組み合わせ、通信相手の認証を行うと共に、情報の暗号化により改竄及び盗聴の防止を図ることができる。また、通信相手の側でも、通信を要求してきた通信元の装置を認証することができる。
このようなＳＳＬや公開鍵暗号を用いた認証に関連する技術としては、例えば特許文献１及び特許文献２に記載のものが挙げられる。
特開２００２−３５３９５９号公報 特開２００２−２５１４９２号公報

ここで、このＳＳＬに従った相互認証を行う場合の通信手順について、認証処理の部分に焦点を当てて説明する。図２５は、通信装置Ａと通信装置ＢとがＳＳＬに従った相互認証を行う際に各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図２５に示すように、ＳＳＬに従った相互認証を行う際には、まず双方の通信装置に、ルート鍵証明書及び、私有鍵と公開鍵証明書を記憶させておく必要がある。この私有鍵は、認証局（ＣＡ：certificate authority）が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にＣＡがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、ＣＡがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。

図２６にこれらの関係を示す。
図２６（ａ）に示すように、公開鍵Ａは、私有鍵Ａを用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者（ＣＡ）や有効期間等の情報を含む書誌情報とによって構成される。そして、ＣＡは、鍵本体や書誌情報が改竄されていないことを示すため、公開鍵Ａをハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名としてクライアント公開鍵に付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Ａの書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、公開鍵証明書Ａである。

この公開鍵証明書Ａを認証処理に用いる場合には、ここに含まれるデジタル署名を、ルート私有鍵と対応する公開鍵であるルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば、デジタル署名が確かにＣＡによって付されたことがわかる。また、公開鍵Ａの部分をハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とが一致すれば、鍵自体も損傷や改竄を受けていないことがわかる。
また、受信したデータを公開鍵Ａを用いて正常に復号化できれば、そのデータは、私有鍵Ａの持ち主から送信されたものであることがわかる。

ここで、認証を行うためには、ルート鍵を予め記憶しておく必要があるが、このルート鍵も、図２６（ｂ）に示すように、ＣＡがデジタル署名を付したルート鍵証明書として記憶しておく。このルート鍵証明書は、自身に含まれる公開鍵でデジタル署名を復号化可能な、自己署名形式である。そして、ルート鍵を使用する際に、そのルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し、ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば、ルート鍵が破損等していないことを確認できるのである。

図２５のフローチャートの説明に入る。なお、この図において、２本のフローチャート間の矢印は、データの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また、各ステップの処理が正常に完了しなかった場合には、その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合、処理がタイムアウトした場合等も同様である。

ここでは、通信装置Ａが通信装置Ｂに通信を要求するものとするが、この要求を行う場合、通信装置ＡのＣＰＵは、所要の制御プログラムを実行することにより、図２５の左側に示すフローチャートの処理を開始する。そして、ステップＳ２１１で通信装置Ｂに対して接続要求を送信する。
一方通信装置ＢのＣＰＵは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図２５の右側に示すフローチャートの処理を開始する。そして、ステップＳ２２１で第１の乱数を生成し、これを私有鍵Ｂを用いて暗号化する。そして、ステップＳ２２２でその暗号化した第１の乱数と公開鍵証明書Ｂとを通信装置Ａに送信する。

通信装置Ａ側では、これを受信すると、ステップＳ２１２でルート鍵証明書を用いて公開鍵証明書Ｂの正当性を確認する。
そして確認ができると、ステップＳ２１３で、受信した公開鍵証明書Ｂに含まれる公開鍵Ｂを用いて第１の乱数を復号化する。ここで復号化が成功すれば、第１の乱数は確かに公開鍵証明書Ｂの発行対象から受信したものだと確認できる。
その後、ステップＳ２１４でこれとは別に第２の乱数及び共通鍵の種を生成する。共通鍵の種は、例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして、ステップＳ２１５で第２の乱数を私有鍵Ａを用いて暗号化し、共通鍵の種を公開鍵Ｂを用いて暗号化し、ステップＳ２１６でこれらを公開鍵証明書Ａと共にサーバ装置に送信する。共通鍵の種の暗号化は、通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。
また、次のステップＳ２１７では、ステップＳ２１４で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。

通信装置Ｂ側では、通信装置ＡがステップＳ２１６で送信してくるデータを受信すると、ステップＳ２２３でルート鍵証明書を用いて公開鍵証明書Ａの正当性を確認する。そして確認ができると、ステップＳ２２４で、受信した公開鍵証明書Ａに含まれる公開鍵Ａを用いて第２の乱数を復号化する。ここで復号化が成功すれば、第２の乱数は確かに公開鍵証明書Ａの発行対象から受信したものだと確認できる。
その後、ステップＳ２２５で私有鍵Ｂを用いて共通鍵の種を復号化する。ここまでの処理で、通信装置Ａ側と通信装置Ｂ側に共通鍵の種が共有されたことになる。そして、この共通鍵の種は、生成した通信装置Ａと、私有鍵Ｂを持つ通信装置Ｂ以外の装置が知ることはない。ここまでの処理が成功すると、通信装置Ｂ側でもステップＳ２２６で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。

そして、通信装置Ａ側のステップＳ２１７と通信装置Ｂ側のステップＳ２２６の処理が終了すると、相互に認証の成功と以後の通信に使用する暗号化方式とを確認し、生成した共通鍵を用いてその暗号化方式で以後の通信を行うものとして認証に関する処理を終了する。なお、この確認には、通信装置Ｂからの認証が成功した旨の応答も含むものとする。以上の処理によって互いに通信を確立し、以後はステップＳ２１７又はＳ２２６で生成した共通鍵を用い、共通鍵暗号方式でデータを暗号化して通信を行うことができる。

このような処理を行うことにより、通信装置Ａと通信装置Ｂが互いに相手を認証した上で安全に共通鍵を共有することができ、通信を安全に行う経路を確立することができる。
なお、片方向認証を採用し、例えば通信装置Ｂが通信要求元の通信装置Ａを認証するのみでよいのであれば、図２５に示した認証処理において、第１の乱数の暗号化及び送信を省略することができる。この場合でも、共通鍵の種を通信装置Ａから通信装置Ｂに安全に送信するために、通信装置Ｂの公開鍵Ｂを用いた暗号化を行うとよいが、公開鍵Ｂに付されたデジタル署名の正当性を確認することは行わなくてよい。そして、この場合の認証処理は、図２７に示すように簡略化されたものになる。すなわち、通信装置Ａ側のステップＳ２１２及びＳ２１３の処理は不要となり、通信装置Ｂ側のステップＳ２２１の処理も不要となる。また、その他の処理も一部簡略化することができる。

以上のような認証処理においては、公開鍵で暗号化された内容は対応する私有鍵を持つ装置でしか復号できず、また、私有鍵で暗号化された内容は対応する公開鍵でしか復号できないことを利用して、通信相手が公開鍵証明書にその発行先として記載されている装置である（又はその装置の利用者が公開鍵証明書にその発行先として記載されている利用者である）と認証することになる。

なお、このような認証処理に使用する公開鍵の管理に関する技術としては、例えば特許文献３及び４に記載の技術が知られている。
特許文献３には、複写機管理装置２がホストコンピュータ４から受信した公開鍵を記憶しておき、異常情報をホストコンピュータ４に送信する際に、記憶している最新の公開鍵を用いて異常情報を暗号化することが記載されている。
特許文献４には、公開鍵暗号を用いた認証処理を行うクライアントがＷＷＷサーバにアクセスした際に、公開鍵証明書の期限切れが近い場合にはその旨をクライアントに警告するようにすることが記載されている。
特開２００１−２４２７５０号公報 特開２００３−２７３８５５号公報

ところで、公開鍵暗号方式においては、鍵長にもよるが、時間をかければ公開鍵から私有鍵を導くことができる。そして、私有鍵がわかってしまえば、第３者がその私有鍵の持ち主になりすますことが可能になるので、認証の確実性や通信の安全性が保たれない。そこで、上述のように鍵に有効期限を設け、所定期間毎に鍵のセットを更新するというセキュリティポリシーを採用するユーザが増えている。このため、例えば上記のような相互認証を利用した遠隔管理システム等を提供する場合には、顧客に対し、鍵の更新が可能なシステムであるという保証を行う必要が生じている。

そして、公開鍵証明書を用いて認証を受ける通信装置に更新用の新しい公開鍵証明書を配布する方式としては、使用中の公開鍵証明書の有効期限が切れる前に、ＣＡが通信装置に対して新たな公開鍵証明書と私有鍵を発行し、これらとルート鍵証明書のセットを、ＣＡあるいはそれに代わる管理装置が、使用中の公開鍵証明書を用いて確立したＳＳＬによる通信経路で更新対象の装置に送信して設定させる方式が考えられる。
このようにすれば、通信装置が認証に使用する公開鍵証明書等を、有効期限が切れる前に自動的に更新することができるので、ユーザの手を煩わせることなく、通信装置を認証可能な状態に保つことができる。また、インターネットを介して送信を行う場合でも、安全な通信経路を確保して公開鍵証明書等の転送を行うことができる。

しかしながら、このような方式を採用したとしても、更新対象の装置が、更新を行うべき期間の間にネットワークに接続されていなかったり、電源が入れられなかったりした場合には、公開鍵証明書を更新できないうちに使用中の公開鍵証明書の有効期限が切れてしまうことが考えられる。そして、これらのような状態になってしまった場合には、更新対象の装置は、もはやＣＡや管理装置に通常の認証を受けることはできない状態になってしまい、ＳＳＬによる安全な通信経路も確立できない状態になってしまう。

ただし、このような場合であっても、通信装置にＣＡや管理装置との間で非常用の通信経路を確保する手段を設けておけば、通信装置がその経路を通して通常の通信経路を確立するための新たな公開鍵証明書等を取得できるようにすることも可能である。このような非常用の通信経路としては、例えば、有効期限の長い公開鍵証明書及びこれと対応する私有鍵やルート鍵証明書を、ベンダーが提供する各装置に共通に記憶させておき、これらを用いてＣＡや管理装置との間でＳＳＬによる通信経路を確立できるようにすることが考えられる。
このような技術について、本件出願人は過去に特許出願を行っている（特願２００３−３４１３２９、未公開）。

しかし、このような非常用の通信経路については、普段は使用しないものであり、また通常の通信経路での通信に不都合があるような場合でも通信が可能であるようにする必要があるため、通常の通信経路の場合と同様な厳密さで認証処理を行うことができるようにすることは難しい。例えば、上記のように各装置に共通な公開鍵証明書を記憶させる場合には、公開鍵証明書に装置の識別情報を記載することはできないため、ＳＳＬによる認証処理の時点では装置の識別情報を参照することができない。そして、ＣＡや管理装置は、通信経路の確立後に通信装置に識別情報を送信させ、その情報を信用して更新用の公開鍵証明書等の送信を行うことになる。

従って、非常用の通信経路に関しては、他の通信装置になりすまして更新用の公開鍵証明書を取得することが、比較的簡単にできてしまうという問題があった。そこで、非常用の通信経路を使用する場合、すなわち通常の通信経路が使用できない場合でも、なりすましを効果的に防止できるようにすることが望まれていた。
この点に関し、上述した各特許文献には、通常使用する公開鍵証明書が使用できなくなった状態での公開鍵証明書の更新については、特に触れられていない。
また、生産設備等の都合により、通常使用する公開鍵証明書についても、上述の非常用の公開鍵証明書の場合のように、各装置に共通な公開鍵証明書を設定せざるを得ない場合もある。そして、このような場合には、上記の非常用の通信経路を利用する場合と同じく、通常使用する公開鍵証明書を、その有効期間内に更新する場合でも、なりすましを効果的に防止できるようにすることが望まれていた。
この発明は、上記のような要望に応え、安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、なりすましを効果的に防止できるようにすることを目的とする。

上記の目的を達成するため、この発明の審査装置は、公開鍵暗号を用いた認証処理を行うがその認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、その通信装置の公開鍵証明書とその通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、上記識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて上記通信装置を審査する審査手段とを設けたものである。
このような審査装置において、上記審査手段に、上記受信手段が受信した公開鍵証明書の内容と上記取得手段が取得した情報とが一致するか否かに基づいて上記公開鍵証明書が適切なものであるか否かを判断する手段を設けるとよい。

また、この発明は、公開鍵暗号を用いた認証処理を行う通信装置から、その通信装置の私有鍵と、その通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵を、その識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した公開鍵と上記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて上記通信装置を審査する審査手段とを設けた審査装置も提供する。
このような審査装置において、通信装置の識別情報とその通信装置が上記認証処理に使用する公開鍵との対応関係を記憶する手段を設けるとよい。
さらに、上記審査手段に、上記取得手段が取得した公開鍵と上記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて上記審査を行う手段を設けるとよい。

また、上記の各審査装置において、上記通信装置が上記審査手段による審査に合格した場合に、上記通信装置に、その通信装置の新たな公開鍵証明書を送信する送信手段を設けるとよい。
さらに、上記送信手段が送信する公開鍵証明書を、上記受信手段が受信した上記通信装置の識別情報を含む公開鍵証明書とするとよい。

また、この発明の通信システムは、公開鍵暗号を用いた認証処理を行うがその認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置であって、自身の公開鍵証明書と自身の識別情報とを審査装置に送信する手段を有する通信装置と、その通信装置から、その通信装置の公開鍵証明書とその通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、上記識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて上記通信装置を審査する審査手段とを設けた審査装置と備える通信システムである。
このような通信システムにおいて、上記審査装置の審査手段に、上記受信手段が受信した公開鍵証明書の内容と上記取得手段が取得した情報とが一致するか否かに基づいて上記公開鍵証明書が適切なものであるか否かを判断する手段を設けるとよい。

また、この発明は、公開鍵暗号を用いた認証処理を行う通信装置であって、自身の私有鍵と識別情報とを審査装置に送信する手段を有する通信装置と、その通信装置から、その通信装置の私有鍵と、その通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵を、その識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した公開鍵と上記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて上記通信装置を審査する審査手段とを備える審査装置とを設けた通信システムも提供する。

このような通信システムにおいて、上記審査装置に、通信装置の識別情報とその通信装置が上記認証処理に使用する公開鍵との対応関係を記憶する手段を設けるとよい。
さらに、上記審査装置の審査手段に、上記取得手段が取得した公開鍵と上記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて上記審査を行う手段を設けるとよい。

また、上記の各通信システムにおいて、上記審査装置に、上記通信装置が上記審査手段による審査に合格した場合に、上記通信装置に、その通信装置の新たな公開鍵証明書を送信する送信手段を設け、上記通信装置に、その公開鍵証明書を受信する手段を設けるとよい。
さらに、上記審査装置の送信手段が送信する公開鍵証明書を、上記受信手段が受信した上記通信装置の識別情報を含む公開鍵証明書とするとよい。
さらにまた、上記通信装置において、上記認証処理に使用する公開鍵証明書と私有鍵とを、独立して交換可能な複数のメモリユニットに分散させて記憶させるようにするとよい。

また、この発明の審査方法は、公開鍵暗号を用いた認証処理を行うがその認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、その通信装置の公開鍵証明書とその通信装置の識別情報とを受信する受信手順と、その手順で受信した識別情報と対応する公開鍵証明書の内容を示す情報を、上記識別情報をもとに上記通信装置とは異なる場所から取得する取得手順と、その手順で取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて上記通信装置を審査する審査手順とを有するものである。
このような審査方法において、上記審査手順に、上記受信手順で受信した公開鍵証明書の内容と、上記取得手順で取得した情報とが一致するか否かに基づいて上記公開鍵証明書が適切なものであるか否かを判断する手順を設けるとよい。

また、この発明は、公開鍵暗号を用いた認証処理を行う通信装置から、その通信装置の私有鍵と、その通信装置の識別情報とを受信する受信手順と、その手順で受信した識別情報と対応する公開鍵を、その識別情報をもとに上記通信装置とは異なる場所から取得する取得手順と、その手順で取得した公開鍵と上記受信手順で受信した私有鍵とが対応するものであるか否かに基づいて上記通信装置を審査する審査手順とを有する審査方法も提供する。
このような審査方法において、上記各手順を実行する装置に、通信装置の識別情報とその通信装置が上記認証処理に使用する公開鍵との対応関係を記憶させておくようにするとよい。
さらに、上記審査手順に、上記取得手順で取得した公開鍵と上記受信手順で受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて上記審査を行う手順を設けるとよい。

また、上記の各審査方法におて、上記通信装置が上記審査手順における審査に合格した場合に、上記通信装置に、その通信装置の新たな公開鍵証明書を送信する送信手順をさらに設けるとよい。
さらに、上記送信手順で送信する公開鍵証明書を、上記受信手順で受信した上記通信装置の識別情報を含む公開鍵証明書とするとよい。

また、この発明のプログラムは、コンピュータを、公開鍵暗号を用いた認証処理を行うがその認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、その通信装置の公開鍵証明書と、その通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、上記識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて上記通信装置を審査する審査手段として機能させるためのプログラムである。
このようなプログラムにおいて、上記審査手段に、上記受信手段が受信した公開鍵証明書の内容と上記取得手段が取得した情報とが一致するか否かに基づいて上記公開鍵証明書が適切なものであるか否かを判断する機能を設けるとよい。

また、この発明は、コンピュータを、公開鍵暗号を用いた認証処理を行う通信装置から、その通信装置の私有鍵と、その通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵を、その識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した公開鍵と上記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて上記通信装置を審査する審査手段として機能させるためのプログラムも提供する。
このようなプログラムにおいて、上記コンピュータを、通信装置の識別情報とその通信装置が上記認証処理に使用する公開鍵との対応関係を記憶する手段として機能させるためのプログラムを更に含めるとよい。
さらに、上記審査手段に、上記取得手段が取得した公開鍵と上記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて上記審査を行う機能を設けるとよい。

また、上記の各プログラムにおいて、上記コンピュータを、上記通信装置が上記審査手段による審査に合格した場合に、上記通信装置に、その通信装置の新たな公開鍵証明書を送信する送信手段として機能させるためのプログラムを更に含めるとよい。
さらに、上記送信手段が送信する公開鍵証明書を、上記受信手段が受信した上記通信装置の識別情報を含む公開鍵証明書とするとよい。

また、この発明の記録媒体は、上記のいずれかのプログラムを記録したコンピュータ読み取り可能な記録媒体である。

以上のようなこの発明の審査装置、通信システム、あるいは審査方法によれば、安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、なりすましを効果的に防止できるようにすることができる。
また、この発明のプログラムによれば、コンピュータを上記の審査装置として機能させてその特徴を実現し、同様な効果を得ることができる。この発明の記録媒体によれば、上記のプログラムを記憶していないコンピュータにそのプログラムを読み出させて実行させ、上記の効果を得ることができる。

以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明の審査装置と、その審査装置を用いて構成したこの発明の通信システムの実施形態の構成について説明する。
図１にその通信システムの構成を示す。
この実施形態においては、図１に示すように、審査装置である管理装置３０及びその通信相手となる通信装置である管理対象機器４０によって通信システムを構成している。
そして、この通信システムにおいて、管理装置３０は、管理対象機器４０と通信を行おうとする場合、公開鍵暗号とデジタル証明書（公開鍵証明書）を用いる認証方式であるＳＳＬプロトコルに従った認証処理によって管理対象機器４０を正当な通信相手として認証した場合に、管理対象機器４０との間で通信を確立させるようにしている。そして、管理装置３０が送信した動作要求（コマンド）に対し、管理対象機器４０が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。

逆に、管理対象機器４０が管理装置３０と通信を行おうとする場合にも、同じくＳＳＬに従った認証処理によって管理装置３０を正当な通信相手として認証した場合に、管理装置３０との間で通信を確立させるようにしている。そして、管理対象機器４０が送信した動作要求（コマンド）に対し、管理装置３０が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。
どちらの場合も、通信を要求する側がクライアント、要求される側がサーバとして機能するものとする。

なお、この通信システムにおいて、管理装置３０は、管理対象機器４０を管理する機能の他、管理対象機器４０に対し、通常使用する公開鍵証明書を用いて上記のようなＳＳＬによる認証ができなくなった状態で通常の認証を行うための公開鍵証明書を再発行する機能と、その再発行を行う場合において、その再発行先の管理対象機器４０を審査して再発行を行ってよいかどうか判断する機能も有する。
また、図１において、管理対象機器４０は１つしか示していないが、図２４に示すように管理対象機器４０を複数設けることも可能である。また、管理対象機器４０が１種類である必要もない。ただし、管理装置３０は１つの通信システムについて１つである。

このような通信システムにおいて、上述の管理装置３０と管理対象機器４０との間の通信は、ＲＰＣ（remote procedure call）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「要求」を送信し、この依頼された処理の結果である「応答」を取得することができるようになっている。
この、ＲＰＣを実現するためには、ＳＯＡＰ（Simple Object Access Protocol），ＨＴＴＰ（Hyper Text Transfer Protocol），ＦＴＰ（File Transfer Protocol）,ＣＯＭ（Component Object Model），ＣＯＲＢＡ（Common Object Request Broker Architecture）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。

次に、図１に示した各装置の構成と機能についてより詳細に説明する。
図１に示した管理装置３０及び管理対象機器４０は、装置の遠隔管理，電子商取引等の目的に応じて種々の構成をとることができる。例えば、遠隔管理の場合には、プリンタ，ＦＡＸ装置，コピー機，スキャナ，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム，自動車，航空機等の電子装置を被管理装置である管理対象機器４０とし、これらの被管理装置から情報を収集したり、コマンドを送って動作させたりするための管理装置を管理装置３０とすることが考えられる。

ここで、図２に管理装置３０のハードウェア構成例を示す。この図に示す通り、管理装置３０は、例えばＣＰＵ１１，ＲＯＭ１２，ＲＡＭ１３，ＨＤＤ１４，通信インタフェース（Ｉ／Ｆ）１５を設け、これらをシステムバス１６によって接続して構成することができる。そして、ＣＰＵ１１がＲＯＭ１２やＨＤＤ１４に記憶している各種制御プログラムを実行することによってこの管理装置３０の動作を制御し、通信相手の認証、管理対象機器４０との通信、管理対象機器４０の管理や審査、公開鍵証明書の発行等の機能を実現させている。
もちろん、管理装置３０として適宜公知のコンピュータを用いたり、必要に応じて他のハードウェアを付加したりしてもよい。

また、管理対象機器４０も、少なくともそれぞれＣＰＵ，ＲＯＭ，ＲＡＭ，ネットワークを介して外部装置と通信するための通信Ｉ／Ｆ、および認証処理に必要な情報を記憶する記憶手段を備え、ＣＰＵがＲＯＭ等に記憶した所要の制御プログラムを実行することにより、装置にこの発明に係る各機能を実現させることができるものとする。
なお、この管理装置３０と管理対象機器４０との間の通信には、有線，無線を問わず、ネットワークを構築可能な各種通信回線（通信経路）を採用することができる。

ここで、図３に、管理装置３０及び管理対象機器４０の、この実施形態の特徴に関連する部分の機能構成に係る機能ブロック図を示す。なお、図中の矢印は、後述するように管理対象機器４０が通常の公開鍵証明書を用いた認証を受けられなくなった状態で管理対象機器４０にその通常の公開鍵証明書を再発行場合のデータの流れを示すものである。
まず、管理装置３０は、ＨＴＴＰＳ（Hypertext Transfer Protocol Security）クライアント機能部３１，ＨＴＴＰＳサーバ機能部３２，認証処理部３３，証明書記憶部３４，証明書審査部３５，証明書発行部３６，コマンド発行部３７，要求管理部３８，コマンド処理部３９を備えている。

ＨＴＴＰＳクライアント機能部３１は、ＳＳＬに従った認証や暗号化の処理を含むＨＴＴＰＳプロトコルを用いて、管理対象機器４０等のＨＴＴＰＳサーバの機能を有する装置に対して通信を要求する機能を有する。
一方、ＨＴＴＰＳサーバ機能部３２は、ＨＴＴＰＳクライアントの機能を有する装置からのＨＴＴＰＳプロトコルを用いた通信要求を受け付ける機能を有する。
そして、これらのＨＴＴＰＳクライアント機能部３１とＨＴＴＰＳサーバ機能部３２とで、通信相手に対してコマンドやデータを送信してそれに応じた動作を実行させる機能と、通信相手から要求やデータを受信してそれに応じた動作を装置の各部に実行させ、その結果を応答として要求元に返す機能とを実現している。この場合において、通信を要求した側がコマンドを送信することもあるし、通信要求を受け付けた側がコマンドを送信することもある。応答についても同様である。

認証処理部３３は、ＨＴＴＰＳクライアント機能部３１やＨＴＴＰＳサーバ機能部３２が通信相手を認証する際に、通信相手から受信した公開鍵証明書や、証明書記憶部３４に記憶している各種証明書、私有鍵等を用いて認証処理を行う認証手段の機能を有する。また、通信相手に認証を要求するために、証明書記憶部３４に記憶している公開鍵証明書をＨＴＴＰＳクライアント機能部３１やＨＴＴＰＳサーバ機能部３２を介して通信相手に送信する機能も有する。
証明書記憶部３４は、公開鍵証明書や私有鍵、ルート鍵証明書等の認証情報を記憶し、認証処理部３３における認証処理に供する機能を有する。そして、証明書記憶部３４が記憶している認証情報には、詳細は後述するが、通常の通信時の認証処理に使用する正規認証情報と、正規認証情報による認証ができなくなった場合の復旧に使用する非常用のレスキュー認証情報とがある。また、証明書記憶部３４は、証明書発行部３６が発行した公開鍵証明書及びその発行先や発行日に関する情報をデータベースとして記憶しておく機能も有する。

証明書審査部３５は、認証処理部３３がレスキュー認証情報により管理対象機器４０との間で認証処理を行った場合に、その管理対象機器４０から受信する機番や証明書等の情報をもとに、その管理対象機器４０に対して更新用の公開鍵証明書や私有鍵を発行してよいか否かを審査する機能を有する。証明書発行部３６は、証明書審査部３５が審査で発行してよいと判断した場合に、更新用の公開鍵証明書や私有鍵を発行し、これらを管理対象機器４０に送信する機能を有する。なお公開鍵証明書の発行については、管理対象機器４０が作成して送信してきた公開鍵にデジタル署名を付して返送するようにすることも考えられる。

コマンド発行部３７は、管理対象機器４０に対して種々のコマンドを発行して管理対象機器４０にそのコマンドに従った動作を実行させる機能を有する。管理対象機器４０に実行させる動作としては、管理対象機器４０の動作内容や設定状態に関する情報の送信、管理装置３０から送信した更新用の公開鍵証明書を始めとする情報の記憶やそれに応じた設定変更等が考えられる。そして、コマンド発行部３７は、管理対象機器４０から取得した情報に従って管理対象機器４０に種々の動作を実行させることにより、管理対象機器４０を管理する機能も有する。

要求管理部３８は、管理装置から受信したコマンドについて、そのコマンドに基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、そのコマンドに基づいた動作を実行する機能部に対してコマンドを伝える機能も有する。なお、コマンドに基づいた動作を実行する機能部は、実際には複数の独立したモジュールとして構成することが考えられるが、図３においてはコマンド処理部３９として一括して示している。そして、このコマンド処理部３９が実行する動作としては、例えば管理対象機器４０からの異常発生通知に対する対応や、管理対象機器４０からの要求に応じて管理装置３０が記憶しているデータを送信する動作等が挙げられる。
以上の各部の機能は、管理装置３０のＣＰＵが所要の制御プログラムを実行して管理装置３０の各部の動作を制御することにより実現される。

次に、管理対象機器４０には、ＨＴＴＰＳクライアント機能部４１，ＨＴＴＰＳサーバ機能部４２，認証処理部４３，コール通知部４４，定期通知部４５，証明書記憶部４６，証明書通知部４７，要求管理部４８，証明書設定部４９，コマンド処理部５０を備えている。
ＨＴＴＰＳクライアント機能部４１は、管理装置３０のＨＴＴＰＳクライアント機能部３１と同様に、ＨＴＴＰＳプロトコルを用いて管理装置３０等のＨＴＴＰＳサーバの機能を有する装置に対して通信を要求すると共に、コマンドやそれに対する応答を送受信する機能を有する。

ＨＴＴＰＳサーバ機能部４２も、管理装置３０のＨＴＴＰＳサーバ機能部３２と同様であり、ＨＴＴＰＳクライアントの機能を有する装置からの通信要求を受け付けると共に、コマンドやそれに対する応答を送受信する機能を有する。
認証処理部４３の機能も、管理装置３０の認証処理部３３と同様であるが、認証処理に使用する証明書等は、証明書記憶部４６に記憶しているものである。

コール通知部４４は、異常を検知したりユーザによる指示があったりした場合に管理装置３０に対してその旨を通知するコールを行う機能を有する。
定期通知部４５は、管理対象機器４０から管理装置３０への定期的な通知を行う機能を有する。その通知の内容としては、例えば画像形成装置であれば画像形成枚数カウンタのカウント値、計量システムであればその計量値等が考えられる。

証明書記憶部４６は、管理装置３０の証明書記憶部３４と同様に各種の証明書や私有鍵等の認証情報を記憶し、認証処理部４３における認証処理に供する証明書記憶手段の機能を有する。ただし、記憶している証明書等は、後述するように証明書記憶部３４とは異なる。
証明書通知部４７は、正規認証情報による認証が受けられなくなり、レスキュー認証情報により管理装置３０に認証を受けた場合等、管理装置３０に正規認証情報を用いた審査を受ける必要がある場合に、管理装置３０に、管理対象機器４０の機番と共にそれまで使用していた正規認証情報を送信し、管理装置３０における管理対象機器４０の審査に供する機能を有する。

要求管理部４８は、管理装置３０から受信したコマンドについて、そのコマンドに基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、そのコマンドに基づいた動作を実行する証明書設定部４９及びコマンド処理部５０のような機能部に対してコマンドを伝える機能も有する。
図４にこの実行可否の判断基準を示すが、その判断基準は、コマンドの種類及び認証処理部４３において認証処理に使用した認証情報の種類である。要求管理部４８は、図４に示すように、正規認証情報による認証を行った場合には全ての動作を許可するが、レスキュー認証情報による認証を行った場合には証明書（私有鍵も含む）の設定動作のみを許可するようにしている。なお、ここでは設定（更新も含む）する証明書は正規認証情報を構成する証明書のみとし、レスキュー認証情報を構成する証明書は設定しないものとする。従って、レスキュー認証情報は、管理対象機器４０に新たな正規認証情報を記憶させる場合のみに使用する認証情報ということになる。

証明書設定部４９は、管理装置３０から受信したコマンドに応じて更新用の公開鍵証明書等を、認証処理に使用するものとして証明書記憶部４６に設定し、公開鍵証明書等を更新する機能を有する。
コマンド処理部５０は、管理装置３０から受信したコマンドに応じた動作を実行する機能を有する。この動作としては、例えば管理対象機器４０が記憶しているデータの送信や、必要に応じて図示を省略したエンジン部の動作を制御することが挙げられる。なお、コマンドに基づいた動作を実行する機能部は、管理装置３０のコマンド処理部３９の場合と同様、実際には複数の独立したモジュールとして構成することが考えられる。そして、上記の証明書設定部４９は、このようなモジュールの１つであると考えられる。
そして、これらの各部の機能は、管理対象機器４０のＣＰＵが所要の制御プログラムを実行して管理対象機器４０の各部の動作を制御することにより実現される。

次に、図５に、上述した管理装置３０及び管理対象機器４０が認証処理に用いる各証明書や鍵の種類を示す。この図において、（ａ）に管理対象機器４０の証明書記憶部４６に記憶している証明書及び鍵の種類を示し、（ｂ）に管理装置３０の証明書記憶部３４に記憶している証明書及び鍵の種類を示している。なお、これらの図には、各装置が通信相手との間の認証処理に使用する証明書及び鍵のみを示している。
この図に示すように、管理装置３０及び管理対象機器４０は、大きく分けて正規認証情報とレスキュー認証情報を記憶している。そして、これらの正規認証情報とレスキュー認証情報は、それぞれ自分に関する認証情報である公開鍵証明書及び私有鍵と、通信相手に関する認証情報であるルート鍵証明書とによって構成される。また、正規認証情報が通常の通信時の認証処理に使用する認証情報であり、レスキュー認証情報は正規認証情報による認証ができなくなった場合の復旧処理時に使用する非常用の認証情報である。
そして、各装置は、通信時にはこれらの認証情報を用いて通信相手とＳＳＬに従った図２５に示したような手順の相互認証あるいは図２７に示したような片方向認証を行う。

ここで、公開鍵証明書のフォーマットは、例えば図６に示したものを用いることができ、公開鍵そのものの他、証明書の発行者や有効期限及びシリアル番号、証明される対象（証明書の発行先の装置あるいは利用者）等の情報が記載されている。このような公開鍵証明書は、具体的には、例えばＸ．５０９と呼ばれるフォーマットに従って作成することができる。

図７に、上記のＸ．５０９フォーマットに従って作成された管理対象機器用通常公開鍵証明書の例を示す。
この例においては、Ａが公開鍵証明書のシリアル番号を示す。また、Ｂが公開鍵証明書を発行した（公開鍵にデジタル署名を付した）管理装置３０の識別情報を、Ｄが証明書の発行先である管理対象機器４０の識別情報をそれぞれ示す。これらは、それぞれ所在地、名称、機番あるいはコード等の情報を含む。ただし、発行先の装置について、機番のように個々の装置を識別できるような識別情報を記載することは必須ではない。また、Ｃが有効期間を示し、その開始日時と終了日時とによって有効期間を指定している。Ｅが、管理対象機器用通常公開鍵の本体である。

また、管理対象機器用通常私有鍵は、上記の管理対象機器用通常公開鍵と対応する私有鍵、管理対象機器認証用通常ルート鍵証明書は、管理対象機器認証用通常ルート鍵に自身と対応するルート私有鍵を用いて自身で正当性を確認可能なデジタル署名を付したデジタル証明書である。
なお、管理対象機器４０を複数設けた場合でも、各装置の管理対象機器用通常公開鍵に付すデジタル署名は同じルート私有鍵を用いて付し、正当性確認に必要なルート鍵証明書は共通にする。しかし、管理対象機器用通常公開鍵証明書に含まれる公開鍵やこれと対応する私有鍵は、装置毎に異なる。
管理装置用通常公開鍵証明書と管理装置用通常私有鍵と管理装置認証用通常ルート鍵証明書も同様な関係である。

そして、例えば管理装置３０と管理対象機器４０とが相互認証を行う場合には、管理対象機器４０からの通信要求に応じて、管理装置３０は管理装置用通常私有鍵を用いて暗号化した第１の乱数を管理装置用通常公開鍵証明書と共に管理対象機器４０に送信する。管理対象機器４０側では管理装置認証用通常ルート鍵証明書を用いてまずこの管理装置用通常公開鍵証明書の正当性（損傷や改竄を受けていないこと）を確認し、これが確認できた場合にここに含まれる公開鍵で第１の乱数を復号化する。この復号化が成功した場合に、管理対象機器４０は通信相手の管理装置３０が確かに管理装置用通常公開鍵証明書の発行先であると認識でき、その証明書に含まれる識別情報から装置を特定することができる。そして、特定した装置が通信相手としてふさわしいか否かに応じて認証の成功と失敗を決定することができる。

また、管理装置３０側でも、管理対象機器４０側で認証が成功した場合に送信されてくる管理対象機器用通常公開鍵証明書及び、管理対象機器用通常私有鍵で暗号化された乱数を受信し、記憶している管理対象機器認証用通常ルート鍵証明書を用いて同様な認証を行うことができる。
なお、この手順は管理対象機器４０がＨＴＴＰＳクライアント機能部４１によって管理装置３０のＨＴＴＰＳサーバ機能部３２に対して通信を要求する場合の処理であり、管理装置３０がＨＴＴＰＳクライアント機能部３１によって管理対象機器４０のＨＴＴＰＳサーバ機能部４２に対して通信を要求する場合には、使用する証明書や鍵は同じであるが、管理装置３０と管理対象機器４０の処理が逆になる。

ところで、ここまでの説明から明らかなように、各装置が通信相手に対して通常公開鍵証明書を送信した場合でも、証明書が破損していたり、証明書の有効期限が切れていたりした場合には、認証を行うことができない。そして、このような事態は、認証情報の更新処理中に電源が切られて更新が失敗したり、装置の電源が入れられないまま放置されて証明書の有効期限内に更新が行えなかったりした場合には十分起こり得る。

ここで、各装置が通常公開鍵証明書を用いた認証しか行えないとすると、通常公開鍵証明書が破損したり有効期間が過ぎてしまったりしている状態では、新たな通常公開鍵証明書や通常私有鍵及び通常ルート鍵証明書をネットワークを介して安全に対象の装置に送信する方法はないことになる。しかし、この通信システムを構成する各装置は、このような事態に対処するためにレスキュー認証情報を記憶しており、通信相手を異なる２種類のデジタル証明書を用いて認証することができるようにしている。そして、レスキュー認証情報を用いることにより、管理装置３０から管理対象機器４０にネットワークを介して新たな通常公開鍵証明書等を安全に送信できるようにしている。

このレスキュー認証情報は、正規認証情報と概ね同様な構成となっており、例えば管理対象機器用レスキュー公開鍵証明書は、図示しないレスキューＣＡが作成したレスキュー公開鍵に、管理対象機器認証用レスキュールート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。また、管理対象機器用レスキュー私有鍵はそのレスキュー公開鍵と対応する私有鍵、管理対象機器認証用レスキュールート鍵証明書は、管理対象機器認証用レスキュールート鍵に自身を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。

そして、このようなレスキュー認証情報としては、例えば、レスキュー公開鍵証明書が、装置の識別情報が付されていないデジタル証明書であるものを使用することが考えられる。
この場合、同じ階位の装置（図１に示した例では、管理装置及び管理対象機器の階位が存在するものとする）には、全て同じレスキュー公開鍵証明書を記憶させるようにすることができる。同じ階位の各装置を個別に区別する必要がないので、証明書に含まれるレスキュー公開鍵及びこれと対応するレスキュー私有鍵も含めて、全く共通のものでよいためである。また、通信相手のレスキュー公開鍵証明書が全て同じであることから、ルート鍵証明書については、ある階位の装置の通信相手となる全ての装置について共通となる。すなわち、図２４に示すように、管理対象機器を複数設けた場合でも、全ての管理対象機器に同じレスキュー認証情報を記憶させることになる。
これは、管理装置３０のレスキュー認証情報についても同様である。

また、このようなレスキュー公開鍵証明書も、通常公開鍵証明書と同様なフォーマットで作成することができ、例えば図８に示したものとすることが考えられる。この場合において、例えば、符号Ｇで示すように発行先装置の機番（ＣＮ）として０を記載して共通証明書であることを示すことが考えられる。また、発行元ＣＡの情報として、符号Ｆで示すようにレスキューＣＡの識別情報を記載している。

このようなレスキュー認証情報は、同じ階位の装置について全て共通であるという特性から、装置の製造時にその機種に応じて定まる階位に応じたものを記憶させてしまうことができる。すなわち、装置の識別情報を付した情報ではないため、検査工程を終了して識別番号を付した各装置に対してそれぞれ個別の証明書を用意して記憶させる必要はなく、多数の装置に対して単純作業によって記憶させることができる。例えば、制御プログラムのマスタにレスキュー認証情報を含めておき、制御プログラムを装置にコピーする際にレスキュー認証情報も共に記憶させる等である。

そして、その後レスキュー認証情報を更新しないようにすれば、上記のように正規認証情報の更新が行えなかったり破損してしまったりして通常公開鍵証明書による認証が行えなくなった場合でも、レスキュー認証情報に含まれるレスキュー公開鍵証明書を用いた認証が可能な状態を保つことができる。
また、レスキュー公開鍵証明書やレスキュールート鍵証明書を更新しないようにすることを考えると、その有効期間を長くし、実質的に発行先装置の使用中に有効期限が来ないように設定することが好ましい。例えば、図８に示した例では、有効期間を５０年に設定している。

ここで、装置の識別情報を付さないレスキュー公開鍵証明書を用いる場合には、その証明書を用いた認証を行った場合でも、通信相手の装置を具体的に特定することはできない。しかし、通信相手についてある程度の情報は得ることができる。
すなわち、例えばあるベンダーが自社製品のうち管理対象機器４０に該当する装置全てに管理対象機器用のレスキュー認証情報（管理対象機器用レスキュー公開鍵証明書，管理対象機器用レスキュー私有鍵及び管理装置認証用レスキュールート鍵証明書）を記憶させ、その通信相手となる管理装置３０に該当する装置全てに管理装置用のレスキュー認証情報（管理装置用レスキュー公開鍵証明書，管理装置用レスキュー私有鍵及び管理対象機器認証用レスキュールート鍵証明書）を記憶させておけば、管理対象機器４０は、自己の記憶している管理装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してくる相手が同じベンダーの管理装置３０であることを認識できるし、逆に管理装置３０も自己の記憶している管理対象機器認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してくる相手は同じベンダーの管理対象機器４０であることを認識できる。

そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができるので、その後機番情報等を交換して通信相手を特定することも可能である。
従って、通常公開鍵証明書に記載された識別情報を使用しなくても、通信相手を特定することは一応可能である。

なお、図５に示した認証情報において、通常ルート鍵証明書は認証対象によらず同じものを用いるようにしてもよい（管理装置認証用通常ルート鍵証明書と管理対象機器認証用通常ルート鍵証明書が同じものでもよい）。これは、通常証明書には装置の識別情報が付されているため、ルート鍵証明書を用いてその正当性を確認できれば、あとはその識別情報を参照して装置の機種や階位を特定できるためである。
しかし、公開鍵証明書に装置に識別情報を付さないレスキュー認証情報を採用する場合には、公開鍵証明書に装置の識別情報が付されていないため、装置の種類の区別を、特定のルート鍵証明書で正当性を確認できるか否かによって行うことになる。従って、この場合のレスキュールート鍵証明書は認証対象の階位毎に異なる必要がある。

ところで、ＳＳＬプロトコルに従った認証処理を行う場合には、サーバは、クライアントから通信要求があった時点ではクライアントの状態を知ることができないため、必然的に、特定のＵＲＬ（Uniform Resource Locator）にアクセスされた場合には常に同じ公開鍵証明書を返すことになる。従って、基本的には、１つのサーバが公開鍵証明書を複数持ち、通信相手が認証に使用しようとする公開鍵証明書の種類に合わせて適当なものを選択して送信するといった構成を取ることはできない。しかし、図１に示した各装置においては、特殊な構成を取ることにより、通常公開鍵証明書とレスキュー公開鍵証明書とを場合によって使い分けることができるようにしている。

そこで、次に、この使い分けのための構成を、図９を用いて説明する。
上述した通り、サーバは基本的には通信を要求してくるクライアントに対して特定の公開鍵証明書しか返すことができない。しかし、通信要求に係るＵＲＬが異なる場合には、ＵＲＬ毎に異なる公開鍵証明書を返すことも可能である。
従ってここでは、図９に示すように、管理装置３０及び管理対象機器４０にそれぞれ、通常公開鍵証明書による認証を行う通常ＵＲＬと、レスキュー公開鍵証明書による認証を行うレスキューＵＲＬとを設け、通信を要求する側（クライアントとして機能する側）が、要求する認証の種類に応じていずれかのＵＲＬを選択的に指定して通信要求を送るようにしている。

管理装置３０と管理対象機器４０との間の通信プロトコルにＳＳＬを採用する場合、通信に使用するポートは４４３が一般的なので、通常ＵＲＬとレスキューＵＲＬとではＩＰアドレスを変更する必要がある。従って、管理装置３０及び管理対象機器４０は、それぞれ別々のＩＰアドレスを設定可能な複数の部分（別々の筐体でも同一の筐体でもよい）からなる装置として構成することになる。

このようにした場合、通信を要求される側（サーバとして機能する側）は、通信要求を、受け付けたＵＲＬによって区別し、通常ＵＲＬで受け付けた場合には通常公開鍵証明書を返し、レスキューＵＲＬで受け付けた場合にはレスキュー公開鍵証明書を返すようにすることができる。
なお、通信を要求するクライアントの側では、どのＵＲＬに対して通信要求を送ったかがわかるので、相互認証を行う場合にはそのＵＲＬに応じた適切な公開鍵証明書を選択して送信することができる。

そして、管理対象機器４０が管理装置３０と通信しようとする場合には、まず通常公開鍵証明書を用いた認証を試みるが、この認証が通常公開鍵証明書の破損や有効期間経過等のため失敗した場合、レスキュー公開鍵証明書を用いた認証を試みるようにしている。また、管理装置３０が通信相手として適当な装置であれば、通常はレスキュー証明書を用いた認証が成功するので、管理装置３０には、その認証が成功した場合に、管理対象機器４０の正規認証情報を更新する機能を設けている。

すなわち、管理対象機器４０は管理装置３０に対して通信を要求する場合、まず通常ＵＲＬに通信要求を送信して通常公開鍵証明書を用いた認証を行うが、これが失敗した場合に、今度はレスキューＵＲＬに通信要求を送信してレスキュー公開鍵証明書を用いた認証を行う。
そして、管理装置３０は、管理対象機器４０をレスキュー公開鍵証明書を用いて認証し、通信相手として適切と判断した場合には、更新用の正規認証情報を発行し、管理対象機器４０に送信してこれを記憶するよう要求するようにしている。

レスキュー公開鍵証明書を用いた認証であっても、共通鍵の共有は通常公開鍵証明書の場合と同様に可能であるから、証明書等の送信は共有した共通鍵を用いて暗号化して安全に行うことができる。なお、ここで送信する証明書等は図１０に示すものであり、管理対象機器４０に記憶させる正規認証情報を構成するものである。そしてもちろん、更新用の管理対象機器用通常公開鍵証明書は、有効期間内のものである。なお、図１０に示した証明書等をセットにし、証明書セットとして送信するようにしてもよい。

また管理対象機器４０は、上記の要求を受けた場合に、受信した証明書等を証明書設定部４９によって証明書記憶部４６に記憶させ、それまでの正規認証情報を更新するようにしている。
この更新が正常に行われれば、管理対象機器４０には再び有効期間内かつ破損等していない通常公開鍵証明書が記憶されることになり、通常公開鍵証明書を用いた認証を行うことができる状態になる。従ってこの後は、通常公開鍵証明書を用いた認証を行って通信を実行するようにすればよい。

しかし、このような正規認証情報の更新を行う場合において、レスキュー公開鍵証明書として、上述のように発行対象装置の機番が記載されていないものを用いる場合には、通信を要求してきた管理対象機器４０の機番について、管理装置３０は、通信経路の確立後に管理対象機器４０が送信してくるものを信用することになる。そして、この機番は、例えば管理対象機器４０が不揮発メモリに記憶しているものであるが、この情報自体には、通常はデジタル署名のような改竄防止の措置は講じられていないので、比較的容易に改竄し、他の装置になりすますことが可能な状態である。
そこで、この通信システムにおいては、管理装置３０側に、レスキュー認証情報を用いて管理対象機器４０を認証した場合に、管理対象機器４０が送信してくる機番の信憑性を確認するための審査を行うようにしている。そして、この審査は、管理対象機器４０に、認証を受けた時点で記憶している正規認証情報を送信させ、それが管理対象機器４０が送信してきた機番と対応するものであるか否かを調べることによって行うようにしている。

次に、このような正規認証情報とレスキュー認証情報の２種類の認証情報を用いた証明書の更新に関する処理について説明する。
まず、図１１のシーケンス図に、更新処理全体の流れを示す。なおここでは、管理対象機器４０に記憶している管理対象機器用通常公開鍵証明書が、破損又は有効期間の経過等により、認証を受けられない状態になっていた場合の処理例を示す。

この例においては、まず管理対象機器４０が、管理装置３０と通信する際に、通信要求を送信すべきＵＲＬを確認し（Ｓ１１）、ＨＴＴＰＳクライアント機能部４１を対管理装置クライアントとして機能させて、確認した通常ＵＲＬに通信要求を送信する（Ｓ１２）。この場合、管理装置３０側ではＨＴＴＰＳサーバ機能部３２が通信要求を受け、認証処理部３３にこの要求を伝える。また、管理装置３０は通常公開鍵証明書を用いた認証を要求されたことになる。そして認証処理部３３は、ＳＳＬプロトコルに従い、証明書記憶部３４に記憶している管理装置用通常私有鍵で暗号化した第１の乱数と共に、同じく証明書記憶部３４に記憶している管理装置用通常公開鍵証明書を管理対象機器４０に返す（Ｓ１３）。

管理対象機器４０側では、これを認証処理部４３に渡して認証処理を行うが、ここでは受信した管理装置用通常公開鍵証明書の正当性は証明書記憶部４６に記憶している管理装置認証用通常ルート鍵証明書を用いて確認できるため、認証成功と判断し（Ｓ１４）、証明書記憶部４６に記憶している管理対象機器用通常私有鍵で暗号化した第２の乱数と共に、同じく証明書記憶部４６に記憶している管理対象機器用通常公開鍵証明書を管理装置３０に返す。またここでは、図示は省略したが、ステップＳ１３で受信した管理装置用通常公開鍵を用いて暗号化した共通鍵の種も第２の乱数と共に返す（Ｓ１５）。
管理装置３０側では、これらを認証処理部３３に渡して認証処理を行うが、ここでは受信した管理対象機器用通常公開鍵証明書が認証を受けられない状態であるため、認証失敗と判断する（Ｓ１６）。従って、管理対象機器４０との間の通信を切断する。

すると、管理対象機器４０は、通常公開鍵証明書を用いて認証を受けることができなかったため、今度はレスキューＵＲＬに通信要求を送信する（Ｓ１７，Ｓ１８）。そして、今度はレスキュー認証情報を用いて管理装置３０との間で相互認証を試みる（Ｓ１９〜Ｓ２１）。なお、この処理の内容は、用いる認証情報の種類が異なるのみで、ステップＳ１３〜Ｓ１５の場合と同じ処理であるから、説明を省略する。

そして、今度は認証が成功するので（Ｓ２２）、管理装置３０はその旨の応答を管理対象機器４０に返す（Ｓ２３）。すると、管理対象機器４０はそれに応じて機番等及び証明書記憶部４６に記憶している正規認証情報を管理装置３０に送信する（Ｓ２４）。そして、管理装置３０の証明書審査部３５がこれらの情報をもとに管理対象機器４０を審査し、更新用の証明書を発行してよいと判断すると（Ｓ２５）、証明書発行部３６が更新用の証明書を発行すると共に、証明書記憶部３４の証明書データベースに発行した公開鍵証明書や発行先装置の識別情報等を登録する（Ｓ２６）。
そしてその後、証明書設定コマンドと共に発行した更新用証明書を管理対象機器４０に転送する（Ｓ２７）。

すると、管理対象機器４０は、証明書設定コマンドに付された更新用証明書を、管理装置３０との通信の際に使用する正規認証情報として設定し（Ｓ２８）、設定結果について管理装置３０に応答を返す（Ｓ２９）。以上で、レスキュー認証情報を用いた管理対象機器４０の通常証明書更新の処理が終了する。
なお、以上の処理において、更新用証明書と共に私有鍵やルート鍵証明書の発行や設定を行う必要があれば、これらも共に発行や設定を行うようにするし、発行や設定を、公開鍵証明書と私有鍵とルート鍵証明書とをセットにした証明書セットの形で行うようにしてもよい。

図１に示した通信システムにおいては、管理対象機器４０において正規認証情報を構成する公開鍵証明書が認証を受けられない状態になってしまった場合でも、以上の処理により、管理対象機器４０の証明書を更新して認証が正常に行える状態に回復させるようにしている。また、正規認証情報を構成する私有鍵やルート鍵証明書が破損等した場合でも、ステップＳ１１乃至Ｓ１６での認証処理が失敗する段階が異なるのみであり、ステップＳ１７以降については上述の処理と同様である。

ここで、図１２及び図１３に、管理装置３０の証明書記憶部３４に設ける証明書データベースの構成例を示す。
これらの図に示すように、ここでは証明書データベース中に２つのテーブルを設けている。そして、図１２に示す第１のテーブルには、公開鍵証明書の発行先装置（管理対象機器）の識別情報である機番と、その装置に発行した最新の公開鍵証明書のシリアル番号（以下単に「シリアル」ともいう）、及びその公開鍵証明書の発行日時の情報を対応させて登録している。

また、図１３に示す第２のテーブルには、公開鍵証明書のシリアルと、その公開鍵証明書の内容とを対応させて登録している。ここでは、公開鍵証明書の内容として、図７に示したような書誌事項を含む公開鍵証明書をそのまま登録するようにしているが、これに加えてまたはこれに代えて、有効期限や発行先装置の国や地域等、書誌情報中の所定の項目を抽出して登録するようにしてもよい。
そして、第２のテーブルには、公開鍵証明書を発行した時点でその証明書の登録を行い、第１のテーブルの内容は、管理対象機器４０から設定成功の応答があった後で更新するようにするとよい。
以上のようなテーブルを用意することにより、管理装置３０は、管理対象機器４０の機番をキーに、その装置が記憶しているはずの公開鍵証明書（設定が失敗していなければ、その装置に発行した最新の公開鍵証明書である）を証明書データベースから取得することができる。

なお、図１２及び図１３に示すようにテーブルを２つ用意したのは、管理対象機器４０に新たな公開鍵証明書を発行した場合でも、過去に発行したものも含め、全ての公開鍵証明書を記憶しておくようにするためである。また、私有鍵については、発行先の装置以外が保持しておくことは好ましくないため、ここではテーブルに登録しないようにしている。ルート鍵証明書については、多数の管理対象機器４０について同じものを記憶させていることから、図示しない別のテーブルで管理し、公開鍵証明書中の、証明書のバージョン情報をキーに取得できるようにし、データ量の低減を図っている。

次に、図１１に示したような更新処理を行う場合に管理対象機器４０が実行する処理について、より詳細に説明する。図１４に、その処理のフローチャートを示す。この処理は、管理対象機器４０のＣＰＵが所要の制御プログラムを実行して行うものである。
管理対象機器４０は、管理装置３０に対してコマンドや通知を送信したり、管理装置３０からのコマンドや通知を受け取るためにポーリングを行ったりする場合、図１４のフローチャートに示す処理を開始し、まずステップＳ４１で管理装置３０の通常ＵＲＬに対して通信要求を送信する。なお、管理対象機器４０は、通信相手となる管理装置３０について、通信要求先として通常ＵＲＬとレスキューＵＲＬとを記憶しているものとする。

そして、まずステップＳ４２で、管理装置３０との間で通常公開鍵証明書及び乱数や共通鍵の種を送受信し、図２５に示したようなＳＳＬによる相互認証処理を行う。そして、ステップＳ４３でこの認証が成功したか否か判断し、成功していれば、管理装置３０との間で通信を確立してステップＳ４４以下に進んで通常の通信に係る処理を行う。なお、ステップＳ４２での認証は、相互認証が好ましいが、少なくとも管理装置３０が管理対象機器４０を認証できれば、相互認証でも片方向認証でも構わない。

以下の処理においては、まずステップＳ４４で、ステップＳ４２の認証処理で送信した共通鍵の種から共通鍵を生成する。そして、ステップＳ４５でコマンド及び受信したコマンドに対する応答をその共通鍵で暗号化して通信中の装置（ここでは管理装置３０）に送信し、ステップＳ４６でコマンド及び送信したコマンドに対する応答を同じ共通鍵で暗号化された状態で通信中の装置から受信する。そして、ステップＳ４７でコマンド及び応答を全て送受信したか否か判断する。そして、まだ残っていればステップＳ４５に戻って処理を繰り返し、全て送受信していればステップＳ４８に進んで通信を切断し、処理を終了する。

なお、ステップＳ４５及びＳ４６の処理は、順不同で構わないし、送受信すべきコマンドや応答がなければ省略する。また、受信したコマンドに係る処理を実行して応答を生成する処理や、受信した応答の内容を解釈してそれに対応した動作を行う処理は、受信したコマンドや応答を記憶しておき、図１４に示したフローチャートとは別に実行するものとする。
一方、ステップＳ４３で認証が失敗した場合には、ステップＳ４９以下に進み、レスキュー認証情報を利用して更新用証明書の取得を試みる処理を行う。なお、認証失敗の原因が、通信異常等、証明書の異常に起因しないものである場合には、この処理を行わないようにしてもよい。

ステップＳ４９以下の処理においては、まずステップＳ４９で、管理装置３０のレスキューＵＲＬに対して通信要求を送信する。そして、ステップＳ５０で、管理装置３０との間でレスキュー公開鍵証明書及び乱数や共通鍵の種を送受信し、図２５に示したようなＳＳＬによる相互認証処理を行う。
そして、ステップＳ５１でこの認証が成功したか否か判断する。ここで認証が失敗した場合にはそのままステップＳ４８で通信を切断して処理を終了するが、認証が成功していれば、管理装置３０との間で通信を確立してステップＳ５２以下に進み、更新用証明書の取得と設定に関する処理を行う。

すなわち、まずステップＳ５２で、ステップＳ５０の認証処理で送信した共通鍵の種から共通鍵を生成する。そして、ステップＳ５３で、その共通鍵で暗号化した機番等の情報を管理装置３０に送信すると共に、ステップＳ５４で、証明書記憶部４６に記憶している正規認証情報を同じ共通鍵で暗号化して管理装置３０に送信する。これらのステップＳ５３及びＳ５４の送信は、必要な情報を１つのメッセージに記載して行ってもよい。
ステップＳ５３及びＳ５４で送信した情報は、管理装置３０において、管理対象機器４０に更新用の証明書を発行してよいか否かを確認するための審査を行うために使用され、また更新用の証明書に記載する管理対象機器４０の識別情報としても使用される。

また、ステップＳ５３で送信する機番以外の情報としては、例えばそれまでの正規認証情報が使用できなくなった原因の通知が考えられる。そして、通知する原因としては例えば、証明書記憶部４６を構成するメモリユニットを交換した、装置がネットワークに接続されていなかったため証明書の自動更新ができなかった、証明書の更新中に電源を切られたためデータが破壊された、等が考えられる。
また、ステップＳ５４で送信する正規認証情報は、ステップＳ４２の処理において認証処理に使用しようとしたものであり、破損していたり、公開鍵証明書の有効期限が切れていたりして、正常に認証を受けることができない状態となっているものである。しかし、ここで送信するのは、管理装置３０における審査に供するためであり、審査の基準はＳＳＬによる認証処理の場合とは異なるので、このような状態であっても構わずに送信する。また、私有鍵は本来は他の装置に送信しないものであるが、ここでは既に対応する公開鍵証明書が認証に使用できない状態になっているものであるから、送信により私有鍵が他の装置に知られてしまったとしても、特に問題ない。

さらに、正規認証情報には図５に示した通り公開鍵証明書と私有鍵とルート鍵証明書とが含まれるが、これら全てを送信することは必須ではない。さらにまた、正規認証情報の全部又は一部に欠落がある場合には、欠落している旨の情報を送信するようにしてもよいし、単に欠落している情報を送信しないようにするだけにしてもよい。
ステップＳ５４の後は、ステップＳ５５で、管理装置３０からの証明書設定コマンドの受信を待つ。上述したように、レスキュー公開鍵証明書を用いた認証を行った場合には、これ以外の要求に係る動作は行わないようにしている。

そして、証明書設定コマンドを受信すると、ステップＳ５６に進み、証明書設定コマンドと共に受信した証明書を記憶し、これを管理装置３０との通信に使用する正規認証情報として設定する。
これが完了すると、ステップＳ５７で応答を返し、ステップＳ５８で通信を切断して自身を再起動する。この再起動は、管理対象機器４０において重要な設定を変更する際に必要なものであり、ここでは証明書の設定がこれに該当する。再起動を行う際に、ユーザに再起動の許可を求めるようにしてもよい。また、図１４にはステップＳ５８の後処理を終了するように図示しているが、実際にはステップＳ５８での再起動時に処理は中断される。また、再起動は行わずに、そのまま処理を終了するようにしてもよい。

ところで、ここでは管理対象機器４０の通常公開鍵証明書が破損又は期限切れ等になった場合の証明書の更新について説明したが、それ以外の場合でも、証明書の更新時に管理装置３０が管理対象機器４０を審査することが好ましい場合がある。
図１５に、この場合の正規認証情報の更新処理全体の流れを示す。
この例においては、管理対象機器４０は、管理装置３０との間の認証処理に使用する公開鍵証明書の有効期限の一定期間前（例えば１ヶ月前）になったことを検出すると（Ｓ６１）、正規認証情報の更新時期になったと判断し、管理装置３０に対して更新用の公開鍵証明書等の送信を要求する証明書要求コマンドを、図１４のステップＳ４５による通常のコマンド送信時に管理装置３０へ送信するコマンドとして登録しておく。

その後、適当なタイミングで管理対象機器４０が管理装置３０の通常ＵＲＬに通信を要求し、その際、正規認証情報を用いて相互認証を行うが、ここでは認証情報に特に問題はないとすると、詳細な説明は図１１等の説明と重複するので省略するが、認証処理は成功する（Ｓ７１〜Ｓ７７）。なお、ここで使用する管理対象機器４０の公開鍵証明書は、共通公開鍵証明書である。
そして、認証が成功すると、管理対象機器４０は、管理装置３０に対し、ステップＳ６２で登録してある証明書要求コマンドを送信する（Ｓ７８）。またこのとき、機番等及び証明書記憶部４６に記憶している正規認証情報も管理装置３０に送信する。これらは、例えば証明書要求コマンドの引数として送信することができる。

そして、管理装置３０の証明書審査部３５がこれらの情報をもとに管理対象機器４０を審査し、更新用の証明書を発行してよいと判断すると（Ｓ７９）、証明書発行部３６が更新用の証明書を発行すると共に、証明書記憶部３４の証明書データベースに発行した公開鍵証明書や発行先装置の識別情報等を登録する（Ｓ８０）。
そしてその後、証明書設定コマンドと共に発行した更新用証明書を管理対象機器４０に転送する（Ｓ８１）。

すると、管理対象機器４０は、証明書設定コマンドに付された更新用証明書を、管理装置３０との通信の際に使用する正規認証情報として設定し（Ｓ８２）、設定結果について管理装置３０に応答を返す（Ｓ８３）。
以上で、管理対象機器４０の通常証明書更新の処理が終了する。なお、ステップＳ８０で発行する証明書は、ステップＳ７８で受信した機番を発行先装置の識別情報として記載した個別公開鍵証明書とするとよい。また、管理対象機器４０は、ステップＳ８１での証明書更新コマンドを、図１４のステップＳ４６に示した通常のコマンド受信処理で受信し、受信したコマンドに係る処理を実行するようにすることができる。

次に、図１６及び図１７に、図１１乃至図１５を用いて説明してきた正規認証情報の更新処理における、管理装置３０側の処理のフローチャートを示す。この処理は、管理装置３０のＣＰＵ１１がレスキューＵＲＬに通信要求を受けた場合に開始するものであり、所要の制御プログラムを実行して行うものである。また、ステップＳ９５以降の処理については、通常ＵＲＬに通信要求を受け、一般的なコマンド送受信において証明書要求コマンドを受信した場合に実行する、このコマンドに係る処理と共通なものである。なお、管理装置３０のＣＰＵが通常ＵＲＬに通信要求を受けた場合に行う一般的なコマンド送受信に関する処理については、図１６及び図１７に示す処理とは独立した一般的な処理であるので、ここでは説明を省略する。

図１６に示す処理においては、管理装置３０のＣＰＵ１１は、まずステップＳ９１で、通信要求の要求元の装置（ここでは管理対象機器４０）との間でレスキュー公開鍵証明書及び乱数と共通鍵の種を送受信し、図２５に示したようなＳＳＬによる相互認証処理を行う。
そして、ステップＳ９２でこの認証が成功したか否か判断する。ここで認証が失敗した場合にはそのまま図１７のステップＳ１０８に進んでで通信を切断して処理を終了するが、認証が成功していれば、通信要求の送信元との間で通信を確立してステップＳ９３以下に進み、通信要求の送信元の審査及び更新用証明書の設定に関する処理を行う。また、認証が成功した時点で、通信要求の送信元がいずれかの管理対象機器であることがわかる。ここでは通信要求の送信元が管理対象機器４０であるとして以後の説明を行う。

この処理においては、まずステップＳ９３で、ステップＳ９１の認証処理で受信した共通鍵の種から共通鍵を生成する。そして、ステップＳ９４で、その共通鍵で暗号化された機番等及び正規認証情報を管理対象機器４０から受信する。ただし、管理対象機器４０が正規認証情報の全てを送信して来たわけではない場合には、送信してきたもののみを受信することになり、ここで正規認証情報を全く受信できない場合もありうる。
このステップＳ９４の処理が受信手順の処理であり、この処理においては管理装置３０のＣＰＵ１１が受信手段として機能する。

ステップＳ９４の後は、ステップＳ９５に進み、ステップＳ９４で受信した機番について、その機番が通信相手として適切な装置のものであるか否か判断する。この処理を、証明書要求コマンド（送信元は管理対象機器４０とする）に係る処理として実行する場合には、証明書要求コマンドと共に受信した機番についてこの判断を行う。
そして、適切な装置のものでなければ、以後の審査を行うまでもなく、管理対象機器４０に更新用証明書を発行すべきでないことがわかる。そこで、そのまま図１７のステップＳ１０９に進み、審査不合格の旨及びその理由を記載したメッセージを管理対象機器４０に送信すると共に、ステップＳ１１０で管理装置３０のオペレータにも審査不合格の旨及びその理由を通知し、通信を切断して処理を終了する。このようになるケースとしては例えば、管理対象機器４０が管理装置３０による管理の対象になり得る装置であるが、管理契約が結ばれていない等の理由により管理装置３０に管理対象として登録されていない場合等が考えられる。

一方、ステップＳ９５で適切な装置のものであれば、ステップＳ９６に進み、ステップＳ９４で（又は証明書要求コマンドと共に、以下同じ）受信した機番をキーに証明書記憶部３４の証明書データベース（図１２及び図１３参照）を検索し、その機番の装置が記憶しているはずの最近の通常公開鍵証明書及び通常ルート鍵証明書の情報を取得する。この取得はもちろん管理対象機器４０とは異なる場所から行うものである。また、ここで取得するのは、公開鍵証明書やルート鍵証明書の全体であっても一部分であっても、これらから証明書のシリアル番号、発行先装置の識別情報、有効期限、発行日等の必要な情報を抽出したものであってもよい。ステップＳ９７乃至Ｓ９９での審査に必要な情報を取得すれば足りる。また、ここで取得する公開鍵証明書が上述した共通公開鍵証明書である場合もある。
このステップＳ９６の処理が取得手順の処理であり、この処理においては管理装置３０のＣＰＵ１１が取得手段として機能する。

次のステップＳ９７は、ステップＳ９４で受信した公開鍵証明書を用いた審査の処理であり、ステップＳ９４で管理対象機器４０から受信した公開鍵証明書と、ステップＳ９６で取得した情報とを用いて管理対象機器４０を審査してその結果を結果テーブルに登録する。この公開鍵証明書を用いた審査をどのように行うかについては種々の方式が考えられるが、少なくとも、ステップＳ９４で公開鍵証明書を受信した場合には、その公開鍵証明書が、同ステップで受信した機番の装置が記憶している公開鍵証明書として適切なものであるか否かを判断できるように行うものとする。例えば、管理対象機器４０から受信した公開鍵証明書と証明書データベースから取得した公開鍵証明書との全体を比較したり、それらの一部を比較したり、両証明書からパラメータを抽出して比較したりして、両証明書の内容が一致した場合に適切なものであるとすることができる。

図１８のフローチャートに、ステップＳ９７での公開鍵証明書を用いた審査の処理の一例を示す。
この処理においては、まずステップＳ１１１で、図１６のステップＳ９４で管理対象機器４０から正規認証情報として公開鍵証明書を受信したか否か判断する。そして、受信していれば、ステップＳ１１２に進み、受信した公開鍵証明書と、図１６のステップＳ９６で証明書データベースから取得した公開鍵証明書とが一致するか否か判断する。

そして、一致していれば、ステップＳ９４で受信した公開鍵証明書は管理対象機器４０が記憶しているはずのものであり、これは通信相手が管理対象機器４０であることを支持する根拠となるので、ステップＳ１１３で結果テーブルに公開鍵証明書の審査結果として「ＯＫ」を登録して元の処理に戻る。一致していなければ、逆に通信相手が管理対象機器４０でないことを支持する根拠となるので、ステップＳ１１４で審査結果として「ＮＧ」を登録して元の処理に戻る。
また、ステップＳ１１１で公開鍵証明書を受信していなければ、ステップＳ１１５で公開鍵証明書の審査結果として「なし」を登録して元の処理に戻る。
図１６のステップＳ９７での審査処理は、例えば以上のような処理により行うことができる。

公開鍵証明書は、一般には秘密に保つデータではなく、適宜通信相手に送信してしまうデータであるため、公開鍵証明書を記憶していることは、その公開鍵証明書の発行先の装置であることの根拠にはなり難い。
しかし、特定の通信相手とのみ通信し、従って公開鍵証明書も特定の装置にしか渡さないような通信システムにおいては、全く無関係な装置が管理対象機器４０の公開鍵証明書を記憶している可能性は低い。また、管理対象機器４０の通信相手となる装置が、管理対象機器４０と同じベンダーの製品である場合には、通信相手の側では公開鍵証明書を保存しないようにしたり、他の装置に転送しないようにしたりという対応が可能になる。

例えば、管理対象機器４０がファイアウォールの内側にあることを前提としてシステムを構築し、管理対象機器４０と管理装置３０との間の通信は、必ず管理対象装置４０が発呼側になるように行い、かつ管理対象装置４０が管理装置３０以外に対しては通信を要求しないようにすれば、管理対象機器４０の公開鍵証明書が、管理装置３０以外の装置に対して送信されないようにすることができる。さらに、管理対象機器４０において、公開鍵証明書を、基板に固定されたフラッシュロムやイープロム等のメモリにスクランブルされた状態で保存するようにすれば、オフラインでの証明書の持ち出しも防止され、管理対象機器４０の公開鍵証明書が、自身と管理装置３０以外の装置に記憶される事態を一層効果的に防止することができる。

従って、このような場合には、管理装置３０側で特定の機番の装置が記憶していると把握している公開鍵証明書を送信してくる装置は、本当にその機番の装置である可能性が高いといえる。特に、管理対象機器４０の通信相手が管理装置３０のみである場合には、管理対象機器４０に対して発行した公開鍵証明書は、管理対象機器４０と管理装置３０のみが記憶しているはずであるから、管理装置３０側で把握しているものと同じ公開鍵証明書を送信してくることをもって、対応する機番の装置であると判断するようにすることも考えられる。

また、図１９のフローチャートに、ステップＳ９７での公開鍵証明書を用いた審査の処理の別の例を示す。この処理は、証明書要求コマンドに応じた処理の際に適用すると好適な例である。
この処理においてはまず、ステップＳ１２１及びステップＳ１２２で、図１８のステップＳ１１１及びＳ１１２の場合と同様な審査を行う。

その後、管理対象機器４０から受信した機番や、受信した公開鍵証明書の有効期限の情報を用い、これらの情報をキーにして管理対象とする装置についての情報を記録している図示しないテーブルを参照し、管理対象機器４０が管理対象の装置であるか否か、および管理対象機器４０について管理契約期間が使用中の公開鍵証明書の有効期限後まであるか否かを判断する（Ｓ１２３，Ｓ１２４）。

そして、管理対象の装置以外に対しては、今後も通信が可能な状態にしておく必要はないし、管理契約期間が使用中の公開鍵証明書の有効期限内で終了するのであれば、その後通信が可能な状態にしておく必要はないので、ステップＳ１２３又はＳ１２４の判断がＮＯである場合は、ステップＳ１２７で審査ＮＧ（不合格）として以下の処理に進む。
なお、ステップＳ１２４については、公開鍵証明書の有効期限を管理契約の期限をもとに定めてある場合には、管理延長契約がなされているか否かを基準に判断するようにしてもよい。

また、ステップＳ１２３とＳ１２４でＹＥＳであれば、ステップＳ１２５に進み、現在の公開鍵証明書が期限切れ間近（例えば有効期限まで１ヶ月以内）か否か判断する。証明書要求コマンドは、公開鍵証明書の期限切れ間近に送信されてくるはずであるから、この判断がＮＯの場合には、何らかの異常が発生していると考えられ、やはりステップＳ１２７で審査ＮＧとしてもとの処理に戻る。
また、以上のステップＳ１２１乃至Ｓ１２５の判断が全てＹＥＳであれば、ステップＳ１２６で審査ＯＫ（合格）として元の処理に戻る。

以上の処理により、機番の送信元の装置を審査し、公開鍵証明書を発行してよいか否かを判断することができる。なお、審査処理において判断すべき項目については、図１８や図１９に示したものは一例に過ぎず、管理対象機器４０の用途や管理装置３０による管理の運用形態等に応じて適宜定めればよいことは、もちろんである。

図１６の説明に戻る。
次のステップＳ９８は、ステップＳ９４で受信した私有鍵を用いた審査の処理であり、ステップＳ９４で管理対象機器４０から受信した私有鍵と、ステップＳ９６で取得した情報とを用いて管理対象機器４０を審査してその結果を結果テーブルに登録する。この私有鍵を用いた審査をどのように行うかについても、種々の方式が考えられるが、少なくとも、ステップＳ９４で私有鍵を受信した場合には、その私有鍵が、同ステップで受信した機番の装置が記憶している公開鍵と対応するものであるか否かを判断できるように行うものとする。例えば、管理対象機器４０から受信した私有鍵と証明書データベースから取得した公開鍵証明書中の公開鍵との一方を用いて適当なデータを暗号化し、他方を用いてその暗号化したデータを復号化し、復号化により元のデータが得られた場合に適切なものであるとすることができる。

図２０のフローチャートに、ステップＳ９８での私有鍵を用いた審査の処理の一例を示す。
この処理においては、まずステップＳ１４１で、図１６のステップＳ９４で管理対象機器４０から正規認証情報として私有鍵を受信したか否か判断する。そして、受信していれば、ステップＳ１４２に進み、受信した私有鍵を用いて適当なデータを暗号化し、ステップＳ１４３で、その暗号化したデータを、図１６のステップＳ９６で証明書データベースから取得した公開鍵証明書中の公開鍵を用いて復号化する。なお、このとき復号化に管理対象機器４０から受信した公開鍵証明書中の公開鍵を用いたのでは、単に管理対象機器４０に互いに対応する公開鍵と私有鍵が記憶されていることを確認することにしかならないので注意が必要であるが、このようにすることも考えられる。

そして、ステップＳ１４４でこの復号化が成功したか否か、すなわち復号化の結果暗号化前のデータが得られたか否か判断する。
ここで得られれば、ステップＳ９４で受信した私有鍵は管理対象機器４０が記憶していると管理装置３０側で把握している公開鍵と対応するものであり、これは通信相手が管理対象機器４０であることを支持する根拠となる。そこで、ステップＳ１４５で結果テーブルに私有鍵の審査結果として「ＯＫ」を登録して元の処理に戻る。元のデータが得られなければ、逆に通信相手が管理対象機器４０でないことを支持する根拠となるので、ステップＳ１４６で審査結果として「ＮＧ」を登録して元の処理に戻る。
また、ステップＳ１４１で私有鍵を受信していなければ、ステップＳ１４７で私有鍵の審査結果として「なし」を登録して元の処理に戻る。
図１６のステップＳ９８での審査処理は、例えば以上のような処理により行うことができる。

私有鍵は、通常は発行対象の装置しか記憶していないデータである。従って、ある機番の装置が記憶していると把握している私有鍵を送信してくる装置は、本当にその機番の装置である可能性が高いと言える。しかし、比較のために各装置に発行した私有鍵を管理装置３０側で記憶しておくとすると、管理装置３０が管理対象機器４０になりすますことが可能になってしまい、システムの設計上好ましくない。そこで、図２０に示した例においては、受信した私有鍵が、ある機番の装置が記憶していると把握している公開鍵と対応するものであることを確認することにより、その私有鍵がその機番の装置が記憶しているはずのものであることを間接的に確認するようにしている。
しかし、証明書データベースに私有鍵も記憶しておき、管理対象機器４０から受信した私有鍵と証明書データベースから取得した私有鍵とを比較するようにすることも、技術的には可能である。

再度図１６の説明に戻る。
次のステップＳ９９は、ステップＳ９４で受信したルート鍵証明書を用いた審査の処理であり、ステップＳ９４で管理対象機器４０から受信したルート証明書と、ステップＳ９６で取得した情報とを用いて管理対象機器４０を審査してその結果を結果テーブルに登録する。このルート鍵証明書を用いた審査をどのように行うかについても種々の方式が考えられるが、考え方は公開鍵証明書の場合と同様であるから、詳細な説明は省略する。処理の具体例としても、図１８に示したフローチャートの処理のうち、「公開鍵証明書」の部分を「ルート鍵証明書」と読み替えた処理を採用することが可能である。

ルート鍵証明書も、公開鍵証明書の場合と同様、一般には秘密に保つデータではない。また、管理対象機器４０と同じ階位に属する装置には共通に記憶させておくものである。従って、ルート鍵証明書を記憶していることは、特定の装置であることの根拠にはなり難い。
しかし、一度設定されたルート鍵証明書は、通常は外部の装置に送信するものではないので、全く無関係な装置が管理対象機器４０のルート鍵証明書を記憶している可能性は低い。従って、このような場合には、管理装置３０側で特定の階位の装置が記憶していると把握しているルート鍵証明書を送信してくる装置は、少なくとも本当にその階位の装置である可能性が高いと言える。

また、複数のバージョンの公開鍵証明書と対応するルート鍵証明書が混在している場合、通信相手が管理装置３０側で把握している公開鍵証明書と対応するルート鍵証明書を送信してくれば、このことは、通信相手が本当に送信してきた機番の装置であることを支持する証拠となる。
従って、ルート鍵証明書を用いた審査の結果も、公開鍵証明書や私有鍵を用いた審査よりは信頼性に劣るものの、公開鍵証明書や私有鍵を用いた審査の結果と組み合わせて判断材料とすれば、十分に有用なものである。

そして、ステップＳ９９の後は、図１７のステップＳ１００に進み、ステップＳ９７乃至Ｓ９９で結果テーブルに登録した各審査結果の内容により、通信中の管理対象機器に対する最終的な審査を行う。この審査においては、通信相手がステップＳ９４で受信した機番の装置であると信用してよければＯＫを、そうでなければＮＧを返すようにする。
この基準としては例えば、審査結果が公開鍵証明書と私有鍵とルート鍵証明書の全てについてＯＫであれば最終結果もＯＫとし、それ以外はＮＧとすることが考えられる。しかし、一部の結果が「なし」であっても最終結果をＯＫとしたり、ＯＫとＮＧ以外にも、管理装置３０のオペレータに警告を発したり判断を委ねたりするような審査結果を返すようにすることも可能である。これらの基準は、ベンダーにおける管理装置３０の運用基準及び、管理対象機器４０の用途や機能等に応じて適宜定めればよい。

また、ステップＳ９４で正規認証情報が使えなくなった原因の情報を受信した場合には、審査においてこのような情報も利用し、例えば原因に応じて審査の基準を変えることも考えられる。
以上のステップＳ９７乃至Ｓ１００の処理が審査手順の処理であり、この処理において、管理装置３０のＣＰＵ１１が審査手段として機能する。なお、審査については、ステップＳ９７乃至Ｓ９９の処理を全て行うことは必須ではなく、最低限これらのステップのいずれか１つを行えばよい。

次のステップＳ１０１では、ステップＳ１００での審査結果がＯＫであったか否か判断する。そして、ＯＫであれば、ステップＳ１０２以下の証明書更新の処理を行う。
そして、まずステップＳ１０２で、証明書発行部３６の機能により、ステップＳ９４で受信した機番を含む更新用の証明書を作成する。図７等に示した例では、公開鍵証明書には機番以外にも発行対象装置の識別情報を記載しているが、これらの情報を記載する場合には、管理装置３０のデータベースを参照したり、管理対象機器４０から送信させるようにしたりして取得することができる。
ステップＳ１０２の後は、ステップＳ１０３に進み、作成した証明書の情報を証明書データベースに登録する。この処理においては、例えば図１２及び図１３に示したような形式の証明書データベースを用いる場合には、図１３に示した第２のテーブルに公開鍵証明書を登録する。

そして、次のステップＳ１０４では、ステップＳ１０２で作成した証明書を管理対象機器４０に送信する。このとき、送信した証明書を管理装置３０との通信に使用する証明書として設定するように要求する証明書設定コマンドも同時に送信する。
そして、ステップＳ１０５で証明書設定コマンドに対する応答を待って、応答があるとステップＳ１０６に進んで更新が成功したか否か判断する。そして成功していれば、ステップＳ１０７で証明書を更新させた管理対象機器４０について、その機番と対応する公開鍵証明書の情報を更新する。具体的には、図１２に示した第１のテーブルに登録してある証明書のシリアル番号と発行日の情報を、ステップＳ１０４で送信した証明書のものに更新する。そしてその後、ステップＳ１０８で通信を切断して終了する。

ステップＳ１０６で成功していない場合には、そのまま通信を切断して終了する。ステップＳ１０５で所定時間応答がない場合も同様とする。このような場合でも、管理対象機器４０側から再度アクセスしてくることが考えられるため、そのまま終了してしまっても差し支えないのである。このような場合には、管理対象機器４０は依然として更新前と同じ正規認証情報を記憶していると想定されるので、図１２に示した第１のテーブルは更新しないようにしている。
一方、ステップＳ１０１で審査ＯＫでなかった場合には、ステップＳ１０９に進み、通信相手の管理対象機器４０に、審査不合格の旨及びその理由を記載したメッセージを送信し、ステップＳ１１０で管理装置３０のオペレータにも審査不合格の旨及びその理由を通知し、さらにステップＳ１０８で通信を切断して終了する。なおこの場合、管理対象機器４０に通知を行ったり審査不合格の理由を正確に伝えたりすることが不適切であれば、単にそのまま通信を切断したり、ダミーのメッセージを送信したりするようにしてもよい。

図１に示した通信システムにおいては、このような処理を行うことにより、管理対象機器４０において管理装置３０との間で通常の認証処理に使用していた公開鍵証明書が認証処理に使用できなくなってしまった状態であっても、また安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、管理対象機器４０の公開鍵証明書を更新し、再度管理装置３０との間で通常の認証処理が可能な状態に復帰させることができる。
また、この場合において、なりすましが比較的容易になされ得るレスキュー認証情報を用いた非常用の通信経路を使用したとしても、管理対象機器４０が記憶している正規認証情報を機番と共に管理装置３０に送信し、管理装置３０側でその情報をもとに管理対象機器４０を審査するようにしているので、かなりの確実性でなりすましを排除し、不正に更新用の公開鍵証明書等を取得されることを防止することができる。
また、正規認証情報に含まれる通常公開鍵証明書として共通公開鍵証明書を使用しているような場合にも、同様にその更新の際のなりすましを排除し、同様な効果を得ることができる。

また、以上説明してきた方式によれば、自動的に公開鍵証明書を更新することができるので、この方式は、設置先の操作者による証明書の更新が行えないような装置、例えばケーブルテレビのセットトップボックスや遠隔保守の対象となる画像形成装置等に公開鍵証明書を送信する際に審査を行う審査装置や、そのような審査装置を含む通信システムに適用すると、特に効果的である。

次に、以上説明してきた管理対象機器４０における証明書記憶部４６の好ましい構成について説明する。
まず、図２１に、証明書記憶部４６の構成例を示す。
管理対象機器４０においては、図２１に示すように、証明書記憶部４６を構成するメモリとして、互いに独立して交換可能な第１のメモリユニットと第２のメモリユニットとを設け、その一方（ここでは第１のメモリユニット）に図５（ａ）に示したように正規認証情報とレスキュー認証情報を記憶させると共に、他方にも正規認証情報の一部又は全部を記憶させるようにするとよい。図２１においては、第２のメモリユニットに通常公開鍵証明書を記憶させた例を示しているが、通常私有鍵や通常ルート鍵証明書、あるいはこれらの組み合わせを記憶させるようにしてもよい。また、これらのメモリユニットとしては、それぞれ書き換え可能な不揮発性メモリを用い、例えばＳＲＡＭ、フラッシュメモリ、ＳＤカードや、ハードディスクドライブを使用することも可能である。

図２１に示したような構成とした場合でも、通常は第１のメモリユニットに記憶している正規認証情報を用いた認証処理を行えばよい。しかし、管理対象機器４０の運用中には、第１のメモリユニットが破損してしまい交換せざるを得なくなる場合や、第１のメモリユニットを設けたマザーボードを故障等により交換せざるを得なくなる場合も考えられる。
このような場合であっても、レスキュー認証情報が管理対象機器４０の識別情報を含まないものであれば、少なくとも同一機種の管理対象機器４０については共通なものを使用できるから、交換用の部品を製造する際にレスキュー認証情報を予め記憶させておくことが可能である。そして、上述したようにこのレスキュー認証情報を用いて管理装置３０に通信を要求し、新たな正規認証情報の発行を求めることができる。

しかし、もし第１のメモリユニットにしか正規認証情報を記憶させていないとすると、第１のメモリユニットが取り外された段階で管理対象機器４０内に正規認証情報はなくなってしまい、新たな正規認証情報の発行を求める際に、正規認証情報を管理装置３０における審査に供することができなくなってしまう。そうすると、管理装置３０における審査の基準によっては、特に安全性を高めるために審査結果「なし」では審査に合格させないようにしている場合には、管理対象機器４０は審査に合格できず、新たな正規認証情報の発行を受けられないことになってしまう。
一方、第２のメモリユニットにも正規認証情報を記憶させておくようにすれば、図２２に示すように、第１のメモリユニットを交換した場合でも、第２のメモリユニットに記憶している正規認証情報はそのまま残る。そして、これを管理装置３０に送信して審査に供することができ、正規認証情報が適切なものであれば、管理対象機器４０は審査に合格して新たな正規認証情報の発行を受けることができる。

また、管理装置３０から受信した更新用の証明書を第１のメモリユニットに記憶させると共に、その一部または全部を第２のメモリユニットにも記憶させるようにすれば、図２１に示した元の状態に戻すことができる。
このように、上述した実施形態の通信システムにおいては、管理対象機器４０において、正規認証情報を構成する公開鍵証明書と私有鍵とを、独立して交換可能な複数のメモリユニットに分散して記憶させるようにすることが有効である。この場合において、公開鍵証明書や私有鍵を、複数のメモリユニットに記憶させる場合があってもよいことはもちろんである。
なお、図２３に例を示すように、第２のメモリユニットに記憶させた証明書等は、同じものを第１のメモリユニットに記憶させなくてもよい。この場合、第２のメモリユニットに記憶させた証明書等も認証処理に使用することになるが、一方のメモリユニットを交換した場合でも他方のメモリユニットに記憶している証明書等が残ることは、上記の場合と同様である。このような態様も、当然上記の「分散して」に含まれる。
以上で管理対象機器４０の証明書記憶部４６についての説明を終了する。

なお、このような点の他、以下のような変更も可能である。
まず、上述した実施形態では、管理装置３０にＣＡの機能を設け、更新用の証明書を管理装置３０自身が発行する例について説明したが、管理装置３０とＣＡとを別々の装置とすることを妨げるものではない。この場合において、ＣＡと管理装置３０との間の通信経路は、専用線とするとよいが、ＳＳＬやＶＰＮ等により安全な通信経路を確保できれば、インターネットを介したものであってもよい。
このようにする場合、例えば、管理装置３０が更新用公開鍵の送信元である被管理機器を審査して合格と判断した後、ＣＡに更新用証明書の発行を要求して更新用証明書を発行させ、ＣＡからその更新用証明書を受信して証明書データベースに登録し、管理対象機器４０に転送するようにすることができる。

また、ＣＡに証明書データベースを持たせ、管理装置３０が審査に使用するための公開鍵証明書やルート鍵証明書の情報を、ＣＡから取得するようにしてもよい。ＣＡから取得するようにしても、管理対象機器４０と異なる場所から取得することに変わりはない。この場合において、更新用証明書の発行は、上記のようにＣＡに要求して行わせることができることはもちろんであるが、管理装置３０が自身で行うようにすることも可能である。

さらにまた、上述した管理装置３０における審査の機能も、ＣＡに持たせるようにしてもよい。このようにする場合には、管理装置３０は管理対象機器４０から審査に供するために受信した機番や正規認証情報等をＣＡに転送し、これらをもとにＣＡに審査処理を行わせ、審査ＯＫならＣＡが発行した更新用証明書を、審査ＮＧならその旨の情報を取得して管理対象機器４０に転送することになる。もちろん、更新用証明書を取得した場合には管理対象機器４０にこれを設定させる。
さらに、上述した実施形態においては、管理装置３０が管理対象機器４０を管理する通信システムの例について説明したが、通信相手を審査する機能を有する装置が、その審査対象の装置を管理することは必須ではない。単に相互に通信してデータの授受を行うような構成であっても、この発明を適用することは可能である。

また、上述した実施形態では、管理装置３０と管理対象機器４０とが、図２５あるいは図２７を用いて説明したようなＳＳＬに従った認証を行う場合の例について説明した。しかし、この認証が必ずしもこのようなものでなくてもこの発明は効果を発揮する。
ＳＳＬを改良したＴＬＳ（Transport Layer Security）も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。また、公開鍵暗号の方式についても、ＲＳＡ（Rivest Shamir Adleman）だけでなく、楕円曲線暗号等の他の方式のものにも適用可能である。
また、以上説明した各変形を、適宜組み合わせて適用できることはもちろんである。

また、この発明によるプログラムは、管理装置３０を制御するコンピュータに、以上説明したような機能を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
このようなプログラムは、初めからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。

以上説明してきた通り、この発明の審査装置、通信システム、審査方法、プログラムあるいは記録媒体によれば、安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、なりすましを効果的に防止できるようにすることができる。
従って、この発明を、各ノードが通信に際してデジタル証明書を用いた認証処理を行うような通信システムを運用する際に利用することにより、より安全なシステムを構成することができる。

この発明の実施形態である通信システムの構成例を示すブロック図である。 図１に示した管理装置のハードウェア構成を示すブロック図である。 図１に示した管理装置及び管理対象機器について、この発明の特徴に関連する部分の機能構成を示す機能ブロック図である。 図３に示した管理対象機器の要求管理部におけるコマンド実行可否の判断基準について説明するための図である。 図１及び図３に示した管理装置及び管理対象機器が認証処理に用いる証明書及び鍵について説明するための図である。

図５に示した公開鍵証明書のフォーマット例について説明するための図である。 図６に記載したフォーマットに従った管理対象機器用通常公開鍵証明書の例を示す図である。 同じく管理対象機器用レスキュー公開鍵証明書の例を示す図である。 図１に示した通信システムにおける正規認証情報とレスキュー認証情報との使い分けについて説明するための図である。 同じく管理装置が管理対象機器に正規認証情報を設定させる際に送信する証明書等の構成を示す図である。

図１に示した通信システムにおいて、管理対象機器中の認証に使用できなくなった正規認証情報を更新する際に各装置が実行する処理の流れを示すシーケンス図である。 図１に示した管理装置の証明書記憶部に設ける証明書データベースの構成例の一部を示す図である。 同じく別の一部を示す図である。 図１１に示した処理を実行する場合の、管理対象機器側の処理を示すフローチャートである。 図１に示した通信システムにおいて、管理装置が、管理対象機器との通常の通信により正規認証情報を更新する際にも発行先の管理対象機器を審査するようにする場合に、正規認証情報を更新する際に各装置が実行する処理の流れを示すシーケンス図である。

同じく管理装置側の処理を示すフローチャートである。 その続きの処理を示すフローチャートである。 図１６のステップＳ９７に示した公開鍵証明書を用いた審査の処理の一例を示すフローチャートである。 その別の例を示す図である。 同じくステップＳ９８に示した私有鍵を用いた審査の処理の一例を示すフローチャートである。

図３に示した管理対象機器の証明書記憶部の好ましい構成について説明するための図である。 その別の図である。 そのさらに別の図である。 図１に示した通信システムにおいて管理対象機器を複数設けた例を示す図である。 ２つの通信装置がＳＳＬに従った相互認証を行う際に各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。 図２５に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。 ２つの通信装置がＳＳＬに従った片方向認証を行う際の各装置において実行する処理を示す、図２５と対応する図である。

符号の説明

３０…管理装置、３１，４１…ＨＴＴＰＳクライアント機能部、
３２，４２…ＨＴＴＰＳサーバ機能部、３３，４３…認証処理部、
３４，４６…証明書記憶部、３５…証明書審査部、３６…証明書発行部、
３７…コマンド発行部、３８，４８…要求管理部、３９，５０…コマンド処理部、
４０…管理対象機器、４４…コール通知部、４５…定期通知部、４７…証明書通知部
４９…証明書設定部

Claims (30)

1. 公開鍵暗号を用いた認証処理を行うが該認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、該通信装置の公開鍵証明書と該通信装置の識別情報とを受信する受信手段と、
   該手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、前記識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
   該手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて前記通信装置を審査する審査手段とを設けたことを特徴とする審査装置。
2. 請求項１記載の審査装置であって、
   前記審査手段が、前記受信手段が受信した公開鍵証明書の内容と前記取得手段が取得した情報とが一致するか否かに基づいて前記公開鍵証明書が適切なものであるか否かを判断する手段を有することを特徴とする審査装置。
3. 公開鍵暗号を用いた認証処理を行う通信装置から、該通信装置の私有鍵と、該通信装置の識別情報とを受信する受信手段と、
   該手段が受信した識別情報と対応する公開鍵を、該識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
   該手段が取得した公開鍵と前記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて前記通信装置を審査する審査手段とを設けたことを特徴とする審査装置。
4. 請求項３記載の審査装置であって、
   通信装置の識別情報と該通信装置が前記認証処理に使用する公開鍵との対応関係を記憶する手段を設けたことを特徴とする審査装置。
5. 請求項３又は４記載の審査装置であって、
   前記審査手段が、前記取得手段が取得した公開鍵と前記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて前記審査を行う手段を有することを特徴とする審査装置。
6. 請求項１乃至５のいずれか一項記載の審査装置であって、
   前記通信装置が前記審査手段による審査に合格した場合に、前記通信装置に、該通信装置の新たな公開鍵証明書を送信する送信手段を設けたことを特徴とする審査装置。
7. 請求項６記載の審査装置であって、
   前記送信手段が送信する公開鍵証明書は、前記受信手段が受信した前記通信装置の識別情報を含む公開鍵証明書であることを特徴とする審査装置。
8. 公開鍵暗号を用いた認証処理を行うが該認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置であって、自身の公開鍵証明書と自身の識別情報とを審査装置に送信する手段を有する通信装置と、
   該通信装置から、該通信装置の公開鍵証明書と該通信装置の識別情報とを受信する受信手段と、
   該手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、前記識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
   該手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて前記通信装置を審査する審査手段とを設けた審査装置とを備えることを特徴とする通信システム。
9. 請求項８記載の通信システムであって、
   前記審査装置の審査手段が、前記受信手段が受信した公開鍵証明書の内容と前記取得手段が取得した情報とが一致するか否かに基づいて前記公開鍵証明書が適切なものであるか否かを判断する手段を有することを特徴とする通信システム。
10. 公開鍵暗号を用いた認証処理を行う通信装置であって、自身の私有鍵と識別情報とを審査装置に送信する手段を有する通信装置と、
    該通信装置から、該通信装置の私有鍵と、該通信装置の識別情報とを受信する受信手段と、
    該手段が受信した識別情報と対応する公開鍵を、該識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
    該手段が取得した公開鍵と前記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて前記通信装置を審査する審査手段とを設けた審査装置とを備えることを特徴とする通信システム。
11. 請求項１０記載の通信システムであって、
    前記審査装置に、通信装置の識別情報と該通信装置が前記認証処理に使用する公開鍵との対応関係を記憶する手段を設けたことを特徴とする通信システム。
12. 請求項１０又は１１記載の通信システムであって、
    前記審査装置の審査手段が、前記取得手段が取得した公開鍵と前記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて前記審査を行う手段を有することを特徴とする通信システム。
13. 請求項８乃至１２のいずれか一項記載の通信システムであって、
    前記審査装置に、前記通信装置が前記審査手段による審査に合格した場合に、前記通信装置に、該通信装置の新たな公開鍵証明書を送信する送信手段を設け、
    前記通信装置に、該公開鍵証明書を受信する手段を設けたことを特徴とする通信システム。
14. 請求項１３記載の通信システムであって、
    前記審査装置の送信手段が送信する公開鍵証明書は、前記受信手段が受信した前記通信装置の識別情報を含む公開鍵証明書であることを特徴とする通信システム。
15. 請求項８乃至１３のいずれか一項記載の通信システムであって、
    前記通信装置において、前記認証処理に使用する公開鍵証明書と私有鍵とを、独立して交換可能な複数のメモリユニットに分散させて記憶させるようにしたことを特徴とする通信システム。
16. 公開鍵暗号を用いた認証処理を行うが該認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、該通信装置の公開鍵証明書と該通信装置の識別情報とを受信する受信手順と、
    該手順で受信した識別情報と対応する公開鍵証明書の内容を示す情報を、前記識別情報をもとに前記通信装置とは異なる場所から取得する取得手順と、
    該手順で取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて前記通信装置を審査する審査手順とを有することを特徴とする審査方法。
17. 請求項１６記載の審査方法であって、
    前記審査手順に、前記受信手順で受信した公開鍵証明書の内容と前記取得手順で取得した情報とが一致するか否かに基づいて前記公開鍵証明書が適切なものであるか否かを判断する手順を設けたことを特徴とする審査方法。
18. 公開鍵暗号を用いた認証処理を行う通信装置から、該通信装置の私有鍵と、該通信装置の識別情報とを受信する受信手順と、
    該手順で受信した識別情報と対応する公開鍵を、該識別情報をもとに前記通信装置とは異なる場所から取得する取得手順と、
    該手順で取得した公開鍵と前記受信手順で受信した私有鍵とが対応するものであるか否かに基づいて前記通信装置を審査する審査手順とを有することを特徴とする審査方法。
19. 請求項１８記載の審査方法であって、
    前記各手順を実行する装置に、通信装置の識別情報と該通信装置が前記認証処理に使用する公開鍵との対応関係を記憶させておくようにしたことを特徴とする審査方法。
20. 請求項１８又は１９記載の審査方法であって、
    前記審査手順に、前記取得手順で取得した公開鍵と前記受信手順で受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて前記審査を行う手順を設けたことを特徴とする審査方法。
21. 請求項１６乃至２０のいずれか一項記載の審査方法であって、
    前記通信装置が前記審査手順における審査に合格した場合に、前記通信装置に、該通信装置の新たな公開鍵証明書を送信する送信手順をさらに有することを特徴とする審査方法。
22. 請求項２１記載の審査方法であって、
    前記送信手順で送信する公開鍵証明書は、前記受信手順で受信した前記通信装置の識別情報を含む公開鍵証明書であることを特徴とする審査方法。
23. コンピュータを、
    公開鍵暗号を用いた認証処理を行うが該認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、該通信装置の公開鍵証明書と該通信装置の識別情報とを受信する受信手段と、
    該手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、前記識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
    該手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて前記通信装置を審査する審査手段として機能させるためのプログラム。
24. 請求項２３記載のプログラムであって、
    前記審査手段が、前記受信手段が受信した公開鍵証明書の内容と前記取得手段が取得した情報とが一致するか否かに基づいて前記公開鍵証明書が適切なものであるか否かを判断する機能を有することを特徴とするプログラム。
25. コンピュータを、
    公開鍵暗号を用いた認証処理を行う通信装置から、該通信装置の私有鍵と、該通信装置の識別情報とを受信する受信手段と、
    該手段が受信した識別情報と対応する公開鍵を、該識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
    該手段が取得した公開鍵と前記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて前記通信装置を審査する審査手段として機能させるためのプログラム。
26. 請求項２５記載のプログラムであって、
    前記コンピュータを、通信装置の識別情報と該通信装置が前記認証処理に使用する公開鍵との対応関係を記憶する手段として機能させるためのプログラムを更に含むことを特徴とするプログラム。
27. 請求項２５又は２６記載のプログラムであって、
    前記審査手段が、前記取得手段が取得した公開鍵と前記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて前記審査を行う機能を有することを特徴とするプログラム。
28. 請求項２３乃至２７のいずれか一項記載のプログラムであって、
    前記コンピュータを、前記通信装置が前記審査手段による審査に合格した場合に、前記通信装置に、該通信装置の新たな公開鍵証明書を送信する送信手段として機能させるためのプログラムを更に含むことを特徴とするプログラム。
29. 請求項２８記載のプログラムであって、
    前記送信手段が送信する公開鍵証明書は、前記受信手段が受信した前記通信装置の識別情報を含む公開鍵証明書であることを特徴とするプログラム。
30. 請求項２３乃至２９のいずれか一項記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
    

Images