JP4522771B2 - 通信装置、通信システム、通信装置の制御方法及びプログラム - Google Patents

Description

この発明は、通信手段を備え、通信の際に通信相手に認証を受けるためにデジタル証明書を提供する通信装置、このような通信装置である下位装置とその通信相手となる上位装置によって構成される通信システム、通信の際に通信相手に認証を受けるためにデジタル証明書を提供させるための通信装置の制御方法、およびコンピュータを上記の通信装置として機能させるためのプログラムに関する。

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

このようなシステムを構築する上では、通信を行う際に、通信相手が適切か、あるいは送信されてくる情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばＳＳＬ（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）を用いるようにしてもよい。この情報は、上述のＨＴＴＰヘッダ情報に含まれるものである。

また、各種機能３８０は要求実行手段に該当し、ここに含まれる各機能は、各々が要求処理手段であり、受信した要求に応じた処理を行うためのソフトウェアによって提供される機能である。そして、通常処理ＵＲＬ用第２振り分け部４２１又はレスキューＵＲＬ用第２振り分け部４２２によって起動され、受け取ったデータに従ってロジックを実行し、その結果を処理の依頼元の第２振り分け部に返す処理を行う。

また、各第２振り分け部４２１，４２２から渡されたＤＯＭツリー形式のデータを解析し、これを、各種機能３８０に含まれる各機能のロジックを記述したプログラム言語で処理可能なデータ形式に変換する機能や、プログラムの実行結果である結果データを、ＤＯＭツリー形式のデータに変換する機能も有する。なお、ここでは各種機能３８０に含まれる各機能のロジックはＣ言語で記載されているものとし、このデータ形式はＣ言語の構造体データであるものとする。
このような各種機能３８０について、図では固有情報取得機能３８１と証明書設定機能３８７以外は具体的な内容を示していないが、各機能は要求の種類に対応して設けられる。

例えば、固有情報取得機能３８１に分類される機能としては、ＩＤ（機番），モデル名，ファームウェアのバージョン，オプション構成，証明書のバージョン等の下位装置２０に固有な情報（識別情報を含む）の取得のようなものが挙げられるが、これらの機能の実行を指示するために別々の要求を用意するのであれば、これらの要求の実行に係るソフトウェアは、別々にコールされるプログラムとして設けるようにしている。
なお、証明書設定機能の提供する機能は、個別公開鍵証明書の設定である。ただし、この設定は、この下位装置２０では正規認証情報を構成する証明書セット全体を設定して行われる。

また、各種機能３８０に含まれる他の機能としては、例えば要求元に下位装置２０の状態の情報を取得させる状態取得機能、同じくログ情報を取得させるログ情報取得機能、同じく設定値の情報を取得させる設定値情報取得機能、下位装置２０の設定値を変更させる設定値変更機能、下位装置２０の調整動作を行わせる調整実行機能等が考えられるが、どのような機能を設けるかは、下位装置２０の構成や、上位装置１０との関係に応じて適宜に定めればよい。
また、図示はしていないが、下位装置２０が実行する複数のアプリが、それぞれアプリの機能に応じて各種機能３８０のような機能セットを提供するようにしてもよい。

ところで、この下位装置２０においては、通常処理ＵＲＬ用第２振り分け部４２１は、対応する機能がある全ての要求をその機能に振り分ける。しかし、レスキューＵＲＬ用第２振り分け部４２２は、図８に太線で示したように、個別公開鍵証明書の設定に関する要求のみしか機能に振り分けない。そして、その他の要求を受け付けた場合には、対応する機能がないものとして応答を返す。
そしてここでは、個別公開鍵証明書の設定に関する要求は、個別公開鍵証明書の作成（情報の記載も含む）に必要な個別情報の取得要求と、個別公開鍵証明書の設定要求としており、これらに対応する機能は、固有情報取得機能３８１のうちＩＤ，モデル名及び証明書のバージョン情報の取得に係る機能と、証明書設定機能３８７としている。しかし、さらに他の要求も個別公開鍵証明書の設定に関する要求として取り扱ったり、逆に個別情報の取得要求を公開鍵証明書の設定に関する要求として取り扱わないようにすることも考えられる。具体的にどのような要求を個別公開鍵証明書の設定に関する要求として取り扱うかは、最終的にはシステムの設計者が適宜定めればよい。

このような振り分けは、図１０に示したように、第２振り分け部毎に要求の種類と振り分け先とのテーブルを設け、各第２振り分け部が自己と対応するテーブルを参照して振り分けを行うようにすることにより、実現することができる。テーブルに記載されていない要求については、対応する機能がないものとして取り扱うようにすればよい。
このようにしたことにより、下位装置２０が通常処理ＵＲＬから要求を受信した場合には全ての要求に係る処理が許可される一方、レスキューＵＲＬから要求を受信した場合には、その要求は第１振り分け部４１０からレスキューＵＲＬ用第２振り分け部４２２に届くものの、個別公開鍵証明書の設定に関する要求以外の処理は機能に振り分けられず、結果的に処理が禁止されることになる。そして、第１振り分け部４１０とレスキューＵＲＬ用第２振り分け部４２２とで禁止手段の機能が実現される。
なお、他のアプリへの要求に係る処理も禁止するためには、レスキューＵＲＬで要求を受信した場合にＨＴＴＰデーモン３３１がその要求を個別公開鍵証明書の設定を行うアプリ以外には渡さないようにすればよい。また、アプリ毎に通常処理ＵＲＬ用第２振り分け部とレスキューＵＲＬ用第２振り分け部とを設け、後者が各機能への振り分けを全く行わないようにしてもよい。

以上のような禁止手段により、共通公開鍵証明書を用いてＳＳＬハンドシェイクを行うレスキューＵＲＬで通信を行った場合に、個別公開鍵証明書の設定に関する処理以外の処理を禁止するようにすることができる。そして、このことにより、共通公開鍵証明書を使用することによる効果を十分維持しながら、共通証明書や対応する私有鍵等が万一漏洩した場合の影響を最低限に抑え、高いセキュリティを実現することができる。

次に、図８に示した構成を有する下位装置２０において実行される処理について、図１１及び図１２を用いて説明する。図１１は、下位装置２０が通信要求を受け付けた場合に行う処理を示すフローチャート、図１２はその続きの処理を示すフローチャートである。これらの処理は、この発明の通信装置の制御方法に係る処理である。そしてここでは、説明を簡単にするため、通信相手が下位装置２０を認証するのみの、図２３に示したような片方向認証を行う場合の処理を示している。しかし、図２１に示したような双方向認証を行うようにしてもよいことはもちろんである。

下位装置２０のＣＰＵは、ＨＴＴＰデーモン３３１を常に実行しており、これが他の装置からの通信要求を受け付けると、図１１のフローチャートに示す処理を開始する。
この処理においては、まずステップＳ１０１で、通信要求を受け付けたＵＲＬが通常処理ＵＲＬであるか否か判断する。そして通常処理ＵＲＬであれば、ステップＳ１０２に進んで、下位装置用個別公開鍵証明書を下位装置用個別私有鍵で暗号化した第１の乱数と共に通信相手（通信要求の要求元）に送信して認証を要求する。すなわち、この場合には通信相手に対して個別証明書を提供する。この処理は、図２３のステップＳ２１及びＳ２２の処理に相当する。

その後、ステップＳ１０６に進んで通信相手からの応答を待ち、認証されなかった場合には以後の通信を許可せずにそのまま終了するが、通信相手に認証された場合には、ステップＳ１０７に進み、認証処理において受信した共通鍵の種から共通鍵を作成する。これらの処理は、図２３のステップＳ２５及びＳ２６の処理に相当する。
そして、ステップＳ１０８で通信相手からのＨＴＴＰリクエストによる要求の受信を待ち、受信するとステップＳ１０９に進んで、その要求を、受信したＵＲＬの情報と共に第１振り分け部４１０に渡す。ここまでの処理が、ＨＴＴＰデーモン３３１による処理である。

また、ステップＳ１０１で通常処理ＵＲＬでなかった場合には、ステップＳ１０３に進んで通信要求を受け付けたＵＲＬがレスキューＵＲＬであるか否か判断する。そしてレスキューＵＲＬであれば、ステップＳ１０４に進んで、下位装置用共通公開鍵証明書を下位装置用共通私有鍵で暗号化した第１の乱数と共に通信相手に送信して認証を要求する。すなわち、この場合には通信相手に対して共通証明書を提供する。この処理も、図２３のステップＳ２１及びＳ２２の処理に相当する。
そして、ステップＳ１０６以下に進み、ステップＳ１０９までは個別証明書を提供した場合と同様な処理を行う。また、ステップＳ１０３でレスキューＵＲＬでない場合には、通信を受け付けていないＵＲＬへの通信要求であるので、ステップＳ１０５でエラー処理を行って処理を終了する。

