JP4671783B2 - 通信システム - Google Patents

Description

この発明は、証明書及び該証明書と対応する私有鍵を記憶する通信装置と証明書送信装置とを備えた通信システムに関する。

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

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

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

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

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

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

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

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

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

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

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

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

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

なお、このような認証処理に使用する公開鍵の管理に関する技術としては、例えば特許文献３及び４に記載の技術が知られている。
特許文献３には、ネットワーク上に鍵登録装置を実装して公開鍵の管理をすることにより、ユーザの負荷を軽減することが記載されている。
特許文献４には、電子メールの暗号化を行うために公開鍵暗号を利用する場合において、電子メール装置の公開鍵データベースに必要な公開鍵のみを自動的に登録したり、有効な公開鍵のみが保持されるように自動的に管理することが記載されている。
特開２００３−３４８０６８号公報（段落０００４） 特開２００２−１９０７９６号公報

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

また、第３者機関により公開鍵証明書を発行するサービスも提供されているが、このような機関が発行する公開鍵証明書は、安全性を考慮し、有効期間が１〜３年程度と短い。そして、この期間が過ぎた証明書では認証が失敗するようにしてある。そこで、このような第３者機関が発行した公開鍵証明書を利用しようとする場合には、有効期間が経過する前に証明書を新しいものに更新する必要がある。
なお、上述した特許文献３及び４に記載の技術は、他の装置から受信したその送信元装置の公開鍵を、単にその送信元装置の情報と対応させて管理したり有効性を検証したりすることが記載されているのみであり、新たな公開鍵証明書の発行については特に記載されていない。

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

しかしながら、ＳＳＬを用いて安全な通信経路を確保したとしても、インターネットを経由して通信する場合、どのようなサーバを介して情報が転送されるかわからないのであるから、転送する情報を盗み見られたり、改竄されたりする可能性はゼロではない。そして、万一私有鍵を盗み見られてしまうと、なりすましが可能になってしまうので、このような危険性は例え僅かなものであっても排除したいという要求があった。
この発明は、このような要求に応え、通信装置が認証に使用する証明書を自動的に更新することを可能としながら、私有鍵の漏洩の可能性を低下させ、安全な更新を実現させることを目的とする。

また、この発明の通信システムは、通信装置と証明書送信装置とを備える通信システムにおいて、上記通信装置に、通信相手の装置に認証を受けるための証明書及びその証明書と対応する私有鍵を記憶する記憶手段と、上記記憶手段に記憶している証明書の更新時期を検出する更新時期検出手段と、上記更新時期検出手段が、上記記憶手段に記憶している証明書が更新時期になったことを検出したときに、対になる公開鍵及び私有鍵を生成する鍵生成手段と、上記記憶手段に記憶している証明書の有効期限が切れる前に、その証明書を上記証明書送信装置に送信し、その証明書を用いて上記証明書送信装置に認証されたときに、その証明書送信装置に上記鍵生成手段が生成した公開鍵を送信する公開鍵送信手段と、上記公開鍵送信手段による公開鍵の送信に応じて上記証明書送信装置から送信されてくる、その公開鍵を含む証明書と、上記鍵生成手段が生成したその公開鍵と対になる私有鍵とを、相手先装置に認証を受けるための新たな証明書及びその新たな証明書と対応する私有鍵として上記記憶手段に記憶させる証明書設定手段とを設け、上記証明書送信装置に、証明書を受信してその証明書を用いてその証明書の送信元を認証する認証手段と、上記認証手段が認証した送信元から公開鍵を受信する受信手段と、上記公開鍵の送信元を、その送信元について管理契約期間が上記認証手段の受信した証明書の有効期限後まであることを確認する工程を少なくとも含む工程により審査する審査手段と、上記審査手段による審査に合格した場合に、上記受信手段が受信した公開鍵を含む証明書を上記公開鍵の送信元に送信する送信手段とを設けたものである。
このような通信システムにおいて、上記証明書送信装置に、上記受信手段が受信した公開鍵に署名を付して証明書を作成する証明書作成手段を設けるとよい。

さらに、上記証明書送信装置の証明書作成手段に、作成する証明書に、上記受信した証明書に記載されている、その証明書の送信元の識別情報を記載する手段を設けるとよい。
さらに、上記証明書送信装置の審査手段を、上記認証手段が受信した証明書を用いて、上記認証手段が受信した証明書の有効期限までの期間が所定の閾値以下であることを確認する工程を含む上記送信元の審査を行う手段とするとよい。

さらにまた、上記通信装置の上記公開鍵送信手段が上記証明書送信装置に認証を受けるために送信する証明書が、その通信装置の製造時にその通信装置に設定された証明書であるとよい。
また、上記証明書送信装置の審査手段を、上記認証手段が受信した証明書に記載されている、その証明書の送信元の識別情報を用いてその送信元の審査を行う手段とするとよい。
さらに、上記証明書送信装置の送信手段に、上記公開鍵証明書を送信する場合に、その公開鍵証明書と共に、その公開鍵証明書の正当性を確認するための証明鍵も送信する手段を設け、上記通信装置の上記証明書設定手段に、上記公開鍵送信手段による公開鍵の送信に応じて上記相手先装置から上記証明書に加えてその証明書の正当性を確認するための証明鍵も受信し、その証明鍵を用いて受信した証明書の正当性を確認した後で、受信した証明書を上記記憶手段に記憶させる手段を設けるとよい。

以上のようなこの発明の通信システムによれば、通信装置が認証に使用する証明書を自動的に更新することを可能としながら、私有鍵の漏洩の可能性を低下させ、安全な更新を実現させることができる。

以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明の証明書送信装置と、その証明書送信装置を用いて構成したこの発明の通信システムの実施形態の構成について説明する。
図１にその通信システムの構成を示す。
この実施形態においては、証明書送信装置である管理装置３０及びその通信相手となる通信装置である管理対象機器４０によって通信システムを構成している。なお、この通信システムにおいて、管理装置３０は、管理対象機器４０を管理する機能の他、管理対象機器４０に対して認証処理に使用するデジタル証明書として公開鍵証明書を発行して送信する機能も有する。

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

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

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

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

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

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

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

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

