JP4915182B2 - 情報の管理方法及び情報処理装置 - Google Patents

Description

本発明は、複数のノードによって構成されるネットワークにおける情報の管理方法、及びネットワークを構成するノードとしての情報処理装置に関する。

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

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

しかし、有効期間を過ぎていなくても、ディジタル証明書の持ち主がディジタル証明書に係る秘密鍵を紛失しまたは他人に盗難されると、そのディジタル証明書の信頼性が損なわれる。そこで、認証局は、このような信頼性の損なわれたディジタル証明書を、そのシリアル番号などに関する情報を証明書失効リスト（ＣＲＬ：Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）に掲載し公開することによって、失効させる。

また、ディジタル証明書の持ち主の属性（例えば、氏名または会社名など）が変わった場合または持ち主が存在しなくなった場合にも、認証局は、そのディジタル証明書を失効させる。よって、通信相手の確認（認証）の確実性を高めるためには、ディジタル証明書の内容だけでなく失効証明書リストをも確認する必要がある。

特許文献１には、上記のような考え方に従った分散協調型のコンテンツ配信システムが提案されている。これは各クライアントにキャッシュ記憶装置を設置し、配信するコンテンツを分担して担わせ、実際のコンテンツ配信は、キャッシュインデクスを提供することで、各クライアント同士でデータやり取りするシステムとなっている。いわゆるＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）システムである。

Ｐ２Ｐシステムでの通信は、上記のような通信相手の確認（認証）がセキュリティ上、特に重要であり、上記特許文献１では、通信に用いる公開鍵証明書の検証を行っている。但し、証明書が有効であるかどうかは、状況によって変化しうることは否めず、やはり失効証明書リストをその都度確認する必要があることは同様である。
特開２００４−１８５２６３号公報

しかしながら、特許文献１によれば、公開鍵証明書の検証を行うものの、証明書検証の発信元のポリシーが許せば、毎回でなくとも、発信元が定める周期内であれば、以前の検証結果を利用する。例えば失効リストＣＲＬの次回発信日までは、前の検証結果を用いてよい。

これはセキュリティ上、問題がある。証明書の有効性は、いつどんな状況により変化するかは分からない。何らかの状況により失効した証明書が生じた場合は、タイムリーに失効リストＣＲＬに反映され、必要なクライアントにより速やかに確認されることが望まれる。

また従来より、各クライアントが定期的に認証局にＣＲＬを取得に行くことも行われていたが、これも問題がある。Ｐ２Ｐネットワークの場合、かなり頻繁に証明書の破棄が生ずる可能性がある。例えば、ノードとしての端末装置を買い換えのために破棄する場合、まさにその破棄された瞬間から、すべてのノードは破棄されたノードの証明書による接続を許容してはならない。

一定期間毎にＣＲＬを取得するような管理方法では、各ノードでＣＲＬが更新されるまでの時間差を利用して、悪意ある第三者が破棄されたはずの証明書によるネットワークへの不正な接続を行い、秘密情報を取得してしまう恐れもある。

本発明の目的は、上記のような問題を解決し、複数のノードによって構成され、各ノードが互いに認証し直接通信が可能なネットワークにおいて、ノードが脱退するなど証明書の失効が生じたとき、証明書の失効に関する情報が他の既存ノードの失効リストＣＲＬに速やかに反映され、ＣＲＬが更新されるまでの時間内に不正な接続が行われる危険を抑制できる、証明書の失効に関する情報の管理方法、及びそのネットワークを構成するノードとしての情報処理装置を提供することである。

上記の課題を解決するために、本発明は以下の特徴を有するものである。

１． 複数のノードによって構成されるネットワークにおける、ディジタル証明書に関する情報の管理方法であって、前記ネットワークから脱退するノードが、当該ノードのディジタル証明書を失効させるために、発行元である認証サーバに脱退を通知するとともに、他の既存ノードの一部あるいは全部に対して当該ノードの脱退を通知する脱退通知工程を有し、前記脱退通知工程は、前記脱退するノードが他の既存ノードの一部あるいは全部に対して脱退を通知する際に、当該ノードのディジタル証明書の失効に関する情報を合わせて配布することを特徴とする情報の管理方法。

２． 前記脱退通知工程により脱退通知を受けた前記既存ノードのそれぞれが前記認証サーバから前記脱退するノードのディジタル証明書の失効に関する情報を取得する失効情報取得工程を有することを特徴とする１に記載の情報の管理方法。

３． 前記ネットワークを構成する各ノードは、それぞれが他の既存ノードのディジタル証明書の失効に関する情報を保持しており、前記脱退通知工程により脱退通知を受けた前記既存ノードのそれぞれが、受け取った前記脱退通知に基づき、それぞれの保持する前記他の既存ノードのディジタル証明書の失効に関する情報を修正する失効情報変更工程を有することを特徴とする１に記載の情報の管理方法。

４． 前記脱退通知工程で、一時的なネットワークへの接続停止により脱退通知を受けることができなかった既存ノードが存在した場合、脱退通知を受けた既存ノードが、脱退通知を受けることができなかった既存ノードが接続復帰した時点で発信する復帰通知を受けて、当該既存ノードに、前記脱退するノードのディジタル証明書の失効に関する情報を送信する第１の失効情報提供工程を有することを特徴とする１乃至３の何れか１項に記載の情報の管理方法。

５． 前記脱退通知工程で、一時的なネットワークへの接続停止により脱退通知を受けることができなかった既存ノードが存在した場合、脱退通知を受けた既存ノードが、脱退通知を受けることができなかった既存ノードに対して、当該ノードが接続復帰し、受信するまで、前記脱退するノードのディジタル証明書の失効に関する情報を定期的に送信する第２の失効情報提供工程を有することを特徴とする１乃至３の何れか１項に記載の情報の管理方法。

６． ネットワークを構成するノードである情報処理装置であって、自らが前記ネットワークから脱退する場合に、自らのディジタル証明書を失効させるために、発行元である認証サーバに脱退を通知するとともに、前記ネットワークを構成する他の既存ノードの一部あるいは全部に対して、自らの脱退を通知する脱退通知手段を有し、前記脱退通知手段は、前記ネットワークを構成する他の既存ノードの一部あるいは全部に対して脱退を通知する際に、自らのディジタル証明書の失効に関する情報を合わせて配布することを特徴とする情報処理装置。

