通信装置、通信システム及び証明書設定方法
【課題】 セキュリティを維持しながら、認証に必要な証明書を記憶する部品を交換する必要が生じた場合でも、容易かつ速やかに正常な認証が行える状態に容易に回復させることができるようにする。
【解決手段】 通信I/Fを備え、その通信I/Fを介して通信可能な上位装置10によって管理される下位装置20において、通信を行う際に通信相手に認証を受けるために通常公開鍵証明書を提供し、その通常公開鍵証明書によって通信相手に認証された場合に通信を行うようにし、その通常公開鍵証明書とその通常公開鍵証明書よりも有効期間が長いレスキュー公開鍵証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品である部品Aに設ける。この構成により、正規の部品Aを装着した下位装置20には安全に通常証明書セットを記憶させることができる一方、偽部品A′を装着した下位装置には通常証明書セットを送信しないようにすることができる。
【解決手段】 通信I/Fを備え、その通信I/Fを介して通信可能な上位装置10によって管理される下位装置20において、通信を行う際に通信相手に認証を受けるために通常公開鍵証明書を提供し、その通常公開鍵証明書によって通信相手に認証された場合に通信を行うようにし、その通常公開鍵証明書とその通常公開鍵証明書よりも有効期間が長いレスキュー公開鍵証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品である部品Aに設ける。この構成により、正規の部品Aを装着した下位装置20には安全に通常証明書セットを記憶させることができる一方、偽部品A′を装着した下位装置には通常証明書セットを送信しないようにすることができる。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、通信手段を備え、該通信手段によって通信相手と通信可能な通信装置、このような通信装置である下位装置とその通信相手となる上位装置を備える通信システム、およびこのような通信装置に証明書を設定する証明書設定方法に関する。
【背景技術】
【0002】
従来から、それぞれ通信機能を備えた複数の通信装置をネットワークを介して通信可能に接続し、様々なシステムを構築することが行われている。その一例としては、クライアント装置として機能するPC等のコンピュータから商品の注文を送信し、これとインターネットを介して通信可能なサーバ装置においてその注文を受け付けるといった、いわゆる電子商取引システムが挙げられる。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。
【0003】
このようなシステムを構築する上では、通信を行う際に、通信相手が適切か、あるいは送信されてくる情報が改竄されていないかといった確認が重要である。また、特にインターネットによる通信を行う場合には、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばSSL(Secure Socket Layer)と呼ばれるプロトコルが開発されており、広く用いられている。このプロトコルを用いて通信を行うことにより、公開鍵暗号方式と共通鍵暗号方式とを組み合わせ、通信相手の認証を行うと共に、情報の暗号化により改竄及び盗聴の防止を図ることができる。また、通信相手の側でも、通信を要求してきた通信元の装置を認証することができる。
このようなSSLや公開鍵暗号を用いた認証に関連する技術としては、例えば特許文献1及び特許文献2に記載のものが挙げられる。
【0004】
ここで、このSSLに従った相互認証を行う場合の通信手順について、認証処理の部分に焦点を当てて説明する。図21は、通信装置Aと通信装置BとがSSLに従った相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図21に示すように、SSLに従った相互認証を行う際には、まず双方の通信装置にルート鍵証明書及び、私有鍵と公開鍵証明書を記憶させておく必要がある。この私有鍵は、認証局(CA:certificate authority)が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にCAがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、CAがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。
【0005】
図22にこれらの関係を示す。
図22(a)に示すように、公開鍵Aは、私有鍵Aを用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者(CA)や有効期限等の情報を含む書誌情報とによって構成される。そして、CAは、鍵本体や書誌情報が改竄されていないことを示すため、公開鍵Aをハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名としてクライアント公開鍵に付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Aの書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、公開鍵証明書Aである。
【0006】
この公開鍵証明書Aを認証処理に用いる場合には、ここに含まれるデジタル署名を、ルート私有鍵と対応する公開鍵であるルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば、デジタル署名が確かにCAによって付されたことがわかる。また、公開鍵Aの部分をハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とが一致すれば、鍵自体も損傷や改竄を受けていないことがわかる。さらに、受信したデータをこの公開鍵Aを用いて正常に復号化できれば、そのデータは、私有鍵Aの持ち主から送信されたものであることがわかる。
【0007】
ここで、認証を行うためには、ルート鍵を予め記憶しておく必要があるが、このルート鍵も、図22(b)に示すように、CAがデジタル署名を付したルート鍵証明書として記憶しておく。このルート鍵証明書は、自身に含まれる公開鍵でデジタル署名を復号化可能な、自己署名形式である。そして、ルート鍵を使用する際に、そのルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し、ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば、ルート鍵が破損等していないことを確認できるのである。
【0008】
図21のフローチャートの説明に入る。なお、この図において、2本のフローチャート間の矢印は、データの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また、各ステップの処理が正常に完了しなかった場合には、その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合、処理がタイムアウトした場合等も同様である。
【0009】
ここでは、通信装置Aが通信装置Bに通信を要求するものとするが、この要求を行う場合、通信装置AのCPUは、所要の制御プログラムを実行することにより、図21の左側に示すフローチャートの処理を開始する。そして、ステップS11で通信装置Bに対して接続要求を送信する。
一方通信装置BのCPUは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図21の右側に示すフローチャートの処理を開始する。そして、ステップS21で第1の乱数を生成し、これを私有鍵Bを用いて暗号化する。そして、ステップS22でその暗号化した第1の乱数と公開鍵証明書Bとを通信装置Aに送信する。
【0010】
通信装置A側では、これを受信すると、ステップS12でルート鍵証明書を用いて公開鍵証明書Bの正当性を確認する。
そして確認ができると、ステップS13で、受信した公開鍵証明書Bに含まれる公開鍵Bを用いて第1の乱数を復号化する。ここで復号化が成功すれば、第1の乱数は確かに公開鍵証明書Bの発行対象から受信したものだと確認できる。
その後、ステップS14でこれとは別に第2の乱数及び共通鍵の種を生成する。共通鍵の種は、例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして、ステップS15で第2の乱数を私有鍵Aを用いて暗号化し、共通鍵の種を公開鍵Bを用いて暗号化し、ステップS16でこれらを公開鍵証明書Aと共にサーバ装置に送信する。共通鍵の種の暗号化は、通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。
また、次のステップS17では、ステップS14で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
【0011】
通信装置B側では、通信装置AがステップS16で送信してくるデータを受信すると、ステップS23でルート鍵証明書を用いて公開鍵証明書Aの正当性を確認する。そして確認ができると、ステップS24で、受信した公開鍵証明書Aに含まれる公開鍵Aを用いて第2の乱数を復号化する。ここで復号化が成功すれば、第2の乱数は確かに公開鍵証明書Aの発行対象から受信したものだと確認できる。
その後、ステップS25で私有鍵Bを用いて共通鍵の種を復号化する。ここまでの処理で、通信装置A側と通信装置B側に共通鍵の種が共有されたことになる。そして、この共通鍵の種は、生成した通信装置Aと、私有鍵Bを持つ通信装置B以外の装置が知ることはない。ここまでの処理が成功すると、通信装置B側でもステップS26で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
【0012】
そして、通信装置A側のステップS17と通信装置B側のステップS26の処理が終了すると、相互に認証の成功と以後の通信に使用する暗号化方式とを確認し、生成した共通鍵を用いてその暗号化方式で以後の通信を行うものとして認証に関する処理を終了する。なお、この確認には、通信装置Bからの認証が成功した旨の応答も含むものとする。以上の処理によって互いに通信を確立し、以後はステップS17又はS26で生成した共通鍵を用い、共通鍵暗号方式でデータを暗号化して通信を行うことができる。
【0013】
このような処理を行うことにより、通信装置Aと通信装置Bが安全に共通鍵を共有することができ、通信を安全に行う経路を確立することができる。
ただし、上述した処理において、第2の乱数を公開鍵Aで暗号化し、公開鍵証明書Aを通信装置Bに送信することは必須ではない。この場合、通信装置B側のステップS23及びS24の処理は不要になり、処理は図23に示すようになる。このようにすると、通信装置Bが通信装置Aを認証することはできないが、通信装置Aが通信装置Bを認証するだけでよい場合にはこの処理で十分である。そしてこの場合には、通信装置Aに記憶させるのはルート鍵証明書のみでよく、私有鍵A及び公開鍵証明書Aは不要である。また、通信装置Bにはルート鍵証明書を記憶させる必要はない。
【0014】
一方、このような公開鍵証明書を発行する第3者機関として、私有鍵の保有者の確認を行い、その私有鍵に対応した公開鍵に対してデジタル署名を行い、公開鍵証明書を発行する商用サービスが、例えばベリサイン社やボルチモア社によって提供されている。そして、公開鍵発行のためのシステムが私有鍵を含めて厳重に管理されている信頼性の高い第3者機関が発行する公開鍵証明書は、広く認証に利用されている。また、デジタル証明書を用いた認証を行う場合、信頼性の高い第3者機関が発行した公開鍵証明書を使用したいという要求もある。
【0015】
さらに、このような第3者機関の発行する公開鍵証明書を利用する場合、主要な第3者機関によるデジタル署名の内容を確認するためのルート鍵は、インターネットエクスプローラ(登録商標)やネットスケープ(登録商標)のような一般的なウェブブラウザには予め埋め込まれているため、ウェブブラウザの操作者は、新たにルート鍵を入手して設定する必要がないという利点がある。
また、予めルート鍵を設定されていない装置であっても、信頼性の高い第3者機関のものであればユーザがルート鍵の設定に同意しやすいし、ルート鍵を入手して設定すれば、同じ第3者機関が発行した公開鍵証明書を持つ装置は、装置自体のベンダーに関わらず認証することができるという利点もある。従って、自社製の装置を他社製の装置に接続したい場合等には、第3者機関の発行する公開鍵証明書を利用することが効果的である。また、装置のユーザ側からも、このような公開鍵証明書を利用したいという要望がある。
【発明の概要】
【発明が解決しようとする課題】
【0016】
ところで、このような第3者機関は、安全性を高めるため、発行する公開鍵証明書に有効期間を設定している。また、この期間は通常数年単位であり、1〜3年程度と短い場合が多い。そして、上記の認証処理において、この有効期間が過ぎた公開鍵証明書は、正当な公開鍵証明書とは認めないようにしている。従って、この有効期間が過ぎる前に新しいものに更新する必要がある。
しかし、デジタル証明書を記憶する部品が破損し、これを交換してしまったような場合には、デジタル証明書も部品と共に取り去られてしまう。このため、装置の認証が不可能になってしまうことになり、ネットワークを介した安全な通信経路を確保できなくなってしまうので、自動的な更新は行えなくなってしまう。
【0017】
交換後の部品にデジタル証明書が記憶されていれば問題ないが、上記のような有効期間の短い証明書を記憶させておく場合、販売店、生産・物流拠点、サービス拠点等にストックしておくうちに証明書の有効期限が切れてしまうことも考えられる。従って、有効期限が切れたものについては回収して再度新しい証明書を記憶させる必要がある等、効率の悪い生産体制を強いられることになるという問題がある。また、装置本体の生産打ち切り後に部品を確保しておく場合等、あまり数が必要でない場合にも定期的に部品を生産しつづけなければならないため、この点でも効率が悪い。さらに、このような体制を取る場合、部品の生産打ち切り後には、有効に機能する部品がすぐに市場からなくなってしまうという問題もある。
【0018】
部品を交換してから別途公開鍵証明書や私有鍵を記憶させることも考えられるが、これらを持たない状態では、部品を交換した装置に対する安全な通信経路を確保することができない。そこで、新たな公開鍵証明書等を安全に配布するためには、これを記録媒体に記録して、装置の設置先に郵送したり、部品交換のサービスマンが持参したりする必要がある。しかし、このような体制を取る場合、装置の成りすまし等を防止するため、デジタル証明書については、悪意のユーザによる交換、読み出し、登録を防止する必要があり、一般のユーザによるデジタル証明書の更新を禁止する必要があるので、手動でデジタル証明書を設定するようにする場合の権限の確認が困難であるという問題がある。
【0019】
この発明は、このような問題を解決し、通信手段によって通信相手と通信可能な通信装置あるいはこのような通信装置を備える通信システムにおいて、セキュリティを維持しながら、認証に必要な証明書を記憶する部品を交換する必要が生じた場合でも、容易かつ速やかに正常な認証が行える状態に回復させることができるようにすることを目的とする。
【課題を解決するための手段】
【0020】
上記の目的を達成するため、この発明の通信装置は、通信手段を備え、その通信手段によって通信相手と通信可能な通信装置において、異なる有効期間が設定されている2種類のデジタル証明書であってより有効期間が短い短期証明書とより有効期間が長い長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、上記通信手段を、通信を行う際に上記通信相手に認証を受けるために上記短期証明書を提供する手段を備え、その短期証明書によって上記通信相手に認証された場合に通信を行う手段としたものである。
【0021】
また、通信手段を備え、その通信手段によって通信相手と通信可能な通信装置において、その通信装置の製品寿命よりも有効期間が短いデジタル証明書である短期証明書とその通信装置の製品寿命よりも有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、上記通信手段を、通信を行う際に上記通信相手に認証を受けるために上記短期証明書を提供する手段を備え、その短期証明書によって上記通信相手に認証された場合に通信を行う手段としたものである。
【0022】
また、通信手段を備え、その通信手段によって通信相手と通信可能な通信装置において、その通信装置の動作中に有効期限が切れるデジタル証明書である短期証明書とその通信装置の動作中は有効期限が切れないデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、上記通信手段を、通信を行う際に上記通信相手に認証を受けるために上記短期証明書を提供する手段を備え、その短期証明書によって上記通信相手に認証された場合に通信を行う手段としたものである。
【0023】
また、通信手段を備え、その通信手段によって通信相手と通信可能な通信装置において、有効期限があるデジタル証明書である短期証明書と有効期限が事実上ないデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、上記通信手段を、通信を行う際に上記通信相手に認証を受けるために上記短期証明書を提供する手段を備え、その短期証明書によって上記通信相手に認証された場合に通信を行う手段としたものである。
これらの各通信装置において、上記通信手段に、通信を行う際に通信相手に認証を受けるために上記長期証明書を提供する手段も設け、上記長期証明書によって通信相手に認証された場合に上記通信手段を介してその通信相手から上記短期証明書を取得して上記記憶領域に記憶させる証明書設定手段を設けるとよい。
さらに、上記交換部品を、上記通信装置に装着される前には、上記長期証明書を記憶し、上記短期証明書を記憶していない部品とするとよい。
さらに、上記認証を、SSL又はTLSのプロトコルに従った認証処理によって行うものとし、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
【0024】
また、この発明の通信システムは、上位装置と、その上位装置の通信相手となる下位装置とを備えた通信システムにおいて、上記下位装置において、異なる有効期間が設定されている2種類のデジタル証明書であってより有効期間が短い短期証明書とより有効期間が長い長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、上記通信手段を、通信を行う際に上記通信相手に認証を受けるために上記短期証明書を提供する手段を備え、その短期証明書によって上記通信相手に認証された場合に通信を行う手段としたものである。
【0025】
また、上位装置と、その上位装置の通信相手となる下位装置とを備えた通信システムにおいて、上記下位装置において、上記下位装置の製品寿命よりも有効期間が短いデジタル証明書である短期証明書と上記下位装置の製品寿命よりも有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、上記通信手段を、通信を行う際に上記通信相手に認証を受けるために上記短期証明書を提供する手段を備え、その短期証明書によって上記通信相手に認証された場合に通信を行う手段としたものである。
【0026】
これらの通信システムにおいて、上記下位装置の通信手段に、通信を行う際に通信相手に認証を受けるために上記長期証明書を提供する手段も設け、上記下位装置に、上記長期証明書によって通信相手に認証された場合に上記通信手段を介してその通信相手から上記短期証明書を取得して上記記憶領域に記憶させる証明書設定手段を設けるとよい。
さらに、上記交換部品を、上記下位装置に装着される前には、上記長期証明書を記憶し、上記短期証明書を記憶していない部品とするとよい。
さらに、上記認証を、SSL又はTLSのプロトコルに従った認証処理によって行うものとし、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
【0027】
また、この発明の証明書設定方法は、通信手段を備え、その通信手段によって通信相手と通信可能な通信装置に、デジタル証明書である短期証明書を設定する証明書設定方法において、上記短期証明書と、その短期証明書よりも設定されている有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を備えた交換可能な最小単位の交換部品を、上記長期証明書を記憶させ、上記短期証明書を記憶させない状態で上記通信装置に装着し、上記通信装置に、通信を行う際に通信相手に認証を受けるために上記長期証明書を提供させ、その長期証明書によって上記通信相手に認証された場合に上記通信手段を介してその通信相手から上記短期証明書を取得させて上記記憶領域に記憶させるようにしたものである。
【0028】
また、通信手段を備え、その通信手段によって通信相手と通信可能な通信装置に、上記通信装置の製品寿命よりも有効期間が短いデジタル証明書である短期証明書を設定する証明書設定方法において、上記短期証明書と、上記通信装置の製品寿命よりも有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を備えた交換可能な最小単位の交換部品を、上記長期証明書を記憶させ、上記短期証明書を記憶させない状態で上記通信装置に装着し、上記通信装置に、通信を行う際に通信相手に認証を受けるために上記長期証明書を提供させ、その長期証明書によって上記通信相手に認証された場合に上記通信手段を介してその通信相手から上記短期証明書を取得させて上記記憶領域に記憶させるようにしたものである。
このような証明書設定方法において、上記認証を、SSL又はTLSのプロトコルに従った認証処理によって行うものとし、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
【発明の効果】
【0029】
以上のようなこの発明の通信装置、通信システムあるいは証明書更新方法によれば、通信手段によって通信相手と通信可能な通信装置あるいはこのような通信装置を備える通信システムにおいて、セキュリティを維持しながら、認証に必要な証明書を記憶する部品を交換する必要が生じた場合でも、容易かつ速やかに正常な認証が行える状態に容易に回復させることができる。
【図面の簡単な説明】
【0030】
【図1】この発明の通信システムの実施形態の構成を示すブロック図である。
【図2】図1に示した上位装置及び下位装置のハードウェア構成を示すブロック図である。
【図3】同じく上位装置及び下位装置の遠隔管理及び証明書の設定に関わる部分の機能構成を示す機能ブロック図である。
【図4】図3に示した要求管理部における動作の実行可否の判断基準を示す図である。
【図5】図1に示した通信システムにおける上位装置と下位装置との間の通信方式の概要を示す説明図である。
【図6】図1に示した上位装置及び下位装置が記憶する認証情報について説明するための図である。
【図7】通常公開鍵証明書のフォーマット例について説明するための図である。
【図8】図7に記載したフォーマットに従って作成した一般的な公開鍵証明書の例を示す図である。
【図9】同じく、レスキュー公開鍵証明書と対比するための、通常公開鍵証明書の例を示す図である。
【図10】同じく、通常公開鍵証明書と対比するための、レスキュー公開鍵証明書の例を示す図である。
【図11】図1に示した上位装置及び下位装置が通常公開鍵証明書とレスキュー公開鍵証明書とを使い分けるための構成について説明するための図である。
【図12】図1等に示した実施形態の比較例における、証明書の記憶領域を設ける交換部品の構成及びその問題点について説明するための図である。
【図13】図1に示した下位装置における、証明書の記憶領域を設ける交換部品の構成及びその効果について説明するための図である。
【図14】図13に示した部品A及びその部品Aを装着した下位装置の製造工程の概略を示す図である。
【図15】その部品Aに各証明書セットを記憶させる工程について説明するための図である。
【図16】図15に示した工程において下位装置に通常証明書セットを書き込む際に下位装置側で実行する処理を示すフローチャートである。
【図17】図14及び図15に示した製品組み立て工程において通常証明書セットを下位装置に設定するために使用する設備の概略を示す図である。
【図18】生産工場における、図17に示した通信端末および証明書書き込み装置の周辺の状況の概略を示す図である。
【図19】機能検査に合格した装置に識別番号を付与する際に貼付する定格銘板の例を示す図である。
【図20】図1に示した通信システムについて、下位装置を複数設けた場合の構成について説明するための図である。
【図21】2つの通信装置がSSLに従った相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
【図22】図21に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。
【図23】2つの通信装置がSSLに従った片方向認証を行う際の各装置において実行する処理を示す、図21と対応する図である。
【発明を実施するための形態】
【0031】
以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明による通信装置と、その通信装置を用いて構成したこの発明の通信システムの実施形態の構成について説明する。
図1はその通信システムの構成を示すブロック図である。
この通信システムは、図1に示すように、それぞれ通信手段を備える上位装置10及び下位装置20をネットワーク30によって接続して構成している。そして、下位装置20がこの発明の通信装置の実施形態である。また、上位装置10も通信機能を備えた通信装置であり、下位装置20の通信相手となる。
ネットワーク30としては、有線,無線を問わず、ネットワークを構築可能な各種通信回線(通信経路)を採用することができる。また、ここでは下位装置20を1つしか示していないが、図20に示すように通信システム内に下位装置20を複数設けることも可能である。
【0032】
このような通信システムについて、まず上位装置10及び下位装置20のハードウェア構成から説明する。上位装置10及び下位装置20のハードウェア構成は、単純化して示すと、図2に示すようなものである。
この図に示す通り、上位装置10は、CPU11,ROM12,RAM13,HDD14,通信インタフェース(I/F)15を備え、これらがシステムバス16によって接続されている。そして、CPU11がROM12やHDD14に記憶している各種制御プログラムを実行することによってこの上位装置10の動作を制御し、通信相手の認証や下位装置20のデジタル証明書更新等の機能を実現している。なお、この明細書において、デジタル証明書とは、偽造されないようにするための署名が付されたデジタルデータを指すものとする。
【0033】
下位装置20も、上位装置10の場合と同様にCPU21,ROM22,RAM23,HDD24,通信インタフェース(I/F)25を備え、これらがシステムバス26によって接続されている。CPU21が、ROM22やHDD24に記憶している各種制御プログラムを必要に応じて実行し、装置の制御を行うことにより、通信手段、証明書設定手段等の種々の手段としての機能を実現できるようにしている。
なお、この通信システムにおいて、上位装置10及び下位装置20が、遠隔管理,電子商取引等の目的に応じて種々の構成をとることができることは、もちろんである。そして、上位装置10や下位装置20のハードウェアとしては、適宜公知のコンピュータを採用することもできる。もちろん、必要に応じて他のハードウェアを付加してもよいし、上位装置10と下位装置20が同一の構成である必要もない。
【0034】
次に、この通信システムのうちこの実施形態の特徴に関連する部分として、上位装置10及び下位装置20の証明書の設定に関連する部分の機能構成を図3に示す。上位装置10に係るこれらの機能は、上位装置10のCPU11がROM12やHDD14に記憶している所要の制御プログラムを実行することにより実現されるものであり、下位装置20に係るこれらの機能は、下位装置20のCPU21がROM22やHDD24等に記憶している所要の制御プログラムを実行することにより実現されるものである。
【0035】
図3に示すように、上位装置10には、HTTPS(Hypertext Transfer Protocol Security)クライアント機能部31,HTTPSサーバ機能部32,認証処理部33,証明書更新要求部34,証明書記憶部35を備えている。
HTTPSクライアント機能部31は、SSLに従った認証や暗号化の処理を含むHTTPSプロトコルを用いて下位装置20等のHTTPSサーバの機能を有する装置に対して通信を要求すると共に、通信相手に対して要求(コマンド)やデータを送信してそれに応じた動作を実行させる機能を有する。
【0036】
一方、HTTPSサーバ機能部32は、HTTPSクライアントの機能を有する装置からのHTTPSプロトコルを用いた通信要求を受け付け、その装置から要求やデータを受信してそれに応じた動作を装置の各部に実行させ、その結果を応答として要求元に返す機能を有する。
認証処理部33は、HTTPSクライアント機能部31やHTTPSサーバ機能部32が通信相手を認証する際に、通信相手から受信したデジタル証明書や、証明書記憶部35に記憶している各種証明書、私有鍵等を用いて認証処理を行う認証手段の機能を有する。また、通信相手に認証を要求するために証明書記憶部35に記憶しているデジタル証明書をHTTPSクライアント機能部31やHTTPSサーバ機能部32を介して通信相手に送信する機能も有する。
【0037】
証明書更新要求部34は、後述するように所定の場合に下位装置20等の通信相手に対して通常公開鍵証明書を送信してこれを記憶するよう要求する機能を有する。なお、ここで送信する証明書は、この通信システムの外部の証明書管理装置(CA)50に必要な情報を送信して発行させる。
証明書記憶部35は、各種の証明書や私有鍵等の認証情報を記憶し、認証処理部33における認証処理に供する機能を有する。これらの各種証明書や私有鍵の種類及びその用途や作成方法については後に詳述する。
【0038】
一方、下位装置20には、HTTPSクライアント機能部41,HTTPSサーバ機能部42,認証処理部43,要求管理部44,証明書記憶部45,状態通知部46,ログ通知部47,証明書設定部48,コマンド受信部49を備えている。
HTTPSクライアント機能部41は、上位装置10のHTTPSクライアント機能部31と同様に、HTTPSプロトコルを用いて上位装置10等のHTTPSサーバの機能を有する装置に対して通信を要求すると共に、送信する要求やデータ等に応じた動作を実行させる機能を有する。
【0039】
HTTPSサーバ機能部42も、上位装置10のHTTPSサーバ機能部32と同様であり、HTTPSクライアントの機能を有する装置からの通信要求を受け付け、受信した要求やデータに応じた動作を装置の各部に実行させ、要求元に応答を返す機能を有する。
認証処理部43の機能も、上位装置10の認証処理部33と同様であるが、認証処理に使用する証明書等は、証明書記憶部45に記憶しているものである。
要求管理部44は、上位装置から受信した要求について、その要求に基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、その要求に基づいた動作を実行する機能部46〜49に対して動作要求を伝える機能も有する。
【0040】
図4にこの実行可否の判断基準を示すが、その判断基準は、要求の種類及び認証処理部43において認証処理に使用したデジタル証明書の種類である。上位装置10及び下位装置20が記憶しているデジタル証明書には、詳細は後述するが、短期証明書であり長期証明書よりも短い有効期間が設定されている公開鍵証明書である通常公開鍵証明書と、長期証明書であり短期証明書よりも長い有効期間が設定されている公開鍵証明書であるレスキュー公開鍵証明書があり、要求管理部44は、図3に示すように、通常公開鍵証明書による認証処理を行った場合には全ての動作を許可するが、レスキュー公開鍵証明書による認証処理を行った場合には証明書の設定動作のみを許可するようにしている。従って、レスキュー公開鍵証明書は、下位装置20に新たな通常公開鍵証明書を記憶させる場合のみに使用する証明書ということになる。
【0041】
証明書記憶部45は、上位装置の証明書記憶部35と同様に各種の証明書や私有鍵等の認証情報を記憶し、認証処理部33における認証処理に供する証明書記憶手段の機能を有する。ただし、記憶している証明書等は、後述するように認証管理部33とは異なる。
状態通知部46は、異常を検知したりユーザによる指示があったりした場合に上位装置10に対して下位装置20の状態を通知するコールを行う機能を有する。この通知は、上位装置10からの問い合わせに対する応答として送信してもよいし、HTTPSクライアント機能部41から上位装置10に通信を要求して送信してもよい。
【0042】
ログ通知部47は、下位装置20から上位装置10へのログの通知を行う機能を有する。その通知の内容としては、下位装置40の動作ログの他、例えば画像形成装置であれば画像形成枚数カウンタのカウント値、計量システムであればその計量値等が考えられる。この通知は緊急を要さないので、上位装置10からの問い合わせに対する応答として送信するとよい。
証明書設定部48は、上位装置10から受信する後述する通常公開鍵証明書等によって証明書記憶部45に記憶している証明書等を設定及び更新する証明書設定手段の機能を有する。
コマンド受信部49は、上述した各機能部46〜48以外の機能に係る要求に対応する動作を実行する機能を有する。この動作としては、例えば下位装置20が記憶しているデータの送信や、必要に応じてエンジン部の動作を制御することが挙げられる。なお、状態通知部46やログ通知部47は、コマンド受信部49が提供する機能の具体例として示したものであり、これらのような機能を設けることは必須ではない。
【0043】
次に、この通信システムにおける上位装置10と下位装置20との間の通信方式について説明する。図5はその通信方式の概要を示す説明図である。
この通信システムにおいて、上位装置10は、下位装置20と通信を行おうとする場合、まず下位装置20に対して通信を要求する。そして、従来の技術の項で図21又は図23を用いて説明したようなSSLプロトコルに従った認証処理によって下位装置20を正当な通信相手として認証した場合に、下位装置20との間で通信を確立させるようにしている。この認証処理は、SSLハンドシェイクと呼ばれる。ただし、図21に示したような相互認証は必須ではなく、図23に示したような片方向認証でもよい。
この処理において、下位装置20は自身の公開鍵証明書を上位装置10に送信して、認証を受ける。そして、相互認証を行う場合には上位装置10も下位装置20に自身の公開鍵証明書を送信して認証を受けるが、片方向認証の場合にはこちらの認証は行わない。
【0044】
以上の認証が成功すると、上位装置10は、下位装置20が実装するアプリケーションプログラムのメソッドに対する処理の依頼である要求を、構造化言語形式であるXML形式で記載したSOAPメッセージ60として生成し、HTTP(Hyper Text Transfer Protocol)に従ってHTTPリクエストとして下位装置20に送信する。このような要求は、RPC(Remote Procedure Call)と呼ばれる。
そして、下位装置20はこの要求の内容に応じた処理を実行し、その結果を応答のSOAPメッセージ70として生成し、HTTPレスポンスとして上位装置10に送信する。ここで、これらの要求と応答は、SSLハンドシェイクの処理において共有された共通鍵を用いて暗号化して送信し、通信の安全性を確保している。
【0045】
また、これらの要求と応答とによって、この通信システムは、上位装置10をクライアント、下位装置20をサーバとするクライアント・サーバシステムとして機能している。なお、逆に下位装置20から上位装置10に通信を要求し、下位装置20をクライアント、上位装置10をサーバとするクライアント・サーバシステムとして機能する場合もある。
また、RPCを実現するためには、上記の技術の他、FTP(File Transfer Protocol),COM(Component Object Model),CORBA(Common Object Request Broker Architecture)等の既知のプロトコル(通信規格),技術,仕様などを利用することができる。
【0046】
次に、上述した上位装置10及び下位装置20が上述した認証処理に用いる認証情報である各証明書や鍵の特性及び用途について説明する。図6は、(a)に下位装置20が認証情報として記憶している証明書及び鍵の種類を示し、(b)に上位装置10が認証情報として記憶している証明書及び鍵の種類を示す図である。
図1に示した上位装置10及び下位装置20は、図6に示すように、大きく分けて通常認証情報とレスキュー認証情報とを記憶している。そして、これらの認証情報は、それぞれ自分に関する認証情報である公開鍵証明書及び私有鍵と、通信相手に関する認証情報であるルート鍵証明書とによって構成される。
【0047】
また、例えば下位装置用通常公開鍵証明書は、証明書管理装置50が下位装置20に対して発行した通常公開鍵に、下位装置認証用通常ルート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書であり、短期証明書に該当する。
ここで、公開鍵証明書のフォーマットは、例えば図7に示したものを用いることができ、公開鍵そのものの他、証明書の発行者や証明書の有効期限、証明される対象(証明書の発行先の装置あるいは利用者)等の情報が記載されている。具体的には、例えばX.509と呼ばれるフォーマットに従って作成することができ、このフォーマットに従って作成された公開鍵証明書は、例えば図8に示すようなものになる。
この例においては、AがCAの識別情報を示し、Cが証明書の発行先の装置の識別情報を示す。これらは、それぞれ所在地、名称、機番あるいはコード等の情報を含む。また、Bが有効期間を示し、その開始日時と終了日時によって有効期間を指定している。
【0048】
なお、装置を特定する目的のみであれば、公開鍵証明書に付す識別情報に機番情報を含めることは必須ではないのであるが、ここで識別情報に機番情報と同一の情報を含めるようにしているのは、通信システムを運営する場合の要求に応えるためである。すなわち、この通信システムを装置の管理に使用する場合、装置の特定は機番情報によって行うことが多いが、識別情報が機番情報を含んでいない場合には、上位装置10側で識別情報と機番情報との対応関係をテーブル等として別途管理しておく必要が生じるのである。そして、このような管理を行う場合、下位装置20を新たに生産する度にデータを追加する必要があるし、下位装置20の数は数万台、数十万台あるいはそれ以上になる場合もあり、非常に大きな量のデータを管理する必要が生じるので、管理の負担が大きくなってしまう。
しかし、公開鍵証明書に付す識別情報に機番情報と同一の情報を含めておけば、認証処理において通信相手の機番を直接特定できる。従って、このようにすることにより、公開鍵証明書に付す識別情報と機番情報との対応関係を管理する必要がなくなり、管理負担を低減できるのである。
もちろん、このような機番情報を証明書に記載しなくてもよいし、逆に、この他に下位装置20の機種番号や登録ユーザ等の情報も記載するようにしてもよい。
【0049】
また、下位装置用通常私有鍵は、上記の通常公開鍵と対応する私有鍵、下位装置認証用通常ルート鍵証明書は、下位装置認証用通常ルート鍵に自身と対応するルート私有鍵を用いて自身で正当性を確認可能なデジタル署名を付したデジタル証明書である。
そして、下位装置20を複数設けた場合でも、各装置の通常公開鍵に付すデジタル署名は同じルート私有鍵を用いて付し、正当性確認に必要な通常ルート鍵証明書は共通にする。しかし、通常公開鍵証明書に含まれる通常公開鍵やこれと対応する私有鍵は、装置毎に異なる。
上位装置用通常公開鍵証明書と上位装置用通常私有鍵と上位装置認証用通常ルート鍵証明書も同様な関係である。
【0050】
そして、例えば上位装置10と下位装置20とが通常認証情報を用いて相互認証を行う場合には、上位装置10からの通信要求に応じて、下位装置20は下位装置用通常私有鍵を用いて暗号化した第1の乱数を下位装置用通常公開鍵証明書と共に上位装置10に送信する。上位装置10側では下位装置認証用通常ルート鍵証明書を用いてまずこの下位装置用通常公開鍵証明書の正当性(損傷や改竄を受けていないこと)を確認し、これが確認できた場合にここに含まれる公開鍵で第1の乱数を復号化する。この復号化が成功した場合に、上位装置10は通信相手の下位装置20が確かに下位装置用通常公開鍵証明書の発行先であると認識でき、その証明書に含まれる識別情報から装置を特定することができる。そして、特定した装置が通信相手としてふさわしいか否かに応じて認証の成功と失敗を決定することができる。
また、下位装置20側でも、上位装置10側で認証が成功した場合に送信されてくる上位装置用通常公開鍵証明書及び、上位装置用通常私有鍵で暗号化された乱数を受信し、記憶している上位装置認証用ルート鍵証明書を用いて同様な認証を行うことができる。
【0051】
ところで、これらの公開鍵証明書や私有鍵は、ROM22あるいはRAM23を構成するフラッシュメモリのような書き換え可能な不揮発性記憶手段に記憶させておくものである。従って、発明の開示の項で述べたように、このような記憶手段を含む部品を交換する場合には、記憶している公開鍵証明書や私有鍵は、取り外した旧部品と共に取り去られてしまう。そしてこのような場合、再度通常公開鍵証明書を用いた認証(通常証明書セットを用いた認証)を可能にするためには、取り去られた証明書や鍵を再度記憶させる必要がある。
【0052】
ここで、各装置が通常公開鍵証明書を用いた認証しか行えないとすると、この認証が行えなくなっている状態では、新たな通常公開鍵証明書等をネットワーク30を介して安全に対象の装置に送信する方法はないことになる。しかし、この実施形態の通信システムを構成する各装置は、このような事態に対処するためにレスキュー認証情報を記憶しており、通信相手を異なる2種類のデジタル証明書を用いて認証することができるようにしている。そして、レスキュー認証情報を用いることにより、必要な装置にネットワーク30を介して新たな通常公開鍵証明書等を安全に送受信できるようにしている。
【0053】
このレスキュー認証情報は、通常認証情報と概ね同様な構成となっている。例えば下位装置用レスキュー公開鍵証明書は、長期証明書であり、CAが下位装置に対して発行したレスキュー公開鍵に、上位装置認証用レスキュールート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書であり、上位装置用レスキュー私有鍵はそのレスキュー公開鍵と対応する私有鍵、下位装置認証用レスキュールート鍵証明書は、下位装置認証用レスキュールート鍵に自身を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。そして、これらのレスキュー公開鍵証明書とレスキュー私有鍵とレスキュールート鍵証明書とを合わせて、レスキュー証明書セットと呼ぶことにする。上位装置10側に記憶させるレスキュー認証情報についても同様とする。
【0054】
しかし、正規認証情報と大きく異なる点は、レスキュー公開鍵証明書の有効期間が、通常公開鍵証明書の有効期間よりも長く設定されている点である。
ここで、図9に通常公開鍵証明書の例を、図10にレスキュー公開鍵証明書の例を示す。
これらは、符号F及びIで示すように、発行先の装置の識別情報が同一であり、同じ装置に対して発行された公開鍵証明書である。しかし、通常公開鍵証明書の有効期間は、符号Eで示すように、2003年1月1日午前0時から2004年1月1日午前0時までの1年間としている一方、レスキュー公開鍵証明書の有効期間は、符号Hで示すように、2000年1月1日午前0時から2050年1月1日午前0時までの50年間としている。
また、証明書の発行者は、同じxxx社のCAであるが、通常公開鍵証明書については符号Gで示すように「RegularCA」、レスキュー公開鍵証明書については符号Dで示すように「RescueCA」というように、異なるCAとしている。
【0055】
このような有効期間の長いレスキュー公開鍵証明書は、有効期間の短い通常公開鍵証明書と比べた場合には安全性が若干劣る。しかしながら、このようなレスキュー公開鍵証明書は、有効期限が長い分、有効期限切れにより使用不能になってしまう事態も生じにくい。従って、証明書の記憶領域を備える部品の製造時に、予めレスキュー認証情報を記憶させておくようにすれば、レスキュー公開鍵証明書の有効期間内は、通信相手を認証することができる。そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができる。従って、この通信経路を利用して、通信相手に新しい通常公開鍵証明書を通信相手との間で送受信し、設定することが可能となる。従って、部品を長期間ストックしておき、交換が必要になった場合に速やかにこれに対応することができる。
【0056】
なお、レスキュー認証情報を用いて認証処理を行った場合に、通常公開鍵証明書を始めとする正規認証情報の更新のような限られた要求のみ実行を許可するようにすれば、有効期間を長くしたために若干安全性が低下したとしても、大きな問題にはならない。
また、この点を考慮すると、レスキュー公開鍵証明書の有効期間経過後には部品に再度レスキュー公開鍵証明書を設定し直す必要が生じてしまうので、レスキュー公開鍵証明書の有効期間は長い方が好ましい。具体的には、例えば記憶させる装置の製品寿命よりも長い有効期間を設定するとよい。この製品寿命は、装置の想定運用期間あるいは想定動作期間であり、開発時に想定している使用期間や想定耐用年数、装置の品質保証期間等から定めることができる。
また、レスキュー公開鍵証明書の有効期間を、装置をメンテナンスしながら正常に動作させられると想定される期間よりも長く設定すれば、レスキュー公開鍵証明書は装置の動作中には有効期限が切れない証明書であるということができる。従って、装置の動作中は、常にレスキュー公開鍵証明書を用いた認証(レスキュー証明書セットを用いた認証)が可能な状態を保つことができる。従って、一旦レスキュー公開鍵証明書を記憶させて製造した部品に対し、ストック中にこの証明書の有効期限が切れて、これを更新する必要が生じることもない。
【0057】
また、上記の製品寿命や装置の動作期間よりも極めて長い有効期間を定めるようにすれば、なおよい。図8に示した例では、有効期間を50年に設定しており、通常の装置であればこの程度で十分と考えられるが、これはX.509フォーマットに従って設定できる有効期間の最大が50年であるためこのようにしただけで、さらに長い期間、例えば100年や数百年を設定してもよいことはもちろんである。このように有効期間を定めた場合、有効期間の終期は、単に公開鍵証明書のフォーマット上の要求により記載したものであり、レスキュー公開鍵証明書の有効期限は事実上ないものと考えることができる。また、対象の装置によっては、20年や30年程度あるいはそれ以下の有効期間であっても、同様に考えることができる場合もある。
さらにまた、たとえレスキュー公開鍵証明書の有効期間が製品寿命より短かったとしても、通常公開鍵証明書の有効期間よりも長ければ、通常公開鍵証明書を記憶させておく場合よりも部品のストック可能期間を延ばすことができるという効果を得ることはできる。
通常公開鍵証明書の有効期間については、安全性を考慮して適当な期間を定めればよいが、この期間は、製品寿命よりも短く、また装置の動作中に有効期限が切れるような期間となることが多い。
【0058】
また、ここでは、レスキュー公開鍵証明書の書誌情報には装置の識別情報を記載せず、同じ階位の装置(図1あるいは図20に示した例では、上位装置と下位装置の階位が存在するものとする)には、全て同じレスキュー公開鍵証明書を記憶させることができるようにしている。この場合、同じ階位の各装置を個別に区別する必要がないので、証明書に含まれるレスキュー公開鍵及びこれと対応するレスキュー私有鍵も含めて、全く共通のものでよい。そして、通信相手のレスキュー公開鍵証明書が全て同じであることから、ルート鍵証明書については、ある階位の装置の通信相手となる全ての装置について共通となる。すなわち、下位装置20を複数設けた場合でも、全ての下位装置20に同じレスキュー認証情報を記憶させることになる。
これは、上位装置10のレスキュー認証情報についても同様である。
そして、通常公開鍵証明書とデータ形式を統一化するため、図10に示した例において、発行先装置の機番として0を記載してレスキュー公開鍵証明書であることを示すようにしている。なお、「Subject」の項目を空白としてこのことを示すことも考えられる。
【0059】
このようにすることは必須ではないが、このように、レスキュー認証情報を同じ階位の装置について全て共通にできるようにすると、証明書の記憶領域を備える部品の製造時に、その部品を装着する装置の機種に応じて定まる階位に対応するものを画一的に記憶させてしまうことができる。そして、このようなレスキュー認証情報を記憶しており、通常認証情報を記憶していない部品であれば、製造時に装置の識別情報が必要ないため、装置の識別情報によらず共通に使用可能な部品として生産することができる。
【0060】
なお、レスキュー公開鍵証明書には装置の識別情報を付さないようにする場合、レスキュー公開鍵証明書を用いた認証を行った場合でも、通信相手の装置を具体的に特定することはできない。しかし、通信相手についてある程度の情報は得ることができる。
すなわち、例えばあるベンダーが自社製品のうち下位装置20に該当する装置全てに下位装置用のレスキュー証明書セットを記憶させ、その通信相手となる上位装置10に該当する装置全てに上位装置用のレスキュー証明書セットを記憶させておけば、認証が成功した場合、下位装置20は、自己の記憶している上位装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手が同じベンダーの上位装置10であることを認識できるし、逆に上位装置10も自己の記憶している下位装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手は同じベンダーの下位装置20であることを認識できる。
【0061】
従って、通信を要求した装置あるいは要求してきた装置が通信相手として適当な装置か否かについて、識別情報を参照できなくてもある程度の判断を行うことができる。
そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができるので、その後機番情報等を交換して通信相手を特定することも可能である。
【0062】
ところで、サーバとして機能する下位装置20は、SSLハンドシェイクの際に、通信を要求してきた相手を識別できないため、基本的には全ての相手に同一の公開鍵証明書を送信することになる。しかし、この通信システムにおいては、状況に応じて通常公開鍵証明書とレスキュー公開鍵とを使い分ける必要がある。そこで、次にこの使い分けのための構成について図11を用いて説明する。
SSLプロトコルにおいては、サーバは、クライアントから通信要求があった時点ではクライアントの状態を知ることができないため、必然的に、特定のURL(Uniform Resource Locator)にアクセスされた場合には常に同じ公開鍵証明書を提供することになる。従って基本的には、通常公開鍵証明書を複数持ち、通信相手の持つ通常ルート鍵証明書の種類に合わせて適当なものを選択して送信するといった構成を取ることはできない。しかし、通信要求を受け付けるアドレスが異なる場合には、アドレス毎に異なる公開鍵証明書を返すことも可能である。このアドレスは、例えばURLによって定めることができる。
【0063】
従ってここでは、図11に示すように、上位装置10及び下位装置20にそれぞれ、通常公開鍵証明書による認証を行う通常URLとレスキュー公開鍵証明書による認証を行うレスキューURLとを設け、通信を要求する側(クライアントとして機能する側)が、要求する認証の種類に応じていずれかのURLを選択的に指定して通信要求を送るようにしている。これらのURLは、IPアドレスやポート番号(いずれか一方でもよい)を変えることにより、物理的には同じ装置のURLであっても、論理的には異なる装置のURLとして取り扱うことができるようにしている。すなわち、いわゆるバーチャルサーバの機能を実現するためのものである。
【0064】
このようにした場合、通信を要求される側(サーバとして機能する側)は、返す証明書を通信要求を受け付けたURLによって区別し、通常URLで受け付けた場合には通常公開鍵証明書を返し、レスキューURLで受け付けた場合にはレスキュー公開鍵証明書を返すことができる。
なお、通信を要求するクライアントの側では、どのURLに対して通信要求を送ったかがわかるので、相互認証を行う場合にはURLに応じた適切な公開鍵証明書を選択して送信することができる。
【0065】
従って、この通信システムにおいては、上位装置10と下位装置20との間で基本的には通常公開鍵証明書を用いた認証を行いながら、これが部品の交換によって取り去られた場合にも、新たな部品が装着された後でレスキュー公開鍵証明書を用いた認証を行い、安全な通信経路を確保することができる。レスキュー公開鍵証明書を用いた認証であっても、共通鍵の共有は通常公開鍵証明書の場合と同様に可能であるためである。そして、この通信経路を用いて上位装置10から下位装置20に設定用の通常認証情報を送信して記憶させることにより、再度通常認証情報を用いた認証が可能な状態に復帰させることができる。
【0066】
また、レスキュー公開鍵証明書を用いた認証であっても、上述のようにある程度相手の装置を特定することができるので、例えば自社の製造した装置のみに通常公開鍵証明書を送信するようにする等の制限をかけることができ、不正な装置に通常公開鍵証明書を送信して記憶させてしまうことを防止できる。
以上のように、この通信システムにおいては、通常認証情報に加えてレスキュー認証情報も使用することにより、認証に必要な証明書を記憶する部品を交換する必要が生じた場合でも、容易かつ速やかに正常な認証が行える状態に容易に回復させることができる。
【0067】
なお、図6に示した認証情報は、上位装置10と下位装置20とが相互認証を行う場合には全て記憶している必要があるが、下位装置20がサーバとして機能し、かつ上位装置10が下位装置20を認証する片方向認証だけを行う場合には、一部の証明書等については記憶しておく必要はない。通常認証情報とレスキュー認証情報の双方について、下位装置20においては、上位装置認証用ルート鍵証明書は不要となるし、上位装置10においては、上位装置用公開鍵証明書と上位装置用私有鍵が不要となる。
【0068】
次に、下位装置20や上位装置10において、上述した認証情報を記憶する記憶領域を設けるハードウェアについて説明する。
下位装置20や上位装置10において、このような記憶領域は、不揮発性の記録媒体であれば設計上はどこにでも設けることができる(ただし、通常証明書セットを記憶する領域は書き換え可能な記録媒体に設けることが好ましい)。例えば、下位装置20において、通常証明書セットを記憶する記憶領域をRAM23に、レスキュー証明書セットを記憶する記憶領域をROM22に設けることもできる。
しかしながら、通常証明書セットとレスキュー証明書セットの記憶領域を別々に交換可能な部品に設けると、以下のような問題が生じる。図12を用いてこの問題について説明する。図12は、この実施形態の比較例における、証明書の記憶領域を設ける交換部品の構成及びその問題点について説明するための図である。
【0069】
比較例として、図12(a)に示すように、別々に交換可能な部品Xと部品Yにそれぞれ通常証明書セット記憶領域とレスキュー証明書セット記憶領域を設けた構成を考える。すると、なお、部品Xについては、製造時に通常公開鍵証明書を記憶させておいてもストック中に有効期間が過ぎてしまう可能性があるため、通常証明書セットは記憶させない状態で製造することになる。一方、部品Yについては、レスキュー公開鍵証明書であれば有効期間が過ぎてしまうことはあまりないと想定し、その機種や階位に適したレスキュー証明書セットをあらかじめ記憶させた状態で製造するようにすることができる。
【0070】
そして、下位装置20′において部品Xと部品Yが破損等してこれらを交換した場合(部品Xのみを交換した場合でも同じ)、(b)に示すように、下位装置20′には、レスキュー証明書セットのみが記憶され、通常証明書セットは記憶されていない状態となる。この状態において、上位装置10がこの下位装置20′をレスキュー証明書セットに含まれる下位装置用レスキュー公開鍵証明書を用いた認証処理によって認証すると、通常証明書セットを下位装置20′に送信し、これを通常証明書セット記憶領域に設定させる。そしてこの後は、この通常証明書セットに含まれる下位装置用通常公開鍵証明書を用いて認証可能な状態となる。
【0071】
しかし、その後(c)に示すように下位装置20′から部品Xを取り外して部品Xと同様な記憶領域を有する偽部品X′を装着した場合、(b)の場合と同様に下位装置20′にレスキュー証明書セットのみが記憶された状態となるため、上位装置10は再度下位装置20′に通常証明書セットを送信して記憶させてしまう。そして、証明書の記憶領域を設ける部品自体はメモリカード等の汎用性の高い部品とすることも多いため、正規の部品Xと同様な記憶領域を設けることのできる偽部品X′を入手することは容易である場合が多い。従って、偽部品への交換を繰り返すことにより、ユーザは正規の通常証明書セットを記憶させた偽部品X′を大量に取得し、場合によっては成りすまし等に悪用することも可能になってしまうという問題があるのである。なお、部品Yさえ正規のものを使用すれば、正規の部品Xを一切使用しなくても上記と同様なことが可能になってしまう。
【0072】
次に、この実施形態の構成及びその効果について、図13を用いて説明する。図13は、下位装置20における、証明書の記憶領域を設ける交換部品の構成及びその効果について説明するための図である。
この実施形態の下位装置20においては、上記の問題を解決するため、図12(a)に示した比較例の構成とは異なり、図13(a)に示すように、通常証明書セットを記憶する記憶領域と、レスキュー証明書セットを記憶する記憶領域とを両方とも、交換可能な最小単位の交換部品上に設けている。しかし、このような構成を採る場合でも、証明書の特性は変わらないので、この部品Aを、レスキュー証明書セットのみ予め記憶させ、通常証明書セットは記憶させない状態で製造することになる点は、図12(a)の場合と同様である。
【0073】
ここで、下位装置20において部品Aが破損等してこれらを交換した場合、図13(b)に示すように、下位装置20には、レスキュー証明書セットのみが記憶され、通常証明書セットは記憶されていない状態となる。そして、図12(b)の場合と同様に、上位装置10がこの下位装置20を下位装置用レスキュー公開鍵証明書を用いた認証処理によって認証すると、通常証明書セットを下位装置20に送信して設定させ、下位装置用通常公開鍵証明書を用いて認証可能な状態とする。
【0074】
しかし、その後図13(c)に示すように下位装置から部品Aを取り外して部品Aと同様な記憶領域を有する偽部品A′を装着した場合でも、偽部品A′は正しいレスキュー証明書セットを記憶していない。正当なベンダー以外は正しいレスキュー証明書セットを知らないので、正しいレスキュー証明書セットを記憶した偽部品A′を製造することができないためである。従って、図12(c)の場合とは異なり、下位装置20は上位装置10に認証を受けることができないので、上位装置10が下位装置に通常証明書セットを送信して記憶させてしまうこともない。従って、部品Aをハードウェアとしては汎用性の高い部品で構成したとしても、通常証明書セットを偽部品A′に不正に設定されてしまうことを防止できる。
部品Aを取り外して別の正規の部品Aに交換した場合には、新たな通常証明書セットがそこに記憶されることになるが、正規の部品Aであれば、ベンダー側が流通をコントロールすることが可能であるので、ユーザに必要以上の数の部品Aを供給しないようにすればよい。
【0075】
この通信システムにおいては、以上のような構成を採ることにより、通常公開鍵証明書を不正に取得されることを防止し、成りすまし等の危険を低減して通信の高い安全性を維持することができる。
なお、ここでいう交換可能な最小単位の交換部品とは、ユーザの作業やサービスマンによる出張メンテナンス等の作業によって交換可能な部品のうち、交換する場合にはその全部を交換する必要がある部品を指すものとする。例えばROM22やRAM23を構成するフラッシュメモリやNVRAM等を備えたメモリカードやメモリユニット、あるいはCPU21と共に書き換え可能な不揮発性メモリを搭載したCPUボード等が考えられる。しかし、例えば、CPUボード上に複数のメモリチップが搭載されており、工場等で特殊な設備を使用すればこれらを個別に交換可能であったとしても、ユーザの作業やサービスマンによる出張メンテナンス等の作業では通常交換できない場合には、それは交換可能とは言わないものとする。
【0076】
次に、このような証明書セットの記憶領域を設けた部品A及びその部品Aを装着した下位装置20の製造工程について説明する。
まず、これらの製造工程の概略を図14に示す。この図においては、証明書セットの設定に関する部分を中心に示し、それ以外の部分については大幅に簡略化して示している。
【0077】
この図に示すように、下位装置20を製造する場合、まず部品製造工程において証明書セットの記憶領域を設けた部品Aを製造するが、この工程では、部品Aを組み立て、検査して、その後工場のソフトウェア複写装置130によって下位装置20用のレスキュー証明書セットを書き込む。この時点では、ソフトウェア複写装置130と部品Aとの間でネットワークを介した安全な通信経路を設けることはできないし、レスキュー証明書セットは漏洩した場合の影響が通常証明書セットの場合より大きいため、書き込みは専用の冶具を用いて直接行うようにしている。またこの時、下位装置20の制御に使用するソフトウェアのうち部品Aに記憶させるものも同時に書き込むようにするとよい。
以上で部品Aが完成し、これを部品として流通させる場合には、梱包した上出荷することになる。
ここで、レスキュー公開鍵証明書に装置の識別情報を記載しない場合には、書き込むべきレスキュー証明書セットは部品Aを装着する装置の機種や階位に応じて定まるので、これを予めソフトウェア複写装置130に記憶させておけばよい。また、部品Aが規格化されたメモリカード等の場合には、組み立てる必要がない場合もある。
【0078】
一方、部品Aを下位装置20の製造に使用する場合には、レスキュー証明書セットを書き込んだ部品Aを製品組み立て工程に回し、これを組み立て中の下位装置20の本体部に装着する。そして、下位装置20の組み立てが完了した後、その機能検査を行い、合格した装置に機番を付与する。その後、その機番を装置の識別情報として通常公開鍵証明書に含む通常証明書セットを、証明書書き込み装置160によって下位装置20に記憶させ、また装置の機番情報や初期設定値もこの工程で記憶させる。その後、外観を検査し、梱包して出荷する。
以上の工程で下位装置20を製造することができる。また、記憶させるレスキュー証明書セットは異なるが、上位装置10についても同様な工程で製造することができる。なお、部品製造工程と製品組み立て工程とは、別々の工場で行われることが多い。
【0079】
また、図15に部品Aに各証明書セットを記憶させる工程の説明図を示す。
この図に示すように、部品Aには部品製造工程においてレスキュー証明書セットのみを記憶させ、通常証明書セットは記憶させない。そしてこの状態で、製品組み立て工程で新しい装置の組み立てに用いる部品と、市場に販売済の装置のための交換部品(サービスパーツ)とのどちらの用途にも使用できる部品として完成する。
そして、部品Aが装置の組み立て工場において製品組み立て工程で装置に装着された場合には、その装置が検査に合格し、装置に機番が付与された後で、証明書書き込み装置160によって通常証明書セットが書き込まれる。このとき、機番情報入力装置161から証明書書き込み装置160に書き込み対象の装置の機番を入力し、証明書書き込み装置160がその機番の情報を識別情報として含む通常証明書セットを取得して書き込むことになる。この通常証明書セットは、通常公開鍵証明書を管理するCAである証明書管理装置50が発行するものである。
【0080】
なおこのとき、証明書書き込み装置160と下位装置20とを接続した上で、証明書書き込み装置160から下位装置20のレスキューURLに通信を要求し、下位装置20に記憶しているレスキュー証明書セットを用いて、SSLによる認証処理を行う。そして、証明書書き込み装置160が下位装置20が正当な装置であると認証した場合に証明書設定要求と共に通常証明書セットを送信して部品Aの通常証明書セット記憶領域に書き込ませるようにしている。
【0081】
ここで、通常証明書セットを書き込む際に下位装置20側で実行する処理を図16のフローチャートに示す。
下位装置20は、通信相手がレスキューURLに通信を要求してきた場合、図16のフローチャートに示す処理を開始する。
この処理においては、まずステップS201で、通信相手(ここでは証明書書き込み装置160)に認証を受けるために下位装置用レスキュー公開鍵証明書を、下位装置用レスキュー私有鍵で暗号化した第1の乱数と共に通信相手に送信する。この処理は、図23のステップS21及びS22の処理に相当する。
【0082】
通信相手は、下位装置20が送信した証明書と乱数を受信すると、これを用いて認証処理を行い、その結果を応答として返してくる。また、認証が成功していれば、共通鍵の種を下位装置20に送信すると共に共通鍵を作成して以後の通信に使用するようにする。ここでの認証には、下位装置認証用レスキュールート鍵証明書を使用し、この処理は図23のステップS12乃至S17の処理に相当する。
下位装置20は、この認証結果を受け取ると、ステップS202で認証が成功したか否か判断し、失敗であればそのまま処理を終了するが、成功していればステップS203に進んで受信した共通鍵の種を用いて共通鍵を作成して以後の通信に使用するようにする。これらの処理は、図19のステップS25及びS26の処理に相当する。
【0083】
その後、ステップS204で要求の受信を待ち、要求を受信するとステップS205に進む。そして、図4を用いて説明したように、下位装置20の要求管理部44は、レスキュー公開鍵証明書を用いた認証を行った場合には、証明書設定動作のみを許可するようにしているので、ステップS205で受信した要求が証明書設定要求か否かを判断する。そして、証明書設定要求でなければその要求は無視してステップS204に戻って次の要求を待つ。ここで、要求を受け付けられない旨の応答を返すようにしてもよい。
【0084】
ステップS205で証明書設定要求であれば、ステップS206に進んで証明書設定要求と共に受信(通信相手から取得)した証明書セットを部品Aの通常証明書セット記憶領域に記憶させて図6(a)に示した通常証明書セットをその内容に設定する。この処理において、下位装置20のCPU21が証明書設定手段として機能する。
その後、ステップS207で設定結果を応答として送信元に通知して処理を終了する。
下位装置20がこのような処理を実行することにより、証明書書き込み装置160が、下位装置20が通常証明書セットの書き込み対象であることについて少なくとも最低限の確認を行うことができるので、全く異なる装置に誤って通常証明書セットを送信してしまうような事態を防止できる。
【0085】
また、証明書書き込み装置160側にもレスキュー証明書セットを記憶させ、認証処理において下位装置20との間で相互認証を行うようにしてもよい。この場合に使用するレスキュー証明書セットは、上位装置10に記憶させるものと同じものになり、下位装置20側の認証処理も、図21に示した処理に対応したものになる。そして、このようにすれば、下位装置20側でも、不正な証明書書き込み装置から送られてくる通常証明書セットを設定してしまうことがないようにすることができる。
さらに、通信要求について、下位装置20側から証明書書き込み装置160に対して通信要求を行うようにすることも考えられる。この場合でも、証明書書き込み装置160と下位装置20とがレスキュー公開鍵証明書を用いた認証処理を行い、これが成功した場合に証明書書き込み装置160が下位装置20に通常公開鍵証明書を送信して設定させることは、上述の処理の場合と同様である。
【0086】
一方で、図15において、部品Aがサービスパーツとして出荷され、設置先で稼動中の下位装置20に装着された場合には、その下位装置20と対応する上位装置10によって通常証明書セットが書き込まれることになる。このとき、機番情報入力装置171から上位装置10に書き込み対象の装置の機番を入力し、上位装置10がその機番の情報を識別情報として含む通常証明書セットを証明書管理装置50に発行させ、これを取得して下位装置20に設定させることになる。下位装置20の機番等の識別情報については、上位装置10からの要求に応じて下位装置20から上位装置10に送信させるようにしてもよい。
【0087】
なおこのとき、上位装置10から下位装置20のレスキューURLに通信を要求し、下位装置20に記憶しているレスキュー証明書セットを用いて、SSLによる認証処理を行う。そして、上位装置10が下位装置20は正当な装置であると認証した場合に通常証明書セットを送信して部品Aの通常証明書セット記憶領域に設定させるようにしている。この場合に下位装置20側で行う処理は、図16のフローチャートに示したものと同じものである。もちろん、相互認証を行うようにしてもよい。このことによる効果は、証明書書き込み装置160によって書き込む場合と同様であるが、どのような装置と接続されるかわからない出荷後の方が、接続対象が限定される工場内においてよりも安全性向上の要求は強いと言える。
また、下位装置20が上位装置10に通信要求を行うようにしてもよいことも、上述の証明書書き込み装置160によって書き込む場合と同様である。
【0088】
以上の説明から明らかなように、下位装置20に対して、工場での生産時と市場での部品交換時とにおいて全く同じ手順で通常公開鍵証明書を記憶させることができる。
なお、下位装置20に、その機番情報を装置の識別情報として付された通常公開鍵証明書を記憶させるようにする場合であっても、機番は、装置の組み立てが完了し、機能の検査に合格した装置に付すようにしたいという要求がある。なぜなら、検査前に機番を付してしまうと、検査に不合格となった装置の機番が欠番になってしまい、このような欠番があるとその後の製品管理に不都合があるためにである。
【0089】
従って、この要求を満たしつつ、機番情報を装置の識別情報として付された公開鍵証明書を装置の製造工程で記憶させるとすると、必然的に組み立てが全て完了した状態で行うことになる。そして、このような状態においては、レスキュー証明書セットの場合のように特殊なインタフェース(専用の冶具)を用いて証明書を記憶させるよりも、下位装置20が備え、かつ通常使用するインタフェースを介して記憶させる方が好ましい。デザインや機能上の制約から、特殊なインタフェースの接続口は、作業しやすい位置や構成では設けにくいためである。
【0090】
ここで説明した下位装置20は、ネットワークを介して通常証明書セットを書き込むことが可能であるので、装置の組み立て完了後であっても、装置に備えているネットワークケーブルの接続I/Fを介して証明書書き込み装置160と接続し、通常証明書セットの書き込み作業を行うことができる。従って、効率のよい作業を行うことができるし、作業中に装置を破損等してしまう危険も極めて少ない。また、この書き込み工程において通信を暗号化できるので、通常証明書セットを安全に記憶させることができる。
【0091】
なお、通常公開鍵証明書とレスキュー公開鍵証明書とでは用途も機能も異なるため、図15に示したように、これらの証明書は別々のCAが発行するようにすることが好ましい。
また、ここではレスキュー公開鍵証明書は同じ階位の装置全てに同じものを記憶させるため、レスキュールート私有鍵が漏洩するとセキュリティの維持が著しく困難になるので、秘密保持を特に厳重に行う必要がある。一方で、各装置について個別に異なる証明書を作成して記憶させる必要はない。そこで、安全性を重視し、外部からアクセス不能なCAを用いるとよい。
【0092】
一方、通常公開鍵証明書は必要に応じて更新できるため、通常ルート私有鍵が漏洩したとしても、これを更新すればセキュリティを保つことができる。そして、装置毎に個別に証明書を作成して記憶させる必要があることから、インターネット等のオープンネットワークに接続したCAを用いるとよい。
なお、CAをさらに細分化し、下位装置用の証明書を発行するCA,上位装置用の証明書を発行するCA等、証明書を発行する対象の装置の階位に応じてCAを分けるようにしてもよい。
また、通常公開鍵証明書とレスキュー公開鍵証明書とで全く形式の異なるデジタル証明書を使用することも可能である。
【0093】
次に、上述した製品組み立て工程において通常証明書セットを下位装置20に設定するために使用する設備について説明する。図17はその概略構成を示すブロック図である。
この図に示すように、製品組み立て工程を行う生産工場Eには、通常証明書セットを設定するための設備として、生産管理システム140,通信端末150,証明書書き込み装置160が設置されている。
そして、生産管理システム140は、上位装置10や下位装置20等の装置の日々の生産台数を管理する。
【0094】
通信端末150は、証明書データベース(DB)154a,入力装置156,表示装置157を備えている。そして、生産管理システム140からその日の機種別の生産台数及び付与予定の機番の情報(ここでは機種コードとシリアル番号とを含めた情報)を取得する。また、その情報に基づいて、通常公開鍵証明書を発行するCAである証明書管理装置50に生産予定の装置に記憶させるべき通常証明書セットを発行させ、これを入手して証明書DB154aに記憶させる。
証明書書き込み装置160は、機番情報入力装置161を備えており、装置の生産時にその機番情報入力装置161から生産中の装置の機番の入力を受け付ける。そして、これが入力された場合に、その機番に対応する証明書を通信端末150から入手し、それを対応する装置へ送信してその装置の不揮発性メモリに設けた通常証明書セット記憶領域に設定させる。下位装置20を生産する場合には、部品Aに設けた記憶領域に設定させることになる。
【0095】
次に、図18に生産工場Eにおける通信端末150および証明書書き込み装置160の周辺の状況の概略を示す。
生産工場Eにおいては、通信端末150は、セキュリティ面を考慮して管理者室Fに設置している。そして、その管理者室Fは、特定の管理者しか入れないように、ドアGに鍵をかけるようにしており、通信端末150は、特定のIDとパスワードが入力された場合にのみ操作できるようにしている。
またこの例では、生産工場Eには上位装置10の生産用ライン1001と下位装置20の生産用ライン1002とを設けている。そして、その各生産用ライン毎に証明書書き込み装置160(160a,160b)を設置している。
【0096】
そして、各証明書書き込み装置160にはそれぞれ、機番情報入力装置161(161a,161b)と接続するための機番情報入力用I/F162(162a,162b)、および生産する装置(上位装置10及び下位装置20)と接続するための書き込み用I/F165(165a,165b)がそれぞれ接続されている。
このような生産ラインにおいては、例えば下位装置20を生産する場合、機能検査に合格した装置に識別番号を付与する際に、定格銘板を貼付する。この定格銘板の例を図19に示すが、定格銘板には、定格電圧,消費電力等の情報と共に、装置の機番を記載している。そしてさらに、この機番の情報を示すバーコードBCも記載している。
【0097】
そして、通常証明書セットの設定工程においては、まず書き込み用I/F165としてクロスケーブルを用いて証明書書き込み装置160と設定対象の下位装置20を接続する。ここでクロスケーブルを用いるのは、生産される各装置は初期値として同じIPアドレスを有しており、証明書書き込み装置160とLAN接続すると、IPアドレスが重複してしまうためである。
続いて機番情報入力装置161としてバーコードリーダを用い、定格銘板上のバーコードBCを読み取って作業対象の装置の機番の情報を証明書書き込み装置160に入力する。すると、証明書書き込み装置160がその機番に対応する証明書を通信端末150から入手し、書き込み用I/F165を介して接続する下位装置20へ送信してその装置の部品Aに設けた通常証明書セット記憶領域に設定させる。
以上の作業及び処理により、生産する各下位装置20に、その機番情報を装置の識別情報として付された通常公開鍵証明書を簡単な作業で記憶させることができる。
【0098】
なお、以上説明した実施形態では、上位装置10と下位装置20を始めとする各装置間で、図21あるいは図23を用いて説明したようなSSLに従った認証を行う場合の例について説明した。しかし、この認証が必ずしもこのようなものでなくてもこの実施形態は効果を発揮する。
SSLを改良したTLS(Transport Layer Security)も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。
【0099】
また、上述した実施形態では、有効期間の短い通常公開鍵証明書と、有効期間の長いレスキュー公開鍵証明書とを用いる例について説明したが、前者はセキュリティ強度が高い証明書、後者はセキュリティ強度が比較的低い証明書と捉えることもできる。
一般に、セキュリティ強度が高い証明書には、多くの情報を記載する必要があったり、輸出制限があったり特殊な認証処理プログラムが必要であったりして利用可能な環境が限られていたりするため、全ての装置に同じように記憶させて認証処理に用いることが難しい場合がある。一方で、セキュリティ強度が低い証明書であれば、このような制限が少なく、全ての装置に同じように記憶させて認証処理に用いることが比較的容易であると考えられる。
【0100】
そこで、セキュリティ強度が低い証明書を記憶させた装置を製造・販売した上で、利用環境に合わせてセキュリティ強度が高い証明書を事後的に記憶させることができるようにしたいという要求がある。例えば、システムの運用者によって種々に認証処理の内容を工夫したり信頼性の高いCAを選択したりしてセキュリティの向上を図る場合も考えられるが、このような場合、ある装置を1つのシステムから他のシステムに移動(単に設定を変更するのみの場合も含む)させる場合、通常の認証処理に使用する証明書を入れ換える必要があることが考えられる。また、セキュリティの高い証明書に後で欠陥が発見され、認証処理の方式を変更する必要が生じることも考えられる。
【0101】
このような場合に、上述した実施形態の構成を利用し、セキュリティ強度が高い証明書を記憶する記憶領域とセキュリティ強度が低い証明書を記憶する記憶領域とを、交換可能な最小単位の交換部品に設けることにより、セキュリティ強度が高い証明書を不正に取得されることを防止し、成りすまし等の危険を低減して通信の高い安全性を維持することができる。また、製造する部品に種々の環境で共通に利用できるようなセキュリティの比較的低い証明書を記憶させておくようにすることにより、その部品を種々の環境で共通に利用することができるので、部品供給が容易になる。
【0102】
また、上述した実施形態では、通常公開鍵証明書に装置の識別情報を記載する例について説明したが、通常公開鍵証明書にも装置の識別情報を含めず、同じ階位の装置には、全て同じ通常公開鍵証明書を記憶させるようにしてもよい。このようにしたとしても、通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けた後で機種機番情報等を交換して通信相手を特定することが可能であることは、レスキュー公開鍵証明書の場合と同様である。そして、このようにしたとしても、有効期限が短い分だけレスキュー公開鍵証明書よりも高い安全性を得ることができる。
【0103】
また、上述した実施形態では、証明書管理装置50を上位装置10と別に設ける例について説明したが、これと一体として設けることを妨げるものではない。この場合、証明書管理装置50の機能を実現するためのCPU,ROM,RAM等の部品を独立して設けてもよいが、上位装置10のCPU,ROM,RAM等を使用し、そのCPUに適当なソフトウェアを実行させることにより、証明書管理装置50として機能させるようにしてもよい。
このような場合において、証明書管理装置50と、これと一体になっている上位装置10との間の通信には、ハードウェアを証明書管理装置50として機能させるためのプロセスと、ハードウェアを上位装置10として機能させるためのプロセスとの間のプロセス間通信を含むものとする。
【0104】
さらに、上述した実施形態では、証明書管理装置50がルート鍵やデジタル証明書を自ら作成する例について説明したが、証明書管理装置50は鍵や証明書の管理を専門に行い、他の装置からルート鍵やデジタル証明書の供給を受けてこれらを取得するようにしてもよい。
【0105】
また、上述した実施形態では、通信システムを上位装置10と下位装置20のみによって構成したが、他の装置を含めて構成するようにしてもよい。例えば、上位装置10と下位装置20との間の通信を仲介する仲介装置を設け、上位装置10と下位装置20とがこの仲介装置を介して要求や応答を授受するようにしてもよい。あるいは、上位装置10の更に上位の装置を設けてもよい。この場合には、上位装置10を「下位装置」、その更に上位の装置を「上位装置」と見れば、これらの装置についても上述した実施形態の場合と同様な取り扱いが可能である。
【0106】
また、従来から、通信機能を備えたプリンタ,ファクシミリ(FAX)装置,デジタル複写機,スキャナ装置,デジタル複合機等の画像処理装置を被管理装置とし、これらの被管理装置と通信可能な管理装置によってこれらの被管理装置を遠隔管理する遠隔管理システムが提案されている。
例えば、画像形成手段を備えた画像処理装置については、感光体静電プロセスを用いて普通紙に画像形成するものが一般的であるが、このような感光体静電プロセスを行う機構からは、トラブル(異常)が発生する割合も高く、更に性能維持のための定期的なオーバホールの必要性から、保守管理のサービス体制を採っている。
そして、この保守管理を充実させる目的で、画像形成装置を被管理装置とする遠隔管理システムとして、画像形成装置の内部又は外部に通信装置を設け、画像形成装置とサービスセンタ(管理センタ)に設置された管理装置とを公衆回線(電話回線)を介して接続し、画像形成装置の異常発生時にその旨を管理装置に通報するようにしたものが既に開発され運用されている。
【0107】
上述した実施形態は、このような遠隔管理システムにも適用可能であり、この場合、被管理装置を下位装置とし、被管理装置を管理する管理装置やユーザ環境内にあって複数の被管理装置の情報を取りまとめるような装置を上位装置とするとよい。
遠隔管理を行う場合には、被管理装置の近くに管理装置の操作者がいないことが多いため、被管理装置の特定は、通信によって行う必要がある。そして、通信によって特定された被管理装置が確かにその装置であることを保証する仕組みが必要になる。従って、上述の実施形態で説明したように通常公開鍵証明書を用いた認証を容易に運用できるようにすることによる効果は大きい。
【0108】
なお、遠隔管理の対象としては、画像処理装置に限られず、ネットワーク家電,自動販売機,医療機器,電源装置,空調システム,ガス・水道・電気等の計量システム,自動車,航空機あるいは汎用コンピュータ等の種々の電子装置に通信機能を持たせた通信装置を被管理装置とすることが考えられる。ただし、下位装置20が遠隔管理システムにおける被管理装置に限られるものでないことも、もちろんである。
【産業上の利用可能性】
【0109】
以上説明してきたように、この発明の通信装置、通信システム、証明書更新方法を用いれば、通信手段によって通信相手と通信可能な通信装置あるいはこのような通信装置を備える通信システムにおいて、セキュリティを維持しながら、認証に必要な証明書を記憶する部品を交換する必要が生じた場合でも、容易かつ速やかに正常な認証が行える状態に容易に回復させることができる。
従って、この発明を、このような通信装置あるいは通信システムに適用することにより、より安全性の高い装置あるいはシステムを提供することができる。
【符号の説明】
【0110】
10…上位装置、11…CPU、12…ROM、13…RAM、14…HDD、
15…通信I/F、16…システムバス、20,20′…下位装置、
31,41…HTTPSクライアント機能部、32,42…HTTPSサーバ機能部、
33,43…認証処理部、34…証明書更新要求部、35,45…証明書記憶部、
44…要求管理部、46…状態通知部、47…ログ通知部、48…証明書設定部、
49…コマンド受信部、50…証明書管理装置、60,70…SOAPメッセージ、
140…生産管理システム、150…通信端末、154a…証明書DB、
156…入力装置、157…表示装置、160…証明書書き込み装置、
161…機番情報入力装置、162…機番情報入力用I/F、
165…書き込み用I/F、
BC…バーコード、E…生産工場、F…管理者室、G…ドア
【先行技術文献】
【特許文献】
【0111】
【特許文献1】特開2002−353959号公報
【特許文献2】特開2002−251492号公報
【技術分野】
【0001】
この発明は、通信手段を備え、該通信手段によって通信相手と通信可能な通信装置、このような通信装置である下位装置とその通信相手となる上位装置を備える通信システム、およびこのような通信装置に証明書を設定する証明書設定方法に関する。
【背景技術】
【0002】
従来から、それぞれ通信機能を備えた複数の通信装置をネットワークを介して通信可能に接続し、様々なシステムを構築することが行われている。その一例としては、クライアント装置として機能するPC等のコンピュータから商品の注文を送信し、これとインターネットを介して通信可能なサーバ装置においてその注文を受け付けるといった、いわゆる電子商取引システムが挙げられる。また、種々の電子装置にクライアント装置あるいはサーバ装置の機能を持たせてネットワークを介して接続し、相互間の通信によって電子装置の遠隔管理を行うシステムも提案されている。
【0003】
このようなシステムを構築する上では、通信を行う際に、通信相手が適切か、あるいは送信されてくる情報が改竄されていないかといった確認が重要である。また、特にインターネットによる通信を行う場合には、情報が通信相手に到達するまでに無関係なコンピュータを経由する場合が多いことから、機密情報を送信する場合、その内容を盗み見られないようにする必要もある。そして、このような要求に応える通信プロトコルとして、例えばSSL(Secure Socket Layer)と呼ばれるプロトコルが開発されており、広く用いられている。このプロトコルを用いて通信を行うことにより、公開鍵暗号方式と共通鍵暗号方式とを組み合わせ、通信相手の認証を行うと共に、情報の暗号化により改竄及び盗聴の防止を図ることができる。また、通信相手の側でも、通信を要求してきた通信元の装置を認証することができる。
このようなSSLや公開鍵暗号を用いた認証に関連する技術としては、例えば特許文献1及び特許文献2に記載のものが挙げられる。
【0004】
ここで、このSSLに従った相互認証を行う場合の通信手順について、認証処理の部分に焦点を当てて説明する。図21は、通信装置Aと通信装置BとがSSLに従った相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
図21に示すように、SSLに従った相互認証を行う際には、まず双方の通信装置にルート鍵証明書及び、私有鍵と公開鍵証明書を記憶させておく必要がある。この私有鍵は、認証局(CA:certificate authority)が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にCAがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、CAがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。
【0005】
図22にこれらの関係を示す。
図22(a)に示すように、公開鍵Aは、私有鍵Aを用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者(CA)や有効期限等の情報を含む書誌情報とによって構成される。そして、CAは、鍵本体や書誌情報が改竄されていないことを示すため、公開鍵Aをハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名としてクライアント公開鍵に付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Aの書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、公開鍵証明書Aである。
【0006】
この公開鍵証明書Aを認証処理に用いる場合には、ここに含まれるデジタル署名を、ルート私有鍵と対応する公開鍵であるルート鍵の鍵本体を用いて復号化する。この復号化が正常に行われれば、デジタル署名が確かにCAによって付されたことがわかる。また、公開鍵Aの部分をハッシュ処理して得たハッシュ値と、復号して得たハッシュ値とが一致すれば、鍵自体も損傷や改竄を受けていないことがわかる。さらに、受信したデータをこの公開鍵Aを用いて正常に復号化できれば、そのデータは、私有鍵Aの持ち主から送信されたものであることがわかる。
【0007】
ここで、認証を行うためには、ルート鍵を予め記憶しておく必要があるが、このルート鍵も、図22(b)に示すように、CAがデジタル署名を付したルート鍵証明書として記憶しておく。このルート鍵証明書は、自身に含まれる公開鍵でデジタル署名を復号化可能な、自己署名形式である。そして、ルート鍵を使用する際に、そのルート鍵証明書に含まれる鍵本体を用いてデジタル署名を復号化し、ルート鍵をハッシュ処理して得たハッシュ値と比較する。これが一致すれば、ルート鍵が破損等していないことを確認できるのである。
【0008】
図21のフローチャートの説明に入る。なお、この図において、2本のフローチャート間の矢印は、データの転送を示し、送信側は矢印の根元のステップで転送処理を行い、受信側はその情報を受信すると矢印の先端のステップの処理を行うものとする。また、各ステップの処理が正常に完了しなかった場合には、その時点で認証失敗の応答を返して処理を中断するものとする。相手から認証失敗の応答を受けた場合、処理がタイムアウトした場合等も同様である。
【0009】
ここでは、通信装置Aが通信装置Bに通信を要求するものとするが、この要求を行う場合、通信装置AのCPUは、所要の制御プログラムを実行することにより、図21の左側に示すフローチャートの処理を開始する。そして、ステップS11で通信装置Bに対して接続要求を送信する。
一方通信装置BのCPUは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図21の右側に示すフローチャートの処理を開始する。そして、ステップS21で第1の乱数を生成し、これを私有鍵Bを用いて暗号化する。そして、ステップS22でその暗号化した第1の乱数と公開鍵証明書Bとを通信装置Aに送信する。
【0010】
通信装置A側では、これを受信すると、ステップS12でルート鍵証明書を用いて公開鍵証明書Bの正当性を確認する。
そして確認ができると、ステップS13で、受信した公開鍵証明書Bに含まれる公開鍵Bを用いて第1の乱数を復号化する。ここで復号化が成功すれば、第1の乱数は確かに公開鍵証明書Bの発行対象から受信したものだと確認できる。
その後、ステップS14でこれとは別に第2の乱数及び共通鍵の種を生成する。共通鍵の種は、例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして、ステップS15で第2の乱数を私有鍵Aを用いて暗号化し、共通鍵の種を公開鍵Bを用いて暗号化し、ステップS16でこれらを公開鍵証明書Aと共にサーバ装置に送信する。共通鍵の種の暗号化は、通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。
また、次のステップS17では、ステップS14で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
【0011】
通信装置B側では、通信装置AがステップS16で送信してくるデータを受信すると、ステップS23でルート鍵証明書を用いて公開鍵証明書Aの正当性を確認する。そして確認ができると、ステップS24で、受信した公開鍵証明書Aに含まれる公開鍵Aを用いて第2の乱数を復号化する。ここで復号化が成功すれば、第2の乱数は確かに公開鍵証明書Aの発行対象から受信したものだと確認できる。
その後、ステップS25で私有鍵Bを用いて共通鍵の種を復号化する。ここまでの処理で、通信装置A側と通信装置B側に共通鍵の種が共有されたことになる。そして、この共通鍵の種は、生成した通信装置Aと、私有鍵Bを持つ通信装置B以外の装置が知ることはない。ここまでの処理が成功すると、通信装置B側でもステップS26で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
【0012】
そして、通信装置A側のステップS17と通信装置B側のステップS26の処理が終了すると、相互に認証の成功と以後の通信に使用する暗号化方式とを確認し、生成した共通鍵を用いてその暗号化方式で以後の通信を行うものとして認証に関する処理を終了する。なお、この確認には、通信装置Bからの認証が成功した旨の応答も含むものとする。以上の処理によって互いに通信を確立し、以後はステップS17又はS26で生成した共通鍵を用い、共通鍵暗号方式でデータを暗号化して通信を行うことができる。
【0013】
このような処理を行うことにより、通信装置Aと通信装置Bが安全に共通鍵を共有することができ、通信を安全に行う経路を確立することができる。
ただし、上述した処理において、第2の乱数を公開鍵Aで暗号化し、公開鍵証明書Aを通信装置Bに送信することは必須ではない。この場合、通信装置B側のステップS23及びS24の処理は不要になり、処理は図23に示すようになる。このようにすると、通信装置Bが通信装置Aを認証することはできないが、通信装置Aが通信装置Bを認証するだけでよい場合にはこの処理で十分である。そしてこの場合には、通信装置Aに記憶させるのはルート鍵証明書のみでよく、私有鍵A及び公開鍵証明書Aは不要である。また、通信装置Bにはルート鍵証明書を記憶させる必要はない。
【0014】
一方、このような公開鍵証明書を発行する第3者機関として、私有鍵の保有者の確認を行い、その私有鍵に対応した公開鍵に対してデジタル署名を行い、公開鍵証明書を発行する商用サービスが、例えばベリサイン社やボルチモア社によって提供されている。そして、公開鍵発行のためのシステムが私有鍵を含めて厳重に管理されている信頼性の高い第3者機関が発行する公開鍵証明書は、広く認証に利用されている。また、デジタル証明書を用いた認証を行う場合、信頼性の高い第3者機関が発行した公開鍵証明書を使用したいという要求もある。
【0015】
さらに、このような第3者機関の発行する公開鍵証明書を利用する場合、主要な第3者機関によるデジタル署名の内容を確認するためのルート鍵は、インターネットエクスプローラ(登録商標)やネットスケープ(登録商標)のような一般的なウェブブラウザには予め埋め込まれているため、ウェブブラウザの操作者は、新たにルート鍵を入手して設定する必要がないという利点がある。
また、予めルート鍵を設定されていない装置であっても、信頼性の高い第3者機関のものであればユーザがルート鍵の設定に同意しやすいし、ルート鍵を入手して設定すれば、同じ第3者機関が発行した公開鍵証明書を持つ装置は、装置自体のベンダーに関わらず認証することができるという利点もある。従って、自社製の装置を他社製の装置に接続したい場合等には、第3者機関の発行する公開鍵証明書を利用することが効果的である。また、装置のユーザ側からも、このような公開鍵証明書を利用したいという要望がある。
【発明の概要】
【発明が解決しようとする課題】
【0016】
ところで、このような第3者機関は、安全性を高めるため、発行する公開鍵証明書に有効期間を設定している。また、この期間は通常数年単位であり、1〜3年程度と短い場合が多い。そして、上記の認証処理において、この有効期間が過ぎた公開鍵証明書は、正当な公開鍵証明書とは認めないようにしている。従って、この有効期間が過ぎる前に新しいものに更新する必要がある。
しかし、デジタル証明書を記憶する部品が破損し、これを交換してしまったような場合には、デジタル証明書も部品と共に取り去られてしまう。このため、装置の認証が不可能になってしまうことになり、ネットワークを介した安全な通信経路を確保できなくなってしまうので、自動的な更新は行えなくなってしまう。
【0017】
交換後の部品にデジタル証明書が記憶されていれば問題ないが、上記のような有効期間の短い証明書を記憶させておく場合、販売店、生産・物流拠点、サービス拠点等にストックしておくうちに証明書の有効期限が切れてしまうことも考えられる。従って、有効期限が切れたものについては回収して再度新しい証明書を記憶させる必要がある等、効率の悪い生産体制を強いられることになるという問題がある。また、装置本体の生産打ち切り後に部品を確保しておく場合等、あまり数が必要でない場合にも定期的に部品を生産しつづけなければならないため、この点でも効率が悪い。さらに、このような体制を取る場合、部品の生産打ち切り後には、有効に機能する部品がすぐに市場からなくなってしまうという問題もある。
【0018】
部品を交換してから別途公開鍵証明書や私有鍵を記憶させることも考えられるが、これらを持たない状態では、部品を交換した装置に対する安全な通信経路を確保することができない。そこで、新たな公開鍵証明書等を安全に配布するためには、これを記録媒体に記録して、装置の設置先に郵送したり、部品交換のサービスマンが持参したりする必要がある。しかし、このような体制を取る場合、装置の成りすまし等を防止するため、デジタル証明書については、悪意のユーザによる交換、読み出し、登録を防止する必要があり、一般のユーザによるデジタル証明書の更新を禁止する必要があるので、手動でデジタル証明書を設定するようにする場合の権限の確認が困難であるという問題がある。
【0019】
この発明は、このような問題を解決し、通信手段によって通信相手と通信可能な通信装置あるいはこのような通信装置を備える通信システムにおいて、セキュリティを維持しながら、認証に必要な証明書を記憶する部品を交換する必要が生じた場合でも、容易かつ速やかに正常な認証が行える状態に回復させることができるようにすることを目的とする。
【課題を解決するための手段】
【0020】
上記の目的を達成するため、この発明の通信装置は、通信手段を備え、その通信手段によって通信相手と通信可能な通信装置において、異なる有効期間が設定されている2種類のデジタル証明書であってより有効期間が短い短期証明書とより有効期間が長い長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、上記通信手段を、通信を行う際に上記通信相手に認証を受けるために上記短期証明書を提供する手段を備え、その短期証明書によって上記通信相手に認証された場合に通信を行う手段としたものである。
【0021】
また、通信手段を備え、その通信手段によって通信相手と通信可能な通信装置において、その通信装置の製品寿命よりも有効期間が短いデジタル証明書である短期証明書とその通信装置の製品寿命よりも有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、上記通信手段を、通信を行う際に上記通信相手に認証を受けるために上記短期証明書を提供する手段を備え、その短期証明書によって上記通信相手に認証された場合に通信を行う手段としたものである。
【0022】
また、通信手段を備え、その通信手段によって通信相手と通信可能な通信装置において、その通信装置の動作中に有効期限が切れるデジタル証明書である短期証明書とその通信装置の動作中は有効期限が切れないデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、上記通信手段を、通信を行う際に上記通信相手に認証を受けるために上記短期証明書を提供する手段を備え、その短期証明書によって上記通信相手に認証された場合に通信を行う手段としたものである。
【0023】
また、通信手段を備え、その通信手段によって通信相手と通信可能な通信装置において、有効期限があるデジタル証明書である短期証明書と有効期限が事実上ないデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、上記通信手段を、通信を行う際に上記通信相手に認証を受けるために上記短期証明書を提供する手段を備え、その短期証明書によって上記通信相手に認証された場合に通信を行う手段としたものである。
これらの各通信装置において、上記通信手段に、通信を行う際に通信相手に認証を受けるために上記長期証明書を提供する手段も設け、上記長期証明書によって通信相手に認証された場合に上記通信手段を介してその通信相手から上記短期証明書を取得して上記記憶領域に記憶させる証明書設定手段を設けるとよい。
さらに、上記交換部品を、上記通信装置に装着される前には、上記長期証明書を記憶し、上記短期証明書を記憶していない部品とするとよい。
さらに、上記認証を、SSL又はTLSのプロトコルに従った認証処理によって行うものとし、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
【0024】
また、この発明の通信システムは、上位装置と、その上位装置の通信相手となる下位装置とを備えた通信システムにおいて、上記下位装置において、異なる有効期間が設定されている2種類のデジタル証明書であってより有効期間が短い短期証明書とより有効期間が長い長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、上記通信手段を、通信を行う際に上記通信相手に認証を受けるために上記短期証明書を提供する手段を備え、その短期証明書によって上記通信相手に認証された場合に通信を行う手段としたものである。
【0025】
また、上位装置と、その上位装置の通信相手となる下位装置とを備えた通信システムにおいて、上記下位装置において、上記下位装置の製品寿命よりも有効期間が短いデジタル証明書である短期証明書と上記下位装置の製品寿命よりも有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、上記通信手段を、通信を行う際に上記通信相手に認証を受けるために上記短期証明書を提供する手段を備え、その短期証明書によって上記通信相手に認証された場合に通信を行う手段としたものである。
【0026】
これらの通信システムにおいて、上記下位装置の通信手段に、通信を行う際に通信相手に認証を受けるために上記長期証明書を提供する手段も設け、上記下位装置に、上記長期証明書によって通信相手に認証された場合に上記通信手段を介してその通信相手から上記短期証明書を取得して上記記憶領域に記憶させる証明書設定手段を設けるとよい。
さらに、上記交換部品を、上記下位装置に装着される前には、上記長期証明書を記憶し、上記短期証明書を記憶していない部品とするとよい。
さらに、上記認証を、SSL又はTLSのプロトコルに従った認証処理によって行うものとし、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
【0027】
また、この発明の証明書設定方法は、通信手段を備え、その通信手段によって通信相手と通信可能な通信装置に、デジタル証明書である短期証明書を設定する証明書設定方法において、上記短期証明書と、その短期証明書よりも設定されている有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を備えた交換可能な最小単位の交換部品を、上記長期証明書を記憶させ、上記短期証明書を記憶させない状態で上記通信装置に装着し、上記通信装置に、通信を行う際に通信相手に認証を受けるために上記長期証明書を提供させ、その長期証明書によって上記通信相手に認証された場合に上記通信手段を介してその通信相手から上記短期証明書を取得させて上記記憶領域に記憶させるようにしたものである。
【0028】
また、通信手段を備え、その通信手段によって通信相手と通信可能な通信装置に、上記通信装置の製品寿命よりも有効期間が短いデジタル証明書である短期証明書を設定する証明書設定方法において、上記短期証明書と、上記通信装置の製品寿命よりも有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を備えた交換可能な最小単位の交換部品を、上記長期証明書を記憶させ、上記短期証明書を記憶させない状態で上記通信装置に装着し、上記通信装置に、通信を行う際に通信相手に認証を受けるために上記長期証明書を提供させ、その長期証明書によって上記通信相手に認証された場合に上記通信手段を介してその通信相手から上記短期証明書を取得させて上記記憶領域に記憶させるようにしたものである。
このような証明書設定方法において、上記認証を、SSL又はTLSのプロトコルに従った認証処理によって行うものとし、上記デジタル証明書をその認証処理に使用する公開鍵証明書とするとよい。
【発明の効果】
【0029】
以上のようなこの発明の通信装置、通信システムあるいは証明書更新方法によれば、通信手段によって通信相手と通信可能な通信装置あるいはこのような通信装置を備える通信システムにおいて、セキュリティを維持しながら、認証に必要な証明書を記憶する部品を交換する必要が生じた場合でも、容易かつ速やかに正常な認証が行える状態に容易に回復させることができる。
【図面の簡単な説明】
【0030】
【図1】この発明の通信システムの実施形態の構成を示すブロック図である。
【図2】図1に示した上位装置及び下位装置のハードウェア構成を示すブロック図である。
【図3】同じく上位装置及び下位装置の遠隔管理及び証明書の設定に関わる部分の機能構成を示す機能ブロック図である。
【図4】図3に示した要求管理部における動作の実行可否の判断基準を示す図である。
【図5】図1に示した通信システムにおける上位装置と下位装置との間の通信方式の概要を示す説明図である。
【図6】図1に示した上位装置及び下位装置が記憶する認証情報について説明するための図である。
【図7】通常公開鍵証明書のフォーマット例について説明するための図である。
【図8】図7に記載したフォーマットに従って作成した一般的な公開鍵証明書の例を示す図である。
【図9】同じく、レスキュー公開鍵証明書と対比するための、通常公開鍵証明書の例を示す図である。
【図10】同じく、通常公開鍵証明書と対比するための、レスキュー公開鍵証明書の例を示す図である。
【図11】図1に示した上位装置及び下位装置が通常公開鍵証明書とレスキュー公開鍵証明書とを使い分けるための構成について説明するための図である。
【図12】図1等に示した実施形態の比較例における、証明書の記憶領域を設ける交換部品の構成及びその問題点について説明するための図である。
【図13】図1に示した下位装置における、証明書の記憶領域を設ける交換部品の構成及びその効果について説明するための図である。
【図14】図13に示した部品A及びその部品Aを装着した下位装置の製造工程の概略を示す図である。
【図15】その部品Aに各証明書セットを記憶させる工程について説明するための図である。
【図16】図15に示した工程において下位装置に通常証明書セットを書き込む際に下位装置側で実行する処理を示すフローチャートである。
【図17】図14及び図15に示した製品組み立て工程において通常証明書セットを下位装置に設定するために使用する設備の概略を示す図である。
【図18】生産工場における、図17に示した通信端末および証明書書き込み装置の周辺の状況の概略を示す図である。
【図19】機能検査に合格した装置に識別番号を付与する際に貼付する定格銘板の例を示す図である。
【図20】図1に示した通信システムについて、下位装置を複数設けた場合の構成について説明するための図である。
【図21】2つの通信装置がSSLに従った相互認証を行う際の各装置において実行する処理のフローチャートを、その処理に用いる情報と共に示す図である。
【図22】図21に示した認証処理におけるルート鍵、ルート私有鍵、および公開鍵証明書の関係について説明するための図である。
【図23】2つの通信装置がSSLに従った片方向認証を行う際の各装置において実行する処理を示す、図21と対応する図である。
【発明を実施するための形態】
【0031】
以下、この発明の好ましい実施の形態を図面を参照して説明する。
まず、この発明による通信装置と、その通信装置を用いて構成したこの発明の通信システムの実施形態の構成について説明する。
図1はその通信システムの構成を示すブロック図である。
この通信システムは、図1に示すように、それぞれ通信手段を備える上位装置10及び下位装置20をネットワーク30によって接続して構成している。そして、下位装置20がこの発明の通信装置の実施形態である。また、上位装置10も通信機能を備えた通信装置であり、下位装置20の通信相手となる。
ネットワーク30としては、有線,無線を問わず、ネットワークを構築可能な各種通信回線(通信経路)を採用することができる。また、ここでは下位装置20を1つしか示していないが、図20に示すように通信システム内に下位装置20を複数設けることも可能である。
【0032】
このような通信システムについて、まず上位装置10及び下位装置20のハードウェア構成から説明する。上位装置10及び下位装置20のハードウェア構成は、単純化して示すと、図2に示すようなものである。
この図に示す通り、上位装置10は、CPU11,ROM12,RAM13,HDD14,通信インタフェース(I/F)15を備え、これらがシステムバス16によって接続されている。そして、CPU11がROM12やHDD14に記憶している各種制御プログラムを実行することによってこの上位装置10の動作を制御し、通信相手の認証や下位装置20のデジタル証明書更新等の機能を実現している。なお、この明細書において、デジタル証明書とは、偽造されないようにするための署名が付されたデジタルデータを指すものとする。
【0033】
下位装置20も、上位装置10の場合と同様にCPU21,ROM22,RAM23,HDD24,通信インタフェース(I/F)25を備え、これらがシステムバス26によって接続されている。CPU21が、ROM22やHDD24に記憶している各種制御プログラムを必要に応じて実行し、装置の制御を行うことにより、通信手段、証明書設定手段等の種々の手段としての機能を実現できるようにしている。
なお、この通信システムにおいて、上位装置10及び下位装置20が、遠隔管理,電子商取引等の目的に応じて種々の構成をとることができることは、もちろんである。そして、上位装置10や下位装置20のハードウェアとしては、適宜公知のコンピュータを採用することもできる。もちろん、必要に応じて他のハードウェアを付加してもよいし、上位装置10と下位装置20が同一の構成である必要もない。
【0034】
次に、この通信システムのうちこの実施形態の特徴に関連する部分として、上位装置10及び下位装置20の証明書の設定に関連する部分の機能構成を図3に示す。上位装置10に係るこれらの機能は、上位装置10のCPU11がROM12やHDD14に記憶している所要の制御プログラムを実行することにより実現されるものであり、下位装置20に係るこれらの機能は、下位装置20のCPU21がROM22やHDD24等に記憶している所要の制御プログラムを実行することにより実現されるものである。
【0035】
図3に示すように、上位装置10には、HTTPS(Hypertext Transfer Protocol Security)クライアント機能部31,HTTPSサーバ機能部32,認証処理部33,証明書更新要求部34,証明書記憶部35を備えている。
HTTPSクライアント機能部31は、SSLに従った認証や暗号化の処理を含むHTTPSプロトコルを用いて下位装置20等のHTTPSサーバの機能を有する装置に対して通信を要求すると共に、通信相手に対して要求(コマンド)やデータを送信してそれに応じた動作を実行させる機能を有する。
【0036】
一方、HTTPSサーバ機能部32は、HTTPSクライアントの機能を有する装置からのHTTPSプロトコルを用いた通信要求を受け付け、その装置から要求やデータを受信してそれに応じた動作を装置の各部に実行させ、その結果を応答として要求元に返す機能を有する。
認証処理部33は、HTTPSクライアント機能部31やHTTPSサーバ機能部32が通信相手を認証する際に、通信相手から受信したデジタル証明書や、証明書記憶部35に記憶している各種証明書、私有鍵等を用いて認証処理を行う認証手段の機能を有する。また、通信相手に認証を要求するために証明書記憶部35に記憶しているデジタル証明書をHTTPSクライアント機能部31やHTTPSサーバ機能部32を介して通信相手に送信する機能も有する。
【0037】
証明書更新要求部34は、後述するように所定の場合に下位装置20等の通信相手に対して通常公開鍵証明書を送信してこれを記憶するよう要求する機能を有する。なお、ここで送信する証明書は、この通信システムの外部の証明書管理装置(CA)50に必要な情報を送信して発行させる。
証明書記憶部35は、各種の証明書や私有鍵等の認証情報を記憶し、認証処理部33における認証処理に供する機能を有する。これらの各種証明書や私有鍵の種類及びその用途や作成方法については後に詳述する。
【0038】
一方、下位装置20には、HTTPSクライアント機能部41,HTTPSサーバ機能部42,認証処理部43,要求管理部44,証明書記憶部45,状態通知部46,ログ通知部47,証明書設定部48,コマンド受信部49を備えている。
HTTPSクライアント機能部41は、上位装置10のHTTPSクライアント機能部31と同様に、HTTPSプロトコルを用いて上位装置10等のHTTPSサーバの機能を有する装置に対して通信を要求すると共に、送信する要求やデータ等に応じた動作を実行させる機能を有する。
【0039】
HTTPSサーバ機能部42も、上位装置10のHTTPSサーバ機能部32と同様であり、HTTPSクライアントの機能を有する装置からの通信要求を受け付け、受信した要求やデータに応じた動作を装置の各部に実行させ、要求元に応答を返す機能を有する。
認証処理部43の機能も、上位装置10の認証処理部33と同様であるが、認証処理に使用する証明書等は、証明書記憶部45に記憶しているものである。
要求管理部44は、上位装置から受信した要求について、その要求に基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、その要求に基づいた動作を実行する機能部46〜49に対して動作要求を伝える機能も有する。
【0040】
図4にこの実行可否の判断基準を示すが、その判断基準は、要求の種類及び認証処理部43において認証処理に使用したデジタル証明書の種類である。上位装置10及び下位装置20が記憶しているデジタル証明書には、詳細は後述するが、短期証明書であり長期証明書よりも短い有効期間が設定されている公開鍵証明書である通常公開鍵証明書と、長期証明書であり短期証明書よりも長い有効期間が設定されている公開鍵証明書であるレスキュー公開鍵証明書があり、要求管理部44は、図3に示すように、通常公開鍵証明書による認証処理を行った場合には全ての動作を許可するが、レスキュー公開鍵証明書による認証処理を行った場合には証明書の設定動作のみを許可するようにしている。従って、レスキュー公開鍵証明書は、下位装置20に新たな通常公開鍵証明書を記憶させる場合のみに使用する証明書ということになる。
【0041】
証明書記憶部45は、上位装置の証明書記憶部35と同様に各種の証明書や私有鍵等の認証情報を記憶し、認証処理部33における認証処理に供する証明書記憶手段の機能を有する。ただし、記憶している証明書等は、後述するように認証管理部33とは異なる。
状態通知部46は、異常を検知したりユーザによる指示があったりした場合に上位装置10に対して下位装置20の状態を通知するコールを行う機能を有する。この通知は、上位装置10からの問い合わせに対する応答として送信してもよいし、HTTPSクライアント機能部41から上位装置10に通信を要求して送信してもよい。
【0042】
ログ通知部47は、下位装置20から上位装置10へのログの通知を行う機能を有する。その通知の内容としては、下位装置40の動作ログの他、例えば画像形成装置であれば画像形成枚数カウンタのカウント値、計量システムであればその計量値等が考えられる。この通知は緊急を要さないので、上位装置10からの問い合わせに対する応答として送信するとよい。
証明書設定部48は、上位装置10から受信する後述する通常公開鍵証明書等によって証明書記憶部45に記憶している証明書等を設定及び更新する証明書設定手段の機能を有する。
コマンド受信部49は、上述した各機能部46〜48以外の機能に係る要求に対応する動作を実行する機能を有する。この動作としては、例えば下位装置20が記憶しているデータの送信や、必要に応じてエンジン部の動作を制御することが挙げられる。なお、状態通知部46やログ通知部47は、コマンド受信部49が提供する機能の具体例として示したものであり、これらのような機能を設けることは必須ではない。
【0043】
次に、この通信システムにおける上位装置10と下位装置20との間の通信方式について説明する。図5はその通信方式の概要を示す説明図である。
この通信システムにおいて、上位装置10は、下位装置20と通信を行おうとする場合、まず下位装置20に対して通信を要求する。そして、従来の技術の項で図21又は図23を用いて説明したようなSSLプロトコルに従った認証処理によって下位装置20を正当な通信相手として認証した場合に、下位装置20との間で通信を確立させるようにしている。この認証処理は、SSLハンドシェイクと呼ばれる。ただし、図21に示したような相互認証は必須ではなく、図23に示したような片方向認証でもよい。
この処理において、下位装置20は自身の公開鍵証明書を上位装置10に送信して、認証を受ける。そして、相互認証を行う場合には上位装置10も下位装置20に自身の公開鍵証明書を送信して認証を受けるが、片方向認証の場合にはこちらの認証は行わない。
【0044】
以上の認証が成功すると、上位装置10は、下位装置20が実装するアプリケーションプログラムのメソッドに対する処理の依頼である要求を、構造化言語形式であるXML形式で記載したSOAPメッセージ60として生成し、HTTP(Hyper Text Transfer Protocol)に従ってHTTPリクエストとして下位装置20に送信する。このような要求は、RPC(Remote Procedure Call)と呼ばれる。
そして、下位装置20はこの要求の内容に応じた処理を実行し、その結果を応答のSOAPメッセージ70として生成し、HTTPレスポンスとして上位装置10に送信する。ここで、これらの要求と応答は、SSLハンドシェイクの処理において共有された共通鍵を用いて暗号化して送信し、通信の安全性を確保している。
【0045】
また、これらの要求と応答とによって、この通信システムは、上位装置10をクライアント、下位装置20をサーバとするクライアント・サーバシステムとして機能している。なお、逆に下位装置20から上位装置10に通信を要求し、下位装置20をクライアント、上位装置10をサーバとするクライアント・サーバシステムとして機能する場合もある。
また、RPCを実現するためには、上記の技術の他、FTP(File Transfer Protocol),COM(Component Object Model),CORBA(Common Object Request Broker Architecture)等の既知のプロトコル(通信規格),技術,仕様などを利用することができる。
【0046】
次に、上述した上位装置10及び下位装置20が上述した認証処理に用いる認証情報である各証明書や鍵の特性及び用途について説明する。図6は、(a)に下位装置20が認証情報として記憶している証明書及び鍵の種類を示し、(b)に上位装置10が認証情報として記憶している証明書及び鍵の種類を示す図である。
図1に示した上位装置10及び下位装置20は、図6に示すように、大きく分けて通常認証情報とレスキュー認証情報とを記憶している。そして、これらの認証情報は、それぞれ自分に関する認証情報である公開鍵証明書及び私有鍵と、通信相手に関する認証情報であるルート鍵証明書とによって構成される。
【0047】
また、例えば下位装置用通常公開鍵証明書は、証明書管理装置50が下位装置20に対して発行した通常公開鍵に、下位装置認証用通常ルート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書であり、短期証明書に該当する。
ここで、公開鍵証明書のフォーマットは、例えば図7に示したものを用いることができ、公開鍵そのものの他、証明書の発行者や証明書の有効期限、証明される対象(証明書の発行先の装置あるいは利用者)等の情報が記載されている。具体的には、例えばX.509と呼ばれるフォーマットに従って作成することができ、このフォーマットに従って作成された公開鍵証明書は、例えば図8に示すようなものになる。
この例においては、AがCAの識別情報を示し、Cが証明書の発行先の装置の識別情報を示す。これらは、それぞれ所在地、名称、機番あるいはコード等の情報を含む。また、Bが有効期間を示し、その開始日時と終了日時によって有効期間を指定している。
【0048】
なお、装置を特定する目的のみであれば、公開鍵証明書に付す識別情報に機番情報を含めることは必須ではないのであるが、ここで識別情報に機番情報と同一の情報を含めるようにしているのは、通信システムを運営する場合の要求に応えるためである。すなわち、この通信システムを装置の管理に使用する場合、装置の特定は機番情報によって行うことが多いが、識別情報が機番情報を含んでいない場合には、上位装置10側で識別情報と機番情報との対応関係をテーブル等として別途管理しておく必要が生じるのである。そして、このような管理を行う場合、下位装置20を新たに生産する度にデータを追加する必要があるし、下位装置20の数は数万台、数十万台あるいはそれ以上になる場合もあり、非常に大きな量のデータを管理する必要が生じるので、管理の負担が大きくなってしまう。
しかし、公開鍵証明書に付す識別情報に機番情報と同一の情報を含めておけば、認証処理において通信相手の機番を直接特定できる。従って、このようにすることにより、公開鍵証明書に付す識別情報と機番情報との対応関係を管理する必要がなくなり、管理負担を低減できるのである。
もちろん、このような機番情報を証明書に記載しなくてもよいし、逆に、この他に下位装置20の機種番号や登録ユーザ等の情報も記載するようにしてもよい。
【0049】
また、下位装置用通常私有鍵は、上記の通常公開鍵と対応する私有鍵、下位装置認証用通常ルート鍵証明書は、下位装置認証用通常ルート鍵に自身と対応するルート私有鍵を用いて自身で正当性を確認可能なデジタル署名を付したデジタル証明書である。
そして、下位装置20を複数設けた場合でも、各装置の通常公開鍵に付すデジタル署名は同じルート私有鍵を用いて付し、正当性確認に必要な通常ルート鍵証明書は共通にする。しかし、通常公開鍵証明書に含まれる通常公開鍵やこれと対応する私有鍵は、装置毎に異なる。
上位装置用通常公開鍵証明書と上位装置用通常私有鍵と上位装置認証用通常ルート鍵証明書も同様な関係である。
【0050】
そして、例えば上位装置10と下位装置20とが通常認証情報を用いて相互認証を行う場合には、上位装置10からの通信要求に応じて、下位装置20は下位装置用通常私有鍵を用いて暗号化した第1の乱数を下位装置用通常公開鍵証明書と共に上位装置10に送信する。上位装置10側では下位装置認証用通常ルート鍵証明書を用いてまずこの下位装置用通常公開鍵証明書の正当性(損傷や改竄を受けていないこと)を確認し、これが確認できた場合にここに含まれる公開鍵で第1の乱数を復号化する。この復号化が成功した場合に、上位装置10は通信相手の下位装置20が確かに下位装置用通常公開鍵証明書の発行先であると認識でき、その証明書に含まれる識別情報から装置を特定することができる。そして、特定した装置が通信相手としてふさわしいか否かに応じて認証の成功と失敗を決定することができる。
また、下位装置20側でも、上位装置10側で認証が成功した場合に送信されてくる上位装置用通常公開鍵証明書及び、上位装置用通常私有鍵で暗号化された乱数を受信し、記憶している上位装置認証用ルート鍵証明書を用いて同様な認証を行うことができる。
【0051】
ところで、これらの公開鍵証明書や私有鍵は、ROM22あるいはRAM23を構成するフラッシュメモリのような書き換え可能な不揮発性記憶手段に記憶させておくものである。従って、発明の開示の項で述べたように、このような記憶手段を含む部品を交換する場合には、記憶している公開鍵証明書や私有鍵は、取り外した旧部品と共に取り去られてしまう。そしてこのような場合、再度通常公開鍵証明書を用いた認証(通常証明書セットを用いた認証)を可能にするためには、取り去られた証明書や鍵を再度記憶させる必要がある。
【0052】
ここで、各装置が通常公開鍵証明書を用いた認証しか行えないとすると、この認証が行えなくなっている状態では、新たな通常公開鍵証明書等をネットワーク30を介して安全に対象の装置に送信する方法はないことになる。しかし、この実施形態の通信システムを構成する各装置は、このような事態に対処するためにレスキュー認証情報を記憶しており、通信相手を異なる2種類のデジタル証明書を用いて認証することができるようにしている。そして、レスキュー認証情報を用いることにより、必要な装置にネットワーク30を介して新たな通常公開鍵証明書等を安全に送受信できるようにしている。
【0053】
このレスキュー認証情報は、通常認証情報と概ね同様な構成となっている。例えば下位装置用レスキュー公開鍵証明書は、長期証明書であり、CAが下位装置に対して発行したレスキュー公開鍵に、上位装置認証用レスキュールート鍵を用いて正当性を確認可能なデジタル署名を付したデジタル証明書であり、上位装置用レスキュー私有鍵はそのレスキュー公開鍵と対応する私有鍵、下位装置認証用レスキュールート鍵証明書は、下位装置認証用レスキュールート鍵に自身を用いて正当性を確認可能なデジタル署名を付したデジタル証明書である。そして、これらのレスキュー公開鍵証明書とレスキュー私有鍵とレスキュールート鍵証明書とを合わせて、レスキュー証明書セットと呼ぶことにする。上位装置10側に記憶させるレスキュー認証情報についても同様とする。
【0054】
しかし、正規認証情報と大きく異なる点は、レスキュー公開鍵証明書の有効期間が、通常公開鍵証明書の有効期間よりも長く設定されている点である。
ここで、図9に通常公開鍵証明書の例を、図10にレスキュー公開鍵証明書の例を示す。
これらは、符号F及びIで示すように、発行先の装置の識別情報が同一であり、同じ装置に対して発行された公開鍵証明書である。しかし、通常公開鍵証明書の有効期間は、符号Eで示すように、2003年1月1日午前0時から2004年1月1日午前0時までの1年間としている一方、レスキュー公開鍵証明書の有効期間は、符号Hで示すように、2000年1月1日午前0時から2050年1月1日午前0時までの50年間としている。
また、証明書の発行者は、同じxxx社のCAであるが、通常公開鍵証明書については符号Gで示すように「RegularCA」、レスキュー公開鍵証明書については符号Dで示すように「RescueCA」というように、異なるCAとしている。
【0055】
このような有効期間の長いレスキュー公開鍵証明書は、有効期間の短い通常公開鍵証明書と比べた場合には安全性が若干劣る。しかしながら、このようなレスキュー公開鍵証明書は、有効期限が長い分、有効期限切れにより使用不能になってしまう事態も生じにくい。従って、証明書の記憶領域を備える部品の製造時に、予めレスキュー認証情報を記憶させておくようにすれば、レスキュー公開鍵証明書の有効期間内は、通信相手を認証することができる。そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができる。従って、この通信経路を利用して、通信相手に新しい通常公開鍵証明書を通信相手との間で送受信し、設定することが可能となる。従って、部品を長期間ストックしておき、交換が必要になった場合に速やかにこれに対応することができる。
【0056】
なお、レスキュー認証情報を用いて認証処理を行った場合に、通常公開鍵証明書を始めとする正規認証情報の更新のような限られた要求のみ実行を許可するようにすれば、有効期間を長くしたために若干安全性が低下したとしても、大きな問題にはならない。
また、この点を考慮すると、レスキュー公開鍵証明書の有効期間経過後には部品に再度レスキュー公開鍵証明書を設定し直す必要が生じてしまうので、レスキュー公開鍵証明書の有効期間は長い方が好ましい。具体的には、例えば記憶させる装置の製品寿命よりも長い有効期間を設定するとよい。この製品寿命は、装置の想定運用期間あるいは想定動作期間であり、開発時に想定している使用期間や想定耐用年数、装置の品質保証期間等から定めることができる。
また、レスキュー公開鍵証明書の有効期間を、装置をメンテナンスしながら正常に動作させられると想定される期間よりも長く設定すれば、レスキュー公開鍵証明書は装置の動作中には有効期限が切れない証明書であるということができる。従って、装置の動作中は、常にレスキュー公開鍵証明書を用いた認証(レスキュー証明書セットを用いた認証)が可能な状態を保つことができる。従って、一旦レスキュー公開鍵証明書を記憶させて製造した部品に対し、ストック中にこの証明書の有効期限が切れて、これを更新する必要が生じることもない。
【0057】
また、上記の製品寿命や装置の動作期間よりも極めて長い有効期間を定めるようにすれば、なおよい。図8に示した例では、有効期間を50年に設定しており、通常の装置であればこの程度で十分と考えられるが、これはX.509フォーマットに従って設定できる有効期間の最大が50年であるためこのようにしただけで、さらに長い期間、例えば100年や数百年を設定してもよいことはもちろんである。このように有効期間を定めた場合、有効期間の終期は、単に公開鍵証明書のフォーマット上の要求により記載したものであり、レスキュー公開鍵証明書の有効期限は事実上ないものと考えることができる。また、対象の装置によっては、20年や30年程度あるいはそれ以下の有効期間であっても、同様に考えることができる場合もある。
さらにまた、たとえレスキュー公開鍵証明書の有効期間が製品寿命より短かったとしても、通常公開鍵証明書の有効期間よりも長ければ、通常公開鍵証明書を記憶させておく場合よりも部品のストック可能期間を延ばすことができるという効果を得ることはできる。
通常公開鍵証明書の有効期間については、安全性を考慮して適当な期間を定めればよいが、この期間は、製品寿命よりも短く、また装置の動作中に有効期限が切れるような期間となることが多い。
【0058】
また、ここでは、レスキュー公開鍵証明書の書誌情報には装置の識別情報を記載せず、同じ階位の装置(図1あるいは図20に示した例では、上位装置と下位装置の階位が存在するものとする)には、全て同じレスキュー公開鍵証明書を記憶させることができるようにしている。この場合、同じ階位の各装置を個別に区別する必要がないので、証明書に含まれるレスキュー公開鍵及びこれと対応するレスキュー私有鍵も含めて、全く共通のものでよい。そして、通信相手のレスキュー公開鍵証明書が全て同じであることから、ルート鍵証明書については、ある階位の装置の通信相手となる全ての装置について共通となる。すなわち、下位装置20を複数設けた場合でも、全ての下位装置20に同じレスキュー認証情報を記憶させることになる。
これは、上位装置10のレスキュー認証情報についても同様である。
そして、通常公開鍵証明書とデータ形式を統一化するため、図10に示した例において、発行先装置の機番として0を記載してレスキュー公開鍵証明書であることを示すようにしている。なお、「Subject」の項目を空白としてこのことを示すことも考えられる。
【0059】
このようにすることは必須ではないが、このように、レスキュー認証情報を同じ階位の装置について全て共通にできるようにすると、証明書の記憶領域を備える部品の製造時に、その部品を装着する装置の機種に応じて定まる階位に対応するものを画一的に記憶させてしまうことができる。そして、このようなレスキュー認証情報を記憶しており、通常認証情報を記憶していない部品であれば、製造時に装置の識別情報が必要ないため、装置の識別情報によらず共通に使用可能な部品として生産することができる。
【0060】
なお、レスキュー公開鍵証明書には装置の識別情報を付さないようにする場合、レスキュー公開鍵証明書を用いた認証を行った場合でも、通信相手の装置を具体的に特定することはできない。しかし、通信相手についてある程度の情報は得ることができる。
すなわち、例えばあるベンダーが自社製品のうち下位装置20に該当する装置全てに下位装置用のレスキュー証明書セットを記憶させ、その通信相手となる上位装置10に該当する装置全てに上位装置用のレスキュー証明書セットを記憶させておけば、認証が成功した場合、下位装置20は、自己の記憶している上位装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手が同じベンダーの上位装置10であることを認識できるし、逆に上位装置10も自己の記憶している下位装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手は同じベンダーの下位装置20であることを認識できる。
【0061】
従って、通信を要求した装置あるいは要求してきた装置が通信相手として適当な装置か否かについて、識別情報を参照できなくてもある程度の判断を行うことができる。
そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができるので、その後機番情報等を交換して通信相手を特定することも可能である。
【0062】
ところで、サーバとして機能する下位装置20は、SSLハンドシェイクの際に、通信を要求してきた相手を識別できないため、基本的には全ての相手に同一の公開鍵証明書を送信することになる。しかし、この通信システムにおいては、状況に応じて通常公開鍵証明書とレスキュー公開鍵とを使い分ける必要がある。そこで、次にこの使い分けのための構成について図11を用いて説明する。
SSLプロトコルにおいては、サーバは、クライアントから通信要求があった時点ではクライアントの状態を知ることができないため、必然的に、特定のURL(Uniform Resource Locator)にアクセスされた場合には常に同じ公開鍵証明書を提供することになる。従って基本的には、通常公開鍵証明書を複数持ち、通信相手の持つ通常ルート鍵証明書の種類に合わせて適当なものを選択して送信するといった構成を取ることはできない。しかし、通信要求を受け付けるアドレスが異なる場合には、アドレス毎に異なる公開鍵証明書を返すことも可能である。このアドレスは、例えばURLによって定めることができる。
【0063】
従ってここでは、図11に示すように、上位装置10及び下位装置20にそれぞれ、通常公開鍵証明書による認証を行う通常URLとレスキュー公開鍵証明書による認証を行うレスキューURLとを設け、通信を要求する側(クライアントとして機能する側)が、要求する認証の種類に応じていずれかのURLを選択的に指定して通信要求を送るようにしている。これらのURLは、IPアドレスやポート番号(いずれか一方でもよい)を変えることにより、物理的には同じ装置のURLであっても、論理的には異なる装置のURLとして取り扱うことができるようにしている。すなわち、いわゆるバーチャルサーバの機能を実現するためのものである。
【0064】
このようにした場合、通信を要求される側(サーバとして機能する側)は、返す証明書を通信要求を受け付けたURLによって区別し、通常URLで受け付けた場合には通常公開鍵証明書を返し、レスキューURLで受け付けた場合にはレスキュー公開鍵証明書を返すことができる。
なお、通信を要求するクライアントの側では、どのURLに対して通信要求を送ったかがわかるので、相互認証を行う場合にはURLに応じた適切な公開鍵証明書を選択して送信することができる。
【0065】
従って、この通信システムにおいては、上位装置10と下位装置20との間で基本的には通常公開鍵証明書を用いた認証を行いながら、これが部品の交換によって取り去られた場合にも、新たな部品が装着された後でレスキュー公開鍵証明書を用いた認証を行い、安全な通信経路を確保することができる。レスキュー公開鍵証明書を用いた認証であっても、共通鍵の共有は通常公開鍵証明書の場合と同様に可能であるためである。そして、この通信経路を用いて上位装置10から下位装置20に設定用の通常認証情報を送信して記憶させることにより、再度通常認証情報を用いた認証が可能な状態に復帰させることができる。
【0066】
また、レスキュー公開鍵証明書を用いた認証であっても、上述のようにある程度相手の装置を特定することができるので、例えば自社の製造した装置のみに通常公開鍵証明書を送信するようにする等の制限をかけることができ、不正な装置に通常公開鍵証明書を送信して記憶させてしまうことを防止できる。
以上のように、この通信システムにおいては、通常認証情報に加えてレスキュー認証情報も使用することにより、認証に必要な証明書を記憶する部品を交換する必要が生じた場合でも、容易かつ速やかに正常な認証が行える状態に容易に回復させることができる。
【0067】
なお、図6に示した認証情報は、上位装置10と下位装置20とが相互認証を行う場合には全て記憶している必要があるが、下位装置20がサーバとして機能し、かつ上位装置10が下位装置20を認証する片方向認証だけを行う場合には、一部の証明書等については記憶しておく必要はない。通常認証情報とレスキュー認証情報の双方について、下位装置20においては、上位装置認証用ルート鍵証明書は不要となるし、上位装置10においては、上位装置用公開鍵証明書と上位装置用私有鍵が不要となる。
【0068】
次に、下位装置20や上位装置10において、上述した認証情報を記憶する記憶領域を設けるハードウェアについて説明する。
下位装置20や上位装置10において、このような記憶領域は、不揮発性の記録媒体であれば設計上はどこにでも設けることができる(ただし、通常証明書セットを記憶する領域は書き換え可能な記録媒体に設けることが好ましい)。例えば、下位装置20において、通常証明書セットを記憶する記憶領域をRAM23に、レスキュー証明書セットを記憶する記憶領域をROM22に設けることもできる。
しかしながら、通常証明書セットとレスキュー証明書セットの記憶領域を別々に交換可能な部品に設けると、以下のような問題が生じる。図12を用いてこの問題について説明する。図12は、この実施形態の比較例における、証明書の記憶領域を設ける交換部品の構成及びその問題点について説明するための図である。
【0069】
比較例として、図12(a)に示すように、別々に交換可能な部品Xと部品Yにそれぞれ通常証明書セット記憶領域とレスキュー証明書セット記憶領域を設けた構成を考える。すると、なお、部品Xについては、製造時に通常公開鍵証明書を記憶させておいてもストック中に有効期間が過ぎてしまう可能性があるため、通常証明書セットは記憶させない状態で製造することになる。一方、部品Yについては、レスキュー公開鍵証明書であれば有効期間が過ぎてしまうことはあまりないと想定し、その機種や階位に適したレスキュー証明書セットをあらかじめ記憶させた状態で製造するようにすることができる。
【0070】
そして、下位装置20′において部品Xと部品Yが破損等してこれらを交換した場合(部品Xのみを交換した場合でも同じ)、(b)に示すように、下位装置20′には、レスキュー証明書セットのみが記憶され、通常証明書セットは記憶されていない状態となる。この状態において、上位装置10がこの下位装置20′をレスキュー証明書セットに含まれる下位装置用レスキュー公開鍵証明書を用いた認証処理によって認証すると、通常証明書セットを下位装置20′に送信し、これを通常証明書セット記憶領域に設定させる。そしてこの後は、この通常証明書セットに含まれる下位装置用通常公開鍵証明書を用いて認証可能な状態となる。
【0071】
しかし、その後(c)に示すように下位装置20′から部品Xを取り外して部品Xと同様な記憶領域を有する偽部品X′を装着した場合、(b)の場合と同様に下位装置20′にレスキュー証明書セットのみが記憶された状態となるため、上位装置10は再度下位装置20′に通常証明書セットを送信して記憶させてしまう。そして、証明書の記憶領域を設ける部品自体はメモリカード等の汎用性の高い部品とすることも多いため、正規の部品Xと同様な記憶領域を設けることのできる偽部品X′を入手することは容易である場合が多い。従って、偽部品への交換を繰り返すことにより、ユーザは正規の通常証明書セットを記憶させた偽部品X′を大量に取得し、場合によっては成りすまし等に悪用することも可能になってしまうという問題があるのである。なお、部品Yさえ正規のものを使用すれば、正規の部品Xを一切使用しなくても上記と同様なことが可能になってしまう。
【0072】
次に、この実施形態の構成及びその効果について、図13を用いて説明する。図13は、下位装置20における、証明書の記憶領域を設ける交換部品の構成及びその効果について説明するための図である。
この実施形態の下位装置20においては、上記の問題を解決するため、図12(a)に示した比較例の構成とは異なり、図13(a)に示すように、通常証明書セットを記憶する記憶領域と、レスキュー証明書セットを記憶する記憶領域とを両方とも、交換可能な最小単位の交換部品上に設けている。しかし、このような構成を採る場合でも、証明書の特性は変わらないので、この部品Aを、レスキュー証明書セットのみ予め記憶させ、通常証明書セットは記憶させない状態で製造することになる点は、図12(a)の場合と同様である。
【0073】
ここで、下位装置20において部品Aが破損等してこれらを交換した場合、図13(b)に示すように、下位装置20には、レスキュー証明書セットのみが記憶され、通常証明書セットは記憶されていない状態となる。そして、図12(b)の場合と同様に、上位装置10がこの下位装置20を下位装置用レスキュー公開鍵証明書を用いた認証処理によって認証すると、通常証明書セットを下位装置20に送信して設定させ、下位装置用通常公開鍵証明書を用いて認証可能な状態とする。
【0074】
しかし、その後図13(c)に示すように下位装置から部品Aを取り外して部品Aと同様な記憶領域を有する偽部品A′を装着した場合でも、偽部品A′は正しいレスキュー証明書セットを記憶していない。正当なベンダー以外は正しいレスキュー証明書セットを知らないので、正しいレスキュー証明書セットを記憶した偽部品A′を製造することができないためである。従って、図12(c)の場合とは異なり、下位装置20は上位装置10に認証を受けることができないので、上位装置10が下位装置に通常証明書セットを送信して記憶させてしまうこともない。従って、部品Aをハードウェアとしては汎用性の高い部品で構成したとしても、通常証明書セットを偽部品A′に不正に設定されてしまうことを防止できる。
部品Aを取り外して別の正規の部品Aに交換した場合には、新たな通常証明書セットがそこに記憶されることになるが、正規の部品Aであれば、ベンダー側が流通をコントロールすることが可能であるので、ユーザに必要以上の数の部品Aを供給しないようにすればよい。
【0075】
この通信システムにおいては、以上のような構成を採ることにより、通常公開鍵証明書を不正に取得されることを防止し、成りすまし等の危険を低減して通信の高い安全性を維持することができる。
なお、ここでいう交換可能な最小単位の交換部品とは、ユーザの作業やサービスマンによる出張メンテナンス等の作業によって交換可能な部品のうち、交換する場合にはその全部を交換する必要がある部品を指すものとする。例えばROM22やRAM23を構成するフラッシュメモリやNVRAM等を備えたメモリカードやメモリユニット、あるいはCPU21と共に書き換え可能な不揮発性メモリを搭載したCPUボード等が考えられる。しかし、例えば、CPUボード上に複数のメモリチップが搭載されており、工場等で特殊な設備を使用すればこれらを個別に交換可能であったとしても、ユーザの作業やサービスマンによる出張メンテナンス等の作業では通常交換できない場合には、それは交換可能とは言わないものとする。
【0076】
次に、このような証明書セットの記憶領域を設けた部品A及びその部品Aを装着した下位装置20の製造工程について説明する。
まず、これらの製造工程の概略を図14に示す。この図においては、証明書セットの設定に関する部分を中心に示し、それ以外の部分については大幅に簡略化して示している。
【0077】
この図に示すように、下位装置20を製造する場合、まず部品製造工程において証明書セットの記憶領域を設けた部品Aを製造するが、この工程では、部品Aを組み立て、検査して、その後工場のソフトウェア複写装置130によって下位装置20用のレスキュー証明書セットを書き込む。この時点では、ソフトウェア複写装置130と部品Aとの間でネットワークを介した安全な通信経路を設けることはできないし、レスキュー証明書セットは漏洩した場合の影響が通常証明書セットの場合より大きいため、書き込みは専用の冶具を用いて直接行うようにしている。またこの時、下位装置20の制御に使用するソフトウェアのうち部品Aに記憶させるものも同時に書き込むようにするとよい。
以上で部品Aが完成し、これを部品として流通させる場合には、梱包した上出荷することになる。
ここで、レスキュー公開鍵証明書に装置の識別情報を記載しない場合には、書き込むべきレスキュー証明書セットは部品Aを装着する装置の機種や階位に応じて定まるので、これを予めソフトウェア複写装置130に記憶させておけばよい。また、部品Aが規格化されたメモリカード等の場合には、組み立てる必要がない場合もある。
【0078】
一方、部品Aを下位装置20の製造に使用する場合には、レスキュー証明書セットを書き込んだ部品Aを製品組み立て工程に回し、これを組み立て中の下位装置20の本体部に装着する。そして、下位装置20の組み立てが完了した後、その機能検査を行い、合格した装置に機番を付与する。その後、その機番を装置の識別情報として通常公開鍵証明書に含む通常証明書セットを、証明書書き込み装置160によって下位装置20に記憶させ、また装置の機番情報や初期設定値もこの工程で記憶させる。その後、外観を検査し、梱包して出荷する。
以上の工程で下位装置20を製造することができる。また、記憶させるレスキュー証明書セットは異なるが、上位装置10についても同様な工程で製造することができる。なお、部品製造工程と製品組み立て工程とは、別々の工場で行われることが多い。
【0079】
また、図15に部品Aに各証明書セットを記憶させる工程の説明図を示す。
この図に示すように、部品Aには部品製造工程においてレスキュー証明書セットのみを記憶させ、通常証明書セットは記憶させない。そしてこの状態で、製品組み立て工程で新しい装置の組み立てに用いる部品と、市場に販売済の装置のための交換部品(サービスパーツ)とのどちらの用途にも使用できる部品として完成する。
そして、部品Aが装置の組み立て工場において製品組み立て工程で装置に装着された場合には、その装置が検査に合格し、装置に機番が付与された後で、証明書書き込み装置160によって通常証明書セットが書き込まれる。このとき、機番情報入力装置161から証明書書き込み装置160に書き込み対象の装置の機番を入力し、証明書書き込み装置160がその機番の情報を識別情報として含む通常証明書セットを取得して書き込むことになる。この通常証明書セットは、通常公開鍵証明書を管理するCAである証明書管理装置50が発行するものである。
【0080】
なおこのとき、証明書書き込み装置160と下位装置20とを接続した上で、証明書書き込み装置160から下位装置20のレスキューURLに通信を要求し、下位装置20に記憶しているレスキュー証明書セットを用いて、SSLによる認証処理を行う。そして、証明書書き込み装置160が下位装置20が正当な装置であると認証した場合に証明書設定要求と共に通常証明書セットを送信して部品Aの通常証明書セット記憶領域に書き込ませるようにしている。
【0081】
ここで、通常証明書セットを書き込む際に下位装置20側で実行する処理を図16のフローチャートに示す。
下位装置20は、通信相手がレスキューURLに通信を要求してきた場合、図16のフローチャートに示す処理を開始する。
この処理においては、まずステップS201で、通信相手(ここでは証明書書き込み装置160)に認証を受けるために下位装置用レスキュー公開鍵証明書を、下位装置用レスキュー私有鍵で暗号化した第1の乱数と共に通信相手に送信する。この処理は、図23のステップS21及びS22の処理に相当する。
【0082】
通信相手は、下位装置20が送信した証明書と乱数を受信すると、これを用いて認証処理を行い、その結果を応答として返してくる。また、認証が成功していれば、共通鍵の種を下位装置20に送信すると共に共通鍵を作成して以後の通信に使用するようにする。ここでの認証には、下位装置認証用レスキュールート鍵証明書を使用し、この処理は図23のステップS12乃至S17の処理に相当する。
下位装置20は、この認証結果を受け取ると、ステップS202で認証が成功したか否か判断し、失敗であればそのまま処理を終了するが、成功していればステップS203に進んで受信した共通鍵の種を用いて共通鍵を作成して以後の通信に使用するようにする。これらの処理は、図19のステップS25及びS26の処理に相当する。
【0083】
その後、ステップS204で要求の受信を待ち、要求を受信するとステップS205に進む。そして、図4を用いて説明したように、下位装置20の要求管理部44は、レスキュー公開鍵証明書を用いた認証を行った場合には、証明書設定動作のみを許可するようにしているので、ステップS205で受信した要求が証明書設定要求か否かを判断する。そして、証明書設定要求でなければその要求は無視してステップS204に戻って次の要求を待つ。ここで、要求を受け付けられない旨の応答を返すようにしてもよい。
【0084】
ステップS205で証明書設定要求であれば、ステップS206に進んで証明書設定要求と共に受信(通信相手から取得)した証明書セットを部品Aの通常証明書セット記憶領域に記憶させて図6(a)に示した通常証明書セットをその内容に設定する。この処理において、下位装置20のCPU21が証明書設定手段として機能する。
その後、ステップS207で設定結果を応答として送信元に通知して処理を終了する。
下位装置20がこのような処理を実行することにより、証明書書き込み装置160が、下位装置20が通常証明書セットの書き込み対象であることについて少なくとも最低限の確認を行うことができるので、全く異なる装置に誤って通常証明書セットを送信してしまうような事態を防止できる。
【0085】
また、証明書書き込み装置160側にもレスキュー証明書セットを記憶させ、認証処理において下位装置20との間で相互認証を行うようにしてもよい。この場合に使用するレスキュー証明書セットは、上位装置10に記憶させるものと同じものになり、下位装置20側の認証処理も、図21に示した処理に対応したものになる。そして、このようにすれば、下位装置20側でも、不正な証明書書き込み装置から送られてくる通常証明書セットを設定してしまうことがないようにすることができる。
さらに、通信要求について、下位装置20側から証明書書き込み装置160に対して通信要求を行うようにすることも考えられる。この場合でも、証明書書き込み装置160と下位装置20とがレスキュー公開鍵証明書を用いた認証処理を行い、これが成功した場合に証明書書き込み装置160が下位装置20に通常公開鍵証明書を送信して設定させることは、上述の処理の場合と同様である。
【0086】
一方で、図15において、部品Aがサービスパーツとして出荷され、設置先で稼動中の下位装置20に装着された場合には、その下位装置20と対応する上位装置10によって通常証明書セットが書き込まれることになる。このとき、機番情報入力装置171から上位装置10に書き込み対象の装置の機番を入力し、上位装置10がその機番の情報を識別情報として含む通常証明書セットを証明書管理装置50に発行させ、これを取得して下位装置20に設定させることになる。下位装置20の機番等の識別情報については、上位装置10からの要求に応じて下位装置20から上位装置10に送信させるようにしてもよい。
【0087】
なおこのとき、上位装置10から下位装置20のレスキューURLに通信を要求し、下位装置20に記憶しているレスキュー証明書セットを用いて、SSLによる認証処理を行う。そして、上位装置10が下位装置20は正当な装置であると認証した場合に通常証明書セットを送信して部品Aの通常証明書セット記憶領域に設定させるようにしている。この場合に下位装置20側で行う処理は、図16のフローチャートに示したものと同じものである。もちろん、相互認証を行うようにしてもよい。このことによる効果は、証明書書き込み装置160によって書き込む場合と同様であるが、どのような装置と接続されるかわからない出荷後の方が、接続対象が限定される工場内においてよりも安全性向上の要求は強いと言える。
また、下位装置20が上位装置10に通信要求を行うようにしてもよいことも、上述の証明書書き込み装置160によって書き込む場合と同様である。
【0088】
以上の説明から明らかなように、下位装置20に対して、工場での生産時と市場での部品交換時とにおいて全く同じ手順で通常公開鍵証明書を記憶させることができる。
なお、下位装置20に、その機番情報を装置の識別情報として付された通常公開鍵証明書を記憶させるようにする場合であっても、機番は、装置の組み立てが完了し、機能の検査に合格した装置に付すようにしたいという要求がある。なぜなら、検査前に機番を付してしまうと、検査に不合格となった装置の機番が欠番になってしまい、このような欠番があるとその後の製品管理に不都合があるためにである。
【0089】
従って、この要求を満たしつつ、機番情報を装置の識別情報として付された公開鍵証明書を装置の製造工程で記憶させるとすると、必然的に組み立てが全て完了した状態で行うことになる。そして、このような状態においては、レスキュー証明書セットの場合のように特殊なインタフェース(専用の冶具)を用いて証明書を記憶させるよりも、下位装置20が備え、かつ通常使用するインタフェースを介して記憶させる方が好ましい。デザインや機能上の制約から、特殊なインタフェースの接続口は、作業しやすい位置や構成では設けにくいためである。
【0090】
ここで説明した下位装置20は、ネットワークを介して通常証明書セットを書き込むことが可能であるので、装置の組み立て完了後であっても、装置に備えているネットワークケーブルの接続I/Fを介して証明書書き込み装置160と接続し、通常証明書セットの書き込み作業を行うことができる。従って、効率のよい作業を行うことができるし、作業中に装置を破損等してしまう危険も極めて少ない。また、この書き込み工程において通信を暗号化できるので、通常証明書セットを安全に記憶させることができる。
【0091】
なお、通常公開鍵証明書とレスキュー公開鍵証明書とでは用途も機能も異なるため、図15に示したように、これらの証明書は別々のCAが発行するようにすることが好ましい。
また、ここではレスキュー公開鍵証明書は同じ階位の装置全てに同じものを記憶させるため、レスキュールート私有鍵が漏洩するとセキュリティの維持が著しく困難になるので、秘密保持を特に厳重に行う必要がある。一方で、各装置について個別に異なる証明書を作成して記憶させる必要はない。そこで、安全性を重視し、外部からアクセス不能なCAを用いるとよい。
【0092】
一方、通常公開鍵証明書は必要に応じて更新できるため、通常ルート私有鍵が漏洩したとしても、これを更新すればセキュリティを保つことができる。そして、装置毎に個別に証明書を作成して記憶させる必要があることから、インターネット等のオープンネットワークに接続したCAを用いるとよい。
なお、CAをさらに細分化し、下位装置用の証明書を発行するCA,上位装置用の証明書を発行するCA等、証明書を発行する対象の装置の階位に応じてCAを分けるようにしてもよい。
また、通常公開鍵証明書とレスキュー公開鍵証明書とで全く形式の異なるデジタル証明書を使用することも可能である。
【0093】
次に、上述した製品組み立て工程において通常証明書セットを下位装置20に設定するために使用する設備について説明する。図17はその概略構成を示すブロック図である。
この図に示すように、製品組み立て工程を行う生産工場Eには、通常証明書セットを設定するための設備として、生産管理システム140,通信端末150,証明書書き込み装置160が設置されている。
そして、生産管理システム140は、上位装置10や下位装置20等の装置の日々の生産台数を管理する。
【0094】
通信端末150は、証明書データベース(DB)154a,入力装置156,表示装置157を備えている。そして、生産管理システム140からその日の機種別の生産台数及び付与予定の機番の情報(ここでは機種コードとシリアル番号とを含めた情報)を取得する。また、その情報に基づいて、通常公開鍵証明書を発行するCAである証明書管理装置50に生産予定の装置に記憶させるべき通常証明書セットを発行させ、これを入手して証明書DB154aに記憶させる。
証明書書き込み装置160は、機番情報入力装置161を備えており、装置の生産時にその機番情報入力装置161から生産中の装置の機番の入力を受け付ける。そして、これが入力された場合に、その機番に対応する証明書を通信端末150から入手し、それを対応する装置へ送信してその装置の不揮発性メモリに設けた通常証明書セット記憶領域に設定させる。下位装置20を生産する場合には、部品Aに設けた記憶領域に設定させることになる。
【0095】
次に、図18に生産工場Eにおける通信端末150および証明書書き込み装置160の周辺の状況の概略を示す。
生産工場Eにおいては、通信端末150は、セキュリティ面を考慮して管理者室Fに設置している。そして、その管理者室Fは、特定の管理者しか入れないように、ドアGに鍵をかけるようにしており、通信端末150は、特定のIDとパスワードが入力された場合にのみ操作できるようにしている。
またこの例では、生産工場Eには上位装置10の生産用ライン1001と下位装置20の生産用ライン1002とを設けている。そして、その各生産用ライン毎に証明書書き込み装置160(160a,160b)を設置している。
【0096】
そして、各証明書書き込み装置160にはそれぞれ、機番情報入力装置161(161a,161b)と接続するための機番情報入力用I/F162(162a,162b)、および生産する装置(上位装置10及び下位装置20)と接続するための書き込み用I/F165(165a,165b)がそれぞれ接続されている。
このような生産ラインにおいては、例えば下位装置20を生産する場合、機能検査に合格した装置に識別番号を付与する際に、定格銘板を貼付する。この定格銘板の例を図19に示すが、定格銘板には、定格電圧,消費電力等の情報と共に、装置の機番を記載している。そしてさらに、この機番の情報を示すバーコードBCも記載している。
【0097】
そして、通常証明書セットの設定工程においては、まず書き込み用I/F165としてクロスケーブルを用いて証明書書き込み装置160と設定対象の下位装置20を接続する。ここでクロスケーブルを用いるのは、生産される各装置は初期値として同じIPアドレスを有しており、証明書書き込み装置160とLAN接続すると、IPアドレスが重複してしまうためである。
続いて機番情報入力装置161としてバーコードリーダを用い、定格銘板上のバーコードBCを読み取って作業対象の装置の機番の情報を証明書書き込み装置160に入力する。すると、証明書書き込み装置160がその機番に対応する証明書を通信端末150から入手し、書き込み用I/F165を介して接続する下位装置20へ送信してその装置の部品Aに設けた通常証明書セット記憶領域に設定させる。
以上の作業及び処理により、生産する各下位装置20に、その機番情報を装置の識別情報として付された通常公開鍵証明書を簡単な作業で記憶させることができる。
【0098】
なお、以上説明した実施形態では、上位装置10と下位装置20を始めとする各装置間で、図21あるいは図23を用いて説明したようなSSLに従った認証を行う場合の例について説明した。しかし、この認証が必ずしもこのようなものでなくてもこの実施形態は効果を発揮する。
SSLを改良したTLS(Transport Layer Security)も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。
【0099】
また、上述した実施形態では、有効期間の短い通常公開鍵証明書と、有効期間の長いレスキュー公開鍵証明書とを用いる例について説明したが、前者はセキュリティ強度が高い証明書、後者はセキュリティ強度が比較的低い証明書と捉えることもできる。
一般に、セキュリティ強度が高い証明書には、多くの情報を記載する必要があったり、輸出制限があったり特殊な認証処理プログラムが必要であったりして利用可能な環境が限られていたりするため、全ての装置に同じように記憶させて認証処理に用いることが難しい場合がある。一方で、セキュリティ強度が低い証明書であれば、このような制限が少なく、全ての装置に同じように記憶させて認証処理に用いることが比較的容易であると考えられる。
【0100】
そこで、セキュリティ強度が低い証明書を記憶させた装置を製造・販売した上で、利用環境に合わせてセキュリティ強度が高い証明書を事後的に記憶させることができるようにしたいという要求がある。例えば、システムの運用者によって種々に認証処理の内容を工夫したり信頼性の高いCAを選択したりしてセキュリティの向上を図る場合も考えられるが、このような場合、ある装置を1つのシステムから他のシステムに移動(単に設定を変更するのみの場合も含む)させる場合、通常の認証処理に使用する証明書を入れ換える必要があることが考えられる。また、セキュリティの高い証明書に後で欠陥が発見され、認証処理の方式を変更する必要が生じることも考えられる。
【0101】
このような場合に、上述した実施形態の構成を利用し、セキュリティ強度が高い証明書を記憶する記憶領域とセキュリティ強度が低い証明書を記憶する記憶領域とを、交換可能な最小単位の交換部品に設けることにより、セキュリティ強度が高い証明書を不正に取得されることを防止し、成りすまし等の危険を低減して通信の高い安全性を維持することができる。また、製造する部品に種々の環境で共通に利用できるようなセキュリティの比較的低い証明書を記憶させておくようにすることにより、その部品を種々の環境で共通に利用することができるので、部品供給が容易になる。
【0102】
また、上述した実施形態では、通常公開鍵証明書に装置の識別情報を記載する例について説明したが、通常公開鍵証明書にも装置の識別情報を含めず、同じ階位の装置には、全て同じ通常公開鍵証明書を記憶させるようにしてもよい。このようにしたとしても、通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けた後で機種機番情報等を交換して通信相手を特定することが可能であることは、レスキュー公開鍵証明書の場合と同様である。そして、このようにしたとしても、有効期限が短い分だけレスキュー公開鍵証明書よりも高い安全性を得ることができる。
【0103】
また、上述した実施形態では、証明書管理装置50を上位装置10と別に設ける例について説明したが、これと一体として設けることを妨げるものではない。この場合、証明書管理装置50の機能を実現するためのCPU,ROM,RAM等の部品を独立して設けてもよいが、上位装置10のCPU,ROM,RAM等を使用し、そのCPUに適当なソフトウェアを実行させることにより、証明書管理装置50として機能させるようにしてもよい。
このような場合において、証明書管理装置50と、これと一体になっている上位装置10との間の通信には、ハードウェアを証明書管理装置50として機能させるためのプロセスと、ハードウェアを上位装置10として機能させるためのプロセスとの間のプロセス間通信を含むものとする。
【0104】
さらに、上述した実施形態では、証明書管理装置50がルート鍵やデジタル証明書を自ら作成する例について説明したが、証明書管理装置50は鍵や証明書の管理を専門に行い、他の装置からルート鍵やデジタル証明書の供給を受けてこれらを取得するようにしてもよい。
【0105】
また、上述した実施形態では、通信システムを上位装置10と下位装置20のみによって構成したが、他の装置を含めて構成するようにしてもよい。例えば、上位装置10と下位装置20との間の通信を仲介する仲介装置を設け、上位装置10と下位装置20とがこの仲介装置を介して要求や応答を授受するようにしてもよい。あるいは、上位装置10の更に上位の装置を設けてもよい。この場合には、上位装置10を「下位装置」、その更に上位の装置を「上位装置」と見れば、これらの装置についても上述した実施形態の場合と同様な取り扱いが可能である。
【0106】
また、従来から、通信機能を備えたプリンタ,ファクシミリ(FAX)装置,デジタル複写機,スキャナ装置,デジタル複合機等の画像処理装置を被管理装置とし、これらの被管理装置と通信可能な管理装置によってこれらの被管理装置を遠隔管理する遠隔管理システムが提案されている。
例えば、画像形成手段を備えた画像処理装置については、感光体静電プロセスを用いて普通紙に画像形成するものが一般的であるが、このような感光体静電プロセスを行う機構からは、トラブル(異常)が発生する割合も高く、更に性能維持のための定期的なオーバホールの必要性から、保守管理のサービス体制を採っている。
そして、この保守管理を充実させる目的で、画像形成装置を被管理装置とする遠隔管理システムとして、画像形成装置の内部又は外部に通信装置を設け、画像形成装置とサービスセンタ(管理センタ)に設置された管理装置とを公衆回線(電話回線)を介して接続し、画像形成装置の異常発生時にその旨を管理装置に通報するようにしたものが既に開発され運用されている。
【0107】
上述した実施形態は、このような遠隔管理システムにも適用可能であり、この場合、被管理装置を下位装置とし、被管理装置を管理する管理装置やユーザ環境内にあって複数の被管理装置の情報を取りまとめるような装置を上位装置とするとよい。
遠隔管理を行う場合には、被管理装置の近くに管理装置の操作者がいないことが多いため、被管理装置の特定は、通信によって行う必要がある。そして、通信によって特定された被管理装置が確かにその装置であることを保証する仕組みが必要になる。従って、上述の実施形態で説明したように通常公開鍵証明書を用いた認証を容易に運用できるようにすることによる効果は大きい。
【0108】
なお、遠隔管理の対象としては、画像処理装置に限られず、ネットワーク家電,自動販売機,医療機器,電源装置,空調システム,ガス・水道・電気等の計量システム,自動車,航空機あるいは汎用コンピュータ等の種々の電子装置に通信機能を持たせた通信装置を被管理装置とすることが考えられる。ただし、下位装置20が遠隔管理システムにおける被管理装置に限られるものでないことも、もちろんである。
【産業上の利用可能性】
【0109】
以上説明してきたように、この発明の通信装置、通信システム、証明書更新方法を用いれば、通信手段によって通信相手と通信可能な通信装置あるいはこのような通信装置を備える通信システムにおいて、セキュリティを維持しながら、認証に必要な証明書を記憶する部品を交換する必要が生じた場合でも、容易かつ速やかに正常な認証が行える状態に容易に回復させることができる。
従って、この発明を、このような通信装置あるいは通信システムに適用することにより、より安全性の高い装置あるいはシステムを提供することができる。
【符号の説明】
【0110】
10…上位装置、11…CPU、12…ROM、13…RAM、14…HDD、
15…通信I/F、16…システムバス、20,20′…下位装置、
31,41…HTTPSクライアント機能部、32,42…HTTPSサーバ機能部、
33,43…認証処理部、34…証明書更新要求部、35,45…証明書記憶部、
44…要求管理部、46…状態通知部、47…ログ通知部、48…証明書設定部、
49…コマンド受信部、50…証明書管理装置、60,70…SOAPメッセージ、
140…生産管理システム、150…通信端末、154a…証明書DB、
156…入力装置、157…表示装置、160…証明書書き込み装置、
161…機番情報入力装置、162…機番情報入力用I/F、
165…書き込み用I/F、
BC…バーコード、E…生産工場、F…管理者室、G…ドア
【先行技術文献】
【特許文献】
【0111】
【特許文献1】特開2002−353959号公報
【特許文献2】特開2002−251492号公報
【特許請求の範囲】
【請求項1】
通信手段を備え、該通信手段によって通信相手と通信可能な通信装置であって、
異なる有効期間が設定されている2種類のデジタル証明書であってより有効期間が短い短期証明書とより有効期間が長い長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、
前記通信手段を、通信を行う際に前記通信相手に認証を受けるために前記短期証明書を提供する手段を備え、該短期証明書によって前記通信相手に認証された場合に通信を行う手段としたことを特徴とする通信装置。
【請求項2】
通信手段を備え、該通信手段によって通信相手と通信可能な通信装置であって、
当該通信装置の製品寿命よりも有効期間が短いデジタル証明書である短期証明書と当該通信装置の製品寿命よりも有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、
前記通信手段を、通信を行う際に前記通信相手に認証を受けるために前記短期証明書を提供する手段を備え、該短期証明書によって前記通信相手に認証された場合に通信を行う手段としたことを特徴とする通信装置。
【請求項3】
通信手段を備え、該通信手段によって通信相手と通信可能な通信装置であって、
当該通信装置の動作中に有効期限が切れるデジタル証明書である短期証明書と当該通信装置の動作中は有効期限が切れないデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、
前記通信手段を、通信を行う際に前記通信相手に認証を受けるために前記短期証明書を提供する手段を備え、該短期証明書によって前記通信相手に認証された場合に通信を行う手段としたことを特徴とする通信装置。
【請求項4】
通信手段を備え、該通信手段によって通信相手と通信可能な通信装置であって、
有効期限があるデジタル証明書である短期証明書と有効期限が事実上ないデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、
前記通信手段を、通信を行う際に前記通信相手に認証を受けるために前記短期証明書を提供する手段を備え、該短期証明書によって前記通信相手に認証された場合に通信を行う手段としたことを特徴とする通信装置。
【請求項5】
請求項1乃至4のいずれか一項記載の通信装置であって、
前記通信手段に、通信を行う際に通信相手に認証を受けるために前記長期証明書を提供する手段も設け、
前記長期証明書によって通信相手に認証された場合に前記通信手段を介して該通信相手から前記短期証明書を取得して前記記憶領域に記憶させる証明書設定手段を設けたことを特徴とする通信装置。
【請求項6】
請求項5記載の通信装置であって、
前記交換部品は、前記通信装置に装着される前には、前記長期証明書を記憶し、前記短期証明書を記憶していない部品であることを特徴とする通信装置。
【請求項7】
請求項1乃至6のいずれか一項記載の通信装置であって、
前記認証は、SSL又はTLSのプロトコルに従った認証処理によって行うものであり、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信装置。
【請求項8】
上位装置と、該上位装置の通信相手となる下位装置とを備えた通信システムであって、
前記下位装置において、
異なる有効期間が設定されている2種類のデジタル証明書であってより有効期間が短い短期証明書とより有効期間が長い長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、
前記通信手段を、通信を行う際に前記通信相手に認証を受けるために前記短期証明書を提供する手段を備え、該短期証明書によって前記通信相手に認証された場合に通信を行う手段としたことを特徴とする通信システム。
【請求項9】
上位装置と、該上位装置の通信相手となる下位装置とを備えた通信システムであって、
前記下位装置において、
前記下位装置の製品寿命よりも有効期間が短いデジタル証明書である短期証明書と前記下位装置の製品寿命よりも有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、
前記通信手段を、通信を行う際に前記通信相手に認証を受けるために前記短期証明書を提供する手段を備え、該短期証明書によって前記通信相手に認証された場合に通信を行う手段としたことを特徴とする通信システム。
【請求項10】
請求項8又は9記載の通信システムであって、
前記下位装置の通信手段に、通信を行う際に通信相手に認証を受けるために前記長期証明書を提供する手段も設け、
前記下位装置に、前記長期証明書によって通信相手に認証された場合に前記通信手段を介して該通信相手から前記短期証明書を取得して前記記憶領域に記憶させる証明書設定手段を設けたことを特徴とする通信システム。
【請求項11】
請求項10記載の通信システムであって、
前記交換部品は、前記下位装置に装着される前には、前記長期証明書を記憶し、前記短期証明書を記憶していない部品であることを特徴とする通信システム。
【請求項12】
請求項8乃至11のいずれか一項記載の通信システムであって、
前記認証は、SSL又はTLSのプロトコルに従った認証処理によって行うものであり、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信システム。
【請求項13】
通信手段を備え、該通信手段によって通信相手と通信可能な通信装置に、デジタル証明書である短期証明書を設定する証明書設定方法であって、
前記短期証明書と、該短期証明書よりも設定されている有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を備えた交換可能な最小単位の交換部品を、前記長期証明書を記憶させ、前記短期証明書を記憶させない状態で前記通信装置に装着し、
前記通信装置に、通信を行う際に通信相手に認証を受けるために前記長期証明書を提供させ、該長期証明書によって前記通信相手に認証された場合に前記通信手段を介して該通信相手から前記短期証明書を取得させて前記記憶領域に記憶させることを特徴とする証明書設定方法。
【請求項14】
通信手段を備え、該通信手段によって通信相手と通信可能な通信装置に、前記通信装置の製品寿命よりも有効期間が短いデジタル証明書である短期証明書を設定する証明書設定方法であって、
前記短期証明書と、前記通信装置の製品寿命よりも有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を備えた交換可能な最小単位の交換部品を、前記長期証明書を記憶させ、前記短期証明書を記憶させない状態で前記通信装置に装着し、
前記通信装置に、通信を行う際に通信相手に認証を受けるために前記長期証明書を提供させ、該長期証明書によって前記通信相手に認証された場合に前記通信手段を介して該通信相手から前記短期証明書を取得させて前記記憶領域に記憶させることを特徴とする証明書設定方法。
【請求項15】
請求項13又は14記載の証明書設定方法であって、
前記認証は、SSL又はTLSのプロトコルに従った認証処理によって行うものであり、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする証明書設定方法。
【請求項1】
通信手段を備え、該通信手段によって通信相手と通信可能な通信装置であって、
異なる有効期間が設定されている2種類のデジタル証明書であってより有効期間が短い短期証明書とより有効期間が長い長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、
前記通信手段を、通信を行う際に前記通信相手に認証を受けるために前記短期証明書を提供する手段を備え、該短期証明書によって前記通信相手に認証された場合に通信を行う手段としたことを特徴とする通信装置。
【請求項2】
通信手段を備え、該通信手段によって通信相手と通信可能な通信装置であって、
当該通信装置の製品寿命よりも有効期間が短いデジタル証明書である短期証明書と当該通信装置の製品寿命よりも有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、
前記通信手段を、通信を行う際に前記通信相手に認証を受けるために前記短期証明書を提供する手段を備え、該短期証明書によって前記通信相手に認証された場合に通信を行う手段としたことを特徴とする通信装置。
【請求項3】
通信手段を備え、該通信手段によって通信相手と通信可能な通信装置であって、
当該通信装置の動作中に有効期限が切れるデジタル証明書である短期証明書と当該通信装置の動作中は有効期限が切れないデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、
前記通信手段を、通信を行う際に前記通信相手に認証を受けるために前記短期証明書を提供する手段を備え、該短期証明書によって前記通信相手に認証された場合に通信を行う手段としたことを特徴とする通信装置。
【請求項4】
通信手段を備え、該通信手段によって通信相手と通信可能な通信装置であって、
有効期限があるデジタル証明書である短期証明書と有効期限が事実上ないデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、
前記通信手段を、通信を行う際に前記通信相手に認証を受けるために前記短期証明書を提供する手段を備え、該短期証明書によって前記通信相手に認証された場合に通信を行う手段としたことを特徴とする通信装置。
【請求項5】
請求項1乃至4のいずれか一項記載の通信装置であって、
前記通信手段に、通信を行う際に通信相手に認証を受けるために前記長期証明書を提供する手段も設け、
前記長期証明書によって通信相手に認証された場合に前記通信手段を介して該通信相手から前記短期証明書を取得して前記記憶領域に記憶させる証明書設定手段を設けたことを特徴とする通信装置。
【請求項6】
請求項5記載の通信装置であって、
前記交換部品は、前記通信装置に装着される前には、前記長期証明書を記憶し、前記短期証明書を記憶していない部品であることを特徴とする通信装置。
【請求項7】
請求項1乃至6のいずれか一項記載の通信装置であって、
前記認証は、SSL又はTLSのプロトコルに従った認証処理によって行うものであり、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信装置。
【請求項8】
上位装置と、該上位装置の通信相手となる下位装置とを備えた通信システムであって、
前記下位装置において、
異なる有効期間が設定されている2種類のデジタル証明書であってより有効期間が短い短期証明書とより有効期間が長い長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、
前記通信手段を、通信を行う際に前記通信相手に認証を受けるために前記短期証明書を提供する手段を備え、該短期証明書によって前記通信相手に認証された場合に通信を行う手段としたことを特徴とする通信システム。
【請求項9】
上位装置と、該上位装置の通信相手となる下位装置とを備えた通信システムであって、
前記下位装置において、
前記下位装置の製品寿命よりも有効期間が短いデジタル証明書である短期証明書と前記下位装置の製品寿命よりも有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を、交換可能な最小単位の交換部品に設け、
前記通信手段を、通信を行う際に前記通信相手に認証を受けるために前記短期証明書を提供する手段を備え、該短期証明書によって前記通信相手に認証された場合に通信を行う手段としたことを特徴とする通信システム。
【請求項10】
請求項8又は9記載の通信システムであって、
前記下位装置の通信手段に、通信を行う際に通信相手に認証を受けるために前記長期証明書を提供する手段も設け、
前記下位装置に、前記長期証明書によって通信相手に認証された場合に前記通信手段を介して該通信相手から前記短期証明書を取得して前記記憶領域に記憶させる証明書設定手段を設けたことを特徴とする通信システム。
【請求項11】
請求項10記載の通信システムであって、
前記交換部品は、前記下位装置に装着される前には、前記長期証明書を記憶し、前記短期証明書を記憶していない部品であることを特徴とする通信システム。
【請求項12】
請求項8乃至11のいずれか一項記載の通信システムであって、
前記認証は、SSL又はTLSのプロトコルに従った認証処理によって行うものであり、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする通信システム。
【請求項13】
通信手段を備え、該通信手段によって通信相手と通信可能な通信装置に、デジタル証明書である短期証明書を設定する証明書設定方法であって、
前記短期証明書と、該短期証明書よりも設定されている有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を備えた交換可能な最小単位の交換部品を、前記長期証明書を記憶させ、前記短期証明書を記憶させない状態で前記通信装置に装着し、
前記通信装置に、通信を行う際に通信相手に認証を受けるために前記長期証明書を提供させ、該長期証明書によって前記通信相手に認証された場合に前記通信手段を介して該通信相手から前記短期証明書を取得させて前記記憶領域に記憶させることを特徴とする証明書設定方法。
【請求項14】
通信手段を備え、該通信手段によって通信相手と通信可能な通信装置に、前記通信装置の製品寿命よりも有効期間が短いデジタル証明書である短期証明書を設定する証明書設定方法であって、
前記短期証明書と、前記通信装置の製品寿命よりも有効期間が長いデジタル証明書である長期証明書とを記憶する記憶領域を備えた交換可能な最小単位の交換部品を、前記長期証明書を記憶させ、前記短期証明書を記憶させない状態で前記通信装置に装着し、
前記通信装置に、通信を行う際に通信相手に認証を受けるために前記長期証明書を提供させ、該長期証明書によって前記通信相手に認証された場合に前記通信手段を介して該通信相手から前記短期証明書を取得させて前記記憶領域に記憶させることを特徴とする証明書設定方法。
【請求項15】
請求項13又は14記載の証明書設定方法であって、
前記認証は、SSL又はTLSのプロトコルに従った認証処理によって行うものであり、
前記デジタル証明書はその認証処理に使用する公開鍵証明書であることを特徴とする証明書設定方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【公開番号】特開2011−97636(P2011−97636A)
【公開日】平成23年5月12日(2011.5.12)
【国際特許分類】
【出願番号】特願2011−4364(P2011−4364)
【出願日】平成23年1月12日(2011.1.12)
【分割の表示】特願2004−217758(P2004−217758)の分割
【原出願日】平成16年7月26日(2004.7.26)
【出願人】(000006747)株式会社リコー (37,907)
【Fターム(参考)】
【公開日】平成23年5月12日(2011.5.12)
【国際特許分類】
【出願日】平成23年1月12日(2011.1.12)
【分割の表示】特願2004−217758(P2004−217758)の分割
【原出願日】平成16年7月26日(2004.7.26)
【出願人】(000006747)株式会社リコー (37,907)
【Fターム(参考)】
[ Back to top ]