認証処理部３３は、ＨＴＴＰＳクライアント機能部３１やＨＴＴＰＳサーバ機能部３２が通信相手を認証する際に、通信相手から受信した公開鍵証明書や、証明書記憶部３４に記憶している各種証明書、私有鍵等を用いて認証処理を行う認証手段の機能を有する。また、通信相手に認証を要求するために証明書記憶部３４に記憶している公開鍵証明書をＨＴＴＰＳクライアント機能部３１やＨＴＴＰＳサーバ機能部３２を介して通信相手に送信する機能も有する。
証明書記憶部３４は、公開鍵証明書や私有鍵、ルート鍵証明書等の認証情報を記憶し、認証処理部３３における認証処理に供する機能を有する。また、証明書発行部３７が発行した公開鍵証明書及びその発行先に関する情報をデータベースとして記憶しておく機能も有する。

要求管理部３５は、管理装置から受信したコマンドについて、そのコマンドに基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、そのコマンドに基づいた動作を実行する機能部に対してコマンドを伝える機能も有する。なお、図３においては、コマンドに基づいた動作を実行する機能部として、具体的なものは証明書審査部３６及び証明書発行部３７のみを示し、これら以外の機能部は、コマンド処理部３８として一括して示している。

証明書審査部３６は、通信相手から更新用公開鍵を受信した場合に、その送信元に対して公開鍵証明書を発行してよいか否かを審査する機能を有する。証明書発行部３７は、証明書審査部３６が審査で公開鍵証明書を発行してよいと判断した場合に、受信した更新用公開鍵にデジタル署名を付して更新用公開鍵証明書を発行し、更新用公開鍵の送信元に送信する機能を有する。なお、証明書発行部３７は、これ以外にも、後述する生産工場にて管理対象機器４０に記憶させる公開鍵証明書を発行する機能も有する。

コマンド処理部３８は、証明書審査部３６及び証明書発行部３７以外の機能に係る要求に対応する動作を実行する機能を有する。この動作としては、例えば管理対象機器４０からの異常発生通知に対する対応や、管理対象機器４０からの要求に応じて管理装置３０が記憶しているデータを送信する動作等が挙げられる。
コマンド発行部３９は、管理対象機器４０に対して種々のコマンドを発行して管理対象機器４０にそのコマンドに従った動作を実行させる機能を有する。管理対象機器４０に実行させる動作としては、管理対象機器４０の動作内容や設定状態に関する情報の送信、管理装置３０から送信した情報の記憶やそれに応じた設定変更等が考えられる。そして、コマンド発行部３９は、管理対象機器４０から取得した情報に従って管理対象機器４０に種々の動作を実行させることにより、管理対象機器４０を管理する機能も有する。
そして、これらの各部の機能は、管理装置３０のＣＰＵが所要の制御プログラムを実行して管理装置３０の各部の動作を制御することにより実現される。

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

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

コール通知部４４は、異常を検知したりユーザによる指示があったりした場合に管理装置３０に対してその旨を通知するコールを行う機能を有する。
定期通知部４５は、管理対象機器４０から管理装置３０への定期的な通知を行う機能を有する。その通知の内容としては、例えば画像形成装置であれば画像形成枚数カウンタのカウント値、計量システムであればその計量値等が考えられる。
証明書記憶部４６は、管理装置３０の証明書記憶部３４と同様に各種の証明書や私有鍵等の認証情報を記憶し、認証処理部４３における認証処理に供する証明書記憶手段の機能を有する。ただし、記憶している証明書等は、後述するように証明書記憶部３４とは異なる。

証明書更新部４７は、証明書記憶部４６に記憶している公開鍵証明書のうち、管理装置３０との間の認証処理に使用している公開鍵証明書の有効期限が近づいた場合に、鍵生成部４８と鍵通知部４９にその更新を行わせる機能を有する。
そして、鍵生成部４８は、更新用の鍵ペアとして更新用公開鍵と更新用私有鍵のセットを所定のアルゴリズムに従って生成し、更新用私有鍵を証明書記憶部４６に記憶させると共に更新用公開鍵を鍵通知部４９に渡してこれを管理装置３０に送信させる機能を有する。

鍵通知部４９は、鍵生成部４８が生成した更新用公開鍵を管理装置３０に送信すると共に、管理装置３０がこれにデジタル署名を付して返してくる更新用公開鍵証明書を受信し、この更新用公開鍵証明書を更新用私有鍵と対応させて証明書記憶部４６に記憶させ、これらを管理装置３０との間の認証処理に使用する公開鍵証明書及び私有鍵として設定する機能を有する。

要求管理部５０は、管理装置３０から受信したコマンドについて、そのコマンドに基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、コマンド処理部５１中でそのコマンドに基づいた動作を実行する機能部に対してコマンドを伝える機能も有する。
コマンド処理部５１は、管理装置３０から受信したコマンドに応じた動作を実行する機能を有する。この動作としては、例えば管理対象機器４０が記憶しているデータの送信や、必要に応じて図示を省略したエンジン部の動作を制御することが挙げられる。
そして、これらの各部の機能は、管理対象機器４０のＣＰＵが所要の制御プログラムを実行して管理対象機器４０の各部の動作を制御することにより実現される。

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

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

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

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

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

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

ところで、以上説明したような認証処理を行うためには、管理装置３０と管理対象機器４０とにそれぞれ、図４に示したような公開鍵証明書や鍵を設定し、認証処理に使用できる状態にしておく必要がある。そして、管理装置３０については、自身で公開鍵証明書やルート鍵証明書を発行できるので、自身でこれを設定すればよい。
しかし、管理対象機器４０については、機器毎に設定する必要がある。また、識別情報として管理対象機器４０の機番等を記載した公開鍵証明書を用いるのであれば、各機器に対応する公開鍵証明書を発行し、これを適切な機器に設定する必要があるが、このような設定は、管理対象機器４０の生産時に生産工場にて行うことができる。
以下、生産工場にて管理対象機器４０に証明書を設定する場合に使用する設備や設定の手順について説明する。