７． 前記脱退通知手段を有する他の既存ノードからの脱退通知に基づき、前記認証サーバから脱退するノードのディジタル証明書の失効に関する情報を取得する失効情報取得手段を有することを特徴とする６に記載の情報処理装置。

８． 前記ネットワークを構成する他の既存ノードのディジタル証明書の失効に関する情報を保持しており、前記脱退通知手段による脱退通知を受けたときに、受け取った前記脱退通知に基づき、保持している前記他の既存ノードのディジタル証明書の失効に関する情報を修正する失効情報変更手段を有することを特徴とする６に記載の情報処理装置。

９． 一時的なネットワークへの接続停止により、脱退するノードからの脱退通知を受けることができなかった既存ノードに対して、当該ノードが接続復帰した時点で発信する復帰通知を受けて、前記脱退するノードのディジタル証明書の失効に関する情報を送信する第１の失効情報提供手段を有することを特徴とする６乃至８の何れか１項に記載の情報処理装置。

１０． 一時的なネットワークへの接続停止により、脱退するノードからの脱退通知を受けることができなかった既存ノードに対して、当該ノードが接続復帰し、受信するまで、前記脱退するノードのディジタル証明書の失効に関する情報を定期的に送信する第２の失効情報提供手段を有することを特徴とする６乃至８の何れか１項に記載の情報処理装置。

本発明によれば、複数のノードによって構成され、各ノードが互いに認証し、直接通信が可能なネットワークにおいて、ノードが脱退するなど証明書の失効が生じたとき、脱退するノードが直接接続可能なすべての他の既存ノードに対して脱退通知を送信し、それぞれの保持する接続テーブルや失効リストの更新を促すことによって、証明書の失効に関する情報を他の既存ノードの失効リストＣＲＬに速やかに反映することができる。

これにより、上記ネットワークにおける、ＣＲＬが更新されるまでの時間内に不正な接続が行われる危険を抑制できる、証明書の失効に関する情報の管理方法、及びそのネットワークを構成するノードとしての情報処理装置を提供することができる。

以下に、図を参照して本発明に係る実施形態を説明する。
（ネットワークの全体構成）
図１はネットワーク１の全体的な構成の例を示す図である。図１を用いて本発明に係るネットワークの実施形態について、その全体構成を説明する。

本発明の実施形態に係るネットワーク１は、図１に示すように、複数台の端末装置２（２１、２２、…、２ｎ）、スイッチングハブ３、ルータ４、および認証サーバ５などのノードによって構成されるＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）である。これらの端末装置２は、スイッチングハブ３にツイストペアケーブルによってスター型に繋がれている。

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

また本実施形態では、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）と呼ばれる通信ネットワークの形態を採っている。Ｐ２Ｐは不特定多数のノード間で直接情報のやり取りを行なうネットワークの利用形態であり、技術的に中央サーバの媒介を要するものと、バケツリレー式にデータを運ぶものの２種類がある。

中央サーバを要する場合にも、中央サーバはファイル検索データベースの提供とノードの接続管理のみを行っており、データ自体のやり取りはノード間の直接接続によって行われている。

本実施形態では、中央サーバは用いず、後で図３の接続トポロジーを説明するが、予め関連付けられたノード（端末装置２）間では直接接続を行い、通信する。その他のノードとは、直接接続したノードを介して間接的に接続することになる。認証サーバ５は認証のための証明書に関わる管理のみを担い、通信のための接続には直接関わらない。またルータ４も端末装置間の通信には直接関与しない。

Ｐ２Ｐでは、直接ノード同士が通信するため、如何にお互いの正当性を認証するか、不正の入り込む余地を抑制するかというセキュリティが重要である。そのために認証サーバ５の発行するディジタル証明書を用いるが、証明書自体が有効であるかどうかも、各ノード自身がタイムリーに確認し、管理しておく必要がある。

以下、上記の観点から、本実施形態での管理方法を含め、これらのノードのうちの端末装置２同士がデータ通信を行う場合について説明する。
（端末装置の構成）
図２は端末装置２のハードウェア構成の例を示す図である。

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

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

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

ハードディスク２０ｄには、後で機能ブロック図（図５）を用いて説明するが、接続テーブル保持部２０１、接続テーブル管理部２０２、データ保持部２０３、データ操作部２０４、認証部２０５、ネットワーク申請部２０６、データ受信部２０７、データ解析部２０８、データ作成部２０９、およびデータ送信部２１０などの機能を実現するためのプログラムおよびデータが格納されている。これらのプログラムおよびデータは必要に応じてＲＡＭ２０ｂに読み出され、ＣＰＵ２０ａによってプログラムが実行される。

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

本実施形態では、端末装置２１、２２、…ごとに「ＰＣ１」、「ＰＣ２」、…のようなホスト名が付されているものとする。以下、これらの端末装置２をホスト名によって記載することがある。
（ノードの接続形態）
図３はノードの接続形態、すなわち端末装置２の論理的なトポロジーの例を示す図である。図３を用いてノード（端末装置）の接続形態を説明する。

端末装置２は、図３に示すように、仮想空間に配置されているものと仮想されている。そして、点線で示すように、仮想空間内の近隣の少なくとも１台の他の端末装置２と関連付けられている。かつ、これらの関連付けによって、すべての端末装置２が互いに直接的にまたは間接的に関連するようになっている。

なお、「直接的に関連」とは、図３において１本の点線で繋がれていること（例えば、図３のＰＣ１とＰＣ２またはＰＣ９とのような関係）を言い、「間接的に関連」とは、２本以上の点線および１つ以上のノードで繋がれていること（例えば、図３のＰＣ１とＰＣ４とのような関係）を言う。端末装置２は、自らに直接的に関連付けられている他の端末装置２に対してデータを送信する。

図４は図３のように関連付けられた端末装置２の接続テーブルＴＬの例を示す図である。各端末装置２毎に、直接データ送信可能な、「直接的に関連」付けられている他の端末装置２との接続のための情報のリストをテーブル化して保持している。
（端末装置の各部の機能）
図５（ａ）は端末装置２の機能的構成の例を示すブロック図である。図５（ａ）を用いて端末装置２の各部の処理機能について説明する。

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

接続テーブル管理部２０２は、上記接続テーブル保持部２０１に保持される接続テーブルＴＬの管理を行う。

