JP5012173B2 - 暗号通信処理方法及び暗号通信処理装置 - Google Patents

Description

本発明は、ネットワークを構成するノードとしての暗号通信処理装置の間で、暗号通信を行うための暗号通信処理方法、及び暗号通信処理装置に関する。

近年、ネットワークを構成する任意のノード間で自由にデータの送受信を行うような通信形態を有するネットワークが盛んに利用されるようになってきた。

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

こういった分散処理のネットワーク形態では、ノードを探索したり、ログを収集したり、データを問い合わせたりする場合に、マルチキャストのように任意の複数のノードに同時送信するような通信形態が多用される。

しかしながら、任意のノード間で直接接続してデータの送受信を行う度に、そのための手続きが必要であり、手続きのやり方によっては、通信の効率低下とともに、一般にマルチキャストのような通信形態が困難となることもあった。また一方、任意のノード間で自由に接続して通信を行うための手続きをできるだけ簡略化し、マルチキャスト方式の通信も可能な状態にしようとすると、第三者による通信の傍受など安全面においての危険性が増してくるという傾向があった。

例えば、インターネットで用いられる代表的な通信プロトコルとして、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）やＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）があるが、やはり上記のような一長一短の傾向が見られる。すなわちＴＣＰでは、安全性、信頼性において優れるが、その手続きのためにマルチキャスト通信は実施できない。またＵＤＰについては、マルチキャスト通信は可能であるが、手続きが簡略化されているので、通信の安全性、信頼性は低い。

通信の安全性を高めるためには、一般に暗号化処理がよく用いられる。ＵＤＰのようなマルチキャスト通信が可能なプロトコルにおいて、暗号化処理を付加することで通信の安全性を高めることも考えられる。

暗号化通信のプロトコルとして、一般によく使用されているのは、ＩＰｓｅｃ（Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）やＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）等であるが、これらは何れもマルチキャスト通信のできないＴＣＰのプロトコル上で機能するものである。

マルチキャスト通信を可能としながら、効果的な暗号処理を行うのは難しく、暗号化を用いず安全性を高めるための技術も提案されている（例えば、特許文献１参照）。

特許文献１に開示された技術においては、通信のために接続した相手ノードのＩＤを確認し、所定のＩＤ以外は拒否することで、通信相手を特定しようとするものである。しかしながら、総当たりの試みやパケットをキャプチャすることによりＩＤを取得し、なりすますことが比較的簡単にできてしまう。また、暗号化処理ではないため、なりすましにより簡単に通信内容に入り込むことができてしまう。

ＵＤＰのようなマルチキャスト通信の可能なプロトコルでも、手続きを複雑化してマルチキャスト方式を不可能にすることなく機能する暗号化処理が望ましい。そのような暗号化処理の方法としては、従来、固定共通鍵を用いた暗号化処理が用いられてきた。

固定共通鍵を用いた暗号化処理技術は、送信側と受信側のノードが共通の暗号化鍵（すなわち、暗号化と復号化に同じ鍵を用いる）を保持しており、その鍵は固定的で変わらない、というものである。

しかしながら、この固定共通鍵を使用する暗号化処理方法では、その共通鍵は常に同じであるため容易に推測されやすく、また暗号化処理ソフトを用いることで簡単に傍受できてしまうという問題がある。

暗号化通信のために、手続きを複雑化せずに、つまりマルチキャスト通信が可能な状態を損なわずに、より安全性を向上できるような暗号化処理技術が望まれる。
特開２００５−３０３７８４号公報

上述したように、ネットワークにおけるノード間の通信において、マルチキャスト通信とセキュリティ（安全性）は、なかなか両立しがたいものがある。セキュリティのためには暗号化処理を行って通信することが望ましいが、マルチキャスト通信可能な状態を維持しながら、効果的な暗号通信の処理を行うことは困難であった。

本発明の目的は、上記の課題を解決し、ネットワークにおけるノード間の通信において、セキュリティ（安全性）を向上した効果的な暗号通信によるマルチキャストが可能である暗号通信処理方法、及びノードとしての暗号通信処理装置を提供することである。

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

１． ネットワークシステムを構成する複数のノード間で、マルチキャスト方式で暗号通信を行うための暗号通信処理方法であって、マルチキャスト方式で暗号通信を行う送信側の第１のノードと受信側の複数の第２のノードの間で、メッセージナンバーを交換する接続工程と、前記複数の第２のノードが、それぞれ認証のための情報を含むメッセージを送信し、それらを受信した前記第１のノードが、該情報に基づき、前記複数の第２のノードをそれぞれ認証する認証工程と、前記認証工程において、それぞれの認証が成功した場合に、前記第１のノードと前記複数の第２のノードの間で、それぞれ暗号鍵を作成するための情報を含むメッセージを通信し、それぞれ該情報に基づき暗号鍵を作成し、両ノードで共有化する暗号鍵作成工程と、前記第１のノードが、前記暗号鍵作成工程において作成、共有化された暗号鍵に基づき暗号化した情報を含むメッセージを、前記複数の第２のノードにマルチキャスト送信する暗号化工程と、を有し、前記暗号鍵作成工程では、前記暗号鍵を作成するための情報に基づき、前記複数の第２のノードに共通である暗号鍵が作成され、前記暗号化工程では、前記第１のノードが、前記複数の第２のノードのそれぞれに対して、前記複数の第２のノードに共通である暗号鍵を用いて送信する情報を暗号化し、メッセージナンバーを付与してマルチキャスト送信することを特徴とする暗号通信処理方法。

２． 前記暗号鍵作成工程では、前記暗号鍵を作成するための情報に基づき、前記複数の第２のノードに共通である暗号鍵とは異なる暗号鍵を作成し、前記暗号化工程では、暗号化した情報に、暗号化に用いた暗号鍵を識別するための情報を含む送信属性情報を付与して送信することを特徴とする１に記載の暗号通信処理方法。

３． 前記接続工程において交換されるメッセージナンバーは、送信ノード毎に、あるいは送受信するノードの組み合わせ毎に一意に設定され、前記第１のノードから前記複数の第２のノードのどのノードに送信されるどのメッセージにも、同一のメッセージナンバーが付与されることを特徴とする１または２に記載の暗号通信処理方法。

４． 前記メッセージナンバーは、所定のタイミングで破棄され、破棄されたメッセージナンバーに対応するノードが関わる暗号通信処理は、前記接続工程からやり直すことを特徴とする３に記載の暗号通信処理方法。

５． 前記接続工程では、前記第１のノードと前記複数の第２のノードの間で、通信プロトコルのバージョン情報と暗号化アルゴリズム設定のための情報を含む暗号通信のための設定情報が交換されることを特徴とする１乃至４の何れか１項に記載の暗号通信処理方法。

６． 前記認証工程における認証のための情報には、当該情報を送信したノードの公開鍵の情報が含まれ、前記暗号鍵作成工程における暗号鍵を作成するための情報は、前記公開鍵を用いて暗号化され、送信されることを特徴とする１乃至５の何れか１項に記載の暗号通信処理方法。