図７は、管理対象機器４０を生産する生産工場及び関連施設に設ける、証明書の設定に関連する設備の構成例を示すブロック図である。
この図に示すように、管理対象機器４０を生産する生産工場Ｅには、通信端末１５０及び工場端末１６０が設置されている。また、関連施設には、生産管理装置１４０を設け、また管理装置３０も管理対象機器４０に記憶させる公開鍵証明書を発行するＣＡとして用いるために設けている。

このうち、生産管理装置１４０は、メーカーにおける装置の生産計画を立案・管理するための装置であり、管理対象機器４０等の日々の生産数を管理するためにも使用される。そして、管理装置３０は、公開鍵証明書や私有鍵の発行、署名、管理等を行う機能を有し、外部装置からの要求に応じて公開鍵証明書を発行し、送信することもできる。
通信端末１５０は、生産工場Ｅの外部と通信を行い、必要な情報を取得したり、要求を送信したりする装置である。この通信は、種々のネットワークを使用して行うことができる。そして、インターネットを用いる場合には、ＳＳＬ等の適当な方法によりセキュリティを確保するものとする。そして、生産管理装置１４０と通信して機種毎にその日の通信装置の生産台数の情報を取得すると共に、生産予定の各装置に付す機種機番が含まれる図４（ａ）に示したような証明書セットを管理装置３０から取得する機能を有する。

また、証明書データベース（ＤＢ）１５４ａは、通信端末１５０のハードディスクドライブ（ＨＤＤ）に設けたデータベースである。入力装置１５６と表示装置１５７は、それぞれ入出力のためのキーボードやディスプレイ等である。
バーコードリーダ１４１は、生産工場Ｅで生産される装置に貼付された定格銘板あるいは対応するチェックシート上の機番（識別情報）を示すバーコードの情報を読み取って工場端末１６０へ送信するハンドタイプの小型バーコードリーダである。
そして、工場端末１６０は、機番が入力された場合に、その機番に対応する証明書を通信端末１５０から入手し、それを対応する管理対象機器４０へ送信してその不揮発性メモリ（記憶手段）に書き込ませる１以上の装置である。

次に、図８のシーケンス図に、図７に示した設備によって生産工場Ｅで管理対象機器４０に公開鍵証明書等を設定するための処理の流れを示す。この図におけるローマ数字は、図７に示したローマ数字と対応する通信であることを示す。
生産工場Ｅにて管理対象機器４０を生産する場合、図８に示すように、まず通信端末が予め決められた日時に、生産管理装置１４０から、生産工場Ｅで生産する装置の機種コード一覧や各日の機種毎の生産予定台数等の情報を取得する（I）。

また、通信端末１５０は、毎日決められた時刻に、生産管理装置１４０から取得した情報に基づいて、当日生産予定の各通信装置に設定すべき個別証明書セットの送信を要求する証明書発行要求を生成して管理装置３０に送信する。
すると、管理装置３０がこれに応じて、その証明書発行要求と共に受信した機番情報を公開鍵証明書に含む証明書セットを、各機番情報について作成し、通信端末１５０に送信してくるので、通信端末１５０はこれを受信して証明書ＤＢ１５４ａに記憶する（II）。

次に、生産用ラインにおいて組み立てられ、検査を受けた管理対象機器４０が、機番を付され、定格銘板を貼付されて個別証明書の設定工程に供されると、作業員が、これを書き込み用Ｉ／Ｆを介して工場端末１６０と接続した上でバーコードリーダ１４１で定格銘板のバーコードを読み取り、機番を工場端末１６０に入力する（III）。
すると、工場端末１６０はその機番を含む証明書セットの送信を通信端末１５０に要求し、通信端末１５０は、これに応じて、指定された機番と同じ機番を公開鍵証明書に含む証明書セットを証明書ＤＢ１５４ａから読み出して工場端末１６０へ送信する。

これを受信した工場端末１６０は、書き込み用Ｉ／Ｆを介して接続されている、機番が読み取られた管理対象機器４０に、通信端末１５０から受信した証明書セットを管理装置３０との間の認証に使用する証明書セットとして設定するよう要求する（IV）。
一方、管理対象機器４０は、この要求を受信すると、この要求と共に受信した証明書セットを証明書メモリに書き込んで設定し、その結果を工場端末１６０に送信する。
また、通信端末１５０は、この工程により設定の完了した証明書を、定期的にチェックして削除するようにするとよい。
以上の処理により、通信端末１５０が、生産管理装置１４０から取得した生産計画に従って、識別情報として機種機番情報を含む証明書セットを必要な数だけ管理装置３０から取得し、生産した管理対象機器４０に工場端末１６０を介して設定することができる。

このとき、管理対象機器４０の証明書メモリには、管理装置３０と通信を行うための情報として、図９に示すような情報が記憶される。すなわち、証明書セットＳと、その証明書セットに含まれる公開鍵証明書を用いて認証処理を行う通信相手である管理装置３０に通信を要求する際の通信先情報Ｕと、証明書セットＳに含まれる公開鍵証明書のバージョンを示すバージョン情報Ｖとが記憶される。
なお、通信先情報Ｕは、図９の例ではＵＲＬ（Uniform Resource Locator）として記載しているが、これに限られることはない。また、証明書セットＳを記憶させる記憶領域と、通信先情報Ｕを記憶させる記憶領域と、バージョン情報Ｖを記憶させる記憶領域とは、各々の対応関係が把握できるようにしてあれば、必ずしも隣接あるいは近接した領域でなくても構わない。また、証明書セットＳについても、公開鍵証明書と私有鍵とルート鍵証明書とを常にセットで取り扱うことは、必須ではない。
また、上記のように工場での生産時に管理対象機器４０に設定される管理対象機器４０の最初の公開鍵証明書を、「オリジナル証明書」と呼ぶことにする。

以上のような設定は、管理対象機器４０の生産者が管理できる生産工場内で行われることから、通信内容が外部に漏れることは考えにくく、安全に証明書の設定を行うことができる。また、管理装置３０を生産工場Ｅの外部に設ける場合でも、管理装置３０と通信端末１５０との間の通信を専用線を介して行うようにすれば、かなり高い安全性を得ることができる。

