審査装置、通信システム、審査方法、プログラム及び記録媒体
【課題】 安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、なりすましを効果的に防止できるようにする。
【解決手段】 管理装置30が、通常の通信時に公開鍵暗号を用いたSSLによる通信を行う管理対象機器40から、管理対象機器40の私有鍵、公開鍵証明書あるいはルート鍵証明書の少なくとも1つと、管理対象機器40の機番とを受信する(S24)。そして、受信した機番と対応する公開鍵、公開鍵証明書又はルート鍵証明書を、その機番をもとに管理対象機器40とは異なる場所から取得し、その取得した公開鍵等を用いて、管理対象機器40から受信した私有鍵等が適切なものであるか否かにより管理対象機器40を審査するようにする(S25)。
【解決手段】 管理装置30が、通常の通信時に公開鍵暗号を用いたSSLによる通信を行う管理対象機器40から、管理対象機器40の私有鍵、公開鍵証明書あるいはルート鍵証明書の少なくとも1つと、管理対象機器40の機番とを受信する(S24)。そして、受信した機番と対応する公開鍵、公開鍵証明書又はルート鍵証明書を、その機番をもとに管理対象機器40とは異なる場所から取得し、その取得した公開鍵等を用いて、管理対象機器40から受信した私有鍵等が適切なものであるか否かにより管理対象機器40を審査するようにする(S25)。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、公開鍵暗号を用いた認証処理を行う通信装置を審査する審査装置及び審査方法、上記のような審査装置と審査対象の通信装置とを備えた通信システム、コンピュータを上記のような審査装置として機能させるためのプログラム、およびそのようなプログラムを記録したコンピュータ読み取り可能な記録媒体に関する。
【背景技術】
【0002】
従来から、それぞれ通信機能を備えた複数の通信装置をネットワークを介して通信可能に接続し、様々なシステムを構築することが行われている。その一例としては、クライアント装置として機能するPC(パーソナルコンピュータ)等のコンピュータから商品の注文を送信し、これとインターネットを介して通信可能なサーバ装置においてその注文を受け付けるといった、いわゆる電子商取引システムが挙げられる。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。
【0003】
このようなシステムを構築する上では、通信を行う際に、通信相手が適切か、あるいは送信されてくる情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばSSL(Secure Socket Layer)と呼ばれるプロトコルが開発されており、広く用いられている。このプロトコルを用いて通信を行うことにより、公開鍵暗号方式と共通鍵暗号方式とを組み合わせ、通信相手の認証を行うと共に、情報の暗号化により改竄及び盗聴の防止を図ることができる。また、通信相手の側でも、通信を要求してきた通信元の装置を認証することができる。
このようなSSLや公開鍵暗号を用いた認証に関連する技術としては、例えば特許文献1及び特許文献2に記載のものが挙げられる。
【特許文献1】特開2002−353959号公報
【特許文献2】特開2002−251492号公報
【0004】
ここで、このSSLに従った相互認証を行う場合の通信手順について、認証処理の部分に焦点を当てて説明する。図25は、通信装置Aと通信装置BとがSSLに従った相互認証を行う際に各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図25に示すように、SSLに従った相互認証を行う際には、まず双方の通信装置に、ルート鍵証明書及び、私有鍵と公開鍵証明書を記憶させておく必要がある。この私有鍵は、認証局(CA:certificate authority)が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にCAがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、CAがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。
【0005】
図26にこれらの関係を示す。
図26(a)に示すように、公開鍵Aは、私有鍵Aを用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者(CA)や有効期間等の情報を含む書誌情報とによって構成される。そして、CAは、鍵本体や書誌情報が改竄されていないことを示すため、公開鍵Aをハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名としてクライアント公開鍵に付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Aの書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、公開鍵証明書Aである。
【0006】
この公開鍵証明書Aを認証処理に用いる場合には、ここに含まれるデジタル署名を、ルート私有鍵と対応する公開鍵であるルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば、デジタル署名が確かにCAによって付されたことがわかる。また、公開鍵Aの部分をハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とが一致すれば、鍵自体も損傷や改竄を受けていないことがわかる。
また、受信したデータを公開鍵Aを用いて正常に復号化できれば、そのデータは、私有鍵Aの持ち主から送信されたものであることがわかる。
【0007】
ここで、認証を行うためには、ルート鍵を予め記憶しておく必要があるが、このルート鍵も、図26(b)に示すように、CAがデジタル署名を付したルート鍵証明書として記憶しておく。このルート鍵証明書は、自身に含まれる公開鍵でデジタル署名を復号化可能な、自己署名形式である。そして、ルート鍵を使用する際に、そのルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し、ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば、ルート鍵が破損等していないことを確認できるのである。
【0008】
図25のフローチャートの説明に入る。なお、この図において、2本のフローチャート間の矢印は、データの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また、各ステップの処理が正常に完了しなかった場合には、その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合、処理がタイムアウトした場合等も同様である。
【0009】
ここでは、通信装置Aが通信装置Bに通信を要求するものとするが、この要求を行う場合、通信装置AのCPUは、所要の制御プログラムを実行することにより、図25の左側に示すフローチャートの処理を開始する。そして、ステップS211で通信装置Bに対して接続要求を送信する。
一方通信装置BのCPUは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図25の右側に示すフローチャートの処理を開始する。そして、ステップS221で第1の乱数を生成し、これを私有鍵Bを用いて暗号化する。そして、ステップS222でその暗号化した第1の乱数と公開鍵証明書Bとを通信装置Aに送信する。
【0010】
通信装置A側では、これを受信すると、ステップS212でルート鍵証明書を用いて公開鍵証明書Bの正当性を確認する。
そして確認ができると、ステップS213で、受信した公開鍵証明書Bに含まれる公開鍵Bを用いて第1の乱数を復号化する。ここで復号化が成功すれば、第1の乱数は確かに公開鍵証明書Bの発行対象から受信したものだと確認できる。
その後、ステップS214でこれとは別に第2の乱数及び共通鍵の種を生成する。共通鍵の種は、例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして、ステップS215で第2の乱数を私有鍵Aを用いて暗号化し、共通鍵の種を公開鍵Bを用いて暗号化し、ステップS216でこれらを公開鍵証明書Aと共にサーバ装置に送信する。共通鍵の種の暗号化は、通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。
また、次のステップS217では、ステップS214で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
【0011】
通信装置B側では、通信装置AがステップS216で送信してくるデータを受信すると、ステップS223でルート鍵証明書を用いて公開鍵証明書Aの正当性を確認する。そして確認ができると、ステップS224で、受信した公開鍵証明書Aに含まれる公開鍵Aを用いて第2の乱数を復号化する。ここで復号化が成功すれば、第2の乱数は確かに公開鍵証明書Aの発行対象から受信したものだと確認できる。
その後、ステップS225で私有鍵Bを用いて共通鍵の種を復号化する。ここまでの処理で、通信装置A側と通信装置B側に共通鍵の種が共有されたことになる。そして、この共通鍵の種は、生成した通信装置Aと、私有鍵Bを持つ通信装置B以外の装置が知ることはない。ここまでの処理が成功すると、通信装置B側でもステップS226で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
【0012】
そして、通信装置A側のステップS217と通信装置B側のステップS226の処理が終了すると、相互に認証の成功と以後の通信に使用する暗号化方式とを確認し、生成した共通鍵を用いてその暗号化方式で以後の通信を行うものとして認証に関する処理を終了する。なお、この確認には、通信装置Bからの認証が成功した旨の応答も含むものとする。以上の処理によって互いに通信を確立し、以後はステップS217又はS226で生成した共通鍵を用い、共通鍵暗号方式でデータを暗号化して通信を行うことができる。
【0013】
このような処理を行うことにより、通信装置Aと通信装置Bが互いに相手を認証した上で安全に共通鍵を共有することができ、通信を安全に行う経路を確立することができる。
なお、片方向認証を採用し、例えば通信装置Bが通信要求元の通信装置Aを認証するのみでよいのであれば、図25に示した認証処理において、第1の乱数の暗号化及び送信を省略することができる。この場合でも、共通鍵の種を通信装置Aから通信装置Bに安全に送信するために、通信装置Bの公開鍵Bを用いた暗号化を行うとよいが、公開鍵Bに付されたデジタル署名の正当性を確認することは行わなくてよい。そして、この場合の認証処理は、図27に示すように簡略化されたものになる。すなわち、通信装置A側のステップS212及びS213の処理は不要となり、通信装置B側のステップS221の処理も不要となる。また、その他の処理も一部簡略化することができる。
【0014】
以上のような認証処理においては、公開鍵で暗号化された内容は対応する私有鍵を持つ装置でしか復号できず、また、私有鍵で暗号化された内容は対応する公開鍵でしか復号できないことを利用して、通信相手が公開鍵証明書にその発行先として記載されている装置である(又はその装置の利用者が公開鍵証明書にその発行先として記載されている利用者である)と認証することになる。
【0015】
なお、このような認証処理に使用する公開鍵の管理に関する技術としては、例えば特許文献3及び4に記載の技術が知られている。
特許文献3には、複写機管理装置2がホストコンピュータ4から受信した公開鍵を記憶しておき、異常情報をホストコンピュータ4に送信する際に、記憶している最新の公開鍵を用いて異常情報を暗号化することが記載されている。
特許文献4には、公開鍵暗号を用いた認証処理を行うクライアントがWWWサーバにアクセスした際に、公開鍵証明書の期限切れが近い場合にはその旨をクライアントに警告するようにすることが記載されている。
【特許文献3】特開2001−242750号公報
【特許文献4】特開2003−273855号公報
【発明の開示】
【発明が解決しようとする課題】
【0016】
ところで、公開鍵暗号方式においては、鍵長にもよるが、時間をかければ公開鍵から私有鍵を導くことができる。そして、私有鍵がわかってしまえば、第3者がその私有鍵の持ち主になりすますことが可能になるので、認証の確実性や通信の安全性が保たれない。そこで、上述のように鍵に有効期限を設け、所定期間毎に鍵のセットを更新するというセキュリティポリシーを採用するユーザが増えている。このため、例えば上記のような相互認証を利用した遠隔管理システム等を提供する場合には、顧客に対し、鍵の更新が可能なシステムであるという保証を行う必要が生じている。
【0017】
そして、公開鍵証明書を用いて認証を受ける通信装置に更新用の新しい公開鍵証明書を配布する方式としては、使用中の公開鍵証明書の有効期限が切れる前に、CAが通信装置に対して新たな公開鍵証明書と私有鍵を発行し、これらとルート鍵証明書のセットを、CAあるいはそれに代わる管理装置が、使用中の公開鍵証明書を用いて確立したSSLによる通信経路で更新対象の装置に送信して設定させる方式が考えられる。
このようにすれば、通信装置が認証に使用する公開鍵証明書等を、有効期限が切れる前に自動的に更新することができるので、ユーザの手を煩わせることなく、通信装置を認証可能な状態に保つことができる。また、インターネットを介して送信を行う場合でも、安全な通信経路を確保して公開鍵証明書等の転送を行うことができる。
【0018】
しかしながら、このような方式を採用したとしても、更新対象の装置が、更新を行うべき期間の間にネットワークに接続されていなかったり、電源が入れられなかったりした場合には、公開鍵証明書を更新できないうちに使用中の公開鍵証明書の有効期限が切れてしまうことが考えられる。そして、これらのような状態になってしまった場合には、更新対象の装置は、もはやCAや管理装置に通常の認証を受けることはできない状態になってしまい、SSLによる安全な通信経路も確立できない状態になってしまう。
【0019】
ただし、このような場合であっても、通信装置にCAや管理装置との間で非常用の通信経路を確保する手段を設けておけば、通信装置がその経路を通して通常の通信経路を確立するための新たな公開鍵証明書等を取得できるようにすることも可能である。このような非常用の通信経路としては、例えば、有効期限の長い公開鍵証明書及びこれと対応する私有鍵やルート鍵証明書を、ベンダーが提供する各装置に共通に記憶させておき、これらを用いてCAや管理装置との間でSSLによる通信経路を確立できるようにすることが考えられる。
このような技術について、本件出願人は過去に特許出願を行っている(特願2003−341329、未公開)。
【0020】
しかし、このような非常用の通信経路については、普段は使用しないものであり、また通常の通信経路での通信に不都合があるような場合でも通信が可能であるようにする必要があるため、通常の通信経路の場合と同様な厳密さで認証処理を行うことができるようにすることは難しい。例えば、上記のように各装置に共通な公開鍵証明書を記憶させる場合には、公開鍵証明書に装置の識別情報を記載することはできないため、SSLによる認証処理の時点では装置の識別情報を参照することができない。そして、CAや管理装置は、通信経路の確立後に通信装置に識別情報を送信させ、その情報を信用して更新用の公開鍵証明書等の送信を行うことになる。
【0021】
従って、非常用の通信経路に関しては、他の通信装置になりすまして更新用の公開鍵証明書を取得することが、比較的簡単にできてしまうという問題があった。そこで、非常用の通信経路を使用する場合、すなわち通常の通信経路が使用できない場合でも、なりすましを効果的に防止できるようにすることが望まれていた。
この点に関し、上述した各特許文献には、通常使用する公開鍵証明書が使用できなくなった状態での公開鍵証明書の更新については、特に触れられていない。
また、生産設備等の都合により、通常使用する公開鍵証明書についても、上述の非常用の公開鍵証明書の場合のように、各装置に共通な公開鍵証明書を設定せざるを得ない場合もある。そして、このような場合には、上記の非常用の通信経路を利用する場合と同じく、通常使用する公開鍵証明書を、その有効期間内に更新する場合でも、なりすましを効果的に防止できるようにすることが望まれていた。
この発明は、上記のような要望に応え、安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、なりすましを効果的に防止できるようにすることを目的とする。
【課題を解決するための手段】
【0022】
上記の目的を達成するため、この発明の審査装置は、公開鍵暗号を用いた認証処理を行うがその認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、その通信装置の公開鍵証明書とその通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、上記識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて上記通信装置を審査する審査手段とを設けたものである。
このような審査装置において、上記審査手段に、上記受信手段が受信した公開鍵証明書の内容と上記取得手段が取得した情報とが一致するか否かに基づいて上記公開鍵証明書が適切なものであるか否かを判断する手段を設けるとよい。
【0023】
また、この発明は、公開鍵暗号を用いた認証処理を行う通信装置から、その通信装置の私有鍵と、その通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵を、その識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した公開鍵と上記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて上記通信装置を審査する審査手段とを設けた審査装置も提供する。
このような審査装置において、通信装置の識別情報とその通信装置が上記認証処理に使用する公開鍵との対応関係を記憶する手段を設けるとよい。
さらに、上記審査手段に、上記取得手段が取得した公開鍵と上記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて上記審査を行う手段を設けるとよい。
【0024】
また、上記の各審査装置において、上記通信装置が上記審査手段による審査に合格した場合に、上記通信装置に、その通信装置の新たな公開鍵証明書を送信する送信手段を設けるとよい。
さらに、上記送信手段が送信する公開鍵証明書を、上記受信手段が受信した上記通信装置の識別情報を含む公開鍵証明書とするとよい。
【0025】
また、この発明の通信システムは、公開鍵暗号を用いた認証処理を行うがその認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置であって、自身の公開鍵証明書と自身の識別情報とを審査装置に送信する手段を有する通信装置と、その通信装置から、その通信装置の公開鍵証明書とその通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、上記識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて上記通信装置を審査する審査手段とを設けた審査装置と備える通信システムである。
このような通信システムにおいて、上記審査装置の審査手段に、上記受信手段が受信した公開鍵証明書の内容と上記取得手段が取得した情報とが一致するか否かに基づいて上記公開鍵証明書が適切なものであるか否かを判断する手段を設けるとよい。
【0026】
また、この発明は、公開鍵暗号を用いた認証処理を行う通信装置であって、自身の私有鍵と識別情報とを審査装置に送信する手段を有する通信装置と、その通信装置から、その通信装置の私有鍵と、その通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵を、その識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した公開鍵と上記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて上記通信装置を審査する審査手段とを備える審査装置とを設けた通信システムも提供する。
【0027】
このような通信システムにおいて、上記審査装置に、通信装置の識別情報とその通信装置が上記認証処理に使用する公開鍵との対応関係を記憶する手段を設けるとよい。
さらに、上記審査装置の審査手段に、上記取得手段が取得した公開鍵と上記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて上記審査を行う手段を設けるとよい。
【0028】
また、上記の各通信システムにおいて、上記審査装置に、上記通信装置が上記審査手段による審査に合格した場合に、上記通信装置に、その通信装置の新たな公開鍵証明書を送信する送信手段を設け、上記通信装置に、その公開鍵証明書を受信する手段を設けるとよい。
さらに、上記審査装置の送信手段が送信する公開鍵証明書を、上記受信手段が受信した上記通信装置の識別情報を含む公開鍵証明書とするとよい。
さらにまた、上記通信装置において、上記認証処理に使用する公開鍵証明書と私有鍵とを、独立して交換可能な複数のメモリユニットに分散させて記憶させるようにするとよい。
【0029】
また、この発明の審査方法は、公開鍵暗号を用いた認証処理を行うがその認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、その通信装置の公開鍵証明書とその通信装置の識別情報とを受信する受信手順と、その手順で受信した識別情報と対応する公開鍵証明書の内容を示す情報を、上記識別情報をもとに上記通信装置とは異なる場所から取得する取得手順と、その手順で取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて上記通信装置を審査する審査手順とを有するものである。
このような審査方法において、上記審査手順に、上記受信手順で受信した公開鍵証明書の内容と、上記取得手順で取得した情報とが一致するか否かに基づいて上記公開鍵証明書が適切なものであるか否かを判断する手順を設けるとよい。
【0030】
また、この発明は、公開鍵暗号を用いた認証処理を行う通信装置から、その通信装置の私有鍵と、その通信装置の識別情報とを受信する受信手順と、その手順で受信した識別情報と対応する公開鍵を、その識別情報をもとに上記通信装置とは異なる場所から取得する取得手順と、その手順で取得した公開鍵と上記受信手順で受信した私有鍵とが対応するものであるか否かに基づいて上記通信装置を審査する審査手順とを有する審査方法も提供する。
このような審査方法において、上記各手順を実行する装置に、通信装置の識別情報とその通信装置が上記認証処理に使用する公開鍵との対応関係を記憶させておくようにするとよい。
さらに、上記審査手順に、上記取得手順で取得した公開鍵と上記受信手順で受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて上記審査を行う手順を設けるとよい。
【0031】
また、上記の各審査方法におて、上記通信装置が上記審査手順における審査に合格した場合に、上記通信装置に、その通信装置の新たな公開鍵証明書を送信する送信手順をさらに設けるとよい。
さらに、上記送信手順で送信する公開鍵証明書を、上記受信手順で受信した上記通信装置の識別情報を含む公開鍵証明書とするとよい。
【0032】
また、この発明のプログラムは、コンピュータを、公開鍵暗号を用いた認証処理を行うがその認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、その通信装置の公開鍵証明書と、その通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、上記識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて上記通信装置を審査する審査手段として機能させるためのプログラムである。
このようなプログラムにおいて、上記審査手段に、上記受信手段が受信した公開鍵証明書の内容と上記取得手段が取得した情報とが一致するか否かに基づいて上記公開鍵証明書が適切なものであるか否かを判断する機能を設けるとよい。
【0033】
また、この発明は、コンピュータを、公開鍵暗号を用いた認証処理を行う通信装置から、その通信装置の私有鍵と、その通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵を、その識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した公開鍵と上記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて上記通信装置を審査する審査手段として機能させるためのプログラムも提供する。
このようなプログラムにおいて、上記コンピュータを、通信装置の識別情報とその通信装置が上記認証処理に使用する公開鍵との対応関係を記憶する手段として機能させるためのプログラムを更に含めるとよい。
さらに、上記審査手段に、上記取得手段が取得した公開鍵と上記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて上記審査を行う機能を設けるとよい。
【0034】
また、上記の各プログラムにおいて、上記コンピュータを、上記通信装置が上記審査手段による審査に合格した場合に、上記通信装置に、その通信装置の新たな公開鍵証明書を送信する送信手段として機能させるためのプログラムを更に含めるとよい。
さらに、上記送信手段が送信する公開鍵証明書を、上記受信手段が受信した上記通信装置の識別情報を含む公開鍵証明書とするとよい。
【0035】
また、この発明の記録媒体は、上記のいずれかのプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【発明の効果】
【0036】
以上のようなこの発明の審査装置、通信システム、あるいは審査方法によれば、安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、なりすましを効果的に防止できるようにすることができる。
また、この発明のプログラムによれば、コンピュータを上記の審査装置として機能させてその特徴を実現し、同様な効果を得ることができる。この発明の記録媒体によれば、上記のプログラムを記憶していないコンピュータにそのプログラムを読み出させて実行させ、上記の効果を得ることができる。
【発明を実施するための最良の形態】
【0037】
以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明の審査装置と、その審査装置を用いて構成したこの発明の通信システムの実施形態の構成について説明する。
図1にその通信システムの構成を示す。
この実施形態においては、図1に示すように、審査装置である管理装置30及びその通信相手となる通信装置である管理対象機器40によって通信システムを構成している。
そして、この通信システムにおいて、管理装置30は、管理対象機器40と通信を行おうとする場合、公開鍵暗号とデジタル証明書(公開鍵証明書)を用いる認証方式であるSSLプロトコルに従った認証処理によって管理対象機器40を正当な通信相手として認証した場合に、管理対象機器40との間で通信を確立させるようにしている。そして、管理装置30が送信した動作要求(コマンド)に対し、管理対象機器40が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。
【0038】
逆に、管理対象機器40が管理装置30と通信を行おうとする場合にも、同じくSSLに従った認証処理によって管理装置30を正当な通信相手として認証した場合に、管理装置30との間で通信を確立させるようにしている。そして、管理対象機器40が送信した動作要求(コマンド)に対し、管理装置30が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。
どちらの場合も、通信を要求する側がクライアント、要求される側がサーバとして機能するものとする。
【0039】
なお、この通信システムにおいて、管理装置30は、管理対象機器40を管理する機能の他、管理対象機器40に対し、通常使用する公開鍵証明書を用いて上記のようなSSLによる認証ができなくなった状態で通常の認証を行うための公開鍵証明書を再発行する機能と、その再発行を行う場合において、その再発行先の管理対象機器40を審査して再発行を行ってよいかどうか判断する機能も有する。
また、図1において、管理対象機器40は1つしか示していないが、図24に示すように管理対象機器40を複数設けることも可能である。また、管理対象機器40が1種類である必要もない。ただし、管理装置30は1つの通信システムについて1つである。
【0040】
このような通信システムにおいて、上述の管理装置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)等の既知のプロトコル(通信規格),技術,仕様などを利用することができる。
【0041】
次に、図1に示した各装置の構成と機能についてより詳細に説明する。
図1に示した管理装置30及び管理対象機器40は、装置の遠隔管理,電子商取引等の目的に応じて種々の構成をとることができる。例えば、遠隔管理の場合には、プリンタ,FAX装置,コピー機,スキャナ,デジタル複合機等の画像処理装置を始め、ネットワーク家電,自動販売機,医療機器,電源装置,空調システム,ガス・水道・電気等の計量システム,自動車,航空機等の電子装置を被管理装置である管理対象機器40とし、これらの被管理装置から情報を収集したり、コマンドを送って動作させたりするための管理装置を管理装置30とすることが考えられる。
【0042】
ここで、図2に管理装置30のハードウェア構成例を示す。この図に示す通り、管理装置30は、例えばCPU11,ROM12,RAM13,HDD14,通信インタフェース(I/F)15を設け、これらをシステムバス16によって接続して構成することができる。そして、CPU11がROM12やHDD14に記憶している各種制御プログラムを実行することによってこの管理装置30の動作を制御し、通信相手の認証、管理対象機器40との通信、管理対象機器40の管理や審査、公開鍵証明書の発行等の機能を実現させている。
もちろん、管理装置30として適宜公知のコンピュータを用いたり、必要に応じて他のハードウェアを付加したりしてもよい。
【0043】
また、管理対象機器40も、少なくともそれぞれCPU,ROM,RAM,ネットワークを介して外部装置と通信するための通信I/F、および認証処理に必要な情報を記憶する記憶手段を備え、CPUがROM等に記憶した所要の制御プログラムを実行することにより、装置にこの発明に係る各機能を実現させることができるものとする。
なお、この管理装置30と管理対象機器40との間の通信には、有線,無線を問わず、ネットワークを構築可能な各種通信回線(通信経路)を採用することができる。
【0044】
ここで、図3に、管理装置30及び管理対象機器40の、この実施形態の特徴に関連する部分の機能構成に係る機能ブロック図を示す。なお、図中の矢印は、後述するように管理対象機器40が通常の公開鍵証明書を用いた認証を受けられなくなった状態で管理対象機器40にその通常の公開鍵証明書を再発行場合のデータの流れを示すものである。
まず、管理装置30は、HTTPS(Hypertext Transfer Protocol Security)クライアント機能部31,HTTPSサーバ機能部32,認証処理部33,証明書記憶部34,証明書審査部35,証明書発行部36,コマンド発行部37,要求管理部38,コマンド処理部39を備えている。
【0045】
HTTPSクライアント機能部31は、SSLに従った認証や暗号化の処理を含むHTTPSプロトコルを用いて、管理対象機器40等のHTTPSサーバの機能を有する装置に対して通信を要求する機能を有する。
一方、HTTPSサーバ機能部32は、HTTPSクライアントの機能を有する装置からのHTTPSプロトコルを用いた通信要求を受け付ける機能を有する。
そして、これらのHTTPSクライアント機能部31とHTTPSサーバ機能部32とで、通信相手に対してコマンドやデータを送信してそれに応じた動作を実行させる機能と、通信相手から要求やデータを受信してそれに応じた動作を装置の各部に実行させ、その結果を応答として要求元に返す機能とを実現している。この場合において、通信を要求した側がコマンドを送信することもあるし、通信要求を受け付けた側がコマンドを送信することもある。応答についても同様である。
【0046】
認証処理部33は、HTTPSクライアント機能部31やHTTPSサーバ機能部32が通信相手を認証する際に、通信相手から受信した公開鍵証明書や、証明書記憶部34に記憶している各種証明書、私有鍵等を用いて認証処理を行う認証手段の機能を有する。また、通信相手に認証を要求するために、証明書記憶部34に記憶している公開鍵証明書をHTTPSクライアント機能部31やHTTPSサーバ機能部32を介して通信相手に送信する機能も有する。
証明書記憶部34は、公開鍵証明書や私有鍵、ルート鍵証明書等の認証情報を記憶し、認証処理部33における認証処理に供する機能を有する。そして、証明書記憶部34が記憶している認証情報には、詳細は後述するが、通常の通信時の認証処理に使用する正規認証情報と、正規認証情報による認証ができなくなった場合の復旧に使用する非常用のレスキュー認証情報とがある。また、証明書記憶部34は、証明書発行部36が発行した公開鍵証明書及びその発行先や発行日に関する情報をデータベースとして記憶しておく機能も有する。
【0047】
証明書審査部35は、認証処理部33がレスキュー認証情報により管理対象機器40との間で認証処理を行った場合に、その管理対象機器40から受信する機番や証明書等の情報をもとに、その管理対象機器40に対して更新用の公開鍵証明書や私有鍵を発行してよいか否かを審査する機能を有する。証明書発行部36は、証明書審査部35が審査で発行してよいと判断した場合に、更新用の公開鍵証明書や私有鍵を発行し、これらを管理対象機器40に送信する機能を有する。なお公開鍵証明書の発行については、管理対象機器40が作成して送信してきた公開鍵にデジタル署名を付して返送するようにすることも考えられる。
【0048】
コマンド発行部37は、管理対象機器40に対して種々のコマンドを発行して管理対象機器40にそのコマンドに従った動作を実行させる機能を有する。管理対象機器40に実行させる動作としては、管理対象機器40の動作内容や設定状態に関する情報の送信、管理装置30から送信した更新用の公開鍵証明書を始めとする情報の記憶やそれに応じた設定変更等が考えられる。そして、コマンド発行部37は、管理対象機器40から取得した情報に従って管理対象機器40に種々の動作を実行させることにより、管理対象機器40を管理する機能も有する。
【0049】
要求管理部38は、管理装置から受信したコマンドについて、そのコマンドに基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、そのコマンドに基づいた動作を実行する機能部に対してコマンドを伝える機能も有する。なお、コマンドに基づいた動作を実行する機能部は、実際には複数の独立したモジュールとして構成することが考えられるが、図3においてはコマンド処理部39として一括して示している。そして、このコマンド処理部39が実行する動作としては、例えば管理対象機器40からの異常発生通知に対する対応や、管理対象機器40からの要求に応じて管理装置30が記憶しているデータを送信する動作等が挙げられる。
以上の各部の機能は、管理装置30のCPUが所要の制御プログラムを実行して管理装置30の各部の動作を制御することにより実現される。
【0050】
次に、管理対象機器40には、HTTPSクライアント機能部41,HTTPSサーバ機能部42,認証処理部43,コール通知部44,定期通知部45,証明書記憶部46,証明書通知部47,要求管理部48,証明書設定部49,コマンド処理部50を備えている。
HTTPSクライアント機能部41は、管理装置30のHTTPSクライアント機能部31と同様に、HTTPSプロトコルを用いて管理装置30等のHTTPSサーバの機能を有する装置に対して通信を要求すると共に、コマンドやそれに対する応答を送受信する機能を有する。
【0051】
HTTPSサーバ機能部42も、管理装置30のHTTPSサーバ機能部32と同様であり、HTTPSクライアントの機能を有する装置からの通信要求を受け付けると共に、コマンドやそれに対する応答を送受信する機能を有する。
認証処理部43の機能も、管理装置30の認証処理部33と同様であるが、認証処理に使用する証明書等は、証明書記憶部46に記憶しているものである。
【0052】
コール通知部44は、異常を検知したりユーザによる指示があったりした場合に管理装置30に対してその旨を通知するコールを行う機能を有する。
定期通知部45は、管理対象機器40から管理装置30への定期的な通知を行う機能を有する。その通知の内容としては、例えば画像形成装置であれば画像形成枚数カウンタのカウント値、計量システムであればその計量値等が考えられる。
【0053】
証明書記憶部46は、管理装置30の証明書記憶部34と同様に各種の証明書や私有鍵等の認証情報を記憶し、認証処理部43における認証処理に供する証明書記憶手段の機能を有する。ただし、記憶している証明書等は、後述するように証明書記憶部34とは異なる。
証明書通知部47は、正規認証情報による認証が受けられなくなり、レスキュー認証情報により管理装置30に認証を受けた場合等、管理装置30に正規認証情報を用いた審査を受ける必要がある場合に、管理装置30に、管理対象機器40の機番と共にそれまで使用していた正規認証情報を送信し、管理装置30における管理対象機器40の審査に供する機能を有する。
【0054】
要求管理部48は、管理装置30から受信したコマンドについて、そのコマンドに基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、そのコマンドに基づいた動作を実行する証明書設定部49及びコマンド処理部50のような機能部に対してコマンドを伝える機能も有する。
図4にこの実行可否の判断基準を示すが、その判断基準は、コマンドの種類及び認証処理部43において認証処理に使用した認証情報の種類である。要求管理部48は、図4に示すように、正規認証情報による認証を行った場合には全ての動作を許可するが、レスキュー認証情報による認証を行った場合には証明書(私有鍵も含む)の設定動作のみを許可するようにしている。なお、ここでは設定(更新も含む)する証明書は正規認証情報を構成する証明書のみとし、レスキュー認証情報を構成する証明書は設定しないものとする。従って、レスキュー認証情報は、管理対象機器40に新たな正規認証情報を記憶させる場合のみに使用する認証情報ということになる。
【0055】
証明書設定部49は、管理装置30から受信したコマンドに応じて更新用の公開鍵証明書等を、認証処理に使用するものとして証明書記憶部46に設定し、公開鍵証明書等を更新する機能を有する。
コマンド処理部50は、管理装置30から受信したコマンドに応じた動作を実行する機能を有する。この動作としては、例えば管理対象機器40が記憶しているデータの送信や、必要に応じて図示を省略したエンジン部の動作を制御することが挙げられる。なお、コマンドに基づいた動作を実行する機能部は、管理装置30のコマンド処理部39の場合と同様、実際には複数の独立したモジュールとして構成することが考えられる。そして、上記の証明書設定部49は、このようなモジュールの1つであると考えられる。
そして、これらの各部の機能は、管理対象機器40のCPUが所要の制御プログラムを実行して管理対象機器40の各部の動作を制御することにより実現される。
【0056】
次に、図5に、上述した管理装置30及び管理対象機器40が認証処理に用いる各証明書や鍵の種類を示す。この図において、(a)に管理対象機器40の証明書記憶部46に記憶している証明書及び鍵の種類を示し、(b)に管理装置30の証明書記憶部34に記憶している証明書及び鍵の種類を示している。なお、これらの図には、各装置が通信相手との間の認証処理に使用する証明書及び鍵のみを示している。
この図に示すように、管理装置30及び管理対象機器40は、大きく分けて正規認証情報とレスキュー認証情報を記憶している。そして、これらの正規認証情報とレスキュー認証情報は、それぞれ自分に関する認証情報である公開鍵証明書及び私有鍵と、通信相手に関する認証情報であるルート鍵証明書とによって構成される。また、正規認証情報が通常の通信時の認証処理に使用する認証情報であり、レスキュー認証情報は正規認証情報による認証ができなくなった場合の復旧処理時に使用する非常用の認証情報である。
そして、各装置は、通信時にはこれらの認証情報を用いて通信相手とSSLに従った図25に示したような手順の相互認証あるいは図27に示したような片方向認証を行う。
【0057】
ここで、公開鍵証明書のフォーマットは、例えば図6に示したものを用いることができ、公開鍵そのものの他、証明書の発行者や有効期限及びシリアル番号、証明される対象(証明書の発行先の装置あるいは利用者)等の情報が記載されている。このような公開鍵証明書は、具体的には、例えばX.509と呼ばれるフォーマットに従って作成することができる。
【0058】
図7に、上記のX.509フォーマットに従って作成された管理対象機器用通常公開鍵証明書の例を示す。
この例においては、Aが公開鍵証明書のシリアル番号を示す。また、Bが公開鍵証明書を発行した(公開鍵にデジタル署名を付した)管理装置30の識別情報を、Dが証明書の発行先である管理対象機器40の識別情報をそれぞれ示す。これらは、それぞれ所在地、名称、機番あるいはコード等の情報を含む。ただし、発行先の装置について、機番のように個々の装置を識別できるような識別情報を記載することは必須ではない。また、Cが有効期間を示し、その開始日時と終了日時とによって有効期間を指定している。Eが、管理対象機器用通常公開鍵の本体である。
【0059】
また、管理対象機器用通常私有鍵は、上記の管理対象機器用通常公開鍵と対応する私有鍵、管理対象機器認証用通常ルート鍵証明書は、管理対象機器認証用通常ルート鍵に自身と対応するルート私有鍵を用いて自身で正当性を確認可能なデジタル署名を付したデジタル証明書である。
なお、管理対象機器40を複数設けた場合でも、各装置の管理対象機器用通常公開鍵に付すデジタル署名は同じルート私有鍵を用いて付し、正当性確認に必要なルート鍵証明書は共通にする。しかし、管理対象機器用通常公開鍵証明書に含まれる公開鍵やこれと対応する私有鍵は、装置毎に異なる。
管理装置用通常公開鍵証明書と管理装置用通常私有鍵と管理装置認証用通常ルート鍵証明書も同様な関係である。
【0060】
そして、例えば管理装置30と管理対象機器40とが相互認証を行う場合には、管理対象機器40からの通信要求に応じて、管理装置30は管理装置用通常私有鍵を用いて暗号化した第1の乱数を管理装置用通常公開鍵証明書と共に管理対象機器40に送信する。管理対象機器40側では管理装置認証用通常ルート鍵証明書を用いてまずこの管理装置用通常公開鍵証明書の正当性(損傷や改竄を受けていないこと)を確認し、これが確認できた場合にここに含まれる公開鍵で第1の乱数を復号化する。この復号化が成功した場合に、管理対象機器40は通信相手の管理装置30が確かに管理装置用通常公開鍵証明書の発行先であると認識でき、その証明書に含まれる識別情報から装置を特定することができる。そして、特定した装置が通信相手としてふさわしいか否かに応じて認証の成功と失敗を決定することができる。
【0061】
また、管理装置30側でも、管理対象機器40側で認証が成功した場合に送信されてくる管理対象機器用通常公開鍵証明書及び、管理対象機器用通常私有鍵で暗号化された乱数を受信し、記憶している管理対象機器認証用通常ルート鍵証明書を用いて同様な認証を行うことができる。
なお、この手順は管理対象機器40がHTTPSクライアント機能部41によって管理装置30のHTTPSサーバ機能部32に対して通信を要求する場合の処理であり、管理装置30がHTTPSクライアント機能部31によって管理対象機器40のHTTPSサーバ機能部42に対して通信を要求する場合には、使用する証明書や鍵は同じであるが、管理装置30と管理対象機器40の処理が逆になる。
【0062】
ところで、ここまでの説明から明らかなように、各装置が通信相手に対して通常公開鍵証明書を送信した場合でも、証明書が破損していたり、証明書の有効期限が切れていたりした場合には、認証を行うことができない。そして、このような事態は、認証情報の更新処理中に電源が切られて更新が失敗したり、装置の電源が入れられないまま放置されて証明書の有効期限内に更新が行えなかったりした場合には十分起こり得る。
【0063】
ここで、各装置が通常公開鍵証明書を用いた認証しか行えないとすると、通常公開鍵証明書が破損したり有効期間が過ぎてしまったりしている状態では、新たな通常公開鍵証明書や通常私有鍵及び通常ルート鍵証明書をネットワークを介して安全に対象の装置に送信する方法はないことになる。しかし、この通信システムを構成する各装置は、このような事態に対処するためにレスキュー認証情報を記憶しており、通信相手を異なる2種類のデジタル証明書を用いて認証することができるようにしている。そして、レスキュー認証情報を用いることにより、管理装置30から管理対象機器40にネットワークを介して新たな通常公開鍵証明書等を安全に送信できるようにしている。
【0064】
このレスキュー認証情報は、正規認証情報と概ね同様な構成となっており、例えば管理対象機器用レスキュー公開鍵証明書は、図示しないレスキューCAが作成したレスキュー公開鍵に、管理対象機器認証用レスキュールート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。また、管理対象機器用レスキュー私有鍵はそのレスキュー公開鍵と対応する私有鍵、管理対象機器認証用レスキュールート鍵証明書は、管理対象機器認証用レスキュールート鍵に自身を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。
【0065】
そして、このようなレスキュー認証情報としては、例えば、レスキュー公開鍵証明書が、装置の識別情報が付されていないデジタル証明書であるものを使用することが考えられる。
この場合、同じ階位の装置(図1に示した例では、管理装置及び管理対象機器の階位が存在するものとする)には、全て同じレスキュー公開鍵証明書を記憶させるようにすることができる。同じ階位の各装置を個別に区別する必要がないので、証明書に含まれるレスキュー公開鍵及びこれと対応するレスキュー私有鍵も含めて、全く共通のものでよいためである。また、通信相手のレスキュー公開鍵証明書が全て同じであることから、ルート鍵証明書については、ある階位の装置の通信相手となる全ての装置について共通となる。すなわち、図24に示すように、管理対象機器を複数設けた場合でも、全ての管理対象機器に同じレスキュー認証情報を記憶させることになる。
これは、管理装置30のレスキュー認証情報についても同様である。
【0066】
また、このようなレスキュー公開鍵証明書も、通常公開鍵証明書と同様なフォーマットで作成することができ、例えば図8に示したものとすることが考えられる。この場合において、例えば、符号Gで示すように発行先装置の機番(CN)として0を記載して共通証明書であることを示すことが考えられる。また、発行元CAの情報として、符号Fで示すようにレスキューCAの識別情報を記載している。
【0067】
このようなレスキュー認証情報は、同じ階位の装置について全て共通であるという特性から、装置の製造時にその機種に応じて定まる階位に応じたものを記憶させてしまうことができる。すなわち、装置の識別情報を付した情報ではないため、検査工程を終了して識別番号を付した各装置に対してそれぞれ個別の証明書を用意して記憶させる必要はなく、多数の装置に対して単純作業によって記憶させることができる。例えば、制御プログラムのマスタにレスキュー認証情報を含めておき、制御プログラムを装置にコピーする際にレスキュー認証情報も共に記憶させる等である。
【0068】
そして、その後レスキュー認証情報を更新しないようにすれば、上記のように正規認証情報の更新が行えなかったり破損してしまったりして通常公開鍵証明書による認証が行えなくなった場合でも、レスキュー認証情報に含まれるレスキュー公開鍵証明書を用いた認証が可能な状態を保つことができる。
また、レスキュー公開鍵証明書やレスキュールート鍵証明書を更新しないようにすることを考えると、その有効期間を長くし、実質的に発行先装置の使用中に有効期限が来ないように設定することが好ましい。例えば、図8に示した例では、有効期間を50年に設定している。
【0069】
ここで、装置の識別情報を付さないレスキュー公開鍵証明書を用いる場合には、その証明書を用いた認証を行った場合でも、通信相手の装置を具体的に特定することはできない。しかし、通信相手についてある程度の情報は得ることができる。
すなわち、例えばあるベンダーが自社製品のうち管理対象機器40に該当する装置全てに管理対象機器用のレスキュー認証情報(管理対象機器用レスキュー公開鍵証明書,管理対象機器用レスキュー私有鍵及び管理装置認証用レスキュールート鍵証明書)を記憶させ、その通信相手となる管理装置30に該当する装置全てに管理装置用のレスキュー認証情報(管理装置用レスキュー公開鍵証明書,管理装置用レスキュー私有鍵及び管理対象機器認証用レスキュールート鍵証明書)を記憶させておけば、管理対象機器40は、自己の記憶している管理装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してくる相手が同じベンダーの管理装置30であることを認識できるし、逆に管理装置30も自己の記憶している管理対象機器認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してくる相手は同じベンダーの管理対象機器40であることを認識できる。
【0070】
そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができるので、その後機番情報等を交換して通信相手を特定することも可能である。
従って、通常公開鍵証明書に記載された識別情報を使用しなくても、通信相手を特定することは一応可能である。
【0071】
なお、図5に示した認証情報において、通常ルート鍵証明書は認証対象によらず同じものを用いるようにしてもよい(管理装置認証用通常ルート鍵証明書と管理対象機器認証用通常ルート鍵証明書が同じものでもよい)。これは、通常証明書には装置の識別情報が付されているため、ルート鍵証明書を用いてその正当性を確認できれば、あとはその識別情報を参照して装置の機種や階位を特定できるためである。
しかし、公開鍵証明書に装置に識別情報を付さないレスキュー認証情報を採用する場合には、公開鍵証明書に装置の識別情報が付されていないため、装置の種類の区別を、特定のルート鍵証明書で正当性を確認できるか否かによって行うことになる。従って、この場合のレスキュールート鍵証明書は認証対象の階位毎に異なる必要がある。
【0072】
ところで、SSLプロトコルに従った認証処理を行う場合には、サーバは、クライアントから通信要求があった時点ではクライアントの状態を知ることができないため、必然的に、特定のURL(Uniform Resource Locator)にアクセスされた場合には常に同じ公開鍵証明書を返すことになる。従って、基本的には、1つのサーバが公開鍵証明書を複数持ち、通信相手が認証に使用しようとする公開鍵証明書の種類に合わせて適当なものを選択して送信するといった構成を取ることはできない。しかし、図1に示した各装置においては、特殊な構成を取ることにより、通常公開鍵証明書とレスキュー公開鍵証明書とを場合によって使い分けることができるようにしている。
【0073】
そこで、次に、この使い分けのための構成を、図9を用いて説明する。
上述した通り、サーバは基本的には通信を要求してくるクライアントに対して特定の公開鍵証明書しか返すことができない。しかし、通信要求に係るURLが異なる場合には、URL毎に異なる公開鍵証明書を返すことも可能である。
従ってここでは、図9に示すように、管理装置30及び管理対象機器40にそれぞれ、通常公開鍵証明書による認証を行う通常URLと、レスキュー公開鍵証明書による認証を行うレスキューURLとを設け、通信を要求する側(クライアントとして機能する側)が、要求する認証の種類に応じていずれかのURLを選択的に指定して通信要求を送るようにしている。
【0074】
管理装置30と管理対象機器40との間の通信プロトコルにSSLを採用する場合、通信に使用するポートは443が一般的なので、通常URLとレスキューURLとではIPアドレスを変更する必要がある。従って、管理装置30及び管理対象機器40は、それぞれ別々のIPアドレスを設定可能な複数の部分(別々の筐体でも同一の筐体でもよい)からなる装置として構成することになる。
【0075】
このようにした場合、通信を要求される側(サーバとして機能する側)は、通信要求を、受け付けたURLによって区別し、通常URLで受け付けた場合には通常公開鍵証明書を返し、レスキューURLで受け付けた場合にはレスキュー公開鍵証明書を返すようにすることができる。
なお、通信を要求するクライアントの側では、どのURLに対して通信要求を送ったかがわかるので、相互認証を行う場合にはそのURLに応じた適切な公開鍵証明書を選択して送信することができる。
【0076】
そして、管理対象機器40が管理装置30と通信しようとする場合には、まず通常公開鍵証明書を用いた認証を試みるが、この認証が通常公開鍵証明書の破損や有効期間経過等のため失敗した場合、レスキュー公開鍵証明書を用いた認証を試みるようにしている。また、管理装置30が通信相手として適当な装置であれば、通常はレスキュー証明書を用いた認証が成功するので、管理装置30には、その認証が成功した場合に、管理対象機器40の正規認証情報を更新する機能を設けている。
【0077】
すなわち、管理対象機器40は管理装置30に対して通信を要求する場合、まず通常URLに通信要求を送信して通常公開鍵証明書を用いた認証を行うが、これが失敗した場合に、今度はレスキューURLに通信要求を送信してレスキュー公開鍵証明書を用いた認証を行う。
そして、管理装置30は、管理対象機器40をレスキュー公開鍵証明書を用いて認証し、通信相手として適切と判断した場合には、更新用の正規認証情報を発行し、管理対象機器40に送信してこれを記憶するよう要求するようにしている。
【0078】
レスキュー公開鍵証明書を用いた認証であっても、共通鍵の共有は通常公開鍵証明書の場合と同様に可能であるから、証明書等の送信は共有した共通鍵を用いて暗号化して安全に行うことができる。なお、ここで送信する証明書等は図10に示すものであり、管理対象機器40に記憶させる正規認証情報を構成するものである。そしてもちろん、更新用の管理対象機器用通常公開鍵証明書は、有効期間内のものである。なお、図10に示した証明書等をセットにし、証明書セットとして送信するようにしてもよい。
【0079】
また管理対象機器40は、上記の要求を受けた場合に、受信した証明書等を証明書設定部49によって証明書記憶部46に記憶させ、それまでの正規認証情報を更新するようにしている。
この更新が正常に行われれば、管理対象機器40には再び有効期間内かつ破損等していない通常公開鍵証明書が記憶されることになり、通常公開鍵証明書を用いた認証を行うことができる状態になる。従ってこの後は、通常公開鍵証明書を用いた認証を行って通信を実行するようにすればよい。
【0080】
しかし、このような正規認証情報の更新を行う場合において、レスキュー公開鍵証明書として、上述のように発行対象装置の機番が記載されていないものを用いる場合には、通信を要求してきた管理対象機器40の機番について、管理装置30は、通信経路の確立後に管理対象機器40が送信してくるものを信用することになる。そして、この機番は、例えば管理対象機器40が不揮発メモリに記憶しているものであるが、この情報自体には、通常はデジタル署名のような改竄防止の措置は講じられていないので、比較的容易に改竄し、他の装置になりすますことが可能な状態である。
そこで、この通信システムにおいては、管理装置30側に、レスキュー認証情報を用いて管理対象機器40を認証した場合に、管理対象機器40が送信してくる機番の信憑性を確認するための審査を行うようにしている。そして、この審査は、管理対象機器40に、認証を受けた時点で記憶している正規認証情報を送信させ、それが管理対象機器40が送信してきた機番と対応するものであるか否かを調べることによって行うようにしている。
【0081】
次に、このような正規認証情報とレスキュー認証情報の2種類の認証情報を用いた証明書の更新に関する処理について説明する。
まず、図11のシーケンス図に、更新処理全体の流れを示す。なおここでは、管理対象機器40に記憶している管理対象機器用通常公開鍵証明書が、破損又は有効期間の経過等により、認証を受けられない状態になっていた場合の処理例を示す。
【0082】
この例においては、まず管理対象機器40が、管理装置30と通信する際に、通信要求を送信すべきURLを確認し(S11)、HTTPSクライアント機能部41を対管理装置クライアントとして機能させて、確認した通常URLに通信要求を送信する(S12)。この場合、管理装置30側ではHTTPSサーバ機能部32が通信要求を受け、認証処理部33にこの要求を伝える。また、管理装置30は通常公開鍵証明書を用いた認証を要求されたことになる。そして認証処理部33は、SSLプロトコルに従い、証明書記憶部34に記憶している管理装置用通常私有鍵で暗号化した第1の乱数と共に、同じく証明書記憶部34に記憶している管理装置用通常公開鍵証明書を管理対象機器40に返す(S13)。
【0083】
管理対象機器40側では、これを認証処理部43に渡して認証処理を行うが、ここでは受信した管理装置用通常公開鍵証明書の正当性は証明書記憶部46に記憶している管理装置認証用通常ルート鍵証明書を用いて確認できるため、認証成功と判断し(S14)、証明書記憶部46に記憶している管理対象機器用通常私有鍵で暗号化した第2の乱数と共に、同じく証明書記憶部46に記憶している管理対象機器用通常公開鍵証明書を管理装置30に返す。またここでは、図示は省略したが、ステップS13で受信した管理装置用通常公開鍵を用いて暗号化した共通鍵の種も第2の乱数と共に返す(S15)。
管理装置30側では、これらを認証処理部33に渡して認証処理を行うが、ここでは受信した管理対象機器用通常公開鍵証明書が認証を受けられない状態であるため、認証失敗と判断する(S16)。従って、管理対象機器40との間の通信を切断する。
【0084】
すると、管理対象機器40は、通常公開鍵証明書を用いて認証を受けることができなかったため、今度はレスキューURLに通信要求を送信する(S17,S18)。そして、今度はレスキュー認証情報を用いて管理装置30との間で相互認証を試みる(S19〜S21)。なお、この処理の内容は、用いる認証情報の種類が異なるのみで、ステップS13〜S15の場合と同じ処理であるから、説明を省略する。
【0085】
そして、今度は認証が成功するので(S22)、管理装置30はその旨の応答を管理対象機器40に返す(S23)。すると、管理対象機器40はそれに応じて機番等及び証明書記憶部46に記憶している正規認証情報を管理装置30に送信する(S24)。そして、管理装置30の証明書審査部35がこれらの情報をもとに管理対象機器40を審査し、更新用の証明書を発行してよいと判断すると(S25)、証明書発行部36が更新用の証明書を発行すると共に、証明書記憶部34の証明書データベースに発行した公開鍵証明書や発行先装置の識別情報等を登録する(S26)。
そしてその後、証明書設定コマンドと共に発行した更新用証明書を管理対象機器40に転送する(S27)。
【0086】
すると、管理対象機器40は、証明書設定コマンドに付された更新用証明書を、管理装置30との通信の際に使用する正規認証情報として設定し(S28)、設定結果について管理装置30に応答を返す(S29)。以上で、レスキュー認証情報を用いた管理対象機器40の通常証明書更新の処理が終了する。
なお、以上の処理において、更新用証明書と共に私有鍵やルート鍵証明書の発行や設定を行う必要があれば、これらも共に発行や設定を行うようにするし、発行や設定を、公開鍵証明書と私有鍵とルート鍵証明書とをセットにした証明書セットの形で行うようにしてもよい。
【0087】
図1に示した通信システムにおいては、管理対象機器40において正規認証情報を構成する公開鍵証明書が認証を受けられない状態になってしまった場合でも、以上の処理により、管理対象機器40の証明書を更新して認証が正常に行える状態に回復させるようにしている。また、正規認証情報を構成する私有鍵やルート鍵証明書が破損等した場合でも、ステップS11乃至S16での認証処理が失敗する段階が異なるのみであり、ステップS17以降については上述の処理と同様である。
【0088】
ここで、図12及び図13に、管理装置30の証明書記憶部34に設ける証明書データベースの構成例を示す。
これらの図に示すように、ここでは証明書データベース中に2つのテーブルを設けている。そして、図12に示す第1のテーブルには、公開鍵証明書の発行先装置(管理対象機器)の識別情報である機番と、その装置に発行した最新の公開鍵証明書のシリアル番号(以下単に「シリアル」ともいう)、及びその公開鍵証明書の発行日時の情報を対応させて登録している。
【0089】
また、図13に示す第2のテーブルには、公開鍵証明書のシリアルと、その公開鍵証明書の内容とを対応させて登録している。ここでは、公開鍵証明書の内容として、図7に示したような書誌事項を含む公開鍵証明書をそのまま登録するようにしているが、これに加えてまたはこれに代えて、有効期限や発行先装置の国や地域等、書誌情報中の所定の項目を抽出して登録するようにしてもよい。
そして、第2のテーブルには、公開鍵証明書を発行した時点でその証明書の登録を行い、第1のテーブルの内容は、管理対象機器40から設定成功の応答があった後で更新するようにするとよい。
以上のようなテーブルを用意することにより、管理装置30は、管理対象機器40の機番をキーに、その装置が記憶しているはずの公開鍵証明書(設定が失敗していなければ、その装置に発行した最新の公開鍵証明書である)を証明書データベースから取得することができる。
【0090】
なお、図12及び図13に示すようにテーブルを2つ用意したのは、管理対象機器40に新たな公開鍵証明書を発行した場合でも、過去に発行したものも含め、全ての公開鍵証明書を記憶しておくようにするためである。また、私有鍵については、発行先の装置以外が保持しておくことは好ましくないため、ここではテーブルに登録しないようにしている。ルート鍵証明書については、多数の管理対象機器40について同じものを記憶させていることから、図示しない別のテーブルで管理し、公開鍵証明書中の、証明書のバージョン情報をキーに取得できるようにし、データ量の低減を図っている。
【0091】
次に、図11に示したような更新処理を行う場合に管理対象機器40が実行する処理について、より詳細に説明する。図14に、その処理のフローチャートを示す。この処理は、管理対象機器40のCPUが所要の制御プログラムを実行して行うものである。
管理対象機器40は、管理装置30に対してコマンドや通知を送信したり、管理装置30からのコマンドや通知を受け取るためにポーリングを行ったりする場合、図14のフローチャートに示す処理を開始し、まずステップS41で管理装置30の通常URLに対して通信要求を送信する。なお、管理対象機器40は、通信相手となる管理装置30について、通信要求先として通常URLとレスキューURLとを記憶しているものとする。
【0092】
そして、まずステップS42で、管理装置30との間で通常公開鍵証明書及び乱数や共通鍵の種を送受信し、図25に示したようなSSLによる相互認証処理を行う。そして、ステップS43でこの認証が成功したか否か判断し、成功していれば、管理装置30との間で通信を確立してステップS44以下に進んで通常の通信に係る処理を行う。なお、ステップS42での認証は、相互認証が好ましいが、少なくとも管理装置30が管理対象機器40を認証できれば、相互認証でも片方向認証でも構わない。
【0093】
以下の処理においては、まずステップS44で、ステップS42の認証処理で送信した共通鍵の種から共通鍵を生成する。そして、ステップS45でコマンド及び受信したコマンドに対する応答をその共通鍵で暗号化して通信中の装置(ここでは管理装置30)に送信し、ステップS46でコマンド及び送信したコマンドに対する応答を同じ共通鍵で暗号化された状態で通信中の装置から受信する。そして、ステップS47でコマンド及び応答を全て送受信したか否か判断する。そして、まだ残っていればステップS45に戻って処理を繰り返し、全て送受信していればステップS48に進んで通信を切断し、処理を終了する。
【0094】
なお、ステップS45及びS46の処理は、順不同で構わないし、送受信すべきコマンドや応答がなければ省略する。また、受信したコマンドに係る処理を実行して応答を生成する処理や、受信した応答の内容を解釈してそれに対応した動作を行う処理は、受信したコマンドや応答を記憶しておき、図14に示したフローチャートとは別に実行するものとする。
一方、ステップS43で認証が失敗した場合には、ステップS49以下に進み、レスキュー認証情報を利用して更新用証明書の取得を試みる処理を行う。なお、認証失敗の原因が、通信異常等、証明書の異常に起因しないものである場合には、この処理を行わないようにしてもよい。
【0095】
ステップS49以下の処理においては、まずステップS49で、管理装置30のレスキューURLに対して通信要求を送信する。そして、ステップS50で、管理装置30との間でレスキュー公開鍵証明書及び乱数や共通鍵の種を送受信し、図25に示したようなSSLによる相互認証処理を行う。
そして、ステップS51でこの認証が成功したか否か判断する。ここで認証が失敗した場合にはそのままステップS48で通信を切断して処理を終了するが、認証が成功していれば、管理装置30との間で通信を確立してステップS52以下に進み、更新用証明書の取得と設定に関する処理を行う。
【0096】
すなわち、まずステップS52で、ステップS50の認証処理で送信した共通鍵の種から共通鍵を生成する。そして、ステップS53で、その共通鍵で暗号化した機番等の情報を管理装置30に送信すると共に、ステップS54で、証明書記憶部46に記憶している正規認証情報を同じ共通鍵で暗号化して管理装置30に送信する。これらのステップS53及びS54の送信は、必要な情報を1つのメッセージに記載して行ってもよい。
ステップS53及びS54で送信した情報は、管理装置30において、管理対象機器40に更新用の証明書を発行してよいか否かを確認するための審査を行うために使用され、また更新用の証明書に記載する管理対象機器40の識別情報としても使用される。
【0097】
また、ステップS53で送信する機番以外の情報としては、例えばそれまでの正規認証情報が使用できなくなった原因の通知が考えられる。そして、通知する原因としては例えば、証明書記憶部46を構成するメモリユニットを交換した、装置がネットワークに接続されていなかったため証明書の自動更新ができなかった、証明書の更新中に電源を切られたためデータが破壊された、等が考えられる。
また、ステップS54で送信する正規認証情報は、ステップS42の処理において認証処理に使用しようとしたものであり、破損していたり、公開鍵証明書の有効期限が切れていたりして、正常に認証を受けることができない状態となっているものである。しかし、ここで送信するのは、管理装置30における審査に供するためであり、審査の基準はSSLによる認証処理の場合とは異なるので、このような状態であっても構わずに送信する。また、私有鍵は本来は他の装置に送信しないものであるが、ここでは既に対応する公開鍵証明書が認証に使用できない状態になっているものであるから、送信により私有鍵が他の装置に知られてしまったとしても、特に問題ない。
【0098】
さらに、正規認証情報には図5に示した通り公開鍵証明書と私有鍵とルート鍵証明書とが含まれるが、これら全てを送信することは必須ではない。さらにまた、正規認証情報の全部又は一部に欠落がある場合には、欠落している旨の情報を送信するようにしてもよいし、単に欠落している情報を送信しないようにするだけにしてもよい。
ステップS54の後は、ステップS55で、管理装置30からの証明書設定コマンドの受信を待つ。上述したように、レスキュー公開鍵証明書を用いた認証を行った場合には、これ以外の要求に係る動作は行わないようにしている。
【0099】
そして、証明書設定コマンドを受信すると、ステップS56に進み、証明書設定コマンドと共に受信した証明書を記憶し、これを管理装置30との通信に使用する正規認証情報として設定する。
これが完了すると、ステップS57で応答を返し、ステップS58で通信を切断して自身を再起動する。この再起動は、管理対象機器40において重要な設定を変更する際に必要なものであり、ここでは証明書の設定がこれに該当する。再起動を行う際に、ユーザに再起動の許可を求めるようにしてもよい。また、図14にはステップS58の後処理を終了するように図示しているが、実際にはステップS58での再起動時に処理は中断される。また、再起動は行わずに、そのまま処理を終了するようにしてもよい。
【0100】
ところで、ここでは管理対象機器40の通常公開鍵証明書が破損又は期限切れ等になった場合の証明書の更新について説明したが、それ以外の場合でも、証明書の更新時に管理装置30が管理対象機器40を審査することが好ましい場合がある。
図15に、この場合の正規認証情報の更新処理全体の流れを示す。
この例においては、管理対象機器40は、管理装置30との間の認証処理に使用する公開鍵証明書の有効期限の一定期間前(例えば1ヶ月前)になったことを検出すると(S61)、正規認証情報の更新時期になったと判断し、管理装置30に対して更新用の公開鍵証明書等の送信を要求する証明書要求コマンドを、図14のステップS45による通常のコマンド送信時に管理装置30へ送信するコマンドとして登録しておく。
【0101】
その後、適当なタイミングで管理対象機器40が管理装置30の通常URLに通信を要求し、その際、正規認証情報を用いて相互認証を行うが、ここでは認証情報に特に問題はないとすると、詳細な説明は図11等の説明と重複するので省略するが、認証処理は成功する(S71〜S77)。なお、ここで使用する管理対象機器40の公開鍵証明書は、共通公開鍵証明書である。
そして、認証が成功すると、管理対象機器40は、管理装置30に対し、ステップS62で登録してある証明書要求コマンドを送信する(S78)。またこのとき、機番等及び証明書記憶部46に記憶している正規認証情報も管理装置30に送信する。これらは、例えば証明書要求コマンドの引数として送信することができる。
【0102】
そして、管理装置30の証明書審査部35がこれらの情報をもとに管理対象機器40を審査し、更新用の証明書を発行してよいと判断すると(S79)、証明書発行部36が更新用の証明書を発行すると共に、証明書記憶部34の証明書データベースに発行した公開鍵証明書や発行先装置の識別情報等を登録する(S80)。
そしてその後、証明書設定コマンドと共に発行した更新用証明書を管理対象機器40に転送する(S81)。
【0103】
すると、管理対象機器40は、証明書設定コマンドに付された更新用証明書を、管理装置30との通信の際に使用する正規認証情報として設定し(S82)、設定結果について管理装置30に応答を返す(S83)。
以上で、管理対象機器40の通常証明書更新の処理が終了する。なお、ステップS80で発行する証明書は、ステップS78で受信した機番を発行先装置の識別情報として記載した個別公開鍵証明書とするとよい。また、管理対象機器40は、ステップS81での証明書更新コマンドを、図14のステップS46に示した通常のコマンド受信処理で受信し、受信したコマンドに係る処理を実行するようにすることができる。
【0104】
次に、図16及び図17に、図11乃至図15を用いて説明してきた正規認証情報の更新処理における、管理装置30側の処理のフローチャートを示す。この処理は、管理装置30のCPU11がレスキューURLに通信要求を受けた場合に開始するものであり、所要の制御プログラムを実行して行うものである。また、ステップS95以降の処理については、通常URLに通信要求を受け、一般的なコマンド送受信において証明書要求コマンドを受信した場合に実行する、このコマンドに係る処理と共通なものである。なお、管理装置30のCPUが通常URLに通信要求を受けた場合に行う一般的なコマンド送受信に関する処理については、図16及び図17に示す処理とは独立した一般的な処理であるので、ここでは説明を省略する。
【0105】
図16に示す処理においては、管理装置30のCPU11は、まずステップS91で、通信要求の要求元の装置(ここでは管理対象機器40)との間でレスキュー公開鍵証明書及び乱数と共通鍵の種を送受信し、図25に示したようなSSLによる相互認証処理を行う。
そして、ステップS92でこの認証が成功したか否か判断する。ここで認証が失敗した場合にはそのまま図17のステップS108に進んでで通信を切断して処理を終了するが、認証が成功していれば、通信要求の送信元との間で通信を確立してステップS93以下に進み、通信要求の送信元の審査及び更新用証明書の設定に関する処理を行う。また、認証が成功した時点で、通信要求の送信元がいずれかの管理対象機器であることがわかる。ここでは通信要求の送信元が管理対象機器40であるとして以後の説明を行う。
【0106】
この処理においては、まずステップS93で、ステップS91の認証処理で受信した共通鍵の種から共通鍵を生成する。そして、ステップS94で、その共通鍵で暗号化された機番等及び正規認証情報を管理対象機器40から受信する。ただし、管理対象機器40が正規認証情報の全てを送信して来たわけではない場合には、送信してきたもののみを受信することになり、ここで正規認証情報を全く受信できない場合もありうる。
このステップS94の処理が受信手順の処理であり、この処理においては管理装置30のCPU11が受信手段として機能する。
【0107】
ステップS94の後は、ステップS95に進み、ステップS94で受信した機番について、その機番が通信相手として適切な装置のものであるか否か判断する。この処理を、証明書要求コマンド(送信元は管理対象機器40とする)に係る処理として実行する場合には、証明書要求コマンドと共に受信した機番についてこの判断を行う。
そして、適切な装置のものでなければ、以後の審査を行うまでもなく、管理対象機器40に更新用証明書を発行すべきでないことがわかる。そこで、そのまま図17のステップS109に進み、審査不合格の旨及びその理由を記載したメッセージを管理対象機器40に送信すると共に、ステップS110で管理装置30のオペレータにも審査不合格の旨及びその理由を通知し、通信を切断して処理を終了する。このようになるケースとしては例えば、管理対象機器40が管理装置30による管理の対象になり得る装置であるが、管理契約が結ばれていない等の理由により管理装置30に管理対象として登録されていない場合等が考えられる。
【0108】
一方、ステップS95で適切な装置のものであれば、ステップS96に進み、ステップS94で(又は証明書要求コマンドと共に、以下同じ)受信した機番をキーに証明書記憶部34の証明書データベース(図12及び図13参照)を検索し、その機番の装置が記憶しているはずの最近の通常公開鍵証明書及び通常ルート鍵証明書の情報を取得する。この取得はもちろん管理対象機器40とは異なる場所から行うものである。また、ここで取得するのは、公開鍵証明書やルート鍵証明書の全体であっても一部分であっても、これらから証明書のシリアル番号、発行先装置の識別情報、有効期限、発行日等の必要な情報を抽出したものであってもよい。ステップS97乃至S99での審査に必要な情報を取得すれば足りる。また、ここで取得する公開鍵証明書が上述した共通公開鍵証明書である場合もある。
このステップS96の処理が取得手順の処理であり、この処理においては管理装置30のCPU11が取得手段として機能する。
【0109】
次のステップS97は、ステップS94で受信した公開鍵証明書を用いた審査の処理であり、ステップS94で管理対象機器40から受信した公開鍵証明書と、ステップS96で取得した情報とを用いて管理対象機器40を審査してその結果を結果テーブルに登録する。この公開鍵証明書を用いた審査をどのように行うかについては種々の方式が考えられるが、少なくとも、ステップS94で公開鍵証明書を受信した場合には、その公開鍵証明書が、同ステップで受信した機番の装置が記憶している公開鍵証明書として適切なものであるか否かを判断できるように行うものとする。例えば、管理対象機器40から受信した公開鍵証明書と証明書データベースから取得した公開鍵証明書との全体を比較したり、それらの一部を比較したり、両証明書からパラメータを抽出して比較したりして、両証明書の内容が一致した場合に適切なものであるとすることができる。
【0110】
図18のフローチャートに、ステップS97での公開鍵証明書を用いた審査の処理の一例を示す。
この処理においては、まずステップS111で、図16のステップS94で管理対象機器40から正規認証情報として公開鍵証明書を受信したか否か判断する。そして、受信していれば、ステップS112に進み、受信した公開鍵証明書と、図16のステップS96で証明書データベースから取得した公開鍵証明書とが一致するか否か判断する。
【0111】
そして、一致していれば、ステップS94で受信した公開鍵証明書は管理対象機器40が記憶しているはずのものであり、これは通信相手が管理対象機器40であることを支持する根拠となるので、ステップS113で結果テーブルに公開鍵証明書の審査結果として「OK」を登録して元の処理に戻る。一致していなければ、逆に通信相手が管理対象機器40でないことを支持する根拠となるので、ステップS114で審査結果として「NG」を登録して元の処理に戻る。
また、ステップS111で公開鍵証明書を受信していなければ、ステップS115で公開鍵証明書の審査結果として「なし」を登録して元の処理に戻る。
図16のステップS97での審査処理は、例えば以上のような処理により行うことができる。
【0112】
公開鍵証明書は、一般には秘密に保つデータではなく、適宜通信相手に送信してしまうデータであるため、公開鍵証明書を記憶していることは、その公開鍵証明書の発行先の装置であることの根拠にはなり難い。
しかし、特定の通信相手とのみ通信し、従って公開鍵証明書も特定の装置にしか渡さないような通信システムにおいては、全く無関係な装置が管理対象機器40の公開鍵証明書を記憶している可能性は低い。また、管理対象機器40の通信相手となる装置が、管理対象機器40と同じベンダーの製品である場合には、通信相手の側では公開鍵証明書を保存しないようにしたり、他の装置に転送しないようにしたりという対応が可能になる。
【0113】
例えば、管理対象機器40がファイアウォールの内側にあることを前提としてシステムを構築し、管理対象機器40と管理装置30との間の通信は、必ず管理対象装置40が発呼側になるように行い、かつ管理対象装置40が管理装置30以外に対しては通信を要求しないようにすれば、管理対象機器40の公開鍵証明書が、管理装置30以外の装置に対して送信されないようにすることができる。さらに、管理対象機器40において、公開鍵証明書を、基板に固定されたフラッシュロムやイープロム等のメモリにスクランブルされた状態で保存するようにすれば、オフラインでの証明書の持ち出しも防止され、管理対象機器40の公開鍵証明書が、自身と管理装置30以外の装置に記憶される事態を一層効果的に防止することができる。
【0114】
従って、このような場合には、管理装置30側で特定の機番の装置が記憶していると把握している公開鍵証明書を送信してくる装置は、本当にその機番の装置である可能性が高いといえる。特に、管理対象機器40の通信相手が管理装置30のみである場合には、管理対象機器40に対して発行した公開鍵証明書は、管理対象機器40と管理装置30のみが記憶しているはずであるから、管理装置30側で把握しているものと同じ公開鍵証明書を送信してくることをもって、対応する機番の装置であると判断するようにすることも考えられる。
【0115】
また、図19のフローチャートに、ステップS97での公開鍵証明書を用いた審査の処理の別の例を示す。この処理は、証明書要求コマンドに応じた処理の際に適用すると好適な例である。
この処理においてはまず、ステップS121及びステップS122で、図18のステップS111及びS112の場合と同様な審査を行う。
【0116】
その後、管理対象機器40から受信した機番や、受信した公開鍵証明書の有効期限の情報を用い、これらの情報をキーにして管理対象とする装置についての情報を記録している図示しないテーブルを参照し、管理対象機器40が管理対象の装置であるか否か、および管理対象機器40について管理契約期間が使用中の公開鍵証明書の有効期限後まであるか否かを判断する(S123,S124)。
【0117】
そして、管理対象の装置以外に対しては、今後も通信が可能な状態にしておく必要はないし、管理契約期間が使用中の公開鍵証明書の有効期限内で終了するのであれば、その後通信が可能な状態にしておく必要はないので、ステップS123又はS124の判断がNOである場合は、ステップS127で審査NG(不合格)として以下の処理に進む。
なお、ステップS124については、公開鍵証明書の有効期限を管理契約の期限をもとに定めてある場合には、管理延長契約がなされているか否かを基準に判断するようにしてもよい。
【0118】
また、ステップS123とS124でYESであれば、ステップS125に進み、現在の公開鍵証明書が期限切れ間近(例えば有効期限まで1ヶ月以内)か否か判断する。証明書要求コマンドは、公開鍵証明書の期限切れ間近に送信されてくるはずであるから、この判断がNOの場合には、何らかの異常が発生していると考えられ、やはりステップS127で審査NGとしてもとの処理に戻る。
また、以上のステップS121乃至S125の判断が全てYESであれば、ステップS126で審査OK(合格)として元の処理に戻る。
【0119】
以上の処理により、機番の送信元の装置を審査し、公開鍵証明書を発行してよいか否かを判断することができる。なお、審査処理において判断すべき項目については、図18や図19に示したものは一例に過ぎず、管理対象機器40の用途や管理装置30による管理の運用形態等に応じて適宜定めればよいことは、もちろんである。
【0120】
図16の説明に戻る。
次のステップS98は、ステップS94で受信した私有鍵を用いた審査の処理であり、ステップS94で管理対象機器40から受信した私有鍵と、ステップS96で取得した情報とを用いて管理対象機器40を審査してその結果を結果テーブルに登録する。この私有鍵を用いた審査をどのように行うかについても、種々の方式が考えられるが、少なくとも、ステップS94で私有鍵を受信した場合には、その私有鍵が、同ステップで受信した機番の装置が記憶している公開鍵と対応するものであるか否かを判断できるように行うものとする。例えば、管理対象機器40から受信した私有鍵と証明書データベースから取得した公開鍵証明書中の公開鍵との一方を用いて適当なデータを暗号化し、他方を用いてその暗号化したデータを復号化し、復号化により元のデータが得られた場合に適切なものであるとすることができる。
【0121】
図20のフローチャートに、ステップS98での私有鍵を用いた審査の処理の一例を示す。
この処理においては、まずステップS141で、図16のステップS94で管理対象機器40から正規認証情報として私有鍵を受信したか否か判断する。そして、受信していれば、ステップS142に進み、受信した私有鍵を用いて適当なデータを暗号化し、ステップS143で、その暗号化したデータを、図16のステップS96で証明書データベースから取得した公開鍵証明書中の公開鍵を用いて復号化する。なお、このとき復号化に管理対象機器40から受信した公開鍵証明書中の公開鍵を用いたのでは、単に管理対象機器40に互いに対応する公開鍵と私有鍵が記憶されていることを確認することにしかならないので注意が必要であるが、このようにすることも考えられる。
【0122】
そして、ステップS144でこの復号化が成功したか否か、すなわち復号化の結果暗号化前のデータが得られたか否か判断する。
ここで得られれば、ステップS94で受信した私有鍵は管理対象機器40が記憶していると管理装置30側で把握している公開鍵と対応するものであり、これは通信相手が管理対象機器40であることを支持する根拠となる。そこで、ステップS145で結果テーブルに私有鍵の審査結果として「OK」を登録して元の処理に戻る。元のデータが得られなければ、逆に通信相手が管理対象機器40でないことを支持する根拠となるので、ステップS146で審査結果として「NG」を登録して元の処理に戻る。
また、ステップS141で私有鍵を受信していなければ、ステップS147で私有鍵の審査結果として「なし」を登録して元の処理に戻る。
図16のステップS98での審査処理は、例えば以上のような処理により行うことができる。
【0123】
私有鍵は、通常は発行対象の装置しか記憶していないデータである。従って、ある機番の装置が記憶していると把握している私有鍵を送信してくる装置は、本当にその機番の装置である可能性が高いと言える。しかし、比較のために各装置に発行した私有鍵を管理装置30側で記憶しておくとすると、管理装置30が管理対象機器40になりすますことが可能になってしまい、システムの設計上好ましくない。そこで、図20に示した例においては、受信した私有鍵が、ある機番の装置が記憶していると把握している公開鍵と対応するものであることを確認することにより、その私有鍵がその機番の装置が記憶しているはずのものであることを間接的に確認するようにしている。
しかし、証明書データベースに私有鍵も記憶しておき、管理対象機器40から受信した私有鍵と証明書データベースから取得した私有鍵とを比較するようにすることも、技術的には可能である。
【0124】
再度図16の説明に戻る。
次のステップS99は、ステップS94で受信したルート鍵証明書を用いた審査の処理であり、ステップS94で管理対象機器40から受信したルート証明書と、ステップS96で取得した情報とを用いて管理対象機器40を審査してその結果を結果テーブルに登録する。このルート鍵証明書を用いた審査をどのように行うかについても種々の方式が考えられるが、考え方は公開鍵証明書の場合と同様であるから、詳細な説明は省略する。処理の具体例としても、図18に示したフローチャートの処理のうち、「公開鍵証明書」の部分を「ルート鍵証明書」と読み替えた処理を採用することが可能である。
【0125】
ルート鍵証明書も、公開鍵証明書の場合と同様、一般には秘密に保つデータではない。また、管理対象機器40と同じ階位に属する装置には共通に記憶させておくものである。従って、ルート鍵証明書を記憶していることは、特定の装置であることの根拠にはなり難い。
しかし、一度設定されたルート鍵証明書は、通常は外部の装置に送信するものではないので、全く無関係な装置が管理対象機器40のルート鍵証明書を記憶している可能性は低い。従って、このような場合には、管理装置30側で特定の階位の装置が記憶していると把握しているルート鍵証明書を送信してくる装置は、少なくとも本当にその階位の装置である可能性が高いと言える。
【0126】
また、複数のバージョンの公開鍵証明書と対応するルート鍵証明書が混在している場合、通信相手が管理装置30側で把握している公開鍵証明書と対応するルート鍵証明書を送信してくれば、このことは、通信相手が本当に送信してきた機番の装置であることを支持する証拠となる。
従って、ルート鍵証明書を用いた審査の結果も、公開鍵証明書や私有鍵を用いた審査よりは信頼性に劣るものの、公開鍵証明書や私有鍵を用いた審査の結果と組み合わせて判断材料とすれば、十分に有用なものである。
【0127】
そして、ステップS99の後は、図17のステップS100に進み、ステップS97乃至S99で結果テーブルに登録した各審査結果の内容により、通信中の管理対象機器に対する最終的な審査を行う。この審査においては、通信相手がステップS94で受信した機番の装置であると信用してよければOKを、そうでなければNGを返すようにする。
この基準としては例えば、審査結果が公開鍵証明書と私有鍵とルート鍵証明書の全てについてOKであれば最終結果もOKとし、それ以外はNGとすることが考えられる。しかし、一部の結果が「なし」であっても最終結果をOKとしたり、OKとNG以外にも、管理装置30のオペレータに警告を発したり判断を委ねたりするような審査結果を返すようにすることも可能である。これらの基準は、ベンダーにおける管理装置30の運用基準及び、管理対象機器40の用途や機能等に応じて適宜定めればよい。
【0128】
また、ステップS94で正規認証情報が使えなくなった原因の情報を受信した場合には、審査においてこのような情報も利用し、例えば原因に応じて審査の基準を変えることも考えられる。
以上のステップS97乃至S100の処理が審査手順の処理であり、この処理において、管理装置30のCPU11が審査手段として機能する。なお、審査については、ステップS97乃至S99の処理を全て行うことは必須ではなく、最低限これらのステップのいずれか1つを行えばよい。
【0129】
次のステップS101では、ステップS100での審査結果がOKであったか否か判断する。そして、OKであれば、ステップS102以下の証明書更新の処理を行う。
そして、まずステップS102で、証明書発行部36の機能により、ステップS94で受信した機番を含む更新用の証明書を作成する。図7等に示した例では、公開鍵証明書には機番以外にも発行対象装置の識別情報を記載しているが、これらの情報を記載する場合には、管理装置30のデータベースを参照したり、管理対象機器40から送信させるようにしたりして取得することができる。
ステップS102の後は、ステップS103に進み、作成した証明書の情報を証明書データベースに登録する。この処理においては、例えば図12及び図13に示したような形式の証明書データベースを用いる場合には、図13に示した第2のテーブルに公開鍵証明書を登録する。
【0130】
そして、次のステップS104では、ステップS102で作成した証明書を管理対象機器40に送信する。このとき、送信した証明書を管理装置30との通信に使用する証明書として設定するように要求する証明書設定コマンドも同時に送信する。
そして、ステップS105で証明書設定コマンドに対する応答を待って、応答があるとステップS106に進んで更新が成功したか否か判断する。そして成功していれば、ステップS107で証明書を更新させた管理対象機器40について、その機番と対応する公開鍵証明書の情報を更新する。具体的には、図12に示した第1のテーブルに登録してある証明書のシリアル番号と発行日の情報を、ステップS104で送信した証明書のものに更新する。そしてその後、ステップS108で通信を切断して終了する。
【0131】
ステップS106で成功していない場合には、そのまま通信を切断して終了する。ステップS105で所定時間応答がない場合も同様とする。このような場合でも、管理対象機器40側から再度アクセスしてくることが考えられるため、そのまま終了してしまっても差し支えないのである。このような場合には、管理対象機器40は依然として更新前と同じ正規認証情報を記憶していると想定されるので、図12に示した第1のテーブルは更新しないようにしている。
一方、ステップS101で審査OKでなかった場合には、ステップS109に進み、通信相手の管理対象機器40に、審査不合格の旨及びその理由を記載したメッセージを送信し、ステップS110で管理装置30のオペレータにも審査不合格の旨及びその理由を通知し、さらにステップS108で通信を切断して終了する。なおこの場合、管理対象機器40に通知を行ったり審査不合格の理由を正確に伝えたりすることが不適切であれば、単にそのまま通信を切断したり、ダミーのメッセージを送信したりするようにしてもよい。
【0132】
図1に示した通信システムにおいては、このような処理を行うことにより、管理対象機器40において管理装置30との間で通常の認証処理に使用していた公開鍵証明書が認証処理に使用できなくなってしまった状態であっても、また安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、管理対象機器40の公開鍵証明書を更新し、再度管理装置30との間で通常の認証処理が可能な状態に復帰させることができる。
また、この場合において、なりすましが比較的容易になされ得るレスキュー認証情報を用いた非常用の通信経路を使用したとしても、管理対象機器40が記憶している正規認証情報を機番と共に管理装置30に送信し、管理装置30側でその情報をもとに管理対象機器40を審査するようにしているので、かなりの確実性でなりすましを排除し、不正に更新用の公開鍵証明書等を取得されることを防止することができる。
また、正規認証情報に含まれる通常公開鍵証明書として共通公開鍵証明書を使用しているような場合にも、同様にその更新の際のなりすましを排除し、同様な効果を得ることができる。
【0133】
また、以上説明してきた方式によれば、自動的に公開鍵証明書を更新することができるので、この方式は、設置先の操作者による証明書の更新が行えないような装置、例えばケーブルテレビのセットトップボックスや遠隔保守の対象となる画像形成装置等に公開鍵証明書を送信する際に審査を行う審査装置や、そのような審査装置を含む通信システムに適用すると、特に効果的である。
【0134】
次に、以上説明してきた管理対象機器40における証明書記憶部46の好ましい構成について説明する。
まず、図21に、証明書記憶部46の構成例を示す。
管理対象機器40においては、図21に示すように、証明書記憶部46を構成するメモリとして、互いに独立して交換可能な第1のメモリユニットと第2のメモリユニットとを設け、その一方(ここでは第1のメモリユニット)に図5(a)に示したように正規認証情報とレスキュー認証情報を記憶させると共に、他方にも正規認証情報の一部又は全部を記憶させるようにするとよい。図21においては、第2のメモリユニットに通常公開鍵証明書を記憶させた例を示しているが、通常私有鍵や通常ルート鍵証明書、あるいはこれらの組み合わせを記憶させるようにしてもよい。また、これらのメモリユニットとしては、それぞれ書き換え可能な不揮発性メモリを用い、例えばSRAM、フラッシュメモリ、SDカードや、ハードディスクドライブを使用することも可能である。
【0135】
図21に示したような構成とした場合でも、通常は第1のメモリユニットに記憶している正規認証情報を用いた認証処理を行えばよい。しかし、管理対象機器40の運用中には、第1のメモリユニットが破損してしまい交換せざるを得なくなる場合や、第1のメモリユニットを設けたマザーボードを故障等により交換せざるを得なくなる場合も考えられる。
このような場合であっても、レスキュー認証情報が管理対象機器40の識別情報を含まないものであれば、少なくとも同一機種の管理対象機器40については共通なものを使用できるから、交換用の部品を製造する際にレスキュー認証情報を予め記憶させておくことが可能である。そして、上述したようにこのレスキュー認証情報を用いて管理装置30に通信を要求し、新たな正規認証情報の発行を求めることができる。
【0136】
しかし、もし第1のメモリユニットにしか正規認証情報を記憶させていないとすると、第1のメモリユニットが取り外された段階で管理対象機器40内に正規認証情報はなくなってしまい、新たな正規認証情報の発行を求める際に、正規認証情報を管理装置30における審査に供することができなくなってしまう。そうすると、管理装置30における審査の基準によっては、特に安全性を高めるために審査結果「なし」では審査に合格させないようにしている場合には、管理対象機器40は審査に合格できず、新たな正規認証情報の発行を受けられないことになってしまう。
一方、第2のメモリユニットにも正規認証情報を記憶させておくようにすれば、図22に示すように、第1のメモリユニットを交換した場合でも、第2のメモリユニットに記憶している正規認証情報はそのまま残る。そして、これを管理装置30に送信して審査に供することができ、正規認証情報が適切なものであれば、管理対象機器40は審査に合格して新たな正規認証情報の発行を受けることができる。
【0137】
また、管理装置30から受信した更新用の証明書を第1のメモリユニットに記憶させると共に、その一部または全部を第2のメモリユニットにも記憶させるようにすれば、図21に示した元の状態に戻すことができる。
このように、上述した実施形態の通信システムにおいては、管理対象機器40において、正規認証情報を構成する公開鍵証明書と私有鍵とを、独立して交換可能な複数のメモリユニットに分散して記憶させるようにすることが有効である。この場合において、公開鍵証明書や私有鍵を、複数のメモリユニットに記憶させる場合があってもよいことはもちろんである。
なお、図23に例を示すように、第2のメモリユニットに記憶させた証明書等は、同じものを第1のメモリユニットに記憶させなくてもよい。この場合、第2のメモリユニットに記憶させた証明書等も認証処理に使用することになるが、一方のメモリユニットを交換した場合でも他方のメモリユニットに記憶している証明書等が残ることは、上記の場合と同様である。このような態様も、当然上記の「分散して」に含まれる。
以上で管理対象機器40の証明書記憶部46についての説明を終了する。
【0138】
なお、このような点の他、以下のような変更も可能である。
まず、上述した実施形態では、管理装置30にCAの機能を設け、更新用の証明書を管理装置30自身が発行する例について説明したが、管理装置30とCAとを別々の装置とすることを妨げるものではない。この場合において、CAと管理装置30との間の通信経路は、専用線とするとよいが、SSLやVPN等により安全な通信経路を確保できれば、インターネットを介したものであってもよい。
このようにする場合、例えば、管理装置30が更新用公開鍵の送信元である被管理機器を審査して合格と判断した後、CAに更新用証明書の発行を要求して更新用証明書を発行させ、CAからその更新用証明書を受信して証明書データベースに登録し、管理対象機器40に転送するようにすることができる。
【0139】
また、CAに証明書データベースを持たせ、管理装置30が審査に使用するための公開鍵証明書やルート鍵証明書の情報を、CAから取得するようにしてもよい。CAから取得するようにしても、管理対象機器40と異なる場所から取得することに変わりはない。この場合において、更新用証明書の発行は、上記のようにCAに要求して行わせることができることはもちろんであるが、管理装置30が自身で行うようにすることも可能である。
【0140】
さらにまた、上述した管理装置30における審査の機能も、CAに持たせるようにしてもよい。このようにする場合には、管理装置30は管理対象機器40から審査に供するために受信した機番や正規認証情報等をCAに転送し、これらをもとにCAに審査処理を行わせ、審査OKならCAが発行した更新用証明書を、審査NGならその旨の情報を取得して管理対象機器40に転送することになる。もちろん、更新用証明書を取得した場合には管理対象機器40にこれを設定させる。
さらに、上述した実施形態においては、管理装置30が管理対象機器40を管理する通信システムの例について説明したが、通信相手を審査する機能を有する装置が、その審査対象の装置を管理することは必須ではない。単に相互に通信してデータの授受を行うような構成であっても、この発明を適用することは可能である。
【0141】
また、上述した実施形態では、管理装置30と管理対象機器40とが、図25あるいは図27を用いて説明したようなSSLに従った認証を行う場合の例について説明した。しかし、この認証が必ずしもこのようなものでなくてもこの発明は効果を発揮する。
SSLを改良したTLS(Transport Layer Security)も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。また、公開鍵暗号の方式についても、RSA(Rivest Shamir Adleman)だけでなく、楕円曲線暗号等の他の方式のものにも適用可能である。
また、以上説明した各変形を、適宜組み合わせて適用できることはもちろんである。
【0142】
また、この発明によるプログラムは、管理装置30を制御するコンピュータに、以上説明したような機能を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
このようなプログラムは、初めからコンピュータに備えるROMあるいはHDD等の記憶手段に格納しておいてもよいが、記録媒体であるCD−ROMあるいはフレキシブルディスク,SRAM,EEPROM,メモリカード等の不揮発性記録媒体(メモリ)に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてCPUに実行させるか、CPUにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
【産業上の利用可能性】
【0143】
以上説明してきた通り、この発明の審査装置、通信システム、審査方法、プログラムあるいは記録媒体によれば、安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、なりすましを効果的に防止できるようにすることができる。
従って、この発明を、各ノードが通信に際してデジタル証明書を用いた認証処理を行うような通信システムを運用する際に利用することにより、より安全なシステムを構成することができる。
【図面の簡単な説明】
【0144】
【図1】この発明の実施形態である通信システムの構成例を示すブロック図である。
【図2】図1に示した管理装置のハードウェア構成を示すブロック図である。
【図3】図1に示した管理装置及び管理対象機器について、この発明の特徴に関連する部分の機能構成を示す機能ブロック図である。
【図4】図3に示した管理対象機器の要求管理部におけるコマンド実行可否の判断基準について説明するための図である。
【図5】図1及び図3に示した管理装置及び管理対象機器が認証処理に用いる証明書及び鍵について説明するための図である。
【0145】
【図6】図5に示した公開鍵証明書のフォーマット例について説明するための図である。
【図7】図6に記載したフォーマットに従った管理対象機器用通常公開鍵証明書の例を示す図である。
【図8】同じく管理対象機器用レスキュー公開鍵証明書の例を示す図である。
【図9】図1に示した通信システムにおける正規認証情報とレスキュー認証情報との使い分けについて説明するための図である。
【図10】同じく管理装置が管理対象機器に正規認証情報を設定させる際に送信する証明書等の構成を示す図である。
【0146】
【図11】図1に示した通信システムにおいて、管理対象機器中の認証に使用できなくなった正規認証情報を更新する際に各装置が実行する処理の流れを示すシーケンス図である。
【図12】図1に示した管理装置の証明書記憶部に設ける証明書データベースの構成例の一部を示す図である。
【図13】同じく別の一部を示す図である。
【図14】図11に示した処理を実行する場合の、管理対象機器側の処理を示すフローチャートである。
【図15】図1に示した通信システムにおいて、管理装置が、管理対象機器との通常の通信により正規認証情報を更新する際にも発行先の管理対象機器を審査するようにする場合に、正規認証情報を更新する際に各装置が実行する処理の流れを示すシーケンス図である。
【0147】
【図16】同じく管理装置側の処理を示すフローチャートである。
【図17】その続きの処理を示すフローチャートである。
【図18】図16のステップS97に示した公開鍵証明書を用いた審査の処理の一例を示すフローチャートである。
【図19】その別の例を示す図である。
【図20】同じくステップS98に示した私有鍵を用いた審査の処理の一例を示すフローチャートである。
【0148】
【図21】図3に示した管理対象機器の証明書記憶部の好ましい構成について説明するための図である。
【図22】その別の図である。
【図23】そのさらに別の図である。
【図24】図1に示した通信システムにおいて管理対象機器を複数設けた例を示す図である。
【図25】2つの通信装置がSSLに従った相互認証を行う際に各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
【図26】図25に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。
【図27】2つの通信装置がSSLに従った片方向認証を行う際の各装置において実行する処理を示す、図25と対応する図である。
【符号の説明】
【0149】
30…管理装置、31,41…HTTPSクライアント機能部、
32,42…HTTPSサーバ機能部、33,43…認証処理部、
34,46…証明書記憶部、35…証明書審査部、36…証明書発行部、
37…コマンド発行部、38,48…要求管理部、39,50…コマンド処理部、
40…管理対象機器、44…コール通知部、45…定期通知部、47…証明書通知部
49…証明書設定部
【技術分野】
【0001】
この発明は、公開鍵暗号を用いた認証処理を行う通信装置を審査する審査装置及び審査方法、上記のような審査装置と審査対象の通信装置とを備えた通信システム、コンピュータを上記のような審査装置として機能させるためのプログラム、およびそのようなプログラムを記録したコンピュータ読み取り可能な記録媒体に関する。
【背景技術】
【0002】
従来から、それぞれ通信機能を備えた複数の通信装置をネットワークを介して通信可能に接続し、様々なシステムを構築することが行われている。その一例としては、クライアント装置として機能するPC(パーソナルコンピュータ)等のコンピュータから商品の注文を送信し、これとインターネットを介して通信可能なサーバ装置においてその注文を受け付けるといった、いわゆる電子商取引システムが挙げられる。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。
【0003】
このようなシステムを構築する上では、通信を行う際に、通信相手が適切か、あるいは送信されてくる情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばSSL(Secure Socket Layer)と呼ばれるプロトコルが開発されており、広く用いられている。このプロトコルを用いて通信を行うことにより、公開鍵暗号方式と共通鍵暗号方式とを組み合わせ、通信相手の認証を行うと共に、情報の暗号化により改竄及び盗聴の防止を図ることができる。また、通信相手の側でも、通信を要求してきた通信元の装置を認証することができる。
このようなSSLや公開鍵暗号を用いた認証に関連する技術としては、例えば特許文献1及び特許文献2に記載のものが挙げられる。
【特許文献1】特開2002−353959号公報
【特許文献2】特開2002−251492号公報
【0004】
ここで、このSSLに従った相互認証を行う場合の通信手順について、認証処理の部分に焦点を当てて説明する。図25は、通信装置Aと通信装置BとがSSLに従った相互認証を行う際に各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図25に示すように、SSLに従った相互認証を行う際には、まず双方の通信装置に、ルート鍵証明書及び、私有鍵と公開鍵証明書を記憶させておく必要がある。この私有鍵は、認証局(CA:certificate authority)が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にCAがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、CAがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。
【0005】
図26にこれらの関係を示す。
図26(a)に示すように、公開鍵Aは、私有鍵Aを用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者(CA)や有効期間等の情報を含む書誌情報とによって構成される。そして、CAは、鍵本体や書誌情報が改竄されていないことを示すため、公開鍵Aをハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名としてクライアント公開鍵に付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Aの書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、公開鍵証明書Aである。
【0006】
この公開鍵証明書Aを認証処理に用いる場合には、ここに含まれるデジタル署名を、ルート私有鍵と対応する公開鍵であるルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば、デジタル署名が確かにCAによって付されたことがわかる。また、公開鍵Aの部分をハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とが一致すれば、鍵自体も損傷や改竄を受けていないことがわかる。
また、受信したデータを公開鍵Aを用いて正常に復号化できれば、そのデータは、私有鍵Aの持ち主から送信されたものであることがわかる。
【0007】
ここで、認証を行うためには、ルート鍵を予め記憶しておく必要があるが、このルート鍵も、図26(b)に示すように、CAがデジタル署名を付したルート鍵証明書として記憶しておく。このルート鍵証明書は、自身に含まれる公開鍵でデジタル署名を復号化可能な、自己署名形式である。そして、ルート鍵を使用する際に、そのルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し、ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば、ルート鍵が破損等していないことを確認できるのである。
【0008】
図25のフローチャートの説明に入る。なお、この図において、2本のフローチャート間の矢印は、データの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また、各ステップの処理が正常に完了しなかった場合には、その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合、処理がタイムアウトした場合等も同様である。
【0009】
ここでは、通信装置Aが通信装置Bに通信を要求するものとするが、この要求を行う場合、通信装置AのCPUは、所要の制御プログラムを実行することにより、図25の左側に示すフローチャートの処理を開始する。そして、ステップS211で通信装置Bに対して接続要求を送信する。
一方通信装置BのCPUは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図25の右側に示すフローチャートの処理を開始する。そして、ステップS221で第1の乱数を生成し、これを私有鍵Bを用いて暗号化する。そして、ステップS222でその暗号化した第1の乱数と公開鍵証明書Bとを通信装置Aに送信する。
【0010】
通信装置A側では、これを受信すると、ステップS212でルート鍵証明書を用いて公開鍵証明書Bの正当性を確認する。
そして確認ができると、ステップS213で、受信した公開鍵証明書Bに含まれる公開鍵Bを用いて第1の乱数を復号化する。ここで復号化が成功すれば、第1の乱数は確かに公開鍵証明書Bの発行対象から受信したものだと確認できる。
その後、ステップS214でこれとは別に第2の乱数及び共通鍵の種を生成する。共通鍵の種は、例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして、ステップS215で第2の乱数を私有鍵Aを用いて暗号化し、共通鍵の種を公開鍵Bを用いて暗号化し、ステップS216でこれらを公開鍵証明書Aと共にサーバ装置に送信する。共通鍵の種の暗号化は、通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。
また、次のステップS217では、ステップS214で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
【0011】
通信装置B側では、通信装置AがステップS216で送信してくるデータを受信すると、ステップS223でルート鍵証明書を用いて公開鍵証明書Aの正当性を確認する。そして確認ができると、ステップS224で、受信した公開鍵証明書Aに含まれる公開鍵Aを用いて第2の乱数を復号化する。ここで復号化が成功すれば、第2の乱数は確かに公開鍵証明書Aの発行対象から受信したものだと確認できる。
その後、ステップS225で私有鍵Bを用いて共通鍵の種を復号化する。ここまでの処理で、通信装置A側と通信装置B側に共通鍵の種が共有されたことになる。そして、この共通鍵の種は、生成した通信装置Aと、私有鍵Bを持つ通信装置B以外の装置が知ることはない。ここまでの処理が成功すると、通信装置B側でもステップS226で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
【0012】
そして、通信装置A側のステップS217と通信装置B側のステップS226の処理が終了すると、相互に認証の成功と以後の通信に使用する暗号化方式とを確認し、生成した共通鍵を用いてその暗号化方式で以後の通信を行うものとして認証に関する処理を終了する。なお、この確認には、通信装置Bからの認証が成功した旨の応答も含むものとする。以上の処理によって互いに通信を確立し、以後はステップS217又はS226で生成した共通鍵を用い、共通鍵暗号方式でデータを暗号化して通信を行うことができる。
【0013】
このような処理を行うことにより、通信装置Aと通信装置Bが互いに相手を認証した上で安全に共通鍵を共有することができ、通信を安全に行う経路を確立することができる。
なお、片方向認証を採用し、例えば通信装置Bが通信要求元の通信装置Aを認証するのみでよいのであれば、図25に示した認証処理において、第1の乱数の暗号化及び送信を省略することができる。この場合でも、共通鍵の種を通信装置Aから通信装置Bに安全に送信するために、通信装置Bの公開鍵Bを用いた暗号化を行うとよいが、公開鍵Bに付されたデジタル署名の正当性を確認することは行わなくてよい。そして、この場合の認証処理は、図27に示すように簡略化されたものになる。すなわち、通信装置A側のステップS212及びS213の処理は不要となり、通信装置B側のステップS221の処理も不要となる。また、その他の処理も一部簡略化することができる。
【0014】
以上のような認証処理においては、公開鍵で暗号化された内容は対応する私有鍵を持つ装置でしか復号できず、また、私有鍵で暗号化された内容は対応する公開鍵でしか復号できないことを利用して、通信相手が公開鍵証明書にその発行先として記載されている装置である(又はその装置の利用者が公開鍵証明書にその発行先として記載されている利用者である)と認証することになる。
【0015】
なお、このような認証処理に使用する公開鍵の管理に関する技術としては、例えば特許文献3及び4に記載の技術が知られている。
特許文献3には、複写機管理装置2がホストコンピュータ4から受信した公開鍵を記憶しておき、異常情報をホストコンピュータ4に送信する際に、記憶している最新の公開鍵を用いて異常情報を暗号化することが記載されている。
特許文献4には、公開鍵暗号を用いた認証処理を行うクライアントがWWWサーバにアクセスした際に、公開鍵証明書の期限切れが近い場合にはその旨をクライアントに警告するようにすることが記載されている。
【特許文献3】特開2001−242750号公報
【特許文献4】特開2003−273855号公報
【発明の開示】
【発明が解決しようとする課題】
【0016】
ところで、公開鍵暗号方式においては、鍵長にもよるが、時間をかければ公開鍵から私有鍵を導くことができる。そして、私有鍵がわかってしまえば、第3者がその私有鍵の持ち主になりすますことが可能になるので、認証の確実性や通信の安全性が保たれない。そこで、上述のように鍵に有効期限を設け、所定期間毎に鍵のセットを更新するというセキュリティポリシーを採用するユーザが増えている。このため、例えば上記のような相互認証を利用した遠隔管理システム等を提供する場合には、顧客に対し、鍵の更新が可能なシステムであるという保証を行う必要が生じている。
【0017】
そして、公開鍵証明書を用いて認証を受ける通信装置に更新用の新しい公開鍵証明書を配布する方式としては、使用中の公開鍵証明書の有効期限が切れる前に、CAが通信装置に対して新たな公開鍵証明書と私有鍵を発行し、これらとルート鍵証明書のセットを、CAあるいはそれに代わる管理装置が、使用中の公開鍵証明書を用いて確立したSSLによる通信経路で更新対象の装置に送信して設定させる方式が考えられる。
このようにすれば、通信装置が認証に使用する公開鍵証明書等を、有効期限が切れる前に自動的に更新することができるので、ユーザの手を煩わせることなく、通信装置を認証可能な状態に保つことができる。また、インターネットを介して送信を行う場合でも、安全な通信経路を確保して公開鍵証明書等の転送を行うことができる。
【0018】
しかしながら、このような方式を採用したとしても、更新対象の装置が、更新を行うべき期間の間にネットワークに接続されていなかったり、電源が入れられなかったりした場合には、公開鍵証明書を更新できないうちに使用中の公開鍵証明書の有効期限が切れてしまうことが考えられる。そして、これらのような状態になってしまった場合には、更新対象の装置は、もはやCAや管理装置に通常の認証を受けることはできない状態になってしまい、SSLによる安全な通信経路も確立できない状態になってしまう。
【0019】
ただし、このような場合であっても、通信装置にCAや管理装置との間で非常用の通信経路を確保する手段を設けておけば、通信装置がその経路を通して通常の通信経路を確立するための新たな公開鍵証明書等を取得できるようにすることも可能である。このような非常用の通信経路としては、例えば、有効期限の長い公開鍵証明書及びこれと対応する私有鍵やルート鍵証明書を、ベンダーが提供する各装置に共通に記憶させておき、これらを用いてCAや管理装置との間でSSLによる通信経路を確立できるようにすることが考えられる。
このような技術について、本件出願人は過去に特許出願を行っている(特願2003−341329、未公開)。
【0020】
しかし、このような非常用の通信経路については、普段は使用しないものであり、また通常の通信経路での通信に不都合があるような場合でも通信が可能であるようにする必要があるため、通常の通信経路の場合と同様な厳密さで認証処理を行うことができるようにすることは難しい。例えば、上記のように各装置に共通な公開鍵証明書を記憶させる場合には、公開鍵証明書に装置の識別情報を記載することはできないため、SSLによる認証処理の時点では装置の識別情報を参照することができない。そして、CAや管理装置は、通信経路の確立後に通信装置に識別情報を送信させ、その情報を信用して更新用の公開鍵証明書等の送信を行うことになる。
【0021】
従って、非常用の通信経路に関しては、他の通信装置になりすまして更新用の公開鍵証明書を取得することが、比較的簡単にできてしまうという問題があった。そこで、非常用の通信経路を使用する場合、すなわち通常の通信経路が使用できない場合でも、なりすましを効果的に防止できるようにすることが望まれていた。
この点に関し、上述した各特許文献には、通常使用する公開鍵証明書が使用できなくなった状態での公開鍵証明書の更新については、特に触れられていない。
また、生産設備等の都合により、通常使用する公開鍵証明書についても、上述の非常用の公開鍵証明書の場合のように、各装置に共通な公開鍵証明書を設定せざるを得ない場合もある。そして、このような場合には、上記の非常用の通信経路を利用する場合と同じく、通常使用する公開鍵証明書を、その有効期間内に更新する場合でも、なりすましを効果的に防止できるようにすることが望まれていた。
この発明は、上記のような要望に応え、安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、なりすましを効果的に防止できるようにすることを目的とする。
【課題を解決するための手段】
【0022】
上記の目的を達成するため、この発明の審査装置は、公開鍵暗号を用いた認証処理を行うがその認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、その通信装置の公開鍵証明書とその通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、上記識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて上記通信装置を審査する審査手段とを設けたものである。
このような審査装置において、上記審査手段に、上記受信手段が受信した公開鍵証明書の内容と上記取得手段が取得した情報とが一致するか否かに基づいて上記公開鍵証明書が適切なものであるか否かを判断する手段を設けるとよい。
【0023】
また、この発明は、公開鍵暗号を用いた認証処理を行う通信装置から、その通信装置の私有鍵と、その通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵を、その識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した公開鍵と上記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて上記通信装置を審査する審査手段とを設けた審査装置も提供する。
このような審査装置において、通信装置の識別情報とその通信装置が上記認証処理に使用する公開鍵との対応関係を記憶する手段を設けるとよい。
さらに、上記審査手段に、上記取得手段が取得した公開鍵と上記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて上記審査を行う手段を設けるとよい。
【0024】
また、上記の各審査装置において、上記通信装置が上記審査手段による審査に合格した場合に、上記通信装置に、その通信装置の新たな公開鍵証明書を送信する送信手段を設けるとよい。
さらに、上記送信手段が送信する公開鍵証明書を、上記受信手段が受信した上記通信装置の識別情報を含む公開鍵証明書とするとよい。
【0025】
また、この発明の通信システムは、公開鍵暗号を用いた認証処理を行うがその認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置であって、自身の公開鍵証明書と自身の識別情報とを審査装置に送信する手段を有する通信装置と、その通信装置から、その通信装置の公開鍵証明書とその通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、上記識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて上記通信装置を審査する審査手段とを設けた審査装置と備える通信システムである。
このような通信システムにおいて、上記審査装置の審査手段に、上記受信手段が受信した公開鍵証明書の内容と上記取得手段が取得した情報とが一致するか否かに基づいて上記公開鍵証明書が適切なものであるか否かを判断する手段を設けるとよい。
【0026】
また、この発明は、公開鍵暗号を用いた認証処理を行う通信装置であって、自身の私有鍵と識別情報とを審査装置に送信する手段を有する通信装置と、その通信装置から、その通信装置の私有鍵と、その通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵を、その識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した公開鍵と上記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて上記通信装置を審査する審査手段とを備える審査装置とを設けた通信システムも提供する。
【0027】
このような通信システムにおいて、上記審査装置に、通信装置の識別情報とその通信装置が上記認証処理に使用する公開鍵との対応関係を記憶する手段を設けるとよい。
さらに、上記審査装置の審査手段に、上記取得手段が取得した公開鍵と上記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて上記審査を行う手段を設けるとよい。
【0028】
また、上記の各通信システムにおいて、上記審査装置に、上記通信装置が上記審査手段による審査に合格した場合に、上記通信装置に、その通信装置の新たな公開鍵証明書を送信する送信手段を設け、上記通信装置に、その公開鍵証明書を受信する手段を設けるとよい。
さらに、上記審査装置の送信手段が送信する公開鍵証明書を、上記受信手段が受信した上記通信装置の識別情報を含む公開鍵証明書とするとよい。
さらにまた、上記通信装置において、上記認証処理に使用する公開鍵証明書と私有鍵とを、独立して交換可能な複数のメモリユニットに分散させて記憶させるようにするとよい。
【0029】
また、この発明の審査方法は、公開鍵暗号を用いた認証処理を行うがその認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、その通信装置の公開鍵証明書とその通信装置の識別情報とを受信する受信手順と、その手順で受信した識別情報と対応する公開鍵証明書の内容を示す情報を、上記識別情報をもとに上記通信装置とは異なる場所から取得する取得手順と、その手順で取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて上記通信装置を審査する審査手順とを有するものである。
このような審査方法において、上記審査手順に、上記受信手順で受信した公開鍵証明書の内容と、上記取得手順で取得した情報とが一致するか否かに基づいて上記公開鍵証明書が適切なものであるか否かを判断する手順を設けるとよい。
【0030】
また、この発明は、公開鍵暗号を用いた認証処理を行う通信装置から、その通信装置の私有鍵と、その通信装置の識別情報とを受信する受信手順と、その手順で受信した識別情報と対応する公開鍵を、その識別情報をもとに上記通信装置とは異なる場所から取得する取得手順と、その手順で取得した公開鍵と上記受信手順で受信した私有鍵とが対応するものであるか否かに基づいて上記通信装置を審査する審査手順とを有する審査方法も提供する。
このような審査方法において、上記各手順を実行する装置に、通信装置の識別情報とその通信装置が上記認証処理に使用する公開鍵との対応関係を記憶させておくようにするとよい。
さらに、上記審査手順に、上記取得手順で取得した公開鍵と上記受信手順で受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて上記審査を行う手順を設けるとよい。
【0031】
また、上記の各審査方法におて、上記通信装置が上記審査手順における審査に合格した場合に、上記通信装置に、その通信装置の新たな公開鍵証明書を送信する送信手順をさらに設けるとよい。
さらに、上記送信手順で送信する公開鍵証明書を、上記受信手順で受信した上記通信装置の識別情報を含む公開鍵証明書とするとよい。
【0032】
また、この発明のプログラムは、コンピュータを、公開鍵暗号を用いた認証処理を行うがその認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、その通信装置の公開鍵証明書と、その通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、上記識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて上記通信装置を審査する審査手段として機能させるためのプログラムである。
このようなプログラムにおいて、上記審査手段に、上記受信手段が受信した公開鍵証明書の内容と上記取得手段が取得した情報とが一致するか否かに基づいて上記公開鍵証明書が適切なものであるか否かを判断する機能を設けるとよい。
【0033】
また、この発明は、コンピュータを、公開鍵暗号を用いた認証処理を行う通信装置から、その通信装置の私有鍵と、その通信装置の識別情報とを受信する受信手段と、その手段が受信した識別情報と対応する公開鍵を、その識別情報をもとに上記通信装置とは異なる場所から取得する取得手段と、その手段が取得した公開鍵と上記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて上記通信装置を審査する審査手段として機能させるためのプログラムも提供する。
このようなプログラムにおいて、上記コンピュータを、通信装置の識別情報とその通信装置が上記認証処理に使用する公開鍵との対応関係を記憶する手段として機能させるためのプログラムを更に含めるとよい。
さらに、上記審査手段に、上記取得手段が取得した公開鍵と上記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて上記審査を行う機能を設けるとよい。
【0034】
また、上記の各プログラムにおいて、上記コンピュータを、上記通信装置が上記審査手段による審査に合格した場合に、上記通信装置に、その通信装置の新たな公開鍵証明書を送信する送信手段として機能させるためのプログラムを更に含めるとよい。
さらに、上記送信手段が送信する公開鍵証明書を、上記受信手段が受信した上記通信装置の識別情報を含む公開鍵証明書とするとよい。
【0035】
また、この発明の記録媒体は、上記のいずれかのプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【発明の効果】
【0036】
以上のようなこの発明の審査装置、通信システム、あるいは審査方法によれば、安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、なりすましを効果的に防止できるようにすることができる。
また、この発明のプログラムによれば、コンピュータを上記の審査装置として機能させてその特徴を実現し、同様な効果を得ることができる。この発明の記録媒体によれば、上記のプログラムを記憶していないコンピュータにそのプログラムを読み出させて実行させ、上記の効果を得ることができる。
【発明を実施するための最良の形態】
【0037】
以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明の審査装置と、その審査装置を用いて構成したこの発明の通信システムの実施形態の構成について説明する。
図1にその通信システムの構成を示す。
この実施形態においては、図1に示すように、審査装置である管理装置30及びその通信相手となる通信装置である管理対象機器40によって通信システムを構成している。
そして、この通信システムにおいて、管理装置30は、管理対象機器40と通信を行おうとする場合、公開鍵暗号とデジタル証明書(公開鍵証明書)を用いる認証方式であるSSLプロトコルに従った認証処理によって管理対象機器40を正当な通信相手として認証した場合に、管理対象機器40との間で通信を確立させるようにしている。そして、管理装置30が送信した動作要求(コマンド)に対し、管理対象機器40が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。
【0038】
逆に、管理対象機器40が管理装置30と通信を行おうとする場合にも、同じくSSLに従った認証処理によって管理装置30を正当な通信相手として認証した場合に、管理装置30との間で通信を確立させるようにしている。そして、管理対象機器40が送信した動作要求(コマンド)に対し、管理装置30が必要な処理を行って応答を返すことにより、クライアント・サーバシステムとして機能する。
どちらの場合も、通信を要求する側がクライアント、要求される側がサーバとして機能するものとする。
【0039】
なお、この通信システムにおいて、管理装置30は、管理対象機器40を管理する機能の他、管理対象機器40に対し、通常使用する公開鍵証明書を用いて上記のようなSSLによる認証ができなくなった状態で通常の認証を行うための公開鍵証明書を再発行する機能と、その再発行を行う場合において、その再発行先の管理対象機器40を審査して再発行を行ってよいかどうか判断する機能も有する。
また、図1において、管理対象機器40は1つしか示していないが、図24に示すように管理対象機器40を複数設けることも可能である。また、管理対象機器40が1種類である必要もない。ただし、管理装置30は1つの通信システムについて1つである。
【0040】
このような通信システムにおいて、上述の管理装置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)等の既知のプロトコル(通信規格),技術,仕様などを利用することができる。
【0041】
次に、図1に示した各装置の構成と機能についてより詳細に説明する。
図1に示した管理装置30及び管理対象機器40は、装置の遠隔管理,電子商取引等の目的に応じて種々の構成をとることができる。例えば、遠隔管理の場合には、プリンタ,FAX装置,コピー機,スキャナ,デジタル複合機等の画像処理装置を始め、ネットワーク家電,自動販売機,医療機器,電源装置,空調システム,ガス・水道・電気等の計量システム,自動車,航空機等の電子装置を被管理装置である管理対象機器40とし、これらの被管理装置から情報を収集したり、コマンドを送って動作させたりするための管理装置を管理装置30とすることが考えられる。
【0042】
ここで、図2に管理装置30のハードウェア構成例を示す。この図に示す通り、管理装置30は、例えばCPU11,ROM12,RAM13,HDD14,通信インタフェース(I/F)15を設け、これらをシステムバス16によって接続して構成することができる。そして、CPU11がROM12やHDD14に記憶している各種制御プログラムを実行することによってこの管理装置30の動作を制御し、通信相手の認証、管理対象機器40との通信、管理対象機器40の管理や審査、公開鍵証明書の発行等の機能を実現させている。
もちろん、管理装置30として適宜公知のコンピュータを用いたり、必要に応じて他のハードウェアを付加したりしてもよい。
【0043】
また、管理対象機器40も、少なくともそれぞれCPU,ROM,RAM,ネットワークを介して外部装置と通信するための通信I/F、および認証処理に必要な情報を記憶する記憶手段を備え、CPUがROM等に記憶した所要の制御プログラムを実行することにより、装置にこの発明に係る各機能を実現させることができるものとする。
なお、この管理装置30と管理対象機器40との間の通信には、有線,無線を問わず、ネットワークを構築可能な各種通信回線(通信経路)を採用することができる。
【0044】
ここで、図3に、管理装置30及び管理対象機器40の、この実施形態の特徴に関連する部分の機能構成に係る機能ブロック図を示す。なお、図中の矢印は、後述するように管理対象機器40が通常の公開鍵証明書を用いた認証を受けられなくなった状態で管理対象機器40にその通常の公開鍵証明書を再発行場合のデータの流れを示すものである。
まず、管理装置30は、HTTPS(Hypertext Transfer Protocol Security)クライアント機能部31,HTTPSサーバ機能部32,認証処理部33,証明書記憶部34,証明書審査部35,証明書発行部36,コマンド発行部37,要求管理部38,コマンド処理部39を備えている。
【0045】
HTTPSクライアント機能部31は、SSLに従った認証や暗号化の処理を含むHTTPSプロトコルを用いて、管理対象機器40等のHTTPSサーバの機能を有する装置に対して通信を要求する機能を有する。
一方、HTTPSサーバ機能部32は、HTTPSクライアントの機能を有する装置からのHTTPSプロトコルを用いた通信要求を受け付ける機能を有する。
そして、これらのHTTPSクライアント機能部31とHTTPSサーバ機能部32とで、通信相手に対してコマンドやデータを送信してそれに応じた動作を実行させる機能と、通信相手から要求やデータを受信してそれに応じた動作を装置の各部に実行させ、その結果を応答として要求元に返す機能とを実現している。この場合において、通信を要求した側がコマンドを送信することもあるし、通信要求を受け付けた側がコマンドを送信することもある。応答についても同様である。
【0046】
認証処理部33は、HTTPSクライアント機能部31やHTTPSサーバ機能部32が通信相手を認証する際に、通信相手から受信した公開鍵証明書や、証明書記憶部34に記憶している各種証明書、私有鍵等を用いて認証処理を行う認証手段の機能を有する。また、通信相手に認証を要求するために、証明書記憶部34に記憶している公開鍵証明書をHTTPSクライアント機能部31やHTTPSサーバ機能部32を介して通信相手に送信する機能も有する。
証明書記憶部34は、公開鍵証明書や私有鍵、ルート鍵証明書等の認証情報を記憶し、認証処理部33における認証処理に供する機能を有する。そして、証明書記憶部34が記憶している認証情報には、詳細は後述するが、通常の通信時の認証処理に使用する正規認証情報と、正規認証情報による認証ができなくなった場合の復旧に使用する非常用のレスキュー認証情報とがある。また、証明書記憶部34は、証明書発行部36が発行した公開鍵証明書及びその発行先や発行日に関する情報をデータベースとして記憶しておく機能も有する。
【0047】
証明書審査部35は、認証処理部33がレスキュー認証情報により管理対象機器40との間で認証処理を行った場合に、その管理対象機器40から受信する機番や証明書等の情報をもとに、その管理対象機器40に対して更新用の公開鍵証明書や私有鍵を発行してよいか否かを審査する機能を有する。証明書発行部36は、証明書審査部35が審査で発行してよいと判断した場合に、更新用の公開鍵証明書や私有鍵を発行し、これらを管理対象機器40に送信する機能を有する。なお公開鍵証明書の発行については、管理対象機器40が作成して送信してきた公開鍵にデジタル署名を付して返送するようにすることも考えられる。
【0048】
コマンド発行部37は、管理対象機器40に対して種々のコマンドを発行して管理対象機器40にそのコマンドに従った動作を実行させる機能を有する。管理対象機器40に実行させる動作としては、管理対象機器40の動作内容や設定状態に関する情報の送信、管理装置30から送信した更新用の公開鍵証明書を始めとする情報の記憶やそれに応じた設定変更等が考えられる。そして、コマンド発行部37は、管理対象機器40から取得した情報に従って管理対象機器40に種々の動作を実行させることにより、管理対象機器40を管理する機能も有する。
【0049】
要求管理部38は、管理装置から受信したコマンドについて、そのコマンドに基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、そのコマンドに基づいた動作を実行する機能部に対してコマンドを伝える機能も有する。なお、コマンドに基づいた動作を実行する機能部は、実際には複数の独立したモジュールとして構成することが考えられるが、図3においてはコマンド処理部39として一括して示している。そして、このコマンド処理部39が実行する動作としては、例えば管理対象機器40からの異常発生通知に対する対応や、管理対象機器40からの要求に応じて管理装置30が記憶しているデータを送信する動作等が挙げられる。
以上の各部の機能は、管理装置30のCPUが所要の制御プログラムを実行して管理装置30の各部の動作を制御することにより実現される。
【0050】
次に、管理対象機器40には、HTTPSクライアント機能部41,HTTPSサーバ機能部42,認証処理部43,コール通知部44,定期通知部45,証明書記憶部46,証明書通知部47,要求管理部48,証明書設定部49,コマンド処理部50を備えている。
HTTPSクライアント機能部41は、管理装置30のHTTPSクライアント機能部31と同様に、HTTPSプロトコルを用いて管理装置30等のHTTPSサーバの機能を有する装置に対して通信を要求すると共に、コマンドやそれに対する応答を送受信する機能を有する。
【0051】
HTTPSサーバ機能部42も、管理装置30のHTTPSサーバ機能部32と同様であり、HTTPSクライアントの機能を有する装置からの通信要求を受け付けると共に、コマンドやそれに対する応答を送受信する機能を有する。
認証処理部43の機能も、管理装置30の認証処理部33と同様であるが、認証処理に使用する証明書等は、証明書記憶部46に記憶しているものである。
【0052】
コール通知部44は、異常を検知したりユーザによる指示があったりした場合に管理装置30に対してその旨を通知するコールを行う機能を有する。
定期通知部45は、管理対象機器40から管理装置30への定期的な通知を行う機能を有する。その通知の内容としては、例えば画像形成装置であれば画像形成枚数カウンタのカウント値、計量システムであればその計量値等が考えられる。
【0053】
証明書記憶部46は、管理装置30の証明書記憶部34と同様に各種の証明書や私有鍵等の認証情報を記憶し、認証処理部43における認証処理に供する証明書記憶手段の機能を有する。ただし、記憶している証明書等は、後述するように証明書記憶部34とは異なる。
証明書通知部47は、正規認証情報による認証が受けられなくなり、レスキュー認証情報により管理装置30に認証を受けた場合等、管理装置30に正規認証情報を用いた審査を受ける必要がある場合に、管理装置30に、管理対象機器40の機番と共にそれまで使用していた正規認証情報を送信し、管理装置30における管理対象機器40の審査に供する機能を有する。
【0054】
要求管理部48は、管理装置30から受信したコマンドについて、そのコマンドに基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、そのコマンドに基づいた動作を実行する証明書設定部49及びコマンド処理部50のような機能部に対してコマンドを伝える機能も有する。
図4にこの実行可否の判断基準を示すが、その判断基準は、コマンドの種類及び認証処理部43において認証処理に使用した認証情報の種類である。要求管理部48は、図4に示すように、正規認証情報による認証を行った場合には全ての動作を許可するが、レスキュー認証情報による認証を行った場合には証明書(私有鍵も含む)の設定動作のみを許可するようにしている。なお、ここでは設定(更新も含む)する証明書は正規認証情報を構成する証明書のみとし、レスキュー認証情報を構成する証明書は設定しないものとする。従って、レスキュー認証情報は、管理対象機器40に新たな正規認証情報を記憶させる場合のみに使用する認証情報ということになる。
【0055】
証明書設定部49は、管理装置30から受信したコマンドに応じて更新用の公開鍵証明書等を、認証処理に使用するものとして証明書記憶部46に設定し、公開鍵証明書等を更新する機能を有する。
コマンド処理部50は、管理装置30から受信したコマンドに応じた動作を実行する機能を有する。この動作としては、例えば管理対象機器40が記憶しているデータの送信や、必要に応じて図示を省略したエンジン部の動作を制御することが挙げられる。なお、コマンドに基づいた動作を実行する機能部は、管理装置30のコマンド処理部39の場合と同様、実際には複数の独立したモジュールとして構成することが考えられる。そして、上記の証明書設定部49は、このようなモジュールの1つであると考えられる。
そして、これらの各部の機能は、管理対象機器40のCPUが所要の制御プログラムを実行して管理対象機器40の各部の動作を制御することにより実現される。
【0056】
次に、図5に、上述した管理装置30及び管理対象機器40が認証処理に用いる各証明書や鍵の種類を示す。この図において、(a)に管理対象機器40の証明書記憶部46に記憶している証明書及び鍵の種類を示し、(b)に管理装置30の証明書記憶部34に記憶している証明書及び鍵の種類を示している。なお、これらの図には、各装置が通信相手との間の認証処理に使用する証明書及び鍵のみを示している。
この図に示すように、管理装置30及び管理対象機器40は、大きく分けて正規認証情報とレスキュー認証情報を記憶している。そして、これらの正規認証情報とレスキュー認証情報は、それぞれ自分に関する認証情報である公開鍵証明書及び私有鍵と、通信相手に関する認証情報であるルート鍵証明書とによって構成される。また、正規認証情報が通常の通信時の認証処理に使用する認証情報であり、レスキュー認証情報は正規認証情報による認証ができなくなった場合の復旧処理時に使用する非常用の認証情報である。
そして、各装置は、通信時にはこれらの認証情報を用いて通信相手とSSLに従った図25に示したような手順の相互認証あるいは図27に示したような片方向認証を行う。
【0057】
ここで、公開鍵証明書のフォーマットは、例えば図6に示したものを用いることができ、公開鍵そのものの他、証明書の発行者や有効期限及びシリアル番号、証明される対象(証明書の発行先の装置あるいは利用者)等の情報が記載されている。このような公開鍵証明書は、具体的には、例えばX.509と呼ばれるフォーマットに従って作成することができる。
【0058】
図7に、上記のX.509フォーマットに従って作成された管理対象機器用通常公開鍵証明書の例を示す。
この例においては、Aが公開鍵証明書のシリアル番号を示す。また、Bが公開鍵証明書を発行した(公開鍵にデジタル署名を付した)管理装置30の識別情報を、Dが証明書の発行先である管理対象機器40の識別情報をそれぞれ示す。これらは、それぞれ所在地、名称、機番あるいはコード等の情報を含む。ただし、発行先の装置について、機番のように個々の装置を識別できるような識別情報を記載することは必須ではない。また、Cが有効期間を示し、その開始日時と終了日時とによって有効期間を指定している。Eが、管理対象機器用通常公開鍵の本体である。
【0059】
また、管理対象機器用通常私有鍵は、上記の管理対象機器用通常公開鍵と対応する私有鍵、管理対象機器認証用通常ルート鍵証明書は、管理対象機器認証用通常ルート鍵に自身と対応するルート私有鍵を用いて自身で正当性を確認可能なデジタル署名を付したデジタル証明書である。
なお、管理対象機器40を複数設けた場合でも、各装置の管理対象機器用通常公開鍵に付すデジタル署名は同じルート私有鍵を用いて付し、正当性確認に必要なルート鍵証明書は共通にする。しかし、管理対象機器用通常公開鍵証明書に含まれる公開鍵やこれと対応する私有鍵は、装置毎に異なる。
管理装置用通常公開鍵証明書と管理装置用通常私有鍵と管理装置認証用通常ルート鍵証明書も同様な関係である。
【0060】
そして、例えば管理装置30と管理対象機器40とが相互認証を行う場合には、管理対象機器40からの通信要求に応じて、管理装置30は管理装置用通常私有鍵を用いて暗号化した第1の乱数を管理装置用通常公開鍵証明書と共に管理対象機器40に送信する。管理対象機器40側では管理装置認証用通常ルート鍵証明書を用いてまずこの管理装置用通常公開鍵証明書の正当性(損傷や改竄を受けていないこと)を確認し、これが確認できた場合にここに含まれる公開鍵で第1の乱数を復号化する。この復号化が成功した場合に、管理対象機器40は通信相手の管理装置30が確かに管理装置用通常公開鍵証明書の発行先であると認識でき、その証明書に含まれる識別情報から装置を特定することができる。そして、特定した装置が通信相手としてふさわしいか否かに応じて認証の成功と失敗を決定することができる。
【0061】
また、管理装置30側でも、管理対象機器40側で認証が成功した場合に送信されてくる管理対象機器用通常公開鍵証明書及び、管理対象機器用通常私有鍵で暗号化された乱数を受信し、記憶している管理対象機器認証用通常ルート鍵証明書を用いて同様な認証を行うことができる。
なお、この手順は管理対象機器40がHTTPSクライアント機能部41によって管理装置30のHTTPSサーバ機能部32に対して通信を要求する場合の処理であり、管理装置30がHTTPSクライアント機能部31によって管理対象機器40のHTTPSサーバ機能部42に対して通信を要求する場合には、使用する証明書や鍵は同じであるが、管理装置30と管理対象機器40の処理が逆になる。
【0062】
ところで、ここまでの説明から明らかなように、各装置が通信相手に対して通常公開鍵証明書を送信した場合でも、証明書が破損していたり、証明書の有効期限が切れていたりした場合には、認証を行うことができない。そして、このような事態は、認証情報の更新処理中に電源が切られて更新が失敗したり、装置の電源が入れられないまま放置されて証明書の有効期限内に更新が行えなかったりした場合には十分起こり得る。
【0063】
ここで、各装置が通常公開鍵証明書を用いた認証しか行えないとすると、通常公開鍵証明書が破損したり有効期間が過ぎてしまったりしている状態では、新たな通常公開鍵証明書や通常私有鍵及び通常ルート鍵証明書をネットワークを介して安全に対象の装置に送信する方法はないことになる。しかし、この通信システムを構成する各装置は、このような事態に対処するためにレスキュー認証情報を記憶しており、通信相手を異なる2種類のデジタル証明書を用いて認証することができるようにしている。そして、レスキュー認証情報を用いることにより、管理装置30から管理対象機器40にネットワークを介して新たな通常公開鍵証明書等を安全に送信できるようにしている。
【0064】
このレスキュー認証情報は、正規認証情報と概ね同様な構成となっており、例えば管理対象機器用レスキュー公開鍵証明書は、図示しないレスキューCAが作成したレスキュー公開鍵に、管理対象機器認証用レスキュールート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。また、管理対象機器用レスキュー私有鍵はそのレスキュー公開鍵と対応する私有鍵、管理対象機器認証用レスキュールート鍵証明書は、管理対象機器認証用レスキュールート鍵に自身を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。
【0065】
そして、このようなレスキュー認証情報としては、例えば、レスキュー公開鍵証明書が、装置の識別情報が付されていないデジタル証明書であるものを使用することが考えられる。
この場合、同じ階位の装置(図1に示した例では、管理装置及び管理対象機器の階位が存在するものとする)には、全て同じレスキュー公開鍵証明書を記憶させるようにすることができる。同じ階位の各装置を個別に区別する必要がないので、証明書に含まれるレスキュー公開鍵及びこれと対応するレスキュー私有鍵も含めて、全く共通のものでよいためである。また、通信相手のレスキュー公開鍵証明書が全て同じであることから、ルート鍵証明書については、ある階位の装置の通信相手となる全ての装置について共通となる。すなわち、図24に示すように、管理対象機器を複数設けた場合でも、全ての管理対象機器に同じレスキュー認証情報を記憶させることになる。
これは、管理装置30のレスキュー認証情報についても同様である。
【0066】
また、このようなレスキュー公開鍵証明書も、通常公開鍵証明書と同様なフォーマットで作成することができ、例えば図8に示したものとすることが考えられる。この場合において、例えば、符号Gで示すように発行先装置の機番(CN)として0を記載して共通証明書であることを示すことが考えられる。また、発行元CAの情報として、符号Fで示すようにレスキューCAの識別情報を記載している。
【0067】
このようなレスキュー認証情報は、同じ階位の装置について全て共通であるという特性から、装置の製造時にその機種に応じて定まる階位に応じたものを記憶させてしまうことができる。すなわち、装置の識別情報を付した情報ではないため、検査工程を終了して識別番号を付した各装置に対してそれぞれ個別の証明書を用意して記憶させる必要はなく、多数の装置に対して単純作業によって記憶させることができる。例えば、制御プログラムのマスタにレスキュー認証情報を含めておき、制御プログラムを装置にコピーする際にレスキュー認証情報も共に記憶させる等である。
【0068】
そして、その後レスキュー認証情報を更新しないようにすれば、上記のように正規認証情報の更新が行えなかったり破損してしまったりして通常公開鍵証明書による認証が行えなくなった場合でも、レスキュー認証情報に含まれるレスキュー公開鍵証明書を用いた認証が可能な状態を保つことができる。
また、レスキュー公開鍵証明書やレスキュールート鍵証明書を更新しないようにすることを考えると、その有効期間を長くし、実質的に発行先装置の使用中に有効期限が来ないように設定することが好ましい。例えば、図8に示した例では、有効期間を50年に設定している。
【0069】
ここで、装置の識別情報を付さないレスキュー公開鍵証明書を用いる場合には、その証明書を用いた認証を行った場合でも、通信相手の装置を具体的に特定することはできない。しかし、通信相手についてある程度の情報は得ることができる。
すなわち、例えばあるベンダーが自社製品のうち管理対象機器40に該当する装置全てに管理対象機器用のレスキュー認証情報(管理対象機器用レスキュー公開鍵証明書,管理対象機器用レスキュー私有鍵及び管理装置認証用レスキュールート鍵証明書)を記憶させ、その通信相手となる管理装置30に該当する装置全てに管理装置用のレスキュー認証情報(管理装置用レスキュー公開鍵証明書,管理装置用レスキュー私有鍵及び管理対象機器認証用レスキュールート鍵証明書)を記憶させておけば、管理対象機器40は、自己の記憶している管理装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してくる相手が同じベンダーの管理装置30であることを認識できるし、逆に管理装置30も自己の記憶している管理対象機器認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してくる相手は同じベンダーの管理対象機器40であることを認識できる。
【0070】
そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができるので、その後機番情報等を交換して通信相手を特定することも可能である。
従って、通常公開鍵証明書に記載された識別情報を使用しなくても、通信相手を特定することは一応可能である。
【0071】
なお、図5に示した認証情報において、通常ルート鍵証明書は認証対象によらず同じものを用いるようにしてもよい(管理装置認証用通常ルート鍵証明書と管理対象機器認証用通常ルート鍵証明書が同じものでもよい)。これは、通常証明書には装置の識別情報が付されているため、ルート鍵証明書を用いてその正当性を確認できれば、あとはその識別情報を参照して装置の機種や階位を特定できるためである。
しかし、公開鍵証明書に装置に識別情報を付さないレスキュー認証情報を採用する場合には、公開鍵証明書に装置の識別情報が付されていないため、装置の種類の区別を、特定のルート鍵証明書で正当性を確認できるか否かによって行うことになる。従って、この場合のレスキュールート鍵証明書は認証対象の階位毎に異なる必要がある。
【0072】
ところで、SSLプロトコルに従った認証処理を行う場合には、サーバは、クライアントから通信要求があった時点ではクライアントの状態を知ることができないため、必然的に、特定のURL(Uniform Resource Locator)にアクセスされた場合には常に同じ公開鍵証明書を返すことになる。従って、基本的には、1つのサーバが公開鍵証明書を複数持ち、通信相手が認証に使用しようとする公開鍵証明書の種類に合わせて適当なものを選択して送信するといった構成を取ることはできない。しかし、図1に示した各装置においては、特殊な構成を取ることにより、通常公開鍵証明書とレスキュー公開鍵証明書とを場合によって使い分けることができるようにしている。
【0073】
そこで、次に、この使い分けのための構成を、図9を用いて説明する。
上述した通り、サーバは基本的には通信を要求してくるクライアントに対して特定の公開鍵証明書しか返すことができない。しかし、通信要求に係るURLが異なる場合には、URL毎に異なる公開鍵証明書を返すことも可能である。
従ってここでは、図9に示すように、管理装置30及び管理対象機器40にそれぞれ、通常公開鍵証明書による認証を行う通常URLと、レスキュー公開鍵証明書による認証を行うレスキューURLとを設け、通信を要求する側(クライアントとして機能する側)が、要求する認証の種類に応じていずれかのURLを選択的に指定して通信要求を送るようにしている。
【0074】
管理装置30と管理対象機器40との間の通信プロトコルにSSLを採用する場合、通信に使用するポートは443が一般的なので、通常URLとレスキューURLとではIPアドレスを変更する必要がある。従って、管理装置30及び管理対象機器40は、それぞれ別々のIPアドレスを設定可能な複数の部分(別々の筐体でも同一の筐体でもよい)からなる装置として構成することになる。
【0075】
このようにした場合、通信を要求される側(サーバとして機能する側)は、通信要求を、受け付けたURLによって区別し、通常URLで受け付けた場合には通常公開鍵証明書を返し、レスキューURLで受け付けた場合にはレスキュー公開鍵証明書を返すようにすることができる。
なお、通信を要求するクライアントの側では、どのURLに対して通信要求を送ったかがわかるので、相互認証を行う場合にはそのURLに応じた適切な公開鍵証明書を選択して送信することができる。
【0076】
そして、管理対象機器40が管理装置30と通信しようとする場合には、まず通常公開鍵証明書を用いた認証を試みるが、この認証が通常公開鍵証明書の破損や有効期間経過等のため失敗した場合、レスキュー公開鍵証明書を用いた認証を試みるようにしている。また、管理装置30が通信相手として適当な装置であれば、通常はレスキュー証明書を用いた認証が成功するので、管理装置30には、その認証が成功した場合に、管理対象機器40の正規認証情報を更新する機能を設けている。
【0077】
すなわち、管理対象機器40は管理装置30に対して通信を要求する場合、まず通常URLに通信要求を送信して通常公開鍵証明書を用いた認証を行うが、これが失敗した場合に、今度はレスキューURLに通信要求を送信してレスキュー公開鍵証明書を用いた認証を行う。
そして、管理装置30は、管理対象機器40をレスキュー公開鍵証明書を用いて認証し、通信相手として適切と判断した場合には、更新用の正規認証情報を発行し、管理対象機器40に送信してこれを記憶するよう要求するようにしている。
【0078】
レスキュー公開鍵証明書を用いた認証であっても、共通鍵の共有は通常公開鍵証明書の場合と同様に可能であるから、証明書等の送信は共有した共通鍵を用いて暗号化して安全に行うことができる。なお、ここで送信する証明書等は図10に示すものであり、管理対象機器40に記憶させる正規認証情報を構成するものである。そしてもちろん、更新用の管理対象機器用通常公開鍵証明書は、有効期間内のものである。なお、図10に示した証明書等をセットにし、証明書セットとして送信するようにしてもよい。
【0079】
また管理対象機器40は、上記の要求を受けた場合に、受信した証明書等を証明書設定部49によって証明書記憶部46に記憶させ、それまでの正規認証情報を更新するようにしている。
この更新が正常に行われれば、管理対象機器40には再び有効期間内かつ破損等していない通常公開鍵証明書が記憶されることになり、通常公開鍵証明書を用いた認証を行うことができる状態になる。従ってこの後は、通常公開鍵証明書を用いた認証を行って通信を実行するようにすればよい。
【0080】
しかし、このような正規認証情報の更新を行う場合において、レスキュー公開鍵証明書として、上述のように発行対象装置の機番が記載されていないものを用いる場合には、通信を要求してきた管理対象機器40の機番について、管理装置30は、通信経路の確立後に管理対象機器40が送信してくるものを信用することになる。そして、この機番は、例えば管理対象機器40が不揮発メモリに記憶しているものであるが、この情報自体には、通常はデジタル署名のような改竄防止の措置は講じられていないので、比較的容易に改竄し、他の装置になりすますことが可能な状態である。
そこで、この通信システムにおいては、管理装置30側に、レスキュー認証情報を用いて管理対象機器40を認証した場合に、管理対象機器40が送信してくる機番の信憑性を確認するための審査を行うようにしている。そして、この審査は、管理対象機器40に、認証を受けた時点で記憶している正規認証情報を送信させ、それが管理対象機器40が送信してきた機番と対応するものであるか否かを調べることによって行うようにしている。
【0081】
次に、このような正規認証情報とレスキュー認証情報の2種類の認証情報を用いた証明書の更新に関する処理について説明する。
まず、図11のシーケンス図に、更新処理全体の流れを示す。なおここでは、管理対象機器40に記憶している管理対象機器用通常公開鍵証明書が、破損又は有効期間の経過等により、認証を受けられない状態になっていた場合の処理例を示す。
【0082】
この例においては、まず管理対象機器40が、管理装置30と通信する際に、通信要求を送信すべきURLを確認し(S11)、HTTPSクライアント機能部41を対管理装置クライアントとして機能させて、確認した通常URLに通信要求を送信する(S12)。この場合、管理装置30側ではHTTPSサーバ機能部32が通信要求を受け、認証処理部33にこの要求を伝える。また、管理装置30は通常公開鍵証明書を用いた認証を要求されたことになる。そして認証処理部33は、SSLプロトコルに従い、証明書記憶部34に記憶している管理装置用通常私有鍵で暗号化した第1の乱数と共に、同じく証明書記憶部34に記憶している管理装置用通常公開鍵証明書を管理対象機器40に返す(S13)。
【0083】
管理対象機器40側では、これを認証処理部43に渡して認証処理を行うが、ここでは受信した管理装置用通常公開鍵証明書の正当性は証明書記憶部46に記憶している管理装置認証用通常ルート鍵証明書を用いて確認できるため、認証成功と判断し(S14)、証明書記憶部46に記憶している管理対象機器用通常私有鍵で暗号化した第2の乱数と共に、同じく証明書記憶部46に記憶している管理対象機器用通常公開鍵証明書を管理装置30に返す。またここでは、図示は省略したが、ステップS13で受信した管理装置用通常公開鍵を用いて暗号化した共通鍵の種も第2の乱数と共に返す(S15)。
管理装置30側では、これらを認証処理部33に渡して認証処理を行うが、ここでは受信した管理対象機器用通常公開鍵証明書が認証を受けられない状態であるため、認証失敗と判断する(S16)。従って、管理対象機器40との間の通信を切断する。
【0084】
すると、管理対象機器40は、通常公開鍵証明書を用いて認証を受けることができなかったため、今度はレスキューURLに通信要求を送信する(S17,S18)。そして、今度はレスキュー認証情報を用いて管理装置30との間で相互認証を試みる(S19〜S21)。なお、この処理の内容は、用いる認証情報の種類が異なるのみで、ステップS13〜S15の場合と同じ処理であるから、説明を省略する。
【0085】
そして、今度は認証が成功するので(S22)、管理装置30はその旨の応答を管理対象機器40に返す(S23)。すると、管理対象機器40はそれに応じて機番等及び証明書記憶部46に記憶している正規認証情報を管理装置30に送信する(S24)。そして、管理装置30の証明書審査部35がこれらの情報をもとに管理対象機器40を審査し、更新用の証明書を発行してよいと判断すると(S25)、証明書発行部36が更新用の証明書を発行すると共に、証明書記憶部34の証明書データベースに発行した公開鍵証明書や発行先装置の識別情報等を登録する(S26)。
そしてその後、証明書設定コマンドと共に発行した更新用証明書を管理対象機器40に転送する(S27)。
【0086】
すると、管理対象機器40は、証明書設定コマンドに付された更新用証明書を、管理装置30との通信の際に使用する正規認証情報として設定し(S28)、設定結果について管理装置30に応答を返す(S29)。以上で、レスキュー認証情報を用いた管理対象機器40の通常証明書更新の処理が終了する。
なお、以上の処理において、更新用証明書と共に私有鍵やルート鍵証明書の発行や設定を行う必要があれば、これらも共に発行や設定を行うようにするし、発行や設定を、公開鍵証明書と私有鍵とルート鍵証明書とをセットにした証明書セットの形で行うようにしてもよい。
【0087】
図1に示した通信システムにおいては、管理対象機器40において正規認証情報を構成する公開鍵証明書が認証を受けられない状態になってしまった場合でも、以上の処理により、管理対象機器40の証明書を更新して認証が正常に行える状態に回復させるようにしている。また、正規認証情報を構成する私有鍵やルート鍵証明書が破損等した場合でも、ステップS11乃至S16での認証処理が失敗する段階が異なるのみであり、ステップS17以降については上述の処理と同様である。
【0088】
ここで、図12及び図13に、管理装置30の証明書記憶部34に設ける証明書データベースの構成例を示す。
これらの図に示すように、ここでは証明書データベース中に2つのテーブルを設けている。そして、図12に示す第1のテーブルには、公開鍵証明書の発行先装置(管理対象機器)の識別情報である機番と、その装置に発行した最新の公開鍵証明書のシリアル番号(以下単に「シリアル」ともいう)、及びその公開鍵証明書の発行日時の情報を対応させて登録している。
【0089】
また、図13に示す第2のテーブルには、公開鍵証明書のシリアルと、その公開鍵証明書の内容とを対応させて登録している。ここでは、公開鍵証明書の内容として、図7に示したような書誌事項を含む公開鍵証明書をそのまま登録するようにしているが、これに加えてまたはこれに代えて、有効期限や発行先装置の国や地域等、書誌情報中の所定の項目を抽出して登録するようにしてもよい。
そして、第2のテーブルには、公開鍵証明書を発行した時点でその証明書の登録を行い、第1のテーブルの内容は、管理対象機器40から設定成功の応答があった後で更新するようにするとよい。
以上のようなテーブルを用意することにより、管理装置30は、管理対象機器40の機番をキーに、その装置が記憶しているはずの公開鍵証明書(設定が失敗していなければ、その装置に発行した最新の公開鍵証明書である)を証明書データベースから取得することができる。
【0090】
なお、図12及び図13に示すようにテーブルを2つ用意したのは、管理対象機器40に新たな公開鍵証明書を発行した場合でも、過去に発行したものも含め、全ての公開鍵証明書を記憶しておくようにするためである。また、私有鍵については、発行先の装置以外が保持しておくことは好ましくないため、ここではテーブルに登録しないようにしている。ルート鍵証明書については、多数の管理対象機器40について同じものを記憶させていることから、図示しない別のテーブルで管理し、公開鍵証明書中の、証明書のバージョン情報をキーに取得できるようにし、データ量の低減を図っている。
【0091】
次に、図11に示したような更新処理を行う場合に管理対象機器40が実行する処理について、より詳細に説明する。図14に、その処理のフローチャートを示す。この処理は、管理対象機器40のCPUが所要の制御プログラムを実行して行うものである。
管理対象機器40は、管理装置30に対してコマンドや通知を送信したり、管理装置30からのコマンドや通知を受け取るためにポーリングを行ったりする場合、図14のフローチャートに示す処理を開始し、まずステップS41で管理装置30の通常URLに対して通信要求を送信する。なお、管理対象機器40は、通信相手となる管理装置30について、通信要求先として通常URLとレスキューURLとを記憶しているものとする。
【0092】
そして、まずステップS42で、管理装置30との間で通常公開鍵証明書及び乱数や共通鍵の種を送受信し、図25に示したようなSSLによる相互認証処理を行う。そして、ステップS43でこの認証が成功したか否か判断し、成功していれば、管理装置30との間で通信を確立してステップS44以下に進んで通常の通信に係る処理を行う。なお、ステップS42での認証は、相互認証が好ましいが、少なくとも管理装置30が管理対象機器40を認証できれば、相互認証でも片方向認証でも構わない。
【0093】
以下の処理においては、まずステップS44で、ステップS42の認証処理で送信した共通鍵の種から共通鍵を生成する。そして、ステップS45でコマンド及び受信したコマンドに対する応答をその共通鍵で暗号化して通信中の装置(ここでは管理装置30)に送信し、ステップS46でコマンド及び送信したコマンドに対する応答を同じ共通鍵で暗号化された状態で通信中の装置から受信する。そして、ステップS47でコマンド及び応答を全て送受信したか否か判断する。そして、まだ残っていればステップS45に戻って処理を繰り返し、全て送受信していればステップS48に進んで通信を切断し、処理を終了する。
【0094】
なお、ステップS45及びS46の処理は、順不同で構わないし、送受信すべきコマンドや応答がなければ省略する。また、受信したコマンドに係る処理を実行して応答を生成する処理や、受信した応答の内容を解釈してそれに対応した動作を行う処理は、受信したコマンドや応答を記憶しておき、図14に示したフローチャートとは別に実行するものとする。
一方、ステップS43で認証が失敗した場合には、ステップS49以下に進み、レスキュー認証情報を利用して更新用証明書の取得を試みる処理を行う。なお、認証失敗の原因が、通信異常等、証明書の異常に起因しないものである場合には、この処理を行わないようにしてもよい。
【0095】
ステップS49以下の処理においては、まずステップS49で、管理装置30のレスキューURLに対して通信要求を送信する。そして、ステップS50で、管理装置30との間でレスキュー公開鍵証明書及び乱数や共通鍵の種を送受信し、図25に示したようなSSLによる相互認証処理を行う。
そして、ステップS51でこの認証が成功したか否か判断する。ここで認証が失敗した場合にはそのままステップS48で通信を切断して処理を終了するが、認証が成功していれば、管理装置30との間で通信を確立してステップS52以下に進み、更新用証明書の取得と設定に関する処理を行う。
【0096】
すなわち、まずステップS52で、ステップS50の認証処理で送信した共通鍵の種から共通鍵を生成する。そして、ステップS53で、その共通鍵で暗号化した機番等の情報を管理装置30に送信すると共に、ステップS54で、証明書記憶部46に記憶している正規認証情報を同じ共通鍵で暗号化して管理装置30に送信する。これらのステップS53及びS54の送信は、必要な情報を1つのメッセージに記載して行ってもよい。
ステップS53及びS54で送信した情報は、管理装置30において、管理対象機器40に更新用の証明書を発行してよいか否かを確認するための審査を行うために使用され、また更新用の証明書に記載する管理対象機器40の識別情報としても使用される。
【0097】
また、ステップS53で送信する機番以外の情報としては、例えばそれまでの正規認証情報が使用できなくなった原因の通知が考えられる。そして、通知する原因としては例えば、証明書記憶部46を構成するメモリユニットを交換した、装置がネットワークに接続されていなかったため証明書の自動更新ができなかった、証明書の更新中に電源を切られたためデータが破壊された、等が考えられる。
また、ステップS54で送信する正規認証情報は、ステップS42の処理において認証処理に使用しようとしたものであり、破損していたり、公開鍵証明書の有効期限が切れていたりして、正常に認証を受けることができない状態となっているものである。しかし、ここで送信するのは、管理装置30における審査に供するためであり、審査の基準はSSLによる認証処理の場合とは異なるので、このような状態であっても構わずに送信する。また、私有鍵は本来は他の装置に送信しないものであるが、ここでは既に対応する公開鍵証明書が認証に使用できない状態になっているものであるから、送信により私有鍵が他の装置に知られてしまったとしても、特に問題ない。
【0098】
さらに、正規認証情報には図5に示した通り公開鍵証明書と私有鍵とルート鍵証明書とが含まれるが、これら全てを送信することは必須ではない。さらにまた、正規認証情報の全部又は一部に欠落がある場合には、欠落している旨の情報を送信するようにしてもよいし、単に欠落している情報を送信しないようにするだけにしてもよい。
ステップS54の後は、ステップS55で、管理装置30からの証明書設定コマンドの受信を待つ。上述したように、レスキュー公開鍵証明書を用いた認証を行った場合には、これ以外の要求に係る動作は行わないようにしている。
【0099】
そして、証明書設定コマンドを受信すると、ステップS56に進み、証明書設定コマンドと共に受信した証明書を記憶し、これを管理装置30との通信に使用する正規認証情報として設定する。
これが完了すると、ステップS57で応答を返し、ステップS58で通信を切断して自身を再起動する。この再起動は、管理対象機器40において重要な設定を変更する際に必要なものであり、ここでは証明書の設定がこれに該当する。再起動を行う際に、ユーザに再起動の許可を求めるようにしてもよい。また、図14にはステップS58の後処理を終了するように図示しているが、実際にはステップS58での再起動時に処理は中断される。また、再起動は行わずに、そのまま処理を終了するようにしてもよい。
【0100】
ところで、ここでは管理対象機器40の通常公開鍵証明書が破損又は期限切れ等になった場合の証明書の更新について説明したが、それ以外の場合でも、証明書の更新時に管理装置30が管理対象機器40を審査することが好ましい場合がある。
図15に、この場合の正規認証情報の更新処理全体の流れを示す。
この例においては、管理対象機器40は、管理装置30との間の認証処理に使用する公開鍵証明書の有効期限の一定期間前(例えば1ヶ月前)になったことを検出すると(S61)、正規認証情報の更新時期になったと判断し、管理装置30に対して更新用の公開鍵証明書等の送信を要求する証明書要求コマンドを、図14のステップS45による通常のコマンド送信時に管理装置30へ送信するコマンドとして登録しておく。
【0101】
その後、適当なタイミングで管理対象機器40が管理装置30の通常URLに通信を要求し、その際、正規認証情報を用いて相互認証を行うが、ここでは認証情報に特に問題はないとすると、詳細な説明は図11等の説明と重複するので省略するが、認証処理は成功する(S71〜S77)。なお、ここで使用する管理対象機器40の公開鍵証明書は、共通公開鍵証明書である。
そして、認証が成功すると、管理対象機器40は、管理装置30に対し、ステップS62で登録してある証明書要求コマンドを送信する(S78)。またこのとき、機番等及び証明書記憶部46に記憶している正規認証情報も管理装置30に送信する。これらは、例えば証明書要求コマンドの引数として送信することができる。
【0102】
そして、管理装置30の証明書審査部35がこれらの情報をもとに管理対象機器40を審査し、更新用の証明書を発行してよいと判断すると(S79)、証明書発行部36が更新用の証明書を発行すると共に、証明書記憶部34の証明書データベースに発行した公開鍵証明書や発行先装置の識別情報等を登録する(S80)。
そしてその後、証明書設定コマンドと共に発行した更新用証明書を管理対象機器40に転送する(S81)。
【0103】
すると、管理対象機器40は、証明書設定コマンドに付された更新用証明書を、管理装置30との通信の際に使用する正規認証情報として設定し(S82)、設定結果について管理装置30に応答を返す(S83)。
以上で、管理対象機器40の通常証明書更新の処理が終了する。なお、ステップS80で発行する証明書は、ステップS78で受信した機番を発行先装置の識別情報として記載した個別公開鍵証明書とするとよい。また、管理対象機器40は、ステップS81での証明書更新コマンドを、図14のステップS46に示した通常のコマンド受信処理で受信し、受信したコマンドに係る処理を実行するようにすることができる。
【0104】
次に、図16及び図17に、図11乃至図15を用いて説明してきた正規認証情報の更新処理における、管理装置30側の処理のフローチャートを示す。この処理は、管理装置30のCPU11がレスキューURLに通信要求を受けた場合に開始するものであり、所要の制御プログラムを実行して行うものである。また、ステップS95以降の処理については、通常URLに通信要求を受け、一般的なコマンド送受信において証明書要求コマンドを受信した場合に実行する、このコマンドに係る処理と共通なものである。なお、管理装置30のCPUが通常URLに通信要求を受けた場合に行う一般的なコマンド送受信に関する処理については、図16及び図17に示す処理とは独立した一般的な処理であるので、ここでは説明を省略する。
【0105】
図16に示す処理においては、管理装置30のCPU11は、まずステップS91で、通信要求の要求元の装置(ここでは管理対象機器40)との間でレスキュー公開鍵証明書及び乱数と共通鍵の種を送受信し、図25に示したようなSSLによる相互認証処理を行う。
そして、ステップS92でこの認証が成功したか否か判断する。ここで認証が失敗した場合にはそのまま図17のステップS108に進んでで通信を切断して処理を終了するが、認証が成功していれば、通信要求の送信元との間で通信を確立してステップS93以下に進み、通信要求の送信元の審査及び更新用証明書の設定に関する処理を行う。また、認証が成功した時点で、通信要求の送信元がいずれかの管理対象機器であることがわかる。ここでは通信要求の送信元が管理対象機器40であるとして以後の説明を行う。
【0106】
この処理においては、まずステップS93で、ステップS91の認証処理で受信した共通鍵の種から共通鍵を生成する。そして、ステップS94で、その共通鍵で暗号化された機番等及び正規認証情報を管理対象機器40から受信する。ただし、管理対象機器40が正規認証情報の全てを送信して来たわけではない場合には、送信してきたもののみを受信することになり、ここで正規認証情報を全く受信できない場合もありうる。
このステップS94の処理が受信手順の処理であり、この処理においては管理装置30のCPU11が受信手段として機能する。
【0107】
ステップS94の後は、ステップS95に進み、ステップS94で受信した機番について、その機番が通信相手として適切な装置のものであるか否か判断する。この処理を、証明書要求コマンド(送信元は管理対象機器40とする)に係る処理として実行する場合には、証明書要求コマンドと共に受信した機番についてこの判断を行う。
そして、適切な装置のものでなければ、以後の審査を行うまでもなく、管理対象機器40に更新用証明書を発行すべきでないことがわかる。そこで、そのまま図17のステップS109に進み、審査不合格の旨及びその理由を記載したメッセージを管理対象機器40に送信すると共に、ステップS110で管理装置30のオペレータにも審査不合格の旨及びその理由を通知し、通信を切断して処理を終了する。このようになるケースとしては例えば、管理対象機器40が管理装置30による管理の対象になり得る装置であるが、管理契約が結ばれていない等の理由により管理装置30に管理対象として登録されていない場合等が考えられる。
【0108】
一方、ステップS95で適切な装置のものであれば、ステップS96に進み、ステップS94で(又は証明書要求コマンドと共に、以下同じ)受信した機番をキーに証明書記憶部34の証明書データベース(図12及び図13参照)を検索し、その機番の装置が記憶しているはずの最近の通常公開鍵証明書及び通常ルート鍵証明書の情報を取得する。この取得はもちろん管理対象機器40とは異なる場所から行うものである。また、ここで取得するのは、公開鍵証明書やルート鍵証明書の全体であっても一部分であっても、これらから証明書のシリアル番号、発行先装置の識別情報、有効期限、発行日等の必要な情報を抽出したものであってもよい。ステップS97乃至S99での審査に必要な情報を取得すれば足りる。また、ここで取得する公開鍵証明書が上述した共通公開鍵証明書である場合もある。
このステップS96の処理が取得手順の処理であり、この処理においては管理装置30のCPU11が取得手段として機能する。
【0109】
次のステップS97は、ステップS94で受信した公開鍵証明書を用いた審査の処理であり、ステップS94で管理対象機器40から受信した公開鍵証明書と、ステップS96で取得した情報とを用いて管理対象機器40を審査してその結果を結果テーブルに登録する。この公開鍵証明書を用いた審査をどのように行うかについては種々の方式が考えられるが、少なくとも、ステップS94で公開鍵証明書を受信した場合には、その公開鍵証明書が、同ステップで受信した機番の装置が記憶している公開鍵証明書として適切なものであるか否かを判断できるように行うものとする。例えば、管理対象機器40から受信した公開鍵証明書と証明書データベースから取得した公開鍵証明書との全体を比較したり、それらの一部を比較したり、両証明書からパラメータを抽出して比較したりして、両証明書の内容が一致した場合に適切なものであるとすることができる。
【0110】
図18のフローチャートに、ステップS97での公開鍵証明書を用いた審査の処理の一例を示す。
この処理においては、まずステップS111で、図16のステップS94で管理対象機器40から正規認証情報として公開鍵証明書を受信したか否か判断する。そして、受信していれば、ステップS112に進み、受信した公開鍵証明書と、図16のステップS96で証明書データベースから取得した公開鍵証明書とが一致するか否か判断する。
【0111】
そして、一致していれば、ステップS94で受信した公開鍵証明書は管理対象機器40が記憶しているはずのものであり、これは通信相手が管理対象機器40であることを支持する根拠となるので、ステップS113で結果テーブルに公開鍵証明書の審査結果として「OK」を登録して元の処理に戻る。一致していなければ、逆に通信相手が管理対象機器40でないことを支持する根拠となるので、ステップS114で審査結果として「NG」を登録して元の処理に戻る。
また、ステップS111で公開鍵証明書を受信していなければ、ステップS115で公開鍵証明書の審査結果として「なし」を登録して元の処理に戻る。
図16のステップS97での審査処理は、例えば以上のような処理により行うことができる。
【0112】
公開鍵証明書は、一般には秘密に保つデータではなく、適宜通信相手に送信してしまうデータであるため、公開鍵証明書を記憶していることは、その公開鍵証明書の発行先の装置であることの根拠にはなり難い。
しかし、特定の通信相手とのみ通信し、従って公開鍵証明書も特定の装置にしか渡さないような通信システムにおいては、全く無関係な装置が管理対象機器40の公開鍵証明書を記憶している可能性は低い。また、管理対象機器40の通信相手となる装置が、管理対象機器40と同じベンダーの製品である場合には、通信相手の側では公開鍵証明書を保存しないようにしたり、他の装置に転送しないようにしたりという対応が可能になる。
【0113】
例えば、管理対象機器40がファイアウォールの内側にあることを前提としてシステムを構築し、管理対象機器40と管理装置30との間の通信は、必ず管理対象装置40が発呼側になるように行い、かつ管理対象装置40が管理装置30以外に対しては通信を要求しないようにすれば、管理対象機器40の公開鍵証明書が、管理装置30以外の装置に対して送信されないようにすることができる。さらに、管理対象機器40において、公開鍵証明書を、基板に固定されたフラッシュロムやイープロム等のメモリにスクランブルされた状態で保存するようにすれば、オフラインでの証明書の持ち出しも防止され、管理対象機器40の公開鍵証明書が、自身と管理装置30以外の装置に記憶される事態を一層効果的に防止することができる。
【0114】
従って、このような場合には、管理装置30側で特定の機番の装置が記憶していると把握している公開鍵証明書を送信してくる装置は、本当にその機番の装置である可能性が高いといえる。特に、管理対象機器40の通信相手が管理装置30のみである場合には、管理対象機器40に対して発行した公開鍵証明書は、管理対象機器40と管理装置30のみが記憶しているはずであるから、管理装置30側で把握しているものと同じ公開鍵証明書を送信してくることをもって、対応する機番の装置であると判断するようにすることも考えられる。
【0115】
また、図19のフローチャートに、ステップS97での公開鍵証明書を用いた審査の処理の別の例を示す。この処理は、証明書要求コマンドに応じた処理の際に適用すると好適な例である。
この処理においてはまず、ステップS121及びステップS122で、図18のステップS111及びS112の場合と同様な審査を行う。
【0116】
その後、管理対象機器40から受信した機番や、受信した公開鍵証明書の有効期限の情報を用い、これらの情報をキーにして管理対象とする装置についての情報を記録している図示しないテーブルを参照し、管理対象機器40が管理対象の装置であるか否か、および管理対象機器40について管理契約期間が使用中の公開鍵証明書の有効期限後まであるか否かを判断する(S123,S124)。
【0117】
そして、管理対象の装置以外に対しては、今後も通信が可能な状態にしておく必要はないし、管理契約期間が使用中の公開鍵証明書の有効期限内で終了するのであれば、その後通信が可能な状態にしておく必要はないので、ステップS123又はS124の判断がNOである場合は、ステップS127で審査NG(不合格)として以下の処理に進む。
なお、ステップS124については、公開鍵証明書の有効期限を管理契約の期限をもとに定めてある場合には、管理延長契約がなされているか否かを基準に判断するようにしてもよい。
【0118】
また、ステップS123とS124でYESであれば、ステップS125に進み、現在の公開鍵証明書が期限切れ間近(例えば有効期限まで1ヶ月以内)か否か判断する。証明書要求コマンドは、公開鍵証明書の期限切れ間近に送信されてくるはずであるから、この判断がNOの場合には、何らかの異常が発生していると考えられ、やはりステップS127で審査NGとしてもとの処理に戻る。
また、以上のステップS121乃至S125の判断が全てYESであれば、ステップS126で審査OK(合格)として元の処理に戻る。
【0119】
以上の処理により、機番の送信元の装置を審査し、公開鍵証明書を発行してよいか否かを判断することができる。なお、審査処理において判断すべき項目については、図18や図19に示したものは一例に過ぎず、管理対象機器40の用途や管理装置30による管理の運用形態等に応じて適宜定めればよいことは、もちろんである。
【0120】
図16の説明に戻る。
次のステップS98は、ステップS94で受信した私有鍵を用いた審査の処理であり、ステップS94で管理対象機器40から受信した私有鍵と、ステップS96で取得した情報とを用いて管理対象機器40を審査してその結果を結果テーブルに登録する。この私有鍵を用いた審査をどのように行うかについても、種々の方式が考えられるが、少なくとも、ステップS94で私有鍵を受信した場合には、その私有鍵が、同ステップで受信した機番の装置が記憶している公開鍵と対応するものであるか否かを判断できるように行うものとする。例えば、管理対象機器40から受信した私有鍵と証明書データベースから取得した公開鍵証明書中の公開鍵との一方を用いて適当なデータを暗号化し、他方を用いてその暗号化したデータを復号化し、復号化により元のデータが得られた場合に適切なものであるとすることができる。
【0121】
図20のフローチャートに、ステップS98での私有鍵を用いた審査の処理の一例を示す。
この処理においては、まずステップS141で、図16のステップS94で管理対象機器40から正規認証情報として私有鍵を受信したか否か判断する。そして、受信していれば、ステップS142に進み、受信した私有鍵を用いて適当なデータを暗号化し、ステップS143で、その暗号化したデータを、図16のステップS96で証明書データベースから取得した公開鍵証明書中の公開鍵を用いて復号化する。なお、このとき復号化に管理対象機器40から受信した公開鍵証明書中の公開鍵を用いたのでは、単に管理対象機器40に互いに対応する公開鍵と私有鍵が記憶されていることを確認することにしかならないので注意が必要であるが、このようにすることも考えられる。
【0122】
そして、ステップS144でこの復号化が成功したか否か、すなわち復号化の結果暗号化前のデータが得られたか否か判断する。
ここで得られれば、ステップS94で受信した私有鍵は管理対象機器40が記憶していると管理装置30側で把握している公開鍵と対応するものであり、これは通信相手が管理対象機器40であることを支持する根拠となる。そこで、ステップS145で結果テーブルに私有鍵の審査結果として「OK」を登録して元の処理に戻る。元のデータが得られなければ、逆に通信相手が管理対象機器40でないことを支持する根拠となるので、ステップS146で審査結果として「NG」を登録して元の処理に戻る。
また、ステップS141で私有鍵を受信していなければ、ステップS147で私有鍵の審査結果として「なし」を登録して元の処理に戻る。
図16のステップS98での審査処理は、例えば以上のような処理により行うことができる。
【0123】
私有鍵は、通常は発行対象の装置しか記憶していないデータである。従って、ある機番の装置が記憶していると把握している私有鍵を送信してくる装置は、本当にその機番の装置である可能性が高いと言える。しかし、比較のために各装置に発行した私有鍵を管理装置30側で記憶しておくとすると、管理装置30が管理対象機器40になりすますことが可能になってしまい、システムの設計上好ましくない。そこで、図20に示した例においては、受信した私有鍵が、ある機番の装置が記憶していると把握している公開鍵と対応するものであることを確認することにより、その私有鍵がその機番の装置が記憶しているはずのものであることを間接的に確認するようにしている。
しかし、証明書データベースに私有鍵も記憶しておき、管理対象機器40から受信した私有鍵と証明書データベースから取得した私有鍵とを比較するようにすることも、技術的には可能である。
【0124】
再度図16の説明に戻る。
次のステップS99は、ステップS94で受信したルート鍵証明書を用いた審査の処理であり、ステップS94で管理対象機器40から受信したルート証明書と、ステップS96で取得した情報とを用いて管理対象機器40を審査してその結果を結果テーブルに登録する。このルート鍵証明書を用いた審査をどのように行うかについても種々の方式が考えられるが、考え方は公開鍵証明書の場合と同様であるから、詳細な説明は省略する。処理の具体例としても、図18に示したフローチャートの処理のうち、「公開鍵証明書」の部分を「ルート鍵証明書」と読み替えた処理を採用することが可能である。
【0125】
ルート鍵証明書も、公開鍵証明書の場合と同様、一般には秘密に保つデータではない。また、管理対象機器40と同じ階位に属する装置には共通に記憶させておくものである。従って、ルート鍵証明書を記憶していることは、特定の装置であることの根拠にはなり難い。
しかし、一度設定されたルート鍵証明書は、通常は外部の装置に送信するものではないので、全く無関係な装置が管理対象機器40のルート鍵証明書を記憶している可能性は低い。従って、このような場合には、管理装置30側で特定の階位の装置が記憶していると把握しているルート鍵証明書を送信してくる装置は、少なくとも本当にその階位の装置である可能性が高いと言える。
【0126】
また、複数のバージョンの公開鍵証明書と対応するルート鍵証明書が混在している場合、通信相手が管理装置30側で把握している公開鍵証明書と対応するルート鍵証明書を送信してくれば、このことは、通信相手が本当に送信してきた機番の装置であることを支持する証拠となる。
従って、ルート鍵証明書を用いた審査の結果も、公開鍵証明書や私有鍵を用いた審査よりは信頼性に劣るものの、公開鍵証明書や私有鍵を用いた審査の結果と組み合わせて判断材料とすれば、十分に有用なものである。
【0127】
そして、ステップS99の後は、図17のステップS100に進み、ステップS97乃至S99で結果テーブルに登録した各審査結果の内容により、通信中の管理対象機器に対する最終的な審査を行う。この審査においては、通信相手がステップS94で受信した機番の装置であると信用してよければOKを、そうでなければNGを返すようにする。
この基準としては例えば、審査結果が公開鍵証明書と私有鍵とルート鍵証明書の全てについてOKであれば最終結果もOKとし、それ以外はNGとすることが考えられる。しかし、一部の結果が「なし」であっても最終結果をOKとしたり、OKとNG以外にも、管理装置30のオペレータに警告を発したり判断を委ねたりするような審査結果を返すようにすることも可能である。これらの基準は、ベンダーにおける管理装置30の運用基準及び、管理対象機器40の用途や機能等に応じて適宜定めればよい。
【0128】
また、ステップS94で正規認証情報が使えなくなった原因の情報を受信した場合には、審査においてこのような情報も利用し、例えば原因に応じて審査の基準を変えることも考えられる。
以上のステップS97乃至S100の処理が審査手順の処理であり、この処理において、管理装置30のCPU11が審査手段として機能する。なお、審査については、ステップS97乃至S99の処理を全て行うことは必須ではなく、最低限これらのステップのいずれか1つを行えばよい。
【0129】
次のステップS101では、ステップS100での審査結果がOKであったか否か判断する。そして、OKであれば、ステップS102以下の証明書更新の処理を行う。
そして、まずステップS102で、証明書発行部36の機能により、ステップS94で受信した機番を含む更新用の証明書を作成する。図7等に示した例では、公開鍵証明書には機番以外にも発行対象装置の識別情報を記載しているが、これらの情報を記載する場合には、管理装置30のデータベースを参照したり、管理対象機器40から送信させるようにしたりして取得することができる。
ステップS102の後は、ステップS103に進み、作成した証明書の情報を証明書データベースに登録する。この処理においては、例えば図12及び図13に示したような形式の証明書データベースを用いる場合には、図13に示した第2のテーブルに公開鍵証明書を登録する。
【0130】
そして、次のステップS104では、ステップS102で作成した証明書を管理対象機器40に送信する。このとき、送信した証明書を管理装置30との通信に使用する証明書として設定するように要求する証明書設定コマンドも同時に送信する。
そして、ステップS105で証明書設定コマンドに対する応答を待って、応答があるとステップS106に進んで更新が成功したか否か判断する。そして成功していれば、ステップS107で証明書を更新させた管理対象機器40について、その機番と対応する公開鍵証明書の情報を更新する。具体的には、図12に示した第1のテーブルに登録してある証明書のシリアル番号と発行日の情報を、ステップS104で送信した証明書のものに更新する。そしてその後、ステップS108で通信を切断して終了する。
【0131】
ステップS106で成功していない場合には、そのまま通信を切断して終了する。ステップS105で所定時間応答がない場合も同様とする。このような場合でも、管理対象機器40側から再度アクセスしてくることが考えられるため、そのまま終了してしまっても差し支えないのである。このような場合には、管理対象機器40は依然として更新前と同じ正規認証情報を記憶していると想定されるので、図12に示した第1のテーブルは更新しないようにしている。
一方、ステップS101で審査OKでなかった場合には、ステップS109に進み、通信相手の管理対象機器40に、審査不合格の旨及びその理由を記載したメッセージを送信し、ステップS110で管理装置30のオペレータにも審査不合格の旨及びその理由を通知し、さらにステップS108で通信を切断して終了する。なおこの場合、管理対象機器40に通知を行ったり審査不合格の理由を正確に伝えたりすることが不適切であれば、単にそのまま通信を切断したり、ダミーのメッセージを送信したりするようにしてもよい。
【0132】
図1に示した通信システムにおいては、このような処理を行うことにより、管理対象機器40において管理装置30との間で通常の認証処理に使用していた公開鍵証明書が認証処理に使用できなくなってしまった状態であっても、また安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、管理対象機器40の公開鍵証明書を更新し、再度管理装置30との間で通常の認証処理が可能な状態に復帰させることができる。
また、この場合において、なりすましが比較的容易になされ得るレスキュー認証情報を用いた非常用の通信経路を使用したとしても、管理対象機器40が記憶している正規認証情報を機番と共に管理装置30に送信し、管理装置30側でその情報をもとに管理対象機器40を審査するようにしているので、かなりの確実性でなりすましを排除し、不正に更新用の公開鍵証明書等を取得されることを防止することができる。
また、正規認証情報に含まれる通常公開鍵証明書として共通公開鍵証明書を使用しているような場合にも、同様にその更新の際のなりすましを排除し、同様な効果を得ることができる。
【0133】
また、以上説明してきた方式によれば、自動的に公開鍵証明書を更新することができるので、この方式は、設置先の操作者による証明書の更新が行えないような装置、例えばケーブルテレビのセットトップボックスや遠隔保守の対象となる画像形成装置等に公開鍵証明書を送信する際に審査を行う審査装置や、そのような審査装置を含む通信システムに適用すると、特に効果的である。
【0134】
次に、以上説明してきた管理対象機器40における証明書記憶部46の好ましい構成について説明する。
まず、図21に、証明書記憶部46の構成例を示す。
管理対象機器40においては、図21に示すように、証明書記憶部46を構成するメモリとして、互いに独立して交換可能な第1のメモリユニットと第2のメモリユニットとを設け、その一方(ここでは第1のメモリユニット)に図5(a)に示したように正規認証情報とレスキュー認証情報を記憶させると共に、他方にも正規認証情報の一部又は全部を記憶させるようにするとよい。図21においては、第2のメモリユニットに通常公開鍵証明書を記憶させた例を示しているが、通常私有鍵や通常ルート鍵証明書、あるいはこれらの組み合わせを記憶させるようにしてもよい。また、これらのメモリユニットとしては、それぞれ書き換え可能な不揮発性メモリを用い、例えばSRAM、フラッシュメモリ、SDカードや、ハードディスクドライブを使用することも可能である。
【0135】
図21に示したような構成とした場合でも、通常は第1のメモリユニットに記憶している正規認証情報を用いた認証処理を行えばよい。しかし、管理対象機器40の運用中には、第1のメモリユニットが破損してしまい交換せざるを得なくなる場合や、第1のメモリユニットを設けたマザーボードを故障等により交換せざるを得なくなる場合も考えられる。
このような場合であっても、レスキュー認証情報が管理対象機器40の識別情報を含まないものであれば、少なくとも同一機種の管理対象機器40については共通なものを使用できるから、交換用の部品を製造する際にレスキュー認証情報を予め記憶させておくことが可能である。そして、上述したようにこのレスキュー認証情報を用いて管理装置30に通信を要求し、新たな正規認証情報の発行を求めることができる。
【0136】
しかし、もし第1のメモリユニットにしか正規認証情報を記憶させていないとすると、第1のメモリユニットが取り外された段階で管理対象機器40内に正規認証情報はなくなってしまい、新たな正規認証情報の発行を求める際に、正規認証情報を管理装置30における審査に供することができなくなってしまう。そうすると、管理装置30における審査の基準によっては、特に安全性を高めるために審査結果「なし」では審査に合格させないようにしている場合には、管理対象機器40は審査に合格できず、新たな正規認証情報の発行を受けられないことになってしまう。
一方、第2のメモリユニットにも正規認証情報を記憶させておくようにすれば、図22に示すように、第1のメモリユニットを交換した場合でも、第2のメモリユニットに記憶している正規認証情報はそのまま残る。そして、これを管理装置30に送信して審査に供することができ、正規認証情報が適切なものであれば、管理対象機器40は審査に合格して新たな正規認証情報の発行を受けることができる。
【0137】
また、管理装置30から受信した更新用の証明書を第1のメモリユニットに記憶させると共に、その一部または全部を第2のメモリユニットにも記憶させるようにすれば、図21に示した元の状態に戻すことができる。
このように、上述した実施形態の通信システムにおいては、管理対象機器40において、正規認証情報を構成する公開鍵証明書と私有鍵とを、独立して交換可能な複数のメモリユニットに分散して記憶させるようにすることが有効である。この場合において、公開鍵証明書や私有鍵を、複数のメモリユニットに記憶させる場合があってもよいことはもちろんである。
なお、図23に例を示すように、第2のメモリユニットに記憶させた証明書等は、同じものを第1のメモリユニットに記憶させなくてもよい。この場合、第2のメモリユニットに記憶させた証明書等も認証処理に使用することになるが、一方のメモリユニットを交換した場合でも他方のメモリユニットに記憶している証明書等が残ることは、上記の場合と同様である。このような態様も、当然上記の「分散して」に含まれる。
以上で管理対象機器40の証明書記憶部46についての説明を終了する。
【0138】
なお、このような点の他、以下のような変更も可能である。
まず、上述した実施形態では、管理装置30にCAの機能を設け、更新用の証明書を管理装置30自身が発行する例について説明したが、管理装置30とCAとを別々の装置とすることを妨げるものではない。この場合において、CAと管理装置30との間の通信経路は、専用線とするとよいが、SSLやVPN等により安全な通信経路を確保できれば、インターネットを介したものであってもよい。
このようにする場合、例えば、管理装置30が更新用公開鍵の送信元である被管理機器を審査して合格と判断した後、CAに更新用証明書の発行を要求して更新用証明書を発行させ、CAからその更新用証明書を受信して証明書データベースに登録し、管理対象機器40に転送するようにすることができる。
【0139】
また、CAに証明書データベースを持たせ、管理装置30が審査に使用するための公開鍵証明書やルート鍵証明書の情報を、CAから取得するようにしてもよい。CAから取得するようにしても、管理対象機器40と異なる場所から取得することに変わりはない。この場合において、更新用証明書の発行は、上記のようにCAに要求して行わせることができることはもちろんであるが、管理装置30が自身で行うようにすることも可能である。
【0140】
さらにまた、上述した管理装置30における審査の機能も、CAに持たせるようにしてもよい。このようにする場合には、管理装置30は管理対象機器40から審査に供するために受信した機番や正規認証情報等をCAに転送し、これらをもとにCAに審査処理を行わせ、審査OKならCAが発行した更新用証明書を、審査NGならその旨の情報を取得して管理対象機器40に転送することになる。もちろん、更新用証明書を取得した場合には管理対象機器40にこれを設定させる。
さらに、上述した実施形態においては、管理装置30が管理対象機器40を管理する通信システムの例について説明したが、通信相手を審査する機能を有する装置が、その審査対象の装置を管理することは必須ではない。単に相互に通信してデータの授受を行うような構成であっても、この発明を適用することは可能である。
【0141】
また、上述した実施形態では、管理装置30と管理対象機器40とが、図25あるいは図27を用いて説明したようなSSLに従った認証を行う場合の例について説明した。しかし、この認証が必ずしもこのようなものでなくてもこの発明は効果を発揮する。
SSLを改良したTLS(Transport Layer Security)も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。また、公開鍵暗号の方式についても、RSA(Rivest Shamir Adleman)だけでなく、楕円曲線暗号等の他の方式のものにも適用可能である。
また、以上説明した各変形を、適宜組み合わせて適用できることはもちろんである。
【0142】
また、この発明によるプログラムは、管理装置30を制御するコンピュータに、以上説明したような機能を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
このようなプログラムは、初めからコンピュータに備えるROMあるいはHDD等の記憶手段に格納しておいてもよいが、記録媒体であるCD−ROMあるいはフレキシブルディスク,SRAM,EEPROM,メモリカード等の不揮発性記録媒体(メモリ)に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてCPUに実行させるか、CPUにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
【産業上の利用可能性】
【0143】
以上説明してきた通り、この発明の審査装置、通信システム、審査方法、プログラムあるいは記録媒体によれば、安全性の比較的低い公開鍵証明書を利用して通信装置を識別する必要がある場合においても、なりすましを効果的に防止できるようにすることができる。
従って、この発明を、各ノードが通信に際してデジタル証明書を用いた認証処理を行うような通信システムを運用する際に利用することにより、より安全なシステムを構成することができる。
【図面の簡単な説明】
【0144】
【図1】この発明の実施形態である通信システムの構成例を示すブロック図である。
【図2】図1に示した管理装置のハードウェア構成を示すブロック図である。
【図3】図1に示した管理装置及び管理対象機器について、この発明の特徴に関連する部分の機能構成を示す機能ブロック図である。
【図4】図3に示した管理対象機器の要求管理部におけるコマンド実行可否の判断基準について説明するための図である。
【図5】図1及び図3に示した管理装置及び管理対象機器が認証処理に用いる証明書及び鍵について説明するための図である。
【0145】
【図6】図5に示した公開鍵証明書のフォーマット例について説明するための図である。
【図7】図6に記載したフォーマットに従った管理対象機器用通常公開鍵証明書の例を示す図である。
【図8】同じく管理対象機器用レスキュー公開鍵証明書の例を示す図である。
【図9】図1に示した通信システムにおける正規認証情報とレスキュー認証情報との使い分けについて説明するための図である。
【図10】同じく管理装置が管理対象機器に正規認証情報を設定させる際に送信する証明書等の構成を示す図である。
【0146】
【図11】図1に示した通信システムにおいて、管理対象機器中の認証に使用できなくなった正規認証情報を更新する際に各装置が実行する処理の流れを示すシーケンス図である。
【図12】図1に示した管理装置の証明書記憶部に設ける証明書データベースの構成例の一部を示す図である。
【図13】同じく別の一部を示す図である。
【図14】図11に示した処理を実行する場合の、管理対象機器側の処理を示すフローチャートである。
【図15】図1に示した通信システムにおいて、管理装置が、管理対象機器との通常の通信により正規認証情報を更新する際にも発行先の管理対象機器を審査するようにする場合に、正規認証情報を更新する際に各装置が実行する処理の流れを示すシーケンス図である。
【0147】
【図16】同じく管理装置側の処理を示すフローチャートである。
【図17】その続きの処理を示すフローチャートである。
【図18】図16のステップS97に示した公開鍵証明書を用いた審査の処理の一例を示すフローチャートである。
【図19】その別の例を示す図である。
【図20】同じくステップS98に示した私有鍵を用いた審査の処理の一例を示すフローチャートである。
【0148】
【図21】図3に示した管理対象機器の証明書記憶部の好ましい構成について説明するための図である。
【図22】その別の図である。
【図23】そのさらに別の図である。
【図24】図1に示した通信システムにおいて管理対象機器を複数設けた例を示す図である。
【図25】2つの通信装置がSSLに従った相互認証を行う際に各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
【図26】図25に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。
【図27】2つの通信装置がSSLに従った片方向認証を行う際の各装置において実行する処理を示す、図25と対応する図である。
【符号の説明】
【0149】
30…管理装置、31,41…HTTPSクライアント機能部、
32,42…HTTPSサーバ機能部、33,43…認証処理部、
34,46…証明書記憶部、35…証明書審査部、36…証明書発行部、
37…コマンド発行部、38,48…要求管理部、39,50…コマンド処理部、
40…管理対象機器、44…コール通知部、45…定期通知部、47…証明書通知部
49…証明書設定部
【特許請求の範囲】
【請求項1】
公開鍵暗号を用いた認証処理を行うが該認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、該通信装置の公開鍵証明書と該通信装置の識別情報とを受信する受信手段と、
該手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、前記識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
該手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて前記通信装置を審査する審査手段とを設けたことを特徴とする審査装置。
【請求項2】
請求項1記載の審査装置であって、
前記審査手段が、前記受信手段が受信した公開鍵証明書の内容と前記取得手段が取得した情報とが一致するか否かに基づいて前記公開鍵証明書が適切なものであるか否かを判断する手段を有することを特徴とする審査装置。
【請求項3】
公開鍵暗号を用いた認証処理を行う通信装置から、該通信装置の私有鍵と、該通信装置の識別情報とを受信する受信手段と、
該手段が受信した識別情報と対応する公開鍵を、該識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
該手段が取得した公開鍵と前記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて前記通信装置を審査する審査手段とを設けたことを特徴とする審査装置。
【請求項4】
請求項3記載の審査装置であって、
通信装置の識別情報と該通信装置が前記認証処理に使用する公開鍵との対応関係を記憶する手段を設けたことを特徴とする審査装置。
【請求項5】
請求項3又は4記載の審査装置であって、
前記審査手段が、前記取得手段が取得した公開鍵と前記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて前記審査を行う手段を有することを特徴とする審査装置。
【請求項6】
請求項1乃至5のいずれか一項記載の審査装置であって、
前記通信装置が前記審査手段による審査に合格した場合に、前記通信装置に、該通信装置の新たな公開鍵証明書を送信する送信手段を設けたことを特徴とする審査装置。
【請求項7】
請求項6記載の審査装置であって、
前記送信手段が送信する公開鍵証明書は、前記受信手段が受信した前記通信装置の識別情報を含む公開鍵証明書であることを特徴とする審査装置。
【請求項8】
公開鍵暗号を用いた認証処理を行うが該認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置であって、自身の公開鍵証明書と自身の識別情報とを審査装置に送信する手段を有する通信装置と、
該通信装置から、該通信装置の公開鍵証明書と該通信装置の識別情報とを受信する受信手段と、
該手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、前記識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
該手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて前記通信装置を審査する審査手段とを設けた審査装置とを備えることを特徴とする通信システム。
【請求項9】
請求項8記載の通信システムであって、
前記審査装置の審査手段が、前記受信手段が受信した公開鍵証明書の内容と前記取得手段が取得した情報とが一致するか否かに基づいて前記公開鍵証明書が適切なものであるか否かを判断する手段を有することを特徴とする通信システム。
【請求項10】
公開鍵暗号を用いた認証処理を行う通信装置であって、自身の私有鍵と識別情報とを審査装置に送信する手段を有する通信装置と、
該通信装置から、該通信装置の私有鍵と、該通信装置の識別情報とを受信する受信手段と、
該手段が受信した識別情報と対応する公開鍵を、該識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
該手段が取得した公開鍵と前記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて前記通信装置を審査する審査手段とを設けた審査装置とを備えることを特徴とする通信システム。
【請求項11】
請求項10記載の通信システムであって、
前記審査装置に、通信装置の識別情報と該通信装置が前記認証処理に使用する公開鍵との対応関係を記憶する手段を設けたことを特徴とする通信システム。
【請求項12】
請求項10又は11記載の通信システムであって、
前記審査装置の審査手段が、前記取得手段が取得した公開鍵と前記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて前記審査を行う手段を有することを特徴とする通信システム。
【請求項13】
請求項8乃至12のいずれか一項記載の通信システムであって、
前記審査装置に、前記通信装置が前記審査手段による審査に合格した場合に、前記通信装置に、該通信装置の新たな公開鍵証明書を送信する送信手段を設け、
前記通信装置に、該公開鍵証明書を受信する手段を設けたことを特徴とする通信システム。
【請求項14】
請求項13記載の通信システムであって、
前記審査装置の送信手段が送信する公開鍵証明書は、前記受信手段が受信した前記通信装置の識別情報を含む公開鍵証明書であることを特徴とする通信システム。
【請求項15】
請求項8乃至13のいずれか一項記載の通信システムであって、
前記通信装置において、前記認証処理に使用する公開鍵証明書と私有鍵とを、独立して交換可能な複数のメモリユニットに分散させて記憶させるようにしたことを特徴とする通信システム。
【請求項16】
公開鍵暗号を用いた認証処理を行うが該認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、該通信装置の公開鍵証明書と該通信装置の識別情報とを受信する受信手順と、
該手順で受信した識別情報と対応する公開鍵証明書の内容を示す情報を、前記識別情報をもとに前記通信装置とは異なる場所から取得する取得手順と、
該手順で取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて前記通信装置を審査する審査手順とを有することを特徴とする審査方法。
【請求項17】
請求項16記載の審査方法であって、
前記審査手順に、前記受信手順で受信した公開鍵証明書の内容と前記取得手順で取得した情報とが一致するか否かに基づいて前記公開鍵証明書が適切なものであるか否かを判断する手順を設けたことを特徴とする審査方法。
【請求項18】
公開鍵暗号を用いた認証処理を行う通信装置から、該通信装置の私有鍵と、該通信装置の識別情報とを受信する受信手順と、
該手順で受信した識別情報と対応する公開鍵を、該識別情報をもとに前記通信装置とは異なる場所から取得する取得手順と、
該手順で取得した公開鍵と前記受信手順で受信した私有鍵とが対応するものであるか否かに基づいて前記通信装置を審査する審査手順とを有することを特徴とする審査方法。
【請求項19】
請求項18記載の審査方法であって、
前記各手順を実行する装置に、通信装置の識別情報と該通信装置が前記認証処理に使用する公開鍵との対応関係を記憶させておくようにしたことを特徴とする審査方法。
【請求項20】
請求項18又は19記載の審査方法であって、
前記審査手順に、前記取得手順で取得した公開鍵と前記受信手順で受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて前記審査を行う手順を設けたことを特徴とする審査方法。
【請求項21】
請求項16乃至20のいずれか一項記載の審査方法であって、
前記通信装置が前記審査手順における審査に合格した場合に、前記通信装置に、該通信装置の新たな公開鍵証明書を送信する送信手順をさらに有することを特徴とする審査方法。
【請求項22】
請求項21記載の審査方法であって、
前記送信手順で送信する公開鍵証明書は、前記受信手順で受信した前記通信装置の識別情報を含む公開鍵証明書であることを特徴とする審査方法。
【請求項23】
コンピュータを、
公開鍵暗号を用いた認証処理を行うが該認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、該通信装置の公開鍵証明書と該通信装置の識別情報とを受信する受信手段と、
該手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、前記識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
該手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて前記通信装置を審査する審査手段として機能させるためのプログラム。
【請求項24】
請求項23記載のプログラムであって、
前記審査手段が、前記受信手段が受信した公開鍵証明書の内容と前記取得手段が取得した情報とが一致するか否かに基づいて前記公開鍵証明書が適切なものであるか否かを判断する機能を有することを特徴とするプログラム。
【請求項25】
コンピュータを、
公開鍵暗号を用いた認証処理を行う通信装置から、該通信装置の私有鍵と、該通信装置の識別情報とを受信する受信手段と、
該手段が受信した識別情報と対応する公開鍵を、該識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
該手段が取得した公開鍵と前記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて前記通信装置を審査する審査手段として機能させるためのプログラム。
【請求項26】
請求項25記載のプログラムであって、
前記コンピュータを、通信装置の識別情報と該通信装置が前記認証処理に使用する公開鍵との対応関係を記憶する手段として機能させるためのプログラムを更に含むことを特徴とするプログラム。
【請求項27】
請求項25又は26記載のプログラムであって、
前記審査手段が、前記取得手段が取得した公開鍵と前記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて前記審査を行う機能を有することを特徴とするプログラム。
【請求項28】
請求項23乃至27のいずれか一項記載のプログラムであって、
前記コンピュータを、前記通信装置が前記審査手段による審査に合格した場合に、前記通信装置に、該通信装置の新たな公開鍵証明書を送信する送信手段として機能させるためのプログラムを更に含むことを特徴とするプログラム。
【請求項29】
請求項28記載のプログラムであって、
前記送信手段が送信する公開鍵証明書は、前記受信手段が受信した前記通信装置の識別情報を含む公開鍵証明書であることを特徴とするプログラム。
【請求項30】
請求項23乃至29のいずれか一項記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項1】
公開鍵暗号を用いた認証処理を行うが該認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、該通信装置の公開鍵証明書と該通信装置の識別情報とを受信する受信手段と、
該手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、前記識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
該手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて前記通信装置を審査する審査手段とを設けたことを特徴とする審査装置。
【請求項2】
請求項1記載の審査装置であって、
前記審査手段が、前記受信手段が受信した公開鍵証明書の内容と前記取得手段が取得した情報とが一致するか否かに基づいて前記公開鍵証明書が適切なものであるか否かを判断する手段を有することを特徴とする審査装置。
【請求項3】
公開鍵暗号を用いた認証処理を行う通信装置から、該通信装置の私有鍵と、該通信装置の識別情報とを受信する受信手段と、
該手段が受信した識別情報と対応する公開鍵を、該識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
該手段が取得した公開鍵と前記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて前記通信装置を審査する審査手段とを設けたことを特徴とする審査装置。
【請求項4】
請求項3記載の審査装置であって、
通信装置の識別情報と該通信装置が前記認証処理に使用する公開鍵との対応関係を記憶する手段を設けたことを特徴とする審査装置。
【請求項5】
請求項3又は4記載の審査装置であって、
前記審査手段が、前記取得手段が取得した公開鍵と前記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて前記審査を行う手段を有することを特徴とする審査装置。
【請求項6】
請求項1乃至5のいずれか一項記載の審査装置であって、
前記通信装置が前記審査手段による審査に合格した場合に、前記通信装置に、該通信装置の新たな公開鍵証明書を送信する送信手段を設けたことを特徴とする審査装置。
【請求項7】
請求項6記載の審査装置であって、
前記送信手段が送信する公開鍵証明書は、前記受信手段が受信した前記通信装置の識別情報を含む公開鍵証明書であることを特徴とする審査装置。
【請求項8】
公開鍵暗号を用いた認証処理を行うが該認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置であって、自身の公開鍵証明書と自身の識別情報とを審査装置に送信する手段を有する通信装置と、
該通信装置から、該通信装置の公開鍵証明書と該通信装置の識別情報とを受信する受信手段と、
該手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、前記識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
該手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて前記通信装置を審査する審査手段とを設けた審査装置とを備えることを特徴とする通信システム。
【請求項9】
請求項8記載の通信システムであって、
前記審査装置の審査手段が、前記受信手段が受信した公開鍵証明書の内容と前記取得手段が取得した情報とが一致するか否かに基づいて前記公開鍵証明書が適切なものであるか否かを判断する手段を有することを特徴とする通信システム。
【請求項10】
公開鍵暗号を用いた認証処理を行う通信装置であって、自身の私有鍵と識別情報とを審査装置に送信する手段を有する通信装置と、
該通信装置から、該通信装置の私有鍵と、該通信装置の識別情報とを受信する受信手段と、
該手段が受信した識別情報と対応する公開鍵を、該識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
該手段が取得した公開鍵と前記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて前記通信装置を審査する審査手段とを設けた審査装置とを備えることを特徴とする通信システム。
【請求項11】
請求項10記載の通信システムであって、
前記審査装置に、通信装置の識別情報と該通信装置が前記認証処理に使用する公開鍵との対応関係を記憶する手段を設けたことを特徴とする通信システム。
【請求項12】
請求項10又は11記載の通信システムであって、
前記審査装置の審査手段が、前記取得手段が取得した公開鍵と前記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて前記審査を行う手段を有することを特徴とする通信システム。
【請求項13】
請求項8乃至12のいずれか一項記載の通信システムであって、
前記審査装置に、前記通信装置が前記審査手段による審査に合格した場合に、前記通信装置に、該通信装置の新たな公開鍵証明書を送信する送信手段を設け、
前記通信装置に、該公開鍵証明書を受信する手段を設けたことを特徴とする通信システム。
【請求項14】
請求項13記載の通信システムであって、
前記審査装置の送信手段が送信する公開鍵証明書は、前記受信手段が受信した前記通信装置の識別情報を含む公開鍵証明書であることを特徴とする通信システム。
【請求項15】
請求項8乃至13のいずれか一項記載の通信システムであって、
前記通信装置において、前記認証処理に使用する公開鍵証明書と私有鍵とを、独立して交換可能な複数のメモリユニットに分散させて記憶させるようにしたことを特徴とする通信システム。
【請求項16】
公開鍵暗号を用いた認証処理を行うが該認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、該通信装置の公開鍵証明書と該通信装置の識別情報とを受信する受信手順と、
該手順で受信した識別情報と対応する公開鍵証明書の内容を示す情報を、前記識別情報をもとに前記通信装置とは異なる場所から取得する取得手順と、
該手順で取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて前記通信装置を審査する審査手順とを有することを特徴とする審査方法。
【請求項17】
請求項16記載の審査方法であって、
前記審査手順に、前記受信手順で受信した公開鍵証明書の内容と前記取得手順で取得した情報とが一致するか否かに基づいて前記公開鍵証明書が適切なものであるか否かを判断する手順を設けたことを特徴とする審査方法。
【請求項18】
公開鍵暗号を用いた認証処理を行う通信装置から、該通信装置の私有鍵と、該通信装置の識別情報とを受信する受信手順と、
該手順で受信した識別情報と対応する公開鍵を、該識別情報をもとに前記通信装置とは異なる場所から取得する取得手順と、
該手順で取得した公開鍵と前記受信手順で受信した私有鍵とが対応するものであるか否かに基づいて前記通信装置を審査する審査手順とを有することを特徴とする審査方法。
【請求項19】
請求項18記載の審査方法であって、
前記各手順を実行する装置に、通信装置の識別情報と該通信装置が前記認証処理に使用する公開鍵との対応関係を記憶させておくようにしたことを特徴とする審査方法。
【請求項20】
請求項18又は19記載の審査方法であって、
前記審査手順に、前記取得手順で取得した公開鍵と前記受信手順で受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて前記審査を行う手順を設けたことを特徴とする審査方法。
【請求項21】
請求項16乃至20のいずれか一項記載の審査方法であって、
前記通信装置が前記審査手順における審査に合格した場合に、前記通信装置に、該通信装置の新たな公開鍵証明書を送信する送信手順をさらに有することを特徴とする審査方法。
【請求項22】
請求項21記載の審査方法であって、
前記送信手順で送信する公開鍵証明書は、前記受信手順で受信した前記通信装置の識別情報を含む公開鍵証明書であることを特徴とする審査方法。
【請求項23】
コンピュータを、
公開鍵暗号を用いた認証処理を行うが該認証処理に使用する公開鍵証明書は特定の相手にしか渡さない通信装置から、該通信装置の公開鍵証明書と該通信装置の識別情報とを受信する受信手段と、
該手段が受信した識別情報と対応する公開鍵証明書の内容を示す情報を、前記識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
該手段が取得した情報をもとに、受信した公開鍵証明書が適切なものであるか否かに基づいて前記通信装置を審査する審査手段として機能させるためのプログラム。
【請求項24】
請求項23記載のプログラムであって、
前記審査手段が、前記受信手段が受信した公開鍵証明書の内容と前記取得手段が取得した情報とが一致するか否かに基づいて前記公開鍵証明書が適切なものであるか否かを判断する機能を有することを特徴とするプログラム。
【請求項25】
コンピュータを、
公開鍵暗号を用いた認証処理を行う通信装置から、該通信装置の私有鍵と、該通信装置の識別情報とを受信する受信手段と、
該手段が受信した識別情報と対応する公開鍵を、該識別情報をもとに前記通信装置とは異なる場所から取得する取得手段と、
該手段が取得した公開鍵と前記受信手段が受信した私有鍵とが対応するものであるか否かに基づいて前記通信装置を審査する審査手段として機能させるためのプログラム。
【請求項26】
請求項25記載のプログラムであって、
前記コンピュータを、通信装置の識別情報と該通信装置が前記認証処理に使用する公開鍵との対応関係を記憶する手段として機能させるためのプログラムを更に含むことを特徴とするプログラム。
【請求項27】
請求項25又は26記載のプログラムであって、
前記審査手段が、前記取得手段が取得した公開鍵と前記受信手段が受信した私有鍵とのうち一方を用いて任意のデータを暗号化し、他方を用いてその暗号化したデータを復号化し、その復号化の結果に基づいて前記審査を行う機能を有することを特徴とするプログラム。
【請求項28】
請求項23乃至27のいずれか一項記載のプログラムであって、
前記コンピュータを、前記通信装置が前記審査手段による審査に合格した場合に、前記通信装置に、該通信装置の新たな公開鍵証明書を送信する送信手段として機能させるためのプログラムを更に含むことを特徴とするプログラム。
【請求項29】
請求項28記載のプログラムであって、
前記送信手段が送信する公開鍵証明書は、前記受信手段が受信した前記通信装置の識別情報を含む公開鍵証明書であることを特徴とするプログラム。
【請求項30】
請求項23乃至29のいずれか一項記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【図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】
【図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】
【公開番号】特開2006−60780(P2006−60780A)
【公開日】平成18年3月2日(2006.3.2)
【国際特許分類】
【出願番号】特願2005−187405(P2005−187405)
【出願日】平成17年6月27日(2005.6.27)
【出願人】(000006747)株式会社リコー (37,907)
【Fターム(参考)】
【公開日】平成18年3月2日(2006.3.2)
【国際特許分類】
【出願日】平成17年6月27日(2005.6.27)
【出願人】(000006747)株式会社リコー (37,907)
【Fターム(参考)】
[ Back to top ]