７． 任意のノードが複数の他のノードに対してマルチキャスト方式で暗号通信を行うネットワークシステムにおける、ノードとしての暗号通信処理装置であって、マルチキャストで暗号通信する複数の他のノードとの間で、メッセージナンバーを交換する接続手段と、前記複数の他のノードから、それぞれ認証のための情報を含むメッセージを受信し、受信した該情報に基づき、前記複数の他のノードをそれぞれ認証する認証手段と、前記認証手段により認証した前記複数の他のノードと、暗号鍵を作成するための情報を含むメッセージを通信し、それぞれ該情報に基づき暗号鍵を作成、共有化する暗号鍵作成手段と、前記暗号鍵作成手段により作成、共有化された暗号鍵に基づき暗号化した情報を含むメッセージを、前記複数の他のノードにマルチキャスト送信する暗号化手段と、を有し、前記暗号鍵作成手段は、前記暗号鍵を作成するための情報に基づき、前記複数の他のノードに共通である暗号鍵を作成、共有化し、前記暗号化手段は、前記複数の他のノードのそれぞれに対して、前記複数の他のノードに共通である暗号鍵を用いて送信する情報を暗号化し、メッセージナンバーを付与してマルチキャスト送信することを特徴とする暗号通信処理装置。

８． 前記暗号鍵作成手段は、前記暗号鍵を作成するための情報に基づき、前記複数の他のノードに共通である暗号鍵とは異なる暗号鍵を作成し、前記暗号化手段は、暗号化した情報に、暗号化に用いた暗号鍵を識別するための情報を含む送信属性情報を付与して送信することを特徴とする７に記載の暗号通信処理装置。

９． 前記接続手段により交換されるメッセージナンバーは、送信ノード毎に、あるいは送受信するノードの組み合わせ毎に一意に設定されたものであり、前記複数の他のノードのどのノードに送信するどのメッセージにも、同一のメッセージナンバーを付与することを特徴とする７または８に記載の暗号通信処理装置。

１０． 前記メッセージナンバーは、所定のタイミングで破棄し、破棄した後の暗号通信処理は前記接続手段によるメッセージナンバーの交換からやり直すことを特徴とする９に記載の暗号通信処理装置。

１１． 前記接続手段は、前記複数の他のノードとの間で、通信プロトコルのバージョン情報と暗号化アルゴリズム設定のための情報を含む暗号通信のための設定情報を交換することを特徴とする７乃至１０の何れか１項に記載の暗号通信処理装置。

１２． 前記認証手段により送信する認証のための情報は、送信するノードの公開鍵の情報を含み、前記暗号鍵作成手段により送信する暗号鍵を作成するための情報は、前記公開鍵を用いて暗号化することを特徴とする７乃至１１の何れか１項に記載の暗号通信処理装置。

本発明の暗号通信処理装置、及び暗号通信処理方法によれば、ネットワークにおけるノード間のマルチキャスト通信において、最初に一つ以上の共通の暗号鍵を設定しておくことで、暗号鍵固定ではなく、かつ暗号通信のための手続きでマルチキャスト通信の可能な状態を損なうこともなくなる。従ってセキュリティ（安全性）を向上した効果的な暗号通信によるマルチキャストが可能となる。

以下に、図を参照して本発明に係る実施形態を説明する。

（ネットワークの全体構成）
図１は本実施形態に係る暗号通信処理方法、及び暗号通信処理装置により構成されるネットワーク１の全体的な構成の例を示す図である。図１を用いて本発明の実施形態に係るネットワーク１について、その全体構成を説明する。

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

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

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

また、中央サーバがホストとして集中処理するような形態であっても、任意のクライアントが中央サーバとしての機能を果たすよう随時変更可能なシステムもあり、実質的には不特定多数の任意のノード間で直接情報のやり取りを行なうＰ２Ｐのシステムと同等機能を有すると見なせるようなネットワーク形態もある。

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

Ｐ２Ｐでは、直接ノード同士が通信するため、如何にお互いの正当性を認証するか、不正の入り込む余地を抑制するかというセキュリティが重要である。そのために認証サーバ５の発行するディジタル証明書を用いる。後述する暗号通信処理においては、Ｘ．５０９仕様のディジタル証明書が使用される。

ディジタル証明書の有効期間を過ぎたり、秘密鍵の紛失や盗難などでそのディジタル証明書の信頼性が損なわれと、認証局は証明書失効リスト（ＣＲＬ：Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ）に掲載し、公開することにより失効させる。

以下、上記の観点から、本実施形態に係るネットワークにおいて、これらのノード２同士が暗号通信のための接続を確立し、各ノード間で暗号による情報の送受信を行う場合について説明する。

（暗号通信処理装置の構成）
図２はノード（暗号通信処理装置）２のハードウェア構成の例を示す図である。

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

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

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

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

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

本実施形態では、ノード（暗号通信処理装置）２１、２２、…ごとに「ＰＣ１」、「ＰＣ２」、…のようなホスト名が付されているものとする。以下、これらのノード２をホスト名によって記載することがある。

（ノードの接続形態）
図３はノードの接続形態、すなわちノード２の論理的なトポロジーの例を示す図である。図３を用いてノード（暗号通信処理装置）の接続形態を説明する。

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

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

図４は、図３のように関連付けられたノード２の接続テーブルＴＬの例を示す図である。各ノード２毎に、直接データ送信可能な、「直接的に関連」付けられている他のノード２との接続のための情報のリストをテーブル化して保持している。

例えば、図３におけるＰＣ１、ＰＣ２、ＰＣ６、ＰＣ７、ＰＣ８、およびＰＣ９には、それぞれ図４に示すような接続テーブルＴＬ１、ＴＬ２、ＴＬ６、ＴＬ７、ＴＬ８、およびＴＬ９が保持されている。

（暗号通信処理装置の各部の機能）
図５（ａ）はノード（暗号通信処理装置）２の機能的構成の例を示すブロック図である。図５（ａ）を用いてノード２の各部の処理機能について説明する。

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

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

データ保持部２０３は、そのノード２またはユーザなどの属性を示す属性データ、そのノード２自身のディジタル証明書、失効リスト（ＣＲＬ）、オペレーティングシステム（ＯＳ）またはアプリケーションソフトなどが使用するデータ、ユーザがアプリケーションソフトによって作成したデータ、暗号通信処理のために必要なデータ、その他種々のデータを、ファイルとして保存している。

ディジタル証明書は、ノード２の要請により認証サーバ５が発行し、当該ノード２が保持し、ノード２同士の通信時に互いを認証するのに利用される。失効リスト（ＣＲＬ）は、ノードの脱退などによるディジタル証明書の失効を登録記載するもので、認証サーバ５が管理する。

データ操作部２０４は、データ保持部２０３にデータを保存し、またはデータ保持部２０３に保存されているデータを更新するなどの処理を行う。例えば、ノード２の環境または設定内容が変わるごとに、属性データを更新する。

またデータ操作部２０４は、他のノードから取得したデータ（情報）の処理と一時保存も行う。

認証部２０５は、他のノード２から送信されて来たディジタル証明書などに基づいて当該他のノード２の認証の処理を行う。また送信されて来たディジタル証明書が失効していないかどうかを、認証サーバ５に問い合わせるなどして確認する。