次にステップＳ１１０以降の処理について説明する。
ステップＳ１０９で要求を渡された第１振り分け部４１０は、図９に示したようなテーブルを参照し、受信したＵＲＬに応じて振り分け先を決定する。そしてここでは、通常処理ＵＲＬで受信した要求はステップＳ１１１で通常処理ＵＲＬ用第２振り分け部４２１に渡し、レスキューＵＲＬで受信した要求はステップＳ１１２でレスキューＵＲＬ用第２振り分け部４２２に渡す。
ステップＳ１１１及びＳ１１２の後は、それぞれ図１２のステップＳ１１３及びＳ１１６に進み、第２振り分け部が、ＨＴＴＰリクエストとして受信した要求のＨＴＭＬボディーに当たるＳＯＡＰエンベロープを解析し、その構成を示すＤＯＭツリー形式のデータを作成する。この処理は、どちらの第２振り分け部でも同様に行う。

そしてその後、それぞれステップＳ１１４及びＳ１１７に進み、第２振り分け部が各種機能３８０中の要求の種類に応じた機能に要求を振り分けてその要求に係る処理を依頼する。このとき、要求はＨＴＴＰヘッダ情報及びＤＯＭツリー形式のデータとして機能に渡す。また、通常処理ＵＲＬ用第２振り分け部４２１は、各種機能３８０のどの機能に対しても振り分けを行うが、レスキューＵＲＬ用第２振り分け部４２２は、個別証明書の設定に関する要求のみを振り分ける。この振り分けは、図１０に示したように、２つの第２振り分け部で、要求の種類と振り分け先の機能との対応関係を示したテーブルについて異なるものを使用すれば、処理の手順自体は同じものにすることができる。
この振り分けの後、それぞれステップＳ１１５及びＳ１１８に進み、振り分けが成功したか否か、すなわちテーブルに要求の種類と対応する振り分け先が存在したか否か判断する。そして、成功していれば、どちらのステップの場合もステップＳ１１９に進む。

次のステップＳ１１９では、要求を振り分けられた機能が、要求のＤＯＭツリーを解析して、そこに含まれるパラメータをＣ言語の構造体データに変換する。そして、ステップＳ１２０で機能のロジックを実行し、結果を構造体データとして生成する。その後、ステップＳ１２１でその構造体データをＤＯＭツリーに変換して、レスポンスとして第２振り分け部に返す。このとき、結果は機能に対して要求を振り分けた第２振り分け部に返す。
そして、これを受け取った第２振り分け部は、ステップＳ１２２でそのＤＯＭツリーを図示しないＸＭＬシリアライザによってＸＭＬ形式のＳＯＡＰメッセージによるレスポンスデータに変換し、ＨＴＴＰデーモン３３１によってＨＴＴＰレスポンスとして要求の送信元に返して処理を終了する。

一方、ステップＳ１１５又はＳ１１８で振り分けが失敗していた場合には、振り分けを試みた第２振り分け部は、ステップＳ１２３でその種類の要求をサポートしていない旨のエラー情報（ＳＯＡＰ Ｆａｕｌｔ）のＤＯＭツリーを生成し、ステップＳ１２４でＸＭＬ形式のレスポンスデータに変換して、これをＨＴＴＰデーモン３３１によってＨＴＴＰレスポンスとして要求の送信元に返して処理を終了する。
なお、第２振り分け部を通常処理ＵＲＬ用とレスキューＵＲＬ用で区別する必要があるのは、要求を機能に振り分ける手順までであり、応答を返す処理においては通常処理ＵＲＬ用とレスキューＵＲＬ用の機能は全く同じである。従って、ステップＳ１１９以降ではこれらを区別せずに示している。

次に、図１１及び図１２のフローチャートに示した処理による処理シーケンスの例について、図１３を用いて説明する。図１３は、この処理シーケンスを示すシーケンス図であり、下位装置２０が通常処理ＵＲＬで要求を受け付けた場合の処理を示している。
この例においては、ＳＳＬハンドシェイクの処理は図示を省略しているが、その後上位装置１０が下位装置２０の通常処理ＵＲＬに要求をＨＴＴＰリクエストとして送信すると、ＨＴＴＰデーモン３３１がこれを受け付ける（Ｓ２０１）。この要求はＳＯＡＰメッセージとして記載されており、ＨＴＴＰデーモン３３１は受信した要求を受信したＵＲＬを示す情報（例えばＩＰアドレスとポート番号）と共に第１振り分け部４１０に渡して振り分け処理を依頼する（Ｓ２０２）。

そして第１振り分け部４１０は、その情報を基に図９に示したようなテーブルを参照し、要求を受信したＵＲＬに応じて要求の振り分け先を決定する（Ｓ２０３）。そして、ここではＵＲＬは通常処理ＵＲＬであり、振り分け先は通常処理ＵＲＬ用第２振り分け部４２１であるので、ここに要求を振り分けてその後の処理を依頼する（Ｓ２０４）。これを受けた通常処理ＵＲＬ用第２振り分け部４２１は、要求のＳＯＡＰメッセージをＤＯＭツリー形式のデータに変換し（Ｓ２０５）、要求の種類に応じて振り分け先を決定し（Ｓ２０６）、振り分け先となる機能３８ｘにＤＯＭツリー形式のデータを渡して処理を依頼する（Ｓ２０７）。

そして、その機能３８ｘがＤＯＭツリー形式のデータをロジックにより処理できる構造体データに変換し（Ｓ２０８）、これを引数としてロジックを実行して要求に係る処理を行い（Ｓ２０９）、処理結果の構造体データをＤＯＭツリー形式のデータに変換し（Ｓ２１０）、処理を依頼してきた通常処理ＵＲＬ用第２振り分け部４２１にそのデータを渡す（Ｓ２１１）。
そして、このデータを受け取った通常処理ＵＲＬ用第２振り分け部４２１は、これを応答のＳＯＡＰメッセージに変換し（Ｓ２１２）、ＨＴＴＰデーモン３３１を介して上位装置１０にＨＴＴＰレスポンスとして送信する（Ｓ２１３，Ｓ２１４）。
以上が通常処理ＵＲＬで要求を受け付けた場合の処理である。

そして、レスキューＵＲＬで要求を受け付けた場合にも、ほぼ同様な処理が行われるが、第１振り分け部４１０による振り分け先がレスキューＵＲＬ用第２振り分け部４２２となる。そして、レスキューＵＲＬ用第２振り分け部４２２は個別公開鍵証明書の設定に関する要求のみを機能３８ｘに振り分け、それ以外の要求は振り分け先がないものとして処理する。従って、通常処理ＵＲＬで要求を受け付けた場合とレスキューＵＲＬで要求を受け付けた場合とでほぼ同様な手順の処理を行いながら、結果的に、レスキューＵＲＬで要求を受け付けた場合には個別公開鍵証明書の設定に関する要求以外の要求に係る処理を禁止することができる。

次に、上位装置１０から下位装置２０へ送信する要求のＨＴＴＰリクエスト及び下位装置２０から上位装置１０へ返す応答のＨＴＴＰレスポンスの例について図１４乃至図１７を用いて説明する。
まず、図１４に上位装置１０から下位装置２０のレスキューＵＲＬに送信する証明書設定要求のＨＴＴＰリクエストの例を示す。
このＨＴＴＰリクエストは、上述したように、ＳＯＡＰに従ったＳＯＡＰメッセージであり、ＨＴＴＰヘッダの最後にＳＯＡＰＡｃｔｉｏｎヘッダ６１を付してある。そして、それ以後の内容がＳＯＡＰエンベロープであり、ここに含まれるＳＯＡＰボディ中に要求の内容を記載している。ここでは、Ｂｏｄｙのすぐ下位の符号６２で示す要素に、要求が証明書設定要求であることを示す情報を記載している。そして、その下位に、証明書のバージョンを示すパラメータ６３、証明書の暗号化パスワードを示すパラメータ６４、設定すべき証明書を暗号化してＢａｓｅ６４エンコードしたデータを示すパラメータ６５を記載している。そして、要求の種類は、要素６２あるいはＳＯＡＰＡｃｔｉｏｎヘッダ６１の末尾を参照すればわかり、第２振り分け部は、この情報に従って機能への振り分け処理を行う。

図１５にこのようなＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示す。
このＨＴＴＰレスポンスも、ＳＯＡＰメッセージであり、ＨＴＴＰヘッダとＳＯＡＰエンベロープとからなる。そして、ＳＯＡＰボディー中に、実行した要求の種類を要素７１として、その実行結果が「成功」である旨を要素７２として示している。更新を試みることはできたものの失敗した場合には、要素７２の内容が「ＮＧ」になる。

また、図１６に、上位装置１０から下位装置２０のレスキューＵＲＬに送信する別のＨＴＴＰリクエストの例を示す。
このＨＴＴＰリクエストも、ＳＯＡＰメッセージであり、状態取得要求を行うものである。そして、図１４の場合とは要求の種類が異なることに伴い、ＳＯＡＰＡｃｔｉｏｎヘッダ８１の末尾と、ＳＯＡＰボディーの内容が図１４に示した例と異なる。ここでは、ＳＯＡＰボディーの下位には要求が状態取得要求であることを示す要素８２のみを記載し、その他のパラメータは記載していない。