ところで、上述した通り、オリジナル証明書を含め、公開鍵証明書には通常は有効期限が設定されており、有効期限が切れた公開鍵証明書を用いて認証を要求された場合には、認証が失敗するようにしている。従って、管理対象機器４０に設定する公開鍵証明書は、有効期限が切れる前に更新する必要がある。そしてこの時点では、管理対象機器４０は事業所や住居等のユーザ側環境にて使用されていることが多いと想定されるので、図７及び図８を用いて説明したものと同様な手順により更新用の公開鍵証明書を設定することは難しいと考えられる。
そこで、次に、管理対象機器４０がユーザ側環境にて使用されている状態で公開鍵証明書を更新する際に管理装置３０及び管理対象機器４０が実行する処理について説明する。

まず、図１０のシーケンス図に、更新処理全体の流れを示す。
図１０に示すとおり、この処理においては、管理対象機器４０は、管理装置３０との間の認証処理に使用する公開鍵証明書の有効期限の一定期間前（例えば１ヶ月前）になったことを検出すると（Ｓ１１）、公開鍵証明書の更新時期になったと判断し、以下の証明書更新に関する処理を行う。なお、公開鍵更新に関する処理を開始する条件は、別の基準で定めるようにしてもよい。
そして、ステップＳ１２以下においては、まず鍵生成部４８の機能により、新たな公開鍵と私有鍵のペアを、更新用鍵ペアとして生成する（Ｓ１２）。その後、管理装置３０に通信を要求して通常通り認証処理に使用するものとして設定されている証明書を用いた認証処理を行い（Ｓ１３）、認証が成功したら、鍵通知部４９の機能により、ステップＳ１２で生成した新たな公開鍵を更新用公開鍵として記載した自己生成公開鍵通知を管理装置３０に送信する（Ｓ１４）。なお、自己生成公開鍵通知は、管理装置３０に対して、送信した公開鍵にデジタル署名を付して公開鍵証明書を発行することを要求するコマンドであると考えることもできる。また、ステップＳ１３での認証は、相互認証が好ましいが、少なくとも管理装置３０が管理対象機器４０を認証できれば、相互認証でも片方向認証でも構わない。

管理装置３０は、管理対象機器から自己生成公開鍵通知を受信すると、要求通り公開鍵証明書を発行してよいかどうか判断するため、証明書審査部３６の機能により、通知の送信元である管理対象機器４０を審査する（Ｓ１５）。この審査は、受信した公開鍵自体の情報の他、ステップＳ１３での認証処理時に管理対象機器４０から受信した公開鍵証明書に記載されている事項も用いて行うが、その内容に付いては後に詳述する。

そして、管理対象機器４０が審査に合格した場合、証明書発行部３７の機能により、受信した更新用公開鍵にデジタル署名を付して更新用公開鍵証明書を作成して発行し、これを証明書記憶部３４のデータベースに登録する（Ｓ１６）。そして、作成した更新用公開鍵証明書を管理対象機器４０に送信する（Ｓ１７）。この送信は、ステップＳ１４で受信したコマンドに対する応答であると考えることができる。また、更新用公開鍵証明書の有効期限は、通常は少なくとも管理対象装置４０に現在設定されている証明書の有効期限よりは後である。
そして、更新用公開鍵証明書を受信した管理対象機器４０は、その受信した更新用公開鍵証明書と、ステップＳ１２で生成した更新用私有鍵とを、管理装置３０との間の認証処理に使用する公開鍵証明書及び私有鍵として設定する（Ｓ１８）。

以上の処理により、管理対象機器４０は、それまで使用していた公開鍵証明書よりも有効期限までの期間が長い公開鍵証明書を取得し、以後これを用いて管理装置３０との間の認証処理を行うことができるようにするとことができる。そして、このような処理を行うことにより、管理対象機器４０が管理装置３０と通信可能な状態である場合には公開鍵証明書の更新が可能となる。この処理は、管理対象機器４０に設定されている証明書がオリジナル証明書である場合にも、既に更新が行われた証明書である場合（２回目以降の更新を行う場合）でも、同様に行うことができる。
以下、このような更新処理を行う場合に管理装置３０及び管理対象機器４０が実行する処理について、より詳細に説明する。

まず、図１１に、図１０に示した処理を実行する場合の管理装置３０側の処理のフローチャートを示す。この図に示す処理は、管理装置３０のＣＰＵ１１が所要の制御プログラムを実行することにより行うものである。
そして、管理装置３０のＣＰＵ１１は、管理対象機器４０から通信の要求を受けると、図１１のフローチャートに示す処理を開始し、まずステップＳ２１でＳＳＬによる認証処理を行って管理対象機器４０を認証する。この処理としては、例えば背景技術の項で図２１を用いて説明したものを採用することができるので、詳細な説明は省略する。ただし、この認証処理において管理対象機器４０から受信する公開鍵証明書は、後の処理に使用するので、適当な記憶手段に記憶しておくようにする。
また、ＳＳＬによる認証処理をＳＳＬアクセラレータのような専用のハードウェアを用いて行う場合、認証に使用した証明書の内容を別の処理で参照することが困難な場合もある。このような場合には、認証が成功した後で、管理対象機器４０に再度管理装置３０に対して公開鍵証明書を送信させるようにするとよい。

ステップＳ２１での認証が成功すると、ステップＳ２２で管理対象機器４０から更新用公開鍵を受信する。この受信は、図１０に示した自己生成公開鍵通知によるものであり、受信する公開鍵のフォーマットは例えば図１２に示すようなものである。すなわち、公開鍵の本体に、その公開鍵の鍵長や生成アルゴリズムを示す情報が付加されたものである。ただし、管理対象機器４０自体の情報は、公開鍵に記載されている必要はなく、図１２の例では記載されていない。
また、管理対象機器４０は、この自己生成公開鍵通知をＳＯＡＰリクエストの形式で行うことができる。このメッセージは構造化言語であるＸＭＬの形式で記載されており、具体例は図１３に示すものとなる。この例においては、ＳＯＡＰボディに、自己生成公開鍵通知であることを示す「自己生成公開鍵通知」タグを設け、その下位のタグに、更新用公開鍵を記載している。
このステップＳ２２の処理が受信手順の処理であり、この処理においては、ＣＰＵ１１が受信手段として機能する。そして、ステップＳ２２の後は、ステップＳ２３に進む。

ステップＳ２３では、ステップＳ２１でのＳＳＬによる認証処理時に受信した公開鍵証明書を用いて、更新用公開鍵の送信元の装置（ここでは管理対象機器４０）を審査する。ステップＳ２１での認証が成功しているということは、更新用公開鍵の送信元は、現時点では通信相手として適切な装置であるが、更新用公開鍵証明書を発行してよい相手か否かは、通信相手として適切か否かとは別の基準で判断することが望ましいため、ここでは別途審査の手順を設けているのである。
このステップＳ２３の処理が審査手順の処理であり、この処理においてはＣＰＵ１１が審査手段として機能する。

図１４に、このステップＳ２３での審査処理の内容の一例を示す。
この図に示す処理においては、まずステップＳ３１で、ＳＳＬによる認証処理時に受信した公開鍵証明書から、発行対象装置の識別情報と公開鍵証明書の期限の情報とを取得する。
そして、これらの情報をキーにして、管理対象とする装置についての情報を記録している図示しないテーブルを参照し、更新用公開鍵の送信元が管理対象の装置であるか否か、および更新用公開鍵の送信元について管理契約期間が使用中の公開鍵証明書の有効期限後まであるか否かを判断する（Ｓ３２，Ｓ３３）。そして、更新用公開鍵の管理対象の装置以外に対しては、今後も通信が可能な状態にしておく必要はないし、管理契約期間が使用中の公開鍵証明書の有効期限内で終了するのであれば、その後通信が可能な状態にしておく必要はないので、ステップＳ３２又はＳ３３の判断がＮＯである場合は、ステップＳ３９で審査ＮＧ（不合格）として以下の処理に進む。
なお、ステップＳ３３については、公開鍵証明書の有効期限を管理契約の期限をもとに定めてある場合には、管理延長契約がなされているか否かを基準に判断するようにしてもよい。

また、ステップＳ３２とＳ３３でＹＥＳであれば、ステップＳ３４に進み、現在の公開鍵証明書が期限切れ間近（例えば有効期限まで１ヶ月以内）か否か判断する。図１０に示した公開鍵更新処理は、公開鍵証明書の期限切れ間近に行われるはずであるから、この判断がＮＯの場合には、何らかの異常が発生していると考えられ、やはりステップＳ３９で審査ＮＧとしてもとの処理に戻る。
ステップＳ３４でもＹＥＳであれば、ステップＳ３５〜Ｓ３７で、受信した更新用公開鍵の内容をチェックする。具体的には、例えばフォーマット（Ｓ３５）、生成アルゴリズム（Ｓ３６）、鍵長（Ｓ３７）をチェックする。これらの判断は、受信した更新用公開鍵に記載されている情報をもとに行うことができる。また、受信した更新用公開鍵に関する情報が例えば使用中の公開鍵証明書に含まれる公開鍵に関する情報と同じ場合に適切であると判断することも考えられる。
そして、これらのうちいずれか１つでも不適切であれば、やはり何らかの異常が発生していると考えられるので、ステップＳ３９で審査ＮＧとしてもとの処理に戻る。
また、以上のステップＳ３２乃至Ｓ３７の判断が全てＹＥＳであれば、ステップＳ３８で審査ＯＫ（合格）として元の処理に戻る。

以上の処理により、更新用公開鍵証明書の送信元装置を審査すると共に、受信した更新用公開鍵の内容を検査し、公開鍵証明書を発行してよいか否かを判断することができる。なお、この判断にＳＳＬによる認証処理時に受信した公開鍵証明書に記載されている情報を用いることは必須ではない。しかし、自身の持つ管理対象機器認証用ルート鍵で公開鍵証明書の正当性が確認できていれば、そこに記載されている情報は信頼でき、改竄もされていないと考えられることから、公開鍵証明書に記載されている情報を用いることが好ましい。
また、審査処理において判断すべき項目については、図１４に示したものは一例に過ぎず、管理対象機器４０の用途や管理装置３０による管理の運用形態等に応じて適宜定めればよいことは、もちろんである。

図１１の説明に戻る。
ステップＳ２３の審査処理の後は、ステップＳ２４に進み、審査がＯＫであったか否か判断する。そして、ＯＫであればステップＳ２５に進み、ステップＳ２２で受信した更新用公開鍵に、認証処理時に使用しているルート鍵で正当性を確認できるデジタル署名を付加して更新用公開鍵証明書を作成する。
ここでいうデジタル署名の付加は、図１２に示したような更新用公開鍵に、公開鍵証明書の発行先装置や署名を付した装置の識別情報、証明書のシリアル番号、有効期限等の書誌情報を付し、さらにその全体をハッシュ処理して得たハッシュ値をルート私有鍵を用いて暗号化したものを付加することによって行うことができる。従って、更新用公開鍵証明書は、更新用公開鍵を含む公開鍵証明書である。そして、ここで用いるルート私有鍵は、管理装置３０が管理対象機器４０との間の認証処理を行う際に使用する管理対象機器認証用ルート鍵証明書に含まれるルート鍵と対応するものであり、ステップＳ２１での認証処理時に受信した管理対象機器４０の公開鍵証明書にデジタル署名を付した際に使用したルート私有鍵と同じものである。

また、更新用公開鍵に付す書誌情報についても、オリジナル証明書の場合と同じ管理装置３０が同じ管理対象機器４０に対して公開鍵証明書を発行するのであるから、少なくとも、公開鍵証明書の発行先装置や署名を付した装置の識別情報は、認証処理時に受信した管理対象機器４０の公開鍵証明書のものと同じものになる。そしてここでは、シリアル番号と有効期限以外の情報は全て、認証処理時に受信した管理対象機器４０の公開鍵証明書のものと同じものとしている。
このステップＳ２５の処理が証明書作成手順の処理であり、この処理においてはＣＰＵ１１が証明書作成手段として機能する。

次のステップＳ２６では、ステップＳ２５で発行した更新用公開鍵証明書を証明書記憶部３４のデータベースに登録する。図１５にこのデータベースの例を示すが、データベースに登録すべき項目としては、例えば証明書のシリアル番号，証明書の内容，有効期限，発行先装置の機番，証明書の発行日等が挙げられる。そして、証明書の内容については、発行した公開鍵証明書をそのまま記憶し、それ以外の項目については公開鍵証明書に付した書誌事項から抽出して記憶するようにするとよい。

