JP4770423B2 - ディジタル証明書に関する情報の管理方法、通信相手の認証方法、情報処理装置、ｍｆｐ、およびコンピュータプログラム - Google Patents

Description

本発明は、ディジタル証明書による認証方法およびその認証方法を用いた情報処理装置などに関する。

近年、端末装置同士による通信のセキュリティを確保するために、ディジタル証明書の技術が広く用いられている。この技術によると、通信相手の身元を確認することができるので、いわゆる「なりすまし」との間での不正なデータのやり取りを未然に防ぐことができる。

ディジタル証明書は、通信の当事者以外の第三者でありかつ信頼のできる機関である認証局（ＣＡ：Certificate Authority）によって発行される。このディジタル証明書の仕様としては、ＩＴＵ−ＴＸ．５０９で規定されるものが一般的に知られている。ディジタル証明書には有効期間が定められており、有効期間を過ぎたディジタル証明書は使用することができない。

しかし、有効期間を過ぎていなくても、ディジタル証明書の持ち主がディジタル証明書に係る秘密鍵を紛失しまたは他人に盗難されると、そのディジタル証明書の信頼性が損なわれる。そこで、認証局は、このような信頼性の損なわれたディジタル証明書を、そのシリアル番号などに関する情報を証明書失効リスト（ＣＲＬ：Certificate Revocation List）に掲載し公開することによって、失効させる。また、ディジタル証明書の持ち主の属性（例えば、氏名または会社名など）が変わった場合または持ち主が存在しなくなった場合にも、認証局は、そのディジタル証明書を失効させる。

よって、通信相手の確認（認証）の確実性を高めるためには、ディジタル証明書の内容だけでなく失効証明書リストをも確認する必要がある。なお、ディジタル証明書に関する技術として、特許文献１〜３に記載されるような方法が提案されている。

特許文献１に記載される方法によると、共同ＲＡサーバは、各認証局の証明書失効リストから取得した複数の失効リスト情報を予め共同証明書失効リストＤＢに記憶する。そして、共同証明書失効リストＤＢのデータに基づいてクライアント端末から送信されてくる電子証明書の有効性を判定する。

特許文献２に記載される方法によると、クライアントは、証明書管理サーバに対して電子証明書の要求または失効要求を行う。証明書管理サーバは、クライアントからの要求が電子証明書の要求であれば電子証明書を作成してリポジトリに登録し、クライアントからの要求が電子証明書の失効要求であればリポジトリから電子証明書を削除し、クライアントに通知する。クライアントは電子証明書を入手したときにリポジトリに電子証明書の照会を行うことで電子証明書が失効されているかどうかを検証する。

特許文献３に記載される方法によると、無線基地局は、携帯機器による通信が電子証明書を含むものであることを識別すると、証明書検証サーバにその電子証明書の有効性を確認するための問合せを行う。問合せを受けた証明書検証サーバは、自らが保持している失効証明書データベースによりその証明書の有効性を判定する。そして、有効性の判定結果は、無線基地局を介して携帯機器に送信される。
特開２００１−３６５２１号公報 特開２００１−７７８０９号公報 特開２００２−２１７８９９号公報

ところが、特許文献１〜３に示されるような従来の方法では、例えば、認証局のサーバまたは失効リストを保持しているサーバが障害の発生などによって停止している間は、ディジタル証明書の有効性を証明書失効リストに基づいて判定することができない。また、端末装置が所属するネットワークの中にファイアウォールまたはプロキシサーバなどが設置されていると、そのフィルタリングの機能の働きによって、証明書失効リストを取得できないことがある。この場合においても、ディジタル証明書の有効性を判定することができない。

本発明は、このような問題点に鑑み、ディジタル証明書の有効性の判定を従来よりも確実に行うことができるようにすることを目的とする。

本発明の一形態に係るディジタル証明書に関する情報の管理方法は、複数のノードによって構成されるネットワークにおけるディジタル証明書に関する情報の管理方法であって、前記ノードは、失効したディジタル証明書を示す失効証明書情報をそれぞれ有しており、自らの前記失効証明書情報および認証局の最新の証明書失効リストのいずれに基づいても、他のノードから提示されたディジタル証明書が失効していることを確認できない場合に、当該他のノードの属性と当該提示されたディジタル証明書とを比較することによって、当該提示されたディジタル証明書の信頼性を判別し、前記提示されたディジタル証明書に信頼性がないと判別した場合に、自らの前記失効証明書情報を、当該提示されたディジタル証明書がさらに示されるように更新するとともに、他のノードが有している前記失効証明書情報も同様に更新されるように、当該提示されたディジタル証明書を示す情報を当該他ノードへ送信する、ことを特徴とする。

本発明の一形態に係る通信相手の認証方法は、情報処理装置における通信相手の認証方法であって、前記情報処理装置は、失効したディジタル証明書を示す失効証明書情報を有しており、通信を行う際に、当該通信の相手から当該相手のディジタル証明書を取得し、自らの前記失効証明書情報および認証局の最新の証明書失効リストのいずれに基づいても、前記取得したディジタル証明書が失効していることを確認できない場合に、前記相手の属性と当該取得したディジタル証明書とを比較することによって、当該取得したディジタル証明書の信頼性を判別し、前記取得したディジタル証明書に信頼性がないと判別した場合に、自らの前記失効証明書情報を、当該取得したディジタル証明書がさらに示されるように更新するとともに、他の情報処理装置が有している前記失効証明書情報も同様に更新されるように、当該取得したディジタル証明書を示す情報を当該他の情報処理装置へ送信する、ことを特徴とする。

