(57)【要約】【課題】  セキュリティを維持しながら、正常な認証を受けられる状態を容易に維持できるようにする。【解決手段】  下位装置２０が、上位装置１０から通信を要求された場合に、上位装置１０に認証を受けるための証明書として、複数のＵＲＬでデジタル証明書を提供するようにし、通常処理ＵＲＬに通信を要求された場合にはパブリック認証局によって発行されたデジタル証明書である通常公開鍵証明書を提供し、レスキューＵＲＬに通信を要求された場合にはプライベート認証局によって発行されたデジタル証明書であるレスキュー公開鍵証明書を提供する。そして、レスキュー公開鍵証明書を提供するレスキューＵＲＬで通信を行う場合には、上記通常公開鍵証明書の設定に関する要求以外の要求に係る処理を禁止するようにした。【選択図】        図１０
2005130454.tif 000002
【特許請求の範囲】
【請求項１】
通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、前記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置であって、
前記通信手段は、前記複数のアドレスのうち第１のアドレスではパブリック認証局によって発行されたデジタル証明書であるパブリック証明書を提供し、第２のアドレスではプライベート認証局によって発行されたデジタル証明書であるプライベート証明書を提供する手段であり、
前記第２のアドレスで通信を行う場合には前記パブリック証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段を設けたことを特徴とする通信装置。
【請求項２】
請求項１記載の通信装置であって、
前記デジタル証明書を提供した通信相手から該通信相手のデジタル証明書を受信して認証を行い、該認証が成功した場合のみその後の通信を許可する認証手段を設け、
前記要求実行手段に、その通信相手から前記パブリック証明書の設定要求を受信した場合に前記パブリック証明書を更新する手段を設けたことを特徴とする通信装置。
【請求項３】
請求項１又は２記載の通信装置であって、
前記パブリック証明書の設定に関する要求は、前記パブリック証明書の作成に必要な情報の取得要求と前記パブリック証明書の設定要求であることを特徴とする通信装置。
【請求項４】
請求項１乃至３のいずれか一項記載の通信装置であって、
前記要求実行手段は、前記要求に対応する所定の処理を行う複数の要求処理手段を有し、
受信したアドレスと要求の種類とに従って要求を前記各要求処理手段に振り分ける振り分け手段を設け、
前記禁止手段は、前記振り分け手段が前記通信を行っているアドレスによっては所定の要求以外の要求を前記要求処理手段に振り分けないようにすることにより、前記処理の禁止を行う手段であることを特徴とする通信装置。
【請求項５】
請求項１乃至４のいずれか一項記載の通信装置であって、
前記要求はＳＯＡＰメッセージとして記載されていることを特徴とする通信装置。
【請求項６】
請求項１乃至５のいずれか一項記載の通信装置であって、
前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信装置。
【請求項７】
通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、前記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する下位装置と、該下位装置の通信相手となる上位装置とによって構成される通信システムであって、
前記下位装置の前記通信手段は、前記複数のアドレスのうち第１のアドレスではパブリック認証局によって発行されたデジタル証明書であるパブリック証明書を提供し、第２のアドレスではプライベート認証局によって発行されたデジタル証明書であるプライベート証明書を提供する手段であり、
前記下位装置に、前記第２のアドレスで通信を行う場合には前記パブリック証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段を設け、
前記上位装置に、通信相手から受信したデジタル証明書を用いてその通信相手を認証する認証手段を設けたことを特徴とする通信システム。
【請求項８】
請求項７記載の通信システムであって、
前記下位装置に、前記デジタル証明書を提供した通信相手から該通信相手のデジタル証明書を受信して認証を行い、該認証が成功した場合のみその後の通信を許可する認証手段を設け、
前記下位装置の前記要求実行手段に、通信相手から前記パブリック証明書の設定要求を受信した場合に前記パブリック証明書を更新する手段を設けたことを特徴とする通信システム。
【請求項９】
請求項７又は８記載の通信システムであって、
前記パブリック証明書の設定に関する要求は、前記パブリック証明書の作成に必要な情報の取得要求と前記パブリック証明書の設定要求であることを特徴とする通信システム。
【請求項１０】
請求項７乃至９のいずれか一項記載の通信システムであって、
前記要求はＳＯＡＰメッセージとして記載されていることを特徴とする通信システム。
【請求項１１】
請求項７乃至１０のいずれか一項記載の通信システムであって、
前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信システム。
【請求項１２】
通信装置に、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供させ、前記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行わせ、該通信において通信相手から受信した要求に応じた処理を行わせる通信装置の制御方法であって、
前記通信装置に、前記複数のアドレスのうち第１のアドレスではパブリック認証局によって発行されたデジタル証明書であるパブリック証明書を提供させ、第２のアドレスではプライベート認証局によって発行されたデジタル証明書であるプライベート証明書を提供させ、
前記第２のアドレスで通信を行う場合には前記パブリック証明書の設定に関する要求以外の要求に係る処理を禁止させることを特徴とする通信装置の制御方法。
【請求項１３】
請求項１２記載の通信装置の制御方法であって、
さらに、前記通信装置に、前記デジタル証明書を提供した通信相手から該通信相手のデジタル証明書を受信させて認証を行わせ、該認証が成功した場合のみその後の通信を許可させるようにし、
通信相手から前記パブリック証明書の設定要求を受信した場合に前記パブリック証明書を更新させることを特徴とする通信装置の制御方法。
【請求項１４】
請求項１２又は１３記載の通信装置の制御方法であって、
前記パブリック証明書の設定に関する要求は、前記パブリック証明書の作成に必要な情報の取得要求と前記パブリック証明書の設定要求であることを特徴とする通信装置の制御方法。
【請求項１５】
請求項１２乃至１４のいずれか一項記載の通信装置の制御方法であって、
前記要求はＳＯＡＰメッセージとして記載されていることを特徴とする通信装置の制御方法。
【請求項１６】
請求項１２乃至１５のいずれか一項記載の通信装置の制御方法であって、
前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信装置の制御方法。
【請求項１７】
コンピュータを、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、前記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段として機能させるためのプログラムであって、
前記通信手段は、前記複数のアドレスのうち第１のアドレスではパブリック認証局によって発行されたデジタル証明書であるパブリック証明書を提供し、第２のアドレスではプライベート認証局によって発行されたデジタル証明書であるプライベート証明書を提供する手段であり、
さらに、前記コンピュータを、前記第２のアドレスで通信を行う場合には前記パブリック証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段として機能させるためのプログラムを含むことを特徴とするプログラム。
【請求項１８】
請求項１７記載のプログラムであって、
さらに、前記コンピュータを、前記デジタル証明書を提供した通信相手から該通信相手のデジタル証明書を受信して認証を行い、該認証が成功した場合のみその後の通信を許可する認証手段として機能させるためのプログラムを含み、
前記要求実行手段に、その通信相手から前記パブリック証明書の設定要求を受信した場合に前記パブリック証明書を更新する機能を設けたことを特徴とするプログラム。
【請求項１９】
請求項１７又は１８記載のプログラムであって、
前記パブリック証明書の設定に関する要求は、前記パブリック証明書の作成に必要な情報の取得要求と前記パブリック証明書の設定要求であることを特徴とするプログラム。
【請求項２０】
請求項１７乃至１９のいずれか一項記載のプログラムであって、
前記要求はＳＯＡＰメッセージとして記載されていることを特徴とするプログラム。
【請求項２１】
請求項１７乃至２０のいずれか一項記載のプログラムであって、
前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、通信手段を備え、通信の際に通信相手に認証を受けるためにデジタル証明書を提供する通信装置、このような通信装置である下位装置とその通信相手となる上位装置によって構成される通信システム、通信の際に通信相手に認証を受けるためにデジタル証明書を提供させるための通信装置の制御方法、およびコンピュータを上記の通信装置として機能させるためのプログラムに関する。
【背景技術】
【０００２】
従来から、それぞれ通信機能を備えた複数の通信装置をネットワークを介して通信可能に接続し、様々なシステムを構築することが行われている。その一例としては、クライアント装置として機能するＰＣ等のコンピュータから商品の注文を送信し、これとインターネットを介して通信可能なサーバ装置においてその注文を受け付けるといった、いわゆる電子商取引システムが挙げられる。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。
【０００３】
このようなシステムを構築する上では、通信を行う際に、通信相手が適切か、あるいは送信されてくる情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばＳＳＬ（Secure Socket Layer）と呼ばれるプロトコルが開発されており、広く用いられている。このプロトコルを用いて通信を行うことにより、公開鍵暗号方式と共通鍵暗号方式とを組み合わせ、通信相手の認証を行うと共に、情報の暗号化により改竄及び盗聴の防止を図ることができる。また、通信相手の側でも、通信を要求してきた通信元の装置を認証することができる。
このようなＳＳＬや公開鍵暗号を用いた認証に関連する技術としては、例えば特許文献１及び特許文献２に記載のものが挙げられる。
【特許文献１】特開２００２−３５３９５９号公報
【特許文献２】特開２００２−２５１４９２号公報
【０００４】
ここで、このＳＳＬに従った相互認証を行う場合の通信手順について、認証処理の部分に焦点を当てて説明する。図２４は、通信装置Ａと通信装置ＢとがＳＳＬに従った相互認証を行う際に各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図２４に示すように、ＳＳＬに従った相互認証を行う際には、まず双方の通信装置にルート鍵証明書及び、私有鍵と公開鍵証明書（これらをまとめて「証明書セット」と呼ぶ）を記憶させておく必要がある。この私有鍵は、認証局（ＣＡ：certificate authority）が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にＣＡがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、ＣＡがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。
【０００５】
図２５にこれらの関係を示す。
図２５（ａ）に示すように、公開鍵Ａは、私有鍵Ａを用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者（ＣＡ）や有効期限等の情報を含む書誌情報とによって構成される。そして、ＣＡは、鍵本体や書誌情報が改竄されていないことを示すため、公開鍵Ａをハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名として公開鍵Ａに付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Ａの書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、公開鍵証明書Ａである。
【０００６】
この公開鍵証明書Ａを認証処理に用いる場合には、ここに含まれるデジタル署名を、ルート私有鍵と対応する公開鍵であるルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば、デジタル署名が確かにＣＡによって付されたことがわかる。また、公開鍵Ａの部分をハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とが一致すれば、鍵自体も損傷や改竄を受けていないことがわかる。さらに、受信したデータをこの公開鍵Ａを用いて正常に復号化できれば、そのデータは、私有鍵Ａの持ち主から送信されたものであることがわかる。
【０００７】
ここで、認証を行うためには、ルート鍵を予め記憶しておく必要があるが、このルート鍵も、図２５（ｂ）に示すように、ＣＡがデジタル署名を付したルート鍵証明書として記憶しておく。このルート鍵証明書は、自身に含まれる公開鍵でデジタル署名を復号化可能な、自己署名形式である。そして、ルート鍵を使用する際に、そのルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し、ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば、ルート鍵が破損等していないことを確認できるのである。
【０００８】
図２４のフローチャートの説明に入る。なお、この図において、２本のフローチャート間の矢印は、データの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また、各ステップの処理が正常に完了しなかった場合には、その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合、処理がタイムアウトした場合等も同様である。
【０００９】
ここでは、通信装置Ａが通信装置Ｂに通信を要求するものとするが、この要求を行う場合、通信装置ＡのＣＰＵは、所要の制御プログラムを実行することにより、図２４の左側に示すフローチャートの処理を開始する。そして、ステップＳ１１で通信装置Ｂに対して接続要求を送信する。
一方通信装置ＢのＣＰＵは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図２４の右側に示すフローチャートの処理を開始する。そして、ステップＳ２１で第１の乱数を生成し、これを私有鍵Ｂを用いて暗号化する。そして、ステップＳ２２でその暗号化した第１の乱数と公開鍵証明書Ｂとを通信装置Ａに送信する。
【００１０】
通信装置Ａ側では、これを受信すると、ステップＳ１２でルート鍵証明書を用いて公開鍵証明書Ｂの正当性を確認する。
そして確認ができると、ステップＳ１３で、受信した公開鍵証明書Ｂに含まれる公開鍵Ｂを用いて第１の乱数を復号化する。ここで復号化が成功すれば、第１の乱数は確かに公開鍵証明書Ｂの発行対象から受信したものだと確認できる。
その後、ステップＳ１４でこれとは別に第２の乱数及び共通鍵の種を生成する。共通鍵の種は、例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして、ステップＳ１５で第２の乱数を私有鍵Ａを用いて暗号化し、共通鍵の種を公開鍵Ｂを用いて暗号化し、ステップＳ１６でこれらを公開鍵証明書Ａと共にサーバ装置に送信する。共通鍵の種の暗号化は、通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。
また、次のステップＳ１７では、ステップＳ１４で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
【００１１】
通信装置Ｂ側では、通信装置ＡがステップＳ１６で送信してくるデータを受信すると、ステップＳ２３でルート鍵証明書を用いて公開鍵証明書Ａの正当性を確認する。そして確認ができると、ステップＳ２４で、受信した公開鍵証明書Ａに含まれる公開鍵Ａを用いて第２の乱数を復号化する。ここで復号化が成功すれば、第２の乱数は確かに公開鍵証明書Ａの発行対象から受信したものだと確認できる。
その後、ステップＳ２５で私有鍵Ｂを用いて共通鍵の種を復号化する。ここまでの処理で、通信装置Ａ側と通信装置Ｂ側に共通鍵の種が共有されたことになる。そして、この共通鍵の種は、生成した通信装置Ａと、私有鍵Ｂを持つ通信装置Ｂ以外の装置が知ることはない。ここまでの処理が成功すると、通信装置Ｂ側でもステップＳ２６で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
【００１２】
そして、通信装置Ａ側のステップＳ１７と通信装置Ｂ側のステップＳ２６の処理が終了すると、相互に認証の成功と以後の通信に使用する暗号化方式とを確認し、生成した共通鍵を用いてその暗号化方式で以後の通信を行うものとして認証に関する処理を終了する。なお、この確認には、通信装置Ｂからの認証が成功した旨の応答も含むものとする。以上の処理によって互いに通信を確立し、以後はステップＳ１７又はＳ２６で生成した共通鍵を用い、共通鍵暗号方式でデータを暗号化して通信を行うことができる。
【００１３】
このような処理を行うことにより、通信装置Ａと通信装置Ｂが安全に共通鍵を共有することができ、通信を安全に行う経路を確立することができる。
ただし、上述した処理において、第２の乱数を公開鍵Ａで暗号化し、公開鍵証明書Ａを通信装置Ｂに送信することは必須ではない。この場合、通信装置Ｂ側のステップＳ２３及びＳ２４の処理は不要になり、処理は図２６に示すようになる。このようにすると、通信装置Ｂが通信装置Ａを認証することはできないが、通信装置Ａが通信装置Ｂを認証するだけでよい場合にはこの処理で十分である。そしてこの場合には、通信装置Ａに記憶させるのはルート鍵証明書のみでよく、私有鍵Ａ及び公開鍵証明書Ａは不要である。また、通信装置Ｂにはルート鍵証明書を記憶させる必要はない。
【００１４】
一方、このような公開鍵証明書を発行する第３者機関として、私有鍵の保有者の確認を行い、その私有鍵に対応した公開鍵に対してデジタル署名を行い、公開鍵証明書を発行する商用サービスが、例えばベリサイン社やボルチモア社によって提供されている。そして、公開鍵発行のためのシステムが私有鍵を含めて厳重に管理されている信頼性の高い第３者機関が発行する公開鍵証明書は、広く認証に利用されている。また、デジタル証明書を用いた認証を行う場合、信頼性の高い第３者機関が発行した公開鍵証明書を使用したいという要求もある。
【００１５】
さらに、このような第３者機関の発行する公開鍵証明書を利用する場合、主要な第３者機関によるデジタル署名の内容を確認するためのルート鍵は、インターネットエクスプローラ（登録商標）やネットスケープ（登録商標）のような一般的なウェブブラウザには予め埋め込まれているため、ウェブブラウザの操作者は、新たにルート鍵を入手して設定する必要がないという利点がある。
また、予めルート鍵を設定されていない装置であっても、信頼性の高い第３者機関のものであればユーザがルート鍵の設定に同意しやすいし、ルート鍵を入手して設定すれば、同じ第３者機関が発行した公開鍵証明書を持つ装置は、装置自体のベンダーに関わらず認証することができるという利点もある。従って、自社製の装置を他社製の装置に接続したい場合等には、第３者機関の発行する公開鍵証明書を利用することが効果的である。また、装置のユーザ側からも、このような公開鍵証明書を利用したいという要望がある。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
このように、第３者機関が発行する公開鍵証明書は、信頼性の面では優れたものであるが、その信頼性を保つために、有効期間が例えば１〜３年などと比較的短く設定されていることが多く、有効期限が切れた場合に新たな公開鍵証明書の発行を受ける必要がある。また、通信装置の運用者が従前の契約を破棄し、新たな第３者期間との契約を締結する場合も考えられる。このようなとき、通信装置が従来から記憶している公開鍵証明書では通信相手から認証を受けられない状態となってしまう場合があるという問題があった。
【００１７】
このような場合でも、認証を受けられない状態となった時点で操作者が装置を操作して新たな公開鍵証明書を容易に設定できるような場合は、操作者を認証する等してセキュリティを保持することができるため、さほど深刻な問題にはならない。しかし、ユーザの習熟度や利用環境から操作者による設定が困難であったり、装置の運用上、操作者に自由に証明書を設定させることが好ましくなかったりする等の理由で通信システム上の他の通信装置からリモートで証明書を設定するような構成とする場合は、認証が行えない状態ではセキュリティを保持するための手段がなく、この点が深刻な問題となる。
この発明は、このような問題を解決し、通信手段を備え、通信の際に通信相手に認証を受けるためにデジタル証明書を提供する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、セキュリティを維持しながら、正常な認証を受けられる状態を容易に維持できるようにすることを目的とする。
【課題を解決するための手段】
【００１８】
上記の目的を達成するため、この発明の通信装置は、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、上記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置において、上記通信手段を、上記複数のアドレスのうち第１のアドレスではパブリック認証局によって発行されたデジタル証明書であるパブリック証明書を提供し、第２のアドレスではプライベート認証局によって発行されたデジタル証明書であるプライベート証明書を提供する手段とし、上記第２のアドレスで通信を行う場合には上記パブリック証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段を設けたものである。
【００１９】
このような通信装置において、上記デジタル証明書を提供した通信相手からその通信相手のデジタル証明書を受信して認証を行い、その認証が成功した場合のみその後の通信を許可する認証手段を設け、上記要求実行手段に、その通信相手から上記パブリック証明書の設定要求を受信した場合に上記パブリック証明書を更新する手段を設けるとよい。
さらに、上記パブリック証明書の設定に関する要求を、上記パブリック証明書の作成に必要な情報の取得要求と上記パブリック証明書の設定要求とするとよい。
【００２０】
さらに、上記要求実行手段に、上記要求に対応する所定の処理を行う複数の要求処理手段を設け、受信したアドレスと要求の種類とに従って要求を上記各要求処理手段に振り分ける振り分け手段を設け、上記禁止手段を、上記振り分け手段が上記通信を行っているアドレスによっては所定の要求以外の要求を上記要求処理手段に振り分けないようにすることにより、上記処理の禁止を行う手段とするとよい。
さらにまた、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらに、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
【００２１】
また、この発明の通信システムは、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、上記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する下位装置と、その下位装置の通信相手となる上位装置とによって構成される通信システムにおいて、上記下位装置の上記通信手段を、上記複数のアドレスのうち第１のアドレスではパブリック認証局によって発行されたデジタル証明書であるパブリック証明書を提供し、第２のアドレスではプライベート認証局によって発行されたデジタル証明書であるプライベート証明書を提供する手段とし、上記下位装置に、上記第２のアドレスで通信を行う場合には上記パブリック証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段を設け、上記上位装置に、通信相手から受信したデジタル証明書を用いてその通信相手を認証する認証手段を設けたものである。
【００２２】
このような通信システムにおいて、上記下位装置に、上記デジタル証明書を提供した通信相手からその通信相手のデジタル証明書を受信して認証を行い、その認証が成功した場合のみその後の通信を許可する認証手段を設け、上記下位装置の上記要求実行手段に、通信相手から上記パブリック証明書の設定要求を受信した場合に上記パブリック証明書を更新する手段を設けるとよい。
さらに、上記パブリック証明書の設定に関する要求を、上記パブリック証明書の作成に必要な情報の取得要求と上記パブリック証明書の設定要求とするとよい。
さらに、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらにまた、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
【００２３】
また、この発明の通信装置の制御方法は、通信装置に、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供させ、上記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行わせ、その通信において通信相手から受信した要求に応じた処理を行わせる通信装置の制御方法において、上記通信装置に、上記複数のアドレスのうち第１のアドレスではパブリック認証局によって発行されたデジタル証明書であるパブリック証明書を提供させ、第２のアドレスではプライベート認証局によって発行されたデジタル証明書であるプライベート証明書を提供させ、上記第２のアドレスで通信を行う場合には上記パブリック証明書の設定に関する要求以外の要求に係る処理を禁止させるようにしたものである。
【００２４】
このような通信装置の制御方法において、上記通信装置に、上記デジタル証明書を提供した通信相手からその通信相手のデジタル証明書を受信させて認証を行わせ、その認証が成功した場合のみその後の通信を許可させるようにし、通信相手から上記パブリック証明書の設定要求を受信した場合に上記パブリック証明書を更新させるようにするとよい。
さらに、上記パブリック証明書の設定に関する要求を、上記パブリック証明書の作成に必要な情報の取得要求と上記パブリック証明書の設定要求とするとよい。
さらに、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらにまた、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
【００２５】
また、この発明のプログラムは、コンピュータを、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、上記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段として機能させるためのプログラムにおいて、上記通信手段を、上記複数のアドレスのうち第１のアドレスではパブリック認証局によって発行されたデジタル証明書であるパブリック証明書を提供し、第２のアドレスではプライベート認証局によって発行されたデジタル証明書であるプライベート証明書を提供する手段とし、さらに、上記コンピュータを、上記第２のアドレスで通信を行う場合には上記パブリック証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段として機能させるためのプログラムを含めるようにしたものである。
【００２６】
このようなプログラムにおいて、さらに、上記コンピュータを、上記デジタル証明書を提供した通信相手からその通信相手のデジタル証明書を受信して認証を行い、その認証が成功した場合のみその後の通信を許可する認証手段として機能させるためのプログラムを含め、上記要求実行手段に、その通信相手から上記パブリック証明書の設定要求を受信した場合に上記パブリック証明書を更新する機能を設けるとよい。
さらに、上記パブリック証明書の設定に関する要求を、上記パブリック証明書の作成に必要な情報の取得要求と上記パブリック証明書の設定要求とするとよい。
さらに、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらにまた、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
【発明の効果】
【００２７】
以上のようなこの発明の通信装置、通信システムあるいは通信装置の制御方法によれば、通信手段を備え、通信の際に通信相手に認証を受けるためにデジタル証明書を提供する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、セキュリティを維持しながら、正常な認証を受けられる状態を容易に維持できるようにすることができる。
また、この発明のプログラムによれば、コンピュータを上記の通信装置として機能させてその特徴を実現し、同様な効果を得ることができる。
【発明を実施するための最良の形態】
【００２８】
以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明による通信装置と、その通信装置を用いて構成したこの発明の通信システムの実施形態の構成について説明する。
図１はその通信システムの構成を示すブロック図である。
この通信システムは、図１に示すように、それぞれ通信装置である上位装置１０及び下位装置２０をネットワーク３０によって接続して構成されている。そして、下位装置２０がこの発明の通信装置の実施形態である。また、上位装置１０も通信機能を備えた通信装置である。
ネットワーク３０としては、有線，無線を問わず、ネットワークを構築可能な各種通信回線（通信経路）を採用することができる。また、ここでは下位装置２０を１つしか示していないが、図２３に示すように通信システム内に下位装置２０を複数設けることも可能である。
【００２９】
このような通信システムについて、まず上位装置１０及び下位装置２０のハードウェア構成から説明する。上位装置１０及び下位装置２０のハードウェア構成は、単純化して示すと、図２に示すようなものである。
この図に示す通り、上位装置１０は、ＣＰＵ１１，ＲＯＭ１２，ＲＡＭ１３，ＨＤＤ１４，通信インタフェース（Ｉ／Ｆ）１５を備え、これらがシステムバス１６によって接続されている。そして、ＣＰＵ１１がＲＯＭ１２やＨＤＤ１４に記憶している各種制御プログラムを実行することによってこの上位装置１０の動作を制御し、通信相手の認証や下位装置２０のデジタル証明書更新等の機能を実現している。なお、この明細書において、デジタル証明書とは、偽造されないようにするための署名が付されたデジタルデータを指すものとする。
【００３０】
下位装置２０も、上位装置１０の場合と同様にＣＰＵ２１，ＲＯＭ２２，ＲＡＭ２３，ＨＤＤ２４，通信インタフェース（Ｉ／Ｆ）２５を備え、これらがシステムバス２６によって接続されている。ＣＰＵ２１が、ＲＯＭ２２やＨＤＤ２４に記憶している各種制御プログラムを必要に応じて実行し、装置の制御を行うことにより、通信手段、禁止手段、認証手段、要求実行手段、振り分け手段等の種々の手段としての機能を実現できるようにしている。
なお、この通信システムにおいて、上位装置１０及び下位装置２０が、遠隔管理，電子商取引等の目的に応じて種々の構成をとることができることは、もちろんである。そして、上位装置１０や下位装置２０のハードウェアとしては、適宜公知のコンピュータを採用することもできる。もちろん、必要に応じて他のハードウェアを付加してもよいし、上位装置１０と下位装置２０が同一の構成である必要もない。
【００３１】
次に、この通信システムにおける通信方式について説明する。図３はその通信方式の概要を示す説明図である。
この通信システムにおいて、上位装置１０は、下位装置２０と通信を行おうとする場合、まず下位装置２０に対して通信を要求する。そして、従来の技術の項で図２４又は図２６を用いて説明したようなＳＳＬプロトコルに従った認証処理によって下位装置２０を正当な通信相手として認証した場合に、下位装置２０との間で通信を確立させるようにしている。この認証処理は、ＳＳＬハンドシェイクと呼ばれる。ただし、図２４に示したような相互認証は必須ではなく、図２６に示したような片方向認証でもよい。
この処理において、下位装置２０は自身の公開鍵証明書を上位装置１０に送信して、認証を受ける。そして、相互認証を行う場合には上位装置１０も下位装置２０に自身の公開鍵証明書を送信して認証を受けるが、片方向認証の場合にはこちらの認証は行わない。そして、相互認証の場合には、上位装置１０から受信した公開鍵証明書により認証を行う際に、下位装置２０のＣＰＵが認証手段として機能する。
【００３２】
以上の認証が成功すると、上位装置１０は、下位装置２０が実装するアプリケーションプログラムのメソッドに対する処理の依頼である要求を、構造化言語形式であるＸＭＬ形式で記載したＳＯＡＰメッセージとして生成し、ＨＴＴＰ（Hyper Text Transfer Protocol）に従ってＨＴＴＰリクエスト４０として下位装置２０に送信する。このような要求は、ＲＰＣ（Remote Procedure Call）と呼ばれる。
そして、下位装置２０はこの要求の内容に応じた処理を実行し、その結果を応答のＳＯＡＰメッセージとして生成し、ＨＴＴＰレスポンス５０として上位装置１０に送信する。ここで、これらの要求と応答は、ＳＳＬハンドシェイクの処理において共有された共通鍵を用いて暗号化して送信し、通信の安全性を確保している。
【００３３】
また、これらの要求と応答とによって、この通信システムは、上位装置１０をクライアント、下位装置２０をサーバとするクライアント・サーバシステムとして機能している。
なお、ＲＰＣを実現するためには、上記の技術の他、ＦＴＰ（File Transfer Protocol）,ＣＯＭ（Component Object Model），ＣＯＲＢＡ（Common Object Request Broker Architecture）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。
【００３４】
次に、上述した上位装置１０及び下位装置２０が上述した認証処理に用いる認証情報である各証明書や鍵の特性及び用途について説明する。図４は、（ａ）に上位装置１０が認証情報として記憶している証明書及び鍵の種類を示し、（ｂ）に下位装置２０が認証情報として記憶している証明書及び鍵の種類を示す図である。
図１に示した上位装置１０及び下位装置２０は、図４に示すように、大きく分けて正規認証情報とレスキュー認証情報を記憶している。そして、これらの正規認証情報とレスキュー認証情報は、それぞれ自分に関する認証情報である公開鍵証明書及び私有鍵と、通信相手に関する認証情報であるルート鍵証明書とによって構成される。
【００３５】
また、例えば下位装置用通常公開鍵証明書は、証明書管理装置が下位装置２０に対して発行した通常公開鍵に、下位装置認証用通常ルート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書であり、パブリック証明書に該当する。なおここでは、パブリック認証局とは、背景技術の項で説明した第３者機関のように広く世間で信頼性が認められた認証局、あるいは公的に信頼性が認められた認証局、法的に証明書の効力が認められるような認証局等、一般的に通用するような証明書を発行できる認証局を指すものとする。また、パブリック認証局は、証明書の利用者と異なる運営者が運営する認証局である。
【００３６】
ここで、公開鍵証明書のフォーマットは、例えば図５に示したものを用いることができ、公開鍵そのものの他、証明書の発行者や証明書の有効期限、証明される対象（証明書の発行先の装置あるいは利用者）等の情報が記載されている。具体的には、例えばＸ．５０９と呼ばれるフォーマットに従って作成することができ、このフォーマットに従って作成された公開鍵証明書は、例えば図６に示すようなものになる。
この例においては、ＡがＣＡの識別情報を示し、Ｃが証明書の発行先の装置の識別情報を示す。これらは、それぞれ所在地、名称、機番あるいはコード等の情報を含む。また、Ｂが有効期間を示し、その開始日時と終了日時によって有効期間を指定している。
【００３７】
また、下位装置用通常私有鍵は、上記の通常公開鍵と対応する私有鍵、下位装置認証用通常ルート鍵証明書は、下位装置認証用通常ルート鍵に自身と対応するルート私有鍵を用いて自身で正当性を確認可能なデジタル署名を付したデジタル証明書である。
そして、下位装置２０を複数設けた場合でも、各装置の通常公開鍵に付すデジタル署名は同じルート私有鍵を用いて付し、正当性確認に必要な通常ルート鍵証明書は共通にする。しかし、通常公開鍵証明書に含まれる通常公開鍵やこれと対応する私有鍵は、装置毎に異なる。
上位装置用通常公開鍵証明書と上位装置用通常私有鍵と上位装置認証用通常ルート鍵証明書も同様な関係である。
なお、各装置に、複数のパブリック認証局によって発行された公開鍵証明書の正当性を確認できるようにするため、その各パブリック認証局と対応したルート鍵証明書を記憶させるようにすることも考えられる。
【００３８】
そして、例えば上位装置１０と下位装置２０とが正規認証情報を用いて相互認証を行う場合には、上位装置１０からの通信要求に応じて、下位装置２０は下位装置用通常私有鍵を用いて暗号化した第１の乱数を下位装置用通常公開鍵証明書と共に上位装置１０に送信する。上位装置１０側では下位装置認証用通常ルート鍵証明書を用いてまずこの下位装置用通常公開鍵証明書の正当性（損傷や改竄を受けていないこと）を確認し、これが確認できた場合にここに含まれる公開鍵で第１の乱数を復号化する。この復号化が成功した場合に、上位装置１０は通信相手の下位装置２０が確かに下位装置用通常公開鍵証明書の発行先であると認識でき、その証明書に含まれる識別情報から装置を特定することができる。そして、特定した装置が通信相手としてふさわしいか否かに応じて認証の成功と失敗を決定することができる。
また、下位装置２０側でも、上位装置１０側で認証が成功した場合に送信されてくる上位装置用通常公開鍵証明書及び、上位装置用通常私有鍵で暗号化された乱数を受信し、記憶している上位装置認証用ルート鍵証明書を用いて同様な認証を行うことができる。
【００３９】
ところで、既に述べたように、各装置が通信相手から通常公開鍵証明書を受信した場合、その発行元の認証局が発行した公開鍵証明書の正当性を確認するためのルート鍵（証明書）を記憶していなければ、受信した通常公開鍵証明書の正当性を確認することができない。従って、この場合には認証を行うことができないことになる。
また、各装置が通信相手から受信した通常公開鍵証明書による認証を行うための機能（暗号化／復号化を実現するためのモジュール等）を備えていなければ、当然のことながらその通常公開鍵証明書による認証を行うことはできない。上位装置１０において認証処理に使用する証明書を切り替えたり、下位装置２０が以前と異なる認証局の証明書を使用する上位装置１０に接続される等した場合には、このような事態が発生することも考えられる。どのパブリック認証局が発行する証明書に対応させるかは、通信システムの運用者が種々の条件を考慮して適宜定めるものだからである。
【００４０】
ここで、各装置が通常公開鍵証明書を用いた認証（通常認証情報を用いた認証）しか行えないとすると、このように証明書の正当性が確認できなかったり、認証処理に対応していなかったりする状態では、使用可能な通常公開鍵証明書や通常私有鍵及び通常ルート鍵証明書等を設定しようとしても、これらをネットワークを介して安全に対象の装置に送信する方法はないことになる。
また、装置の電源がＯＦＦされていたことにより自動更新が行えずに証明書の有効期限が切れてしまったり、更新処理中に電源がＯＦＦされる等により証明書が破損してしまったりした場合にも、認証が行えない状態になってしまうが、このような場合にも同様な問題が発生する。
【００４１】
しかし、この実施形態の通信システムを構成する各通信装置は、このような事態に対処するためにレスキュー認証情報を記憶しており、通信相手を異なる２種類のデジタル証明書を用いて認証することができるようにしている。そして、レスキュー認証情報を用いることにより、必要な装置にネットワークを介して新たな通常公開鍵証明書等を安全に送受信できるようにしている。
【００４２】
このレスキュー認証情報は、正規認証情報と概ね同様な構成となっており、例えば下位装置用レスキュー公開鍵証明書は、ＣＡが下位装置に対して発行したレスキュー公開鍵に、下位装置認証用レスキュールート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書であり、プライベート証明書に該当する。また、下位装置用レスキュー私有鍵はそのレスキュー公開鍵と対応する私有鍵、下位装置認証用レスキュールート鍵証明書は、下位装置認証用レスキュールート鍵に自身を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。
【００４３】
しかし、正規認証情報と大きく異なる点は、レスキュー公開鍵証明書は、プライベート認証局によって発行された公開鍵証明書である点である。プライベート認証局とは、特に世間に広く信頼性が認められているわけではなく、発行する証明書が一般的に通用するわけではない認証局を指す。また、証明書の利用者が運営する認証局であり、例えば、自社内で利用する証明書を管理するためにその企業が運営する認証局である。
このような認証局が発行する証明書は、通常はパブリック認証局が発行する証明書よりも信頼性が低いと考えられるが、プライベート認証局は、安全性と利便性を考慮して設置者が独自のポリシーにより運営することができるため、用途に適合した証明書を発行し易いという利点もある。また、プライベート認証局であっても、安全性に配慮すれば、比較的安全性の高い証明書を提供することも可能である。
【００４４】
ここで、図７に通常公開鍵証明書の例を、図８にレスキュー公開鍵証明書の例を示す。
これらは、符号Ｆ及びＩで示すように、発行先の装置の識別情報が同一であり、同じ装置に対して発行された公開鍵証明書である。しかし、証明書の発行者は、通常公開鍵証明書については符号Ｄで示すようにＹＹＹ社の「ＰｕｂｌｉｃＣＡ」としている一方、レスキュー公開鍵証明書については符号Ｇで示すようにＸＸＸ社の「ＰｒｉｖａｔｅＣＡ」というように、異なるＣＡとしている。「ＰｕｂｌｉｃＣＡ」はパブリック認証局、「ＰｒｉｖａｔｅＣＡ」はプライベート認証局に該当するものとする。またここでは、プライベート認証局は、発行先装置のメーカーであるＸＸＸ社が設けている。
そして、このようなレスキュー公開鍵証明書を含むレスキュー認証情報を用意し、レスキュー認証情報の内容を、輸出規制や、各地域で普及している認証処理の内容等を考慮しても下位装置２０が使用されると想定される種々の環境で共通に使用できるような認証処理により認証を行うことができるようなものにするとよい。
【００４５】
このようにすれば、通常公開鍵証明書を用いた認証が行えないような環境下でも、レスキュー公開鍵証明書により通信相手を認証することができる。そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができる。従って、この通信経路を利用して、通信時点の環境に適合した新しい通常公開鍵証明書を通信相手に送信し、設定させることが可能となる。
また、パブリック認証局の発行する公開鍵証明書では、厳格な管理や安全性が要求されるため、上記のように種々の環境で共通に使用できるような証明書を発行することが難しい場合もあるし、費用もかかる。しかし、プライベート認証局であれば、証明書の仕様を比較的自由に定められるので、暗号強度を低くしたり、最新であまり普及していない認証処理アルゴリズムを避けたりして、種々の環境で共通に使用できるような証明書を発行することも可能である。また、装置のメーカー自身がプライベート認証局を提供すれば、安価に証明書を発行することも可能である。さらに、例えば下位装置２０と上位装置１０でメーカーが異なったり、通信システムの運用者が種々にカスタマイズを行ったりするような場合でも、レスキュー公開鍵証明書を無償で提供する等して、これらのメーカーや運用者に、レスキュー公開鍵証明書を用いた認証に対応できるようにするよう働きかけることも容易となる。
【００４６】
なお、プライベート認証局が発行するレスキュー公開鍵証明書は、パブリック認証局が発行する通常公開鍵証明書と比べた場合に、安全性や信頼性が劣ることも考えられる。しかし、レスキュー認証情報を用いて認証処理を行った場合に、通常公開鍵証明書を始めとする正規認証情報の更新のような限られた要求のみ実行を許可するようにすれば、プライベート認証局が発行した証明書を利用するために若干安全性が低下したとしても、大きな問題にはならない。
【００４７】
ここで、図７及び図８の説明に戻ると、これらの２つの公開鍵証明書において、通常公開鍵証明書では、符号Ｅで示すように有効期間が２００３年１月１日午前０時から２００４年１月１日午前０時までの１年間である一方、レスキュー公開鍵証明書では、符号Ｈで示すように２０００年１月１日午前０時から２０５０年１月１日午前０時までの５０年間としている。
すなわち、通常公開鍵証明書はパブリック認証局が発行するものであるから、装置の製造者や使用者が有効期間を自由に定めることができず、また安全性を考慮して有効期間が短く設定されているのが通常である。従って、有効期間内に証明書を更新する必要がある。そして、証明書の更新を自動で行う必要があるような装置においては、上述のように更新期限の徒過や更新時の異常による証明書の破損の危険がある。
【００４８】
一方で、レスキュー認証情報を、通常公開鍵証明書による認証が行えなくなった場合に非常用の通信経路を確保するための認証情報であると位置付けるならば、レスキュー公開鍵証明書の有効期間経過後にはレスキュー公開鍵証明書を更新する必要が生じてしまうので、レスキュー公開鍵証明書の有効期間は長い方が好ましい。具体的には、例えば記憶させる装置の製品寿命よりも長い有効期間を設定するとよい。この製品寿命は、装置の想定運用期間あるいは想定動作期間であり、開発時に想定している使用期間や想定耐用年数、装置の品質保証期間等から定めることができる。
また、レスキュー公開鍵証明書の有効期間を、装置をメンテナンスしながら正常に動作させられると想定される期間よりも長く設定すれば、レスキュー公開鍵証明書は装置の動作中には有効期限が切れない証明書であるということができる。従って、装置の動作中は、常にレスキュー公開鍵証明書を用いた認証（レスキュー証明書セットを用いた認証）が可能な状態を保つことができる。また、レスキュー公開鍵証明書を更新する必要がないので、更新時の破損等を防止できる。
【００４９】
また、上記の製品寿命や装置の動作期間よりも極めて長い有効期間を定めるようにすれば、なおよい。図８示した例では、有効期間を５０年に設定しており、通常の装置であればこの程度で十分と考えられるが、これはＸ．５０９フォーマットに従って設定できる有効期間の最大が５０年であるためこのようにしただけで、さらに長い期間、例えば１００年や数百年を設定してもよいことはもちろんである。このように有効期間を定めた場合、有効期間の終期は、単に公開鍵証明書のフォーマット上の要求により記載したものであり、レスキュー公開鍵証明書の有効期限は事実上ないものと考えることができる。また、対象の装置によっては、２０年や３０年程度あるいはそれ以下の有効期間であっても、同様に考えることができる場合もある。
さらにまた、たとえレスキュー公開鍵証明書の有効期間が製品寿命より短かったとしても、通常公開鍵証明書の有効期間よりも長ければ、通常公開鍵証明書の有効期間経過後も一定の期間レスキュー公開鍵証明書を用いた認証が可能な状態を保つことができると共に、証明書の破損の危険性が低い安定した通信経路を用意できるという効果を得ることはできる。
なお、通常公開鍵証明書の有効期間については、安全性を考慮して適当な期間を定めればよいが、この期間は、製品寿命よりも短く、また装置の動作中に有効期限が切れるような期間となることが多い。
【００５０】
そして、プライベート認証局が発行するレスキュー公開鍵証明書では、有効期間は発行者が適宜定めればよいので、これらの要求に応えるような有効期間を定めることも可能である。また、有効期間の長い公開鍵証明書は、有効期間の短い公開鍵証明書と比べた場合には安全性が若干劣るものの、上述のように、レスキュー公開鍵証明書を用いて認証を行った場合に実行を許可する動作を制限することにより、この点は大きな問題にはならないようにすることができる。
また、このようなレスキュー公開鍵証明書により非常用の通信経路を確保できるようにしておけば、有効期間の短い通常証明書を使用する場合であっても、期限切れや更新時の破損等による不都合を最小限に留めることができ、人手での証明書更新が困難であり自動更新に頼らざるを得ないような装置であっても、信頼性の高いパブリック認証局が発行する証明書を有効に活用することができる。
【００５１】
ところで、サーバとして機能する下位装置２０は、ＳＳＬハンドシェイクの際に、通信を要求してきた相手を識別できないため、基本的には全ての相手に同一の公開鍵証明書を送信することになる。しかし、この通信システムにおいては状況に応じて通常公開鍵証明書とレスキュー公開鍵証明書とを使い分ける必要がある。そこで、次にこの使い分けのための構成について図９を用いて説明する。図９は、クライアントがサーバに通信を要求する際に通信先アドレスの指定に用いるＵＲＬ（Uniform Resource Locator）の例を示す図である。
【００５２】
この通信システムにおいては、下位装置２０が複数のアドレスで通信要求を受け付けるようにし、通信要求を受け付けたアドレスに応じた公開鍵証明書を提供するようにしている。例えば、「https://123.45.67.89:10000」なるＵＲＬ（通常処理ＵＲＬとする）が示す第１のアドレスで通信要求を受け付けた場合には下位装置用通常公開鍵証明書を要求元に送信し、「https://123.45.67.90:10001」なるＵＲＬ（レスキューＵＲＬとする）が示す第２のアドレスで通信要求を受け付けた場合には下位装置用レスキュー公開鍵証明書を送信する等である。
このようにしたことにより、１つの下位装置２０が通信要求を区別し、必要に応じた公開鍵証明書をＳＳＬハンドシェイクの処理に供することができる。
クライアントとして機能する上位装置１０の側では、下位装置２０のどのアドレスに対して通信要求を送ったかは当然わかるので、相互認証を行う場合にはアドレスに応じた適切な公開鍵証明書を選択して送信することができる。
【００５３】
なお、図９に示すように、ＵＲＬには、ホストを示す情報，そのホストのポートを示す情報，ＵＲＬパスを示す情報が含まれる。そして、ＵＲＬパスを示す情報は、図３に符号４１で示したように、ＳＳＬハンドシェイクが成功した場合に送信する、ＳＯＡＰメッセージ含むＨＴＴＰリクエストに含まれるものであるから、ＳＳＬハンドシェイクの処理では参照することができない。従って、通信要求の受け口を区別するためのアドレスをＵＲＬで表現する場合には、ホストを示す情報であるＩＰ（Internet Protocol）アドレスと、そのホストのポートを示すポート番号との組み合わせによって区別することになる。もちろん、ＩＰアドレスとポート番号のうち一方のみによって区別するようにすることも考えられる。このようにする場合、他方については共通の情報を使用することができる。
【００５４】
このように、この通信システムにおいては、上位装置１０と下位装置２０との間で基本的には通常公開鍵証明書を用いた認証を行いながら、これが破損等して使用不能になった場合にも、レスキュー公開鍵証明書を用いた認証を行い、安全な通信経路を確保することができる。レスキュー公開鍵証明書を用いた認証であっても、共通鍵の交換は通常公開鍵証明書の場合と同様に可能であるためである。そして、この通信経路を用いて上位装置１０から下位装置２０に更新用の正規認証情報を送信して記憶させることにより、再度正規認証情報を用いた認証が可能な状態に復帰させることができる。
【００５５】
以上のように、この通信システムにおいては、正規認証情報に加えてレスキュー認証情報も使用することにより、正常な認証を受けられる状態を容易に維持できるようにすることができる。しかしながら、上述したように、レスキュー公開鍵証明書を始めとするレスキュー認証情報を、プライベート認証局が非常用の通信経路の確保に好適な条件で発行するものとすると、正規認証情報と比べて安全性が若干劣ることが考えられる。
そこで、この影響を最低限に抑えるため、この通信システムにおいては、レスキュー公開鍵証明書を用いてＳＳＬハンドシェイクを行った場合に実行できる機能をできるだけ制限するようにしている。そして、新たな通常公開鍵証明書を下位装置２０に記憶させれば、再度通常公開鍵証明書を用いたＳＳＬハンドシェイクが可能になることから、レスキュー公開鍵証明書を用いた場合には、新たな通常公開鍵証明書を下位装置２０に記憶させるための処理のみを許可すれば足りる。
【００５６】
従って、この通信システムにおいては、レスキュー公開鍵証明書を用いてＳＳＬハンドシェイクを行うレスキューＵＲＬで通信を行った場合に、下位装置２０において通常公開鍵証明書の設定に関する処理以外の処理を禁止するようにすることにより、レスキュー公開鍵証明書を使用することによる効果を十分維持しながら、高いセキュリティを実現することができるようにしている。この点がこの実施形態の特徴である。
【００５７】
次に、このような特徴を実現するためのこの通信システムの構成及び運用方式の概略について図１０を用いて説明する。図１０は、その構成及び運用方式について説明するための図である。
この通信システムにおいては、通常時には、（ａ）に示すように上位装置１０が下位装置２０の通常処理ＵＲＬに通信要求を行い、通常公開鍵証明書を用いた認証が成功した場合に下位装置２０に対して要求を送信して各種機能を利用する。
【００５８】
詳細は後述するが、このとき下位装置２０において、ＨＴＴＰによる通信を制御するＨＴＴＰデーモンが要求のＨＴＴＰリクエストを受け付け、第１振り分け部４１０がそのＨＴＴＰリクエストを受信したＵＲＬに応じて要求を第２振り分け部４２１，４２２のいずれかに振り分ける。ここでは、通常処理ＵＲＬで受信しているので、通常処理ＵＲＬ用第２振り分け部４２１に振り分ける。
そして、通常処理ＵＲＬ用第２振り分け部４２１が要求の種類と対応する機能に要求に係る処理を振り分けてこれを実行させ、以後逆の経路で上位装置１０に対して応答のＨＴＴＰレスポンスを返す。このような処理によって、下位装置２０は上位装置１０からの要求に応じた動作を行う。そして要求を通常処理ＵＲＬで受信した場合には、要求に応じた動作に特に制限は設けない。
【００５９】
なお、通常処理ＵＲＬで通信を行う場合の認証に用いる通常公開鍵証明書は、下位装置２０の識別情報を含むため、この証明書を用いてＳＳＬハンドシェイクを行えば、この処理内で通信相手を特定できる。
従って、ＳＳＬハンドシェイク後に別のコマンドによって識別情報を取得する場合に比べ、通信相手の「なりすまし」を効果的に防止することができる。また、万一私有鍵が漏洩したとしても、これを不正に取得した第３者は、私有鍵の発行対象の装置にしかなりすますことができず、またその装置の鍵を更新してしまえばこのような「なりすまし」も防止できるため、通信の高い安全性を得ることができる。
また、上位装置１０が下位装置２０を管理する場合においては、通常公開鍵証明書に含まれる識別情報によって管理対象の装置を識別して管理動作を行うことができるので、別途識別情報を取得する場合に比べ、管理動作を単純な処理で円滑に行うことができる。
【００６０】
ところが、下位装置２０が設定されている通常公開鍵証明書による認証で対応できない環境下に置かれたり、通常公開鍵証明書が破損や有効期限切れ等により使用できなくなってしまった場合には、上位装置１０が正当性を確認できる通常公開鍵証明書を送信できないため、（ｂ）に示すように認証処理が失敗する。そして、この場合にはこのままでは上位装置１０は下位装置２０の機能を利用することができない。そこで、レスキューＵＲＬに通信要求を行い、レスキュー公開鍵証明書を用いた認証を行う。そして、これが成功した場合には、下位装置２０に通常証明書設定要求を行い、証明書設定用機能を利用して通常公開鍵証明書を更新させる。
なお、要求をレスキューＵＲＬで受信した場合には、要求は第１振り分け部４１０からレスキューＵＲＬ用第２振り分け部４２２に振り分けられる。そして、レスキューＵＲＬ用第２振り分け部４２２が要求の種類と対応する機能に要求に係る処理を振り分けてこれを実行させるのであるが、このとき、通常公開鍵証明書の設定に関する要求のみを振り分け、それ以外の要求は振り分けないようにしている。従ってこの場合には、通常公開鍵証明書の設定に関する要求以外の要求に係る処理は禁止するようにしていることになる。
【００６１】
そして、このような処理を行い、正常な通常公開鍵証明書を下位装置２０に設定することができれば、再度（ａ）に示したように通常処理ＵＲＬでの通信が可能になる。
従って、下位装置２０が設定されている通常公開鍵証明書による認証で対応できない環境下に置かれたり、通常公開鍵証明書が破損や有効期限切れ等により使用できなくなってしまった場合でも、レスキュー公開鍵証明書が利用可能な環境下であれば、速やかに正常な状態に復帰させ、通常公開鍵証明書を用いた認証が可能な状態を維持することができる。つまり、下位装置２０が正常な認証を受けられる状態を維持することができる。そして、これらの処理に人手を介す必要はなく、容易にこのような効果を得ることができる。
【００６２】
なお実際には、上位装置１０は、この上記の通常公開鍵証明書の更新の際に、下位装置２０から識別情報を取得し、これを図示しないパブリックＣＡに送信し、この識別情報の装置の証明書を発行させてこれを取得し、これを証明書設定要求と共に下位装置２０に送信して記憶させるという処理手順を踏むことになる。なお、このパブリックＣＡは、上位装置１０が行う認証処理で使用可能な証明書を発行するパブリックＣＡであり、下位装置２０がそれまでに記憶していた通常公開鍵証明書を発行したパブリックＣＡとは異なるものであってもよい。
【００６３】
また、下位装置２０に記憶させる通常公開鍵証明書を発行する場合において、その中の公開鍵本体や対応する私有鍵については、新たに生成してもよいが、ＣＡが過去に下位装置２０に対して発行した鍵を管理しているのであれば、その鍵をそのまま使うようにしてもよい。また、更新用の証明書を発行する際に、ルート私有鍵を新たに発行し、公開鍵証明書のバージョンアップを行うようにすることも考えられる。
また、パブリックＣＡが発行する公開鍵証明書を利用する場合には、上位装置１０からパブリックＣＡに対して直接証明書の発行を依頼し、証明書の管理もそのＣＡに任せてしまうよりは、発行された証明書を管理する機能を上位装置１０に設けたり、上位装置１０が間に発行された証明書を管理する装置を介してＣＡに証明書の発行を依頼するような構成が好ましい。
【００６４】
次に、下位装置２０において上記の処理を実現するための機能構成について図１１を用いて説明する。図１１は、上位装置１０から受信した要求の内容に応じた動作を実行して応答を返すための、下位装置２０における機能構成を示す機能ブロック図である。なお、以下の説明に登場する各部や各機能は、ＣＰＵが適当なソフトウェアを実行することによって実現されるものである。
【００６５】
図１１に示すように、下位装置２０は、ＨＴＴＰデーモン３３１，第１振り分け部４１０、通常処理ＵＲＬ用第２振り分け部４２１，レスキューＵＲＬ用第２振り分け部４２２，および各種機能３８０を有する。そして、各種機能３８０は、固有情報取得機能３８１や証明書設定機能３８７を含む。これらの各部や各機能は、図１０に示した各部や各機能と対応するものである。
【００６６】
これらの各部のうち、まず、ＨＴＴＰデーモン３３１は、ＨＴＴＰによる通信を制御すると共に、ＳＳＬハンドシェイクの処理を実行する。そして、ＳＳＬハンドシェイクが成功した後で受信したＨＴＴＰリクエストを、受信したＵＲＬの情報と共に第１振り分け部４１０に渡す機能を有する。なお、このＵＲＬは、ＨＴＴＰリクエストを受信する際のＴＣＰ（Transmission Control Protocol）接続要求によって認識することができる。そして、このＨＴＴＰデーモン３３１が通信手段の機能を実現する。
【００６７】
なお、ここでは第１振り分け部４１０は１つしか図示していないが、下位装置２０において、複数のアプリケーション（アプリ）が各種機能を提供するようにし、アプリ毎にそのアプリが提供する機能に対する要求の振り分けを行うための第１振り分け部を設けてもよい。この場合、ＨＴＴＰデーモン３３１がＨＴＴＰリクエストを各リクエストに含まれるＵＲＬパスに応じて各第１振り分け部に振り分けることになる。
【００６８】
第１振り分け部４１０は、ＨＴＴＰデーモン３３１がＨＴＴＰリクエストとして受信したＳＯＡＰメッセージによる要求（コマンド）を、その要求を受信したＵＲＬに応じて、各第２振り分け部４２１，４２２に振り分ける機能を有する。ここでは、下位装置２０は図１２に示すように第１振り分け部４１０による要求の振り分け先をＵＲＬ毎に示したテーブルを記憶しており、第１振り分け部４１０はこれを参照して振り分け先を決定する。従って、ここでは通常処理ＵＲＬで受け付けた要求は通常処理ＵＲＬ用第２振り分け部４２１に、レスキューＵＲＬで受け付けた要求はレスキューＵＲＬ用第２振り分け部４２２に振り分けることになる。
【００６９】
そして、これらの各第２振り分け部４２１，４２２は、ＸＭＬプロセッサを備え、要求に係るＨＴＴＰリクエストのうちのＨＴＭＬボディのＸＭＬの構文を解析し、ＸＭＬで記述されるタグ間の関連をツリー構造で示すＤＯＭ（Document Object Model）ツリー形式のデータに変換する機能を有する。このＤＯＭツリー形式のデータは、要求のメッセージの構成を示す構成データ形式のデータであり、この場合下位装置２０の各第２振り分け部４２１，４２２がメッセージ変換手段としての機能を有する。
また、各第２振り分け部４２１，４２２は、ＸＭＬシリアライザも備え、逆にＤＯＭツリー形式のデータをＸＭＬ形式のデータに変換する機能も有する。
【００７０】
さらに、各第２振り分け部４２１，４２２は、生成したＤＯＭツリー形式のデータを解析して要求の種類のデータを取り出し、各種機能３８０のうちそのデータに応じた機能に、ＨＴＴＰリクエストのヘッダ情報をまとめたＨＴＴＰヘッダ情報と共に、上記のＤＯＭ形式のデータを振り分けて、要求に関する処理を依頼する第２の振り分け手段として機能を有する。
【００７１】
ここで、この振り分けの規則は、通常処理ＵＲＬ用第２振り分け部４２１とレスキューＵＲＬ用第２振り分け部４２２とで異なるが、この点については後述する。
また要求の種類のデータとしては、例えば、ＤＯＭツリーのうち、ＳＯＡＰボディーを示す「Ｂｏｄｙ」ノードの子ノードの名称が考えられる。また、要求に係るＨＴＴＰリクエストのＳＯＡＰＡｃｔｉｏｎヘッダに含まれるＵＲＩ（Uniform Resource Identifiers）を用いるようにしてもよい。この情報は、上述のＨＴＴＰヘッダ情報に含まれるものである。
【００７２】
また、各種機能３８０は要求実行手段に該当し、ここに含まれる各機能は、各々が要求処理手段であり、受信した要求に応じた処理を行うためのソフトウェアによって提供される機能である。そして、通常処理ＵＲＬ用第２振り分け部４２１又はレスキューＵＲＬ用第２振り分け部４２２によって起動され、受け取ったデータに従ってロジックを実行し、その結果を処理の依頼元の第２振り分け部に返す処理を行う。
【００７３】
また、各第２振り分け部４２１，４２２から渡されたＤＯＭツリー形式のデータを解析し、これを、各種機能３８０に含まれる各機能のロジックを記述したプログラム言語で処理可能なデータ形式に変換する機能や、プログラムの実行結果である結果データを、ＤＯＭツリー形式のデータに変換する機能も有する。なお、ここでは各種機能３８０に含まれる各機能のロジックはＣ言語で記載されているものとし、このデータ形式はＣ言語の構造体データであるものとする。
このような各種機能３８０について、図では固有情報取得機能３８１と証明書設定機能３８７以外は具体的な内容を示していないが、各機能は要求の種類に対応して設けられる。
【００７４】
例えば、固有情報取得機能３８１に分類される機能としては、ＩＤ（機番），モデル名，ファームウェアのバージョン，オプション構成，証明書のバージョン等の下位装置２０に固有な情報（識別情報を含む）の取得のようなものが挙げられるが、これらの機能の実行を指示するために別々の要求を用意するのであれば、これらの要求の実行に係るソフトウェアは、別々にコールされるプログラムとして設けるようにしている。
なお、証明書設定機能の提供する機能は、通常公開鍵証明書の設定である。ただし、この設定は、この下位装置２０では正規認証情報を構成する証明書セット全体を設定して行われる。
【００７５】
また、各種機能３８０に含まれる他の機能としては、例えば要求元に下位装置２０の状態の情報を取得させる状態取得機能、同じくログ情報を取得させるログ情報取得機能、同じく設定値の情報を取得させる設定値情報取得機能、下位装置２０の設定値を変更させる設定値変更機能、下位装置２０の調整動作を行わせる調整実行機能等が考えられるが、どのような機能を設けるかは、下位装置２０の構成や、上位装置１０との関係に応じて適宜に定めればよい。
また、図示はしていないが、下位装置２０が実行する複数のアプリが、それぞれアプリの機能に応じて各種機能３８０のような機能セットを提供するようにしてもよい。
【００７６】
ところで、この下位装置２０においては、通常処理ＵＲＬ用第２振り分け部４２１は、対応する機能がある全ての要求をその機能に振り分ける。しかし、レスキューＵＲＬ用第２振り分け部４２２は、図１１に太線で示したように、通常公開鍵証明書の設定に関する要求のみしか機能に振り分けない。そして、その他の要求を受け付けた場合には、対応する機能がないものとして応答を返す。
そしてここでは、通常公開鍵証明書の設定に関する要求は、通常公開鍵証明書の作成（情報の記載も含む）に必要な情報の取得要求と、通常公開鍵証明書の設定要求としており、これらに対応する機能は、固有情報取得機能３８１のうちＩＤ，モデル名及び証明書のバージョン情報の取得に係る機能と、証明書設定機能３８７としている。しかし、さらに他の要求も通常公開鍵証明書の設定に関する要求として取り扱ったり、逆にこれらの情報の取得要求を公開鍵証明書の設定に関する要求として取り扱わないようにすることも考えられる。具体的にどのような要求を通常公開鍵証明書の設定に関する要求として取り扱うかは、最終的にはシステムの設計者が適宜定めればよい。
【００７７】
このような振り分けは、図１３に示したように、第２振り分け部毎に要求の種類と振り分け先とのテーブルを設け、各第２振り分け部が自己と対応するテーブルを参照して振り分けを行うようにすることにより、実現することができる。テーブルに記載されていない要求については、対応する機能がないものとして取り扱うようにすればよい。
このようにしたことにより、下位装置２０が通常処理ＵＲＬから要求を受信した場合には全ての要求に係る処理が許可される一方、レスキューＵＲＬから要求を受信した場合には、その要求は第１振り分け部４１０からレスキューＵＲＬ用第２振り分け部４２２に届くものの、通常公開鍵証明書の設定に関する要求以外の処理は機能に振り分けられず、結果的に処理が禁止されることになる。そして、第１振り分け部４１０とレスキューＵＲＬ用第２振り分け部４２２とで禁止手段の機能が実現される。
なお、他のアプリへの要求に係る処理も禁止するためには、レスキューＵＲＬで要求を受信した場合にＨＴＴＰデーモン３３１がその要求を通常公開鍵証明書の設定を行うアプリ以外には渡さないようにすればよい。また、アプリ毎に通常処理ＵＲＬ用第２振り分け部とレスキューＵＲＬ用第２振り分け部とを設け、後者が各機能への振り分けを全く行わないようにしてもよい。
【００７８】
以上のような禁止手段により、レスキュー公開鍵証明書を用いてＳＳＬハンドシェイクを行うレスキューＵＲＬで通信を行った場合に、通常公開鍵証明書の設定に関する処理以外の処理を禁止するようにすることができる。そして、このことにより、レスキュー公開鍵証明書を使用することによる効果を十分維持しながら、レスキュー公開鍵証明書や対応する私有鍵等が万一漏洩した場合の影響を最低限に抑え、高いセキュリティを実現することができる。
【００７９】
次に、図１１に示した構成を有する下位装置２０において実行される処理について、図１４及び図１５を用いて説明する。図１４は、下位装置２０が通信要求を受け付けた場合に行う処理を示すフローチャート、図１５はその続きの処理を示すフローチャートである。これらの処理は、この発明の通信装置の制御方法に係る処理である。そしてここでは、説明を簡単にするため、通信相手が下位装置２０を認証するのみの、図２６に示したような片方向認証を行う場合の処理を示している。しかし、図２４に示したような双方向認証を行うようにしてもよいことはもちろんである。
【００８０】
下位装置２０のＣＰＵは、ＨＴＴＰデーモン３３１を常に実行しており、これが他の装置からの通信要求を受け付けると、図１４のフローチャートに示す処理を開始する。
この処理においては、まずステップＳ１０１で、通信要求を受け付けたＵＲＬが通常処理ＵＲＬであるか否か判断する。そして通常処理ＵＲＬであれば、ステップＳ１０２に進んで、下位装置用通常公開鍵証明書を下位装置用通常私有鍵で暗号化した第１の乱数と共に通信相手（通信要求の要求元）に送信して認証を要求する。すなわち、この場合には通信相手に対して通常公開鍵証明書を提供する。この処理は、図２６のステップＳ２１及びＳ２２の処理に相当する。
【００８１】
その後、ステップＳ１０６に進んで通信相手からの応答を待ち、認証されなかった場合には以後の通信を許可せずにそのまま終了するが、通信相手に認証された場合には、ステップＳ１０７に進み、認証処理において受信した共通鍵の種から共通鍵を作成する。これらの処理は、図２６のステップＳ２５及びＳ２６の処理に相当する。
そして、ステップＳ１０８で通信相手からのＨＴＴＰリクエストによる要求の受信を待ち、受信するとステップＳ１０９に進んで、その要求を、受信したＵＲＬの情報と共に第１振り分け部４１０に渡す。ここまでの処理が、ＨＴＴＰデーモン３３１による処理である。
【００８２】
また、ステップＳ１０１で通常処理ＵＲＬでなかった場合には、ステップＳ１０３に進んで通信要求を受け付けたＵＲＬがレスキューＵＲＬであるか否か判断する。そしてレスキューＵＲＬであれば、ステップＳ１０４に進んで、下位装置用レスキュー公開鍵証明書を下位装置用レスキュー私有鍵で暗号化した第１の乱数と共に通信相手に送信して認証を要求する。すなわち、この場合には通信相手に対してレスキュー公開鍵証明書を提供する。この処理も、図２６のステップＳ２１及びＳ２２の処理に相当する。
そして、ステップＳ１０６以下に進み、ステップＳ１０９までは通常公開鍵証明書を提供した場合と同様な処理を行う。また、ステップＳ１０３でレスキューＵＲＬでない場合には、通信を受け付けていないＵＲＬへの通信要求であるので、ステップＳ１０５でエラー処理を行って処理を終了する。
【００８３】
次にステップＳ１１０以降の処理について説明する。
ステップＳ１０９で要求を渡された第１振り分け部４１０は、図１２に示したようなテーブルを参照し、受信したＵＲＬに応じて振り分け先を決定する。そしてここでは、通常処理ＵＲＬで受信した要求はステップＳ１１１で通常処理ＵＲＬ用第２振り分け部４２１に渡し、レスキューＵＲＬで受信した要求はステップＳ１１２でレスキューＵＲＬ用第２振り分け部４２２に渡す。
ステップＳ１１１及びＳ１１２の後は、それぞれ図１５のステップＳ１１３及びＳ１１６に進み、第２振り分け部が、ＨＴＴＰリクエストとして受信した要求のＨＴＭＬボディーに当たるＳＯＡＰエンベロープを解析し、その構成を示すＤＯＭツリー形式のデータを作成する。この処理は、どちらの第２振り分け部でも同様に行う。
【００８４】
そしてその後、それぞれステップＳ１１４及びＳ１１７に進み、第２振り分け部が各種機能３８０中の要求の種類に応じた機能に要求を振り分けてその要求に係る処理を依頼する。このとき、要求はＨＴＴＰヘッダ情報及びＤＯＭツリー形式のデータとして機能に渡す。また、通常処理ＵＲＬ用第２振り分け部４２１は、各種機能３８０のどの機能に対しても振り分けを行うが、レスキューＵＲＬ用第２振り分け部４２２は、通常公開鍵証明書の設定に関する要求のみを振り分ける。この振り分けは、図１３に示したように、２つの第２振り分け部で、要求の種類と振り分け先の機能との対応関係を示したテーブルについて異なるものを使用すれば、処理の手順自体は同じものにすることができる。
この振り分けの後、それぞれステップＳ１１５及びＳ１１８に進み、振り分けが成功したか否か、すなわちテーブルに要求の種類と対応する振り分け先が存在したか否か判断する。そして、成功していれば、どちらのステップの場合もステップＳ１１９に進む。
【００８５】
次のステップＳ１１９では、要求を振り分けられた機能が、要求のＤＯＭツリーを解析して、そこに含まれるパラメータをＣ言語の構造体データに変換する。そして、ステップＳ１２０で機能のロジックを実行し、結果を構造体データとして生成する。その後、ステップＳ１２１でその構造体データをＤＯＭツリーに変換して、レスポンスとして第２振り分け部に返す。このとき、結果は機能に対して要求を振り分けた第２振り分け部に返す。
そして、これを受け取った第２振り分け部は、ステップＳ１２２でそのＤＯＭツリーを図示しないＸＭＬシリアライザによってＸＭＬ形式のＳＯＡＰメッセージによるレスポンスデータに変換し、ＨＴＴＰデーモン３３１によってＨＴＴＰレスポンスとして要求の送信元に返して処理を終了する。
【００８６】
一方、ステップＳ１１５又はＳ１１８で振り分けが失敗していた場合には、振り分けを試みた第２振り分け部は、ステップＳ１２３でその種類の要求をサポートしていない旨のエラー情報（ＳＯＡＰ  Ｆａｕｌｔ）のＤＯＭツリーを生成し、ステップＳ１２４でＸＭＬ形式のレスポンスデータに変換して、これをＨＴＴＰデーモン３３１によってＨＴＴＰレスポンスとして要求の送信元に返して処理を終了する。
なお、第２振り分け部を通常処理ＵＲＬ用とレスキューＵＲＬ用で区別する必要があるのは、要求を機能に振り分ける手順までであり、応答を返す処理においては通常処理ＵＲＬ用とレスキューＵＲＬ用の機能は全く同じである。従って、ステップＳ１１９以降ではこれらを区別せずに示している。
【００８７】
次に、図１４及び図１５のフローチャートに示した処理による処理シーケンスの例について、図１６を用いて説明する。図１６は、この処理シーケンスを示すシーケンス図であり、下位装置２０が通常処理ＵＲＬで要求を受け付けた場合の処理を示している。
この例においては、ＳＳＬハンドシェイクの処理は図示を省略しているが、その後上位装置１０が下位装置２０の通常処理ＵＲＬに要求をＨＴＴＰリクエストとして送信すると、ＨＴＴＰデーモン３３１がこれを受け付ける（Ｓ２０１）。この要求はＳＯＡＰメッセージとして記載されており、ＨＴＴＰデーモン３３１は受信した要求を受信したＵＲＬを示す情報（例えばＩＰアドレスとポート番号）と共に第１振り分け部４１０に渡して振り分け処理を依頼する（Ｓ２０２）。
【００８８】
そして第１振り分け部４１０は、その情報を基に図１２に示したようなテーブルを参照し、要求を受信したＵＲＬに応じて要求の振り分け先を決定する（Ｓ２０３）。そして、ここではＵＲＬは通常処理ＵＲＬであり、振り分け先は通常処理ＵＲＬ用第２振り分け部４２１であるので、ここに要求を振り分けてその後の処理を依頼する（Ｓ２０４）。これを受けた通常処理ＵＲＬ用第２振り分け部４２１は、要求のＳＯＡＰメッセージをＤＯＭツリー形式のデータに変換し（Ｓ２０５）、要求の種類に応じて振り分け先を決定し（Ｓ２０６）、振り分け先となる機能３８ｘにＤＯＭツリー形式のデータを渡して処理を依頼する（Ｓ２０７）。
【００８９】
そして、その機能３８ｘがＤＯＭツリー形式のデータをロジックにより処理できる構造体データに変換し（Ｓ２０８）、これを引数としてロジックを実行して要求に係る処理を行い（Ｓ２０９）、処理結果の構造体データをＤＯＭツリー形式のデータに変換し（Ｓ２１０）、処理を依頼してきた通常処理ＵＲＬ用第２振り分け部４２１にそのデータを渡す（Ｓ２１１）。
そして、このデータを受け取った通常処理ＵＲＬ用第２振り分け部４２１は、これを応答のＳＯＡＰメッセージに変換し（Ｓ２１２）、ＨＴＴＰデーモン３３１を介して上位装置１０にＨＴＴＰレスポンスとして送信する（Ｓ２１３，Ｓ２１４）。
以上が通常処理ＵＲＬで要求を受け付けた場合の処理である。
【００９０】
そして、レスキューＵＲＬで要求を受け付けた場合にも、ほぼ同様な処理が行われるが、第１振り分け部４１０による振り分け先がレスキューＵＲＬ用第２振り分け部４２２となる。そして、レスキューＵＲＬ用第２振り分け部４２２は通常公開鍵証明書の設定に関する要求のみを機能３８ｘに振り分け、それ以外の要求は振り分け先がないものとして処理する。従って、通常処理ＵＲＬで要求を受け付けた場合とレスキューＵＲＬで要求を受け付けた場合とでほぼ同様な手順の処理を行いながら、結果的に、レスキューＵＲＬで要求を受け付けた場合には通常公開鍵証明書の設定に関する要求以外の要求に係る処理を禁止することができる。
【００９１】
次に、上位装置１０から下位装置２０へ送信する要求のＨＴＴＰリクエスト及び下位装置２０から上位装置１０へ返す応答のＨＴＴＰレスポンスの例について図１７乃至図２０を用いて説明する。
まず、図１７に上位装置１０から下位装置２０のレスキューＵＲＬに送信する証明書設定要求のＨＴＴＰリクエストの例を示す。
このＨＴＴＰリクエストは、上述したように、ＳＯＡＰに従ったＳＯＡＰメッセージであり、ＨＴＴＰヘッダの最後にＳＯＡＰＡｃｔｉｏｎヘッダ６１を付してある。そして、それ以後の内容がＳＯＡＰエンベロープであり、ここに含まれるＳＯＡＰボディ中に要求の内容を記載している。ここでは、Ｂｏｄｙのすぐ下位の符号６２で示す要素に、要求が証明書設定要求であることを示す情報を記載している。そして、その下位に、証明書のバージョンを示すパラメータ６３、証明書の暗号化パスワードを示すパラメータ６４、設定すべき証明書を暗号化してＢａｓｅ６４エンコードしたデータを示すパラメータ６５を記載している。そして、要求の種類は、要素６２あるいはＳＯＡＰＡｃｔｉｏｎヘッダ６１の末尾を参照すればわかり、第２振り分け部は、この情報に従って機能への振り分け処理を行う。
【００９２】
図１８にこのようなＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示す。
このＨＴＴＰレスポンスも、ＳＯＡＰメッセージであり、ＨＴＴＰヘッダとＳＯＡＰエンベロープとからなる。そして、ＳＯＡＰボディー中に、実行した要求の種類を要素７１として、その実行結果が「成功」である旨を要素７２として示している。更新を試みることはできたものの失敗した場合には、要素７２の内容が「ＮＧ」になる。
【００９３】
また、図１９に、上位装置１０から下位装置２０のレスキューＵＲＬに送信する別のＨＴＴＰリクエストの例を示す。
このＨＴＴＰリクエストも、ＳＯＡＰメッセージであり、状態取得要求を行うものである。そして、図１７の場合とは要求の種類が異なることに伴い、ＳＯＡＰＡｃｔｉｏｎヘッダ８１の末尾と、ＳＯＡＰボディーの内容が図１７に示した例と異なる。ここでは、ＳＯＡＰボディーの下位には要求が状態取得要求であることを示す要素８２のみを記載し、その他のパラメータは記載していない。
【００９４】
図２０にこのようなＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示すが、状態取得要求は、レスキューＵＲＬで受信した場合には機能に振り分けない要求であるので、このようなコマンドは存在しない旨の応答が、ＳＯＡＰ  Ｆａｕｌｔとして返されることになる。そして、ＳＯＡＰボディー中に要素９１としてその旨を示す情報を記載している。
【００９５】
以上説明してきたような通信システムによれば、通常公開鍵証明書が破損や有効期限切れ等により使用できなくなった場合でも、レスキュー公開鍵証明書を用いた認証が成功した場合にネットワークを介してこれを設定できるようにしているので、下位装置２０が常に正常な認証を受けられる状態を維持できる。そして、この処理に人手を介す必要はなく、容易にこのような効果を得ることができる。また、レスキュー公開鍵証明書を用いてＳＳＬハンドシェイクを行うレスキューＵＲＬで通信を行った場合に、通常公開鍵証明書の設定に関する処理以外の処理を禁止するようにしているので、レスキュー公開鍵証明書を使用することによる効果を十分維持しながら、レスキュー公開鍵証明書や対応する私有鍵等が万一漏洩した場合の影響を最低限に抑え、高いセキュリティを実現することができる。
【００９６】
また、プライベート認証局が発行したレスキュー公開鍵証明書は、パブリック認証局が発行した通常公開鍵証明書と比べた場合には世間一般での信頼性が若干劣るが、相当程度の安全性は確保できる。そして、このような証明書を用意しておくことにより、設定されている通常公開鍵証明書による認証で対応できない環境下に置かれたり、通常公開鍵証明書が破損や有効期限切れ等により使用できなくなってしまった場合でも、レスキュー公開鍵証明書が利用可能な環境下であれば、共通鍵暗号を用いた安全な通信経路を確保できるという効果がある。そして、プライベート認証局であれば、広汎な環境下で利用可能であり、かつ有効期限が長く期限切れが起こらず、更新を不要として更新時の破損を防止できるようなレスキュー公開鍵証明書を発行することができる。
なお、通常公開鍵証明書の設定の際には下位装置２０と上位装置１０との間で相互認証を行うようにすれば、下位装置２０が不適当な装置から通常公開鍵証明書を受信して記憶してしまうことを防止でき、さらに通信の安全性を向上させることができる。
【００９７】
〔変形例：図２１，図２２〕
次に、上述した実施形態の変形例について説明する。
まず、図２１に下位装置２０の機能構成の変形例を示す。
上述した実施形態においては、上位装置１０から受信した要求の内容に応じた動作を実行して応答を返すための下位装置２０の機能構成が図１１に示すものである例について説明したが、これを図２１に示すものにしてもよい。すなわち、仲介デーモン３３２とＨＴＴＰ接続管理部３４２とＨＴＴＰサービス実行部３４３とを設けるようにしてもよい。
【００９８】
この場合、第１振り分け部４１０とＨＴＴＰデーモン３３１との間のデータの受け渡しをＨＴＴＰサービス実行部３４３を介して行い、さらにＨＴＴＰサービス実行部３４３は、各種機能３８０が提供する機能に関する動作要求を含むと考えられるＰＯＳＴメソッドのみを第１振り分け部４１０に渡すようにする。また、仲介デーモン３３２はＨＴＴＰデーモン３３１から通信の接続、切断に関する通知を受けてＨＴＴＰ接続管理部３４２にこれを伝え、ＨＴＴＰ接続管理部３４２はこの通知に応じてＨＴＴＰサービス実行部３４３にＨＴＴＰデーモン３３１からＨＴＴＰリクエストを取得させる。
このような構成とし、ＨＴＴＰサービス実行部３４３に対応するスレッドを複数備えることによって、上位装置１０からの複数の要求を単一のアプリ（プロセス）で平行処理することが可能になり、上位装置１０に対する応答性能を向上させることができる。本件の出願人は、このような技術に関し、過去に特許出願を行っている（特願２００３−８１２４６）。
【００９９】
またここでは、第２振り分け部を複数設け、第１振り分け部４１０が受信したＵＲＬに従って要求を適当な第２振り分け部に振り分ける例について説明した。
しかしながら、例えば第２振り分け部を１つだけ設け、第２振り分け部に第１振り分け部４１０の機能を併せ持たせ、１つの第２振り分け部が、受信したＵＲＬと要求の種類との両方に従って各機能に要求を振り分けるようにすることも可能である。この場合には、例えば図２２に示すような、受信したＵＲＬと要求の種類の組み合わせ毎に要求の振り分け先を定めたテーブルを記憶しておき、これを参照して振り分け先の機能にＨＴＴＰヘッダ情報及びＤＯＭツリー形式のデータを振り分けるようにすればよい。
このようにすれば、プログラムモジュールの点数を削減することができる。ただし、図１１に示した実施形態の構成であれば、ＵＲＬの情報を第２振り分け部から先に渡す必要がないため、モジュール間インタフェースの簡略化という点では図１１に示した構成の方が優れていると言える。
【０１００】
また、ここでは各機能にＤＯＭツリーを構造体データに変換したり構造体データをＤＯＭツリーに変換したりする機能を設ける例について説明したが、各機能とは別に、このような変換を行うハンドラを設けるようにしてもよい。このようなすれば、各機能には、その機能のプログラムが直接処理できる形式でデータを渡すことができるので、各機能のプログラムを、ＳＯＡＰやＸＭＬの知識がなくても開発できるようにすることができる。
また、ここでは第２振り分け部にＸＭＬで記載されたＳＯＡＰメッセージをＤＯＭツリーに変換したりＤＯＭツリーをＳＯＡＰメッセージに変換したりする機能を設ける例について説明したが、このようにすることも必須ではない。ＳＯＡＰメッセージを直接取り扱うことができるように各機能のプログラムを作成すれば、第１振り分け部４１０が図２２に示したようなテーブルを参照して要求に係るＳＯＡＰリクエストを直接各機能に振り分けるようにすることも可能である。
【０１０１】
また、上述した実施形態では、パブリック認証局が発行した通常公開鍵証明書と、プライベート認証局が発行したレスキュー公開鍵証明書とを用いる例について説明したが、前者はセキュリティ強度が高い証明書、後者はセキュリティ強度が比較的低い証明書と捉えることもできる。
一般に、セキュリティ強度が高い証明書には、多くの情報を記載する必要があったり、輸出制限があったり特殊な認証処理プログラムが必要であったりして利用可能な環境が限られていたりするため、全ての装置に同じように記憶させて認証処理に用いることが難しい場合がある。一方で、セキュリティ強度が低い証明書であれば、このような制限が少なく、全ての装置に同じように記憶させて認証処理に用いることが比較的容易であると考えられる。
【０１０２】
そこで、セキュリティ強度が低い証明書を記憶させた装置を製造・販売した上で、利用環境に合わせてセキュリティ強度が高い証明書を事後的に記憶させることができるようにしたいという要求がある。例えば、システムの運用者によって種々に認証処理の内容を工夫したり信頼性の高いＣＡを選択したりしてセキュリティの向上を図る場合も考えられるが、このような場合、ある装置を１つのシステムから他のシステムに移動（単に設定を変更するのみの場合も含む）させる場合、通常の認証処理に使用する証明書を入れ換える必要があることが考えられる。また、セキュリティの高い証明書に後で欠陥が発見され、認証処理の方式を変更する必要が生じることも考えられる。
【０１０３】
このような場合に、上述した実施形態の処理を利用し、種々の環境で共通に利用できるようなセキュリティの比較的低い証明書による通信経路を確保できるようにしておき、セキュリティの低い証明書を用いる認証を行うアドレスで通信を行った場合に、セキュリティの高い証明書の設定に関する処理以外の処理を禁止するようにすれば、セキュリティの低い証明書を使用することによる効果を十分維持しながら、セキュリティの低い証明書や対応する私有鍵等が万一漏洩した場合の影響を最低限に抑え、全体として高いセキュリティを実現することができる。
【０１０４】
また、上述した実施形態では、レスキュー公開鍵証明書にも装置の識別情報を記載する例について説明したが、レスキュー公開鍵証明書には装置の識別情報を含めず、同じ階位の装置（図１及び図２に示した例では、上位装置と下位装置の階位が存在するものとする）には、全て同じレスキュー公開鍵証明書を記憶させるようにしてもよい。この場合、同じ階位の各装置を個別に区別する必要がないので、証明書に含まれるレスキュー公開鍵及びこれと対応するレスキュー私有鍵も含めて、全く共通のものでよい。そして、通信相手のレスキュー公開鍵証明書が全て同じであることから、ルート鍵証明書については、ある階位の装置の通信相手となる全ての装置について共通となる。すなわち、図２３に示したように下位装置を複数設けた場合でも、全ての下位装置に同じレスキュー認証情報を記憶させることになる。
【０１０５】
これは、上位装置１０のレスキュー認証情報のレスキュー認証情報についても同様である。
なお、通常公開鍵証明書とデータ形式を統一化する場合には、例えば図６に示した形式において「Subject」の項目を空白としたり、ベンダー名のみ記載して機番として０を記載してレスキュー公開鍵証明書であることを示すこと等も考えられる。
【０１０６】
このようにすれは、レスキュー認証情報は同じ階位の装置について全て共通となるので、装置の製造時にその機種に応じて定まる階位に応じたものを記憶させてしまうことができる。すなわち、装置の識別情報を付した情報ではないため、検査工程を終了して識別番号を付した各装置に対してそれぞれ個別の証明書を用意して記憶させる必要はなく、多数の装置に対して単純作業によって記憶させることができる。例えば、制御プログラムのマスタにレスキュー認証情報を含めておき、制御プログラムを装置にコピーする際にレスキュー認証情報も共に記憶させる等である。
そして、レスキュー公開鍵証明書に十分長期の有効期間を設定しておけば、その後レスキュー認証情報を更新する必要はないため破損しづらく、また上記のように通常公開鍵証明書の有効期間が過ぎて通常公開鍵証明書による認証が行えなくなった場合でも、レスキュー認証情報に含まれるレスキュー公開鍵証明書を用いた認証は可能な状態を保つことができる。
【０１０７】
なおこの場合、レスキュー公開鍵証明書には装置の識別情報を付していないため、レスキュー公開鍵証明書を用いた認証を行った場合でも、通信相手の装置を具体的に特定することはできない。しかし、通信相手についてある程度の情報は得ることができる。
すなわち、例えばあるベンダーが自社製品のうち下位装置２０に該当する装置全てに下位装置用のレスキュー認証情報（下位装置用レスキュー公開鍵証明書，下位装置用レスキュー私有鍵及び上位装置認証用レスキュールート鍵証明書）を記憶させ、その通信相手となる上位装置１０に該当する装置全てに上位装置用のレスキュー認証情報（上位装置用レスキュー公開鍵証明書，上位装置用レスキュー私有鍵及び下位装置認証用レスキュールート鍵証明書）を記憶させておけば、下位装置２０は、認証処理が成功した場合、自己の記憶している上位装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手が同じベンダーの上位装置１０であることを認識できるし、逆に上位装置１０も自己の記憶しているレスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手は同じベンダーの下位装置２０であることを認識できる。
【０１０８】
そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができるので、その後機番情報等を交換して通信相手を特定することも可能である。
なお、通常公開鍵証明書についても、パブリック認証局がこのようなサービスを提供していれば、同様に装置の識別情報を含めないものとすることも考えられる。このようにしたとしても、パブリック認証局が発行するものであるから信頼性は高いと考えられる。また、レスキュー公開鍵証明書よりも有効期間が短ければ、その分だけレスキュー公開鍵証明書よりも安全性を高めることができる。
また、通常公開鍵証明書とレスキュー公開鍵証明書の有効期間についても、特に上述した関係に限定されることはない。さらに、認証局の種類についても、セキュリティ高低の１つの要素と捉え、有効期間、装置の識別情報の有無、証明書を用いた認証処理の暗号強度等により、通常公開鍵証明書とレスキュー公開鍵証明書の差を出すようにすることも考えられる。
【０１０９】
また、上述した実施形態では、上位装置１０と下位装置２０が、図２４あるいは図２６を用いて説明したようなＳＳＬに従った認証を行う場合の例について説明した。しかし、この認証が必ずしもこのようなものでなくてもこの実施形態は効果を発揮する。
ＳＳＬを改良したＴＬＳ（Transport Layer Security）も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。
また、要求の記載形式も、ＳＯＡＰメッセージに限られるものではない。要求をこのような構造化言語形式で記載された情報として受け付けるようにすれば、データの汎用性を高め、データ形式の設計や改変を容易に行うことができるが、他の形式で記載することも可能である。
【０１１０】
また、上述した実施形態では、ＣＡを上位装置１０と別に設ける例について説明したが、これらが一体である構成を排除するものではない。この場合、ＣＡの機能を実現するためのＣＰＵ，ＲＯＭ，ＲＡＭ等の部品を独立して設けてもよいが、上位装置１０のＣＰＵ，ＲＯＭ，ＲＡＭ等を使用し、そのＣＰＵに適当なソフトウェアを実行させることにより、ＣＡとして機能させるようにしてもよい。
【０１１１】
さらにまた、上位装置１０と下位装置２０が、目的に応じて種々の構成をとることができることは既に述べたが、このような場合も、各種機能３８０に含まれる機能の種類は装置の種類や構成に応じて適宜定めることができ、レスキュー公開鍵証明書によって通信相手に認証された場合に通常公開鍵証明書の設定に関する要求以外の要求に係る処理を禁止するようにすれば、上述した実施形態の場合のような効果を得ることができる。また、禁止から除外する要求を、通常公開鍵証明書の設定に関する要求に限らず適宜定め、セキュリティの比較的低いレスキュー公開鍵証明書を用いて認証処理を行った場合に一部の機能の使用を制限するような機能制限を行うようにすることも考えられる。
上位装置１０と下位装置２０の具体例としては、例えば、遠隔管理システムにおいて、プリンタ，ＦＡＸ装置，コピー機，スキャナ，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム、自動車、航空機等に通信機能を設けた通信装置を被管理装置である下位装置２０とし、これらの被管理装置から情報を収集したり、コマンドを送って動作させたりするための管理装置を上位装置１０とすることが考えられる。
【０１１２】
また、この発明によるプログラムは、コンピュータを、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、その通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信装置である下位装置２０のような装置として機能させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
【産業上の利用可能性】
【０１１３】
以上説明してきた通り、この発明の通信装置、通信システム、通信装置の制御方法あるいはプログラムによれば、通信手段を備え、通信の際に通信相手に認証を受けるためにデジタル証明書を提供する通信装置を用いて通信システムを構成する場合において、セキュリティを維持しながら、正常な認証を受けられる状態を容易に維持できるようにすることができる。従って、通信システムの運用を高い信頼性で行うことができる。
【図面の簡単な説明】
【０１１４】
【図１】この発明の実施形態の通信装置を用いて構成したこの発明の通信システムの実施形態の構成を示すブロック図である。
【図２】図１に示した上位装置のハードウェア構成を示すブロック図である。
【図３】図１に示した通信システムにおける通信方式の概要を示す説明図である。
【図４】図１に示した上位装置及び下位装置が認証情報として記憶している証明書及び鍵の種類を示す図である。
【図５】通常公開鍵証明書のフォーマット例について説明するための図である。
【図６】図５に記載したフォーマットに従って作成した一般的な公開鍵証明書の例を示す図である。
【図７】同じく、レスキュー公開鍵証明書と対比するための、通常公開鍵証明書の例を示す図である。
【図８】同じく、通常公開鍵証明書と対比するための、レスキュー公開鍵証明書の例を示す図である。
【図９】クライアントがサーバに通信を要求する際に通信先の指定に用いるＵＲＬの例を示す図である。
【図１０】図１に示した通信システムの構成及び運用方式について説明するための図である。
【０１１５】
【図１１】上位装置から受信した要求の内容に応じた動作を実行して応答を返すための、下位装置における機能構成を示す図である。
【図１２】第１振り分け部による要求の振り分け先をＵＲＬ毎に規定したテーブルの例を示す図である。
【図１３】各第２振り分け部についての要求の種類と振り分け先との関係を規定したテーブルの例を示す図である。
【図１４】図１に示した下位装置が通信要求を受け付けた場合に行う処理を示すフローチャートである。
【図１５】その続きの処理を示すフローチャートである。
【図１６】図１に示した下位装置が通常処理ＵＲＬで要求を受け付けた場合の処理シーケンスの例を示すシーケンス図である。
【図１７】図１に示した通信システムにおいて上位装置から下位装置のレスキューＵＲＬに送信する証明書設定要求のＨＴＴＰリクエストの例を示す図である。
【図１８】図１７に示したＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示す図である。
【図１９】上位装置から下位装置のレスキューＵＲＬに送信する図１７とは別のＨＴＴＰリクエストの例を示す図である。
【図２０】図１９に示したＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示す図である。
【０１１６】
【図２１】図１に示した下位装置の機能構成の変形例を示す図である。
【図２２】この発明の実施形態の変形例において、第２振り分け部が参照するテーブルの例を示す図である。
【図２３】図１に示した通信システムについて、下位装置を複数設けた場合の構成について説明するための図である。
【図２４】２つの通信装置がＳＳＬに従った相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
【図２５】図２４に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。
【図２６】２つの通信装置がＳＳＬに従った片方向認証を行う際の各装置において実行する処理を示す、図２４と対応する図である。
【符号の説明】
【０１１７】
１０…上位装置、１１…ＣＰＵ、１２…ＲＯＭ、１３…ＲＡＭ、１４…ＨＤＤ、
１５…通信Ｉ／Ｆ、１６…システムバス、２０…下位装置、３０…ネットワーク、
４０…ＨＴＴＰリクエスト、５０…ＨＴＴＰレスポンス、
３３１…ＨＴＴＰデーモン、３８０…各種機能、４１０…第１振り分け部、
４２１…通常処理ＵＲＬ用第２振り分け部、４２２…レスキューＵＲＬ用第２振り分け部
【図１】
2005130454.tif 000003
【図２】
2005130454.tif 000004
【図３】
2005130454.tif 000005
【図４】
2005130454.tif 000006
【図５】
2005130454.tif 000007
【図６】
2005130454.tif 000008
【図７】
2005130454.tif 000009
【図８】
2005130454.tif 000010
【図９】
2005130454.tif 000011
【図１０】
2005130454.tif 000012
【図１１】
2005130454.tif 000013
【図１２】
2005130454.tif 000014
【図１３】
2005130454.tif 000015
【図１４】
2005130454.tif 000016
【図１５】
2005130454.tif 000017
【図１６】
2005130454.tif 000018
【図１７】
2005130454.tif 000019
【図１８】
2005130454.tif 000020
【図１９】
2005130454.tif 000021
【図２０】
2005130454.tif 000022
【図２１】
2005130454.tif 000023
【図２２】
2005130454.tif 000024
【図２３】
2005130454.tif 000025
【図２４】
2005130454.tif 000026
【図２５】
2005130454.tif 000027
【図２６】
2005130454.tif 000028