このようなデータベースを作成することは必須ではないが、発行した公開鍵証明書をこのように記憶しておくようにすれば、管理動作や認証動作等に異常が生じた場合に、適当な項目をキーに検索して公開鍵証明書を取得し、異常の原因究明に役立てることができる。
ステップＳ２６の次はステップＳ２７に進み、ステップＳ２５で発行した更新用公開鍵証明書及び、その正当性を確認するための管理対象機器認証用ルート鍵証明書を、更新用公開鍵の送信元に送信し、以上で管理装置３０側の処理を終了する。

なお、図４に示したように、管理対象機器４０は、自身が記憶する公開鍵証明書の正当性を確認するためのルート鍵証明書は記憶していない。そこで、ステップＳ２７において、更新用公開鍵証明書と共に、その正当性を確認するためのルート鍵を含むルート鍵証明書（管理対象機器認証用ルート鍵証明書）も送信するようにするとよい。このようにすれば、管理対象機器４０は、受信した更新用公開鍵証明書が正しいものであり、破損等していないことをルート鍵証明書を用いて確認した上で設定できるため、公開鍵証明書更新処理の安定性を増すことができる。
もし管理対象機器４０が破損している更新用公開鍵証明書を設定してしまうと、管理装置３０との間の認証処理が失敗し、通信ができない状態になってしまうので、復旧に手間や時間がかかることから、このような事態を防止するため、更新用公開鍵証明書と共に管理対象機器認証用ルート鍵証明書も管理対象機器４０に送信することが好ましい。ただし、ルート鍵証明書の送信は必須ではない。

また、更新用公開鍵証明書及びルート鍵証明書の送信は、自己生成公開鍵通知のＳＯＡＰリクエストに対するＳＯＡＰレスポンスの形式で行うことができる。このメッセージも構造化言語であるＸＭＬの形式で記載されており、具体例は図１６に示すものとなる。この例においては、ＳＯＡＰボディに、自己生成公開鍵通知に対する応答であることを示す「自己生成公開鍵通知response」タグを設け、その下位のタグに、ステップＳ２３での審査の結果（ＯＫ）、更新用公開鍵証明書、およびその正当性を確認するためのルート鍵証明書を記載している。
このステップＳ２７の処理が送信手順の処理であり、この処理においてＣＰＵ１１が送信手段として機能する。

また、ステップＳ２４で審査がＮＧであれば、ステップＳ２８に進み、更新用公開鍵証明書に代えて審査時の不合格理由を記載したエラー通知を、更新用公開鍵の送信元に送信して処理を終了する。
このようなエラー通知も、自己生成公開鍵通知のＳＯＡＰリクエストに対するＳＯＡＰレスポンスの形式で行うことができる。この場合の具体例は図１７に示すものとなる。この例においては、ＳＯＡＰボディに、自己生成公開鍵通知に対する応答であることを示す「自己生成公開鍵通知response」タグを設け、その下位のタグに、ステップＳ２３での審査の結果（ＮＧ）及びその理由を記載している。
なお、審査時の不合格理由が特定の内容であった場合、例えば使用中の公開鍵証明書の有効期限までにまだ時間があった場合等に、管理装置３０のオペレータにその旨を通知し、オペレータが管理対象機器４０のユーザに問い合わせを行うことができるようにしてもよい。

以上の処理により、管理装置３０は、管理対象機器４０から公開鍵を受信し、審査の結果管理対象機器４０に対して公開鍵証明書を送信してよいと判断した場合に、受信した公開鍵を含む公開鍵証明書を送信することができる。
なお、自己生成公開鍵通知を他のコマンドと同列に考える場合、管理装置３０側では、自己生成公開鍵通知を受信する前のＳＳＬによる認証処理の時点では、公開鍵証明書の更新処理を行っていると認識していなくてよい。そして、管理対象機器４０から自己生成公開鍵通知（コマンド）を受信した時点で、そのコマンドに応じた処理としてステップＳ２３以下の処理を行うようにしてもよい。ただし、このようにした場合にでも、ＳＳＬによる認証処理を行う際に管理対象機器４０から受信した公開鍵証明書に含まれる情報を審査に用いるのであれば、認証処理の時点でその公開鍵証明書を記憶しておくようにする。

次に、図１８に、図１０に示した処理を実行する場合の管理対象機器４０側の処理のフローチャートを示す。この図に示す処理は、管理対象機器４０のＣＰＵが所要の制御プログラムを実行することにより行うものである。
そして、管理対象機器４０のＣＰＵは、管理装置３０との間の認証処理に使用する公開鍵証明書の有効期限が近づいたことを検知すると、図１８のフローチャートに示す処理を開始する。なお、上述したように、この処理の開始条件すなわち公開鍵証明書の更新処理を行う条件は、別の基準で定めるようにしてもよい。

そして、まずステップＳ４１で、更新用の一対の鍵ペアとして、更新用公開鍵と、その公開鍵と対応する更新用私有鍵を生成する。この生成の際には、図１２に示したように、鍵本体の他、必要な書誌情報も付すものとする。
その後、ステップＳ４２で管理装置３０に通信を要求し、ステップＳ４３で管理装置３０との間でＳＳＬによる認証処理を行う。このとき、少なくとも管理対象機器４０が管理装置に認証を受けるが、逆に管理対象機器４０も管理装置３０を認証するようにするとよく、この場合、例えば背景技術の項で図２１を用いて説明した認証処理を採用することができる。
そして、ステップＳ４３での認証処理が成功すると、ステップＳ４４で更新用公開鍵を記載した自己生成公開鍵通知を生成し、この通知により更新用公開鍵を管理装置３０に送信する。そして、管理装置３０からの応答を待ち、ステップＳ４５でこの応答を受信する。

図１１を用いて説明した通り、管理装置３０からの応答には、管理装置３０が更新用公開鍵にデジタル署名を付して発行した更新用公開鍵証明書及びその正当性を確認するためのルート鍵証明書か、またはエラー通知が記載されているはずである。そこで、次のステップＳ４６で、更新用公開鍵証明書を受信したか否か判断する。
ここで受信していればステップＳ４７に進み、受信した更新用公開鍵証明書の正当性を、共に受信したルート鍵証明書を用いて確認する。そして、これが確認できると、ステップＳ４８からＳ４９に進み、受信した更新用公開鍵証明書と、ステップＳ４１で生成した更新用私有鍵とを、管理装置３０との通信に使用するものとして設定して処理を終了する。

一方、ステップＳ４６で更新用公開鍵証明書を受信していない（エラー通知を受信した）場合、あるいはステップＳ４８で更新用公開鍵証明書の正当性が確認できなかった場合には、ステップＳ５０でエラー処理をして終了する。
なお、エラー処理の内容はエラー通知の内容や更新用公開鍵証明書の確認結果に応じて異なるものであり、例えば更新用公開鍵証明書の正当性を確認できなかった場合には、証明書が破損していたと判断して再度図１８のフローチャートの処理を繰り返したり、管理契約期間が延長されていなかった場合には延長の案内メッセージを表示部に表示させたりといった動作が考えられる。
また、図１６及び図１７に示した例のように応答に審査結果を記載するようにした場合には、ステップＳ４７でその審査結果がＯＫかＮＧかを判断するようにしてもよい。この場合、ＯＫがＹＥＳに、ＮＧがＮＯに該当する。

以上の処理により、更新が成功した場合には、管理対象機器４０自身が生成した公開鍵に管理装置３０がデジタル署名を付して作成した公開鍵証明書を、管理装置３０との間の認証に使用する公開鍵証明書として設定することができる。また、私有鍵についても、管理対象機器４０自身が生成した公開鍵と対応する私有鍵を、管理装置３０との間の認証に使用するものとして設定することができる。
この場合において、図９に示したような更新前の証明書メモリの内容は、公開鍵証明書及び私有鍵の部分が更新後のものに置き換えられる。

図１９に、この更新後の証明書メモリの内容を示す。この図において、更新前と更新後とで変化する部分に下線を付した。
この図からわかるように、更新前と更新後とで、公開鍵（デジタル署名も含む）や私有鍵の内容は当然異なるが、それ以外の部分で異なるのは、主として公開鍵証明書のシリアル番号と有効期限のみである。そして、署名アルゴリズムや署名者、公開鍵証明書の発行先の識別情報等は、更新前のものと変わらない。
従って、更新後の公開鍵証明書は、更新前のものを単に有効期限までの期間が長いものに更新したものであるということができる。

以上説明してきたような公開鍵証明書の更新処理においては、管理対象機器４０が使用する私有鍵は、管理対象機器４０自身が生成し、その後他の装置に送信されることがない。従って、転送中に盗み見られる危険性はない。従って、更新処理中に私有鍵が漏洩する可能性は極めて低く、高い安全性を確保することができる。また、更新後にあっても、他の装置に保管された私有鍵が流用されてしまうといった恐れもないため、高い安全性を確保することができる。

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

また、以上説明してきた方式以外にも、公開鍵証明書の更新には、例えば管理装置３０が要求に応じて更新用の公開鍵と私有鍵の鍵ペアを作成し、公開鍵にデジタル署名を付して公開鍵証明書とし、この公開鍵証明書と私有鍵とを管理対象機器４０に転送して設定させるという方式も考えられる。しかし、以上説明してきた方式は、記憶すべき装置以外が私有鍵に一切触れない状態で公開鍵証明書の更新を行うことができ、当然私有鍵がネットワーク上を流れることもないため、管理装置３０が鍵ペアを生成する方式よりも高い安全性が確保できると言える。

私有鍵は、本来これを使用する装置のみが保持しているべきものであるが、ＣＡや管理装置が私有鍵を配布するとすると、これを使用する装置だけでなく、ＣＡや管理装置にも私有鍵が保持され得ることになってしまう。ＣＡや管理装置と私有鍵を使用する装置とを同じ主体が管理するのであればこの点はあまり問題にならないが、ベンダーが機器のユーザに対して管理装置によって管理サービスを提供する場合等は、管理装置に機器の私有鍵を保持し得る状態をユーザが好まないことも考えられる。そこで、機器の私有鍵はその機器のみが保持している状態にしておきたいという要求もあった。
そして、以上説明してきた方式によれば、管理対象機器４０が認証に使用する私有鍵を、管理装置３０等の他の装置が保持できないようにしながら管理対象機器４０に対する公開鍵証明書の発行を可能とすることができるので、このような要求に応えることができる。

なお、以上説明してきた方式を採用する場合でも、生産工場で最初に管理対象機器４０に記憶させる証明書セットは、全て管理装置３０側で生成し、生産工場の通信端末に転送したものである。しかし、出荷時点から管理対象機器４０に自身で生成した私有鍵を使用させるようにするため、工場においても図１０乃至図１８を用いて説明したような処理により証明書を設定するようにしてもよい。このようにすれば、出荷当初から管理対象機器４０に安全性の高い私有鍵を使用させることができる。

この場合、管理対象機器４０側に公開鍵証明書が設定されていない段階で管理装置３０が管理対象機器４０を審査する方法が問題となるが、この点については、例えば、図８に示した処理のように作業員がバーコードリーダで読み取ったバーコードの内容を、通信端末１５０を介して管理装置３０に送信し、これをもとに審査するようにすることが考えられる。あるいは、図８を用いて説明したような処理により設定する証明書セットを仮の証明書セットとし、その設定後に、管理対象機器４０に自身で図１０乃至図１８を用いて説明したような処理により証明書を更新させるようにすることも考えられる。
また、工場以外の場所で、管理対象機器４０に仮の証明書セットを設定し、その設定後に、管理対象機器４０に自身で図１０乃至図１８を用いて説明したような処理により証明書を更新させて、認証処理に使用する正規の証明書セットを設定することができるようにしてもよい。このような手法は、メモリの破損等により使用していた証明書セットが消滅してしまった場合の復旧作業時等に有効である。

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

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

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

以上説明してきた通り、この発明の通信システムによれば、通信装置が認証に使用する証明書を自動的に更新することを可能としながら、私有鍵の漏洩の可能性を低下させ、安全な更新を実現させることができる。
従って、この発明を、各ノードが通信に際して証明書を用いた認証処理を行うような通信システムを運用する際に利用することにより、有効期限のある証明書を認証処理に使用する場合でも、なりすましの危険性を低減し、より安全なシステムを構成することができる。