なお、本発明における「ネットワーク」とは、例えばＰ２Ｐネットワークなどであり、「ノード」および「情報処理装置」とは、例えばパーソナルコンピュータまたはワークステーションなどの装置である。

本発明によると、ディジタル証明書の有効性の判定を従来よりも確実に行うことができる。請求項３〜６、７、８の発明によると、なりすましとの不正な通信を従来よりも確実に防ぐことができる。

図１はネットワーク１の全体的な構成の例を示す図、図２は端末装置２のハードウェア構成の例を示す図、図３は端末装置２の機能的構成の例を示す図、図４は端末装置２の論理的なトポロジーの例を示す図、図５はディジタル証明書ＤＣの例を示す図である。

本発明に係るネットワーク１は、図１に示すように、複数台の端末装置２（２１、２２、…、２ｎ）、スイッチングハブ３、ルータ４、およびファイアウォール５などのノードによって構成されるＬＡＮ（Local Area Network）である。これらの端末装置２は、スイッチングハブ３にツイストペアケーブルによってスター型に繋がれている。スイッチングハブ３とルータ４との間にはファイアウォール５が設けられている。以下、これらのノードのうちの端末装置２同士がデータ通信を行う場合について説明する。

端末装置２は、パーソナルコンピュータ、ワークステーション、またはプリンタなどのような、他の装置との間でデータの入出力の処理を実行する装置である。以下、端末装置２としてパーソナルコンピュータが用いられる場合を例に説明する。

端末装置２は、図２に示すように、ＣＰＵ２０ａ、ＲＡＭ２０ｂ、ＲＯＭ２０ｃ、ハードディスク２０ｄ、通信インタフェース２０ｅ、画像インタフェース２０ｆ、入出力インタフェース２０ｇ、その他の種々の回路または装置などによって構成される。

通信インタフェース２０ｅは、ＮＩＣ（Network Interface Card）であって、ツイストペアケーブルを介してスイッチングハブ３のいずれかのポートに繋がれている。画像インタフェース２０ｆは、モニタと繋がれており、画面を表示するための映像信号をモニタに送出する。

入出力インタフェース２０ｇは、キーボード若しくはマウスなどの入力装置またはフロッピディスクドライブ若しくはＣＤ−ＲＯＭドライブなどの外部記憶装置などと繋がれている。そして、ユーザが入力装置に対して行った操作の内容を示す信号を入力装置から入力する。または、フロッピディスクまたはＣＤ−ＲＯＭなどの記録媒体に記録されているデータを外部記憶装置に読み取らせ、これを入力する。または、記録媒体に書き込むためのデータを外部記憶装置に出力する。

ハードディスク２０ｄには、図３に示すような接続テーブル保存部２０１、データ保存部２０２、通信制御部２０３、データ受信部２０４、データ解析部２０５、失効情報確認部２０６、認証部２０７、送信データ生成部２０８、データ送信部２０９、データ操作管理部２１０、およびコマンド受付部２１１などの機能を実現するためのプログラムおよびデータが格納されている。これらのプログラムおよびデータは必要に応じてＲＡＭ２０ｂに読み出され、ＣＰＵ２０ａによってプログラムが実行される。

各端末装置２には、それぞれ、他の端末装置２との識別のために、ホスト名（マシン名）、ＩＰアドレス、およびＭＡＣアドレスが与えられている。ホスト名は、ネットワーク１の管理者などが自由に付けることができる。ＩＰアドレスは、ネットワーク１の規則に従って与えられる。ＭＡＣアドレスは、その端末装置２の通信インタフェース１０ｅに対して固定的に与えられているアドレスである。本実施形態では、端末装置２１、２２、…ごとに「ＰＣ１」、「ＰＣ２」、…のようなホスト名が付されているものとする。以下、これらの端末装置２をホスト名によって記載することがある。

また、これらの端末装置２は、図４に示すように、仮想空間に配置されているものと仮想されている。そして、点線で示すように、仮想空間内の近隣の少なくとも１台の他の端末装置２と関連付けられている。かつ、これらの関連付けによって、すべての端末装置２が互いに直接的にまたは間接的に関係するようになっている。なお、「直接的に関係する」とは、図４において１本の点線で繋がれていること（例えば、図４のＰＣ１とＰＣ２またはＰＣ９とのような関係）を言い、「間接的に関係する」とは、２本以上の点線および１つ以上のノードで繋がれていること（例えば、図４のＰＣ１とＰＣ４とのような関係）を言う。端末装置２は、自らに直接的に関連付けられている他の端末装置２に対してデータを送信する。以下、「関連付けられている」とは、特に断りのない限り、直接的に関連付けられていることを言う。

ところで、本実施形態における端末装置２は、直接的にまたは間接的に関連付けられた端末装置２との間でＳＳＬ（Secure Sockets Layer）通信を行うことができる。ＳＳＬは、ディジタル証明書を用いて暗号化を行うことにより、ネットワーク上でデータを安全に送受信するためのプロトコルである。なお、本実施形態においては、本発明に係る認証処理を行った後にＳＳＬ通信のコネクションを確立する。この処理の流れについては、後に説明する。

ディジタル証明書は、一般に、それを必要とする者からの申請に従って認証局によって発行される。そして、認証局のサーバから申請者の端末装置に送信される。本実施形態においては、ネットワーク１を構成する端末装置２ごとにディジタル証明書が発行され与えられているものとする。