図１７にこのようなＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示すが、状態取得要求は、レスキューＵＲＬで受信した場合には機能に振り分けない要求であるので、このようなコマンドは存在しない旨の応答が、ＳＯＡＰ Ｆａｕｌｔとして返されることになる。そして、ＳＯＡＰボディー中に要素９１としてその旨を示す情報を記載している。

以上説明してきたような通信システムによれば、個別証明書が破損等した場合でも共通証明書を用いた認証が成功した場合にネットワークを介してこれを設定できるようにしているので、下位装置２０が常に正常な認証を受けられる状態を維持できる。そして、この処理に人手を介す必要はなく、容易にこのような効果を得ることができる。また、共通公開鍵証明書を用いてＳＳＬハンドシェイクを行うレスキューＵＲＬで通信を行った場合に、個別証明書の設定に関する処理以外の処理を禁止するようにしているので、共通証明書を使用することによる効果を十分維持しながら、共通証明書や対応する私有鍵等が万一漏洩した場合の影響を最低限に抑え、高いセキュリティを実現することができる。
なお、個別証明書の設定の際には下位装置２０と上位装置１０との間で相互認証を行うようにすれば、下位装置２０が不適当な装置から個別証明書を受信して記憶してしまうことを防止でき、さらに通信の安全性を向上させることができる。

〔変形例：図１８，図１９〕
次に、上述した実施形態の変形例について説明する。
まず、図１８に下位装置２０の機能構成の変形例を示す。
上述した実施形態においては、上位装置１０から受信した要求の内容に応じた動作を実行して応答を返すための下位装置２０の機能構成が図８に示すものである例について説明したが、これを図１８に示すものにしてもよい。すなわち、仲介デーモン３３２とＨＴＴＰ接続管理部３４２とＨＴＴＰサービス実行部３４３とを設けるようにしてもよい。

この場合、第１振り分け部４１０とＨＴＴＰデーモン３３１との間のデータの受け渡しをＨＴＴＰサービス実行部３４３を介して行い、さらにＨＴＴＰサービス実行部３４３は、各種機能３８０が提供する機能に関する動作要求を含むと考えられるＰＯＳＴメソッドのみを第１振り分け部４１０に渡すようにする。また、仲介デーモン３３２はＨＴＴＰデーモン３３１から通信の接続、切断に関する通知を受けてＨＴＴＰ接続管理部３４２にこれを伝え、ＨＴＴＰ接続管理部３４２はこの通知に応じてＨＴＴＰサービス実行部３４３にＨＴＴＰデーモン３３１からＨＴＴＰリクエストを取得させる。
このような構成とし、ＨＴＴＰサービス実行部３４３に対応するスレッドを複数備えることによって、上位装置１０からの複数の要求を単一のアプリ（プロセス）で平行処理することが可能になり、上位装置１０に対する応答性能を向上させることができる。本件の出願人は、このような技術に関し、過去に特許出願を行っている（特願２００３−８１２４６）。

またここでは、第２振り分け部を複数設け、第１振り分け部４１０が受信したＵＲＬに従って要求を適当な第２振り分け部に振り分ける例について説明した。
しかしながら、例えば第２振り分け部を１つだけ設け、第２振り分け部に第１振り分け部４１０の機能を併せ持たせ、１つの第２振り分け部が、受信したＵＲＬと要求の種類との両方に従って各機能に要求を振り分けるようにすることも可能である。この場合には、例えば図１９に示すような、受信したＵＲＬと要求の種類の組み合わせ毎に要求の振り分け先を定めたテーブルを記憶しておき、これを参照して振り分け先の機能にＨＴＴＰヘッダ情報及びＤＯＭツリー形式のデータを振り分けるようにすればよい。
このようにすれば、プログラムモジュールの点数を削減することができる。ただし、図８に示した実施形態の構成であれば、ＵＲＬの情報を第２振り分け部から先に渡す必要がないため、モジュール間インタフェースの簡略化という点では図８に示した構成の方が優れていると言える。

また、ここでは各機能にＤＯＭツリーを構造体データに変換したり構造体データをＤＯＭツリーに変換したりする機能を設ける例について説明したが、各機能とは別に、このような変換を行うハンドラを設けるようにしてもよい。このようなすれば、各機能には、その機能のプログラムが直接処理できる形式でデータを渡すことができるので、各機能のプログラムを、ＳＯＡＰやＸＭＬの知識がなくても開発できるようにすることができる。
また、ここでは第２振り分け部にＸＭＬで記載されたＳＯＡＰメッセージをＤＯＭツリーに変換したりＤＯＭツリーをＳＯＡＰメッセージに変換したりする機能を設ける例について説明したが、このようにすることも必須ではない。ＳＯＡＰメッセージを直接取り扱うことができるように各機能のプログラムを作成すれば、第１振り分け部４１０が図１９に示したようなテーブルを参照して要求に係るＳＯＡＰリクエストを直接各機能に振り分けるようにすることも可能である。

また、上述した実施形態では、装置の識別情報が付された個別証明書と、装置の識別情報が付されていない共通証明書とを用いる例について説明したが、前者はセキュリティ強度が高い証明書、後者はセキュリティ強度が低い証明書と捉えることもできる。
一般に、セキュリティ強度が高い証明書には、多くの情報を記載する必要があったり、輸出制限があったり特殊な認証処理プログラムが必要であったりして利用可能な環境が限られていたりするため、全ての装置に同じように記憶させて認証処理に用いることが難しい場合がある。一方で、セキュリティ強度が低い証明書であれば、このような制限が少なく、全ての装置に同じように記憶させて認証処理に用いることが比較的容易であると考えられる。

そこで、セキュリティ強度が低い証明書を記憶させた装置を製造・販売した上で、利用環境に合わせてセキュリティ強度が高い証明書を事後的に記憶させることができるようにしたいという要求がある。このような場合に、上述した実施形態の処理を利用し、セキュリティの低い証明書を用いる認証を行うアドレスで通信を行った場合に、セキュリティの高い証明書の設定に関する処理以外の処理を禁止するようにすれば、セキュリティの低い証明書を使用することによる効果を十分維持しながら、セキュリティの低い証明書や対応する私有鍵等が万一漏洩した場合の影響を最低限に抑え、全体として高いセキュリティを実現することができる。

また、上述した実施形態では、上位装置１０と下位装置２０が、図２１あるいは図２３を用いて説明したようなＳＳＬに従った認証を行う場合の例について説明した。しかし、この認証が必ずしもこのようなものでなくてもこの実施形態は効果を発揮する。
ＳＳＬを改良したＴＬＳ（Transport Layer Security）も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。
また、要求の記載形式も、ＳＯＡＰメッセージに限られるものではない。要求をこのような構造化言語形式で記載された情報として受け付けるようにすれば、データの汎用性を高め、データ形式の設計や改変を容易に行うことができるが、他の形式で記載することも可能である。

また、上述した実施形態では、ＣＡを上位装置１０と別に設ける例について説明したが、これと一体として設けることを妨げるものではない。この場合、ＣＡの機能を実現するためのＣＰＵ，ＲＯＭ，ＲＡＭ等の部品を独立して設けてもよいが、上位装置１０のＣＰＵ，ＲＯＭ，ＲＡＭ等を使用し、そのＣＰＵに適当なソフトウェアを実行させることにより、ＣＡとして機能させるようにしてもよい。

さらにまた、上位装置１０と下位装置２０が、目的に応じて種々の構成をとることができることは既に述べたが、このような場合も、各種機能３８０に含まれる機能の種類は装置の種類や構成に応じて適宜定めることができ、共通証明書によって通信相手に認証された場合に個別証明書の設定に関する要求以外の要求に係る処理を禁止するようにすれば、上述した実施形態の場合のような効果を得ることができる。また、禁止から除外する要求を、個別証明書の設定に関する要求に限らず適宜定め、セキュリティの比較的低い共通証明書を用いて認証処理を行った場合に一部の機能の使用を制限するような機能制限を行うようにすることも考えられる。
上位装置１０と下位装置２０の具体例としては、例えば、遠隔管理システムにおいて、プリンタ，ＦＡＸ装置，コピー機，スキャナ，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム、自動車、航空機等に通信機能を設けた通信装置を被管理装置である下位装置２０とし、これらの被管理装置から情報を収集したり、コマンドを送って動作させたりするための管理装置を上位装置１０とすることが考えられる。

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

以上説明してきた通り、この発明の通信装置、通信システム、通信装置の制御方法あるいはプログラムによれば、通信手段を備え、通信の際に通信相手に認証を受けるためにデジタル証明書を提供する通信装置を用いて通信システムを構成する場合において、セキュリティを維持しながら、正常な認証を受けられる状態を容易に維持できるようにすることができる。従って、通信システムの運用を高い信頼性で行うことができる。