また認証部２０５は、他のノードとの暗号通信確立のための処理、及び暗号通信処理を行う。詳細は後述する。

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

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

図５（ｂ）は、認証部２０５の機能の内部構成を示す図である。図５（ｂ）を用いて認証部２０５の機能、すなわち他のノードとの暗号通信確立のための処理と暗号化の処理機能について説明する。

認証部２０５には、メッセージナンバーを交換する接続手段として機能する接続設定部２０５ａと、各ノードの認証のために必要な情報を送受信し、認証を行う認証手段として機能する認証処理部２０５ｂが含まれる。

また認証部２０５には、暗号鍵を作成するための情報を送受信し、暗号鍵を作成、共有化する暗号鍵作成手段として機能する暗号鍵作成部２０５ｃと、暗号鍵に基づき暗号化処理したデータ通信を行う暗号化手段として機能する暗号化処理部２０５ｄが含まれる。

接続設定部２０５ａ、認証処理部２０５ｂ、暗号鍵作成部２０５ｃ、そして暗号化処理部２０５ｄの各機能の詳細については、後述する暗号通信処理のフローで合わせて説明する。

図５（ａ）に戻り、ノード（暗号通信処理装置）２の各部の説明を続ける。

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

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

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

データ送信部２１０は、送信データ作成部２０９によって生成され、パケット化された送信データを他のノード２に送信する。

（ノード間のＳＳＬ通信）
ところで、本実施形態におけるノード２は、直接的にまたは間接的に関連付けられた複数のノード２に対して、マルチキャスト通信を維持するため、例えばＵＤＰのようにセッションを張らない簡略的な通信形態を想定している。従って既述したように、一般的なＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）通信を行うことはできない。しかしながらＳＳＬは、ディジタル証明書を用いて認証し、暗号化を行うことにより、ネットワーク上でデータを安全に送受信するためのプロトコルであり、本実施形態における暗号通信を確立する処理の流れとも関連する。

まず、ＳＳＬ通信のコネクション確立の処理について、以下に説明する。

なお、一般的なディジタル証明書および失効リスト（ＣＲＬ）の標準仕様は、ＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ）によってＸ．５０９として定められている。以下のＳＳＬ通信の説明においては、ディジタル証明書をＸ．５０９証明書と呼称する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（暗号通信処理）
既述したように、本実施形態におけるノード２は、直接的にまたは間接的に関連付けられた複数のノード２に対して、マルチキャスト通信を維持するため、例えばＵＤＰのようにセッションを張らない簡略的な通信形態を想定している。そういった簡略的な手続きを維持して、暗号通信を確立する、本実施形態の暗号通信処理の流れについて、図７を用いて以下に説明する。

図７は本実施形態における暗号通信処理方法の流れを示すフローチャートである。

図７のステップＳ１０１は、接続工程であり、メッセージナンバーを交換する。送信側ノード（ＰＣ１）が複数の受信側ノード（その任意のノードをＰＣＮとする）に対してマルチキャスト送信を行おうとする場合を例に、図８を参照しながら接続工程の詳細を述べる。

この接続工程は、すべての受信側ノード（任意のＰＣＮ）に対して独立して行ってもよい。引き続く、ステップＳ１０２の認証工程、ステップＳ１０３の暗号鍵作成工程も同様である。但し、ステップＳ１０４の暗号化工程はマルチキャストであり、すべての受信側ノード（すべてのＰＣＮ）に対して同時に行われる。従ってそれまでにすべての受信側ノードで上記３工程が終了していなければならない。

＜接続工程＞
図８には、図７のステップＳ１０１の接続工程における詳細な処理の流れを示す。接続工程は、認証部２０５の接続設定部２０５ａによって実行される。

まず図１８のステップＳ１１で、暗号通信確立のための処理に入る。ＰＣ１はメッセージナンバー（以降、メッセージＮｏとも呼称する）、及び暗号通信のための設定情報を含むメッセージをＰＣＮに送信する。

暗号通信のための設定情報とは、通信プロトコルのバージョン、そして暗号アルゴリズムに関する設定を含む。暗号アルゴリズムに関する設定には、後述するプリマスター鍵から暗号鍵を作成するのに必要な情報（暗号鍵作成用乱数など）も含まれている。

メッセージＮｏは、後述するように破棄されるまで、以後ＰＣ１から送信されるすべてのメッセージに付与される番号であり、ここではメッセージＮｏ１であるとする。従って任意のＰＣＮは、このメッセージＮｏ１を受け取って以後は、受信するメッセージに付与されているメッセージＮｏを確認し、このメッセージＮｏ１であればＰＣ１から送信されてきたメッセージであることが分かる。これにより、メッセージを送受信する都度のハンドシェイクを簡略化することができる。

メッセージＮｏは、送信ノード毎に一意の番号とするか、または送受信するノードの組み合わせ毎に一意となるようにすることが望ましい。あるいは、この暗号通信によるマルチキャスト送信のハンドシェーク単位で一意であるようにしてもよい。本実施形態においては、送信ノード毎に一意の番号としている。

ステップＳ１２で、暗号通信のための設定情報を受信したＰＣＮは、受信した通信プロトコルのバージョンデータに基づき、ＰＣＮで対応できるバージョンを選択、設定する。また、受信した暗号化アルゴリズムの設定に基づき、ＰＣＮでサポートしているアルゴリズムを選択し、設定する。

ステップＳ１３で、それぞれのＰＣＮは暗号通信のための設定選択を含むメッセージをＰＣ１に送信する。暗号通信のための設定選択としては、選択した通信プロトコルのバージョンと暗号化アルゴリズムの設定情報を含む。そしてメッセージにはメッセージＮｏが付与される。

それぞれのＰＣＮからメッセージＮｏＮとともに受信した暗号化アルゴリズムの設定情報には、それぞれ暗号鍵作成用乱数が含まれている。しかしながら、どの任意のＰＣＮからの受信にも、一つ以上の共通の暗号鍵作成用乱数が含まれていることが望ましい。

なお上記のメッセージＮｏの付与は、ＰＣ１の送信メッセージにメッセージＮｏ１が付与されるのと同じ理由によるものであり、ここではメッセージＮｏＮであるとする。以後任意のＰＣＮから送信されるすべてのメッセージには、それぞれメッセージＮｏＮが付与される。ＰＣ１のメッセージＮｏ１と同様に、メッセージに付与されたこのメッセージＮｏＮにより、それぞれ任意のＰＣＮから送信されてきたメッセージであることが分かる。

ステップＳ１４で、暗号通信のための設定選択を受信したＰＣ１は、受信した通信プロトコルのバージョン設定に基づき、ＰＣ１で用いるバージョンを設定する。また、受信した暗号化アルゴリズムの設定に基づき、ＰＣ１でのアルゴリズムを設定する。また、メッセージＮｏＮを、この後の暗号通信に備えて、それぞれのＰＣＮからの送信メッセージを代表する番号として記憶する。