ディジタル証明書は、登録内容の変更または秘密鍵の盗難、紛失、若しくは破壊などが生じた場合は、その信頼性が損なわれるので、失効させる必要がある。そこで、一般に、認証局は、自局が発行したディジタル証明書について失効させる必要が生じた場合は、証明書失効リスト（ＣＲＬ）にそのディジタル証明書のシリアル番号および失効日などに関する情報を掲載し、公開する。これにより、ディジタル証明書が失効する。以下、端末装置２が取り扱うディジタル証明書を「ディジタル証明書ＤＣ」と記載する。

また、本実施形態では、端末装置２は、認証局のＣＲＬとは別に、失効したディジタル証明書を示すリストをそれぞれ独自に有している。以下、端末装置２が有するこのリストを「失効リストＲＬ」と記載する。失効リストＲＬは、認証局などが公開する失効証明書リストの内容に合わせて適宜更新される。つまり、失効したディジタル証明書ＤＣの情報が次々に登録される。ただし、認証局のサーバなどがダウンし、通信回線の障害が発生し、または認証局のサーバに接続できないようにファイアウォール５に設定されている場合のために、他の方法によっても、失効したディジタル証明書ＤＣの情報が次々に登録される。これについては、後に説明する。

ディジタル証明書ＤＣには、ディジタル証明書ＤＣの所有者などの属性、公開鍵、認証局、およびディジタル証明書ＤＣの属性などに関する情報が含まれている。ここで、これらの情報のうち本実施形態において特に重要なものを図５を用いて説明する。

ディジタル証明書ＤＣには、図５に示すように、所有者情報ＤＣｐ、公開鍵ＤＣｋ、および証明書情報ＤＣｃなどが記載されている。所有者情報ＤＣｐは、そのディジタル証明書ＤＣの所有者または端末装置２などの属性に関する情報であって、例えば、ＵＵＩＤ（Universally Unique Identifier）、メーカ名、型式、ＩＰアドレス、およびドメイン名などの情報を含む。その他、ＩＰアドレスまたはメールアドレスなどの情報を含むようにしてもよい。

「ＵＵＩＤ」は、汎用的な識別子であって、例えば、そのディジタル証明書ＤＣの所有者の端末装置２のＭＡＣアドレスおよびそのＵＵＩＤの発行の日時を表す文字列などを組み合わることによって生成される。「メーカ名」は、端末装置２またはそれに設けられているＮＩＣを製造したメーカの名称を示す。「型式」は、端末装置２またはそれに設けられているＮＩＣの型式を示す。「ドメイン名」は、端末装置２が所属するドメインの名称を示す。

公開鍵ＤＣｋは、各端末装置２同士がＳＳＬ通信のための共通鍵に関するデータのやり取りを安全に行うために用いられる。なお、各端末装置２は、自らのディジタル証明書ＤＣに含まれる公開鍵ＤＣｋと対になる秘密鍵も保持している。

証明書情報ＤＣｃは、そのディジタル証明書ＤＣ自身の属性の情報であり、例えば、シリアル番号、登録日、または有効期間などの情報を含む。「シリアル番号」は、そのディジタル証明書ＤＣを一意に識別するための番号である。「登録日」は、そのディジタル証明書ＤＣが発行された日を示す。「有効期間」は、そのディジタル証明書ＤＣが有効である期間の始期および終期を示す。なお、一般的なディジタル証明書ＤＣおよび失効リストＲＬの標準仕様は、ＩＴＵ（International Telecommunication Union）によってＸ．５０９として定められている。

図６は図４のように関連付けられた端末装置２の接続テーブルＴＬの例を示す図である。以下、図３に示す端末装置２の各部の処理内容について説明する。

接続テーブル保存部２０１は、その端末装置２自身に関連付けられている他の端末装置２のホスト名、ＩＰアドレス、およびＭＡＣアドレスなどの属性の一覧を示す接続テーブルＴＬを保存している。例えば、図４におけるＰＣ１、ＰＣ２、ＰＣ６、ＰＣ７、ＰＣ８、およびＰＣ９の接続テーブル保存部２０１には、図６に示すような接続テーブルＴＬ１、ＴＬ２、ＴＬ６、ＴＬ７、ＴＬ８、およびＴＬ９がそれぞれ保存されている。これらの接続テーブルＴＬの内容は、各端末装置２の関連付けに基づいて管理者によって予め作成される。

データ保存部２０２は、その端末装置２またはユーザなどの属性を示す属性データＰＩ、その端末装置２自身のディジタル証明書ＤＣ、失効リストＲＬ、オペレーティングシステム（ＯＳ）またはアプリケーションソフトなどが使用するデータ、ユーザがアプリケーションソフトによって作成したデータ、その他種々のデータを、ファイルとして保存している。属性データＰＩには、例えば、ＵＵＩＤ、メーカ名、型式、またはドメイン名などの情報が含まれる。これらの情報の意味は、図５のディジタル証明書ＤＣの所有者情報ＤＣｐの意味と同じである。なお、本実施形態においては、ディジタル証明書ＤＣを申請する際に、この属性データＰＩに記載される内容を認証局に対して申告する。したがって、発行されたディジタル証明書ＤＣの所有者情報ＤＣｐは、この属性データＰＩと同じ内容を示すことになる。

通信制御部２０３は、他の端末装置２とデータ通信を行うための種々の制御処理を行う。データ受信部２０４は、ネットワーク１を流れるパケットのうち、その端末装置２に必要なものを受信する。