データ保持部２０３は、その端末装置２またはユーザなどの属性を示す属性データ、その端末装置２自身のディジタル証明書ＤＣ、失効リストＣＲＬ、オペレーティングシステム（ＯＳ）またはアプリケーションソフトなどが使用するデータ、ユーザがアプリケーションソフトによって作成したデータ、その他種々のデータを、ファイルとして保存している。属性データには、例えば、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）、メーカ名、型式、またはドメイン名などの情報が含まれる。

ディジタル証明書ＤＣは、端末装置２の要請により認証サーバ５が発行し、当該端末装置２が保持し、端末装置２同士の通信時に互いを認証するのに利用される。失効リストＣＲＬは、端末装置の脱退などによるディジタル証明書ＤＣの失効を登録記載するもので、認証サーバ５が管理するが、Ｐ２Ｐ通信を行う本実施形態では、各端末装置２がそれぞれ失効リストＣＲＬを保持し、更新などの管理を行う。詳細については後述する。

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

認証部２０５は、他の端末装置２から送信されて来たディジタル証明書ＤＣなどに基づいて当該他の端末装置２の認証の処理を行う。また送信されて来たディジタル証明書ＤＣが失効していないかどうかを、データ保持部２０３に保存されている失効リストＣＲＬを参照して確認する。

ネットワーク申請部２０６は、当該端末装置２が新たにネットワークに参加、もしくは脱退しようとする場合の処理を行う。

データ操作部２０４、認証部２０５、ネットワーク申請部２０６は、必要に応じてデータ受信部２０７、データ送信部２１０を介してネットワーク１の他の端末装置２とデータ通信を行い、また必要に応じて接続テーブル保持部２０１、データ保持部２０３のデータを参照、あるいは更新する。

図５（ｂ）は、ネットワーク申請部２０６の機能の内部構成を示す図である。図５（ｂ）を用いてネットワーク申請部２０６の機能、すなわちネットワークに参加、もしくは脱退しようとする場合の処理機能について説明する。

ネットワーク申請部２０６には、参加、脱退の連絡などの手続きを管理する管理部２０６ａと、それに伴い失効する情報などの取得や送受信、および変更を制御する情報部２０６ｂが含まれる。これらは以下のような処理動作を行うように制御するものである。

管理部２０６ａは、例えば脱退時には認証サーバ５にディジタル証明書ＤＣの破棄要求を送信する。これにより認証サーバ５に証明書失効リスト（ＣＲＬ）を更新させ、送信されてくる証明書ＤＣの破棄完了通知を受領する。

また管理部２０６ａは、脱退時に証明書ＤＣの破棄完了通知を受領後、直接的に関連している他の端末装置２に脱退通知を送信する。これにより送信先の端末装置２に、それぞれの保持している失効リストを認証サーバ５に問い合わせて更新するように促す。すなわち、脱退通知手段として機能する。

情報部２０６ｂは、例えば脱退時には、脱退の手続きを終了後、自らの保持する所定の情報を破棄する。また他の端末装置２から脱退通知を受けた場合には、認証サーバ５に証明書失効リスト（ＣＲＬ）の発行を要求し、自らの保持する失効リストＣＲＬを更新する。すなわち、失効情報取得手段として機能する。

また場合によっては、情報部２０６ｂは他の端末装置２から脱退通知を受けた場合に、その脱退通知に基づき、あるいは合わせて配布されてきた失効リストＣＲＬに基づき、自らの保持する失効リストＣＲＬを更新する。すなわち、失効情報変更手段として機能する。

また情報部２０６ｂは、一時的な接続停止状態で脱退通知を受けられなかった他の端末装置２に対して、自らの保持する失効リストＣＲＬなどの失効に関する情報を提供し、当該端末装置２に失効に関わる情報の更新を促す。すなわち、第１及び第２の失効情報提供手段として機能する。

図５（ａ）に戻り、端末装置２の各部の説明を続ける。

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

データ解析部２０８は、データ受信部２０７が受信した受信データから必要な情報を抽出してその内容を解析することによって、その受信データの種類を判別する。

データ作成部２０９は、データ操作部２０４、認証部２０５、またはネットワーク申請部２０６などの指示に基づいて、他の端末装置２に送信するための送信データを作成する。

データ送信部２１０は、送信データ作成部２０９によって生成された送信データをパケット化して他の端末装置２に送信する。
（ディジタル証明書ＤＣと失効リストＣＲＬ）
ディジタル証明書ＤＣは、一般に、それを必要とする者からの申請に従って認証サーバ５によって発行される。そして、認証サーバ５から申請者の端末装置２に送信される。本実施形態においては、ネットワーク１を構成する端末装置２ごとにディジタル証明書ＤＣが発行され与えられているものとする。

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

また、本実施形態では、端末装置２は、認証サーバ５の保持する証明書失効リスト（ＣＲＬ）とは別に、失効したディジタル証明書ＤＣを示す失効リストＣＲＬをそれぞれ独自に有している。

失効リストＣＲＬは、認証サーバ５などが公開する証明書失効リスト（ＣＲＬ）の内容に合わせて適宜更新される。つまり、失効したディジタル証明書ＤＣの情報が次々に登録される。ただし、認証サーバ５などがダウンし、通信回線の障害が発生し、または認証サーバ５に接続できないようにファイアウォール等で設定されている場合のために、他の方法によっても、失効したディジタル証明書ＤＣの情報が次々に登録される。

後述するが、本実施形態では、他の端末装置２の脱退による失効を、必ずしも認証サーバ５を介さずに速やかに各端末装置の保持する失効リストＣＲＬに反映する形態を採用している。

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

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

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

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

証明書情報ＤＣｃは、そのディジタル証明書ＤＣ自身の属性の情報であり、例えば、シリアル番号、登録日、または有効期間などの情報を含む。「シリアル番号」は、そのディジタル証明書ＤＣを一意に識別するための番号である。「登録日」は、そのディジタル証明書ＤＣが発行された日を示す。「有効期間」は、そのディジタル証明書ＤＣが有効である期間の始期および終期を示す。

なお、一般的なディジタル証明書ＤＣおよび失効リストＣＲＬの標準仕様は、ＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ）によってＸ．５０９として定められている。以下のＳＳＬ通信の説明においては、ディジタル証明書をＸ．５０９証明書と呼称する。
（ノード間のＳＳＬ通信）
ところで、本実施形態における端末装置２は、直接的にまたは間接的に関連付けられた端末装置２との間でＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）通信を行うことができる。ＳＳＬは、ディジタル証明書ＤＣを用いて暗号化を行うことにより、ネットワーク上でデータを安全に送受信するためのプロトコルである。本実施形態におけるＳＳＬ通信のコネクションを確立する処理の流れについて、以下に説明する。

図７はＳＳＬ通信のコネクションを確立する際の処理の流れの例を説明するための図である。図３の端末装置、例えばＰＣ１とＰＣ２とが目的の通信を行おうとする場合を例に、図７を参照しながらさらに詳細に説明する。

ＳＳＬ通信のコネクションを確立する前段階として、接続自体の確立が行われる。まず、例えばＰＣ１において、ＰＣ２と通信を行いたい旨のコマンドをユーザがキーボードなどを操作して入力したとする。すると、データ作成部２０９は接続要求データを作成し、データ送信部２１０はその接続要求データを他方の端末装置ＰＣ２に対して送信する。

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

ＰＣ１のデータ受信部２０７によって接続許可データが受信され、その後所定の処理が行われると、ＰＣ１とＰＣ２とが接続される。ただし、この時点では、未だＳＳＬ通信のコネクションは確立されておらず、この後ＳＳＬ通信のコネクション確立のフローに入る。

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

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

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

次いでＰＣ１において、Ｘ．５０９ディジタル証明書ＤＣをＰＣ１に送信する。このＸ．５０９証明書ＤＣが周知の認証サーバ５によって署名されたものでなければ、そこに達するまでの証明書のチェーンも送信する。ＰＣ１においては認証サーバ５自身を証明するルート証明書を予め保持しており、そのなかにＰＣ２から受信したＸ．５０９証明書ＤＣを署名したものがあるかどうかを検証する。また当該証明書ＤＣが、その署名を行った認証サーバ５の発行した証明書失効リスト（ＣＲＬ）に記載がないかどうかを確認し、もし記載があればこの時点で通信を終了する（ステップＳ１３）。

上記認証処理をクリアすれば、この後、ＰＣ２は、応答終了の旨をＰＣ１に対して通知する（ステップＳ１４）。

ＰＣ２からの応答終了の通知を受けて、ＰＣ１は、ＳＳＬ通信で使用する共通鍵を生成するために、３８４ビットのランダムな値であるプリマスターキーＰＭＫを生成する。ＰＣ１のデータ作成部２０９は、プリマスターキーＰＭＫを、ＰＣ２より受け取ったＸ．５０９証明書ＤＣに含まれるＰＣ２の公開鍵ＤＣｋによって暗号化してＰＣ２に送信する（ステップＳ１５）。

また、ＰＣ１はこのプリマスターキーＰＭＫを基に、実際にデータの暗号化に使用する共通鍵を生成して、通信用の暗号鍵をその共通鍵に切り替えるように制御を行う。また暗号鍵を切り替える旨の暗号切り替え通知をＰＣ２に送信する（ステップＳ１６）。

ＰＣ１からの暗号切り替え終了の通知を受けると（ステップＳ１７）、ＰＣ２においても、暗号鍵の切り替えを行うべく、ＰＣ１に暗号切り替えの通知を送信する（ステップＳ１８）。ＰＣ２のデータ受信部２０７は、ＰＣ１から受信した自らの公開鍵ＤＣｋで暗号化されたプリマスターキーＰＭＫを、対応する自らの秘密鍵で復号する。データ解析部２０８がこれを解析することによってデータの種類がプリマスターキーＰＭＫであることを確認すると、データ操作部２０４は、受信したプリマスターキーＰＭＫを基に共通鍵を生成し、以後、ＰＣ１との間ではその共通鍵による暗号化通信が行われるように制御を行う。つまり、暗号鍵の切替えを行う。

ＰＣ２は、上記暗号鍵の切り替えを終了すると、ＰＣ１に暗号切り替え終了の通知を送信する（ステップＳ１９）。

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

なお、上述したコネクションの確立は、ＰＣ２のＸ．５０９証明書ＤＣをＰＣ１が確認する場合を示したが、同時にＰＣ１のＸ．５０９証明書ＤＣをＰＣ２が確認する場合もある。これをＳＳＬクライアント認証通信と呼ぶ。

このＳＳＬクライアント認証通信をＰＣ同士、および認証サーバとの間で行うためには、各々がＸ．５０９証明書ＤＣを保持している必要があり、また証明書ＤＣを検証するためにルート証明書も保持している必要がある。

このようにして、ネットワーク１の各端末装置２は、互いに認証されたノードとして安全に通信する動作を果たすことができる。

しかしながら、一旦認証サーバ５により署名された証明書ＤＣであっても、各種の事情により失効する場合がある。例えば特定の端末装置２が破棄されるため、ネットワーク１から脱退するようなケースである。

このような場合、前述したように、認証サーバ５により発行される証明書失効リスト（ＣＲＬ）に記載され、その失効リスト（ＣＲＬ）を確認することにより、各既存ノードである端末装置２は、破棄対象のノードである端末装置２がネットワーク１から脱退したことを知ることができる。しかしながら、その手続きが迅速に行われないと、例えば脱退の動作開始時点から、各既存ノードが失効リスト（ＣＲＬ）を確認するまでの時間差に乗じて、破棄されたはずの端末装置がネットワーク１の任意の既存ノードにアクセスしてしまうといったことが生ずる可能性がある。

本実施形態では、そういった危険を回避するため、以下に説明するような、端末装置２がノードを脱退するときの処理方法を採用している。以下、各端末装置をノードと呼称して、端末装置２（ノード）が脱退するときの処理を説明する。
（ノード脱退時の処理例１）
図８は、破棄対象ノード２Ｄがネットワーク１から脱退するときの処理例１について、そのシーケンスを示す図である。図９は、同じく破棄対象ノード２Ｄがネットワーク１から脱退するときの処理例１の手順を示すフローチャートである。図８および図９を参照して、破棄対象ノード２Ｄがネットワーク１から脱退するときの処理例１を説明する。

ノード脱退時の処理に関わってくるのは、脱退する破棄対象ノード２Ｄと認証サーバ５、およびその他の既存ノード２Ａである。図８にはその３種のノードについて、処理動作をそのシーケンスに応じて記載している。各処理動作に付した符号は、図９のフローチャートにおける対応する各ステップの符号と同じである。