この発明の実施形態の通信装置を用いて構成したこの発明の通信システムの実施形態の構成を示すブロック図である。 図１に示した上位装置のハードウェア構成を示すブロック図である。 図１に示した通信システムにおける通信方式の概要を示す説明図である。 図１に示した上位装置及び下位装置が認証情報として記憶している証明書及び鍵の種類を示す図である。 図４に示した下位装置用個別公開鍵証明書に含まれる情報の例を示す図である。 クライアントがサーバに通信を要求する際に通信先の指定に用いるＵＲＬの例を示す図である。 図１に示した通信システムの構成及び運用方式について説明するための図である。 上位装置から受信した要求の内容に応じた動作を実行して応答を返すための、下位装置における機能構成を示す図である。 第１振り分け部による要求の振り分け先をＵＲＬ毎に規定したテーブルの例を示す図である。 各第２振り分け部についての要求の種類と振り分け先との関係を規定したテーブルの例を示す図である。

図１に示した下位装置が通信要求を受け付けた場合に行う処理を示すフローチャートである。 その続きの処理を示すフローチャートである。 図１に示した下位装置が通常処理ＵＲＬで要求を受け付けた場合の処理シーケンスの例を示すシーケンス図である。 図１に示した通信システムにおいて上位装置から下位装置のレスキューＵＲＬに送信する証明書設定要求のＨＴＴＰリクエストの例を示す図である。 図１４に示したＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示す図である。 上位装置から下位装置のレスキューＵＲＬに送信する図１４とは別のＨＴＴＰリクエストの例を示す図である。 図１６に示したＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示す図である。 図１に示した下位装置の機能構成の変形例を示す図である。 この発明の実施形態の変形例において、第２振り分け部が参照するテーブルの例を示す図である。 図１に示した通信システムについて、下位装置を複数設けた場合の構成について説明するための図である。 ２つの通信装置がＳＳＬに従った相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。 図２１に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。 ２つの通信装置がＳＳＬに従った片方向認証を行う際の各装置において実行する処理を示す、図２１と対応する図である。

符号の説明

１０…上位装置、１１…ＣＰＵ、１２…ＲＯＭ、１３…ＲＡＭ、１４…ＨＤＤ、
１５…通信Ｉ／Ｆ、１６…システムバス、２０…下位装置、３０…ネットワーク、
４０…ＨＴＴＰリクエスト、５０…ＨＴＴＰレスポンス、
３３１…ＨＴＴＰデーモン、３８０…各種機能、４１０…第１振り分け部、
４２１…通常処理ＵＲＬ用第２振り分け部、４２２…レスキューＵＲＬ用第２振り分け部

Claims (21)

1. 通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、前記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置であって、
   前記通信手段は、前記複数のアドレスのうち第１のアドレスでは装置の識別情報が付されたデジタル証明書である個別証明書を提供し、第２のアドレスでは装置の識別情報が付されていないデジタル証明書である共通証明書を提供する手段であり、
   前記第２のアドレスで通信を行う場合には前記個別証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段を設けたことを特徴とする通信装置。
2. 請求項１記載の通信装置であって、
   前記デジタル証明書を提供した通信相手から該通信相手のデジタル証明書を受信して認証を行い、該認証が成功した場合のみその後の通信を許可する認証手段を設け、
   前記要求実行手段に、その通信相手から前記個別証明書の設定要求を受信した場合に前記個別証明書を更新する手段を設けたことを特徴とする通信装置。
3. 請求項１又は２記載の通信装置であって、
   前記個別証明書の設定に関する要求は、当該通信装置の個別情報の取得要求と前記個別証明書の設定要求であることを特徴とする通信装置。
4. 請求項１乃至３のいずれか一項記載の通信装置であって、
   前記要求実行手段は、前記要求に対応する所定の処理を行う複数の要求処理手段を有し、
   受信したアドレスと要求の種類とに従って要求を前記各要求処理手段に振り分ける振り分け手段を設け、
   前記禁止手段は、前記振り分け手段が前記通信を行っているアドレスによっては所定の要求以外の要求を前記要求処理手段に振り分けないようにすることにより、前記処理の禁止を行う手段であることを特徴とする通信装置。
5. 請求項１乃至４のいずれか一項記載の通信装置であって、
   前記要求はＳＯＡＰメッセージとして記載されていることを特徴とする通信装置。
6. 請求項１乃至５のいずれか一項記載の通信装置であって、
   前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
   前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信装置。
7. 通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、前記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する下位装置と、該下位装置の通信相手となる上位装置とによって構成される通信システムであって、
   前記下位装置の前記通信手段は、前記複数のアドレスのうち第１のアドレスでは装置の識別情報が付されたデジタル証明書である個別証明書を提供し、第２のアドレスでは装置の識別情報が付されていないデジタル証明書である共通証明書を提供する手段であり、
   前記下位装置に、前記第２のアドレスで通信を行う場合には前記個別証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段を設け、
   前記上位装置に、通信相手から受信したデジタル証明書を用いてその通信相手を認証する認証手段を設けたことを特徴とする通信システム。
8. 請求項７記載の通信システムであって、
   前記下位装置に、前記デジタル証明書を提供した通信相手から該通信相手のデジタル証明書を受信して認証を行い、該認証が成功した場合のみその後の通信を許可する認証手段を設け、
   前記下位装置の前記要求実行手段に、通信相手から前記個別証明書の設定要求を受信した場合に前記個別証明書を更新する手段を設けたことを特徴とする通信システム。
9. 請求項７又は８記載の通信システムであって、
   前記個別証明書の設定に関する要求は、前記下位装置の個別情報の取得要求と前記個別証明書の設定要求であることを特徴とする通信システム。
10. 請求項７乃至９のいずれか一項記載の通信システムであって、
    前記要求はＳＯＡＰメッセージとして記載されていることを特徴とする通信システム。
11. 請求項７乃至１０のいずれか一項記載の通信システムであって、
    前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
    前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信システム。
12. 通信装置に、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供させ、前記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行わせ、該通信において通信相手から受信した要求に応じた処理を行わせる通信装置の制御方法であって、
    前記複数のアドレスのうち第１のアドレスでは装置の識別情報が付されたデジタル証明書である個別証明書を提供させ、第２のアドレスでは装置の識別情報が付されていないデジタル証明書である共通証明書を提供させ、
    前記第２のアドレスで通信を行う場合には前記個別証明書の設定に関する要求以外の要求に係る処理を禁止させることを特徴とする通信装置の制御方法。
13. 請求項１２記載の通信装置の制御方法であって、
    さらに、前記通信装置に、前記デジタル証明書を提供した通信相手から該通信相手のデジタル証明書を受信させて認証を行わせ、該認証が成功した場合のみその後の通信を許可させるようにし、
    通信相手から前記個別証明書の設定要求を受信した場合に前記個別証明書を更新させることを特徴とする通信装置の制御方法。
14. 請求項１２又は１３記載の通信装置の制御方法であって、
    前記個別証明書の設定に関する要求は、前記通信装置の個別情報の取得要求と前記個別証明書の設定要求であることを特徴とする通信装置の制御方法。
15. 請求項１２乃至１４のいずれか一項記載の通信装置の制御方法であって、
    前記要求はＳＯＡＰメッセージとして記載されていることを特徴とする通信装置の制御方法。
16. 請求項１２乃至１５のいずれか一項記載の通信装置の制御方法であって、
    前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
    前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信装置の制御方法。
17. コンピュータを、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、前記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段として機能させるためのプログラムであって、
    前記通信手段は、前記複数のアドレスのうち第１のアドレスでは装置の識別情報が付されたデジタル証明書である個別証明書を提供し、第２のアドレスでは装置の識別情報が付されていないデジタル証明書である共通証明書を提供する手段であり、
    さらに、前記コンピュータを、前記第２のアドレスで通信を行う場合には前記個別証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段として機能させるためのプログラムを含むことを特徴とするプログラム。
18. 請求項１７記載のプログラムであって、
    さらに、前記コンピュータを、前記デジタル証明書を提供した通信相手から該通信相手のデジタル証明書を受信して認証を行い、該認証が成功した場合のみその後の通信を許可する認証手段として機能させるためのプログラムを含み、
    前記要求実行手段に、その通信相手から前記個別証明書の設定要求を受信した場合に前記個別証明書を更新する機能を設けたことを特徴とするプログラム。
19. 請求項１７又は１８記載のプログラムであって、
    前記個別証明書の設定に関する要求は、前記コンピュータを備える装置の個別情報の取得要求と前記個別証明書の設定要求であることを特徴とするプログラム。
20. 請求項１７乃至１９のいずれか一項記載のプログラムであって、
    前記要求はＳＯＡＰメッセージとして記載されていることを特徴とするプログラム。
21. 請求項１７乃至２０のいずれか一項記載のプログラムであって、
    前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
    前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とするプログラム。
    

Images