データ解析部２０５は、データ受信部２０４が受信したデータ（以下、「受信データ」と記載する。）から必要な情報を抽出してその内容を解析することによって、その受信データの種類を判別する。

失効情報確認部２０６は、他の端末装置２から送信されて来たディジタル証明書ＤＣが失効していないかどうかを、データ保存部２０２に保存されている失効リストＲＬを参照して確認する。

認証部２０７は、他の端末装置２から送信されて来たディジタル証明書ＤＣおよび属性データＰＩなどに基づいて当該他の端末装置２の認証の処理を行う。

送信データ生成部２０８は、通信制御部２０３、認証部２０７、またはデータ操作管理部２１０などの指示に基づいて、他の端末装置２に送信するためのデータ（以下、「送信データ」と記載する。）を生成する。

データ送信部２０９は、送信データ生成部２０８によって生成された送信データをパケット化して他の端末装置２に送信する。

データ操作管理部２１０は、データ保存部２０２にデータを保存しまたはデータ保存部２０２に保存されているデータを更新するなどの処理を行う。例えば、端末装置２の環境または設定内容が変わるごとに、属性データＰＩを更新する。または、失効リストＲＬを更新する処理を行う。

コマンド受付部２１１は、ユーザがキーボードまたはマウスなどを操作して指定したコマンドを受け付け、そのコマンドに応じた処理を各部に実行させる。

図７はＳＳＬ通信のコネクションを確立する際の処理の流れの例を説明するための図、図８はディジタル証明書ＤＣの検証の処理の流れの例を説明するフローチャートである。

次に、図４のＰＣ１とＰＣ２とが目的の通信を行おうとする場合を例に、図３の各部の処理内容を、図７および図８を参照しながらさらに詳細に説明する。

ＰＣ１またはＰＣ２のうちのいずれか一方の端末装置２において、他方の端末装置２と通信を行いたい旨のコマンドをユーザがキーボードなどを操作して入力したとする。すると、コマンド受付部２１１はこのコマンドを受け付け、送信データ生成部２０８は接続の要求のデータ（以下、「接続要求データＣＲ」と記載する。）を生成し、データ送信部２０９はその接続要求データＣＲを他方の端末装置２に対して送信する（図７の＃１１）。ここでは、ＰＣ２がＰＣ１に対して接続要求データＣＲを送信したものとする。

すると、ＰＣ１において、データ受信部２０４はＰＣ２からの接続要求データＣＲを受信し、データ解析部２０５はそのデータの種類を解析する。ここでは、当然、接続要求データであると解析される。送信データ生成部２０８は接続を許可する旨を示す接続許可データＣＢを生成し、ＰＣ２に送信する（＃１２）。

ＰＣ２のデータ受信部２０４によって接続許可データＣＢが受信され、所定の処理が行われると、ＰＣ１とＰＣ２とが接続される。ただし、この時点では、未だＳＳＬ通信のコネクションは確立されていない。したがって、目的の通信は未だ開始しない。

ＰＣ１およびＰＣ２のうちのいずれか一方において、送信データ生成部２０８は対応可能なＳＳＬのバージョンを示すＳＳＬバージョンデータＳＶを生成し、データ送信部２０９はこれを他方に送信する（＃１３）。ここでは、ＰＣ２がＰＣ１に対してＳＳＬバージョンデータＳＶを送信したものとする。

すると、ＰＣ１において、データ受信部２０４がＳＳＬバージョンデータＳＶを受信し、データ解析部２０５はそのデータの種類を解析し、送信データ生成部２０８はＳＳＬバージョンデータＳＶに示されるバージョンのうちＰＣ１で対応可能なバージョンを１つ選択しこれを示すＳＳＬバージョン選択データＳＤを生成する。そして、データ送信部２０９は、これをＰＣ２に送信する（＃１４）。

ＰＣ２において、ＰＣ１からのＳＳＬバージョン選択データＳＤがデータ受信部２０４によって受信されると、それに示されるバージョンのＳＳＬを、目的の通信のためのプロトコルとして採用することに決定する。ＰＣ１においても、同様に決定する。

ＰＣ１およびＰＣ２において、それぞれに、Ｘ．５０９署名のチェーンに関する処理が行われ、データ送信部２０９によってデータ保存部２０２から自らのディジタル証明書ＤＣおよび属性データＰＩが抽出され通信相手に送信される（＃１５）。

なお、属性データＰＩの送信は、自らのディジタル証明書ＤＣに対応する秘密鍵によって暗号化して行うようにしてもよい。この場合は、その属性データＰＩを受信した端末装置２は、その属性データＰＩとともに送信されて来たディジタル証明書ＤＣに添付されている公開鍵ＤＣｋによってその属性データＰＩを復号すればよい。また、ディジタル証明書ＤＣおよび属性データＰＩの送信は、双方向に行う必要はなく、一方の端末装置２から他方の端末装置２に対してのみ行うようにしてもよい。例えば、ＰＣ１からＰＣ２に対してのみ行い、ＰＣ２からＰＣ１に対しては行わないようにしてもよい。本実施形態では、双方向に送信を行うものとして説明する。

ディジタル証明書ＤＣおよび属性データＰＩのやり取りを行った後、ＰＣ１は、応答終了の旨をＰＣ２に対して通知する（＃１６）。ここまでの処理は、属性データＰＩのやり取りを行う点を除いて従来とほぼ同様である。

