JP4537797B2 - 通信装置、通信システム、通信装置の制御方法及びプログラム - Google Patents
通信装置、通信システム、通信装置の制御方法及びプログラム Download PDFInfo
- Publication number
- JP4537797B2 JP4537797B2 JP2004228590A JP2004228590A JP4537797B2 JP 4537797 B2 JP4537797 B2 JP 4537797B2 JP 2004228590 A JP2004228590 A JP 2004228590A JP 2004228590 A JP2004228590 A JP 2004228590A JP 4537797 B2 JP4537797 B2 JP 4537797B2
- Authority
- JP
- Japan
- Prior art keywords
- certificate
- communication
- request
- authentication
- public key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
この発明は、通信手段を備え、通信の際に通信相手に認証を受けるためにデジタル証明書を提供する通信装置、このような通信装置である下位装置とその通信相手となる上位装置によって構成される通信システム、通信の際に通信相手に認証を受けるためにデジタル証明書を提供させるための通信装置の制御方法、およびコンピュータを上記の通信装置として機能させるためのプログラムに関する。
従来から、それぞれ通信機能を備えた複数の通信装置をネットワークを介して通信可能に接続し、様々なシステムを構築することが行われている。その一例としては、クライアント装置として機能するＰＣ等のコンピュータから商品の注文を送信し、これとインターネットを介して通信可能なサーバ装置においてその注文を受け付けるといった、いわゆる電子商取引システムが挙げられる。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。
このようなシステムを構築する上では、通信を行う際に、通信相手が適切か、あるいは送信されてくる情報が改竄されていないかといった確認が重要である。また、特にインターネットにおいては、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばＳＳＬ（Secure Socket Layer）と呼ばれるプロトコルが開発されており、広く用いられている。このプロトコルを用いて通信を行うことにより、公開鍵暗号方式と共通鍵暗号方式とを組み合わせ、通信相手の認証を行うと共に、情報の暗号化により改竄及び盗聴の防止を図ることができる。また、通信相手の側でも、通信を要求してきた通信元の装置を認証することができる。
このようなＳＳＬや公開鍵暗号を用いた認証に関連する技術としては、例えば特許文献１及び特許文献２に記載のものが挙げられる。
特開２００２−３５３９５９号公報
特開２００２−２５１４９２号公報
このようなＳＳＬや公開鍵暗号を用いた認証に関連する技術としては、例えば特許文献１及び特許文献２に記載のものが挙げられる。
ここで、このＳＳＬに従った相互認証を行う場合の通信手順について、認証処理の部分に焦点を当てて説明する。図２４は、通信装置Ａと通信装置ＢとがＳＳＬに従った相互認証を行う際に各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図２４に示すように、ＳＳＬに従った相互認証を行う際には、まず双方の通信装置にルート鍵証明書及び、私有鍵と公開鍵証明書（これらをまとめて「証明書セット」と呼ぶ）を記憶させておく必要がある。この私有鍵は、認証局（ＣＡ：certificate authority）が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にＣＡがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、ＣＡがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。
図２４に示すように、ＳＳＬに従った相互認証を行う際には、まず双方の通信装置にルート鍵証明書及び、私有鍵と公開鍵証明書（これらをまとめて「証明書セット」と呼ぶ）を記憶させておく必要がある。この私有鍵は、認証局（ＣＡ：certificate authority）が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にＣＡがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、ＣＡがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。
図２５にこれらの関係を示す。
図２５（ａ）に示すように、公開鍵Ａは、私有鍵Ａを用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者（ＣＡ）や有効期限等の情報を含む書誌情報とによって構成される。そして、ＣＡは、鍵本体や書誌情報が改竄されていないことを示すため、公開鍵Ａをハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名として公開鍵Ａに付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Ａの書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、公開鍵証明書Ａである。
図２５（ａ）に示すように、公開鍵Ａは、私有鍵Ａを用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者（ＣＡ）や有効期限等の情報を含む書誌情報とによって構成される。そして、ＣＡは、鍵本体や書誌情報が改竄されていないことを示すため、公開鍵Ａをハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名として公開鍵Ａに付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Ａの書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、公開鍵証明書Ａである。
この公開鍵証明書Ａを認証処理に用いる場合には、ここに含まれるデジタル署名を、ルート私有鍵と対応する公開鍵であるルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば、デジタル署名が確かにＣＡによって付されたことがわかる。また、公開鍵Ａの部分をハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とが一致すれば、鍵自体も損傷や改竄を受けていないことがわかる。さらに、受信したデータをこの公開鍵Ａを用いて正常に復号化できれば、そのデータは、私有鍵Ａの持ち主から送信されたものであることがわかる。
ここで、認証を行うためには、ルート鍵を予め記憶しておく必要があるが、このルート鍵も、図２５（ｂ）に示すように、ＣＡがデジタル署名を付したルート鍵証明書として記憶しておく。このルート鍵証明書は、自身に含まれる公開鍵でデジタル署名を復号化可能な、自己署名形式である。そして、ルート鍵を使用する際に、そのルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し、ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば、ルート鍵が破損等していないことを確認できるのである。
図２４のフローチャートの説明に入る。なお、この図において、２本のフローチャート間の矢印は、データの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また、各ステップの処理が正常に完了しなかった場合には、その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合、処理がタイムアウトした場合等も同様である。
ここでは、通信装置Ａが通信装置Ｂに通信を要求するものとするが、この要求を行う場合、通信装置ＡのＣＰＵは、所要の制御プログラムを実行することにより、図２４の左側に示すフローチャートの処理を開始する。そして、ステップＳ１１で通信装置Ｂに対して接続要求を送信する。
一方通信装置ＢのＣＰＵは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図２４の右側に示すフローチャートの処理を開始する。そして、ステップＳ２１で第１の乱数を生成し、これを私有鍵Ｂを用いて暗号化する。そして、ステップＳ２２でその暗号化した第１の乱数と公開鍵証明書Ｂとを通信装置Ａに送信する。
一方通信装置ＢのＣＰＵは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図２４の右側に示すフローチャートの処理を開始する。そして、ステップＳ２１で第１の乱数を生成し、これを私有鍵Ｂを用いて暗号化する。そして、ステップＳ２２でその暗号化した第１の乱数と公開鍵証明書Ｂとを通信装置Ａに送信する。
通信装置Ａ側では、これを受信すると、ステップＳ１２でルート鍵証明書を用いて公開鍵証明書Ｂの正当性を確認する。
そして確認ができると、ステップＳ１３で、受信した公開鍵証明書Ｂに含まれる公開鍵Ｂを用いて第１の乱数を復号化する。ここで復号化が成功すれば、第１の乱数は確かに公開鍵証明書Ｂの発行対象から受信したものだと確認できる。
その後、ステップＳ１４でこれとは別に第２の乱数及び共通鍵の種を生成する。共通鍵の種は、例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして、ステップＳ１５で第２の乱数を私有鍵Ａを用いて暗号化し、共通鍵の種を公開鍵Ｂを用いて暗号化し、ステップＳ１６でこれらを公開鍵証明書Ａと共にサーバ装置に送信する。共通鍵の種の暗号化は、通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。
また、次のステップＳ１７では、ステップＳ１４で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
そして確認ができると、ステップＳ１３で、受信した公開鍵証明書Ｂに含まれる公開鍵Ｂを用いて第１の乱数を復号化する。ここで復号化が成功すれば、第１の乱数は確かに公開鍵証明書Ｂの発行対象から受信したものだと確認できる。
その後、ステップＳ１４でこれとは別に第２の乱数及び共通鍵の種を生成する。共通鍵の種は、例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして、ステップＳ１５で第２の乱数を私有鍵Ａを用いて暗号化し、共通鍵の種を公開鍵Ｂを用いて暗号化し、ステップＳ１６でこれらを公開鍵証明書Ａと共にサーバ装置に送信する。共通鍵の種の暗号化は、通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。
また、次のステップＳ１７では、ステップＳ１４で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
通信装置Ｂ側では、通信装置ＡがステップＳ１６で送信してくるデータを受信すると、ステップＳ２３でルート鍵証明書を用いて公開鍵証明書Ａの正当性を確認する。そして確認ができると、ステップＳ２４で、受信した公開鍵証明書Ａに含まれる公開鍵Ａを用いて第２の乱数を復号化する。ここで復号化が成功すれば、第２の乱数は確かに公開鍵証明書Ａの発行対象から受信したものだと確認できる。
その後、ステップＳ２５で私有鍵Ｂを用いて共通鍵の種を復号化する。ここまでの処理で、通信装置Ａ側と通信装置Ｂ側に共通鍵の種が共有されたことになる。そして、この共通鍵の種は、生成した通信装置Ａと、私有鍵Ｂを持つ通信装置Ｂ以外の装置が知ることはない。ここまでの処理が成功すると、通信装置Ｂ側でもステップＳ２６で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
その後、ステップＳ２５で私有鍵Ｂを用いて共通鍵の種を復号化する。ここまでの処理で、通信装置Ａ側と通信装置Ｂ側に共通鍵の種が共有されたことになる。そして、この共通鍵の種は、生成した通信装置Ａと、私有鍵Ｂを持つ通信装置Ｂ以外の装置が知ることはない。ここまでの処理が成功すると、通信装置Ｂ側でもステップＳ２６で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
そして、通信装置Ａ側のステップＳ１７と通信装置Ｂ側のステップＳ２６の処理が終了すると、相互に認証の成功と以後の通信に使用する暗号化方式とを確認し、生成した共通鍵を用いてその暗号化方式で以後の通信を行うものとして認証に関する処理を終了する。なお、この確認には、通信装置Ｂからの認証が成功した旨の応答も含むものとする。以上の処理によって互いに通信を確立し、以後はステップＳ１７又はＳ２６で生成した共通鍵を用い、共通鍵暗号方式でデータを暗号化して通信を行うことができる。
このような処理を行うことにより、通信装置Ａと通信装置Ｂが安全に共通鍵を共有することができ、通信を安全に行う経路を確立することができる。
ただし、上述した処理において、第２の乱数を公開鍵Ａで暗号化し、公開鍵証明書Ａを通信装置Ｂに送信することは必須ではない。この場合、通信装置Ｂ側のステップＳ２３及びＳ２４の処理は不要になり、処理は図２６に示すようになる。このようにすると、通信装置Ｂが通信装置Ａを認証することはできないが、通信装置Ａが通信装置Ｂを認証するだけでよい場合にはこの処理で十分である。そしてこの場合には、通信装置Ａに記憶させるのはルート鍵証明書のみでよく、私有鍵Ａ及び公開鍵証明書Ａは不要である。また、通信装置Ｂにはルート鍵証明書を記憶させる必要はない。
ただし、上述した処理において、第２の乱数を公開鍵Ａで暗号化し、公開鍵証明書Ａを通信装置Ｂに送信することは必須ではない。この場合、通信装置Ｂ側のステップＳ２３及びＳ２４の処理は不要になり、処理は図２６に示すようになる。このようにすると、通信装置Ｂが通信装置Ａを認証することはできないが、通信装置Ａが通信装置Ｂを認証するだけでよい場合にはこの処理で十分である。そしてこの場合には、通信装置Ａに記憶させるのはルート鍵証明書のみでよく、私有鍵Ａ及び公開鍵証明書Ａは不要である。また、通信装置Ｂにはルート鍵証明書を記憶させる必要はない。
ところで、以上の認証処理においては、公開鍵で暗号化された内容は対応する私有鍵を持つ装置でしか復号できず、また、私有鍵で暗号化された内容は対応する公開鍵でしか復号できないことを利用して、通信相手が公開鍵証明書にその発行先として記載されている装置である（又はその装置の利用者が公開鍵証明書にその発行先として記載されている利用者である）と認証することになる。
また、ＣＡのルート私有鍵の秘密保全性を前提にして、公開鍵証明書はＣＡが認証したものであり、ＣＡ（の提供者）が公開鍵証明書の記載内容の正確性を保証していることもわかる。しかし、通信相手が確かに公開鍵証明書に記載されている装置と同一であることは、公開鍵証明書を発行したＣＡの保証を信頼して判断する他ない。従って、ＣＡの信頼性は、公開鍵暗号を用いた認証による通信の安全確保の際に重要なファクターとなる。
また、ＣＡのルート私有鍵の秘密保全性を前提にして、公開鍵証明書はＣＡが認証したものであり、ＣＡ（の提供者）が公開鍵証明書の記載内容の正確性を保証していることもわかる。しかし、通信相手が確かに公開鍵証明書に記載されている装置と同一であることは、公開鍵証明書を発行したＣＡの保証を信頼して判断する他ない。従って、ＣＡの信頼性は、公開鍵暗号を用いた認証による通信の安全確保の際に重要なファクターとなる。
一方で、暗号化や認証の技術は日々進歩しており、より強度の高い暗号やその暗号を利用した認証の技術が提案され、実用化されている。このような強度の高い暗号は、上記の公開鍵暗号の場合には、鍵長を長くする、より強度の高い暗号方式を採用するなどによって実現される。そして、このように暗号強度が強い方式が実用化された場合、セキュリティレベルを考慮してそれらの方式を採用することが考えられる。
このようなとき、通信システム上で暗号強度の高いデジタル証明書が発行され運用され始めた場合、通信装置が従来から記憶しているデジタル証明書では通信相手から認証を受けられない状態となってしまう場合があるという問題があった。
このようなとき、通信システム上で暗号強度の高いデジタル証明書が発行され運用され始めた場合、通信装置が従来から記憶しているデジタル証明書では通信相手から認証を受けられない状態となってしまう場合があるという問題があった。
このような問題は、操作者が認証を受けられない状態となった時点で装置を操作し新たなデジタル証明書を容易に設定できるような場合は、操作者を認証する等してセキュリティを保持できるため、さほど深刻にはならない。しかし、ユーザの習熟度や利用環境から操作者による設定が困難であったり、装置の運用上、操作者に自由に証明書を設定させることが好ましくなかったりする等の理由で通信システム上の他の通信装置からリモートで証明書を設定するようにする場合には、認証が行えない状態ではセキュリティを保持するための手段がなく、この点が深刻な問題となる。
この発明は、このような問題を解決し、通信手段を備え、通信の際に通信相手に認証を受けるためにデジタル証明書を提供する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、セキュリティを維持しながら、正常な認証を受けられる状態を容易に維持できるようにすることを目的とする。
この発明は、このような問題を解決し、通信手段を備え、通信の際に通信相手に認証を受けるためにデジタル証明書を提供する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、セキュリティを維持しながら、正常な認証を受けられる状態を容易に維持できるようにすることを目的とする。
上記の目的を達成するため、この発明の通信装置は、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、上記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置において、上記通信手段を、異なる暗号強度での認証処理に対応した２種類のデジタル証明書の提供を行い、上記複数のアドレスのうち第１のアドレスでは上記２種類のデジタル証明書のうち暗号強度が高い方の認証処理に対応した第１の証明書を提供し、第２のアドレスでは上記２種類のデジタル証明書のうち暗号強度が低い方の認証処理に対応した第２の証明書を提供する手段とし、上記第２のアドレスで通信を行う場合には上記第１の証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段を設けたものである。
このような通信装置において、上記デジタル証明書を提供した通信相手からその通信相手のデジタル証明書を受信して認証を行い、その認証が成功した場合のみその後の通信を許可する認証手段を設け、上記要求実行手段に、その通信相手から上記第１の証明書の設定要求を受信した場合に上記第１の証明書を更新する手段を設けるとよい。
さらに、上記第１の証明書の設定に関する要求を、上記第１の証明書の作成に必要な情報の取得要求と上記第１の証明書の設定要求とするとよい。
さらに、上記第１の証明書の設定に関する要求を、上記第１の証明書の作成に必要な情報の取得要求と上記第１の証明書の設定要求とするとよい。
さらに、上記要求実行手段に、上記要求に対応する所定の処理を行う複数の要求処理手段を設け、受信したアドレスと要求の種類とに従って要求を上記各要求処理手段に振り分ける振り分け手段を設け、上記禁止手段を、上記振り分け手段が上記通信を行っているアドレスによっては所定の要求以外の要求を上記要求処理手段に振り分けないようにすることにより、上記処理の禁止を行う手段とするとよい。
さらにまた、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらにまた、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
さらにまた、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらにまた、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
また、この発明の通信システムは、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、上記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する下位装置と、その下位装置の通信相手となる上位装置とによって構成される通信システムにおいて、上記下位装置の上記通信手段を、異なる暗号強度での認証処理に対応した２種類のデジタル証明書の提供を行い、上記複数のアドレスのうち第１のアドレスでは上記２種類のデジタル証明書のうち暗号強度が高い方の認証処理に対応した第１の証明書を提供し、第２のアドレスでは上記２種類のデジタル証明書のうち暗号強度が低い方の認証処理に対応した第２の証明書を提供する手段とし、上記下位装置に、上記第２のアドレスで通信を行う場合には上記第１の証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段を設け、上記上位装置に、通信相手から受信したデジタル証明書を用いてその通信相手を認証する認証手段を設けたものである。
このような通信システムにおいて、上記下位装置に、上記デジタル証明書を提供した通信相手からその通信相手のデジタル証明書を受信して認証を行い、その認証が成功した場合のみその後の通信を許可する認証手段を設け、上記下位装置の上記要求実行手段に、通信相手から上記第１の証明書の設定要求を受信した場合に上記第１の証明書を更新する手段を設けるとよい。
さらに、上記第１の証明書の設定に関する要求を、上記第１の証明書の作成に必要な情報の取得要求と上記第１の証明書の設定要求とするとよい。
さらに、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらにまた、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
さらに、上記第１の証明書の設定に関する要求を、上記第１の証明書の作成に必要な情報の取得要求と上記第１の証明書の設定要求とするとよい。
さらに、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらにまた、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
また、この発明の通信装置の制御方法は、通信装置に、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供させ、上記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行わせ、その通信において通信相手から受信した要求に応じた処理を行わせる通信装置の制御方法において、上記通信装置に、異なる暗号強度での認証処理に対応した２種類のデジタル証明書の提供を行わせ、上記複数のアドレスのうち第１のアドレスでは上記２種類のデジタル証明書のうち暗号強度が高い方の認証処理に対応した第１の証明書を提供させ、第２のアドレスでは上記２種類のデジタル証明書のうち暗号強度が低い方の認証処理に対応した第２の証明書を提供させ、上記第２のアドレスで通信を行う場合には上記第１の証明書の設定に関する要求以外の要求に係る処理を禁止させるようにしたものである。
このような通信装置の制御方法において、さらに、上記通信装置に、上記デジタル証明書を提供した通信相手からその通信相手のデジタル証明書を受信させて認証を行わせ、その認証が成功した場合のみその後の通信を許可させるようにし、通信相手から上記第１の証明書の設定要求を受信した場合に上記第１の証明書を更新させるようにするとよい。
さらに、上記第１の証明書の設定に関する要求を、上記第１の証明書の作成に必要な情報の取得要求と上記第１の証明書の設定要求とするとよい。
さらに、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらにまた、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
さらに、上記第１の証明書の設定に関する要求を、上記第１の証明書の作成に必要な情報の取得要求と上記第１の証明書の設定要求とするとよい。
さらに、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらにまた、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
また、この発明のプログラムは、コンピュータを、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、上記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、その通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段として機能させるためのプログラムにおいて、上記通信手段を、異なる暗号強度での認証処理に対応した２種類のデジタル証明書の提供を行い、上記複数のアドレスのうち第１のアドレスでは上記２種類のデジタル証明書のうち暗号強度が高い方の認証処理に対応した第１の証明書を提供し、第２のアドレスでは上記２種類のデジタル証明書のうち暗号強度が低い方の認証処理に対応した第２の証明書を提供する手段とし、さらに、上記コンピュータを、上記第２のアドレスで通信を行う場合には上記第１の証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段として機能させるためのプログラムを含めたものである。
このようなプログラムにおいて、上記コンピュータを、上記デジタル証明書を提供した通信相手からその通信相手のデジタル証明書を受信して認証を行い、その認証が成功した場合のみその後の通信を許可する認証手段として機能させるためのプログラムを含め、上記要求実行手段に、その通信相手から上記第１の証明書の設定要求を受信した場合に上記第１の証明書を更新する機能を設けるとよい。
さらに、上記第１の証明書の設定に関する要求を、上記第１の証明書の作成に必要な情報の取得要求と上記第１の証明書の設定要求とするとよい。
さらに、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらにまた、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
さらに、上記第１の証明書の設定に関する要求を、上記第１の証明書の作成に必要な情報の取得要求と上記第１の証明書の設定要求とするとよい。
さらに、上記要求をＳＯＡＰメッセージとして記載するようにするとよい。
さらにまた、上記認証を、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
以上のようなこの発明の通信装置、通信システムあるいは通信装置の制御方法によれば、通信手段を備え、通信の際に通信相手に認証を受けるためにデジタル証明書を提供する通信装置あるいはこのような通信装置を用いて構成した通信システムにおいて、セキュリティを維持しながら、正常な認証を受けられる状態を容易に維持できるようにすることができる。
また、この発明のプログラムによれば、コンピュータを上記の通信装置として機能させてその特徴を実現し、同様な効果を得ることができる。
また、この発明のプログラムによれば、コンピュータを上記の通信装置として機能させてその特徴を実現し、同様な効果を得ることができる。
以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明による通信装置と、その通信装置を用いて構成したこの発明の通信システムの実施形態の構成について説明する。
図１はその通信システムの構成を示すブロック図である。
この通信システムは、図１に示すように、それぞれ通信装置である上位装置１０及び下位装置２０をネットワーク３０によって接続して構成されている。そして、下位装置２０がこの発明の通信装置の実施形態である。また、上位装置１０も通信機能を備えた通信装置である。
ネットワーク３０としては、有線，無線を問わず、ネットワークを構築可能な各種通信回線（通信経路）を採用することができる。また、ここでは下位装置２０を１つしか示していないが、図２３に示すように通信システム内に下位装置２０を複数設けることも可能である。
まず、この発明による通信装置と、その通信装置を用いて構成したこの発明の通信システムの実施形態の構成について説明する。
図１はその通信システムの構成を示すブロック図である。
この通信システムは、図１に示すように、それぞれ通信装置である上位装置１０及び下位装置２０をネットワーク３０によって接続して構成されている。そして、下位装置２０がこの発明の通信装置の実施形態である。また、上位装置１０も通信機能を備えた通信装置である。
ネットワーク３０としては、有線，無線を問わず、ネットワークを構築可能な各種通信回線（通信経路）を採用することができる。また、ここでは下位装置２０を１つしか示していないが、図２３に示すように通信システム内に下位装置２０を複数設けることも可能である。
このような通信システムについて、まず上位装置１０及び下位装置２０のハードウェア構成から説明する。上位装置１０及び下位装置２０のハードウェア構成は、単純化して示すと、図２に示すようなものである。
この図に示す通り、上位装置１０は、ＣＰＵ１１，ＲＯＭ１２，ＲＡＭ１３，ＨＤＤ１４，通信インタフェース（Ｉ／Ｆ）１５を備え、これらがシステムバス１６によって接続されている。そして、ＣＰＵ１１がＲＯＭ１２やＨＤＤ１４に記憶している各種制御プログラムを実行することによってこの上位装置１０の動作を制御し、通信相手の認証や下位装置２０のデジタル証明書更新等の機能を実現している。なお、この明細書において、デジタル証明書とは、偽造されないようにするための署名が付されたデジタルデータを指すものとする。
この図に示す通り、上位装置１０は、ＣＰＵ１１，ＲＯＭ１２，ＲＡＭ１３，ＨＤＤ１４，通信インタフェース（Ｉ／Ｆ）１５を備え、これらがシステムバス１６によって接続されている。そして、ＣＰＵ１１がＲＯＭ１２やＨＤＤ１４に記憶している各種制御プログラムを実行することによってこの上位装置１０の動作を制御し、通信相手の認証や下位装置２０のデジタル証明書更新等の機能を実現している。なお、この明細書において、デジタル証明書とは、偽造されないようにするための署名が付されたデジタルデータを指すものとする。
下位装置２０も、上位装置１０の場合と同様にＣＰＵ２１，ＲＯＭ２２，ＲＡＭ２３，ＨＤＤ２４，通信インタフェース（Ｉ／Ｆ）２５を備え、これらがシステムバス２６によって接続されている。ＣＰＵ２１が、ＲＯＭ２２やＨＤＤ２４に記憶している各種制御プログラムを必要に応じて実行し、装置の制御を行うことにより、通信手段、禁止手段、認証手段、要求実行手段、振り分け手段等の種々の手段としての機能を実現できるようにしている。
なお、この通信システムにおいて、上位装置１０及び下位装置２０が、遠隔管理，電子商取引等の目的に応じて種々の構成をとることができることは、もちろんである。そして、上位装置１０や下位装置２０のハードウェアとしては、適宜公知のコンピュータを採用することもできる。もちろん、必要に応じて他のハードウェアを付加してもよいし、上位装置１０と下位装置２０が同一の構成である必要もない。
なお、この通信システムにおいて、上位装置１０及び下位装置２０が、遠隔管理，電子商取引等の目的に応じて種々の構成をとることができることは、もちろんである。そして、上位装置１０や下位装置２０のハードウェアとしては、適宜公知のコンピュータを採用することもできる。もちろん、必要に応じて他のハードウェアを付加してもよいし、上位装置１０と下位装置２０が同一の構成である必要もない。
次に、この通信システムにおける通信方式について説明する。図３はその通信方式の概要を示す説明図である。
この通信システムにおいて、上位装置１０は、下位装置２０と通信を行おうとする場合、まず下位装置２０に対して通信を要求する。そして、従来の技術の項で図２４又は図２６を用いて説明したようなＳＳＬプロトコルに従った認証処理によって下位装置２０を正当な通信相手として認証した場合に、下位装置２０との間で通信を確立させるようにしている。この認証処理は、ＳＳＬハンドシェイクと呼ばれる。ただし、図２４に示したような相互認証は必須ではなく、図２６に示したような片方向認証でもよい。
この処理において、下位装置２０は自身の公開鍵証明書を上位装置１０に送信して、認証を受ける。そして、相互認証を行う場合には上位装置１０も下位装置２０に自身の公開鍵証明書を送信して認証を受けるが、片方向認証の場合にはこちらの認証は行わない。そして、相互認証の場合には、上位装置１０から受信した公開鍵証明書により認証を行う際に、下位装置２０のＣＰＵが認証手段として機能する。
この通信システムにおいて、上位装置１０は、下位装置２０と通信を行おうとする場合、まず下位装置２０に対して通信を要求する。そして、従来の技術の項で図２４又は図２６を用いて説明したようなＳＳＬプロトコルに従った認証処理によって下位装置２０を正当な通信相手として認証した場合に、下位装置２０との間で通信を確立させるようにしている。この認証処理は、ＳＳＬハンドシェイクと呼ばれる。ただし、図２４に示したような相互認証は必須ではなく、図２６に示したような片方向認証でもよい。
この処理において、下位装置２０は自身の公開鍵証明書を上位装置１０に送信して、認証を受ける。そして、相互認証を行う場合には上位装置１０も下位装置２０に自身の公開鍵証明書を送信して認証を受けるが、片方向認証の場合にはこちらの認証は行わない。そして、相互認証の場合には、上位装置１０から受信した公開鍵証明書により認証を行う際に、下位装置２０のＣＰＵが認証手段として機能する。
以上の認証が成功すると、上位装置１０は、下位装置２０が実装するアプリケーションプログラムのメソッドに対する処理の依頼である要求を、構造化言語形式であるＸＭＬ形式で記載したＳＯＡＰメッセージとして生成し、ＨＴＴＰ（Hyper Text Transfer Protocol）に従ってＨＴＴＰリクエスト４０として下位装置２０に送信する。このような要求は、ＲＰＣ（Remote Procedure Call）と呼ばれる。
そして、下位装置２０はこの要求の内容に応じた処理を実行し、その結果を応答のＳＯＡＰメッセージとして生成し、ＨＴＴＰレスポンス５０として上位装置１０に送信する。ここで、これらの要求と応答は、ＳＳＬハンドシェイクの処理において共有された共通鍵を用いて暗号化して送信し、通信の安全性を確保している。
そして、下位装置２０はこの要求の内容に応じた処理を実行し、その結果を応答のＳＯＡＰメッセージとして生成し、ＨＴＴＰレスポンス５０として上位装置１０に送信する。ここで、これらの要求と応答は、ＳＳＬハンドシェイクの処理において共有された共通鍵を用いて暗号化して送信し、通信の安全性を確保している。
また、これらの要求と応答とによって、この通信システムは、上位装置１０をクライアント、下位装置２０をサーバとするクライアント・サーバシステムとして機能している。
なお、ＲＰＣを実現するためには、上記の技術の他、ＦＴＰ（File Transfer Protocol）,ＣＯＭ（Component Object Model），ＣＯＲＢＡ（Common Object Request Broker Architecture）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。
なお、ＲＰＣを実現するためには、上記の技術の他、ＦＴＰ（File Transfer Protocol）,ＣＯＭ（Component Object Model），ＣＯＲＢＡ（Common Object Request Broker Architecture）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。
次に、上述した上位装置１０及び下位装置２０が上述した認証処理に用いる認証情報である各証明書や鍵の特性及び用途について説明する。図４は、（ａ）に上位装置１０が認証情報として記憶している証明書及び鍵の種類を示し、（ｂ）に下位装置２０が認証情報として記憶している証明書及び鍵の種類を示す図である。
図１に示した上位装置１０及び下位装置２０は、図４に示すように、大きく分けて正規認証情報とレスキュー認証情報を記憶している。そして、これらの正規認証情報とレスキュー認証情報は、それぞれ自分に関する認証情報である公開鍵証明書及び私有鍵と、通信相手に関する認証情報であるルート鍵証明書とによって構成される。
図１に示した上位装置１０及び下位装置２０は、図４に示すように、大きく分けて正規認証情報とレスキュー認証情報を記憶している。そして、これらの正規認証情報とレスキュー認証情報は、それぞれ自分に関する認証情報である公開鍵証明書及び私有鍵と、通信相手に関する認証情報であるルート鍵証明書とによって構成される。
また、例えば下位装置用通常公開鍵証明書は、証明書管理装置が下位装置２０に対して発行した通常公開鍵に、下位装置認証用通常ルート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書であり、第１の証明書に該当する。
ここで、公開鍵証明書のフォーマットは、例えば図５に示したものを用いることができ、公開鍵そのものの他、証明書の発行者や証明書の有効期限、証明される対象（証明書の発行先の装置あるいは利用者）等の情報が記載されている。具体的には、例えばＸ．５０９と呼ばれるフォーマットに従って作成することができ、このフォーマットに従って作成された公開鍵証明書は、例えば図６に示すようなものになる。
この例においては、ＡがＣＡの識別情報を示し、Ｃが証明書の発行先の装置の識別情報を示す。これらは、それぞれ所在地、名称、機番あるいはコード等の情報を含む。また、Ｂが有効期間を示し、その開始日時と終了日時によって有効期間を指定している。また、Ｄが公開鍵証明書に含まれる公開鍵の長さ（ここでは１０２４ビット）を、ＥがＣＡがデジタル署名に用いたアルゴリズム（ここでは「md5WithRSAEncryption」）をそれぞれ示している。
ここで、公開鍵証明書のフォーマットは、例えば図５に示したものを用いることができ、公開鍵そのものの他、証明書の発行者や証明書の有効期限、証明される対象（証明書の発行先の装置あるいは利用者）等の情報が記載されている。具体的には、例えばＸ．５０９と呼ばれるフォーマットに従って作成することができ、このフォーマットに従って作成された公開鍵証明書は、例えば図６に示すようなものになる。
この例においては、ＡがＣＡの識別情報を示し、Ｃが証明書の発行先の装置の識別情報を示す。これらは、それぞれ所在地、名称、機番あるいはコード等の情報を含む。また、Ｂが有効期間を示し、その開始日時と終了日時によって有効期間を指定している。また、Ｄが公開鍵証明書に含まれる公開鍵の長さ（ここでは１０２４ビット）を、ＥがＣＡがデジタル署名に用いたアルゴリズム（ここでは「md5WithRSAEncryption」）をそれぞれ示している。
また、下位装置用通常私有鍵は、上記の通常公開鍵と対応する私有鍵、下位装置認証用通常ルート鍵証明書は、下位装置認証用通常ルート鍵に自身と対応するルート私有鍵を用いて自身で正当性を確認可能なデジタル署名を付したデジタル証明書である。
そして、下位装置２０を複数設けた場合でも、各装置の通常公開鍵に付すデジタル署名は同じルート私有鍵を用いて付し、正当性確認に必要な通常ルート鍵証明書は共通にする。しかし、通常公開鍵証明書に含まれる通常公開鍵やこれと対応する私有鍵は、装置毎に異なる。
上位装置用通常公開鍵証明書と上位装置用通常私有鍵と上位装置認証用通常ルート鍵証明書も同様な関係である。
なお、各装置に、複数の認証局が発行した公開鍵証明書の正当性を確認できるようにするため、それらの各認証局と対応したルート鍵証明書を記憶させるようにすることも考えられる。
そして、下位装置２０を複数設けた場合でも、各装置の通常公開鍵に付すデジタル署名は同じルート私有鍵を用いて付し、正当性確認に必要な通常ルート鍵証明書は共通にする。しかし、通常公開鍵証明書に含まれる通常公開鍵やこれと対応する私有鍵は、装置毎に異なる。
上位装置用通常公開鍵証明書と上位装置用通常私有鍵と上位装置認証用通常ルート鍵証明書も同様な関係である。
なお、各装置に、複数の認証局が発行した公開鍵証明書の正当性を確認できるようにするため、それらの各認証局と対応したルート鍵証明書を記憶させるようにすることも考えられる。
そして、例えば上位装置１０と下位装置２０とが正規認証情報を用いて相互認証を行う場合には、上位装置１０からの通信要求に応じて、下位装置２０は下位装置用通常私有鍵を用いて暗号化した第１の乱数を下位装置用通常公開鍵証明書と共に上位装置１０に送信する。上位装置１０側では下位装置認証用通常ルート鍵証明書を用いてまずこの下位装置用通常公開鍵証明書の正当性（損傷や改竄を受けていないこと）を確認し、これが確認できた場合にここに含まれる公開鍵で第１の乱数を復号化する。この復号化が成功した場合に、上位装置１０は通信相手の下位装置２０が確かに下位装置用通常公開鍵証明書の発行先であると認識でき、その証明書に含まれる識別情報から装置を特定することができる。そして、特定した装置が通信相手としてふさわしいか否かに応じて認証の成功と失敗を決定することができる。
また、下位装置２０側でも、上位装置１０側で認証が成功した場合に送信されてくる上位装置用通常公開鍵証明書及び、上位装置用通常私有鍵で暗号化された乱数を受信し、記憶している上位装置認証用ルート鍵証明書を用いて同様な認証を行うことができる。
また、下位装置２０側でも、上位装置１０側で認証が成功した場合に送信されてくる上位装置用通常公開鍵証明書及び、上位装置用通常私有鍵で暗号化された乱数を受信し、記憶している上位装置認証用ルート鍵証明書を用いて同様な認証を行うことができる。
ところで、既に述べたように、各装置が通信相手から通常公開鍵証明書を受信した場合、その発行元の認証局が発行した公開鍵証明書の正当性を確認するためのルート鍵（証明書）を記憶していなければ、受信した通常公開鍵証明書の正当性を確認することができない。従って、この場合には認証を行うことができないことになる。
また、各装置が通信相手から受信した通常公開鍵証明書による認証を行うための機能（暗号化／復号化を実現するためのモジュール等）を備えていなければ、当然のことながらその通常公開鍵証明書による認証を行うことはできない。上位装置１０において認証処理に使用する証明書を切り替えたり、下位装置２０が以前と異なる認証局の証明書を使用する上位装置１０を含む通信システムに接続される等した場合には、このような事態が発生することも考えられる。
どの認証方式に対応した証明書を採用するか、あるいはどの認証局が発行する証明書を採用するかは、通信システムの運用者が種々の条件を考慮して適宜定めるものだからである。そして、暗合強度の高い新しい方式が実用化された場合には、運用者の裁量でこのような方式を適宜採用することが考えられる。
また、各装置が通信相手から受信した通常公開鍵証明書による認証を行うための機能（暗号化／復号化を実現するためのモジュール等）を備えていなければ、当然のことながらその通常公開鍵証明書による認証を行うことはできない。上位装置１０において認証処理に使用する証明書を切り替えたり、下位装置２０が以前と異なる認証局の証明書を使用する上位装置１０を含む通信システムに接続される等した場合には、このような事態が発生することも考えられる。
どの認証方式に対応した証明書を採用するか、あるいはどの認証局が発行する証明書を採用するかは、通信システムの運用者が種々の条件を考慮して適宜定めるものだからである。そして、暗合強度の高い新しい方式が実用化された場合には、運用者の裁量でこのような方式を適宜採用することが考えられる。
ここで、各装置が通常公開鍵証明書を用いた認証（通常認証情報を用いた認証）しか行えないとすると、このように認証処理に対応していなかったり、証明書の正当性が確認できなかったりする状態では、使用可能な通常公開鍵証明書や通常私有鍵及び通常ルート鍵証明書等を設定しようとしても、これらをネットワークを介して安全に対象の装置に送信する方法はないことになる。
また、装置の電源がＯＦＦされていたことにより自動更新が行えずに証明書の有効期限が切れてしまったり、更新処理中に電源がＯＦＦされる等により証明書が破損してしまったりした場合にも、認証が行えない状態になってしまうが、このような場合にも同様な問題が発生する。
また、装置の電源がＯＦＦされていたことにより自動更新が行えずに証明書の有効期限が切れてしまったり、更新処理中に電源がＯＦＦされる等により証明書が破損してしまったりした場合にも、認証が行えない状態になってしまうが、このような場合にも同様な問題が発生する。
しかし、この実施形態の通信システムを構成する各通信装置は、このような事態に対処するためにレスキュー認証情報を記憶しており、通信相手を異なる２種類のデジタル証明書を用いて認証することができるようにしている。そして、レスキュー認証情報を用いることにより、必要な装置にネットワークを介して新たな通常公開鍵証明書等を安全に送受信できるようにしている。
このレスキュー認証情報は、正規認証情報と概ね同様な構成となっており、例えば下位装置用レスキュー公開鍵証明書は、長期証明書であり、ＣＡが下位装置に対して発行したレスキュー公開鍵に、下位装置認証用レスキュールート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書であり、第２の証明書に該当する。また、下位装置用レスキュー私有鍵はそのレスキュー公開鍵と対応する私有鍵、下位装置認証用レスキュールート鍵証明書は、下位装置認証用レスキュールート鍵に自身を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。
ここで、図７に通常公開鍵証明書の例を、図８にレスキュー公開鍵証明書の例を示す。
これらは、符号Ｈ及びＭで示すように、発行先の装置の識別情報が同一であり、同じ装置に対して発行された公開鍵証明書である。しかし、通常公開鍵証明書では符号Ｉで示すように公開鍵の鍵長を２０４８ビットとしているのに対し、レスキュー公開鍵証明書では公開鍵の鍵長は符号Ｎで示すように１０２４ビットとしている。
これらは、符号Ｈ及びＭで示すように、発行先の装置の識別情報が同一であり、同じ装置に対して発行された公開鍵証明書である。しかし、通常公開鍵証明書では符号Ｉで示すように公開鍵の鍵長を２０４８ビットとしているのに対し、レスキュー公開鍵証明書では公開鍵の鍵長は符号Ｎで示すように１０２４ビットとしている。
すなわち、通常公開鍵証明書では、より暗号強度の高い認証処理（ここでは２０４８ビットの公開鍵や私有鍵を用いた認証処理）に対応させてセキュリティの強化を図る一方、レスキュー公開鍵証明書では、より暗号強度の低い認証処理（ここでは１０２４ビットの公開鍵や私有鍵を用いた認証処理）に対応させるようにしている。このようにすることにより、通信システムが暗号強度の高い認証処理に対応していない場合であっても、適当なルート鍵証明書を通信システムを構成し得る各装置に記憶させておけば、レスキュー公開鍵証明書を用いた認証処理を行うことができる。
そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができる。従って、この通信経路を利用して、通信時点の環境に適合した新しい通常公開鍵証明書を通信相手に送信し、設定させることが可能となる。
そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができる。従って、この通信経路を利用して、通信時点の環境に適合した新しい通常公開鍵証明書を通信相手に送信し、設定させることが可能となる。
なお、レスキュー公開鍵証明書における暗号強度や認証処理の内容は、輸出規制や、各地域で普及している認証処理の内容等を考慮しても、下位装置２０が使用されると想定される種々の環境で共通に使用できるような認証処理により認証を行うことができるようなものにする。このようにすることにより、レスキュー公開鍵証明書（を含むレスキュー認証情報）を、通常公開鍵証明書を用いた認証処理が行えなかった場合に非常用の通信経路を確保するための認証情報として使用することができる。
また、ここではデジタル署名に用いるアルゴリズムは通常公開鍵証明書とレスキュー公開鍵証明書とで共通としているが、これらを別々のものにしてもよい。
また、ここではデジタル署名に用いるアルゴリズムは通常公開鍵証明書とレスキュー公開鍵証明書とで共通としているが、これらを別々のものにしてもよい。
また、暗号強度の低い認証処理に対応したレスキュー公開鍵証明書は、暗号強度の高い認証処理に対応した通常公開鍵証明書と比べた場合に、安全性や信頼性が劣ることも考えられる。しかし、レスキュー認証情報を用いて認証処理を行った場合に、通常公開鍵証明書を始めとする正規認証情報の更新のような限られた要求のみ実行を許可するようにすれば、この点は大きな問題にはならない。
ここで、図７及び図８の説明に戻ると、これらの２つの公開鍵証明書において、通常公開鍵証明書では証明書の発行者を符号Ｆで示すようにＹＹＹ社の「ＰｕｂｌｉｃＣＡ」とする一方、レスキュー公開鍵証明書では符号Ｋで示すようにＸＸＸ社の「ＰｒｉｖａｔｅＣＡ」としており、発行者を異なるＣＡとしている。「ＰｕｂｌｉｃＣＡ」はパブリック認証局、「ＰｒｉｖａｔｅＣＡ」はプライベート認証局に該当するものとする。
そして、パブリック認証局とは、広く世間で信頼性が認められた認証局、あるいは公的に信頼性が認められた認証局、法的に証明書の効力が認められるような認証局等、一般的に通用するような証明書を発行できる認証局を指すものとする。このようなパブリック認証局により公開鍵証明書を発行する商用サービスは、例えばベリサイン社やボルチモア社のような第３者機関によって提供されている。また、パブリック認証局は、証明書の利用者と異なる運営者が運営する認証局である。
一方、プライベート認証局とは、特に世間に広く信頼性が認められているわけではなく、発行する証明書が一般的に通用するわけではない認証局を指すものとする。また、証明書の利用者が運営する認証局であり、例えば、自社内で利用する証明書を管理するためにその企業が運営する認証局である。ここでは、プライベート認証局は、発行先装置のメーカーであるＸＸＸ社が設けている。
そして、パブリック認証局とは、広く世間で信頼性が認められた認証局、あるいは公的に信頼性が認められた認証局、法的に証明書の効力が認められるような認証局等、一般的に通用するような証明書を発行できる認証局を指すものとする。このようなパブリック認証局により公開鍵証明書を発行する商用サービスは、例えばベリサイン社やボルチモア社のような第３者機関によって提供されている。また、パブリック認証局は、証明書の利用者と異なる運営者が運営する認証局である。
一方、プライベート認証局とは、特に世間に広く信頼性が認められているわけではなく、発行する証明書が一般的に通用するわけではない認証局を指すものとする。また、証明書の利用者が運営する認証局であり、例えば、自社内で利用する証明書を管理するためにその企業が運営する認証局である。ここでは、プライベート認証局は、発行先装置のメーカーであるＸＸＸ社が設けている。
パブリック認証局の発行する公開鍵証明書は、厳格な管理がなされ、安全性や信頼性が広く一般に認められていることから、通常公開鍵証明書としては、このような証明書を採用するとよい。しかし、パブリック認証局の発行する公開鍵証明書は、厳格な管理や安全性が要求されるため、レスキュー公開鍵証明書のように種々の環境で共通に使用できるような証明書を発行することが難しい場合もあるし、費用もかかる。
一方、プライベート認証局であれば、証明書の仕様を比較的自由に定められるので、暗号強度を低くしたり、最新であまり普及していない認証処理アルゴリズムを避けたりして、種々の環境で共通に使用できるような証明書を発行することも可能である。また、装置のメーカー自身がプライベート認証局を提供すれば、安価に証明書を発行することも可能である。
一方、プライベート認証局であれば、証明書の仕様を比較的自由に定められるので、暗号強度を低くしたり、最新であまり普及していない認証処理アルゴリズムを避けたりして、種々の環境で共通に使用できるような証明書を発行することも可能である。また、装置のメーカー自身がプライベート認証局を提供すれば、安価に証明書を発行することも可能である。
さらに、例えば下位装置２０と上位装置１０でメーカーが異なったり、通信システムの運用者が種々にカスタマイズを行ったりするような場合でも、レスキュー公開鍵証明書を無償で提供する等して、これらのメーカーや運用者に、レスキュー公開鍵証明書を用いた認証に対応できるようにするよう働きかけることも容易となる。そこで、レスキュー公開鍵証明書にはプライベート認証局が発行した証明書を採用している。
なお、プライベート認証局が発行するレスキュー公開鍵証明書は、パブリック認証局が発行する通常公開鍵証明書と比べた場合に、安全性や信頼性が劣ることも考えられるが、上述のように、レスキュー認証情報を用いて認証処理を行った場合に許可する機能を制限するようにすれば、この点は大きな問題にはならない。
なお、プライベート認証局が発行するレスキュー公開鍵証明書は、パブリック認証局が発行する通常公開鍵証明書と比べた場合に、安全性や信頼性が劣ることも考えられるが、上述のように、レスキュー認証情報を用いて認証処理を行った場合に許可する機能を制限するようにすれば、この点は大きな問題にはならない。
また、再度図７及び図８の説明に戻ると、これらの２つの公開鍵証明書において、通常公開鍵証明書では、符号Ｇで示すように有効期間を２００３年１月１日午前０時から２００４年１月１日午前０時までの１年間としている一方、レスキュー公開鍵証明書では、符号Ｌで示すように２０００年１月１日午前０時から２０５０年１月１日午前０時までの５０年間としている。
すなわち、通常公開鍵証明書はパブリック認証局が発行するものとしているので、装置の製造者や使用者が有効期間を自由に定めることができず、また安全性を考慮して有効期間が短く設定されているのが通常である。従って、有効期間内に証明書を更新する必要がある。そして、証明書の更新を自動で行う必要があるような装置においては、更新期限の徒過や更新時の異常による証明書の破損の危険がある。
すなわち、通常公開鍵証明書はパブリック認証局が発行するものとしているので、装置の製造者や使用者が有効期間を自由に定めることができず、また安全性を考慮して有効期間が短く設定されているのが通常である。従って、有効期間内に証明書を更新する必要がある。そして、証明書の更新を自動で行う必要があるような装置においては、更新期限の徒過や更新時の異常による証明書の破損の危険がある。
一方で、レスキュー認証情報を、通常公開鍵証明書による認証が行えなくなった場合に非常用の通信経路を確保するための認証情報であると位置付けるならば、レスキュー公開鍵証明書の有効期間経過後にはレスキュー公開鍵証明書を更新する必要が生じてしまうので、レスキュー公開鍵証明書の有効期間は長い方が好ましい。具体的には、例えば記憶させる装置の製品寿命よりも長い有効期間を設定するとよい。この製品寿命は、装置の想定運用期間あるいは想定動作期間であり、開発時に想定している使用期間や想定耐用年数、装置の品質保証期間等から定めることができる。
また、レスキュー公開鍵証明書の有効期間を、装置をメンテナンスしながら正常に動作させられると想定される期間よりも長く設定すれば、レスキュー公開鍵証明書は装置の動作中には有効期限が切れない証明書であるということができる。従って、装置の動作中は、常にレスキュー公開鍵証明書を用いた認証（レスキュー証明書セットを用いた認証）が可能な状態を保つことができる。また、レスキュー公開鍵証明書を更新する必要がないので、更新時の破損等を防止できる。
また、レスキュー公開鍵証明書の有効期間を、装置をメンテナンスしながら正常に動作させられると想定される期間よりも長く設定すれば、レスキュー公開鍵証明書は装置の動作中には有効期限が切れない証明書であるということができる。従って、装置の動作中は、常にレスキュー公開鍵証明書を用いた認証（レスキュー証明書セットを用いた認証）が可能な状態を保つことができる。また、レスキュー公開鍵証明書を更新する必要がないので、更新時の破損等を防止できる。
また、上記の製品寿命や装置の動作期間よりも極めて長い有効期間を定めるようにすれば、なおよい。図８示した例では、有効期間を５０年に設定しており、通常の装置であればこの程度で十分と考えられるが、これはＸ．５０９フォーマットに従って設定できる有効期間の最大が５０年であるためこのようにしただけで、さらに長い期間、例えば１００年や数百年を設定してもよいことはもちろんである。このように有効期間を定めた場合、有効期間の終期は、単に公開鍵証明書のフォーマット上の要求により記載したものであり、レスキュー公開鍵証明書の有効期限は事実上ないものと考えることができる。また、対象の装置によっては、２０年や３０年程度あるいはそれ以下の有効期間であっても、同様に考えることができる場合もある。
さらにまた、たとえレスキュー公開鍵証明書の有効期間が製品寿命より短かったとしても、通常公開鍵証明書の有効期間よりも長ければ、通常公開鍵証明書の有効期間経過後も一定の期間レスキュー公開鍵証明書を用いた認証が可能な状態を保つことができると共に、証明書の破損の危険性が低い安定した通信経路を用意できるという効果を得ることはできる。
なお、通常公開鍵証明書の有効期間については、安全性を考慮して適当な期間を定めればよいが、この期間は、製品寿命よりも短く、また装置の動作中に有効期限が切れるような期間となることが多い。
さらにまた、たとえレスキュー公開鍵証明書の有効期間が製品寿命より短かったとしても、通常公開鍵証明書の有効期間よりも長ければ、通常公開鍵証明書の有効期間経過後も一定の期間レスキュー公開鍵証明書を用いた認証が可能な状態を保つことができると共に、証明書の破損の危険性が低い安定した通信経路を用意できるという効果を得ることはできる。
なお、通常公開鍵証明書の有効期間については、安全性を考慮して適当な期間を定めればよいが、この期間は、製品寿命よりも短く、また装置の動作中に有効期限が切れるような期間となることが多い。
そして、レスキュー公開鍵証明書をプライベート認証局が発行するようにすれば、有効期間は発行者が適宜定めればよいので、これらの要求に応えるような有効期間を定めることも可能である。また、有効期間の長い公開鍵証明書は、有効期間の短い公開鍵証明書と比べた場合には安全性が若干劣るものの、上述のように、レスキュー公開鍵証明書を用いて認証を行った場合に実行を許可する動作を制限することにより、この点は大きな問題にはならないようにすることができる。
また、このようなレスキュー公開鍵証明書により非常用の通信経路を確保できるようにしておけば、暗号強度が高く有効期間の短い通常証明書を使用する場合であっても、認証方式の不対応及び期限切れや更新時の破損等による不都合を最小限に留めることができ、人手での証明書更新が困難であり自動更新に頼らざるを得ないような装置であっても、暗号強度が強く有効期間が短いような信頼性の高い証明書を有効に活用することができる。
また、このようなレスキュー公開鍵証明書により非常用の通信経路を確保できるようにしておけば、暗号強度が高く有効期間の短い通常証明書を使用する場合であっても、認証方式の不対応及び期限切れや更新時の破損等による不都合を最小限に留めることができ、人手での証明書更新が困難であり自動更新に頼らざるを得ないような装置であっても、暗号強度が強く有効期間が短いような信頼性の高い証明書を有効に活用することができる。
ところで、サーバとして機能する下位装置２０は、ＳＳＬハンドシェイクの際に、通信を要求してきた相手を識別できないため、基本的には全ての相手に同一の公開鍵証明書を送信することになる。しかし、この通信システムにおいては状況に応じて通常公開鍵証明書とレスキュー公開鍵証明書とを使い分ける必要がある。そこで、次にこの使い分けのための構成について図９を用いて説明する。図９は、クライアントがサーバに通信を要求する際に通信先アドレスの指定に用いるＵＲＬ（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）を用いるようにしてもよい。この情報は、上述のＨＴＴＰヘッダ情報に含まれるものである。
また要求の種類のデータとしては、例えば、ＤＯＭツリーのうち、ＳＯＡＰボディーを示す「Ｂｏｄｙ」ノードの子ノードの名称が考えられる。また、要求に係るＨＴＴＰリクエストのＳＯＡＰＡｃｔｉｏｎヘッダに含まれるＵＲＩ（Uniform Resource Identifiers）を用いるようにしてもよい。この情報は、上述のＨＴＴＰヘッダ情報に含まれるものである。
また、各種機能３８０は要求実行手段に該当し、ここに含まれる各機能は、各々が要求処理手段であり、受信した要求に応じた処理を行うためのソフトウェアによって提供される機能である。そして、通常処理ＵＲＬ用第２振り分け部４２１又はレスキューＵＲＬ用第２振り分け部４２２によって起動され、受け取ったデータに従ってロジックを実行し、その結果を処理の依頼元の第２振り分け部に返す処理を行う。
また、各第２振り分け部４２１，４２２から渡されたＤＯＭツリー形式のデータを解析し、これを、各種機能３８０に含まれる各機能のロジックを記述したプログラム言語で処理可能なデータ形式に変換する機能や、プログラムの実行結果である結果データを、ＤＯＭツリー形式のデータに変換する機能も有する。なお、ここでは各種機能３８０に含まれる各機能のロジックはＣ言語で記載されているものとし、このデータ形式はＣ言語の構造体データであるものとする。
このような各種機能３８０について、図では固有情報取得機能３８１と証明書設定機能３８７以外は具体的な内容を示していないが、各機能は要求の種類に対応して設けられる。
このような各種機能３８０について、図では固有情報取得機能３８１と証明書設定機能３８７以外は具体的な内容を示していないが、各機能は要求の種類に対応して設けられる。
例えば、固有情報取得機能３８１に分類される機能としては、ＩＤ（機番），モデル名，ファームウェアのバージョン，オプション構成，証明書のバージョン等の下位装置２０に固有な情報（識別情報を含む）の取得のようなものが挙げられるが、これらの機能の実行を指示するために別々の要求を用意するのであれば、これらの要求の実行に係るソフトウェアは、別々にコールされるプログラムとして設けるようにしている。
なお、証明書設定機能の提供する機能は、通常公開鍵証明書の設定である。ただし、この設定は、この下位装置２０では正規認証情報を構成する証明書セット全体を設定して行われる。
なお、証明書設定機能の提供する機能は、通常公開鍵証明書の設定である。ただし、この設定は、この下位装置２０では正規認証情報を構成する証明書セット全体を設定して行われる。
また、各種機能３８０に含まれる他の機能としては、例えば要求元に下位装置２０の状態の情報を取得させる状態取得機能、同じくログ情報を取得させるログ情報取得機能、同じく設定値の情報を取得させる設定値情報取得機能、下位装置２０の設定値を変更させる設定値変更機能、下位装置２０の調整動作を行わせる調整実行機能等が考えられるが、どのような機能を設けるかは、下位装置２０の構成や、上位装置１０との関係に応じて適宜に定めればよい。
また、図示はしていないが、下位装置２０が実行する複数のアプリが、それぞれアプリの機能に応じて各種機能３８０のような機能セットを提供するようにしてもよい。
また、図示はしていないが、下位装置２０が実行する複数のアプリが、それぞれアプリの機能に応じて各種機能３８０のような機能セットを提供するようにしてもよい。
ところで、この下位装置２０においては、通常処理ＵＲＬ用第２振り分け部４２１は、対応する機能がある全ての要求をその機能に振り分ける。しかし、レスキューＵＲＬ用第２振り分け部４２２は、図１１に太線で示したように、通常公開鍵証明書の設定に関する要求のみしか機能に振り分けない。そして、その他の要求を受け付けた場合には、対応する機能がないものとして応答を返す。
そしてここでは、通常公開鍵証明書の設定に関する要求は、通常公開鍵証明書の作成（情報の記載も含む）に必要な情報の取得要求と、通常公開鍵証明書の設定要求としており、これらに対応する機能は、固有情報取得機能３８１のうちＩＤ，モデル名及び証明書のバージョン情報の取得に係る機能と、証明書設定機能３８７としている。しかし、さらに他の要求も通常公開鍵証明書の設定に関する要求として取り扱ったり、逆にこれらの情報の取得要求を公開鍵証明書の設定に関する要求として取り扱わないようにすることも考えられる。具体的にどのような要求を通常公開鍵証明書の設定に関する要求として取り扱うかは、最終的にはシステムの設計者が適宜定めればよい。
そしてここでは、通常公開鍵証明書の設定に関する要求は、通常公開鍵証明書の作成（情報の記載も含む）に必要な情報の取得要求と、通常公開鍵証明書の設定要求としており、これらに対応する機能は、固有情報取得機能３８１のうちＩＤ，モデル名及び証明書のバージョン情報の取得に係る機能と、証明書設定機能３８７としている。しかし、さらに他の要求も通常公開鍵証明書の設定に関する要求として取り扱ったり、逆にこれらの情報の取得要求を公開鍵証明書の設定に関する要求として取り扱わないようにすることも考えられる。具体的にどのような要求を通常公開鍵証明書の設定に関する要求として取り扱うかは、最終的にはシステムの設計者が適宜定めればよい。
このような振り分けは、図１３に示したように、第２振り分け部毎に要求の種類と振り分け先とのテーブルを設け、各第２振り分け部が自己と対応するテーブルを参照して振り分けを行うようにすることにより、実現することができる。テーブルに記載されていない要求については、対応する機能がないものとして取り扱うようにすればよい。
このようにしたことにより、下位装置２０が通常処理ＵＲＬから要求を受信した場合には全ての要求に係る処理が許可される一方、レスキューＵＲＬから要求を受信した場合には、その要求は第１振り分け部４１０からレスキューＵＲＬ用第２振り分け部４２２に届くものの、通常公開鍵証明書の設定に関する要求以外の処理は機能に振り分けられず、結果的に処理が禁止されることになる。そして、第１振り分け部４１０とレスキューＵＲＬ用第２振り分け部４２２とで禁止手段の機能が実現される。
なお、他のアプリへの要求に係る処理も禁止するためには、レスキューＵＲＬで要求を受信した場合にＨＴＴＰデーモン３３１がその要求を通常公開鍵証明書の設定を行うアプリ以外には渡さないようにすればよい。また、アプリ毎に通常処理ＵＲＬ用第２振り分け部とレスキューＵＲＬ用第２振り分け部とを設け、後者が各機能への振り分けを全く行わないようにしてもよい。
このようにしたことにより、下位装置２０が通常処理ＵＲＬから要求を受信した場合には全ての要求に係る処理が許可される一方、レスキューＵＲＬから要求を受信した場合には、その要求は第１振り分け部４１０からレスキューＵＲＬ用第２振り分け部４２２に届くものの、通常公開鍵証明書の設定に関する要求以外の処理は機能に振り分けられず、結果的に処理が禁止されることになる。そして、第１振り分け部４１０とレスキューＵＲＬ用第２振り分け部４２２とで禁止手段の機能が実現される。
なお、他のアプリへの要求に係る処理も禁止するためには、レスキューＵＲＬで要求を受信した場合にＨＴＴＰデーモン３３１がその要求を通常公開鍵証明書の設定を行うアプリ以外には渡さないようにすればよい。また、アプリ毎に通常処理ＵＲＬ用第２振り分け部とレスキューＵＲＬ用第２振り分け部とを設け、後者が各機能への振り分けを全く行わないようにしてもよい。
以上のような禁止手段により、レスキュー公開鍵証明書を用いてＳＳＬハンドシェイクを行うレスキューＵＲＬで通信を行った場合に、通常公開鍵証明書の設定に関する処理以外の処理を禁止するようにすることができる。そして、このことにより、レスキュー公開鍵証明書を使用することによる効果を十分維持しながら、レスキュー公開鍵証明書や対応する私有鍵等が万一漏洩した場合の影響を最低限に抑え、高いセキュリティを実現することができる。
次に、図１１に示した構成を有する下位装置２０において実行される処理について、図１４及び図１５を用いて説明する。図１４は、下位装置２０が通信要求を受け付けた場合に行う処理を示すフローチャート、図１５はその続きの処理を示すフローチャートである。これらの処理は、この発明の通信装置の制御方法に係る処理である。そしてここでは、説明を簡単にするため、通信相手が下位装置２０を認証するのみの、図２６に示したような片方向認証を行う場合の処理を示している。しかし、図２４に示したような双方向認証を行うようにしてもよいことはもちろんである。
下位装置２０のＣＰＵは、ＨＴＴＰデーモン３３１を常に実行しており、これが他の装置からの通信要求を受け付けると、図１４のフローチャートに示す処理を開始する。
この処理においては、まずステップＳ１０１で、通信要求を受け付けたＵＲＬが通常処理ＵＲＬであるか否か判断する。そして通常処理ＵＲＬであれば、ステップＳ１０２に進んで、下位装置用通常公開鍵証明書を下位装置用通常私有鍵で暗号化した第１の乱数と共に通信相手（通信要求の要求元）に送信して認証を要求する。すなわち、この場合には通信相手に対して通常公開鍵証明書を提供する。この処理は、図２６のステップＳ２１及びＳ２２の処理に相当する。
この処理においては、まずステップＳ１０１で、通信要求を受け付けたＵＲＬが通常処理ＵＲＬであるか否か判断する。そして通常処理ＵＲＬであれば、ステップＳ１０２に進んで、下位装置用通常公開鍵証明書を下位装置用通常私有鍵で暗号化した第１の乱数と共に通信相手（通信要求の要求元）に送信して認証を要求する。すなわち、この場合には通信相手に対して通常公開鍵証明書を提供する。この処理は、図２６のステップＳ２１及びＳ２２の処理に相当する。
その後、ステップＳ１０６に進んで通信相手からの応答を待ち、認証されなかった場合には以後の通信を許可せずにそのまま終了するが、通信相手に認証された場合には、ステップＳ１０７に進み、認証処理において受信した共通鍵の種から共通鍵を作成する。これらの処理は、図２６のステップＳ２５及びＳ２６の処理に相当する。
そして、ステップＳ１０８で通信相手からのＨＴＴＰリクエストによる要求の受信を待ち、受信するとステップＳ１０９に進んで、その要求を、受信したＵＲＬの情報と共に第１振り分け部４１０に渡す。ここまでの処理が、ＨＴＴＰデーモン３３１による処理である。
そして、ステップＳ１０８で通信相手からのＨＴＴＰリクエストによる要求の受信を待ち、受信するとステップＳ１０９に進んで、その要求を、受信したＵＲＬの情報と共に第１振り分け部４１０に渡す。ここまでの処理が、ＨＴＴＰデーモン３３１による処理である。
また、ステップＳ１０１で通常処理ＵＲＬでなかった場合には、ステップＳ１０３に進んで通信要求を受け付けたＵＲＬがレスキューＵＲＬであるか否か判断する。そしてレスキューＵＲＬであれば、ステップＳ１０４に進んで、下位装置用レスキュー公開鍵証明書を下位装置用レスキュー私有鍵で暗号化した第１の乱数と共に通信相手に送信して認証を要求する。すなわち、この場合には通信相手に対してレスキュー公開鍵証明書を提供する。この処理も、図２６のステップＳ２１及びＳ２２の処理に相当する。
そして、ステップＳ１０６以下に進み、ステップＳ１０９までは通常公開鍵証明書を提供した場合と同様な処理を行う。また、ステップＳ１０３でレスキューＵＲＬでない場合には、通信を受け付けていないＵＲＬへの通信要求であるので、ステップＳ１０５でエラー処理を行って処理を終了する。
そして、ステップＳ１０６以下に進み、ステップＳ１０９までは通常公開鍵証明書を提供した場合と同様な処理を行う。また、ステップＳ１０３でレスキューＵＲＬでない場合には、通信を受け付けていないＵＲＬへの通信要求であるので、ステップＳ１０５でエラー処理を行って処理を終了する。
次にステップＳ１１０以降の処理について説明する。
ステップＳ１０９で要求を渡された第１振り分け部４１０は、図１２に示したようなテーブルを参照し、受信したＵＲＬに応じて振り分け先を決定する。そしてここでは、通常処理ＵＲＬで受信した要求はステップＳ１１１で通常処理ＵＲＬ用第２振り分け部４２１に渡し、レスキューＵＲＬで受信した要求はステップＳ１１２でレスキューＵＲＬ用第２振り分け部４２２に渡す。
ステップＳ１１１及びＳ１１２の後は、それぞれ図１５のステップＳ１１３及びＳ１１６に進み、第２振り分け部が、ＨＴＴＰリクエストとして受信した要求のＨＴＭＬボディーに当たるＳＯＡＰエンベロープを解析し、その構成を示すＤＯＭツリー形式のデータを作成する。この処理は、どちらの第２振り分け部でも同様に行う。
ステップＳ１０９で要求を渡された第１振り分け部４１０は、図１２に示したようなテーブルを参照し、受信したＵＲＬに応じて振り分け先を決定する。そしてここでは、通常処理ＵＲＬで受信した要求はステップＳ１１１で通常処理ＵＲＬ用第２振り分け部４２１に渡し、レスキューＵＲＬで受信した要求はステップＳ１１２でレスキューＵＲＬ用第２振り分け部４２２に渡す。
ステップＳ１１１及びＳ１１２の後は、それぞれ図１５のステップＳ１１３及びＳ１１６に進み、第２振り分け部が、ＨＴＴＰリクエストとして受信した要求のＨＴＭＬボディーに当たるＳＯＡＰエンベロープを解析し、その構成を示すＤＯＭツリー形式のデータを作成する。この処理は、どちらの第２振り分け部でも同様に行う。
そしてその後、それぞれステップＳ１１４及びＳ１１７に進み、第２振り分け部が各種機能３８０中の要求の種類に応じた機能に要求を振り分けてその要求に係る処理を依頼する。このとき、要求はＨＴＴＰヘッダ情報及びＤＯＭツリー形式のデータとして機能に渡す。また、通常処理ＵＲＬ用第２振り分け部４２１は、各種機能３８０のどの機能に対しても振り分けを行うが、レスキューＵＲＬ用第２振り分け部４２２は、通常公開鍵証明書の設定に関する要求のみを振り分ける。この振り分けは、図１３に示したように、２つの第２振り分け部で、要求の種類と振り分け先の機能との対応関係を示したテーブルについて異なるものを使用すれば、処理の手順自体は同じものにすることができる。
この振り分けの後、それぞれステップＳ１１５及びＳ１１８に進み、振り分けが成功したか否か、すなわちテーブルに要求の種類と対応する振り分け先が存在したか否か判断する。そして、成功していれば、どちらのステップの場合もステップＳ１１９に進む。
この振り分けの後、それぞれステップＳ１１５及びＳ１１８に進み、振り分けが成功したか否か、すなわちテーブルに要求の種類と対応する振り分け先が存在したか否か判断する。そして、成功していれば、どちらのステップの場合もステップＳ１１９に進む。
次のステップＳ１１９では、要求を振り分けられた機能が、要求のＤＯＭツリーを解析して、そこに含まれるパラメータをＣ言語の構造体データに変換する。そして、ステップＳ１２０で機能のロジックを実行し、結果を構造体データとして生成する。その後、ステップＳ１２１でその構造体データをＤＯＭツリーに変換して、レスポンスとして第２振り分け部に返す。このとき、結果は機能に対して要求を振り分けた第２振り分け部に返す。
そして、これを受け取った第２振り分け部は、ステップＳ１２２でそのＤＯＭツリーを図示しないＸＭＬシリアライザによってＸＭＬ形式のＳＯＡＰメッセージによるレスポンスデータに変換し、ＨＴＴＰデーモン３３１によってＨＴＴＰレスポンスとして要求の送信元に返して処理を終了する。
そして、これを受け取った第２振り分け部は、ステップＳ１２２でそのＤＯＭツリーを図示しないＸＭＬシリアライザによってＸＭＬ形式のＳＯＡＰメッセージによるレスポンスデータに変換し、ＨＴＴＰデーモン３３１によってＨＴＴＰレスポンスとして要求の送信元に返して処理を終了する。
一方、ステップＳ１１５又はＳ１１８で振り分けが失敗していた場合には、振り分けを試みた第２振り分け部は、ステップＳ１２３でその種類の要求をサポートしていない旨のエラー情報（ＳＯＡＰ Ｆａｕｌｔ）のＤＯＭツリーを生成し、ステップＳ１２４でＸＭＬ形式のレスポンスデータに変換して、これをＨＴＴＰデーモン３３１によってＨＴＴＰレスポンスとして要求の送信元に返して処理を終了する。
なお、第２振り分け部を通常処理ＵＲＬ用とレスキューＵＲＬ用で区別する必要があるのは、要求を機能に振り分ける手順までであり、応答を返す処理においては通常処理ＵＲＬ用とレスキューＵＲＬ用の機能は全く同じである。従って、ステップＳ１１９以降ではこれらを区別せずに示している。
なお、第２振り分け部を通常処理ＵＲＬ用とレスキューＵＲＬ用で区別する必要があるのは、要求を機能に振り分ける手順までであり、応答を返す処理においては通常処理ＵＲＬ用とレスキューＵＲＬ用の機能は全く同じである。従って、ステップＳ１１９以降ではこれらを区別せずに示している。
次に、図１４及び図１５のフローチャートに示した処理による処理シーケンスの例について、図１６を用いて説明する。図１６は、この処理シーケンスを示すシーケンス図であり、下位装置２０が通常処理ＵＲＬで要求を受け付けた場合の処理を示している。
この例においては、ＳＳＬハンドシェイクの処理は図示を省略しているが、その後上位装置１０が下位装置２０の通常処理ＵＲＬに要求をＨＴＴＰリクエストとして送信すると、ＨＴＴＰデーモン３３１がこれを受け付ける（Ｓ２０１）。この要求はＳＯＡＰメッセージとして記載されており、ＨＴＴＰデーモン３３１は受信した要求を受信したＵＲＬを示す情報（例えばＩＰアドレスとポート番号）と共に第１振り分け部４１０に渡して振り分け処理を依頼する（Ｓ２０２）。
この例においては、ＳＳＬハンドシェイクの処理は図示を省略しているが、その後上位装置１０が下位装置２０の通常処理ＵＲＬに要求をＨＴＴＰリクエストとして送信すると、ＨＴＴＰデーモン３３１がこれを受け付ける（Ｓ２０１）。この要求はＳＯＡＰメッセージとして記載されており、ＨＴＴＰデーモン３３１は受信した要求を受信したＵＲＬを示す情報（例えばＩＰアドレスとポート番号）と共に第１振り分け部４１０に渡して振り分け処理を依頼する（Ｓ２０２）。
そして第１振り分け部４１０は、その情報を基に図１２に示したようなテーブルを参照し、要求を受信したＵＲＬに応じて要求の振り分け先を決定する（Ｓ２０３）。そして、ここではＵＲＬは通常処理ＵＲＬであり、振り分け先は通常処理ＵＲＬ用第２振り分け部４２１であるので、ここに要求を振り分けてその後の処理を依頼する（Ｓ２０４）。これを受けた通常処理ＵＲＬ用第２振り分け部４２１は、要求のＳＯＡＰメッセージをＤＯＭツリー形式のデータに変換し（Ｓ２０５）、要求の種類に応じて振り分け先を決定し（Ｓ２０６）、振り分け先となる機能３８ｘにＤＯＭツリー形式のデータを渡して処理を依頼する（Ｓ２０７）。
そして、その機能３８ｘがＤＯＭツリー形式のデータをロジックにより処理できる構造体データに変換し（Ｓ２０８）、これを引数としてロジックを実行して要求に係る処理を行い（Ｓ２０９）、処理結果の構造体データをＤＯＭツリー形式のデータに変換し（Ｓ２１０）、処理を依頼してきた通常処理ＵＲＬ用第２振り分け部４２１にそのデータを渡す（Ｓ２１１）。
そして、このデータを受け取った通常処理ＵＲＬ用第２振り分け部４２１は、これを応答のＳＯＡＰメッセージに変換し（Ｓ２１２）、ＨＴＴＰデーモン３３１を介して上位装置１０にＨＴＴＰレスポンスとして送信する（Ｓ２１３，Ｓ２１４）。
以上が通常処理ＵＲＬで要求を受け付けた場合の処理である。
そして、このデータを受け取った通常処理ＵＲＬ用第２振り分け部４２１は、これを応答のＳＯＡＰメッセージに変換し（Ｓ２１２）、ＨＴＴＰデーモン３３１を介して上位装置１０にＨＴＴＰレスポンスとして送信する（Ｓ２１３，Ｓ２１４）。
以上が通常処理ＵＲＬで要求を受け付けた場合の処理である。
そして、レスキューＵＲＬで要求を受け付けた場合にも、ほぼ同様な処理が行われるが、第１振り分け部４１０による振り分け先がレスキューＵＲＬ用第２振り分け部４２２となる。そして、レスキューＵＲＬ用第２振り分け部４２２は通常公開鍵証明書の設定に関する要求のみを機能３８ｘに振り分け、それ以外の要求は振り分け先がないものとして処理する。従って、通常処理ＵＲＬで要求を受け付けた場合とレスキューＵＲＬで要求を受け付けた場合とでほぼ同様な手順の処理を行いながら、結果的に、レスキューＵＲＬで要求を受け付けた場合には通常公開鍵証明書の設定に関する要求以外の要求に係る処理を禁止することができる。
次に、上位装置１０から下位装置２０へ送信する要求のＨＴＴＰリクエスト及び下位装置２０から上位装置１０へ返す応答のＨＴＴＰレスポンスの例について図１７乃至図２０を用いて説明する。
まず、図１７に上位装置１０から下位装置２０のレスキューＵＲＬに送信する証明書設定要求のＨＴＴＰリクエストの例を示す。
このＨＴＴＰリクエストは、上述したように、ＳＯＡＰに従ったＳＯＡＰメッセージであり、ＨＴＴＰヘッダの最後にＳＯＡＰＡｃｔｉｏｎヘッダ６１を付してある。そして、それ以後の内容がＳＯＡＰエンベロープであり、ここに含まれるＳＯＡＰボディ中に要求の内容を記載している。ここでは、Ｂｏｄｙのすぐ下位の符号６２で示す要素に、要求が証明書設定要求であることを示す情報を記載している。そして、その下位に、証明書のバージョンを示すパラメータ６３、証明書の暗号化パスワードを示すパラメータ６４、設定すべき証明書を暗号化してＢａｓｅ６４エンコードしたデータを示すパラメータ６５を記載している。そして、要求の種類は、要素６２あるいはＳＯＡＰＡｃｔｉｏｎヘッダ６１の末尾を参照すればわかり、第２振り分け部は、この情報に従って機能への振り分け処理を行う。
まず、図１７に上位装置１０から下位装置２０のレスキューＵＲＬに送信する証明書設定要求のＨＴＴＰリクエストの例を示す。
このＨＴＴＰリクエストは、上述したように、ＳＯＡＰに従ったＳＯＡＰメッセージであり、ＨＴＴＰヘッダの最後にＳＯＡＰＡｃｔｉｏｎヘッダ６１を付してある。そして、それ以後の内容がＳＯＡＰエンベロープであり、ここに含まれるＳＯＡＰボディ中に要求の内容を記載している。ここでは、Ｂｏｄｙのすぐ下位の符号６２で示す要素に、要求が証明書設定要求であることを示す情報を記載している。そして、その下位に、証明書のバージョンを示すパラメータ６３、証明書の暗号化パスワードを示すパラメータ６４、設定すべき証明書を暗号化してＢａｓｅ６４エンコードしたデータを示すパラメータ６５を記載している。そして、要求の種類は、要素６２あるいはＳＯＡＰＡｃｔｉｏｎヘッダ６１の末尾を参照すればわかり、第２振り分け部は、この情報に従って機能への振り分け処理を行う。
図１８にこのようなＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示す。
このＨＴＴＰレスポンスも、ＳＯＡＰメッセージであり、ＨＴＴＰヘッダとＳＯＡＰエンベロープとからなる。そして、ＳＯＡＰボディー中に、実行した要求の種類を要素７１として、その実行結果が「成功」である旨を要素７２として示している。更新を試みることはできたものの失敗した場合には、要素７２の内容が「ＮＧ」になる。
このＨＴＴＰレスポンスも、ＳＯＡＰメッセージであり、ＨＴＴＰヘッダとＳＯＡＰエンベロープとからなる。そして、ＳＯＡＰボディー中に、実行した要求の種類を要素７１として、その実行結果が「成功」である旨を要素７２として示している。更新を試みることはできたものの失敗した場合には、要素７２の内容が「ＮＧ」になる。
また、図１９に、上位装置１０から下位装置２０のレスキューＵＲＬに送信する別のＨＴＴＰリクエストの例を示す。
このＨＴＴＰリクエストも、ＳＯＡＰメッセージであり、状態取得要求を行うものである。そして、図１７の場合とは要求の種類が異なることに伴い、ＳＯＡＰＡｃｔｉｏｎヘッダ８１の末尾と、ＳＯＡＰボディーの内容が図１７に示した例と異なる。ここでは、ＳＯＡＰボディーの下位には要求が状態取得要求であることを示す要素８２のみを記載し、その他のパラメータは記載していない。
このＨＴＴＰリクエストも、ＳＯＡＰメッセージであり、状態取得要求を行うものである。そして、図１７の場合とは要求の種類が異なることに伴い、ＳＯＡＰＡｃｔｉｏｎヘッダ８１の末尾と、ＳＯＡＰボディーの内容が図１７に示した例と異なる。ここでは、ＳＯＡＰボディーの下位には要求が状態取得要求であることを示す要素８２のみを記載し、その他のパラメータは記載していない。
図２０にこのようなＨＴＴＰリクエストに対する応答のＨＴＴＰレスポンスの例を示すが、状態取得要求は、レスキューＵＲＬで受信した場合には機能に振り分けない要求であるので、このようなコマンドは存在しない旨の応答が、ＳＯＡＰ Ｆａｕｌｔとして返されることになる。そして、ＳＯＡＰボディー中に要素９１としてその旨を示す情報を記載している。
以上説明してきたような通信システムによれば、通常公開鍵証明書が破損や有効期限切れ等により使用できなくなった場合でも、レスキュー公開鍵証明書を用いた認証が成功した場合にネットワークを介してこれを設定できるようにしているので、下位装置２０が常に正常な認証を受けられる状態を維持できる。そして、この処理に人手を介す必要はなく、容易にこのような効果を得ることができる。また、レスキュー公開鍵証明書を用いてＳＳＬハンドシェイクを行うレスキューＵＲＬで通信を行った場合に、通常公開鍵証明書の設定に関する処理以外の処理を禁止するようにしているので、レスキュー公開鍵証明書を使用することによる効果を十分維持しながら、レスキュー公開鍵証明書や対応する私有鍵等が万一漏洩した場合の影響を最低限に抑え、高いセキュリティを実現することができる。
また、暗号強度が比較的低い認証処理に対応したレスキュー公開鍵証明書は、暗号強度が高い認証処理に対応した通常公開鍵証明書と比べた場合には安全性が若干劣るが、相当程度の安全性は確保できる。そして、このような証明書を用意しておくことにより、設定されている通常公開鍵証明書による認証で対応できない環境下に置かれたり、通常公開鍵証明書が破損や有効期限切れ等により使用できなくなってしまった場合でも、レスキュー公開鍵証明書が利用可能な環境下であれば、共通鍵暗号を用いた安全な通信経路を確保できるという効果がある。そして、プライベート認証局であれば、広汎な環境下で利用可能であり、かつ有効期限が長く期限切れが起こらず、更新を不要として更新時の破損を防止できるようなレスキュー公開鍵証明書を発行することができる。
なお、通常公開鍵証明書の設定の際には下位装置２０と上位装置１０との間で相互認証を行うようにすれば、下位装置２０が不適当な装置から通常公開鍵証明書を受信して記憶してしまうことを防止でき、さらに通信の安全性を向上させることができる。
なお、通常公開鍵証明書の設定の際には下位装置２０と上位装置１０との間で相互認証を行うようにすれば、下位装置２０が不適当な装置から通常公開鍵証明書を受信して記憶してしまうことを防止でき、さらに通信の安全性を向上させることができる。
〔変形例：図２１，図２２〕
次に、上述した実施形態の変形例について説明する。
まず、図２１に下位装置２０の機能構成の変形例を示す。
上述した実施形態においては、上位装置１０から受信した要求の内容に応じた動作を実行して応答を返すための下位装置２０の機能構成が図１１に示すものである例について説明したが、これを図２１に示すものにしてもよい。すなわち、仲介デーモン３３２とＨＴＴＰ接続管理部３４２とＨＴＴＰサービス実行部３４３とを設けるようにしてもよい。
次に、上述した実施形態の変形例について説明する。
まず、図２１に下位装置２０の機能構成の変形例を示す。
上述した実施形態においては、上位装置１０から受信した要求の内容に応じた動作を実行して応答を返すための下位装置２０の機能構成が図１１に示すものである例について説明したが、これを図２１に示すものにしてもよい。すなわち、仲介デーモン３３２とＨＴＴＰ接続管理部３４２とＨＴＴＰサービス実行部３４３とを設けるようにしてもよい。
この場合、第１振り分け部４１０とＨＴＴＰデーモン３３１との間のデータの受け渡しをＨＴＴＰサービス実行部３４３を介して行い、さらにＨＴＴＰサービス実行部３４３は、各種機能３８０が提供する機能に関する動作要求を含むと考えられるＰＯＳＴメソッドのみを第１振り分け部４１０に渡すようにする。また、仲介デーモン３３２はＨＴＴＰデーモン３３１から通信の接続、切断に関する通知を受けてＨＴＴＰ接続管理部３４２にこれを伝え、ＨＴＴＰ接続管理部３４２はこの通知に応じてＨＴＴＰサービス実行部３４３にＨＴＴＰデーモン３３１からＨＴＴＰリクエストを取得させる。
このような構成とし、ＨＴＴＰサービス実行部３４３に対応するスレッドを複数備えることによって、上位装置１０からの複数の要求を単一のアプリ（プロセス）で平行処理することが可能になり、上位装置１０に対する応答性能を向上させることができる。本件の出願人は、このような技術に関し、過去に特許出願を行っている（特願２００３−８１２４６）。
このような構成とし、ＨＴＴＰサービス実行部３４３に対応するスレッドを複数備えることによって、上位装置１０からの複数の要求を単一のアプリ（プロセス）で平行処理することが可能になり、上位装置１０に対する応答性能を向上させることができる。本件の出願人は、このような技術に関し、過去に特許出願を行っている（特願２００３−８１２４６）。
またここでは、第２振り分け部を複数設け、第１振り分け部４１０が受信したＵＲＬに従って要求を適当な第２振り分け部に振り分ける例について説明した。
しかしながら、例えば第２振り分け部を１つだけ設け、第２振り分け部に第１振り分け部４１０の機能を併せ持たせ、１つの第２振り分け部が、受信したＵＲＬと要求の種類との両方に従って各機能に要求を振り分けるようにすることも可能である。この場合には、例えば図２２に示すような、受信したＵＲＬと要求の種類の組み合わせ毎に要求の振り分け先を定めたテーブルを記憶しておき、これを参照して振り分け先の機能にＨＴＴＰヘッダ情報及びＤＯＭツリー形式のデータを振り分けるようにすればよい。
このようにすれば、プログラムモジュールの点数を削減することができる。ただし、図１１に示した実施形態の構成であれば、ＵＲＬの情報を第２振り分け部から先に渡す必要がないため、モジュール間インタフェースの簡略化という点では図１１に示した構成の方が優れていると言える。
しかしながら、例えば第２振り分け部を１つだけ設け、第２振り分け部に第１振り分け部４１０の機能を併せ持たせ、１つの第２振り分け部が、受信したＵＲＬと要求の種類との両方に従って各機能に要求を振り分けるようにすることも可能である。この場合には、例えば図２２に示すような、受信したＵＲＬと要求の種類の組み合わせ毎に要求の振り分け先を定めたテーブルを記憶しておき、これを参照して振り分け先の機能にＨＴＴＰヘッダ情報及びＤＯＭツリー形式のデータを振り分けるようにすればよい。
このようにすれば、プログラムモジュールの点数を削減することができる。ただし、図１１に示した実施形態の構成であれば、ＵＲＬの情報を第２振り分け部から先に渡す必要がないため、モジュール間インタフェースの簡略化という点では図１１に示した構成の方が優れていると言える。
また、ここでは各機能にＤＯＭツリーを構造体データに変換したり構造体データをＤＯＭツリーに変換したりする機能を設ける例について説明したが、各機能とは別に、このような変換を行うハンドラを設けるようにしてもよい。このようなすれば、各機能には、その機能のプログラムが直接処理できる形式でデータを渡すことができるので、各機能のプログラムを、ＳＯＡＰやＸＭＬの知識がなくても開発できるようにすることができる。
また、ここでは第２振り分け部にＸＭＬで記載されたＳＯＡＰメッセージをＤＯＭツリーに変換したりＤＯＭツリーをＳＯＡＰメッセージに変換したりする機能を設ける例について説明したが、このようにすることも必須ではない。ＳＯＡＰメッセージを直接取り扱うことができるように各機能のプログラムを作成すれば、第１振り分け部４１０が図２２に示したようなテーブルを参照して要求に係るＳＯＡＰリクエストを直接各機能に振り分けるようにすることも可能である。
また、ここでは第２振り分け部にＸＭＬで記載されたＳＯＡＰメッセージをＤＯＭツリーに変換したりＤＯＭツリーをＳＯＡＰメッセージに変換したりする機能を設ける例について説明したが、このようにすることも必須ではない。ＳＯＡＰメッセージを直接取り扱うことができるように各機能のプログラムを作成すれば、第１振り分け部４１０が図２２に示したようなテーブルを参照して要求に係るＳＯＡＰリクエストを直接各機能に振り分けるようにすることも可能である。
また、上述した実施形態では、より暗号強度が高い認証処理に対応した通常公開鍵証明書と、より暗号強度が低い認証処理に対応したレスキュー公開鍵証明書とを用いる例について説明したが、前者はセキュリティ強度が高い証明書、後者はセキュリティ強度が比較的低い証明書と捉えることもできる。
一般に、セキュリティ強度が高い証明書には、多くの情報を記載する必要があったり、輸出制限があったり特殊な認証処理プログラムが必要であったりして利用可能な環境が限られていたりするため、全ての装置に同じように記憶させて認証処理に用いることが難しい場合がある。一方で、セキュリティ強度が低い証明書であれば、このような制限が少なく、全ての装置に同じように記憶させて認証処理に用いることが比較的容易であると考えられる。
一般に、セキュリティ強度が高い証明書には、多くの情報を記載する必要があったり、輸出制限があったり特殊な認証処理プログラムが必要であったりして利用可能な環境が限られていたりするため、全ての装置に同じように記憶させて認証処理に用いることが難しい場合がある。一方で、セキュリティ強度が低い証明書であれば、このような制限が少なく、全ての装置に同じように記憶させて認証処理に用いることが比較的容易であると考えられる。
そこで、セキュリティ強度が低い証明書を記憶させた装置を製造・販売した上で、利用環境に合わせてセキュリティ強度が高い証明書を事後的に記憶させることができるようにしたいという要求がある。例えば、システムの運用者によって種々に認証処理の内容を工夫したり信頼性の高いＣＡを選択したりしてセキュリティの向上を図る場合も考えられるが、このような場合、ある装置を１つのシステムから他のシステムに移動（単に設定を変更するのみの場合も含む）させる場合、通常の認証処理に使用する証明書を入れ換える必要があることが考えられる。また、セキュリティの高い証明書に後で欠陥が発見され、認証処理の方式を変更する必要が生じることも考えられる。
このような場合に、上述した実施形態の処理を利用し、種々の環境で共通に利用できるようなセキュリティの比較的低い証明書による通信経路を確保できるようにしておき、セキュリティの低い証明書を用いる認証を行うアドレスで通信を行った場合に、セキュリティの高い証明書の設定に関する処理以外の処理を禁止するようにすれば、セキュリティの低い証明書を使用することによる効果を十分維持しながら、セキュリティの低い証明書や対応する私有鍵等が万一漏洩した場合の影響を最低限に抑え、全体として高いセキュリティを実現することができる。
また、上述した実施形態では、レスキュー公開鍵証明書にも装置の識別情報を記載する例について説明したが、レスキュー公開鍵証明書には装置の識別情報を含めず、同じ階位の装置（図１及び図２に示した例では、上位装置と下位装置の階位が存在するものとする）には、全て同じレスキュー公開鍵証明書を記憶させるようにしてもよい。この場合、同じ階位の各装置を個別に区別する必要がないので、証明書に含まれるレスキュー公開鍵及びこれと対応するレスキュー私有鍵も含めて、全く共通のものでよい。そして、通信相手のレスキュー公開鍵証明書が全て同じであることから、ルート鍵証明書については、ある階位の装置の通信相手となる全ての装置について共通となる。すなわち、図２３に示したように下位装置を複数設けた場合でも、全ての下位装置に同じレスキュー認証情報を記憶させることになる。
これは、上位装置１０のレスキュー認証情報のレスキュー認証情報についても同様である。
なお、通常公開鍵証明書とデータ形式を統一化する場合には、例えば図６に示した形式において「Subject」の項目を空白としたり、ベンダー名のみ記載して機番として０を記載してレスキュー公開鍵証明書であることを示すこと等も考えられる。
なお、通常公開鍵証明書とデータ形式を統一化する場合には、例えば図６に示した形式において「Subject」の項目を空白としたり、ベンダー名のみ記載して機番として０を記載してレスキュー公開鍵証明書であることを示すこと等も考えられる。
このようにすれは、レスキュー認証情報は同じ階位の装置について全て共通となるので、装置の製造時にその機種に応じて定まる階位に応じたものを記憶させてしまうことができる。すなわち、装置の識別情報を付した情報ではないため、検査工程を終了して識別番号を付した各装置に対してそれぞれ個別の証明書を用意して記憶させる必要はなく、多数の装置に対して単純作業によって記憶させることができる。例えば、制御プログラムのマスタにレスキュー認証情報を含めておき、制御プログラムを装置にコピーする際にレスキュー認証情報も共に記憶させる等である。
そして、レスキュー公開鍵証明書に十分長期の有効期間を設定しておけば、その後レスキュー認証情報を更新する必要はないため破損しづらく、また上記のように通常公開鍵証明書の有効期間が過ぎて通常公開鍵証明書による認証が行えなくなった場合でも、レスキュー認証情報に含まれるレスキュー公開鍵証明書を用いた認証は可能な状態を保つことができる。
そして、レスキュー公開鍵証明書に十分長期の有効期間を設定しておけば、その後レスキュー認証情報を更新する必要はないため破損しづらく、また上記のように通常公開鍵証明書の有効期間が過ぎて通常公開鍵証明書による認証が行えなくなった場合でも、レスキュー認証情報に含まれるレスキュー公開鍵証明書を用いた認証は可能な状態を保つことができる。
なおこの場合、レスキュー公開鍵証明書には装置の識別情報を付していないため、レスキュー公開鍵証明書を用いた認証を行った場合でも、通信相手の装置を具体的に特定することはできない。しかし、通信相手についてある程度の情報は得ることができる。
すなわち、例えばあるベンダーが自社製品のうち下位装置２０に該当する装置全てに下位装置用のレスキュー認証情報（下位装置用レスキュー公開鍵証明書，下位装置用レスキュー私有鍵及び上位装置認証用レスキュールート鍵証明書）を記憶させ、その通信相手となる上位装置１０に該当する装置全てに上位装置用のレスキュー認証情報（上位装置用レスキュー公開鍵証明書，上位装置用レスキュー私有鍵及び下位装置認証用レスキュールート鍵証明書）を記憶させておけば、下位装置２０は、認証処理が成功した場合、自己の記憶している上位装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手が同じベンダーの上位装置１０であることを認識できるし、逆に上位装置１０も自己の記憶しているレスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手は同じベンダーの下位装置２０であることを認識できる。
すなわち、例えばあるベンダーが自社製品のうち下位装置２０に該当する装置全てに下位装置用のレスキュー認証情報（下位装置用レスキュー公開鍵証明書，下位装置用レスキュー私有鍵及び上位装置認証用レスキュールート鍵証明書）を記憶させ、その通信相手となる上位装置１０に該当する装置全てに上位装置用のレスキュー認証情報（上位装置用レスキュー公開鍵証明書，上位装置用レスキュー私有鍵及び下位装置認証用レスキュールート鍵証明書）を記憶させておけば、下位装置２０は、認証処理が成功した場合、自己の記憶している上位装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手が同じベンダーの上位装置１０であることを認識できるし、逆に上位装置１０も自己の記憶しているレスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手は同じベンダーの下位装置２０であることを認識できる。
そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができるので、その後機種機番情報等を交換して通信相手を特定することも可能である。
なお、通常公開鍵証明書についても、同様に装置の識別情報を含めないものとすることも考えられる。このようにしたとしても、対応している認証処理の暗号強度が高い分だけ安全性が高いと考えられる。また、レスキュー公開鍵証明書よりも有効期間が短ければ、その分だけレスキュー公開鍵証明書よりも安全性を高めることができる。
また、通常公開鍵証明書とレスキュー公開鍵証明書の有効期間や、これらを発行する認証局についても、特に上述した関係に限定されることはない。逆に、暗号強度についても、セキュリティ高低の１つの要素と捉え、認証局や有効期間、装置の識別情報の有無等により、通常公開鍵証明書とレスキュー公開鍵証明書の差を出すようにすることも考えられる。
なお、通常公開鍵証明書についても、同様に装置の識別情報を含めないものとすることも考えられる。このようにしたとしても、対応している認証処理の暗号強度が高い分だけ安全性が高いと考えられる。また、レスキュー公開鍵証明書よりも有効期間が短ければ、その分だけレスキュー公開鍵証明書よりも安全性を高めることができる。
また、通常公開鍵証明書とレスキュー公開鍵証明書の有効期間や、これらを発行する認証局についても、特に上述した関係に限定されることはない。逆に、暗号強度についても、セキュリティ高低の１つの要素と捉え、認証局や有効期間、装置の識別情報の有無等により、通常公開鍵証明書とレスキュー公開鍵証明書の差を出すようにすることも考えられる。
また、上述した実施形態では、上位装置１０と下位装置２０が、図２４あるいは図２６を用いて説明したようなＳＳＬに従った認証を行う場合の例について説明した。しかし、この認証が必ずしもこのようなものでなくてもこの実施形態は効果を発揮する。
ＳＳＬを改良したＴＬＳ（Transport Layer Security）も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。
また、要求の記載形式も、ＳＯＡＰメッセージに限られるものではない。要求をこのような構造化言語形式で記載された情報として受け付けるようにすれば、データの汎用性を高め、データ形式の設計や改変を容易に行うことができるが、他の形式で記載することも可能である。
ＳＳＬを改良したＴＬＳ（Transport Layer Security）も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。
また、要求の記載形式も、ＳＯＡＰメッセージに限られるものではない。要求をこのような構造化言語形式で記載された情報として受け付けるようにすれば、データの汎用性を高め、データ形式の設計や改変を容易に行うことができるが、他の形式で記載することも可能である。
また、上述した実施形態では、ＣＡを上位装置１０と別に設ける例について説明したが、これと一体として設けることを妨げるものではない。この場合、ＣＡの機能を実現するためのＣＰＵ，ＲＯＭ，ＲＡＭ等の部品を独立して設けてもよいが、上位装置１０のＣＰＵ，ＲＯＭ，ＲＡＭ等を使用し、そのＣＰＵに適当なソフトウェアを実行させることにより、ＣＡとして機能させるようにしてもよい。
さらにまた、上位装置１０と下位装置２０が、目的に応じて種々の構成をとることができることは既に述べたが、このような場合も、各種機能３８０に含まれる機能の種類は装置の種類や構成に応じて適宜定めることができ、レスキュー公開鍵証明書によって通信相手に認証された場合に通常公開鍵証明書の設定に関する要求以外の要求に係る処理を禁止するようにすれば、上述した実施形態の場合のような効果を得ることができる。また、禁止から除外する要求を、通常公開鍵証明書の設定に関する要求に限らず適宜定め、セキュリティの比較的低いレスキュー公開鍵証明書を用いて認証処理を行った場合に一部の機能の使用を制限するような機能制限を行うようにすることも考えられる。
上位装置１０と下位装置２０の具体例としては、例えば、遠隔管理システムにおいて、プリンタ，ＦＡＸ装置，コピー機，スキャナ，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム、自動車、航空機等に通信機能を設けた通信装置を被管理装置である下位装置２０とし、これらの被管理装置から情報を収集したり、コマンドを送って動作させたりするための管理装置を上位装置１０とすることが考えられる。
上位装置１０と下位装置２０の具体例としては、例えば、遠隔管理システムにおいて、プリンタ，ＦＡＸ装置，コピー機，スキャナ，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム、自動車、航空機等に通信機能を設けた通信装置を被管理装置である下位装置２０とし、これらの被管理装置から情報を収集したり、コマンドを送って動作させたりするための管理装置を上位装置１０とすることが考えられる。
また、この発明によるプログラムは、コンピュータを、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、その通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信装置である下位装置２０のような装置として機能させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
以上説明してきた通り、この発明の通信装置、通信システム、通信装置の制御方法あるいはプログラムによれば、通信手段を備え、通信の際に通信相手に認証を受けるためにデジタル証明書を提供する通信装置を用いて通信システムを構成する場合において、セキュリティを維持しながら、正常な認証を受けられる状態を容易に維持できるようにすることができる。従って、通信システムの運用を高い信頼性で行うことができる。
１０…上位装置、１１…ＣＰＵ、１２…ＲＯＭ、１３…ＲＡＭ、１４…ＨＤＤ、
１５…通信Ｉ／Ｆ、１６…システムバス、２０…下位装置、３０…ネットワーク、
４０…ＨＴＴＰリクエスト、５０…ＨＴＴＰレスポンス、
３３１…ＨＴＴＰデーモン、３８０…各種機能、４１０…第１振り分け部、
４２１…通常処理ＵＲＬ用第２振り分け部、４２２…レスキューＵＲＬ用第２振り分け部
１５…通信Ｉ／Ｆ、１６…システムバス、２０…下位装置、３０…ネットワーク、
４０…ＨＴＴＰリクエスト、５０…ＨＴＴＰレスポンス、
３３１…ＨＴＴＰデーモン、３８０…各種機能、４１０…第１振り分け部、
４２１…通常処理ＵＲＬ用第２振り分け部、４２２…レスキューＵＲＬ用第２振り分け部
Claims (21)
- 通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、前記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する通信装置であって、
前記通信手段は、異なる暗号強度での認証処理に対応した２種類のデジタル証明書の提供を行い、前記複数のアドレスのうち第１のアドレスでは前記２種類のデジタル証明書のうち暗号強度が高い方の認証処理に対応した第１の証明書を提供し、第２のアドレスでは前記２種類のデジタル証明書のうち暗号強度が低い方の認証処理に対応した第２の証明書を提供する手段であり、
前記第２のアドレスで通信を行う場合には前記第１の証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段を設けたことを特徴とする通信装置。 - 請求項１記載の通信装置であって、
前記デジタル証明書を提供した通信相手から該通信相手のデジタル証明書を受信して認証を行い、該認証が成功した場合のみその後の通信を許可する認証手段を設け、
前記要求実行手段に、その通信相手から前記第１の証明書の設定要求を受信した場合に前記第１の証明書を更新する手段を設けたことを特徴とする通信装置。 - 請求項１又は２記載の通信装置であって、
前記第１の証明書の設定に関する要求は、前記第１の証明書の作成に必要な情報の取得要求と前記第１の証明書の設定要求であることを特徴とする通信装置。 - 請求項１乃至３のいずれか一項記載の通信装置であって、
前記要求実行手段は、前記要求に対応する所定の処理を行う複数の要求処理手段を有し、
受信したアドレスと要求の種類とに従って要求を前記各要求処理手段に振り分ける振り分け手段を設け、
前記禁止手段は、前記振り分け手段が前記通信を行っているアドレスによっては所定の要求以外の要求を前記要求処理手段に振り分けないようにすることにより、前記処理の禁止を行う手段であることを特徴とする通信装置。 - 請求項１乃至４のいずれか一項記載の通信装置であって、
前記要求はＳＯＡＰメッセージとして記載されていることを特徴とする通信装置。 - 請求項１乃至５のいずれか一項記載の通信装置であって、
前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信装置。 - 通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、前記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段とを有する下位装置と、該下位装置の通信相手となる上位装置とによって構成される通信システムであって、
前記下位装置の前記通信手段は、異なる暗号強度での認証処理に対応した２種類のデジタル証明書の提供を行い、前記複数のアドレスのうち第１のアドレスでは前記２種類のデジタル証明書のうち暗号強度が高い方の認証処理に対応した第１の証明書を提供し、第２のアドレスでは前記２種類のデジタル証明書のうち暗号強度が低い方の認証処理に対応した第２の証明書を提供する手段であり、
前記下位装置に、前記第２のアドレスで通信を行う場合には前記第１の証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段を設け、
前記上位装置に、通信相手から受信したデジタル証明書を用いてその通信相手を認証する認証手段を設けたことを特徴とする通信システム。 - 請求項７記載の通信システムであって、
前記下位装置に、前記デジタル証明書を提供した通信相手から該通信相手のデジタル証明書を受信して認証を行い、該認証が成功した場合のみその後の通信を許可する認証手段を設け、
前記下位装置の前記要求実行手段に、通信相手から前記第１の証明書の設定要求を受信した場合に前記第１の証明書を更新する手段を設けたことを特徴とする通信システム。 - 請求項７又は８記載の通信システムであって、
前記第１の証明書の設定に関する要求は、前記第１の証明書の作成に必要な情報の取得要求と前記第１の証明書の設定要求であることを特徴とする通信システム。 - 請求項７乃至９のいずれか一項記載の通信システムであって、
前記要求はＳＯＡＰメッセージとして記載されていることを特徴とする通信システム。 - 請求項７乃至１０のいずれか一項記載の通信システムであって、
前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信システム。 - 通信装置に、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供させ、前記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行わせ、該通信において通信相手から受信した要求に応じた処理を行わせる通信装置の制御方法であって、
前記通信装置に、異なる暗号強度での認証処理に対応した２種類のデジタル証明書の提供を行わせ、前記複数のアドレスのうち第１のアドレスでは前記２種類のデジタル証明書のうち暗号強度が高い方の認証処理に対応した第１の証明書を提供させ、第２のアドレスでは前記２種類のデジタル証明書のうち暗号強度が低い方の認証処理に対応した第２の証明書を提供させ、
前記第２のアドレスで通信を行う場合には前記第１の証明書の設定に関する要求以外の要求に係る処理を禁止させることを特徴とする通信装置の制御方法。 - 請求項１２記載の通信装置の制御方法であって、
さらに、前記通信装置に、前記デジタル証明書を提供した通信相手から該通信相手のデジタル証明書を受信させて認証を行わせ、該認証が成功した場合のみその後の通信を許可させるようにし、
通信相手から前記第１の証明書の設定要求を受信した場合に前記第１の証明書を更新させることを特徴とする通信装置の制御方法。 - 請求項１２又は１３記載の通信装置の制御方法であって、
前記第１の証明書の設定に関する要求は、前記第１の証明書の作成に必要な情報の取得要求と前記第１の証明書の設定要求であることを特徴とする通信装置の制御方法。 - 請求項１２乃至１４のいずれか一項記載の通信装置の制御方法であって、
前記要求はＳＯＡＰメッセージとして記載されていることを特徴とする通信装置の制御方法。 - 請求項１２乃至１５のいずれか一項記載の通信装置の制御方法であって、
前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信装置の制御方法。 - コンピュータを、通信相手に認証を受けるために複数のアドレスでデジタル証明書を提供し、前記通信相手に認証されたデジタル証明書を提供したアドレスで通信を行う通信手段と、該通信手段によって通信相手から受信した要求に応じた処理を行う要求実行手段として機能させるためのプログラムであって、
前記通信手段は、異なる暗号強度での認証処理に対応した２種類のデジタル証明書の提供を行い、前記複数のアドレスのうち第１のアドレスでは前記２種類のデジタル証明書のうち暗号強度が高い方の認証処理に対応した第１の証明書を提供し、第２のアドレスでは前記２種類のデジタル証明書のうち暗号強度が低い方の認証処理に対応した第２の証明書を提供する手段であり、
さらに、前記コンピュータを、前記第２のアドレスで通信を行う場合には前記第１の証明書の設定に関する要求以外の要求に係る処理を禁止する禁止手段として機能させるためのプログラムを含むことを特徴とするプログラム。 - 請求項１７記載のプログラムであって、
さらに、前記コンピュータを、前記デジタル証明書を提供した通信相手から該通信相手のデジタル証明書を受信して認証を行い、該認証が成功した場合のみその後の通信を許可する認証手段として機能させるためのプログラムを含み、
前記要求実行手段に、その通信相手から前記第１の証明書の設定要求を受信した場合に前記第１の証明書を更新する機能を設けたことを特徴とするプログラム。 - 請求項１７又は１８記載のプログラムであって、
前記第１の証明書の設定に関する要求は、前記第１の証明書の作成に必要な情報の取得要求と前記第１の証明書の設定要求であることを特徴とするプログラム。 - 請求項１７乃至１９のいずれか一項記載のプログラムであって、
前記要求はＳＯＡＰメッセージとして記載されていることを特徴とするプログラム。 - 請求項１７乃至２０のいずれか一項記載のプログラムであって、
前記認証は、ＳＳＬ又はＴＬＳのプロトコルに従った認証処理によって行い、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とするプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004228590A JP4537797B2 (ja) | 2003-09-22 | 2004-08-04 | 通信装置、通信システム、通信装置の制御方法及びプログラム |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003329219 | 2003-09-22 | ||
| JP2003341329 | 2003-09-30 | ||
| JP2004228590A JP4537797B2 (ja) | 2003-09-22 | 2004-08-04 | 通信装置、通信システム、通信装置の制御方法及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2005130455A JP2005130455A (ja) | 2005-05-19 |
| JP4537797B2 true JP4537797B2 (ja) | 2010-09-08 |
Family
ID=34657717
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004228590A Expired - Fee Related JP4537797B2 (ja) | 2003-09-22 | 2004-08-04 | 通信装置、通信システム、通信装置の制御方法及びプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4537797B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007329731A (ja) * | 2006-06-08 | 2007-12-20 | Hitachi Ltd | 証明書更新方法、システム及びプログラム |
| JP2011081762A (ja) | 2009-03-10 | 2011-04-21 | Ricoh Co Ltd | 機器設定装置及び機器設定装置における機器再設定方法 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001507528A (ja) * | 1995-11-14 | 2001-06-05 | マイクロソフト コーポレーション | ルート・キーが危機にさらされた時の回復 |
| JP2002287629A (ja) * | 2001-03-26 | 2002-10-04 | Toppan Printing Co Ltd | 電子デバイス、電子デバイス内の情報更新システム、情報更新方法およびそのプログラム |
| JP2003006161A (ja) * | 2001-06-20 | 2003-01-10 | Mitsubishi Electric Corp | クライアントコンピュータにサービスを提供するサーバ、サービスを提供する方法およびサービスを提供するためのプログラム |
| JP2003196160A (ja) * | 2001-12-28 | 2003-07-11 | Mitsubishi Electric Corp | Ｉｃカードおよびｉｃカードの記録情報管理方法 |
| JP2005130452A (ja) * | 2003-07-25 | 2005-05-19 | Ricoh Co Ltd | 通信装置、通信システム、証明書送信方法及びプログラム |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH05336108A (ja) * | 1992-06-04 | 1993-12-17 | Toshiba Corp | 無線通信システム |
| JPH06268638A (ja) * | 1993-03-10 | 1994-09-22 | Nippon Telegr & Teleph Corp <Ntt> | 端末認証制御法 |
| JPH118619A (ja) * | 1997-06-18 | 1999-01-12 | Hitachi Ltd | 電子証明書発行方法及びシステム |
| JP3905961B2 (ja) * | 1997-11-11 | 2007-04-18 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 臨時署名認証の方法及びそのシステム |
-
2004
- 2004-08-04 JP JP2004228590A patent/JP4537797B2/ja not_active Expired - Fee Related
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001507528A (ja) * | 1995-11-14 | 2001-06-05 | マイクロソフト コーポレーション | ルート・キーが危機にさらされた時の回復 |
| JP2002287629A (ja) * | 2001-03-26 | 2002-10-04 | Toppan Printing Co Ltd | 電子デバイス、電子デバイス内の情報更新システム、情報更新方法およびそのプログラム |
| JP2003006161A (ja) * | 2001-06-20 | 2003-01-10 | Mitsubishi Electric Corp | クライアントコンピュータにサービスを提供するサーバ、サービスを提供する方法およびサービスを提供するためのプログラム |
| JP2003196160A (ja) * | 2001-12-28 | 2003-07-11 | Mitsubishi Electric Corp | Ｉｃカードおよびｉｃカードの記録情報管理方法 |
| JP2005130452A (ja) * | 2003-07-25 | 2005-05-19 | Ricoh Co Ltd | 通信装置、通信システム、証明書送信方法及びプログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2005130455A (ja) | 2005-05-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4555175B2 (ja) | 審査装置、通信システム、審査方法、プログラム及び記録媒体 | |
| JP4712325B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
| JP4576210B2 (ja) | 証明書転送装置、証明書転送システム、証明書転送方法、プログラム及び記録媒体 | |
| JP4522771B2 (ja) | 通信装置、通信システム、通信装置の制御方法及びプログラム | |
| JP4509678B2 (ja) | 証明書設定方法 | |
| JP4611680B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
| JP4504130B2 (ja) | 通信装置、通信システム、証明書送信方法及びプログラム | |
| JP4583833B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
| JP4537797B2 (ja) | 通信装置、通信システム、通信装置の制御方法及びプログラム | |
| JP4657642B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
| JP4611676B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
| JP4542848B2 (ja) | 通信装置、通信システム、通信装置の制御方法及びプログラム | |
| JP4570919B2 (ja) | 通信装置、通信システム、通信装置の制御方法及びプログラム | |
| JP4611678B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
| JP2005065247A (ja) | 通信装置、通信装置の制御方法、通信システム、プログラム及び記録媒体 | |
| JP4671638B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
| JP4778210B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
| JP4712330B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
| JP4657643B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
| JP4712326B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
| JP4509675B2 (ja) | 通信装置、通信システム及び通信方法 | |
| JP4611681B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
| JP2011072046A (ja) | 証明書設定方法 | |
| JP2011097635A (ja) | 通信装置、通信システム及び証明書設定方法 | |
| JP2011097636A (ja) | 通信装置、通信システム及び証明書設定方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070326 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100615 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100618 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130625 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |