JP4778210B2 - 通信装置、通信システム、通信方法及びプログラム - Google Patents
通信装置、通信システム、通信方法及びプログラム Download PDFInfo
- Publication number
- JP4778210B2 JP4778210B2 JP2004228595A JP2004228595A JP4778210B2 JP 4778210 B2 JP4778210 B2 JP 4778210B2 JP 2004228595 A JP2004228595 A JP 2004228595A JP 2004228595 A JP2004228595 A JP 2004228595A JP 4778210 B2 JP4778210 B2 JP 4778210B2
- Authority
- JP
- Japan
- Prior art keywords
- certificate
- communication
- authentication
- public key
- normal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
このようなSSLや公開鍵暗号を用いた認証に関連する技術としては、例えば特許文献1及び特許文献2に記載のものが挙げられる。
図21に示すように、SSLに従った相互認証を行う際には、まず双方の通信装置にルート鍵証明書及び、私有鍵と公開鍵証明書を記憶させておく必要がある。この私有鍵は、認証局(CA:certificate authority)が各装置に対して発行した私有鍵であり、公開鍵証明書は、その私有鍵と対応する公開鍵にCAがデジタル署名を付してデジタル証明書としたものである。また、ルート鍵証明書は、CAがデジタル署名に用いたルート私有鍵と対応するルート鍵に、デジタル署名を付してデジタル証明書としたものである。
図22(a)に示すように、公開鍵Aは、私有鍵Aを用いて暗号化された文書を復号化するための鍵本体と、その公開鍵の発行者(CA)や有効期限等の情報を含む書誌情報とによって構成される。そして、CAは、鍵本体や書誌情報が改竄されていないことを示すため、公開鍵Aをハッシュ処理して得たハッシュ値を、ルート私有鍵を用いて暗号化し、デジタル署名としてクライアント公開鍵に付す。またこの際に、デジタル署名に用いるルート私有鍵の識別情報を署名鍵情報として公開鍵Aの書誌情報に加える。そして、このデジタル署名を付した公開鍵証明書が、公開鍵証明書Aである。
一方通信装置BのCPUは、この接続要求を受信すると、所要の制御プログラムを実行することにより、図21の右側に示すフローチャートの処理を開始する。そして、ステップS21で第1の乱数を生成し、これを私有鍵Bを用いて暗号化する。そして、ステップS22でその暗号化した第1の乱数と公開鍵証明書Bとを通信装置Aに送信する。
そして確認ができると、ステップS13で、受信した公開鍵証明書Bに含まれる公開鍵Bを用いて第1の乱数を復号化する。ここで復号化が成功すれば、第1の乱数は確かに公開鍵証明書Bの発行対象から受信したものだと確認できる。
その後、ステップS14でこれとは別に第2の乱数及び共通鍵の種を生成する。共通鍵の種は、例えばそれまでの通信でやり取りしたデータに基づいて作成することができる。そして、ステップS15で第2の乱数を私有鍵Aを用いて暗号化し、共通鍵の種を公開鍵Bを用いて暗号化し、ステップS16でこれらを公開鍵証明書Aと共にサーバ装置に送信する。共通鍵の種の暗号化は、通信相手以外の装置に共通鍵の種を知られないようにするために行うものである。
また、次のステップS17では、ステップS14で生成した共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
その後、ステップS25で私有鍵Bを用いて共通鍵の種を復号化する。ここまでの処理で、通信装置A側と通信装置B側に共通鍵の種が共有されたことになる。そして、この共通鍵の種は、生成した通信装置Aと、私有鍵Bを持つ通信装置B以外の装置が知ることはない。ここまでの処理が成功すると、通信装置B側でもステップS26で復号化で得た共通鍵の種から以後の通信の暗号化に用いる共通鍵を生成する。
ただし、上述した処理において、第2の乱数を公開鍵Aで暗号化し、公開鍵証明書Aを通信装置Bに送信することは必須ではない。この場合、通信装置B側のステップS23及びS24の処理は不要になり、処理は図23に示すようになる。このようにすると、通信装置Bが通信装置Aを認証することはできないが、通信装置Aが通信装置Bを認証するだけでよい場合にはこの処理で十分である。そしてこの場合には、通信装置Aに記憶させるのはルート鍵証明書のみでよく、私有鍵A及び公開鍵証明書Aは不要である。また、通信装置Bにはルート鍵証明書を記憶させる必要はない。
また、予めルート鍵を設定されていない装置であっても、信頼性の高い第3者機関のものであればユーザがルート鍵の設定に同意しやすいし、ルート鍵を入手して設定すれば、同じ第3者機関が発行した公開鍵証明書を持つ装置は、装置自体のベンダーに関わらず認証することができるという利点もある。従って、自社製の装置を他社製の装置に接続したい場合等には、第3者機関の発行する公開鍵証明書を利用することが効果的である。また、装置のユーザ側からも、このような公開鍵証明書を利用したいという要望がある。
このような場合であっても、部品の交換後に操作者が装置を操作して新たな公開鍵証明書を容易に設定できるような場合は、操作者を認証する等してセキュリティを保持することができるため、さほど深刻な問題にはならない。しかし、ユーザの習熟度や利用環境から操作者による設定が困難であったり、装置の運用上、操作者に自由に証明書を設定させることが好ましくなかったりする等の理由で通信システム上の他の通信装置からリモートで証明書を設定するような構成とする場合は、認証が行えない状態ではセキュリティを保持するための手段がなく、この点が深刻な問題となる。
このような通信装置において、上記第1の証明書を上記記憶手段に記憶させた後は、上記相手先装置と通信を行う際、上記第1の証明書を上記相手先装置へ送信するようにするとよい。
このような通信システムにおいて、上記下位装置が、上記第1の証明書を上記記憶手段に記憶させた後は、上記上位装置と通信を行う際、上記第1の証明書を上記上位装置へ送信するようにし、上記上位装置に、上記下位装置から受信した上記第1の証明書を用いてその下位装置の認証を行う手段を設けるとよい。
まず、この発明による通信装置と、その通信装置を用いて構成したこの発明の通信システムの実施形態の構成について説明する。
図1はその通信システムの構成を示すブロック図である。
この通信システムは、図1に示すように、それぞれ通信手段を備える上位装置10及び下位装置20をネットワーク30によって接続して構成している。そして、下位装置20がこの発明の通信装置の実施形態である。また、上位装置10も通信機能を備えた通信装置であり、下位装置20の通信相手となる。
ネットワーク30としては、有線,無線を問わず、ネットワークを構築可能な各種通信回線(通信経路)を採用することができる。また、ここでは下位装置20を1つしか示していないが、図20に示すように通信システム内に下位装置20を複数設けることも可能である。
この図に示す通り、上位装置10は、CPU11,ROM12,RAM13,HDD14,通信インタフェース(I/F)15を備え、これらがシステムバス16によって接続されている。そして、CPU11がROM12やHDD14に記憶している各種制御プログラムを実行することによってこの上位装置10の動作を制御し、通信相手の認証や下位装置20のデジタル証明書更新等の機能を実現している。なお、この明細書において、デジタル証明書とは、偽造されないようにするための署名が付されたデジタルデータを指すものとする。
なお、この通信システムにおいて、上位装置10及び下位装置20が、遠隔管理,電子商取引等の目的に応じて種々の構成をとることができることは、もちろんである。そして、上位装置10や下位装置20のハードウェアとしては、適宜公知のコンピュータを採用することもできる。もちろん、必要に応じて他のハードウェアを付加してもよいし、上位装置10と下位装置20が同一の構成である必要もない。
HTTPSクライアント機能部31は、SSLに従った認証や暗号化の処理を含むHTTPSプロトコルを用いて下位装置20等のHTTPSサーバの機能を有する装置に対して通信を要求すると共に、通信相手に対して要求(コマンド)やデータを送信してそれに応じた動作を実行させる機能を有する。
認証処理部33は、HTTPSクライアント機能部31やHTTPSサーバ機能部32が通信相手を認証する際に、通信相手から受信したデジタル証明書や、証明書記憶部35に記憶している各種証明書、私有鍵等を用いて認証処理を行う認証手段の機能を有する。また、通信相手に認証を要求するために証明書記憶部35に記憶しているデジタル証明書をHTTPSクライアント機能部31やHTTPSサーバ機能部32を介して通信相手に送信する機能も有する。
証明書記憶部35は、各種の証明書や私有鍵等の認証情報を記憶し、認証処理部33における認証処理に供する機能を有する。これらの各種証明書や私有鍵の種類及びその用途や作成方法については後に詳述する。
HTTPSクライアント機能部41は、上位装置10のHTTPSクライアント機能部31と同様に、HTTPSプロトコルを用いて上位装置10等のHTTPSサーバの機能を有する装置に対して通信を要求すると共に、送信する要求やデータ等に応じた動作を実行させる機能を有する。
認証処理部43の機能も、上位装置10の認証処理部33と同様であるが、認証処理に使用する証明書等は、証明書記憶部45に記憶しているものである。
要求管理部44は、上位装置から受信した要求について、その要求に基づいた動作の実行可否を判断する機能を有する。そして、実行を許可する場合に、その要求に基づいた動作を実行する機能部46〜49に対して動作要求を伝える機能も有する。
状態通知部46は、異常を検知したりユーザによる指示があったりした場合に上位装置10に対して下位装置20の状態を通知するコールを行う機能を有する。この通知は、上位装置10からの問い合わせに対する応答として送信してもよいし、HTTPSクライアント機能部41から上位装置10に通信を要求して送信してもよい。
証明書設定部48は、上位装置10から受信する後述する通常公開鍵証明書等によって証明書記憶部45に記憶している証明書等を設定及び更新する証明書設定手段の機能を有する。
コマンド受信部49は、上述した各機能部46〜48以外の機能に係る要求に対応する動作を実行する機能を有する。この動作としては、例えば下位装置20が記憶しているデータの送信や、必要に応じてエンジン部の動作を制御することが挙げられる。なお、状態通知部46やログ通知部47は、コマンド受信部49が提供する機能の具体例として示したものであり、これらのような機能を設けることは必須ではない。
この通信システムにおいて、上位装置10は、下位装置20と通信を行おうとする場合、まず下位装置20に対して通信を要求する。そして、従来の技術の項で図21又は図23を用いて説明したようなSSLプロトコルに従った認証処理によって下位装置20を正当な通信相手として認証した場合に、下位装置20との間で通信を確立させるようにしている。この認証処理は、SSLハンドシェイクと呼ばれる。ただし、図21に示したような相互認証は必須ではなく、図23に示したような片方向認証でもよい。
この処理において、下位装置20は自身の公開鍵証明書を上位装置10に送信して、認証を受ける。そして、相互認証を行う場合には上位装置10も下位装置20に自身の公開鍵証明書を送信して認証を受けるが、片方向認証の場合にはこちらの認証は行わない。
そして、下位装置20はこの要求の内容に応じた処理を実行し、その結果を応答のSOAPメッセージ70として生成し、HTTPレスポンスとして上位装置10に送信する。ここで、これらの要求と応答は、SSLハンドシェイクの処理において共有された共通鍵を用いて暗号化して送信し、通信の安全性を確保している。
また、RPCを実現するためには、上記の技術の他、FTP(File Transfer Protocol),COM(Component Object Model),CORBA(Common Object Request Broker Architecture)等の既知のプロトコル(通信規格),技術,仕様などを利用することができる。
図1に示した上位装置10及び下位装置20は、図6に示すように、大きく分けて通常認証情報とレスキュー認証情報とを記憶している。そして、これらの認証情報は、それぞれ自分に関する認証情報である公開鍵証明書及び私有鍵と、通信相手に関する認証情報であるルート鍵証明書とによって構成される。
この例においては、AがCAの識別情報を示し、Cが証明書の発行先の装置の識別情報を示す。これらは、それぞれ所在地、名称、機番あるいはコード等の情報を含む。また、Bが有効期間を示し、その開始日時と終了日時によって有効期間を指定している。
しかし、公開鍵証明書に付す識別情報に機番情報と同一の情報を含めておけば、認証処理において通信相手の機番を直接特定できる。従って、このようにすることにより、公開鍵証明書に付す識別情報と機番情報との対応関係を管理する必要がなくなり、管理負担を低減できるのである。
もちろん、このような機番情報を証明書に記載しなくてもよいし、逆に、この他に下位装置20の機種番号や登録ユーザ等の情報も記載するようにしてもよい。
そして、下位装置20を複数設けた場合でも、各装置の通常公開鍵に付すデジタル署名は同じルート私有鍵を用いて付し、正当性確認に必要な通常ルート鍵証明書は共通にする。しかし、通常公開鍵証明書に含まれる通常公開鍵やこれと対応する私有鍵は、装置毎に異なる。
上位装置用通常公開鍵証明書と上位装置用通常私有鍵と上位装置認証用通常ルート鍵証明書も同様な関係である。
また、各装置に、複数のパブリック認証局が発行した公開鍵証明書の正当性を確認できるようにするため、その各パブリック認証局と対応したルート鍵証明書を記憶させるようにすることも考えられる。
また、下位装置20側でも、上位装置10側で認証が成功した場合に送信されてくる上位装置用通常公開鍵証明書及び、上位装置用通常私有鍵で暗号化された乱数を受信し、記憶している上位装置認証用ルート鍵証明書を用いて同様な認証を行うことができる。
このような認証局が発行する証明書は、通常はパブリック認証局が発行する証明書よりも信頼性が低いと考えられるが、プライベート認証局は、安全性と利便性を考慮して設置者が独自のポリシーにより運営することができるため、用途に適合した証明書を発行し易いという利点もある。また、プライベート認証局であっても、安全性に配慮すれば、比較的安全性の高い証明書を提供することも可能である。
これらは、同じ装置に設定して認証処理に使用させる公開鍵証明書である。しかし、証明書の発行者は、通常公開鍵証明書については符号Dで示すようにYYY社の「PublicCA」としている一方、レスキュー公開鍵証明書については符号Gで示すようにXXX社の「PrivateCA」というように、異なるCAとしている。「PublicCA」はパブリック認証局、「PrivateCA」はプライベート認証局に該当するものとする。またここでは、プライベート認証局は、発行先装置のメーカーであるXXX社が設けている。
そして、このようなレスキュー公開鍵証明書を含むレスキュー認証情報を用意し、レスキュー認証情報の内容を、輸出規制や、各地域で普及している認証処理の内容等を考慮しても下位装置20が使用されると想定される種々の環境で共通に使用できるような認証処理により認証を行うことができるようなものにするとよい。
また、パブリック認証局の発行する公開鍵証明書では、厳格な管理や安全性が要求されるため、上記のように種々の環境で共通に使用できるような証明書を発行することが難しい場合もあるし、費用もかかる。しかし、プライベート認証局であれば、証明書の仕様を比較的自由に定められるので、暗号強度を低くしたり、最新であまり普及していない認証処理アルゴリズムを避けたりして、種々の環境で共通に使用できるような証明書を発行することも可能である。また、装置のメーカー自身がプライベート認証局を提供すれば、安価に証明書を発行することも可能である。さらに、例えば下位装置20と上位装置10でメーカーが異なったり、通信システムの運用者が種々にカスタマイズを行ったりするような場合でも、レスキュー公開鍵証明書を無償で提供する等して、これらのメーカーや運用者に、レスキュー公開鍵証明書を用いた認証に対応できるようにするよう働きかけることも容易となる。
なお、下位装置20を用いた通信システムを構成するユーザが、必ずしも上位装置10をレスキュー公開鍵証明書を用いた認証に対応させるとは限らない。しかし、レスキュー公開鍵証明書を用いた認証に対応させることにより、上記のように、交換後の部品に新しい通常公開鍵証明書を安全にリモートで設定できるという機能を利用できるようになることから、ユーザ側にもレスキュー公開鍵証明書を利用可能にするメリットがある。
そこで、当初は上位装置10がレスキュー公開鍵証明書を用いた認証に対応しておらず、レスキュー認証情報を使用できない状態であっても、証明書記憶領域を有する交換部品全てにレスキュー認証情報を記憶させておき、事後的に上位装置10をレスキュー公開鍵証明書を用いた認証に対応させるようにすることも考えられる。このような場合でも、上位装置10の対応後は、部品を交換した下位装置20に、レスキュー公開鍵証明書を用いた認証を行って確立した安全な通信経路で通常認証情報を設定することができる。
なお、プライベート認証局が発行するレスキュー公開鍵証明書は、パブリック認証局が発行する通常公開鍵証明書と比べた場合に、安全性や信頼性が劣ることも考えられる。しかしながら、レスキュー認証情報を用いて認証処理を行った場合に、通常公開鍵証明書を始めとする正規認証情報の更新のような限られた要求のみ実行を許可するようにすれば、若干安全性が低下したとしても、大きな問題にはならない。
すなわち、通常公開鍵証明書はパブリック認証局が発行するものであるから、装置の製造者や使用者が有効期間を自由に定めることができず、また安全性を考慮して有効期間が短く設定されているのが通常である。一方で、レスキュー認証情報は、プライベート認証局が発行するものであるから、装置の製造者が自由に有効期間を定めることができる。そこで、有効期間をこのように通常公開鍵証明書よりも長く設定するようにしている。
このようにすれば、有効期間が長い分、有効期限切れにより使用不能になってしまう事態も生じにくい。従って、証明書の記憶領域を備える部品の製造時に、予めレスキュー認証情報を記憶させておくようにしても、部品を長期間ストックしておき、交換が必要になった場合に速やかにこれに対応することができる。
また、この点を考慮すると、レスキュー公開鍵証明書の有効期間経過後には部品に再度レスキュー公開鍵証明書を設定し直す必要が生じてしまうので、レスキュー公開鍵証明書の有効期間は長い方が好ましい。具体的には、例えば記憶させる装置の製品寿命よりも長い有効期間を設定するとよい。この製品寿命は、装置の想定運用期間あるいは想定動作期間であり、開発時に想定している使用期間や想定耐用年数、装置の品質保証期間等から定めることができる。
また、レスキュー公開鍵証明書の有効期間を、装置をメンテナンスしながら正常に動作させられると想定される期間よりも長く設定すれば、レスキュー公開鍵証明書は装置の動作中には有効期限が切れない証明書であるということができる。従って、装置の動作中は、常にレスキュー公開鍵証明書を用いた認証(レスキュー証明書セットを用いた認証)が可能な状態を保つことができる。従って、一旦レスキュー公開鍵証明書を記憶させて製造した部品に対し、ストック中にこの証明書の有効期限が切れて、これを更新する必要が生じることもない。
さらにまた、たとえレスキュー公開鍵証明書の有効期間が製品寿命より短かったとしても、通常公開鍵証明書の有効期間よりも長ければ、通常公開鍵証明書を記憶させておく場合よりも部品のストック可能期間を延ばすことができるという効果を得ることはできる。
通常公開鍵証明書の有効期間については、パブリック認証局の運営者が安全性を考慮して適当な期間を定めるが、上記のように、この期間は、製品寿命よりも短く、また装置の動作中に有効期限が切れるような期間となることが多い。
これは、上位装置10のレスキュー認証情報についても同様である。
そして、通常公開鍵証明書とデータ形式を統一化するため、図10に示した例において、発行先装置の機番として0を記載してレスキュー公開鍵証明書であることを示すようにしている。なお、「Subject」の項目を空白としてこのことを示すことも考えられる。
すなわち、例えばあるベンダーが自社製品のうち下位装置20に該当する装置全てに下位装置用のレスキュー証明書セットを記憶させ、その通信相手となる上位装置10に該当する装置全てに上位装置用のレスキュー証明書セットを記憶させておけば、認証が成功した場合、下位装置20は、自己の記憶している上位装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手が同じベンダーの上位装置10であることを認識できるし、逆に上位装置10も自己の記憶している下位装置認証用レスキュールート鍵証明書で正当性を確認できる公開鍵証明書を送信してきた相手は同じベンダーの下位装置20であることを認識できる。
そして、このような認証が成功すれば、前述のように通信相手との間で共通鍵を共有して共通鍵暗号を用いた安全な通信経路を設けることができるので、その後機番情報等を交換して通信相手を特定することも可能である。
SSLプロトコルにおいては、サーバは、クライアントから通信要求があった時点ではクライアントの状態を知ることができないため、必然的に、特定のURL(Uniform Resource Locator)にアクセスされた場合には常に同じ公開鍵証明書を提供することになる。従って基本的には、通常公開鍵証明書を複数持ち、通信相手の持つ通常ルート鍵証明書の種類に合わせて適当なものを選択して送信するといった構成を取ることはできない。しかし、通信要求を受け付けるアドレスが異なる場合には、アドレス毎に異なる公開鍵証明書を返すことも可能である。このアドレスは、例えばURLによって定めることができる。
なお、通信を要求するクライアントの側では、どのURLに対して通信要求を送ったかがわかるので、相互認証を行う場合にはURLに応じた適切な公開鍵証明書を選択して送信することができる。
以上のように、この通信システムにおいては、通常認証情報に加えてレスキュー認証情報も使用することにより、認証に必要な証明書を記憶する部品を交換する必要が生じた場合でも、容易かつ速やかに正常な認証が行える状態に容易に回復させることができる。従って、人手での証明書更新が困難であり自動更新に頼らざるを得ないような装置であっても、信頼性の高いパブリック認証局が発行する証明書を有効に活用することができる。
下位装置20や上位装置10において、このような記憶領域は、不揮発性の記録媒体であれば設計上はどこにでも設けることができる(ただし、通常証明書セットを記憶する領域は書き換え可能な記録媒体に設けることが好ましい)。例えば、下位装置20において、通常証明書セットを記憶する記憶領域をRAM23に、レスキュー証明書セットを記憶する記憶領域をROM22に設けることもできる。
しかしながら、通常証明書セットとレスキュー証明書セットの記憶領域を別々に交換可能な部品に設けると、以下のような問題が生じる。図12を用いてこの問題について説明する。図12は、この実施形態の比較例における、証明書の記憶領域を設ける交換部品の構成及びその問題点について説明するための図である。
この実施形態の下位装置20においては、上記の問題を解決するため、図12(a)に示した比較例の構成とは異なり、図13(a)に示すように、通常証明書セットを記憶する記憶領域と、レスキュー証明書セットを記憶する記憶領域とを両方とも、交換可能な最小単位の交換部品上に設けている。しかし、このような構成を採る場合でも、証明書の特性は変わらないので、この部品Aを、レスキュー証明書セットのみ予め記憶させ、通常証明書セットは記憶させない状態で製造することになる点は、図12(a)の場合と同様である。
部品Aを取り外して別の正規の部品Aに交換した場合には、新たな通常証明書セットがそこに記憶されることになるが、正規の部品Aであれば、ベンダー側が流通をコントロールすることが可能であるので、ユーザに必要以上の数の部品Aを供給しないようにすればよい。
なお、ここでいう交換可能な最小単位の交換部品とは、ユーザの作業やサービスマンによる出張メンテナンス等の作業によって交換可能な部品のうち、交換する場合にはその全部を交換する必要がある部品を指すものとする。例えばROM22やRAM23を構成するフラッシュメモリやNVRAM等を備えたメモリカードやメモリユニット、あるいはCPU21と共に書き換え可能な不揮発性メモリを搭載したCPUボード等が考えられる。しかし、例えば、CPUボード上に複数のメモリチップが搭載されており、工場等で特殊な設備を使用すればこれらを個別に交換可能であったとしても、ユーザの作業やサービスマンによる出張メンテナンス等の作業では通常交換できない場合には、それは交換可能とは言わないものとする。
まず、これらの製造工程の概略を図14に示す。この図においては、証明書セットの設定に関する部分を中心に示し、それ以外の部分については大幅に簡略化して示している。
以上で部品Aが完成し、これを部品として流通させる場合には、梱包した上出荷することになる。
ここで、レスキュー公開鍵証明書に装置の識別情報を記載しない場合には、書き込むべきレスキュー証明書セットは部品Aを装着する装置の機種や階位に応じて定まるので、これを予めソフトウェア複写装置130に記憶させておけばよい。また、部品Aが規格化されたメモリカード等の場合には、組み立てる必要がない場合もある。
以上の工程で下位装置20を製造することができる。また、記憶させるレスキュー証明書セットは異なるが、上位装置10についても同様な工程で製造することができる。なお、部品製造工程と製品組み立て工程とは、別々の工場で行われることが多い。
この図に示すように、部品Aには部品製造工程においてレスキュー証明書セットのみを記憶させ、通常証明書セットは記憶させない。そしてこの状態で、製品組み立て工程で新しい装置の組み立てに用いる部品と、市場に販売済の装置のための交換部品(サービスパーツ)とのどちらの用途にも使用できる部品として完成する。
そして、工場においてユーザからの注文に応じて装置を生産するような場合には、機番が付与された段階で、その装置を使用するユーザや、その装置が接続される通信システムがわかっている場合もある。そして、このような場合には、利用環境に適した通常証明書セットを、装置製造の段階で設定してしまうことも可能である。
この通常証明書セットは、パブリックCAである証明書管理装置50が発行するものである。そして、証明書管理装置50は、設定対象の下位装置20が接続される予定の通信システムにおいて、上位装置10が行う認証処理で使用可能な証明書を発行するパブリックCAである。
下位装置20は、通信相手がレスキューURLに通信を要求してきた場合、図16のフローチャートに示す処理を開始する。
この処理においては、まずステップS201で、通信相手(ここでは証明書書き込み装置160)に認証を受けるために下位装置用レスキュー公開鍵証明書を、下位装置用レスキュー私有鍵で暗号化した第1の乱数と共に通信相手に送信する。この処理は、図23のステップS21及びS22の処理に相当する。
下位装置20は、この認証結果を受け取ると、ステップS202で認証が成功したか否か判断し、失敗であればそのまま処理を終了するが、成功していればステップS203に進んで受信した共通鍵の種を用いて共通鍵を作成して以後の通信に使用するようにする。これらの処理は、図23のステップS25及びS26の処理に相当する。
その後、ステップS207で設定結果を応答として送信元に通知して処理を終了する。
下位装置20がこのような処理を実行することにより、証明書書き込み装置160が、下位装置20が通常証明書セットの書き込み対象であることについて少なくとも最低限の確認を行うことができるので、全く異なる装置に誤って通常証明書セットを送信してしまうような事態を防止できる。
さらに、通信要求について、下位装置20側から証明書書き込み装置160に対して通信要求を行うようにすることも考えられる。この場合でも、証明書書き込み装置160と下位装置20とがレスキュー公開鍵証明書を用いた認証処理を行い、これが成功した場合に証明書書き込み装置160が下位装置20に通常公開鍵証明書を送信して設定させることは、上述の処理の場合と同様である。
さらに、通常証明書セットを送信する際に、必要に応じて、その通常証明書セットに含まれる公開鍵証明書や私有鍵を用いた認証処理を行うために必要なソフトウェアも共に送信し、下位装置20に設定させるようにしてもよい。
また、証明書管理装置50は、上位装置10が行う認証処理で使用可能な証明書を発行するパブリックCAである。そして、発行された証明書を管理する機能を上位装置10に設けたり、上位装置10が間に発行された証明書を管理する装置を介してCAに証明書の発行を依頼するような構成が好ましいことは、上述した証明書書き込み装置160の場合と同様である。
また、下位装置20が上位装置10に通信要求を行うようにしてもよいことも、上述の証明書書き込み装置160によって書き込む場合と同様である。
また、工場で下位装置20の通常証明書セットを設定できなかった場合には、部品Aにレスキュー証明書セットのみを記憶させて出荷し、設置先で上記の市場機の場合と同様に通常証明書セットを記憶させるようにすることができる。
なお、下位装置20に、その機番情報を装置の識別情報として付された通常公開鍵証明書を記憶させるようにする場合であっても、機番は、装置の組み立てが完了し、機能の検査に合格した装置に付すようにしたいという要求がある。なぜなら、検査前に機番を付してしまうと、検査に不合格となった装置の機番が欠番になってしまい、このような欠番があるとその後の製品管理に不都合があるためにである。
また、ここではレスキュー公開鍵証明書は同じ階位の装置全てに同じものを記憶させるため、レスキュールート私有鍵が漏洩するとセキュリティの維持が著しく困難になるので、秘密保持を特に厳重に行う必要がある。一方で、各装置について個別に異なる証明書を作成して記憶させる必要はない。そこで、安全性を重視し、外部からアクセス不能なCAを用いるとよい。プライベートCAであれば、このような条件を満たすCAを用意することは容易である。
なお、CAをさらに細分化し、下位装置用の証明書を発行するCA,上位装置用の証明書を発行するCA等、証明書を発行する対象の装置の階位に応じてCAを分けるようにしてもよい。
また、通常証明書セットとレスキュー証明書セットとで全く形式の異なるデジタル証明書を使用することも可能である。
この図に示すように、製品組み立て工程を行う生産工場Eには、通常証明書セットを設定するための設備として、生産管理システム140,通信端末150,証明書書き込み装置160が設置されている。
そして、生産管理システム140は、上位装置10や下位装置20等の装置の日々の生産台数を管理する。
証明書書き込み装置160は、機番情報入力装置161を備えており、装置の生産時にその機番情報入力装置161から生産中の装置の機番の入力を受け付ける。そして、これが入力された場合に、その機番に対応する証明書を通信端末150から入手し、それを対応する装置へ送信してその装置の不揮発性メモリに設けた通常証明書セット記憶領域に設定させる。下位装置20を生産する場合には、部品Aに設けた記憶領域に設定させることになる。
生産工場Eにおいては、通信端末150は、セキュリティ面を考慮して管理者室Fに設置している。そして、その管理者室Fは、特定の管理者しか入れないように、ドアGに鍵をかけるようにしており、通信端末150は、特定のIDとパスワードが入力された場合にのみ操作できるようにしている。
またこの例では、生産工場Eには上位装置10の生産用ライン1001と下位装置20の生産用ライン1002とを設けている。そして、その各生産用ライン毎に証明書書き込み装置160(160a,160b)を設置している。
このような生産ラインにおいては、例えば下位装置20を生産する場合、機能検査に合格した装置に識別番号を付与する際に、定格銘板を貼付する。この定格銘板の例を図19に示すが、定格銘板には、定格電圧,消費電力等の情報と共に、装置の機番を記載している。そしてさらに、この機番の情報を示すバーコードBCも記載している。
続いて機番情報入力装置161としてバーコードリーダを用い、定格銘板上のバーコードBCを読み取って作業対象の装置の機番の情報を証明書書き込み装置160に入力する。すると、証明書書き込み装置160がその機番に対応する証明書を通信端末150から入手し、書き込み用I/F165を介して接続する下位装置20へ送信してその装置の部品Aに設けた通常証明書セット記憶領域に設定させる。なお、証明書DB154aに証明書を設定しない旨の情報が記憶されていた場合には、通常証明書セットの設定は行わない。
以上の作業及び処理により、生産する各下位装置20に、その機番情報を装置の識別情報として付され、かつその機番の装置が使用する予定の通常公開鍵証明書を簡単な作業で記憶させることができる。
SSLを改良したTLS(Transport Layer Security)も知られているが、このプロトコルに基づく認証処理を行う場合にも当然適用可能である。
一般に、セキュリティ強度が高い証明書には、多くの情報を記載する必要があったり、輸出制限があったり特殊な認証処理プログラムが必要であったりして利用可能な環境が限られていたりするため、全ての装置に同じように記憶させて認証処理に用いることが難しい場合がある。一方で、セキュリティ強度が低い証明書であれば、このような制限が少なく、全ての装置に同じように記憶させて認証処理に用いることが比較的容易であると考えられる。
また、通常公開鍵証明書とレスキュー公開鍵証明書の有効期間についても、特に上述した関係に限定されることはない。さらに、認証局の種類についても、セキュリティ高低の1つの要素と捉え、有効期間、装置の識別情報の有無、証明書を用いた認証処理の暗号強度等により、通常公開鍵証明書とレスキュー公開鍵証明書の差を出すようにすることも考えられる。
このような場合において、証明書管理装置50と、これと一体になっている上位装置10との間の通信には、ハードウェアを証明書管理装置50として機能させるためのプロセスと、ハードウェアを上位装置10として機能させるためのプロセスとの間のプロセス間通信を含むものとする。
例えば、画像形成手段を備えた画像処理装置については、感光体静電プロセスを用いて普通紙に画像形成するものが一般的であるが、このような感光体静電プロセスを行う機構からは、トラブル(異常)が発生する割合も高く、更に性能維持のための定期的なオーバホールの必要性から、保守管理のサービス体制を採っている。
そして、この保守管理を充実させる目的で、画像形成装置を被管理装置とする遠隔管理システムとして、画像形成装置の内部又は外部に通信装置を設け、画像形成装置とサービスセンタ(管理センタ)に設置された管理装置とを公衆回線(電話回線)を介して接続し、画像形成装置の異常発生時にその旨を管理装置に通報するようにしたものが既に開発され運用されている。
遠隔管理を行う場合には、被管理装置の近くに管理装置の操作者がいないことが多いため、被管理装置の特定は、通信によって行う必要がある。そして、通信によって特定された被管理装置が確かにその装置であることを保証する仕組みが必要になる。従って、上述の実施形態で説明したように通常公開鍵証明書を用いた認証を容易に運用できるようにすることによる効果は大きい。
従って、この発明を、このような通信装置あるいは通信システムに適用することにより、より安全性の高い装置あるいはシステムを提供することができる。
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…ドア
Claims (6)
- ネットワークを介して相手先装置と通信を行う通信装置であって、
第1の認証局によって発行された当該通信装置の証明書である第1の証明書と、前記第1の認証局と異なる第2の認証局によって発行された当該通信装置の証明書である第2の証明書とを記憶可能な記憶手段と、
前記相手先装置と通信を行う際、前記記憶手段に前記第1の証明書が記憶されている場合は前記第1の証明書を前記相手先装置へ送信し、前記記憶手段に前記第1の証明書が記憶されていない場合は前記第2の証明書を前記相手先装置へ送信する送信手段と、
前記送信手段が送信した前記第2の証明書を用いた前記相手先装置での認証が成功した場合に、前記第1の証明書を前記相手先装置から受信し、該受信した第1の証明書を前記記憶手段に記憶させる証明書設定手段とを設けたことを特徴とする通信装置。 - 請求項1に記載の通信装置であって、
前記第1の証明書を前記記憶手段に記憶させた後は、前記相手先装置と通信を行う際、前記第1の証明書を前記相手先装置へ送信することを特徴とする通信装置。 - 上位装置と下位装置とを備え、前記上位装置と前記下位装置とがネットワークを介して通信を行う通信システムであって、
前記下位装置に、
第1の認証局によって発行された前記下位装置の証明書である第1の証明書と、前記第1の認証局と異なる第2の認証局によって発行された前記下位装置の証明書である第2の証明書とを記憶可能な記憶手段と、
前記上位装置と通信を行う際、前記記憶手段に前記第1の証明書が記憶されている場合は前記第1の証明書を前記上位装置へ送信し、前記記憶手段に前記第1の証明書が記憶されていない場合は前記第2の証明書を前記上位装置へ送信する送信手段と、
前記送信手段が送信した前記第2の証明書を用いた前記上位装置での認証が成功した場合に、前記第1の証明書を前記上位装置から受信し、該受信した第1の証明書を前記記憶手段に記憶させる証明書設定手段とを設け、
前記上位装置に、
前記下位装置から受信した前記第2の証明書を用いて該下位装置の認証を行う認証手段と、
前記認証手段による認証が成功した場合に、前記第1の証明書を前記下位装置へ送信する送信手段とを設けたことを特徴とする通信システム。 - 請求項3に記載の通信システムであって、
前記下位装置は、前記第1の証明書を前記記憶手段に記憶させた後は、前記上位装置と通信を行う際、前記第1の証明書を前記上位装置へ送信し、
前記上位装置は、前記下位装置から受信した前記第1の証明書を用いて該下位装置の認証を行う手段を有することを特徴とする通信システム。 - ネットワークを介して相手先装置と通信を行う通信装置であって、第1の認証局によって発行された前記通信装置の証明書である第1の証明書と、前記第1の認証局と異なる第2の認証局によって発行された前記通信装置の証明書である第2の証明書とを記憶可能な記憶手段を有する通信装置に、
前記相手先装置と通信を行う際、前記記憶手段に前記第1の証明書が記憶されている場合は前記第1の証明書を前記相手先装置へ送信し、前記記憶手段に前記第1の証明書が記憶されていない場合は前記第2の証明書を前記相手先装置へ送信する送信手順と、
前記送信手順で送信した前記第2の証明書を用いた前記相手先装置での認証が成功した場合に、前記第1の証明書を前記相手先装置から受信し、該受信した第1の証明書を前記記憶手段に記憶させる証明書設定手順とを実行させることを特徴とする通信方法。 - ネットワークを介して相手先装置と通信を行う通信装置であって、第1の認証局によって発行された前記通信装置の証明書である第1の証明書と、前記第1の認証局と異なる第2の認証局によって発行された前記通信装置の証明書である第2の証明書とを記憶可能な記憶手段を有する通信装置を制御するコンピュータを、
前記相手先装置と通信を行う際、前記記憶手段に前記第1の証明書が記憶されている場合は前記第1の証明書を前記相手先装置へ送信し、前記記憶手段に前記第1の証明書が記憶されていない場合は前記第2の証明書を前記相手先装置へ送信する送信手段と、
前記送信手段が送信した前記第2の証明書を用いた前記相手先装置での認証が成功した場合に、前記第1の証明書を前記相手先装置から受信し、該受信した第1の証明書を前記記憶手段に記憶させる証明書設定手段として機能させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004228595A JP4778210B2 (ja) | 2003-09-12 | 2004-08-04 | 通信装置、通信システム、通信方法及びプログラム |
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003321762 | 2003-09-12 | ||
JP2003321762 | 2003-09-12 | ||
JP2003341329 | 2003-09-30 | ||
JP2003341329 | 2003-09-30 | ||
JP2004228595A JP4778210B2 (ja) | 2003-09-12 | 2004-08-04 | 通信装置、通信システム、通信方法及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2005130456A JP2005130456A (ja) | 2005-05-19 |
JP4778210B2 true JP4778210B2 (ja) | 2011-09-21 |
Family
ID=34657707
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004228595A Expired - Fee Related JP4778210B2 (ja) | 2003-09-12 | 2004-08-04 | 通信装置、通信システム、通信方法及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4778210B2 (ja) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007329731A (ja) * | 2006-06-08 | 2007-12-20 | Hitachi Ltd | 証明書更新方法、システム及びプログラム |
JP5505517B2 (ja) | 2010-12-13 | 2014-05-28 | 富士通株式会社 | 情報処理装置、電力制御方法、および電力制御プログラム |
JP5889525B2 (ja) * | 2010-12-21 | 2016-03-22 | パナソニックIpマネジメント株式会社 | 認証システム |
WO2017170203A1 (ja) | 2016-03-31 | 2017-10-05 | 日本電気株式会社 | 生体データ登録支援装置、生体データ登録支援システム、生体データ登録支援方法、生体データ登録支援プログラム、生体データ登録支援プログラムを記憶する記憶媒体 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001237820A (ja) * | 2000-02-25 | 2001-08-31 | Nec Corp | 認証用証明書書き換えシステム |
JP2003067326A (ja) * | 2001-08-27 | 2003-03-07 | Sony Corp | ネットワーク上の資源流通システム、及び相互認証システム |
US6854057B2 (en) * | 2001-09-06 | 2005-02-08 | America Online, Inc. | Digital certificate proxy |
JP3842100B2 (ja) * | 2001-10-15 | 2006-11-08 | 株式会社日立製作所 | 暗号化通信システムにおける認証処理方法及びそのシステム |
-
2004
- 2004-08-04 JP JP2004228595A patent/JP4778210B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2005130456A (ja) | 2005-05-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4712325B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP4509678B2 (ja) | 証明書設定方法 | |
JP4583833B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP4611680B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP4778210B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP4671638B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP4504130B2 (ja) | 通信装置、通信システム、証明書送信方法及びプログラム | |
JP4712330B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP4611679B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP4712326B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP4611676B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP4657642B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP4611678B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP4657643B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP5348148B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP5418507B2 (ja) | 通信装置、通信システム、通信方法及びプログラム | |
JP4657641B2 (ja) | 証明書設定方法及び証明書設定装置 | |
JP2011072046A (ja) | 証明書設定方法 | |
JP4537797B2 (ja) | 通信装置、通信システム、通信装置の制御方法及びプログラム | |
JP4509675B2 (ja) | 通信装置、通信システム及び通信方法 | |
JP4542848B2 (ja) | 通信装置、通信システム、通信装置の制御方法及びプログラム | |
JP4570919B2 (ja) | 通信装置、通信システム、通信装置の制御方法及びプログラム | |
JP4611681B2 (ja) | 通信装置、通信システム、通信方法及びプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070309 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100727 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100927 |
|
RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20100927 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110118 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110322 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20110628 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110701 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4778210 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140708 Year of fee payment: 3 |
|
LAPS | Cancellation because of no payment of annual fees |