従来であれば、次に、共通の暗号鍵つまり共通鍵を共有するための処理を行う。しかし、本実施形態では、ＰＣ１およびＰＣ２は、その前に、接続相手から受け取ったディジタル証明書ＤＣの有効性をチェックすることによって、その接続相手の認証のための処理を行う。係る処理は、失効情報確認部２０６および認証部２０７によって図８のフローチャートのような手順で行われる。

失効情報確認部２０６は、データ保存部２０２に保存されている失効リストＲＬを呼び出し（図８の＃３０）、受信した接続相手のディジタル証明書ＤＣがその失効リストＲＬに示されていないどうかをチェックするとともに、現在の日付がそのディジタル証明書ＤＣの有効期間内であるかどうかをチェックする（＃３１）。

そのディジタル証明書ＤＣがその失効リストＲＬに示されている場合または現在の日付が有効期間外である場合は、そのディジタル証明書ＤＣが失効していると判別し（＃３２でＹｅｓ）、通信制御部２０３は、接続相手との通信を中止する（＃３３）。これにより、図７のステップ＃１７以降の処理がキャンセルされる。

一方、そのディジタル証明書ＤＣがその失効リストＲＬに示されておらずかつ現在の日付が有効期間内である場合は（＃３２でＮｏ）、さらに、認証部２０７は、そのディジタル証明書ＤＣの有効性について判別することによって通信相手の認証の処理を次のように行う（＃３４）。

認証部２０７は、通信相手の属性データＰＩの内容とディジタル証明書ＤＣの内容とを比較する。例えば、ディジタル証明書ＤＣの所有者情報ＤＣｐ（図５参照）および属性データＰＩに共通の幾つかの事項（例えば、ＵＵＩＤおよびドメイン名など）について比較し、一致すれば通信相手を認証する。一致しなければ、認証できなかったものとする。また、そのディジタル証明書ＤＣを発行した認証局のサーバに接続することができるのであれば、その認証局の最新のＣＲＬを参照し、そのディジタル証明書ＤＣが失効していないかどうか確認する。失効していれば、認証できなかったものとする。

通信相手の認証ができなかった場合は（＃３５でＮｏ）、通信制御部２０３は、その接続相手との通信を中止し（＃３３）、図７のステップ＃１７以降の処理をキャンセルする。これと並行してまたは前後して、データ操作管理部２１０は、その通信相手から受信したディジタル証明書ＤＣが失効して扱われるようにするために、そのディジタル証明書ＤＣに関する情報を自らの失効リストＲＬを追加する（＃３９）。送信データ生成部２０８は、そのディジタル証明書ＤＣを示す失効リスト更新データＵＣを、自らに関連付けられている他の端末装置２に送信する（＃４０）。この失効リスト更新データＵＣを受信した端末装置２は、これに基づいて自らの失効リストＲＬを更新する。これについては後に説明する。

通信相手の認証ができた場合は（＃３５でＹｅｓ）、その通信相手とのＳＳＬ通信のコネクションを確立し（＃３６）、ＳＳＬによる目的の通信を開始する（＃３７）。これらの処理は、図７に戻って説明する。

互いの認証ができたら、ＰＣ１、ＰＣ２のうちのいずれか一方は、ＰＣ１およびＰＣ２がＳＳＬ通信で使用する共通鍵を生成するために、３８４ビットのランダムな値であるプリマスターキーＰＭＫを生成する。ここでは、ＰＣ２が生成するものとする。ＰＣ２の送信データ生成部２０８は、プリマスターキーＰＭＫを自らのディジタル証明書ＤＣに含まれる公開鍵ＤＣｋによって暗号化してＰＣ１に送信するとともに（＃１７）、共通鍵を生成して通信用の暗号鍵をその共通鍵に切り替えるべき旨のメッセージをＰＣ１に送信する（＃１８）。

ＰＣ１において、データ受信部２０４は、プリマスターキーＰＭＫを受信すると、これを自らのディジタル証明書ＤＣに対応する秘密鍵で復号する。データ解析部２０５がこれを解析することによってデータの種類がプリマスターキーであることを確認すると、通信制御部２０３は、受信したプリマスターキーＰＭＫをよって共通鍵ＫＹＰを生成し、今後、ＰＣ２との間でその共通鍵ＫＹＰによる暗号化通信が行われるように制御を行う。つまり、暗号鍵の切替えを行う。

ＰＣ２においても、同様に、通信制御部２０３は、ＰＣ１に送信したプリマスターキーＰＭＫをよって共通鍵ＫＹＰを生成し、今後、ＰＣ２との間でその共通鍵ＫＹＰによる暗号化通信が行われるように制御を行う。つまり、暗号鍵の切替えを行う。なお、ＰＣ１およびＰＣ２は、同一の関数などを用いて共通鍵ＫＹＰを生成する。したがって、当然、両者がそれぞれ生成した共通鍵ＫＹＰは、同一である。

以上の処理によって、ＰＣ１とＰＣ２との間でＳＳＬ通信のコネクションが確立される（＃１９）。これにより、目的の通信を安全に行うことができる。

〔失効リストＲＬの更新処理〕
図９は失効したディジタル証明書ＤＣまたは信頼性のないディジタル証明書ＤＣに関する情報を他の端末装置２から通知された場合の処理の流れの例を説明するフローチャート、図１０は廃棄された端末装置２のディジタル証明書ＤＣが他の端末装置２によって不正に使用されようとしている場合の処理の例を説明するための図、図１１は失効したディジタル証明書ＤＣに関する情報を管理者または認証局から取得した場合の処理の例を説明するための図である。