図７の説明に戻る。ステップＳ１０１の接続工程に続くステップＳ１０２は認証工程であり、各ノードの認証のために必要な情報を送受信し、認証を行う。送信側ノード（ＰＣ１）が受信側ノード（任意のＰＣＮ）の認証を行おうとする場合を例に、図９を参照しながら認証工程の詳細を述べる。

＜認証工程＞
図９には、図７のステップＳ１０２の認証工程における詳細な処理の流れを示す。認証工程は、認証部２０５の認証処理部２０５ｂによって実行される。

図９のステップＳ２１で、まず任意のＰＣＮは認証のための情報を含むメッセージを、それぞれのＰＣＮのメッセージＮｏＮとともにＰＣ１に送信する。認証のための情報とは、それぞれのＰＣＮのＸ．５０９ディジタル証明書であり、それぞれのＰＣＮの公開鍵の情報を含む。

公開鍵は、次の暗号鍵作成工程でプリマスター鍵を安全に送受信するために用いるものである。Ｘ．５０９証明書を送信する理由とそれによる認証方法は、既述したＳＳＬ通信の場合と同様である。Ｘ．５０９証明書は、周知の認証サーバ５によって署名されたものでなければ、そこに達するまでの証明書のチェーンも送信する。

次のステップＳ２２では、ＰＣ１が受信したそれぞれのＸ．５０９証明書に基づいて、それぞれのＰＣＮの認証を行う。

ＰＣ１においては認証サーバ５自身を証明するルート証明書を予め保持しており、そのなかにそれぞれのＰＣＮから受信したＸ．５０９証明書を署名したものがあるかどうかを検証する。また当該証明書が、その署名を行った認証サーバ５の発行した証明書失効リスト（ＣＲＬ）に記載がないかどうかを確認し、もし記載があればこの時点で通信を終了する。

以上はＰＣ１がそれぞれのＰＣＮのＸ．５０９証明書に基づいて、それぞれのＰＣＮの認証を行ったが、合わせて任意のＰＣＮもＰＣ１のＸ．５０９証明書に基づいてＰＣ１の相互認証を行ってもよい。その場合はＰＣ１と任意のＰＣＮの双方がＸ．５０９証明書とそれぞれの証明書を検証するためのルート証明書を持っている必要がある。

次のステップＳ２３とステップＳ２４は省略してもよいが、任意のＰＣＮがＰＣ１の認証を行う工程である。

ステップＳ２３では、今度はＰＣ１が認証のための情報を含むメッセージを、ＰＣ１のメッセージＮｏ１とともにそれぞれのＰＣＮに送信する。認証のための情報は、同じくＰＣ１のＸ．５０９ディジタル証明書であり、ＰＣ１の公開鍵の情報を含む。

公開鍵は、次の暗号鍵作成工程でプリマスター鍵を安全に送受信するために用いるものである。Ｘ．５０９証明書は、周知の認証サーバ５によって署名されたものでなければ、そこに達するまでの証明書のチェーンも送信する。

次のステップＳ２４では、任意のＰＣＮが受信したＸ．５０９証明書に基づいてＰＣ１の認証を行う。認証方法は、ＰＣ１によるＰＣＮの認証（ステップＳ２１、Ｓ２２）と同様である。

ステップＳ２５では、上記認証処理をクリアした後、それぞれのＰＣＮは応答終了の旨をＰＣ１に対して通知する。それぞれのＰＣＮの応答終了を受けて、ＰＣ１は次の暗号鍵作成工程に入る。

図７の説明に戻る。ステップＳ１０２の認証工程に続くステップＳ１０３は暗号鍵作成工程であり、暗号鍵を作成するための情報を送受信し、暗号通信に用いる暗号鍵を作成、共有化する。送信側ノード（ＰＣ１）が受信側ノード（任意のＰＣＮ）に対してマルチキャストで暗号通信を行う際の共通鍵としての暗号鍵を作成、共有化する場合を例に、図１０を参照しながら暗号鍵作成工程の詳細を述べる。

＜暗号鍵作成工程＞
図１０には、図７のステップＳ１０３の暗号鍵作成工程における詳細な処理の流れを示す。暗号鍵作成工程は、認証部２０５の暗号鍵作成部２０５ｃによって実行される。

図１０のステップＳ３１で、まずＰＣ１は任意のＰＣＮに対する暗号鍵を作成するためのランダムなプリマスター鍵を生成する。

このプリマスター鍵と、接続工程で送信した暗号通信のための設定情報に含まれていた暗号鍵作成用乱数情報とを用いて、暗号鍵が作成されるのである。

ここでは任意のＰＣＮに対するプリマスター鍵として、複数のプリマスター鍵１−１、１−２が作成されたとする。このプリマスター鍵をＰＣＮに送信して、ＰＣ１とＰＣＮで同じ暗号鍵１−１、１−２を作成し、保持しようとするものである。

但し、プリマスター鍵から作成される暗号鍵の少なくとも１つ以上が、それぞれのＰＣＮに対して共通となるように、プリマスター鍵は設定しなければならない。これは、後で暗号化データのマルチキャスト通信を行うためである。ここではプリマスター鍵１−１により作成される暗号鍵１−１が、それぞれのＰＣＮに対して共通の暗号鍵であるとする。

次のステップＳ３２で、ＰＣ１は暗号鍵を作成するための情報を含むメッセージをＰＣＮに送信する。暗号鍵を作成するための情報とは、ステップＳ３１で生成した複数のプリマスター鍵１−１、１−２を含む。

ここで複数のプリマスター鍵は、それぞれ送信先であるＰＣＮの公開鍵を用いて暗号化されている。ＰＣＮの公開鍵は、認証工程においてＰＣ１が取得したＰＣＮの認証のための情報に含まれている。

ステップＳ３３では、任意のＰＣＮが受信した（ＰＣＮ自身の公開鍵で暗号化されている）複数のプリマスター鍵１−１、１−２を、ＰＣＮ自身の保持している秘密鍵を用いて解読する。さらに、復号化された複数のプリマスター鍵１−１、１−２と、接続工程ステップＳ１１でＰＣ１から受領した暗号鍵作成用乱数に基づいて、それぞれ暗号鍵１−１、１−２を作成する。

作成された複数の暗号鍵は、ＰＣ１とＰＣＮとで同じ鍵を所持し、暗号化と復号化に共通して用いる。また上記したように、少なくとも１つはそれぞれのＰＣＮに共通の暗号鍵であり、ここでは暗号鍵１−１が該当するものとする。もちろんＰＣ１においても、同じプリマスター鍵と暗号作成用乱数を用いて、同じ暗号鍵１−１、１−２が作成され、それぞれのＰＣＮと共有化される。

これらの暗号鍵１−１、１−２とその暗号鍵Ｎｏは、基になったプリマスター鍵に付与されてきたメッセージＮｏ１と関連付けられて、ＰＣ１とそれぞれのＰＣＮのデータ保持部２０３に記憶され、共有化される。

メッセージを送信するＰＣ１は、メッセージＮｏ（すなわち暗号通信の送信元であるＰＣ１）と暗号鍵Ｎｏを指定することで、暗号化に用いる暗号鍵を特定し、参照することができる。またメッセージを受信するそれぞれのＰＣＮは、メッセージＮｏ（同じく暗号通信の送信元のＰＣ１）と暗号鍵Ｎｏを指定することで、復号化に用いる暗号鍵を特定し、参照することができる。

なお上記は、同じプリマスター鍵と暗号鍵作成用乱数により、任意のＰＣＮとＰＣ１とで、それぞれ同じ暗号鍵を作成する形態を述べたが、暗号鍵を作成するのは一方のノードだけであってもよい。例えば任意のＰＣＮで作成した暗号鍵を、ＰＣ１の公開鍵を用いて暗号化し、ＰＣ１へメッセージＮｏとともに返信し、ＰＣ１で復号化することにより、ＰＣ１と任意のＰＣＮとで同じ暗号鍵を共有するようにしてもよい。

以上はＰＣ１がＰＣＮに暗号鍵を作成するための情報を送信し、それぞれのＰＣＮに暗号鍵を作成させて、ＰＣ１からＰＣＮへのマルチキャスト暗号通信に備えたものである。またそれぞれのＰＣＮからＰＣ１への暗号通信にも同じ暗号鍵を用いてもよい。しかし、上記のＰＣ１からＰＣＮへの暗号通信とは異なる暗号鍵を用いて、さらに安全性を向上するようにしてもよい。例えば、ＰＣＮの側からもＰＣ１に暗号鍵を作成するための情報を送信し、ＰＣＮからＰＣ１への暗号通信による返信に備えた別の暗号鍵を作成させる手順を加えてもよい。

すなわち、以下のステップＳ３４、Ｓ３５、そしてＳ３６は、上述したステップＳ３１、Ｓ３２、そしてＳ３３の逆の工程であり、マルチキャスト送信とそれに対する返信とで異なる暗号鍵を使用することで、より強固な安全性を得ることができる。返信用の暗号鍵作成は省略してもよいが、その場合は、任意のＰＣＮからＰＣ１への返信においても、上記暗号鍵１−１、１−２を用いることになる。

ステップＳ３４では、ステップＳ３１と同様に、ＰＣＮの方で暗号鍵を作成するためのランダムなプリマスター鍵を生成する。但し、それぞれのＰＣＮで生成されるプリマスター鍵は、少なくとも１つ以上はそれぞれのＰＣＮに共通であることが望ましい。ＰＣ１からのマルチキャスト送信に対する返信であるという共通性を維持するためである。共通のプリマスター鍵を生成するには、例えば、受信した日付を利用するなどの方法がある。

ここでは共通のプリマスター鍵として、プリマスター鍵Ｎ−１が一つだけ作成されたとする。このプリマスター鍵をＰＣ１に送信して、ＰＣＮとＰＣ１で同じ暗号鍵Ｎ−１を作成し、共有しようとするものである。

次のステップＳ３５で、それぞれのＰＣＮは暗号鍵を作成するための情報を含むメッセージを、それぞれのＰＣＮのメッセージＮｏＮとともにＰＣ１に送信する。暗号鍵を作成するための情報は、ステップＳ３４で生成したプリマスター鍵Ｎ−１を含む。

またステップＳ３２と同様に、送信するプリマスター鍵は、それぞれ送信先であるＰＣ１の公開鍵を用いて暗号化されている。ＰＣ１の公開鍵は、認証工程においてＰＣＮが取得したＰＣ１の認証のための情報に含まれている。

ステップＳ３６では、ＰＣ１が受信した（ＰＣ１自身の公開鍵で暗号化されている）プリマスター鍵Ｎ−１を、ＰＣ１自身の保持している秘密鍵を用いて解読する。さらに、復号化されたプリマスター鍵Ｎ−１と、前述した暗号鍵作成用乱数に基づいて、暗号鍵Ｎ−１を作成する。

もちろんＰＣＮにおいても、同じプリマスター鍵と暗号鍵作成用乱数を用いて、同じ暗号鍵２−１が作成されている。あるいは、前述したように一方のノード、すなわちＰＣ１だけで暗号鍵を作成し、ＰＣ１からＰＣＮへ暗号化送信して、共有化するようにしてもよい。

作成された暗号鍵Ｎ−１の暗号鍵Ｎｏは、基になったプリマスター鍵に付与されてきたメッセージＮｏＮと関連付けられて、それぞれのＰＣＮとＰＣとで、データ保持部２０３に記憶され、共有化される。

ＰＣ１に暗号メッセージを返信するＰＣＮは、メッセージＮｏ（すなわち暗号通信の送信元であるＰＣＮ）と暗号鍵Ｎｏを指定することで、暗号化に用いる暗号鍵を特定し、参照することができる。また暗号メッセージを受信するＰＣ１は、メッセージＮｏ（同じく暗号通信の送信元のＰＣＮ）と暗号鍵Ｎｏを指定することで、復号化に用いる暗号鍵を特定し、参照することができる。

上記は、ＰＣ１と任意のＰＣＮとの間での送信方向により異なる暗号鍵を共有化する形態を述べたが、そのためにＰＣ１とＰＣＮとで異なるプリマスター鍵を用いた。しかし、同じプリマスター鍵を用いて、暗号鍵作成用乱数のみを異ならせることにより、異なる暗号鍵を作成するようにしてもよい。

その場合、プリマスター鍵は同じものを用いればよいので、上述したステップＳ３４、Ｓ３５は不要となる。その代わり、ステップＳ３６において、ＰＣ１は、プリマスター鍵１−１と、接続工程ステップＳ１３でそれぞれのＰＣＮから受領した暗号鍵作成用乱数（ステップＳ３３でＰＣＮの用いた乱数とは異なる）に基づいて、暗号鍵Ｎ−１を作成する。但し、それぞれのＰＣＮから受信する暗号作成用乱数は、少なくとも１つは共通でなければならない。ステップＳ３４で共通のプリマスター鍵を生成するのに用いた日付利用などの方法で、ステップＳ１３でも、それぞれのＰＣＮで共通の暗号鍵作成用乱数を生成し、ＰＣ１に送信すればよい。

この暗号鍵Ｎ−１は、もちろんＰＣＮにおいても作成される、あるいはＰＣ１からＰＣＮに送信されることで、それぞれのノードで、それぞれ暗号鍵Ｎ−１として、データ保持部２０３に記憶され、共有化される。

ステップＳ３７では、ＰＣ１はマルチキャスト通信用の暗号鍵を上記のように作成されたそれぞれのＰＣＮに対して共通の、少なくとも１つ以上の暗号鍵に切り替えるように制御を行う。また通信用の暗号鍵を切り替える旨の暗号切り替え通知を任意のＰＣＮに送信する。またＰＣ１は、上記暗号鍵の切り替えを終了すると、任意のＰＣＮに暗号切り替え終了の通知を送信する。

ＰＣ１からの暗号切り替え終了の通知を受けると、それぞれのＰＣＮにおいても、暗号鍵の切り替えを行うべく、ＰＣ１に暗号切り替えの通知を送信するとともに、暗号通信に用いる暗号鍵の切り替えを行う。またＰＣＮは、上記暗号鍵の切り替えを終了すると、ＰＣ１に暗号切り替え終了の通知を送信する。