この発明の実施形態である通信システムの構成例を示すブロック図である。 図１に示した管理装置のハードウェア構成を示すブロック図である。 図１に示した管理装置及び管理対象機器について、この発明の特徴に関連する部分の機能構成を示す機能ブロック図である。 図１及び図３に示した管理装置及び管理対象機器が認証処理に用いる証明書及び鍵について説明するための図である。 図４に示した公開鍵証明書のフォーマット例について説明するための図である。 図５に記載したフォーマットに従った管理対象機器用公開鍵証明書の例を示す図である。 図１に示した管理対象機器を生産する生産工場及び関連施設に設ける、証明書の設定に関連する設備の構成例を示すブロック図である。 図７に示した設備によって生産工場で管理対象機器に公開鍵証明書等を設定するための処理の流れを示すシーケンス図である。 図１に示した管理対象機器の証明書メモリに記憶させる、管理装置と通信を行うための情報の例を示す図である。 図１に示した通信システムにおいて、管理対象機器の公開鍵証明書を更新する場合の処理の流れを示すシーケンス図である。

図１０に示した処理を実行する場合の管理装置側の処理のフローチャートである。 図１１に示した処理において管理装置が受信する公開鍵のフォーマット例を示す図である。 管理対象機器が管理装置に送信する自己生成公開鍵通知をＳＯＡＰリクエストとして記載した例を示す図である。 図１１のステップＳ２３での審査処理の内容の一例を示すフローチャートである。 管理装置の証明書記憶部に作成する公開鍵証明書データベースの例を示す図である。 管理装置における審査が合格だった場合の、図１３に示したＳＯＡＰリクエストに対する応答のＳＯＡＰレスポンスの例を示す図である。 管理装置における審査が不合格だった場合の、図１３に示したＳＯＡＰリクエストに対する応答のＳＯＡＰレスポンスの例を示す図である。 図１０に示した処理を実行する場合の管理対象機器側の処理のフローチャートである。 図１０に示した処理による更新後に証明書メモリに記憶される情報の例を示す図である。 図１に示した通信システムにおいて管理対象機器を複数設けた例を示す図である。 ２つの通信装置がＳＳＬに従った相互認証を行う際に各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。 図２１に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。 ２つの通信装置がＳＳＬに従った片方向認証を行う際の各装置において実行する処理を示す、図２１と対応する図である。

符号の説明

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

Claims (7)

1. 通信装置と証明書送信装置とを備える通信システムであって、
   前記通信装置に、
   通信相手の装置に認証を受けるための証明書及び該証明書と対応する私有鍵を記憶する記憶手段と、
   前記記憶手段に記憶している証明書の更新時期を検出する更新時期検出手段と、
   前記更新時期検出手段が、前記記憶手段に記憶している証明書が更新時期になったことを検出したときに、対になる公開鍵及び私有鍵を生成する鍵生成手段と、
   前記記憶手段に記憶している証明書の有効期限が切れる前に、該証明書を前記証明書送信装置に送信し、該証明書を用いて前記証明書送信装置に認証されたときに、該証明書送信装置に前記鍵生成手段が生成した公開鍵を送信する公開鍵送信手段と、
   前記公開鍵送信手段による公開鍵の送信に応じて前記証明書送信装置から送信されてくる、該公開鍵を含む証明書と、前記鍵生成手段が生成した該公開鍵と対になる私有鍵とを、相手先装置に認証を受けるための新たな証明書及び該新たな証明書と対応する私有鍵として前記記憶手段に記憶させる証明書設定手段とを設け、
   前記証明書送信装置に、
   証明書を受信して該証明書を用いて該証明書の送信元を認証する認証手段と、
   前記認証手段が認証した送信元から公開鍵を受信する受信手段と、
   前記公開鍵の送信元を、該送信元について管理契約期間が前記認証手段の受信した証明書の有効期限後まであることを確認する工程を少なくとも含む工程により審査する審査手段と、
   前記審査手段による審査に合格した場合に、前記受信手段が受信した公開鍵を含む証明書を前記公開鍵の送信元に送信する送信手段とを設けた
   ことを特徴とする通信システム。
2. 請求項１記載の通信システムであって、
   前記証明書送信装置に、前記受信手段が受信した公開鍵に署名を付して証明書を作成する証明書作成手段を設けたことを特徴とする通信システム。
3. 請求項２記載の通信システムであって、
   前記証明書送信装置の証明書作成手段に、作成する証明書に、前記受信した証明書に記載されている、その証明書の送信元の識別情報を記載する手段を設けたことを特徴とする通信システム。
4. 請求項１乃至３のいずれか一項記載の通信システムであって、
   前記証明書送信装置の審査手段が、前記認証手段が受信した証明書を用いて、前記認証手段が受信した証明書の有効期限までの期間が所定の閾値以下であることを確認する工程を含む前記送信元の審査を行う手段であることを特徴とする通信システム。
5. 請求項４記載の通信システムであって、
   前記通信装置の前記公開鍵送信手段が前記証明書送信装置に認証を受けるために送信する証明書が、該通信装置の製造時に該通信装置に設定された証明書であることを特徴とする通信システム。
6. 請求項１乃至３のいずれか一項記載の通信システムであって、
   前記証明書送信装置の審査手段が、前記認証手段が受信した証明書に記載されている、その証明書の送信元の識別情報を用いて該送信元の審査を行う手段であることを特徴とする通信システム。
7. 請求項１乃至６のいずれか一項記載の通信システムであって、
   前記証明書送信装置の送信手段に、前記公開鍵証明書を送信する場合に、該公開鍵証明書と共に、該公開鍵証明書の正当性を確認するための証明鍵も送信する手段を設け、
   前記通信装置の前記証明書設定手段に、前記公開鍵送信手段による公開鍵の送信に応じて前記相手先装置から前記証明書に加えて該証明書の正当性を確認するための証明鍵も受信し、該証明鍵を用いて受信した証明書の正当性を確認した後で、受信した証明書を前記記憶手段に記憶させる手段を設けたことを特徴とする通信システム。

Images