前に図８で説明したように、端末装置２は、目的の通信を開始する前に、通信相手（接続相手）のディジタル証明書ＤＣを取得し、通信相手の認証の処理を行う。この際に、そのディジタル証明書ＤＣが自らの失効リストＲＬに示されていなければ、その通信相手の属性データＰＩを用いてそのディジタル証明書ＤＣの信頼性をチェックし、信頼性がない場合は、その通信相手を認証できないものとして、目的の通信を中止する。さらに、その信頼性のないディジタル証明書ＤＣに関する情報を自らの失効リストＲＬに書き加えるとともに、自らに関連付けられている他の端末装置２に対して失効リスト更新データＵＣを送信する。

つまり、ネットワーク１の中の端末装置２は、信頼性のないディジタル証明書ＤＣを新たに発見した場合は、その情報を互いに知らせ合う。以下、信頼性のないディジタル証明書ＤＣが発見された場合の処理について詳細に説明する。

信頼性のないディジタル証明書ＤＣを発見した端末装置２の処理は、上に述べた通りである。一方、信頼性のないディジタル証明書ＤＣが発見された旨の通知つまり失効リスト更新データＵＣを他の端末装置２から受信した端末装置２は、図９に示すような手順で処理を行う。

端末装置２は、失効リスト更新データＵＣを受信すると（＃５１）、それと同一の失効リスト更新データＵＣを過去に受信したことがない場合つまり初めて受信した場合は（＃５２でＹｅｓ）、自らの失効リストＲＬに、その失効リスト更新データＵＣに示される信頼性のないディジタル証明書ＤＣに関する情報を書き加えて更新する（＃５３）。ただし、別の方法によって既にその情報を書込済である場合は、更新する必要はない。

ステップ＃５３の処理と前後してまたは並行して、信頼性のないディジタル証明書ＤＣに関する情報をネットワーク１の中のさらに別の端末装置２にも通知するために、自らに対応付けられている他の端末装置２に対してその失効リスト更新データＵＣを回送する。ただし、その失効リスト更新データＵＣを回送してくれた端末装置２に対しては、回送する必要はない。

一方、同一の失効リスト更新データＵＣを過去に受信したことがある場合は、それに基づいて失効リストＲＬを更新済であるはずなので、受信した失効リスト更新データＵＣを廃棄する（＃５５）。ただし、何らかのトラブルで、更新できなかった場合もあるので、失効リスト更新データＵＣに示されるディジタル証明書ＤＣが失効リストＲＬに未記載である場合は、更新する。

このような失効リストＲＬの更新のための処理は、例えば、図１０に示すような場合に実行される。

図１０において、ＰＣ６は廃棄されたものとする。ＰＣ６を廃棄するにあたって、ＰＣ６の管理者は、ＰＫＩ（Public Key Infrastructure）の定めに従って、ＰＣ６のディジタル証明書ＤＣが不正に使用されないようにするために、そのディジタル証明書ＤＣを失効させるための適切な手続を認証局に対して行っておくとともに、そのディジタル証明書ＤＣおよびそれに対応する秘密鍵をどこにも残さないように削除しておく。ところが、作業ミスなどでＰＣ６のディジタル証明書ＤＣおよび秘密鍵が漏洩してしまい、ＰＣ１０のユーザがそれらを不正に取得しＰＣ１との通信を試みたとする。

このような場合において、ＰＣ１は、ＰＣ１０との通信を行うにあたって、ＰＣ１０から不正な（つまり、ＰＣ６から漏洩した）ディジタル証明書ＤＣを提示されても、自らの失効リストＲＬまたは認証局の最新のＣＲＬに基づいてそのディジタル証明書ＤＣが失効していることを確認することができる。そして、もしも、自らの失効リストＲＬにそのディジタル証明書ＤＣに関する情報が示されていない場合は、直ちにその情報を失効リストＲＬに追加する。これと並行して、そのディジタル証明書ＤＣについての失効リスト更新データＵＣを他の端末装置２に送信する。その失効リスト更新データＵＣを受信した端末装置２は、さらに別の端末装置２にこれを回送するとともに、自らの失効リストＲＬにそのディジタル証明書ＤＣに関する情報が示されていない場合は、直ちにその情報を追加する。

また、ＰＣ１は、自らの失効リストＲＬおよび認証局の最新のＣＲＬのいずれに基づいてもそのディジタル証明書ＤＣが失効していることを確認できない場合または認証局の最新のＣＲＬが取得できない場合は、ＰＣ１０から取得した属性データＰＩとそのディジタル証明書ＤＣとを比較することによって、そのディジタル証明書ＤＣの信頼性をチェックする。そして、信頼性がないと判別した場合は、自らの失効リストＲＬにそのディジタル証明書ＤＣに関する情報を追加するとともに、他の端末装置２に失効リスト更新データＵＣを送信する。

または、図１１に示すような場合にも、失効リストＲＬの更新のための処理が実行される。管理者は、端末装置２（例えば、ＰＣ１）に新たに発見された信頼性のないディジタル証明書ＤＣまたは失効したディジタル証明書ＤＣの情報を入力する。または、ＰＣ１は、定期的に認証局のサーバから最新のＣＲＬを受信する。すると、ＰＣ１は、入力されたディジタル証明書ＤＣの情報および受信したＣＲＬに示される新たに失効したディジタル証明書ＤＣの情報を自らの失効リストＲＬに追加するとともに、他の端末装置２に対してこれらの情報を示す失効リスト更新データＵＣを送信する。