それぞれのＰＣＮすべてに対する、以上の暗号切り替え終了により、暗号通信の確立を終えて、実際のマルチキャスト送信データの暗号通信処理に入る。

図７の説明に戻る。ステップＳ１０３の暗号鍵作成工程に続くステップＳ１０４は暗号化工程であり、暗号鍵に基づき暗号化処理したデータ通信を行う。送信側ノード（ＰＣ１）が複数の受信側ノード（ＰＣＮ）に、暗号化されたデータ送信をマルチキャストで行う場合を例に、図１１を参照しながら暗号化工程の詳細を述べる。

＜暗号化工程＞
図１１には、図７のステップＳ１０４の暗号化工程における詳細な処理の流れを示す。暗号化工程は、認証部２０５の暗号化処理部２０５ｄによって実行される。

図１１のステップＳ４２で、ＰＣ１は暗号化してマルチキャスト送信するデータに対して、ＰＣ１のメッセージＮｏ１と関連付けた暗号鍵（少なくとも１つ以上あるはずのそれぞれのＰＣＮに対して共通の暗号鍵）を選択する。ここでは、暗号鍵Ｎｏ１、すなわち、データ保持部２０３から、暗号鍵鍵１−１が参照される。

次にステップＳ４３で、ＰＣ１はマルチキャスト送信するデータに対して、選択した暗号鍵を用いて暗号化処理を行う。すなわち、送信データは暗号鍵１−１で暗号化処理される。

次にステップＳ４４で、ＰＣ１は暗号化されたデータを、暗号化情報として、送信元ＰＣ１のメッセージＮｏ１とともに、複数の受信側ノード（すべてのＰＣＮ）にマルチキャスト送信する。この送信は、例えばＵＤＰのような簡略な通信プロトコルで行われる。暗号鍵は事前に共有化しているため、通信の速度を低下させるようなハンドシェイクも必要なく、マルチキャスト通信を行うことができる。また複数の共通の暗号鍵を定めておけば、マルチキャスト通信を行う都度、暗号鍵を変更して、安全性を向上することも可能である。

送信する暗号化情報には、暗号化処理したデータに送信属性情報、すなわちそのデータの暗号化に使用した暗号鍵の番号（例えばここでは暗号鍵Ｎｏ１）が付与されている。上記暗号化情報のサイズは、例えばＵＤＰなど、送信に用いるプロトコルで一度に送信できるサイズ内とすることが望ましい。

ステップＳ４５で、それぞれのＰＣＮは受け取った暗号化情報の送信属性情報（暗号鍵番号）とメッセージＮｏとからデータ保持部２０３を検索し、そのデータの暗号化処理に使用された暗号鍵を特定し、参照する。例えば、付与されているメッセージＮｏ１と暗号鍵の番号（暗号鍵Ｎｏ１）とから暗号鍵１−１を検索する。

ＰＣＮは、このように検索した暗号鍵を用いて、受信した暗号化情報に含まれている暗号化データを解読する。

図７の説明に戻る。ステップＳ１０４の暗号化工程を終えると、次の暗号通信の機会を待つのみである。本実施形態では、複数の受信側ノードに対して共通の暗号鍵を予め設定し、マルチキャスト送信するデータにその共通の暗号鍵を適用することにより、マルチキャスト通信が可能な通信形態を維持しながら、かつ安全性向上を実現している。しかしながら、予め設定した共通の暗号鍵自体も適切なタイミングで変更することにより、さらに安全性を向上することができる。そのため、ステップＳ１０４の暗号化工程を終えた時点で、保持されている共通の暗号鍵を変更するかどうかをチェックする処理手順とした。

＜暗号通信の再確立処理＞
ステップＳ１１１で、ＰＣ１はメッセージＮｏを破棄するかどうかを判定する。メッセージＮｏを破棄するということは、そのメッセージＮｏに関連付けられた暗号鍵を破棄するということである。暗号通信処理を行うためには、再度接続工程から実施し、新たなメッセージＮｏを設定する所からやり直す必要がある。

メッセージＮｏを破棄するかどうかは、所定の条件を満たすかどうかで判断する。破棄するタイミングを決定する条件としては、以下のような条件が考えられる。

１． 上述した暗号通信確立のためのハンドシェイク後、一定時間経過後に破棄する。

２． ＰＣ１の電源ＯＦＦ時に破棄する。

３． ハンドシェイクした相手ＰＣが不通になったとき、破棄する。

４． ハンドシェイクした相手ＰＣの暗号が解読できなかったとき、破棄する。

５． ユーザの指示により破棄する。

上記の条件、あるいはその他の条件から適切な条件を選んで設定することが望ましい。

設定した条件に照らして、破棄するという判定の場合（ステップＳ１１１：ＹＥＳ）は、上記処理で確立した暗号通信の設定はこれで一旦終了である。次に暗号通信を行う局面になれば、図７のＳｔａｒｔから、もう一度上述した暗号通信の確立をやり直すことになる。すなわち、上記設定条件を満たす場合には、安全のために暗号鍵も再度作り直すことになる。

設定した条件に照らして、破棄しないという判定の場合（ステップＳ１１１：ＮＯ）は、ステップＳ１１２に進み、暗号化する送信データを待つ。すなわち、ステップＳ１１２では暗号化する次の送信データがあるかどうかを判定し、ある場合（ステップＳ１１２：ＹＥＳ）は、ステップＳ１０４に戻り、暗号化工程から繰り返す。

暗号化する次の送信データがない場合（ステップＳ１１２：ＮＯ）は、ステップＳ１１１へ戻り、メッセージＮｏを破棄するタイミングかどうかをチェックしながら、ステップＳ１１１とステップＳ１１２を繰り返し、次の暗号化処理する送信データを待つことになる。

このように、ハンドシェイクをやり直す、すなわち暗号鍵自体も適切なタイミングで変更することにより、さらに安全性を向上することができる。

以下に、マルチキャスト送信の事例を説明する。

＜暗号化データのマルチキャスト送信例１＞
図１２は、本暗号通信処理による実際のデータ送信の事例１を示す説明図である。

ＰＣ１からＰＣ４までがネットワーク接続されており、送信側ノードとしてのＰＣ１が受信側ノードであるＰＣ２とＰＣ３に対して、ＵＤＰ通信で暗号化データをマルチキャスト送信するものとする。

上述した説明において、任意のＰＣＮが、それぞれＰＣ２及びＰＣ３であることになる。ＰＣ２及びＰＣ３に対して、上記ハンドシェイクが以下のように行われ、暗号通信のコネクションが確立する。

接続工程では、暗号通信のための設定情報を交換する。すなわち、通信プロトコルのバージョン、暗号アルゴリズム設定を選択し、双方のメッセージＮｏを互いに記憶する。

メッセージＮｏは各ノードに一意の番号であり、通信時に必ず付与されることで、メッセージ送信元を識別する手段にもなり、また使用された暗号鍵を検索するための情報でもある。ここでは送信側ノードのＰＣ１についてはメッセージＮｏ１であり、受信側の各ノード（ＰＣ２及びＰＣ３）については、それぞれメッセージＮｏ２とメッセージＮｏ３である。

認証工程では、それぞれのディジタル証明書により、受信側の各ノード（ＰＣ２及びＰＣ３）を認証する。また送信側のＰＣ１と受信側のＰＣ２及びＰＣ３は、お互いの公開鍵を交換する。

暗号鍵作成工程では、送信側のＰＣ１が受信側のＰＣ２及びＰＣ３に、それぞれの送信先の公開鍵を用いて暗号化したプリマスター鍵を送信する。受信したＰＣ２及びＰＣ３は、それぞれの秘密鍵を用いてプリマスター鍵を解読する。

ＰＣ２及びＰＣ３は、それぞれ解読したプリマスター鍵に基づいて暗号鍵を作成する。但し、ＰＣ２及びＰＣ３で作成される暗号鍵の少なくとも１つは、ＰＣ２及びＰＣ３で共通である。そうなるように設定したプリマスター鍵を、ＰＣ１はＰＣ２及びＰＣ３にそれぞれ送信している。ここでは、作成される暗号鍵は一つ（暗号鍵１とする）であり、それがＰＣ２及びＰＣ３に共通であるとする。

このようにして暗号通信のためのハンドシェイクは終了し、次の暗号化工程でデータの暗号化とマルチキャスト送信が行われる（図１２参照）。

ＰＣ１は、送信データを暗号鍵１を用いて暗号化し、暗号化情報（暗号化されたデータ）にメッセージＮｏ１を付与して、ＰＣ２及びＰＣ３にマルチキャスト送信する。この場合受信側との共通の暗号鍵は一つだけなので暗号鍵Ｎｏは送信していない。

暗号化情報を受信したＰＣ２及びＰＣ３では、それぞれがメッセージＮｏ１に関連付けられた暗号鍵１を利用して、この暗号化されたデータを解読する。

また、例えばＰＣ３からＰＣ１に返信する場合、同じ暗号鍵１を用いて暗号化したデータをその暗号鍵１が対応づけられているメッセージＮｏ１と合わせて送信する。返信を受けたＰＣ１は、暗号鍵１を特定し、返信された暗号化データを解読する。

あるいは、ＰＣ３からメッセージＮｏ３に対応した別の暗号鍵３が作成されていた場合、図１３に示すように、メッセージＮｏ３に対応づけられた暗号鍵３を用いて暗号化したデータをメッセージＮｏ３と合わせてＰＣに送信すればよい。

このようにＰＣ３からの返信メッセージに、別の暗号鍵を利用すれば、より安全性を向上した暗号通信が可能になる。

＜暗号化データのマルチキャスト送信例２＞
図１４は、本暗号通信処理による実際のデータ送信の事例２を示す説明図である。

送信の事例１と同様に、ＰＣ１からＰＣ４までがネットワーク接続されており、送信側ノードとしてのＰＣ１が受信側ノードであるＰＣ２とＰＣ３に対して、ＵＤＰ通信で暗号化データをマルチキャスト送信するものとする。

ＰＣ２及びＰＣ３に対して、事例１と同様に暗号通信のコネクションを確立する。

接続工程では、同様に暗号通信のための設定情報を交換する。

メッセージＮｏは、送信側ノードのＰＣ１についてはメッセージＮｏ１であり、受信側の各ノード（ＰＣ２及びＰＣ３）については、それぞれメッセージＮｏ２とメッセージＮｏ３である。

認証工程では、それぞれのディジタル証明書により、受信側の各ノード（ＰＣ２及びＰＣ３）を認証する。またお互いの公開鍵を交換する。

暗号鍵作成工程では、送信側のＰＣ１が受信側のＰＣ２及びＰＣ３に、それぞれの送信先の公開鍵を用いて暗号化したプリマスター鍵を送信する。受信したＰＣ２及びＰＣ３は、それぞれの秘密鍵を用いてプリマスター鍵を解読する。

ＰＣ２及びＰＣ３は、それぞれ解読したプリマスター鍵に基づいて暗号鍵を作成する。但し、この例ではＰＣ２及びＰＣ３で作成される暗号鍵はそれぞれ複数あり、そのうち３つがＰＣ２及びＰＣ３で共通の暗号鍵１−１、１−２、そして１−３であるとする。ＰＣ２及びＰＣ３は、この暗号鍵に暗号鍵Ｎｏを付けてメッセージＮｏ１とともにメモリに記憶しておく（図１５参照）。

このようにして暗号通信のコネクションを確立すると、次の暗号化工程でデータの暗号化とマルチキャスト送信が行われる（図１４参照）。

ＰＣ１は、送信データに対して利用する暗号鍵を上記共通の暗号鍵１−１、１−２、そして１−３から選択する。例えば選択した暗号鍵Ｎｏ２（暗号鍵２−１）を用いて暗号化し、暗号化情報（暗号化されたデータ）にメッセージＮｏ１と暗号鍵Ｎｏ２を付与して、ＰＣ２及びＰＣ３にマルチキャスト送信する。

暗号化情報を受信したＰＣ２及びＰＣ３では、それぞれがメッセージＮｏ１に関連付けられた暗号鍵Ｎｏ２をメモリ参照し、特定した暗号鍵１−２を利用して、この暗号化されたデータを解読することができる。

ここでは暗号鍵Ｎｏ２を用いたが、暗号化に用いる暗号鍵をマルチキャストの度に変更すれば、利用している暗号の推察をより困難にできる。また、そのために新たにハンドシェイクを行う必要がなく、パフォーマンスも低下しない。

上述したような実施形態により、ネットワークにおけるノード間のマルチキャスト通信において、複数の受信側ノードに共通の暗号鍵を最初に設定しておき、マルチキャスト送信するパケット毎に適用することで、マルチキャスト可能な通信形態を維持しながら、セキュリティ（安全性）を向上した効果的な暗号通信を行うことができる。

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

ネットワーク１の全体構成例を示す図である。 ネットワーク１を構成するノード（暗号通信処理装置）２のハードウェア構成例を示す図である。 ネットワーク１を構成する各ノード２の接続形態、すなわちノードの論理的なトポロジーの例を示す図である。 図３のように関連付けられたノード２の接続テーブルＴＬ例を示す図である。 ノード（暗号通信処理装置）２の機能構成例を示すブロック図（ａ）、および認証部２０５の機能の内部構成を示す図（ｂ）である。 ＳＳＬ通信のコネクションを確立する際の処理例を説明するためのシーケンス図である。 暗号通信の確立からデータの暗号化処理とマルチキャスト送信に至るまでの代表的な暗号通信処理の流れを示すフローチャートである。 図７の接続工程の処理例の詳細な流れを示すシーケンス図である。 図７の認証工程の処理例の詳細な流れを示すシーケンス図である。 図７の暗号鍵作成工程の処理例の詳細な流れを示すシーケンス図である。 図７の暗号化工程の処理例の詳細な流れを示すシーケンス図である。 ＰＣ１からＰＣ２及びＰＣ３へ、共通の暗号鍵で暗号化処理したデータをマルチキャスト送信する事例を示す説明図である。 ＰＣ３からＰＣ１へ暗号化処理した返信データを送信する例を示す説明図である。 ＰＣ１からＰＣ２及びＰＣ３へ、選択された共通の暗号鍵で暗号化処理したデータをマルチキャスト送信する事例を示す説明図である。 ＰＣ１からＰＣ２及びＰＣ３へのマルチキャスト送信の場合に、メッセージＮｏと共通の暗号鍵がメモリに記憶される様子を示す図である。