まずステップＳ２１として、破棄対象ノード２Ｄは認証サーバ５に対して、証明書破棄要求を送信する。これは破棄対象ノード２Ｄのネットワーク申請部２０６により脱退のための手続きとして制御され、データ作成部２０９で作成された証明書破棄要求がデータ送信部２１０により送信される。

ステップＳ２２で、認証サーバ５が破棄対象ノード２Ｄからの証明書破棄要求を受信すると、保持している証明書破棄リストに破棄対象ノード２Ｄのディジタル証明書ＤＣを含め、それを基に証明書失効リスト（ＣＲＬ）を更新し、破棄対象ノード２Ｄの証明書失効を記載する。

次いでステップＳ２３では、認証サーバ５は、証明書失効リスト（ＣＲＬ）の更新後、破棄対象ノード２Ｄへ証明書破棄完了通知を送信する。ＳＳＬ通信は開始時にコネクション確立しているため、通信中に前記証明書失効リスト（ＣＲＬ）が変更されても証明書破棄完了通知の送信には支障ない。

ステップＳ２４では、破棄対象ノード２Ｄは証明書破棄完了通知を受けると、自身の保持する接続テーブルＴＬに記載したすべての他の既存ノード２Ａに対して、脱退通知を送信する。これも同様にネットワーク申請部２０６により制御され、接続テーブル保持部２０１を参照し、データ作成部２０９、データ送信部２１０を介して送信される。

このように、ステップＳ２１からステップＳ２４の工程は、脱退通知工程として機能する。

ステップＳ２５では、脱退通知を受信した各既存ノード２Ａは、各々が接続テーブル保持部２０１に保持している接続テーブルＴＬを接続テーブル管理部２０２の制御により更新する。つまり、破棄対象ノード２Ｄとの関連づけを削除する。

次いでステップＳ２６で、接続テーブルＴＬを更新した各既存ノード２Ａは、破棄対象ノード２Ｄに脱退受領通知を送信する。

ステップＳ２７で、破棄対象ノード２Ｄは所定の時間応答を待った後に、自身の保持している所定の情報をすべて破棄する。ここで所定の時間応答を待つのは、自身の保持している接続テーブルＴＬに記載の関連する既存ノードすべてと問題なく通信が可能かどうかは不定であることによる。

一時的に通信が不可であるような既存ノードがあった場合は、可能になった時点で速やかに手順が遂行されるような処置が必要であるが、そのような場合については後述する。

ステップＳ２８では、接続テーブルＴＬを変更し、脱退受領通知を返信した各既存ノード２Ａは、認証サーバ５に対して、ＣＲＬ要求を送信する。

ステップＳ２９で、各既存ノード２ＡからのＣＲＬ要求を受けた認証サーバ５は、各既存ノード２Ａに対して最新の失効リスト（ＣＲＬ）を発行する。

ステップＳ３０では、認証サーバ５から最新のＣＲＬ発行を受けた各既存ノード２Ａは、受信した失効リスト（ＣＲＬ）に基づき、自身のデータ保持部２０３に保持している失効リストＣＲＬを更新する。

ステップＳ２８からステップＳ３０の工程は、ネットワーク申請部２０６によって制御され、データ作成部２０９、データ送信部２１０を介してＣＲＬ要求が送信され、またデータ操作部２０４によりデータ保持部２０３の失効リストＣＲＬなどが更新される。

従って、ステップＳ２８からステップＳ３０の工程は、失効情報取得工程として機能する。

上述のような脱退時のシーケンスをとることで、破棄対象ノード２Ｄが破棄されたそのときに、他の既存ノード２Ａも速やかに失効リストＣＲＬを取得し、かつＳＳＬを保ったまますべての通信を行うことができる。

以上のように、ネットワーク１から破棄対象ノード２Ｄが脱退するに当たり、自らが関連付けられたすべての他の既存ノード２Ａに対して脱退通知を送信し、それぞれの保持する接続テーブルＴＬや失効リストＣＲＬの更新を促すことによって、破棄対象ノード２Ｄの失効が他の既存ノード２Ａの失効リストＣＲＬに反映されるまでの時間内に不正な接続が行われる危険を避けることができる。
（ノード脱退時の処理例２）
例えば電源が停止していることにより、一時的に接続停止となり、通信が不可であるような既存ノード２Ｃがあった場合の例を処理例２として以下に述べる。処理例２は、接続が可能になった時点で速やかに手順が遂行されるような処置を行うものである。

図１０は、破棄対象ノード２Ｄがネットワーク１から脱退するときに、一時的に電源停止した既存ノード２Ｃがあった場合の処理例２について、そのシーケンスを示す図である。図１１は、同じく処理例２の手順を示すフローチャートである。

図１０および図１１を参照して、一時的に通信が不可であるような既存ノード２Ｃがあった場合の処理例２を説明する。但し、処理例１と同様のステップについては、詳細は略す。

ノード脱退時の処理に関わってくるのは、脱退する破棄対象ノード２Ｄと認証サーバ５、その他の既存ノード２Ａおよび電源ＯＦＦノード２Ｃである。図１０にはその４種のノードについて、処理動作をそのシーケンスに応じて記載している。各処理動作に付した符号は、やはり図１１のフローチャートにおける対応する各ステップの符号と同じである。

まずステップＳ２１からステップＳ２４までは、処理例１の場合と同様であり、説明は省略する。すなわち、破棄対象ノード２Ｄが、自身の保持する接続テーブルＴＬに記載したすべての他の既存ノード２Ａに脱退通知するまでの処理は、すべて処理例１と同様である。

次いでステップＳ３１で、他の既存ノード２Ａと電源ＯＦＦノード２Ｃとで処理が異なってくる。すなわち、タイムアウトしなかった、脱退通知を受領した既存ノード２Ａに対しては、処理Ａのステップに進む。図１４に処理Ａのフローチャートを示す。図１４のステップＳ２５からステップＳ３０については、処理例１のステップＳ２５からステップＳ３０の処理と全く同様であり、説明は省略する。

この処理Ａのフローは、一方で脱退通知を受領していない電源ＯＦＦノード２Ｃがあっても、それとは独立して各々の失効リストＣＲＬを更新して処理例１と同様の処理をすべて終了してしまうものである。

一方ステップＳ３１で脱退通知の受領がタイムアウトしたノード、すなわち電源ＯＦＦノード２Ｃに対しては、ステップＳ３２以下に進む。すなわち、ステップＳ３２からは電源停止で一時的に接続不可となっていた電源ＯＦＦノード２Ｃが電源復帰し、接続可能となってからのフローである。