ところで、失効の手続が適切に行われていれば、仮に他の端末装置２によって不正に使用されようとしても、第三者への被害を効果的に防止することができる。例えば、ＰＣ１０が、廃棄されたＰＣ６のディジタル証明書ＤＣを不正に取得し、これを用いてＰＣ１との通信を試みたとする。失効の手続が適切に行われていれば、ＰＣ１は、認証局の最新のＣＲＬに基づいてそのディジタル証明書ＤＣが失効していることを確認することができるので、ＰＣ１０との通信を中止することができる。

ところが、失効の手続が適切に行われたとしても、従来は、ディジタル証明書ＤＣが不正に使用されてしまうという問題点があった。例えば、ファイアウォール５の設定のためにＰＣ１が認証局のサーバに接続することができない場合は、ＰＣ１０から送信されてきたディジタル証明書ＤＣが失効していることが分からないことがあった。しかし、本実施形態では、認証局のサーバに接続することができる端末装置２が、接続することができない端末装置２に失効に関する情報を配布する。よって、上記のような問題点を解決することができる。

以上説明したように、本実施形態によると、失効したディジタル証明書ＤＣおよび失効したものとみなすべき信頼性のないディジタル証明書ＤＣに関する情報を、ネットワーク１内の端末装置２同士で交換し合う。よって、ファイアウォール５の設定などのために認証局のサーバに接続できない端末装置２であっても、ディジタル証明書ＤＣに関する最新の情報を従来よりも容易に取得することができ、通信相手のディジタル証明書ＤＣの有効性の判定の確実性および通信の安全性を従来よりも向上させることができる。

さらに、本実施形態によると、自らの失効リストＲＬおよび認証局で公開するＣＲＬだけでなく、通信相手の属性データＰＩにも基づいてディジタル証明書ＤＣの評価を行う。よって、通信相手のディジタル証明書ＤＣの有効性の判定の確実性および通信の安全性を一層向上させることができる。

本実施形態では、端末装置２としてパーソナルコンピュータを用いる場合を例に説明したが、本発明を、ＭＦＰ（Multi Function Peripherals）などのような画像形成装置、ワークステーション、携帯端末、その他の種々の情報処理装置に適用することが可能である。

本実施形態では、ＬＡＮの形態のネットワーク１に属する端末装置２同士でディジタル証明書ＤＣに関する情報を交換し合う場合を例に説明したが、インターネットなどのような広域のネットワークに属する端末装置２同士で情報を交換し合う場合にも適用可能である。また、端末装置２は、他のネットワークに参加している装置が通信相手であっても、その装置についての認証の処理を行うことができる。

その他、ネットワーク１、端末装置２の全体または各部の構成、処理内容、処理順序、テーブルの内容、暗号鍵などの鍵長などは、本発明の趣旨に沿って適宜変更することができる。

ネットワークの全体的な構成の例を示す図である。 端末装置のハードウェア構成の例を示す図である。 端末装置の機能的構成の例を示す図である。 端末装置の論理的なトポロジーの例を示す図である。 ディジタル証明書の例を示す図である。 図４のように関連付けられた端末装置の接続テーブルの例を示す図である。 ＳＳＬ通信のコネクションを確立する際の処理の流れを説明するための図である。 ディジタル証明書の検証の処理の流れの例を説明するフローチャートである。 失効したディジタル証明書または信頼性のないディジタル証明書に関する情報を他の端末装置から通知された場合の処理の流れの例を説明するフローチャートである。 廃棄された端末装置のディジタル証明書が他の端末装置によって不正に使用されようとしている場合の処理の例を説明するための図である。 失効したディジタル証明書に関する情報を管理者または認証局から取得した場合の処理の例を説明するための図である。

符号の説明

１ ネットワーク
２ 端末装置（ノード、情報処理装置）
２０２ データ保存部（失効証明書情報保存手段）
２０４ データ受信部（ディジタル証明書受信手段、属性情報受信手段）
２０９ データ送信部（新規失効情報送信手段）
２１０ データ操作管理部（第一の失効証明書情報更新手段、第二の失効証明書情報更新手段）
２０６ 失効情報確認部（認証処理手段）
２０７ 認証部（認証処理手段）
２０３ 通信制御部（通信制御手段）
ＤＣ ディジタル証明書
ＰＩ 属性データ
ＲＬ ディジタル証明書失効リスト（失効証明書情報）
ＵＣ 失効リスト更新データ（新規失効情報）

Claims (5)

1. 複数のノードによって構成されるネットワークにおけるディジタル証明書に関する情報の管理方法であって、
   前記ノードは、
   失効したディジタル証明書を示す失効証明書情報をそれぞれ有しており、
   自らの前記失効証明書情報および認証局の最新の証明書失効リストのいずれに基づいても、他のノードから提示されたディジタル証明書が失効していることを確認できない場合に、当該他のノードの属性と当該提示されたディジタル証明書とを比較することによって、当該提示されたディジタル証明書の信頼性を判別し、
   前記提示されたディジタル証明書に信頼性がないと判別した場合に、自らの前記失効証明書情報を、当該提示されたディジタル証明書がさらに示されるように更新するとともに、他のノードが有している前記失効証明書情報も同様に更新されるように、当該提示されたディジタル証明書を示す情報を当該他ノードへ送信する、
   ことを特徴とするディジタル証明書に関する情報の管理方法。