符号の説明

１ ネットワーク
２ 暗号通信処理装置（ノード）
３ スイッチングハブ
４ ルータ
５ 認証サーバ
２０１ 接続テープ保持部
２０２ 接続テーブル管理部
２０３ データ保持部
２０４ データ操作部
２０５ 認証部
２０５ａ 接続設定部
２０５ｂ 認証処理部
２０５ｃ 暗号鍵作成部
２０５ｄ 暗号化処理部
２０６ ネットワーク申請部
２０７ データ受信部
２０８ データ解析部
２０９ データ作成部
２１０ データ送信部
ＴＬ 接続テーブル

Claims (12)

1. ネットワークシステムを構成する複数のノード間で、マルチキャスト方式で暗号通信を行うための暗号通信処理方法であって、
   マルチキャスト方式で暗号通信を行う送信側の第１のノードと受信側の複数の第２のノードの間で、メッセージナンバーを交換する接続工程と、
   前記複数の第２のノードが、それぞれ認証のための情報を含むメッセージを送信し、それらを受信した前記第１のノードが、該情報に基づき、前記複数の第２のノードをそれぞれ認証する認証工程と、
   前記認証工程において、それぞれの認証が成功した場合に、前記第１のノードと前記複数の第２のノードの間で、それぞれ暗号鍵を作成するための情報を含むメッセージを通信し、それぞれ該情報に基づき暗号鍵を作成し、両ノードで共有化する暗号鍵作成工程と、
   前記第１のノードが、前記暗号鍵作成工程において作成、共有化された暗号鍵に基づき暗号化した情報を含むメッセージを、前記複数の第２のノードにマルチキャスト送信する暗号化工程と、を有し、
   前記暗号鍵作成工程では、前記暗号鍵を作成するための情報に基づき、前記複数の第２のノードに共通である暗号鍵が作成され、
   前記暗号化工程では、前記第１のノードが、前記複数の第２のノードのそれぞれに対して、前記複数の第２のノードに共通である暗号鍵を用いて送信する情報を暗号化し、メッセージナンバーを付与してマルチキャスト送信する
   ことを特徴とする暗号通信処理方法。
2. 前記暗号鍵作成工程では、前記暗号鍵を作成するための情報に基づき、前記複数の第２のノードに共通である暗号鍵とは異なる暗号鍵を作成し、
   前記暗号化工程では、暗号化した情報に、暗号化に用いた暗号鍵を識別するための情報を含む送信属性情報を付与して送信する
   ことを特徴とする請求項１に記載の暗号通信処理方法。
3. 前記接続工程において交換されるメッセージナンバーは、
   送信ノード毎に、あるいは送受信するノードの組み合わせ毎に一意に設定され、
   前記第１のノードから前記複数の第２のノードのどのノードに送信されるどのメッセージにも、同一のメッセージナンバーが付与される
   ことを特徴とする請求項１または２に記載の暗号通信処理方法。
4. 前記メッセージナンバーは、所定のタイミングで破棄され、破棄されたメッセージナンバーに対応するノードが関わる暗号通信処理は、前記接続工程からやり直す
   ことを特徴とする請求項３に記載の暗号通信処理方法。
5. 前記接続工程では、
   前記第１のノードと前記複数の第２のノードの間で、通信プロトコルのバージョン情報と暗号化アルゴリズム設定のための情報を含む暗号通信のための設定情報が交換される
   ことを特徴とする請求項１乃至４の何れか１項に記載の暗号通信処理方法。
6. 前記認証工程における認証のための情報には、当該情報を送信したノードの公開鍵の情報が含まれ、
   前記暗号鍵作成工程における暗号鍵を作成するための情報は、前記公開鍵を用いて暗号化され、送信される
   ことを特徴とする請求項１乃至５の何れか１項に記載の暗号通信処理方法。
7. 任意のノードが複数の他のノードに対してマルチキャスト方式で暗号通信を行うネットワークシステムにおける、ノードとしての暗号通信処理装置であって、
   マルチキャストで暗号通信する複数の他のノードとの間で、
   メッセージナンバーを交換する接続手段と、
   前記複数の他のノードから、それぞれ認証のための情報を含むメッセージを受信し、受信した該情報に基づき、前記複数の他のノードをそれぞれ認証する認証手段と、
   前記認証手段により認証した前記複数の他のノードと、暗号鍵を作成するための情報を含むメッセージを通信し、それぞれ該情報に基づき暗号鍵を作成、共有化する暗号鍵作成手段と、
   前記暗号鍵作成手段により作成、共有化された暗号鍵に基づき暗号化した情報を含むメッセージを、前記複数の他のノードにマルチキャスト送信する暗号化手段と、を有し、
   前記暗号鍵作成手段は、前記暗号鍵を作成するための情報に基づき、前記複数の他のノードに共通である暗号鍵を作成、共有化し、
   前記暗号化手段は、前記複数の他のノードのそれぞれに対して、前記複数の他のノードに共通である暗号鍵を用いて送信する情報を暗号化し、メッセージナンバーを付与してマルチキャスト送信する
   ことを特徴とする暗号通信処理装置。
8. 前記暗号鍵作成手段は、前記暗号鍵を作成するための情報に基づき、前記複数の他のノードに共通である暗号鍵とは異なる暗号鍵を作成し、
   前記暗号化手段は、暗号化した情報に、暗号化に用いた暗号鍵を識別するための情報を含む送信属性情報を付与して送信する
   ことを特徴とする請求項７に記載の暗号通信処理装置。
9. 前記接続手段により交換されるメッセージナンバーは、
   送信ノード毎に、あるいは送受信するノードの組み合わせ毎に一意に設定されたものであり、
   前記複数の他のノードのどのノードに送信するどのメッセージにも、同一のメッセージナンバーを付与する
   ことを特徴とする請求項７または８に記載の暗号通信処理装置。
10. 前記メッセージナンバーは、所定のタイミングで破棄し、破棄した後の暗号通信処理は前記接続手段によるメッセージナンバーの交換からやり直す
    ことを特徴とする請求項９に記載の暗号通信処理装置。
11. 前記接続手段は、
    前記複数の他のノードとの間で、通信プロトコルのバージョン情報と暗号化アルゴリズム設定のための情報を含む暗号通信のための設定情報を交換する
    ことを特徴とする請求項７乃至１０の何れか１項に記載の暗号通信処理装置。
12. 前記認証手段により送信する認証のための情報は、送信するノードの公開鍵の情報を含み、
    前記暗号鍵作成手段により送信する暗号鍵を作成するための情報は、前記公開鍵を用いて暗号化する
    ことを特徴とする請求項７乃至１１の何れか１項に記載の暗号通信処理装置。

Images