ステップＳ３２で電源ＯＦＦノード２Ｃが電源復帰すると、次いでステップＳ３３で、電源復帰ノード２Ｃは即座に関連する既存ノード２Ａに接続し、復帰通知として電源ＯＮ通知を送信する。

ステップＳ３４では、電源ＯＮ通知を受領した既存ノード２Ａは、自身の保持している接続テーブルＴＬと失効リストＣＲＬとを電源復帰ノード２Ｃに送信する。

ステップＳ３５で、電源復帰ノード２Ｃは受信した既存ノード２Ａの接続テーブルＴＬと失効リストＣＲＬとに基づいて、自身の保持している接続テーブルＴＬ及び失効リストＣＲＬを更新する。

ステップＳ３３からステップＳ３５の工程は、ネットワーク申請部２０６によって制御され、データ保持部２０３を参照し、データ作成部２０９、データ送信部２１０を介して失効に関する情報が送信され、またデータ操作部２０４によりデータ保持部２０３の失効リストＣＲＬなどが更新される。

従って、ステップＳ３３からステップＳ３５の工程は、第１の失効情報提供工程として機能する。

このような脱退時のシーケンスをとることで、破棄対象ノード２Ｄが破棄されたそのときに、電源が停止しているなど、一時的に接続不可の既存ノード２Ｃがあっても、接続が回復した時点で速やかに失効リストＣＲＬを取得し、かつＳＳＬも保ったまますべての通信を行うことができる。

以上のように、ネットワーク１から破棄対象ノード２Ｄが脱退するに当たり、自らが関連付けられたすべての他の既存ノード２Ａに対して脱退通知を送信し、それぞれの保持する接続テーブルＴＬや失効リストＣＲＬの更新を促すとともに、一時的に接続不可のノード２Ｃがあっても、接続回復時にそれに応答して他の既存ノード２Ａから失効リストＣＲＬを提供することによって、破棄対象ノード２Ｄの失効が他の既存ノード２Ａ及び２Ｃの失効リストＣＲＬに反映されるまでの時間内に不正な接続が行われる危険を避けることができる。
（ノード脱退時の処理例３）
例えば接続不良やトラブルなど、あるいはネットワーク管理上の理由などにより、一時的に接続停止となり、通信が不可であるような既存ノード２Ｂがあった場合の例を処理例３として以下に述べる。処理例３は、処理例２と同様に接続が可能になった時点で速やかに手順が遂行されるような処置を行うものである。

図１２は、破棄対象ノード２Ｄがネットワーク１から脱退するときに、一時的に接続できない既存ノード２Ｂがあった場合の処理例３について、そのシーケンスを示す図である。図１３は、同じく処理例３の手順を示すフローチャートである。

図１２および図１３を参照して、一時的に通信が不可であるような既存ノード２Ｂがあった場合の処理例３を説明する。但し、処理例１と同様のステップについては、詳細は略す。

ノード脱退時の処理に関わってくるのは、脱退する破棄対象ノード２Ｄと認証サーバ５、その他の既存ノード２Ａおよび接続ＯＦＦノード２Ｂである。図１２にはその４種のノードについて、処理動作をそのシーケンスに応じて記載している。各処理動作に付した符号は、やはり図１３のフローチャートにおける対応する各ステップの符号と同じである。

まずステップＳ２１からステップＳ２３までは、処理例１の場合と同様であり、説明は省略する。しかし、ステップＳ２４ａについては、処理例１のステップＳ２４と若干異なる。すなわち、ステップＳ２４ａでは破棄対象ノード２Ｄが、自身の保持する接続テーブルＴＬに記載したすべての他の既存ノード２Ａに脱退通知するとともに、自身の保持する接続テーブルＴＬも送信する。送信する相手は既存ノード２Ａの一部であってもよい。これは、後述するように、受領した既存ノード２Ａが接続ＯＦＦノード２Ｂに対して、ＣＲＬ通知を送信するためである。

次に処理Ａのステップに進む。図１４に処理Ａのフローチャートを示す。図１４のステップＳ２５からステップＳ３０については、処理例１のステップＳ２５からステップＳ３０の処理と全く同様であり、説明は省略する。

この処理Ａのフローは、一方で脱退通知を受領していない接続ＯＦＦノード２Ｂがあっても、先行して各々の失効リストＣＲＬを更新して処理例１と同様の処理をすべて終了してしまうものである。

次にステップＳ４１では、破棄対象ノード２Ｄから接続テーブルＴＬを受信した既存ノード２Ａが、任意の間隔でＣＲＬ通知を送信する。目的は接続ＯＦＦノード２Ｂへの送信であるが、その送信先はステップＳ２４ａで受領した破棄対象ノード２Ｄの接続テーブルＴＬに基づいて選択される。

このＣＲＬ通知には、失効リストＣＲＬと接続テーブルＴＬとが含まれている。しかし、接続ＯＦＦノード２Ｂが接続復帰するまでは、タイムアウトになってしまう。そのために受領されるまで、定期的に送信を続ける。

ステップＳ４２およびステップＳ４３でタイムアウトになり、接続が復帰していない場合には、ステップＳ４１に戻り、任意間隔でのＣＲＬ通知送信を続行する。

ステップＳ４２およびステップＳ４３でタイムアウトでなくなり、接続が復帰した場合には、接続復帰ノード２ＢにＣＲＬ通知が受領されたということでステップＳ４４に進む。すなわち、ステップＳ４４からは一時的に接続不可となっていた接続ＯＦＦノード２Ｂが接続復帰し、ＣＲＬ通知を受領してからのフローである。

ステップＳ４４では、既存ノード２ＡからＣＲＬ通知、すなわち失効リストＣＲＬと接続テーブルＴＬを受信した接続復帰ノード２Ｂは、発信した既存ノード２ＡにＣＲＬ受領通知を送信する。これに基づき、既存ノード２Ａは任意間隔でのＣＲＬ通知送信を停止する。

ステップＳ４５で、接続復帰ノード２Ｂは受信した既存ノード２Ａからの接続テーブルＴＬと失効リストＣＲＬとに基づいて、自身の保持している接続テーブルＴＬ及び失効リストＣＲＬを更新する。