2. 情報処理装置における通信相手の認証方法であって、
   前記情報処理装置は、
   失効したディジタル証明書を示す失効証明書情報を有しており、
   通信を行う際に、当該通信の相手から当該相手のディジタル証明書を取得し、
   自らの前記失効証明書情報および認証局の最新の証明書失効リストのいずれに基づいても、前記取得したディジタル証明書が失効していることを確認できない場合に、前記相手の属性と当該取得したディジタル証明書とを比較することによって、当該取得したディジタル証明書の信頼性を判別し、
   前記取得したディジタル証明書に信頼性がないと判別した場合に、自らの前記失効証明書情報を、当該取得したディジタル証明書がさらに示されるように更新するとともに、他の情報処理装置が有している前記失効証明書情報も同様に更新されるように、当該取得したディジタル証明書を示す情報を当該他の情報処理装置へ送信する、
   ことを特徴とする通信相手の認証方法。
3. 失効したディジタル証明書を示す失効証明書情報を保存する失効証明書情報保存手段と、
   前記失効証明書情報保存手段に保存されている前記失効証明書情報および認証局の最新の証明書失効リストのいずれに基づいても、他のノードから提示されたディジタル証明書が失効していることを確認できない場合に、当該他のノードの属性と当該提示されたディジタル証明書とを比較することによって、当該提示されたディジタル証明書の信頼性を判別する、信頼性判別手段と、
   前記提示されたディジタル証明書に信頼性がないと判別された場合に、前記失効証明書情報保存手段に保存されている前記失効証明書情報を、当該提示されたディジタル証明書がさらに示されるように更新するとともに、他の情報処理装置が有している前記失効証明書情報も同様に更新されるように、当該提示されたディジタル証明書を示す情報を当該他情報処理装置へ送信する、更新処理手段と、
   を有することを特徴とする情報処理装置。
4. 他のＭＦＰ（Multi Function Peripherals）と通信を行う機能を有するＭＦＰであって、
   失効したディジタル証明書を示す失効証明書情報を保存する失効証明書情報保存手段と、
   他のＭＦＰから当該他のＭＦＰのディジタル証明書を受信するディジタル証明書受信手段と、
   他のＭＦＰから当該他のＭＦＰの属性に関する情報である属性情報を受信する属性情報受信手段と、
   他のＭＦＰの認証の処理を、前記ディジタル証明書受信手段が当該他のＭＦＰから受信したディジタル証明書が前記失効証明書情報に示されているか否かをチェックすることによって行い、当該ディジタル証明書が前記失効証明書情報に示されていない場合は、さらに当該認証の処理を当該ディジタル証明書と前記属性情報受信手段が当該他のＭＦＰから受信した前記属性情報とを比較することによって行う、認証処理手段と、
   他のＭＦＰの認証ができた場合は当該他のＭＦＰとの通信を継続することを認め、できなかった場合は当該他のＭＦＰとの通信を中止する、通信制御手段と、
   新たに失効したディジタル証明書が見つかった場合に、当該ディジタル証明書が示されるように、前記失効証明書情報を更新し、かつ、前記認証処理手段が他のＭＦＰの認証の処理を前記ディジタル証明書受信手段が当該他のＭＦＰから受信したディジタル証明書と前記属性情報受信手段が当該他のＭＦＰから受信した前記属性情報とを比較することによって行った結果、当該他のＭＦＰの認証ができなかった場合に、当該ディジタル証明書が示されるように、前記失効証明書情報を更新する、第一の失効証明書情報更新手段と、
   新たに失効したディジタル証明書が見つかった場合に、当該ディジタル証明書が失効した旨を示す新規失効情報を、通信回線を介して他のＭＦＰに送信し、かつ、前記認証処理手段が他のＭＦＰの認証の処理を前記ディジタル証明書受信手段が当該他のＭＦＰから受信したディジタル証明書と前記属性情報受信手段が当該他のＭＦＰから受信した前記属性情報とを比較することによって行った結果、当該他のＭＦＰの認証ができなかった場合に、当該ディジタル証明書についての前記新規失効情報を、通信回線を介して他のＭＦＰに送信する、新規失効情報送信手段と、
   他のＭＦＰから送信されて来た前記新規失効情報に示されるディジタル証明書が前記失効証明書情報に示されていない場合に、当該ディジタル証明書が示されるように当該失効証明書情報を更新する、第二の失効証明書情報更新手段と、
   を有することを特徴とするＭＦＰ。
5. 他の装置と通信を行う機能および失効したディジタル証明書を示す失効証明書情報を保存する失効証明書情報保存手段を有するコンピュータに用いられるコンピュータプログラムであって、
   前記コンピュータに、
   前記失効証明書情報保存手段に保存されている前記失効証明書情報および認証局の最新の証明書失効リストのいずれに基づいても、他のノードから提示されたディジタル証明書が失効していることを確認できない場合に、当該他のノードの属性と当該提示されたディジタル証明書とを比較することによって、当該提示されたディジタル証明書の信頼性を判別する処理を実行させ、
   前記提示されたディジタル証明書に信頼性がないと判別した場合に、前記失効証明書情報保存手段に保存されている前記失効証明書情報を、当該提示されたディジタル証明書がさらに示されるように更新する処理とともに、他の情報処理装置が有している前記失効証明書情報も同様に更新されるように、当該提示されたディジタル証明書を示す情報を当該他情報処理装置へ送信する処理を実行させる、
   ことを特徴とするコンピュータプログラム。