ステップＳ４１からステップＳ４５の工程は、ネットワーク申請部２０６によって制御され、データ保持部２０３を参照し、データ作成部２０９、データ送信部２１０を介して失効に関する情報が送信され、またデータ操作部２０４によりデータ保持部２０３の失効リストＣＲＬなどが更新される。

従って、ステップＳ４１からステップＳ４５の工程は、第２の失効情報提供工程として機能する。

上述のようなシーケンスをとることで、破棄対象ノード２Ｄが破棄されたそのときに、回線不良などで一時的に接続不可の既存ノード２Ｂがあっても、接続が回復した時点で速やかに失効リストＣＲＬを取得し、かつＳＳＬも保ったまますべての通信を行うことができる。

以上のように、ネットワーク１から破棄対象ノード２Ｄが脱退するに当たり、自らが関連付けられたすべての他の既存ノード２Ａに対して脱退通知を送信し、それぞれの保持する接続テーブルＴＬや失効リストＣＲＬの更新を促すとともに、一時的に接続不可のノード２Ｂがあっても、接続回復時に速やかに取得できるよう、他の既存ノード２ＡからＣＲＬ通知を送信継続することによって、破棄対象ノード２Ｄの失効が他の既存ノード２Ａ及び２Ｂの失効リストＣＲＬに反映されるまでの時間内に不正な接続が行われる危険を避けることができる。
（ノード脱退時の処理例１ｂ）
図８および図９を参照して前述した、破棄対象ノード２Ｄがネットワーク１から脱退するときの処理例１に対する変形として、別の処理例１ｂを説明する。

図１５は、破棄対象ノード２Ｄがネットワーク１から脱退するときの処理例１の変形となる別の処理例１ｂのシーケンスを示す図である。図１６は、同じく破棄対象ノード２Ｄがネットワーク１から脱退するときの処理例１ｂの手順を示すフローチャートである。図１５および図１６を参照して、破棄対象ノード２Ｄがネットワーク１から脱退するときの処理例１ｂを説明する。

ノード脱退時の処理に関わってくるのは、脱退する破棄対象ノード２Ｄと認証サーバ５、およびその他の既存ノード２Ａである。図１５にはその３種のノードについて、処理動作をそのシーケンスに応じて記載している。各処理動作に付した符号は、図１６のフローチャートにおける対応する各ステップの符号と同じである。以下の図１５、図１６の各ステップの説明において、処理例１と同様の場合については説明を省略し、異なる点を主体に説明する。

まずステップＳ２１とステップＳ２２は、処理例１と同様であり、説明は略す。

次いでステップＳ２３ｂは処理例１のステップＳ２３と少し異なり、認証サーバ５は、証明書失効リスト（ＣＲＬ）の更新後、破棄対象ノード２Ｄへ証明書破棄完了通知を送信するとともに、更新した証明書失効リスト（ＣＲＬ）を合わせて送信する。ＳＳＬ通信は開始時にコネクション確立しているため、通信中に前記証明書失効リスト（ＣＲＬ）が変更されても証明書破棄完了通知の送信には支障ない。

ステップＳ２４ｂも処理例１のステップＳ２４とは異なり、破棄対象ノード２Ｄは証明書破棄完了通知を受けると、自身の保持する接続テーブルＴＬに記載したすべての他の既存ノード２Ａに対して、脱退通知を送信するとともに、自らの証明書が失効した失効リストＣＲＬを合わせて配布する。また、失効リストＣＲＬの配布を行わない場合も考えられる。その場合は、後述するようにステップＳ３０での処理が異なってくる。

このように、ステップＳ２１からステップＳ２４ｂの工程は、脱退通知工程として機能する。

ステップＳ２５とステップＳ２６は、処理例１と同様であり、説明は省略する。

ステップＳ２７も処理例１と同様である。破棄対象ノード２Ｄは所定の時間応答を待った後に、自身の保持している所定の情報をすべて破棄する。

一時的に通信が不可であるような既存ノードがあった場合は、可能になった時点で速やかに手順が遂行されるような処置が必要であるが、そのような場合は、上述した処理例２や処理例３が処理例１の場合と同様にして適用できる。

処理例１におけるステップＳ２８及びステップＳ２９のＣＲＬ要求や最新の失効リスト（ＣＲＬ）発行の処理は、この処理例１ｂでは必要としない。これはステップＳ２４ｂで、既に失効リストの配布を行っているためである。

ステップＳ３０では、ステップＳ２４ｂで脱退通知とともに受領した失効リストＣＲＬに基づき、自身のデータ保持部２０３に保持している失効リストＣＲＬを更新する。あるいは、ステップＳ２４ｂで失効リストＣＲＬの配布を受けていない場合は、脱退通知を受けて、直接に自らの保持する失効リストＣＲＬを書き換える処理を行ってもよい。その場合、認証サーバ５による署名入りの失効リスト（ＣＲＬ）に基づく更新ではないため、定期的に確認の動作を行うなどの処理で補完されることが望ましい。

ステップＳ３０の工程は、ネットワーク申請部２０６によって制御され、データ操作部２０４によりデータ保持部２０３の失効リストＣＲＬなどが更新される。

このように、ステップＳ３０の工程は失効情報変更工程として機能する。

上述のような脱退時のシーケンスをとることで、破棄対象ノード２Ｄが破棄されたそのときに、他の既存ノード２Ａも速やかに失効リストＣＲＬを更新し、かつＳＳＬを保ったまますべての通信を行うことができる。

以上のように、ネットワーク１から破棄対象ノード２Ｄが脱退するに当たり、自らが関連付けられたすべての他の既存ノード２Ａに対して脱退通知を送信し、それぞれの保持する接続テーブルＴＬや失効リストＣＲＬの更新を促すことによって、破棄対象ノード２Ｄの失効が他の既存ノード２Ａの失効リストＣＲＬに反映されるまでの時間内に不正な接続が行われる危険を避けることができる。

なお本発明の範囲は、上記実施形態に限定されるものではない。本発明の趣旨を逸脱しない限り、それらの変更された形態もその範囲に含むものである。

ネットワーク１の全体構成例を示す図である。 ネットワーク１を構成する端末装置２のハードウェア構成例を示す図である。 ネットワーク１を構成する各端末装置２の接続形態、すなわちノードの論理的なトポロジーの例を示す図である。 図３のように関連付けられた端末装置２の接続テーブルＴＬ例を示す図である。 端末装置２の機能構成例を示すブロック図（ａ）、およびネットワーク申請部２０６の機能の内部構成を示す図（ｂ）である。 ディジタル証明書ＤＣの例を示す図である。 ＳＳＬ通信のコネクションを確立する際の処理例を説明するためのシーケンス図である。 破棄対象ノード２Ｄがネットワーク１から脱退するときの処理例１について、そのシーケンスを示す図である。 破棄対象ノード２Ｄがネットワーク１から脱退するときの処理例１の手順を示すフローチャートである。 破棄対象ノード２Ｄがネットワーク１から脱退するときに、一時的に電源停止した既存ノード２Ｃがあった場合の処理例２について、そのシーケンスを示す図である。 破棄対象ノード２Ｄがネットワーク１から脱退するときに、一時的に電源停止した既存ノード２Ｃがあった場合の処理例２の手順を示すフローチャートである。 破棄対象ノード２Ｄがネットワーク１から脱退するときに、一時的に接続できない既存ノード２Ｂがあった場合の処理例３について、そのシーケンスを示す図である。 破棄対象ノード２Ｄがネットワーク１から脱退するときに、一時的に接続できない既存ノード２Ｂがあった場合の処理例３の手順を示すフローチャートである。 処理Ａのフローチャートを示す。 破棄対象ノード２Ｄがネットワーク１から脱退するときの処理例１ｂについて、そのシーケンスを示す図である。 破棄対象ノード２Ｄがネットワーク１から脱退するときの処理例１ｂの手順を示すフローチャートである。

符号の説明

１ ネットワーク（Ｐ２Ｐ）
２ 端末装置（ノード）
２Ａ 既存ノード
２Ｂ 接続ＯＦＦノード
２Ｃ 電源ＯＦＦノード
２Ｄ 破棄対象ノード
３ スイッチングハブ
４ ルータ
５ 認証サーバ
２０１ 接続テープ保持部
２０２ 接続テーブル管理部
２０３ データ保持部
２０４ データ操作部
２０５ 認証部
２０６ ネットワーク申請部
２０６ａ 管理部
２０６ｂ 情報部
２０７ データ受信部
２０８ データ解析部
２０９ データ作成部
２１０ データ送信部
ＤＣ ディジタル証明書
ＴＬ 接続テーブル

Claims (10)

1. 複数のノードによって構成されるネットワークにおける、ディジタル証明書に関する情報の管理方法であって、
   前記ネットワークから脱退するノードが、当該ノードのディジタル証明書を失効させるために、発行元である認証サーバに脱退を通知するとともに、他の既存ノードの一部あるいは全部に対して当該ノードの脱退を通知する脱退通知工程を有し、
   前記脱退通知工程は、前記脱退するノードが他の既存ノードの一部あるいは全部に対して脱退を通知する際に、当該ノードのディジタル証明書の失効に関する情報を合わせて配布することを特徴とする情報の管理方法。
2. 前記脱退通知工程により脱退通知を受けた前記既存ノードのそれぞれが前記認証サーバから前記脱退するノードのディジタル証明書の失効に関する情報を取得する失効情報取得工程を有することを特徴とする請求項１に記載の情報の管理方法。
3. 前記ネットワークを構成する各ノードは、それぞれが他の既存ノードのディジタル証明書の失効に関する情報を保持しており、
   前記脱退通知工程により脱退通知を受けた前記既存ノードのそれぞれが、受け取った前記脱退通知に基づき、それぞれの保持する前記他の既存ノードのディジタル証明書の失効に関する情報を修正する失効情報変更工程を有することを特徴とする請求項１に記載の情報の管理方法。
4. 前記脱退通知工程で、一時的なネットワークへの接続停止により脱退通知を受けることができなかった既存ノードが存在した場合、
   脱退通知を受けた既存ノードが、脱退通知を受けることができなかった既存ノードが接続復帰した時点で発信する復帰通知を受けて、当該既存ノードに、前記脱退するノードのディジタル証明書の失効に関する情報を送信する第１の失効情報提供工程を有することを特徴とする請求項１乃至３の何れか１項に記載の情報の管理方法。
5. 前記脱退通知工程で、一時的なネットワークへの接続停止により脱退通知を受けることができなかった既存ノードが存在した場合、
   脱退通知を受けた既存ノードが、脱退通知を受けることができなかった既存ノードに対して、当該ノードが接続復帰し、受信するまで、前記脱退するノードのディジタル証明書の失効に関する情報を定期的に送信する第２の失効情報提供工程を有することを特徴とする請求項１乃至３の何れか１項に記載の情報の管理方法。
6. ネットワークを構成するノードである情報処理装置であって、
   自らが前記ネットワークから脱退する場合に、自らのディジタル証明書を失効させるために、発行元である認証サーバに脱退を通知するとともに、前記ネットワークを構成する他の既存ノードの一部あるいは全部に対して、自らの脱退を通知する脱退通知手段を有し、
   前記脱退通知手段は、前記ネットワークを構成する他の既存ノードの一部あるいは全部に対して脱退を通知する際に、自らのディジタル証明書の失効に関する情報を合わせて配布することを特徴とする情報処理装置。
7. 前記脱退通知手段を有する他の既存ノードからの脱退通知に基づき、前記認証サーバから脱退するノードのディジタル証明書の失効に関する情報を取得する失効情報取得手段を有することを特徴とする請求項６に記載の情報処理装置。
8. 前記ネットワークを構成する他の既存ノードのディジタル証明書の失効に関する情報を保持しており、
   前記脱退通知手段による脱退通知を受けたときに、受け取った前記脱退通知に基づき、保持している前記他の既存ノードのディジタル証明書の失効に関する情報を修正する失効情報変更手段を有することを特徴とする請求項６に記載の情報処理装置。
9. 一時的なネットワークへの接続停止により、脱退するノードからの脱退通知を受けることができなかった既存ノードに対して、
   当該ノードが接続復帰した時点で発信する復帰通知を受けて、前記脱退するノードのディジタル証明書の失効に関する情報を送信する第１の失効情報提供手段を有することを特徴とする請求項６乃至８の何れか１項に記載の情報処理装置。
10. 一時的なネットワークへの接続停止により、脱退するノードからの脱退通知を受けることができなかった既存ノードに対して、
    当該ノードが接続復帰し、受信するまで、前記脱退するノードのディジタル証明書の失効に関する情報を定期的に送信する第２の失効情報提供手段を有することを特徴とする請求項６乃至８の何れか１項に記載の情報処理装置。

Images