JPWO2020157928A1 - データ送信方法、通信処理方法、装置、および通信処理プログラム - Google Patents

Abstract

本開示のある形態に従うデータ通信方法は、第１のデバイス（１００−１）において、第２のデバイス（１００−２）を宛先とするパケットを関連付けられた第１の暗号鍵（１７２）により暗号化して第１の暗号化パケット（２４）を生成するステップ（Ｓ１１８）と、第１の暗号化パケットの送出先となるデバイスを決定し、関連付けられた第２の暗号鍵により第１の暗号化パケットを暗号化して第２の暗号化パケットを生成し、当該決定したデバイスへ送信するステップ（Ｓ１２０〜Ｓ１２８）と、自デバイス宛てであるか否かの判断により、復号された第１の暗号化パケットが自デバイス宛てでなければ、別のデバイスを決定し送信するステップを実行し、復号された第１の暗号化パケットが自デバイス宛てであれば、第１の暗号化パケットをさらに復号するステップ（Ｓ２００〜Ｓ２１８）とを含む。

Description

本開示は、認証済みＩＰアドレスを有するデバイス間のデータ通信技術に関する。

近年の情報通信技術（Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ：ＩＣＴ）の進歩は目覚ましく、インターネットなどのネットワークに接続されるデバイスは、従来のパーソナルコンピュータやスマートフォンといった情報処理装置に限らず、様々なモノ（ｔｈｉｎｇｓ）に広がっている。このような技術トレンドは、「ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ；モノのインターネット）」と称され、様々な技術およびサービスが提案および実用化されつつある。将来的には、地球上の数十億人と数百億または数兆のデバイスとが同時につながる世界が想定されている。このようなネットワーク化された世界を実現するためには、よりシンプル、より安全、より自由につながることができるソリューションを提供する必要がある。

通常、ネットワーク上では、各デバイスに静的または動的に割り当てられたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを用いて、デバイス間のデータ通信が実現される。

デバイス間のデータ通信を実現するためには、送信元のデバイスから送出されたデータを宛先のデバイスまで転送しなければならない。このようなデータ転送の処理は、「ルーティング」などと称される。このようなルーティングを実現するために、ネットワーク上には多数のルータが配置される。

特開平０５−０２２２９３号公報（特許文献１）に開示されるように、ルータは、経路情報を記憶する経路情報テーブルを有しており、受信フレーム中のインターネットワーキング用アドレスと、経路情報テーブルの内容に従って、経路を定めて受信フレームの中継を行う（特開平０５−０２２２９３号公報の段落［０００５］および［０００６］など参照）。

特開平０５−０２２２９３号公報

上記特許文献１によれば、多数のデバイスが存在するネットワークを想定すると、ルータも多数必要となり、また、各ルータの責務も大きくなるという問題が生じる。そのため、多数のデバイスが存在するネットワークにおいては、各デバイスが自立してデータ通信を実現できる構成が好ましい。本開示は、多数のデバイスが存在するネットワークにおいて、各デバイスが自立してデータ通信を実現するデータ送信方法などの解決策を提供する。

本開示のある形態によれば、複数のデバイスが接続されたネットワークにおけるデータ通信方法が提供される。データ通信方法は、第１のデバイスにおいて、第２のデバイスを宛先とするパケットを第２のデバイスに関連付けられた第１の暗号鍵により暗号化して第１の暗号化パケットを生成するステップと、第１の暗号化パケットの送出先となるデバイスを決定し、当該決定したデバイスに関連付けられた第２の暗号鍵により第１の暗号化パケットを暗号化して第２の暗号化パケットを生成し、当該決定したデバイスへ送信するステップと、第２の暗号化パケットを受信したデバイスにおいて、第２の暗号化パケットを第１の暗号化パケットに復号し、当該復号された第１の暗号化パケットが自デバイス宛てであるか否かを判断するステップと、自デバイス宛てであるか否かの判断により、復号された第１の暗号化パケットが自デバイス宛てでなければ、別のデバイスを決定し送信するステップを実行し、復号された第１の暗号化パケットが自デバイス宛てであれば、第１の暗号化パケットをさらに復号するステップとを含む。

上記のデータ通信方法は、複数のデバイスの各々において、各デバイスが有している公開鍵および当該公開鍵に関連付けられた電子証明書を他のデバイスに送信するステップと、公開鍵および電子証明書を受信したデバイスにおいて、ハッシュ関数に従って公開鍵から算出されるハッシュ値に基づいて、公開鍵および電子証明書の送信元のデバイスのＩＰアドレスを決定するステップとをさらに含んでいてもよい。

本開示の別の形態によれば、ネットワークに接続されたデバイスでの通信処理方法が提供される。通信処理方法は、他のデバイスを宛先とするパケットが与えられると実行される、当該パケットを他のデバイスに関連付けられた第１の暗号鍵により暗号化して第１の暗号化パケットを生成するステップと、第１の暗号化パケットの送出先となるデバイスを決定するステップと、第１の暗号化パケットを決定したデバイスに関連付けられた第２の暗号鍵により暗号化して第２の暗号化パケットを生成するステップと、第２の暗号化パケットを決定したデバイスへ送信するステップとを含む。通信処理方法は、さらに、他のデバイスから第２の暗号化パケットを受信すると実行される、第２の暗号化パケットを第１の暗号化パケットに復号するステップと、復号された第１の暗号化パケットが、自デバイス宛てであるか否かの判断により、自デバイス宛てであるか否かを判断するステップと、復号された第１の暗号化パケットが自デバイス宛てでなければ、当該第１の暗号化パケットの送出先となるさらに別のデバイスを決定し、当該決定したデバイスに関連付けられた第２の暗号鍵により第２の暗号化パケットを生成して送信するステップと、復号された第１の暗号化パケットが自デバイス宛てであれば、第１の暗号化パケットをさらに復号するステップとを含む。

上述の形態において、各デバイスが有しているＩＰアドレスに基づいて、送出先となるデバイスが決定されてもよい。

上述の通信処理方法は、秘密鍵および公開鍵を取得するステップと、ハッシュ関数に従って公開鍵から算出されるハッシュ値に基づいて、自デバイスのＩＰアドレスを決定するステップと、認証局から公開鍵に関連付けられた電子証明書を取得するステップと、公開鍵および電子証明書を他のデバイスに送信するステップとをさらに含んでいてもよい。

上述の通信処理方法は、他のデバイスから公開鍵および公開鍵に関連付けられた電子証明書を受信すると、電子証明書の正当性を判断するステップと、電子証明書が正当であると判断されると、ハッシュ関数に従って公開鍵から算出されるハッシュ値に基づいて、他のデバイスのＩＰアドレスを決定するステップとをさらに含んでいてもよい。

上述の通信処理方法は、他のデバイスを宛先とするパケットが与えられると実行される、当該宛先のデバイスのＩＰアドレスを探索するステップをさらに含んでいてもよい。

上述の通信処理方法は、他のデバイスを宛先とするパケットが与えられると実行される、他のデバイスとの間のセッションを確立するとともに、第１の暗号鍵を決定するステップをさらに含んでいてもよい。また、上述の通信処理方法は、他のデバイスから第２の暗号化パケットを受信すると実行される、第１の暗号化パケットの送出先となるさらに別のデバイスとの間のセッションを確立するとともに、第２の暗号鍵を決定するステップをさらに含んでいてもよい。

本開示のさらに別の形態によれば、ネットワークに接続するためのネットワークインターフェイスと、ネットワークインターフェイスに接続された制御部とを含む装置が提供される。制御部は、パケットを他のデバイスに関連付けられた第１の暗号鍵を用いて第１の暗号化パケットに暗号化する処理、および、第１の暗号化パケットを復号する処理を実行可能な第１の暗号化／復号部と、第１の暗号化パケットを第１の暗号化パケットの送出先となるデバイスに関連付けられた第２の暗号鍵を用いて第２の暗号化パケットに暗号化する処理、および、第２の暗号化パケットを復号する処理を実行可能な第２の暗号化／復号部と、他のデバイスを宛先とするパケットが第１の暗号化／復号部および第２の暗号化／復号部においてそれぞれ暗号化されることで生成される第２の暗号化パケットを送出先のデバイスに送信する送信管理部とを含む。送信管理部は、他のデバイスから受信した第２の暗号化パケットを第２の暗号化／復号部において復号することで生成される第１の暗号化パケットが自デバイス宛てであるか否かを判断し、生成された第１の暗号化パケットが自デバイス宛てでなければ、当該第１の暗号化パケットが第２の暗号化／復号部において暗号化されることで生成される第２の暗号化パケットをさらに別のデバイスに送信し、生成された第１の暗号化パケットが自デバイス宛てであれば、当該第１の暗号化パケットを第１の暗号化／復号部においてさらに復号し出力する。

本開示のさらに別の形態によれば、ネットワークに接続するためのネットワークインターフェイスを有するコンピュータのための通信処理プログラムが提供される。通信処理プログラムはコンピュータによって実行されると、コンピュータに上述のいずれかの通信処理方法を実行させる。

本開示によれば、多数のデバイスが存在するネットワークにおいて、各デバイスが自立してデータ通信を実現できる解決策を提供できる。

本実施の形態に従うネットワークシステムの全体構成の一例を示す模式図である。 本実施の形態に従うデバイスのハードウェア構成例を示す模式図である。 本実施の形態に従うデバイスのプログラムおよびデータの構成例を示す模式図である。 本実施の形態に従うネットワークシステムにおけるＩＰアドレスの認証手順を説明するための図である。 本実施の形態に従うネットワークシステムで利用されるＩＰアドレスに埋め込まれる種類特定情報の一例を示す図である。 本実施の形態に従うネットワークシステムにおいてデバイスが認証済みＩＰアドレスを提供する処理手順を示すフローチャートである。 本実施の形態に従うネットワークシステムにおけるＩＰアドレスの通知に係る処理を説明するための図である。 本実施の形態に従うネットワークシステムにおけるＩＰアドレスの通知に係る処理を説明するための図である。 本実施の形態に従うネットワークシステムにおけるＩＰアドレスの通知に係る処理手順を示すシーケンスチャートである。 本実施の形態に従うネットワークシステムにおけるデータ通信の概要を説明するための図である。 本実施の形態に従うデバイスにおけるデータ送信に係る機能構成を示す模式図である。 本実施の形態に従うデバイスにおけるデータ送信時の動作例を示す模式図である。 本実施の形態に従うデバイスにおいて送信パケットが発生した場合の処理手順を示すフローチャートである。 本実施の形態に従うデバイスにおいて他のデバイスからパケットを受信した場合の処理手順を示すフローチャートである。

本開示に係る実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。

＜Ａ．ネットワークシステム１の全体構成＞
まず、本実施の形態に従うネットワークシステム１の全体構成について説明する。

図１は、本実施の形態に従うネットワークシステム１の全体構成の一例を示す模式図である。図１を参照して、インターネットやイントラネットなどの任意のネットワーク２には、複数のデバイス１００−１，１００−２，１００−３，１００−４，１００−５，・・・（以下、「デバイス１００」と総称することもある。）が接続されているとする。一部のデバイス１００は、アクセスポイント４との間に確立された無線通信を介して、ネットワーク２に接続されてもよい。あるいは、別の一部のデバイス１００は、移動体基地局６との間に確立された無線通信を介して、ネットワーク２に接続されてもよい。

このように、ネットワーク２は、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、無線アクセスネットワーク（ＲＡＮ）、およびインターネットのうちのいずれかを含んでいてもよい。

ネットワークに接続されたデバイス１００の各々は、ネットワークの「ノード」とみなすことができ、以下の説明においては、デバイス１００を「ノード」と称することもある。

本実施の形態に従うネットワークシステム１において、デバイス１００の間では、後述するような手順に従って、データ通信を実現する。なお、デバイス１００間の物理的な接続方法はどのようなものであってもよい。

デバイス１００は、各々が有しているＩＰアドレスを用いて他のデバイスとデータ通信を行う機能を有している任意の装置を包含する。デバイス１００は、通信装置単体として構成されることもあるし、何らかのモノの一部として、あるいは、何らかのモノに組み込まれて構成されることもある。

より具体的には、デバイス１００は、例えば、パーソナルコンピュータ、スマートフォン、タブレット、ユーザの身体（例えば、腕や頭など）に装着されるウェアラブルデバイス（例えば、スマートウォッチやＡＲグラスなど）のいずれであってもよい。また、デバイス１００は、スマート家電、コネクティッド自動車、工場などに設置された制御機器あるいはその一部であってもよい。

本実施の形態に従うネットワークシステム１は、１または複数の認証局２００をさらに含む。認証局２００の各々は、１または複数のサーバで構成されるコンピュータである。１または複数の認証局２００を用いて、後述するような手順によって、各デバイス１００が有しているＩＰアドレスは認証される。その結果、各デバイス１００は、認証済みＩＰアドレスを有することになる。

本明細書において、「認証済みＩＰアドレス」は、通信先あるいは第三者に対して、各デバイス１００が保持しているＩＰアドレスの正当性が保証されている状態を意味する。より具体的には、「認証済みＩＰアドレス」は、不可逆な暗号学的ハッシュ関数によって生成されるとともに、認証局によって直接的または間接的に認証されたＩＰアドレスであることを意味する（詳細については後述する）。このような「認証済みＩＰアドレス」を用いることで、各デバイス１００がデータ通信に利用するＩＰアドレスが偽装されていないことを保証できる。

その結果、ネットワークシステム１に含まれる任意のデバイス１００は、各デバイス１００が有しているＩＰアドレスに基づいて一意に特定されることになる。すなわち、各デバイスは、各デバイスが有しているＩＰアドレスに基づいて、データ送信の宛先や送出先となるデバイスを決定できる。

ＩＰアドレスは、インターネットに接続されたデバイス１００間のデータ通信にも用いることができるグローバルＩＰアドレスが想定されるが、特定のネットワーク内だけで利用されるプライベートＩＰアドレスであってもよい。

ＩＰアドレスは、バージョンによって、アドレスを構成するビット数が異なっている。現在制定されているＩＰｖ４（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ４）においては、３２ビットのアドレス区間が規定されており、現在制定されているＩＰｖ６（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ６）においては、１２８ビットのアドレス区間が規定されている。本実施の形態においては、ＩＰｖ６に従うＩＰアドレスを主として説明する。但し、より多くのビット数で規定されるネットワークアドレス、あるいは、より少ないビット数で規定されるネットワークアドレスにも本開示は適用可能である。

＜Ｂ．デバイス１００の構成例＞
次に、本実施の形態に従うネットワークシステム１に用いられるデバイス１００のハードウェアおよびソフトウェアの構成例について説明する。

図２は、本実施の形態に従うデバイス１００のハードウェア構成例を示す模式図である。図２を参照して、デバイス１００は、主たるコンポーネントとして、処理回路（ｐｒｏｃｅｓｓｉｎｇ ｃｉｒｃｕｉｔｒｙ）である制御部１１０とを含む。

制御部１１０は、本実施の形態に従う機能の提供および処理の実行を実現するための演算主体である。制御部１１０は、図２に示すようなプロセッサおよびメモリを用いて、メモリに格納されたコンピュータ可読命令（ｃｏｍｐｕｔｅｒ ｒｅａｄａｂｌｅ ｉｎｓｔｒｕｃｔｉｏｎｓ）（図３に示すようなＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）および通信処理プログラム）をプロセッサが実行するように構成されてもよい。あるいは、コンピュータ可読命令に相当する回路が組み込まれたＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などのハードワイヤード回路を用いて制御部１１０を実現してもよい。さらにあるいは、ＦＰＧＡ（ｆｉｅｌｄ−ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）上にコンピュータ可読命令に相当する回路を実現することで制御部１１０を実現してもよい。また、プロセッサおよびメモリ、ＡＳＩＣ、ＦＰＧＡなどを適宜組み合わせて制御部１１０を実現してもよい。

図２に示すようなプロセッサおよびメモリを用いた構成において、制御部１１０は、プロセッサ１０２と、主メモリ１０４と、ストレージ１０６と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１０８とを含む。

プロセッサ１０２は、コンピュータ可読命令を順次読出して実行する演算回路である。プロセッサ１０２は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＭＰＵ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）などで構成される。複数のプロセッサ１０２を用いて制御部１１０を実現してもよいし（マルチプロセッサの構成）、複数のコアを有するプロセッサを用いて制御部１１０を実現してもよい（マルチコアの構成）。

主メモリ１０４は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの揮発性記憶装置である。プロセッサ１０２は、ストレージ１０６またはＲＯＭ１０８に格納された各種プログラムのうち、指定されたプログラムを主メモリ１０４上に展開し、主メモリ１０４と協働することで、本実施の形態に従う各種処理を実現する。

ストレージ１０６は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリなどの不揮発性記憶装置である。ストレージ１０６には、プロセッサ１０２で実行される各種プログラムや後述するような各種データが格納されている。

ＲＯＭ１０８は、プロセッサ１０２で実行される各種プログラムや後述するような各種データを固定的に格納する。

図２に示すようなプロセッサ１０２がメモリに格納されたコンピュータ可読命令を実行する構成において、メモリは、ストレージ１０６およびＲＯＭ１０８に相当する。

ここで、デバイス１００のメモリに格納されるプログラムおよびデータの一例について説明する。

図３は、本実施の形態に従うデバイス１００のプログラムおよびデータの構成例を示す模式図である。図３を参照して、デバイス１００のメモリ（ストレージ１０６および／またはＲＯＭ１０８）には、例えば、コンピュータ可読命令を含むプログラムとして、ＯＳ１６０と、通信処理プログラム１７０と、各種アプリケーション３００とが格納される。

ＯＳ１６０は、デバイス１００で実行される処理を実現するための基本的な機能を提供するプログラムである。通信処理プログラム１７０は、主として、本実施の形態に従う機能の提供および処理の実行を実現するためのプログラムである。なお、通信処理プログラム１７０は、ＯＳ１６０が提供するライブラリなどを利用して、本実施の形態に従う機能の提供および処理の実行を実現することもある。

各種アプリケーション３００は、デバイス１００が提供する各種機能を実現するためのプログラムであり、ユーザが任意にインストールすることができる。典型的には、各種アプリケーション３００は、通信処理プログラム１７０に提供されるデータ通信機能を利用した各種処理を提供する。

また、デバイス１００のメモリ（ストレージ１０６および／またはＲＯＭ１０８）には、例えば、本実施の形態に従う機能の提供および処理の実行の実現に必要なデータとして、秘密鍵１７２と、公開鍵１７４と、電子証明書１７６とが格納される。秘密鍵１７２および公開鍵１７４は、任意の暗号化／復号アルゴリズムに従って生成される、いわゆる鍵ペアである。秘密鍵１７２は、他のデバイスとの暗号化通信に用いられる。公開鍵１７４は、後述するような手順に従って各デバイス１００のＩＰアドレスの決定に用いられる。電子証明書１７６は、認証局２００によって公開鍵１７４に対して発行されるものであり、デバイス１００のＩＰアドレスの正当性を担保するためのものである。通常、電子証明書１７６は、認証局２００の秘密鍵を用いて、各デバイス１００の公開鍵１７４から算出されたハッシュ値（電子署名）などを含む。電子証明書１７６を受信したデバイス１００は、認証局２００の公開鍵を用いて、電子証明書１７６および電子証明書１７６に関連付けられた公開鍵１７４の正当性を確認する。

鍵ペア（秘密鍵１７２および公開鍵１７４）の生成、電子証明書１７６の取得、およびこれらのデータの利用手順などについては後述する。

なお、ストレージ１０６およびＲＯＭ１０８の両方を設ける必要はなく、実装形態に応じて、いずれか一方のみを設けるようにしてもよい。また、ストレージ１０６およびＲＯＭ１０８の両方を設ける場合には、例えば、鍵ペア（秘密鍵１７２および公開鍵１７４）についてはＲＯＭ１０８に格納して、秘匿性を高めるようにしてもよい。

再度図２を参照して、デバイス１００は、デバイス１００をネットワークに接続するためのネットワークインターフェイス１２０をさらに含む。ネットワークインターフェイス１２０は、ネットワークを介して他のデバイスとデータ通信を行う。

ネットワークインターフェイス１２０は、例えば、イーサネット（登録商標）ポート、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポート、ＩＥＥＥ１３９４などのシリアルポート、レガシーなパラレルポートといった有線接続端子を含む。あるいは、ネットワークインターフェイス１２０は、デバイス、ルータ、移動体基地局などと無線通信するための処理回路およびアンテナなどを含んでもよい。ネットワークインターフェイス１２０が対応する無線通信は、例えば、Ｗｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）、ＬＰＷＡ（Ｌｏｗ Ｐｏｗｅｒ Ｗｉｄｅ Ａｒｅａ）、ＧＳＭ（登録商標）、Ｗ−ＣＤＭＡ、ＣＤＭＡ２００、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、第５世代移動通信システム（５Ｇ）のいずれであってもよい。

デバイス１００は、オプショナルなコンポーネントとして、表示部１３０と、入力部１４０と、メディアインターフェイス１５０とを含んでいてもよい。

表示部１３０は、プロセッサ１０２での処理結果などを外部へ提示するためのコンポーネントである。表示部１３０は、例えば、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）や有機ＥＬ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイなどであってもよい。また、表示部１３０は、ユーザの頭部に装着されるヘッドマウントディスプレイであってもよいし、画像をスクリーン上に投影するプロジェクターであってもよい。

入力部１４０は、デバイス１００を操作するユーザの入力操作を受け付けるためのコンポーネントである。入力部１４０は、例えば、キーボード、マウス、表示部１３０上に配置されたタッチパネル、デバイス１００の筐体に配置された操作ボタンなどであってもよい。

メディアインターフェイス１５０は、各種プログラム（コンピュータ可読命令）および／または各種データが格納された非一過性（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ）のメディア１５２から各種プログラムおよび／または各種データを読み出す。

メディア１５２は、例えば、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）などの光学メディア、ＵＳＢメモリなどの半導体メディアなどであってもよい。メディアインターフェイス１５０は、メディア１５２の種類に応じた構成が採用される。メディアインターフェイス１５０により読み出された各種プログラムおよび／または各種データは、ストレージ１０６などに格納されてもよい。

なお、メディア１５２を介して各種プログラムおよび／または各種データをデバイス１００にインストールするのではなく、ネットワーク上の配信サーバから必要なプログラムおよびデータをデバイス１００にインストールするようにしてもよい。この場合には、ネットワークインターフェイス１２０を介して、必要なプログラムおよびデータが取得される。

上述したように、表示部１３０、入力部１４０、メディアインターフェイス１５０は、オプショナルなコンポーネントであるため、例えば、ＵＳＢなどの任意のインターフェイスを介してデバイス１００の外部から接続されるようにしてもよい。

本実施の形態に従う機能の提供および処理の実行を実現するのは制御部１１０であり、本願の技術的範囲は、少なくとも、制御部１１０を実現するためのハードウェアおよび／またはソフトウェアを包含する。ハードウェアは、上述したように、プロセッサおよびメモリからなる構成だけではなく、ＡＳＩＣなどを用いたハードワイヤード回路やＦＰＧＡを用いた構成を含み得る。すなわち、制御部１１０は、汎用コンピュータにプログラムをインストールすることで実現され得るし、専用のチップとして実現することもできる。

また、プロセッサで実行されるソフトウェアは、メディア１５２を介して流通するものだけではなく、配信サーバを介して適宜ダウンロードされるものも含み得る。

なお、本実施の形態に従う機能の提供および処理の実行を実現するための構成は、図２に示す制御部１１０に限られず、実現される時代に応じた任意の技術を用いて実装できる。

＜Ｃ．認証済みＩＰアドレス＞
次に、各デバイス１００に対して認証済みＩＰアドレスを提供するための処理などについて説明する。

（ｃ１：ＩＰアドレスの決定処理）
本実施の形態に従うネットワークシステム１においては、典型的には、認証済みＩＰアドレスを用いて、各デバイス１００のＩＰアドレスを認証する。一例として、公開鍵暗号基盤（ＰＫＩ：ｐｕｂｌｉｃ ｋｅｙ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を用いて、各デバイス１００のＩＰアドレスを認証してもよい。

図４は、本実施の形態に従うネットワークシステム１におけるＩＰアドレスの認証手順を説明するための図である。なお、図４中の「Ｓ１」〜「Ｓ４」などの符号は、図６に示すステップ番号に対応している。

図４を参照して、デバイス１００は、秘密鍵１７２および公開鍵１７４からなる鍵ペアを有している。予め定められたハッシュ関数１８０に公開鍵１７４を入力することでハッシュ値１７８を算出し、その算出されたハッシュ値１７８の全部または一部を用いて、デバイス１００のＩＰアドレス１９０として用いる。

このようなＩＰアドレス１９０の決定処理に伴い、デバイス１００は、公開鍵１７４を認証局２００へ送信し、認証局２００が公開鍵１７４に対して発行する電子証明書１７６を紐付ける。デバイス１００は、自デバイスの公開鍵１７４および電子証明書１７６を他のデバイスへ送信する。他のデバイスは、デバイス１００が公開する公開鍵１７４および電子証明書１７６に基づいて、デバイス１００のＩＰアドレス１９０の正当性を確認する。ＩＰアドレス１９０の正当性が確認されると、正当性が確認されたＩＰアドレス１９０を用いてデータ通信を開始する。自デバイスおよび他のデバイスは、互いに直接通信を行うことができるが、直接通信の処理に加えて、認証局２００における問い合わせの処理を含むようにしてもよい。

このように、本実施の形態に従うネットワークシステム１においては、ＩＰアドレス１９０自体を認証することができ、このような認証済みＩＰアドレス１９０をデバイス自体が保持することで、各デバイスに静的または動的に割り当てられたＩＰアドレスを用いることなく、自立的なネットワークを構築できる。

以下、本実施の形態に従うネットワークシステム１における認証済みＩＰアドレスを提供するための処理の詳細について説明する。

鍵ペアである秘密鍵１７２および公開鍵１７４は、デバイス１００自身が作成してもよいし、外部から提供されて予めデバイス１００に格納されていてもよい。外部から提供される場合には、デバイス１００は秘密鍵１７２のみを取得し、公開鍵１７４については自身で生成するようにしてもよい。

鍵ペアである公開鍵１７４の生成方法の一例としては、乱数発生器が発生する所定長さのビット列（例えば、５１２ビット）を秘密鍵１７２として用いるとともに、公知の暗号アルゴリズム（例えば、楕円曲線暗号アルゴリズム）に従って秘密鍵１７２から所定長さのビット列（例えば、２５６ビット）からなる公開鍵１７４を生成してもよい。なお、デバイス１００自身が鍵ペアを生成する場合には、乱数発生器は、ＯＳ１６０が提供する機能を利用して実現してもよいし、ＡＳＩＣなどのハードワイヤード回路を用いて実現してもよい。

ハッシュ関数１８０は、公知の不可逆な暗号学的ハッシュ関数（例えば、ＢＬＡＫＥ）を用いることができる。ハッシュ関数１８０は、所定長さのビット列（例えば、２５６ビット）からなるハッシュ値１７８を算出する。

ハッシュ関数１８０には、公開鍵１７４だけではなく、任意のキーワードを入力するようにしてもよい。任意のキーワードとして、所定の組織に関連付けられたメッセージを用いてもよい。所定の組織に関連付けられたメッセージとして、当該所定の組織が有している商標の名称を含むメッセージを用いてもよい。例えば、所定の組織が保有する登録された商標の名称（例えば、「ｃｏｎｎｅｃｔＦｒｅｅ」）をハッシュ関数１８０に入力するキーワードとして用いるようにしてもよい。このような実装方式を採用することで、所定の組織以外の第三者が、当該所定の組織の許諾なしに本実施の形態に従うネットワークシステム１および関連する方法やプログラムなどを実施することを防止できる。

ハッシュ関数１８０により算出されるハッシュ値１７８の全部または一部がＩＰアドレス１９０として用いられる。例えば、２５６ビット（１６進数表現で６４桁）のハッシュ値１７８が算出される場合には、６４桁のハッシュ値１７８のうち任意の３２桁（例えば、前半３２桁）をＩＰｖ６に対応するＩＰアドレス１９０（１２８ビット）として決定してもよい。あるいは、６４桁のハッシュ値１７８のうち前半８桁をＩＰｖ４に対応するＩＰアドレス１９０（３２ビット）として決定してもよい。

あるいは、ＩＰｖ６に対応するＩＰアドレス１９０（１２８ビット）を考慮して、ハッシュ関数１８０から１２８ビットのハッシュ値１７８を算出するようにしてもよい。この場合には、算出されるハッシュ値１７８の全部をＩＰｖ６に対応するＩＰアドレス１９０（１２８ビット）として決定できる。

本実施の形態によれば、デバイス１００の公開鍵１７４に基づいてデバイス１００に固有のＩＰアドレス１９０を決定できる。このように、デバイス１００によって決定されたＩＰアドレス１９０を用いてデバイス１００をインターネットなどのネットワークに接続させることができる。また、デバイス１００は、インターネットサービスプロバイダ（ＩＳＰ）などのグローバルＩＰアドレスを管理するサービス事業者（サーバ）が存在しなくても、自身が決定したＩＰアドレス１９０を用いてデータ通信を行うことができる。また、デバイス１００は、アクセスポイントなどに実装されるＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバなどのプライベートＩＰアドレスを管理するサーバが存在しなくても、自身が決定したＩＰアドレス１９０を用いてインターネットなどのグルーバルネットワークに接続してデータ通信を行うことができる。したがって、インターネットなどのネットワークへの接続についてのユーザ体験およびユーザの利便性を向上できる。

（ｃ２：固有文字列）
デバイス１００が決定するＩＰアドレス１９０は、本実施の形態に従う処理手順に従って決定されたものであることを特定できるようにしてもよい。このような特定を行うために、例えば、ＩＰアドレス１９０に予め定められた特定用の固有値（固有文字列）を含めるようにしてもよい。すなわち、決定されるＩＰアドレスは、予め定められた特定用の固有値（固有文字列）を含んでいてもよい。

一例として、１６進数表現のＩＰアドレス１９０の先頭２桁（先頭から１桁目および２桁目）を予め定められた固有文字列（例えば、「ＦＣ」）に固定してもよい。通常、ハッシュ関数１８０は一方向性関数であるので、ＩＰアドレス１９０から公開鍵１７４を逆算することはできない。そのため、決定されるＩＰアドレス１９０が所定条件（この場合には、先頭２桁が予め定められた固有値になること）を満たすまで、乱数発生器を用いて、秘密鍵１７２および公開鍵１７４を繰り返し生成してもよい。すなわち、公開鍵１７４は、公開鍵１７４からハッシュ関数に従って算出されるハッシュ値に基づいて決定されるＩＰアドレス１９０が、予め定められたフォーマットに合致するように決定されてもよい。

このように、ＩＰアドレス１９０に予め定められた特定用の固有値（例えば、先頭２桁が「ＦＣ」）を含めることで、第三者は、デバイス１００のＩＰアドレス１９０がデバイス１００自身によって決定されたものであるか否かを判断できる。

（ｃ３：種類特定情報）
デバイス１００が決定するＩＰアドレス１９０には、デバイス１００の種類を特定できる情報を含めてもよい。このような特定を行うために、例えば、ＩＰアドレス１９０にデバイス１００の種類に応じた値を含めるようにしてもよい。すなわち、決定されるＩＰアドレス１９０は、そのＩＰアドレス１９０を決定したデバイス１００の種類に応じた値を含んでいてもよい。

一例として、１６進数表現のＩＰアドレス１９０の先頭から３桁目および４桁目にデバイス１００の種類に応じた値（種類特定情報）を埋め込んでもよい。

図５は、本実施の形態に従うネットワークシステム１で利用されるＩＰアドレスに埋め込まれる種類特定情報の一例を示す図である。図５に示される種類特定情報は、各デバイス１００の制御部１１０のＲＯＭ１０８（図２参照）などに予め格納されていてもよい。一例として、図５に示すようなデバイスの種類に応じた値を用いることができる。

図５に示すように、例えば、デバイス１００の種類がパーソナルコンピュータである場合には、ＩＰアドレス１９０の先頭から３桁目および４桁目には、パーソナルコンピュータを示す値「００」が設定される。

上述したように、通常、ハッシュ関数１８０は一方向性関数であるので、ＩＰアドレス１９０から公開鍵１７４を逆算することはできない。そのため、決定されるＩＰアドレス１９０が所定条件（この場合には、先頭から３桁目および４桁目がデバイス１００の種類を示す値になること）を満たすまで、乱数発生器を用いて、秘密鍵１７２および公開鍵１７４を繰り返し生成してもよい。すなわち、公開鍵１７４は、公開鍵１７４からハッシュ関数に従って算出されるハッシュ値に基づいて決定されるＩＰアドレス１９０が、予め定められたフォーマットに合致するように決定されてもよい。

このように、ＩＰアドレス１９０にデバイス１００の種類を示す値を含めることで、第三者は、デバイス１００が決定したＩＰアドレス１９０から当該デバイス１００の種類を特定できる。

（ｃ４：公開鍵１７４の登録および電子証明書１７６の取得）
次に、公開鍵１７４の登録および電子証明書１７６の取得について説明する。

デバイス１００は、公開鍵１７４の正当性を証明するための電子証明書１７６を認証局２００から取得する。電子証明書１７６を取得する手順としては、デバイス１００から公開鍵１７４を認証局２００へ送信して登録するとともに、登録された公開鍵１７４に関連付けられた電子証明書１７６を認証局２００から取得する。

より具体的には、デバイス１００（制御部１１０）は、ネットワークを介して、公開鍵１７４および電子証明書の発行要求（以下、「証明書署名要求」とも称す。）を認証局２００へ送信する。認証局２００は、デバイス１００から受信した証明書署名要求に応答して、公開鍵１７４を登録するとともに、登録した公開鍵１７４に関連付けられた電子証明書１７６を発行する。そして、認証局２００は、ネットワークを介して、電子証明書１７６をデバイス１００へ送信する。

典型的には、電子証明書１７６は、電子証明書１７６の所有者情報（この例では、デバイス１００）、電子証明書１７６の発行者情報（この例では、認証局２００）、発行者のデジタル署名、および電子証明書１７６の有効期限などを含む。

認証局２００は、所定の組織によって運営されていてもよいし、所定の組織によって運営されているルート認証局に関連付けられた中間認証局であってもよい。また、公開鍵１７４の登録および公開鍵１７４に関連付けられた電子証明書１７６の発行にあたっては、所定の組織に対して所定の手数料および／または維持料が必要であってもよい。

本実施の形態によれば、公開鍵１７４の登録および公開鍵１７４の取得を通じて、公開鍵１７４が認証局２００によって直接的に認証されることで、公開鍵１７４に基づいて決定されるＩＰアドレス１９０も認証局２００によって間接的に認証される。このような認証局２００の認証によって、デバイス１００は、認証済みＩＰアドレス１９０を用いて、ネットワークを介してデータ通信を実現できる。

なお、公開鍵１７４に関連付けられた電子証明書１７６には、秘匿性を向上させるために、デバイス１００の属性に関連する情報（以下、「属性情報」とも称する。）を含んでもよい。デバイス１００の属性情報は、例えば、デバイス１００のＯＳ１６０や通信処理プログラム１７０のバージョン情報、デバイス１００を構成するハードウェア（例えば、プロセッサやストレージなど）のシリアル番号などを用いることができる。この場合、デバイス１００は、公開鍵１７４および証明書署名要求を送信する際に、デバイス１００の属性情報を認証局２００へ送信してもよい。なお、電子証明書１７６に含ませるデバイス１００の属性情報は、公知の不可逆な暗号学的ハッシュ関数などによって暗号化されてもよい。

このように、デバイス１００の属性情報を電子証明書１７６に含ませることで、デバイス１００自身からの証明書署名要求に応答して、電子証明書１７６が発行されたことを認証できる。すなわち、デバイス１００以外のデバイスがデバイス１００になりすまして、デバイス１００の公開鍵１７４および電子証明書１７６を用いることをより確実に防止できる。

（ｃ５：処理手順）
次に、各デバイス１００における認証済みＩＰアドレスを提供するための処理手順について説明する。

図６は、本実施の形態に従うネットワークシステム１においてデバイス１００が認証済みＩＰアドレスを提供する処理手順を示すフローチャートである。図６に示される処理手順は、各デバイス１００においてそれぞれ実行され、図６に示す各ステップは、各デバイス１００の制御部１１０によって実行される。

図６を参照して、デバイス１００は、任意のアルゴリズムに従って生成される鍵ペア（秘密鍵１７２および公開鍵１７４）を取得する（ステップＳ１）。この鍵ペアは、デバイス１００自身が生成してもよいし、デバイス１００が外部から取得してもよい。あるいは、デバイス１００は秘密鍵１７２のみを外部から取得して、公開鍵１７４を内部で生成してもよい。

続いて、デバイス１００は、予め定められたハッシュ関数１８０に公開鍵１７４を入力することでハッシュ値１７８を算出し、その算出されたハッシュ値１７８の全部または一部からデバイス１００のＩＰアドレス１９０を決定する（ステップＳ２）。すなわち、デバイス１００は、ハッシュ関数１８０に従って公開鍵１７４から算出されるハッシュ値１７８に基づいて、自デバイスのＩＰアドレスを決定する。

なお、ＩＰアドレス１９０に固有文字列（例えば、ＩＰアドレス１９０の先頭から１桁目および２桁目）および／または種類特定情報（例えば、ＩＰアドレス１９０の先頭から３桁目および４桁目）が含まれるように、適切な鍵ペア（秘密鍵１７２および公開鍵１７４）が生成されてもよい。

また、デバイス１００は、公開鍵１７４および電子証明書の発行要求（証明書署名要求）を認証局２００へ送信する（ステップＳ３）。認証局２００は、デバイス１００から受信した証明書署名要求に応答して、公開鍵１７４を登録するとともに、登録した公開鍵１７４に関連付けられた電子証明書１７６を発行する。そして、認証局２００は、ネットワークを介して電子証明書１７６をデバイス１００へ送信する。すると、デバイス１００は、認証局２００からの電子証明書１７６を受信して格納する（ステップＳ４）。

このように、デバイス１００は、認証局から公開鍵１７４に関連付けられた電子証明書１７６を取得する。

なお、ステップＳ２の処理と、ステップＳ３およびＳ４の処理との実行順序は問わない。

＜Ｄ．データ通信処理＞
次に、認証済みＩＰアドレスを用いたデバイス１００間のデータ通信処理について説明する。

（ｄ１：ＩＰアドレスの通知）
まず、本実施の形態に従うネットワークシステム１におけるデバイス１００間のＩＰアドレスの通知に係る処理について説明する。

図７および図８は、本実施の形態に従うネットワークシステム１におけるＩＰアドレスの通知に係る処理を説明するための図である。図７および図８には、３つのデバイス１００−１，１００−２，１００−３の間でＩＰアドレスを交換する例を示す。なお、２つのデバイス１００の間でも同様の処理が可能であるし、より多くのデバイス１００の間でも同様の処理が可能である。

図７および図８に示す状態において、デバイス１００−１，１００−２，１００−３の各々は、上述したような手順に従って、デバイス１００−１，１００−２，１００−３は、ＩＰアドレス１９０−１，１９０−２，１９０−３をそれぞれ決定しており、また、認証局２００への公開鍵１７４−１，１７４−２，１７４−３の登録および認証局２００からの電子証明書１７６−１，１７６−２，１７６−３の取得もそれぞれ済んでいるものとする。

図７および図８に示すように、各デバイス１００は、定期的またはイベント毎に、各デバイスが有している公開鍵１７４および公開鍵１７４に関連付けられた電子証明書１７６を送信（ブロードキャスト）する。すなわち、各デバイス１００は、公開鍵１７４および電子証明書１７６を他のデバイスに送信する。なお、公開鍵１７４が電子証明書１７６に含まれる場合には、電子証明書１７６のみを送信するようにしてもよい。

図７には、一例として、デバイス１００−１が公開鍵１７４−１および公開鍵１７４−１に関連付けられた電子証明書１７６−１を送信（ブロードキャスト）する例を示す。図７に示す例では、デバイス１００−２および１００−３がデバイス１００−１により送信された公開鍵１７４−１および電子証明書１７６−１を受信できたとする。すると、デバイス１００−２および１００−３は、電子証明書１７６−１が正当であるか否かを判断した上で、正当であると判断されると、関連付けられた公開鍵１７４−１に基づいてデバイス１００−１のＩＰアドレス１９０−１を決定し、コネクションテーブル１９４−２および１９４−３にそれぞれ登録する。

ここで、コネクションテーブルは、データ通信を行うために各デバイス１００の情報を含むものであり、各デバイス１００は、コネクションテーブルを参照して、宛先のデバイス１００のＩＰアドレスなどを特定するとともに、必要なセッションを確立する。ここで、「セッション」とは、パケットなどのデータの送受信に先立って、必要なデータをやり取りすることで構成される、論理的な通信路を意味する。

より具体的には、デバイス１００−２は、まず、デバイス１００−１からブロードキャストされた電子証明書１７６−１が正当であるか否かを判断する。この正当性を判断する処理においては、電子証明書１７６−１の完全性が検証される。

完全性が検証する処理の一例として、まず、デバイス１００−２は、電子証明書１７６−１の所有者情報、電子証明書１７６−１の発行者情報、発行者のデジタル署名の存在を確認する。そして、デバイス１００−２は、電子証明書１７６−１が有効期限内であるか否かを判断する。さらに、デバイス１００−２は、電子証明書１７６−１の発行元が信頼できるものであるか否かを判断する。特に、電子証明書１７６−１が中間認証局により発行されている場合には、デバイス１００−２は、電子証明書１７６−１を発行した中間認証局に関連付けられたルート認証局を特定するとともに、当該特定されたルート認証局が信頼できるものであるか否かを判断する。例えば、特定されたルート認証局がデバイス１００−１に格納されている１または複数のルート認証局のいずれかと一致する場合には、電子証明書１７６−１の発行元が信頼できると判断する。

以上のような判断処理にパスすると、デバイス１００−２は、デバイス１００−１からブロードキャストされた電子証明書１７６−１が正当であると決定する。すると、デバイス１００−２は、予め定められたハッシュ関数１８０に、デバイス１００−１からブロードキャストされた公開鍵１７４−１を入力することでハッシュ値１７８−１を算出し、その算出されたハッシュ値１７８−１の全部または一部を用いて、デバイス１００−１のＩＰアドレス１９０−１を決定する。ここで、デバイス１００−１および１００−２は、共通のハッシュ関数１８０を有しているものとする。また、デバイス１００−１および１００−２の間において、ハッシュ値１７８−１からＩＰアドレス１９０−１を決定する処理も共通であるとする。

以上のような処理によって、デバイス１００−２は、デバイス１００−１のＩＰアドレス１９０−１を決定できる。そして、デバイス１００−２は、決定したデバイス１００−１のＩＰアドレス１９０−１のエントリをコネクションテーブル１９４−２に追加する。なお、ＩＰアドレス１９０−１に関連付けて公開鍵１７４−１を登録してもよい。

また、デバイス１００−３においてもデバイス１００−２と同様の処理が実行され、デバイス１００−３のコネクションテーブル１９４−３には、決定したデバイス１００−１のＩＰアドレス１９０−１のエントリをコネクションテーブル１９４−２に追加する。なお、ＩＰアドレス１９０−１に関連付けて公開鍵１７４−１を登録してもよい。

図７に示すような処理によって、デバイス１００−２およびデバイス１００−３は、デバイス１００−１のＩＰアドレス１９０−１を取得できる。

図８には、一例として、デバイス１００−２が公開鍵１７４−２および公開鍵１７４−２に関連付けられた電子証明書１７６−２を送信（ブロードキャスト）する例を示す。図８に示す例では、デバイス１００−１および１００−３がデバイス１００−２により送信された公開鍵１７４−２および電子証明書１７６−２を受信できたとする。すると、デバイス１００−１および１００−３は、電子証明書１７６−２が正当であるか否かを判断した上で、正当であると判断されると、関連付けられた公開鍵１７４−２に基づいてデバイス１００−２のＩＰアドレス１９０−２を決定し、コネクションテーブル１９４−１および１９４−３にそれぞれ登録する。

デバイス１００−１および１００−３において実行される一連の処理は、図７を参照して説明した処理と同様であるので、詳細な説明は繰り返さない。図８に示すような処理によって、デバイス１００−１およびデバイス１００−３は、デバイス１００−２のＩＰアドレス１９０−２を取得できる。

さらに、デバイス１００−３が公開鍵１７４−３および公開鍵１７４−３に関連付けられた電子証明書１７６−３を送信（ブロードキャスト）してもよい。デバイス１００−１および１００−２がデバイス１００−３により送信された公開鍵１７４−３および電子証明書１７６−３を受信できたとする。すると、デバイス１００−１および１００−２は、電子証明書１７６−３が正当であるか否かを判断した上で、正当であると判断されると、関連付けられた公開鍵１７４−３に基づいてデバイス１００−３のＩＰアドレス１９０−３を決定し、コネクションテーブル１９４−１および１９４−２にそれぞれ登録する。このような処理によって、デバイス１００−１およびデバイス１００−２は、デバイス１００−３のＩＰアドレス１９０−３を取得できる。

図９は、本実施の形態に従うネットワークシステム１におけるＩＰアドレスの通知に係る処理手順を示すシーケンスチャートである。図９には、図７および図８に対応させて、３つのデバイス１００−１，１００−２，１００−３における処理手順を示す。

デバイス１００−１は、公開鍵１７４−１および公開鍵１７４−１に関連付けられた電子証明書１７６−１を送信（ブロードキャスト）する（シーケンスＳＱ１０）。

デバイス１００−２は、デバイス１００−１により送信された公開鍵１７４−１および電子証明書１７６−１を受信すると、電子証明書１７６−１の正当性を判断する（シーケンスＳＱ１１）。電子証明書１７６−１が正当であると判断されると、デバイス１００−２は、公開鍵１７４−１に基づいてデバイス１００−１のＩＰアドレス１９０−１を決定し（シーケンスＳＱ１２）、決定したデバイス１００−１のＩＰアドレス１９０−１をコネクションテーブル１９４−２に登録する（シーケンスＳＱ１３）。

同様に、デバイス１００−３は、デバイス１００−１により送信された公開鍵１７４−１および電子証明書１７６−１を受信すると、電子証明書１７６−１の正当性を判断する（シーケンスＳＱ１４）。電子証明書１７６−１が正当であると判断されると、デバイス１００−３は、公開鍵１７４−１に基づいてデバイス１００−１のＩＰアドレス１９０−１を決定し（シーケンスＳＱ１５）、決定したデバイス１００−１のＩＰアドレス１９０−１をコネクションテーブル１９４−３に登録する（シーケンスＳＱ１６）。

また、デバイス１００−２は、公開鍵１７４−２および公開鍵１７４−２に関連付けられた電子証明書１７６−２を送信（ブロードキャスト）する（シーケンスＳＱ２０）。

デバイス１００−１は、デバイス１００−２により送信された公開鍵１７４−２および電子証明書１７６−２を受信すると、電子証明書１７６−２の正当性を判断する（シーケンスＳＱ２１）。電子証明書１７６−２が正当であると判断されると、デバイス１００−１は、公開鍵１７４−２に基づいてデバイス１００−２のＩＰアドレス１９０−２を決定し（シーケンスＳＱ２２）、決定したデバイス１００−２のＩＰアドレス１９０−２をコネクションテーブル１９４−１に登録する（シーケンスＳＱ２３）。

同様に、デバイス１００−３は、デバイス１００−２により送信された公開鍵１７４−２および電子証明書１７６−２を受信すると、電子証明書１７６−２の正当性を判断する（シーケンスＳＱ２４）。電子証明書１７６−２が正当であると判断されると、デバイス１００−３は、公開鍵１７４−２に基づいてデバイス１００−２のＩＰアドレス１９０−２を決定し（シーケンスＳＱ２５）、決定したデバイス１００−２のＩＰアドレス１９０−２をコネクションテーブル１９４−３に登録する（シーケンスＳＱ２６）。

また、デバイス１００−３は、公開鍵１７４−３および公開鍵１７４−３に関連付けられた電子証明書１７６−３を送信（ブロードキャスト）する（シーケンスＳＱ３０）。

デバイス１００−１は、デバイス１００−３により送信された公開鍵１７４−３および電子証明書１７６−３を受信すると、電子証明書１７６−３の正当性を判断する（シーケンスＳＱ３１）。電子証明書１７６−３が正当であると判断されると、デバイス１００−１は、公開鍵１７４−３に基づいてデバイス１００−３のＩＰアドレス１９０−３を決定し（シーケンスＳＱ３２）、決定したデバイス１００−３のＩＰアドレス１９０−３をコネクションテーブル１９４−１に登録する（シーケンスＳＱ３３）。

同様に、デバイス１００−２は、デバイス１００−３により送信された公開鍵１７４−３および電子証明書１７６−３を受信すると、電子証明書１７６−３の正当性を判断する（シーケンスＳＱ３４）。電子証明書１７６−３が正当であると判断されると、デバイス１００−２は、公開鍵１７４−３に基づいてデバイス１００−３のＩＰアドレス１９０−３を決定し（シーケンスＳＱ３５）、決定したデバイス１００−３のＩＰアドレス１９０−３をコネクションテーブル１９４−２に登録する（シーケンスＳＱ３６）。

なお、シーケンスＳＱ１０〜ＳＱ１６の処理と、シーケンスＳＱ２０〜ＳＱ２６の処理と、シーケンスＳＱ３０〜ＳＱ３６の処理とは、任意の順序あるいは並列的に実行され得る。

このように、各デバイス１００は、他のデバイスから公開鍵１７４および公開鍵１７４に関連付けられた電子証明書１７６を受信すると、電子証明書１７６の正当性を判断する（シーケンスＳＱ１１，ＳＱ１４，ＳＱ２１，ＳＱ２４，ＳＱ３１，ＳＱ３４）。そして、各デバイス１００は、電子証明書１７６が正当であると判断されると、ハッシュ関数に従って公開鍵１７４から算出されるハッシュ値に基づいて、他のデバイスのＩＰアドレスを決定する（シーケンスＳＱ１２，ＳＱ１５，ＳＱ２２，ＳＱ２５，ＳＱ３２，ＳＱ３５）。

上述したように、本実施の形態に従うネットワークシステム１においては、他のデバイス１００から送信された電子証明書１７６が正当であると判断されることを条件に、電子証明書１７６に関連付けられた公開鍵１７４に基づいて、当該他のデバイス１００のＩＰアドレス１９０を決定する。公開鍵１７４に関連付けられた電子証明書１７６が正当であるとの判断を条件に、公開鍵１７４に基づいてＩＰアドレス１９０を決定するので、公開鍵１７４の正当性およびＩＰアドレス１９０の正当性を保証できる。したがって、デバイス１００の間で確実なデータ通信を実現できる。

また、本実施の形態に従うネットワークシステム１においては、各デバイス１００がブロードキャストする公開鍵１７４に基づいて、各デバイス１００のＩＰアドレスを知ることができるので、ＩＰアドレスを管理するサーバが存在しなくても、デバイス１００同士が直接接続し得る。特に、バーチャルプライベートネットワーク（ＶＰＮ）サーバなどが存在しなくても、デバイス１００同士で秘匿性の確保された通信を実現できるため、ＶＰＮサーバを維持するためのコストや消費電力を削減できる。

（ｄ２：データ通信）
次に、デバイス１００間のデータ通信に係る処理について説明する。本実施の形態に従うネットワークシステム１においては、各デバイス１００がルーティング機能およびデータ転送機能を有しており、このような機能によって、自立的にデータ通信を行うことができるネットワークを実現できる。

また、本実施の形態に従うネットワークシステム１においては、データ通信されるデータ（典型的には、パケットまたはフレーム）は、セッション毎に設定される暗号鍵により暗号化される。そのため、データ通信の秘匿性を担保できる。

まず、本実施の形態に従うネットワークシステム１におけるデータ通信の概要について説明する。以下の説明では、典型例として、データは「パケット」の形で送信されるものとする。

図１０は、本実施の形態に従うネットワークシステム１におけるデータ通信の概要を説明するための図である。図１０には、一例として、３つのデバイス１００−１，１００−２，１００−３を含むネットワークにおけるデータ送信方法を説明する。

図１０において、一例として、デバイス１００−１とデバイス１００−２との間は直接的に通信が可能であり、デバイス１００−２とデバイス１００−３との間は直接的に通信が可能であるとする。但し、デバイス１００−１とデバイス１００−３との間は、直接的な通信はできない状態であるとする。ここで、直接的な通信が可能な状態とは、典型的には、ノード間が１ホップ以内に存在しているような接続状態を意味する。このような接続状態において、デバイス１００−１からデバイス１００−３に向けてパケットを送信する処理について説明する。

本実施の形態に従うネットワークシステム１においては、２段階のセッションが確立される。より具体的には、２段階のセッションは、１段階目のセッションである隣接ノードセッション１２と、２段階目のセッションであるエンドトゥエンドセッション１４とを含む。

隣接ノードセッション１２は、直接的な通信が可能なデバイス１００間に確立されるセッションである。図１０に示す例では、デバイス１００−１とデバイス１００−２との間、および、デバイス１００−２とデバイス１００−３との間に隣接ノードセッション１２が確立される。一方、エンドトゥエンドセッション１４は、送信元のデバイス１００と宛先のデバイス１００との間に確立されるセッションである。

隣接ノードセッション１２およびエンドトゥエンドセッション１４の各々において、パケットはそれぞれ暗号化される。典型的には、各セッションが確立される過程において、ノード間で使用される暗号鍵が交換ないし共有される。その結果、エンドトゥエンドセッション１４においては、デバイス１００−１とデバイス１００−３との間で交換ないし共有された暗号鍵に基づいて、送信すべきパケット（以下、「送信パケット２０」とも称す。）を暗号化して得られる暗号化パケット２２がやり取りされる。送信パケット２０は、宛先などの情報を含むヘッダ部２０Ｈおよびデータ本体部２０Ｄからなる。暗号化パケット２２は、送信パケット２０全体を暗号化した結果をデータ本体部２２Ｄとして含み、さらに宛先などの情報を含むヘッダ部２２Ｈが付加されている。このようなデータ構造を採用することで、データ本体部２２Ｄに含まれる送信パケット２０の秘匿性を維持しつつ、宛先のデバイスまでパケット転送を実現できる。

隣接ノードセッション１２においては、デバイス１００−１とデバイス１００−２との間で交換ないし共有された別の暗号鍵に基づいて、暗号化パケット２２をさらに暗号化して得られる暗号化パケット２４がやり取りされる。また、デバイス１００−２とデバイス１００−３との間で交換ないし交換されたさらに別の暗号鍵に基づいて、暗号化パケット２２をさらに暗号化して得られる暗号化パケット２６がやり取りされる。

暗号化パケット２４は、暗号化パケット２２全体を暗号化した結果をデータ本体部２４Ｄとして含み、さらに宛先などの情報を含むヘッダ部２４Ｈが付加されている。同様に、暗号化パケット２６は、暗号化パケット２２全体を暗号化した結果をデータ本体部２６Ｄとして含み、さらに宛先などの情報を含むヘッダ部２６Ｈが付加されている。

なお、デバイス１００−２においては、暗号化パケット２４が暗号化パケット２２に一旦復号された後に、再度暗号化されて暗号化パケット２６が生成されることになる。この場合であっても、デバイス１００−２は、エンドトゥエンドセッション１４において生成された暗号化パケット２２を復号できないので、データ通信の秘匿性は担保される。

図１０に示すデータ送信方法において、デバイス１００−１は、デバイス１００−２を宛先とする送信パケット２０をデバイス１００−２に関連付けられた暗号鍵により暗号化して暗号化パケット２２を生成する。そして、デバイス１００−１は、暗号化パケット２２の送出先となるデバイス（図１０に示す例では、デバイス１００−２）を決定し、当該決定したデバイスに関連付けられた暗号鍵により暗号化パケット２２を暗号化して暗号化パケット２４を生成し、当該決定したデバイスへ送信する。

暗号化パケット２４を受信したデバイス１００−２は、暗号化パケット２４を暗号化パケット２２に復号し、復号された暗号化パケット２２が自デバイス宛てであるか否かを判断する。そして、復号された暗号化パケット２２が自デバイス宛てでなければ、デバイス１００−２は、デバイス１００−１が暗号化パケット２４をデバイス１００−２に送信したのと同様の処理を実行する。すなわち、デバイス１００−２は、暗号化パケット２２のさらなる送出先となるデバイス（この場合には、デバイス１００−３）を決定し、当該決定したデバイスに関連付けられた暗号鍵により暗号化パケット２２を暗号化して暗号化パケット２６を生成し、当該決定したデバイスへ送信する。

一方、復号された暗号化パケット２２が自デバイス宛てであれば（この例では、図１０に示す例では、暗号化パケット２２がデバイス１００−３に到達したとき）、暗号化パケット２２が送信パケット２０に復号される。

図１１は、本実施の形態に従うデバイス１００におけるデータ送信に係る機能構成を示す模式図である。図１１を参照して、デバイス１００は、図１０に示すようなデータ通信を実現するための構成として、ルータエンジン１１２０と、転送エンジン１１１０と、インターフェイス１２１０とを含む。これらのコンポーネントは、制御部１１０によって提供されることになる。

ルータエンジン１１２０は、主として、エンドトゥエンドセッション１４を担当し、転送エンジン１１１０は、主として、隣接ノードセッション１２を担当する。

ルータエンジン１１２０は、各種アプリケーション３００から送信パケットを与えられると、宛先のデバイス１００との間で交換ないし交換された暗号鍵を用いて送信パケットを暗号化するとともに、暗号化した送信パケットを含む暗号化パケットを宛先のデバイス１００へ送信する。

また、ルータエンジン１１２０は、転送エンジン１１１０から暗号化パケットを与えられると、当該暗号化パケットが自デバイス宛てであるか否かを判断する。自デバイス宛ての暗号化パケットである場合には、ルータエンジン１１２０は、送信元のデバイス１００との間で交換ないし共有された暗号鍵を用いて当該暗号化パケットに含まれる送信パケットを受信されたパケット（以下、「受信パケット」とも称す。）として復号し、各種アプリケーション３００へ出力する。一方、他デバイス宛ての暗号化パケットである場合には、ルータエンジン１１２０は、当該暗号化パケットを転送エンジン１１１０へ戻す。

より具体的には、ルータエンジン１１２０は、セッション管理エンジン１１２２と、暗号化／復号エンジン１１２４と、エンドトゥエンドセッション管理テーブル１１２６と、サーチエンジン１１２８とを含む。

セッション管理エンジン１１２２は、宛先のデバイス１００との間のセッション確立、パケットの転送処理および再送処理などを行う。また、セッション管理エンジン１１２２は、与えられた送信パケットの宛先に応じて、当該送信パケットの送信先を決定する。暗号化／復号エンジン１１２４は、データの暗号化および復号を行う。エンドトゥエンドセッション管理テーブル１１２６は、セッション管理エンジン１１２２がセッションを確立できるデバイス１００のＩＰアドレス、暗号化鍵、コネクション種別などを保持する。サーチエンジン１１２８は、各種アプリケーション３００から指定されたＩＰアドレスがエンドトゥエンドセッション管理テーブル１１２６に登録されていない場合に、ネットワーク上で指定されたＩＰアドレスを有するデバイス１００およびその経路を探索する。

転送エンジン１１１０は、インターフェイス１２１０からパケットを与えられると、当該パケットを直接データ通信する先のデバイス１００との間で交換ないし交換された暗号鍵を用いて、当該パケットを復号した上で、ルータエンジン１１２０へ出力する。また、転送エンジン１１１０は、ルータエンジン１１２０からパケットを与えられると、当該パケットを直接データ通信する先のデバイス１００との間で交換ないし交換された暗号鍵を用いて、当該パケットを暗号化した上で、送信先のデバイス１００へ送信する。

より具体的には、転送エンジン１１１０は、セッション管理エンジン１１１２と、暗号化／復号エンジン１１１４と、隣接ノードセッション管理テーブル１１１６とを含む。

セッション管理エンジン１１１２は、パケットを直接データ通信する先のデバイス１００との間のセッション確立、パケットの転送処理および再送処理などを行う。暗号化／復号エンジン１１１４は、データの暗号化および復号を行う。隣接ノードセッション管理テーブル１１１６は、セッション管理エンジン１１１２がセッションを確立できるデバイス１００のＩＰアドレス、暗号化鍵、コネクション種別などを保持する。

インターフェイス１２１０は、ネットワークインターフェイス１２０により物理的にやり取りされるデータを論理的に処理するモジュールである。インターフェイス１２１０は、セッション管理エンジン１１１２と、プロトコル毎に用意されるデータ通信経路（例えば、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）１２１２、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）１２１４、その他のプロトコル１２１６など）とを論理的に接続する。

図１２は、本実施の形態に従うデバイス１００におけるデータ送信時の動作例を示す模式図である。図１２には、デバイス１００が自デバイス宛てのパケット（自デバイス宛受信パケット）を受信した場合の処理、および、デバイス１００が他デバイス宛てのパケット（他デバイス宛受信パケット）を受信した場合の処理を示す。

デバイス１００にパケットが到着すると、当該パケットは転送エンジン１１１０に送られて、当該パケットを直接データ通信したデバイス１００との間で交換ないし交換された暗号鍵を用いて、復号される。当該パケットが自デバイス宛てである場合には、復号されたパケットはルータエンジン１１２０に送られ、送信元のデバイス１００との間で交換ないし交換された暗号鍵を用いてさらに復号されて、各種アプリケーション３００へ出力される。一方、当該パケットが他デバイス宛てである場合には、復号されたパケットは転送エンジン１１１０に戻されて、次の送信先のデバイスとの間で交換ないし交換された暗号鍵を用いて暗号化された上で送信される。

図１３は、本実施の形態に従うデバイス１００において送信パケットが発生した場合の処理手順を示すフローチャートである。図１４は、本実施の形態に従うデバイス１００において他のデバイスからパケットを受信した場合の処理手順を示すフローチャートである。図１３および図１４には、ネットワークに接続されたデバイス１００での通信処理方法の手順が示される。図１３および図１４に示す各ステップは、デバイス１００の制御部１１０（図２参照）によって実行される（典型的には、プロセッサおよびメモリが協働することにより実現される）。

図１３を参照して、各種アプリケーション３００などによって、他のデバイスを宛先とする送信パケット２０が与えられたか否かを判断する（ステップＳ１００）。他のデバイスを宛先とする送信パケット２０が与えられていなければ（ステップＳ１００においてＮＯ）、ステップＳ１００の処理が繰り返される。

一方、他のデバイスを宛先とする送信パケット２０が与えられると（ステップＳ１００においてＹＥＳ）、ステップＳ１０２以下の処理が実行される。すなわち、図１３に示すステップＳ１０２以下の処理は、他のデバイスを宛先とするパケットが与えられると実行される。

ステップＳ１０２において、デバイス１００（図１１のセッション管理エンジン１１２２）は、宛先のデバイスのＩＰアドレスに対応するセッションが登録されているか否かを判断する（ステップＳ１０２）。典型的には、図１１に示すエンドトゥエンドセッション管理テーブル１１２６には確立可能なセッション毎のＩＰアドレスが登録されており、この登録内容が参照される。

宛先のデバイスのＩＰアドレスに対応するセッションが登録されていれば（ステップＳ１０２においてＹＥＳ）、後述のステップＳ１１４の処理が実行される。

宛先のデバイスのＩＰアドレスに対応するセッションが登録されていなければ（ステップＳ１０２においてＮＯ）、デバイス１００（図１１のサーチエンジン１１２８）は、送信パケット２０をキューに一旦格納し（ステップＳ１０４）、それぞれのデータ通信経路について、宛先のデバイスおよび宛先のデバイスまでの経路の探索を開始する（ステップＳ１０６）。そして、デバイス１００は、探索が成功したか否かを判断する（ステップＳ１０８）。探索が成功すると（ステップＳ１０８においてＹＥＳ）、後述のステップＳ１１４の処理が実行される。このように、デバイス１００は、他のデバイスを宛先とするパケットが与えられると、当該宛先のデバイスのＩＰアドレスを探索する。

一方、探索が成功していなければ（ステップＳ１０８においてＮＯ）、デバイス１００は、送信パケット２０をキューに格納してから予め定められた制限時間（タイムアウト時間）が経過したか否かを判断する（ステップＳ１１０）。送信パケット２０をキューに格納してから予め定められた制限時間が経過していなければ（ステップＳ１１０においてＮＯ）、ステップＳ１０８以下の処理が繰り返される。

一方、送信パケット２０をキューに格納してから予め定められた制限時間が経過していれば（ステップＳ１１０においてＹＥＳ）、デバイス１００は、キューに格納した送信パケット２０を破棄する（ステップＳ１１２）。そして、処理は終了する。

ステップＳ１１４において、デバイス１００（図１１のセッション管理エンジン１１２２）は、宛先のデバイスとの間にエンドトゥエンドセッション１４が確立されているか否かを判断する（ステップＳ１１４）。

宛先のデバイスとの間にエンドトゥエンドセッション１４が確立されていなければ（ステップＳ１１４においてＮＯ）、デバイス１００は、宛先のデバイスとの間にエンドトゥエンドセッション１４を確立する（ステップＳ１１６）。エンドトゥエンドセッション１４を確立する際には、デバイス１００は、エンドトゥエンドセッション１４に関連付けられた暗号鍵を宛先のデバイスとの間で交換ないし共有する。このように、デバイス１００は、他のデバイスとの間のエンドトゥエンドセッション１４を確立するとともに、エンドトゥエンドセッション１４（すなわち、当該他のデバイス）に関連付けられた暗号鍵を決定する。

一方、宛先のデバイスとの間にエンドトゥエンドセッション１４が既に確立されていれば（ステップＳ１１４においてＹＥＳ）、ステップＳ１１６の処理はスキップされる。

続いて、デバイス１００（暗号化／復号エンジン１１２４）は、宛先のデバイスとの間に確立されているエンドトゥエンドセッション１４に対応付けられた暗号鍵で送信パケット２０を暗号化することで、暗号化パケット２２を生成する（ステップＳ１１８）。すなわち、デバイス１００は、宛先となっている他のデバイスに関連付けられた暗号鍵により暗号化して暗号化パケット２２を生成する。

続いて、デバイス１００（セッション管理エンジン１１１２）は、暗号化パケット２２の送出先となるデバイスを決定する（ステップＳ１２０）。典型的には、図１１に示す隣接ノードセッション管理テーブル１１１６には確立可能なセッション毎のＩＰアドレスが登録されており、この登録内容が参照される。さらに、デバイス１００（暗号化／復号エンジン１１１４）は、決定した送出先のデバイスとの間に隣接ノードセッション１２が確立されているか否かを判断する（ステップＳ１２２）。

決定した送出先のデバイスとの間に隣接ノードセッション１２が確立されていなければ（ステップＳ１２２においてＮＯ）、デバイス１００は、決定した送出先のデバイスとの間に隣接ノードセッション１２を確立する（ステップＳ１２４）。隣接ノードセッション１２を確立する際には、デバイス１００は、隣接ノードセッション１２に関連付けられた暗号鍵を対象のデバイスとの間で交換ないし共有する。このように、デバイス１００は、暗号化パケット２２の送出先となるさらに別のデバイスとの間の隣接ノードセッション１２を確立するとともに、隣接ノードセッション１２（すなわち、当該送出先となるデバイス）に関連付けられた暗号鍵を決定する。

一方、決定した送出先のデバイスとの間に隣接ノードセッション１２が既に確立されていれば（ステップＳ１２２においてＹＥＳ）、ステップＳ１２４の処理はスキップされる。

続いて、デバイス１００（暗号化／復号エンジン１１１４）は、決定した送出先のデバイスとの間に確立されている隣接ノードセッション１２に対応付けられた暗号鍵で暗号化パケット２２を暗号化することで、暗号化パケット２４を生成する（ステップＳ１２６）。すなわち、すなわち、デバイス１００は、暗号化パケット２２を決定した送出先のデバイスに関連付けられた暗号鍵により暗号化して暗号化パケット２４を生成する。

最終的に、デバイス１００（セッション管理エンジン１１１２）は、生成した暗号化パケット２４を決定した送出先のデバイスへ送出する（ステップＳ１２８）。以上により、送信パケット２０が与えられた場合の処理は終了する。

図１４を参照して、他のデバイスから暗号化パケット２４を受信したか否かを判断する（ステップＳ２００）。他のデバイスから暗号化パケット２４を受信していなければ（ステップＳ２００においてＮＯ）、ステップＳ２００の処理が繰り返される。

一方、他のデバイスから暗号化パケット２４を受信すると（ステップＳ２００においてＹＥＳ）、ステップＳ２０２以下の処理が実行される。すなわち、図１４に示すステップＳ２０２以下の処理は、他のデバイスから暗号化パケット２４を受信すると実行される。

デバイス１００（暗号化／復号エンジン１１１４）は、当該他のデバイスとの間の隣接ノードセッション１２に対応付けられた暗号鍵で暗号化パケット２４を暗号化パケット２２に復号する（ステップＳ２０２）。そして、デバイス１００（セッション管理エンジン１１１２）は、復号された暗号化パケット２２が自デバイス宛てであるか否かを判断する（ステップＳ２０４）。

復号された暗号化パケット２２が自デバイス宛てでなければ（ステップＳ２０４においてＮＯ）、デバイス１００（セッション管理エンジン１１１２）は、暗号化パケット２２のさらなる送出先となるデバイスを決定する（ステップＳ２１０）。典型的には、図１１に示す隣接ノードセッション管理テーブル１１１６が参照される。さらに、デバイス１００（暗号化／復号エンジン１１１４）は、決定した送出先のデバイスとの間に隣接ノードセッション１２が確立されているか否かを判断する（ステップＳ２１２）。決定した送出先のデバイスとの間に隣接ノードセッション１２が確立されていなければ（ステップＳ２１２においてＮＯ）、デバイス１００は、決定した送出先のデバイスとの間に隣接ノードセッション１２を確立する（ステップＳ２１４）。なお、決定した送出先のデバイスとの間に隣接ノードセッション１２が既に確立されていれば（ステップＳ２１２においてＹＥＳ）、ステップＳ２１４の処理はスキップされる。

続いて、デバイス１００（暗号化／復号エンジン１１１４）は、決定した送出先のデバイスとの間に確立されている隣接ノードセッション１２に対応付けられた暗号鍵で暗号化パケット２２を暗号化することで、暗号化パケット２４を生成する（ステップＳ２１６）。最終的に、デバイス１００（セッション管理エンジン１１１２）は、生成した暗号化パケット２４を決定した送出先のデバイスへ送出する（ステップＳ２１８）。

このように、復号された暗号化パケット２２が自デバイス宛てでなければ（ステップＳ２０４においてＮＯ）、デバイス１００は、暗号化パケット２２の送出先となるさらに別のデバイスを決定し、当該決定したデバイスに関連付けられた暗号鍵により暗号化パケット２４を生成して送信する。以上により、他のデバイスから暗号化パケット２４を受信した場合の処理は終了する。

一方、復号された暗号化パケット２２が自デバイス宛てであれば（ステップＳ２０４においてＹＥＳ）、デバイス１００（暗号化／復号エンジン１１２４）は、送信元のデバイスとの間に確立されているエンドトゥエンドセッション１４に対応付けられた暗号鍵で暗号化パケット２２を送信パケット２０に復号する（ステップＳ２０６）。そして、デバイス１００は、復号した送信パケット２０を受信パケットとして、各種アプリケーション３００へ出力する（ステップＳ２０８）。以上により、他のデバイスから暗号化パケット２４を受信した場合の処理は終了する。

上述したように、本実施の形態に従うネットワークシステム１においては、送信元のデバイスから宛先のデバイスへパケットを送信するにあたって、送信元のデバイスと宛先のデバイスとの間のエンドトゥエンドセッション１４に関連付けられた暗号鍵を用いて暗号化パケット２２が生成される。暗号化パケット２２は、１または複数のデバイスにより順次転送されることもあるが、このような過程においても、暗号化された状態で順次転送されるため、宛先のデバイスに到達するまでの間に亘って、パケットの秘匿性を維持できる。

さらに、本実施の形態に従うネットワークシステム１においては、暗号化パケット２２を順次転送するデバイス間においても、当該デバイス間の隣接ノードセッション１２に関連付けられた暗号鍵を用いて暗号化パケット２２がさらに暗号化される。そのため、暗号化パケット２２が順次転送されるデータ通信過程においても、より秘匿性を高めることができる。

＜Ｅ．利点＞
本実施の形態に従うネットワークシステム１によれば、多数のデバイスが存在するネットワークにおいて、各デバイス１００が自立してデータ通信を実現できる解決策を提供できる。

今回開示された実施の形態はすべての点で例示であって制限的なものでないと考えられるべきである。本発明の範囲は上記した説明ではなくて請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ ネットワークシステム、２ ネットワーク、４ アクセスポイント、６ 移動体基地局、１２ 隣接ノードセッション、１４ エンドトゥエンドセッション、２０ 送信パケット、２０Ｄ，２２Ｄ，２４Ｄ，２６Ｄ データ本体部、２０Ｈ，２２Ｈ，２４Ｈ，２６Ｈ ヘッダ部、２２，２４，２６ 暗号化パケット、１００ デバイス、１０２ プロセッサ、１０４ 主メモリ、１０６ ストレージ、１０８ ＲＯＭ、１１０ 制御部、１２０ ネットワークインターフェイス、１３０ 表示部、１４０ 入力部、１５０ メディアインターフェイス、１５２ メディア、１６０ ＯＳ、１７０ 通信処理プログラム、１７２ 秘密鍵、１７４ 公開鍵、１７６ 電子証明書、１７８ ハッシュ値、１８０ ハッシュ関数、１９０ ＩＰアドレス、１９４ コネクションテーブル、２００ 認証局、３００ 各種アプリケーション、１１１０ 転送エンジン、１１１２，１１２２ セッション管理エンジン、１１１４，１１２４ 暗号化／復号エンジン、１１１６ 隣接ノードセッション管理テーブル、１１２０ ルータエンジン、１１２６ エンドトゥエンドセッション管理テーブル、１１２８ サーチエンジン、１２１０ インターフェイス、１２１６ その他のプロトコル。

Claims (10)

1. 複数のデバイスが接続されたネットワークにおけるデータ送信方法であって、
   第１のデバイスにおいて、第２のデバイスを宛先とするパケットを前記第２のデバイスに関連付けられた第１の暗号鍵により暗号化して第１の暗号化パケットを生成するステップと、
   前記第１の暗号化パケットの送出先となるデバイスを決定し、当該決定したデバイスに関連付けられた第２の暗号鍵により前記第１の暗号化パケットを暗号化して第２の暗号化パケットを生成し、当該決定したデバイスへ送信するステップと、
   前記第２の暗号化パケットを受信したデバイスにおいて、前記第２の暗号化パケットを前記第１の暗号化パケットに復号し、当該復号された第１の暗号化パケットが自デバイス宛てであるか否かを判断するステップと、
   前記自デバイス宛てであるか否かの判断により、前記復号された第１の暗号化パケットが自デバイス宛てでなければ、別のデバイスを決定し前記送信するステップを実行し、前記復号された第１の暗号化パケットが自デバイス宛てであれば、前記第１の暗号化パケットをさらに復号するステップとを備える、データ送信方法。
2. 前記複数のデバイスの各々において、各デバイスが有している公開鍵および当該公開鍵に関連付けられた電子証明書を他のデバイスに送信するステップと、
   前記公開鍵および前記電子証明書を受信したデバイスにおいて、ハッシュ関数に従って前記公開鍵から算出されるハッシュ値に基づいて、前記公開鍵および前記電子証明書の送信元のデバイスのＩＰアドレスを決定するステップとをさらに備える、請求項１に記載のデータ送信方法。
3. ネットワークに接続されたデバイスでの通信処理方法であって、
   他のデバイスを宛先とするパケットが与えられると実行される、
   当該パケットを前記他のデバイスに関連付けられた第１の暗号鍵により暗号化して第１の暗号化パケットを生成するステップと、
   前記第１の暗号化パケットの送出先となるデバイスを決定するステップと、
   前記第１の暗号化パケットを前記決定したデバイスに関連付けられた第２の暗号鍵により暗号化して第２の暗号化パケットを生成するステップと、
   前記第２の暗号化パケットを前記決定したデバイスへ送信するステップとを備え、
   他のデバイスから前記第２の暗号化パケットを受信すると実行される、
   前記第２の暗号化パケットを前記第１の暗号化パケットに復号するステップと、
   前記復号された第１の暗号化パケットが自デバイス宛てであるか否かを判断するステップと、
   前記復号された第１の暗号化パケットが、前記自デバイス宛てであるか否かの判断により、自デバイス宛てでなければ、当該第１の暗号化パケットの送出先となるさらに別のデバイスを決定し、当該決定したデバイスに関連付けられた第２の暗号鍵により第２の暗号化パケットを生成して送信するステップと、
   前記復号された第１の暗号化パケットが自デバイス宛てであれば、前記第１の暗号化パケットをさらに復号するステップとを備える、通信処理方法。
4. 各デバイスが有しているＩＰアドレスに基づいて、送出先となるデバイスが決定される、請求項３に記載の通信処理方法。
5. 秘密鍵および公開鍵を取得するステップと、
   ハッシュ関数に従って前記公開鍵から算出されるハッシュ値に基づいて、自デバイスのＩＰアドレスを決定するステップと、
   認証局から前記公開鍵に関連付けられた電子証明書を取得するステップと、
   前記公開鍵および前記電子証明書を他のデバイスに送信するステップとをさらに備える、請求項４に記載の通信処理方法。
6. 前記他のデバイスから前記公開鍵および前記公開鍵に関連付けられた電子証明書を受信すると、前記電子証明書の正当性を判断するステップと、
   前記電子証明書が正当であると判断されると、ハッシュ関数に従って前記公開鍵から算出されるハッシュ値に基づいて、前記他のデバイスのＩＰアドレスを決定するステップとをさらに備える、請求項５に記載の通信処理方法。
7. 前記他のデバイスを宛先とするパケットが与えられると実行される、当該宛先のデバイスのＩＰアドレスを探索するステップをさらに備える、請求項４〜６のいずれか１項に記載の通信処理方法。
8. 前記他のデバイスを宛先とするパケットが与えられると実行される、前記他のデバイスとの間のセッションを確立するとともに、前記第１の暗号鍵を決定するステップをさらに備え、
   前記他のデバイスから前記第２の暗号化パケットを受信すると実行される、前記第１の暗号化パケットの送出先となるさらに別のデバイスとの間のセッションを確立するとともに、前記第２の暗号鍵を決定するステップをさらに備える、請求項３〜７のいずれか１項に記載の通信処理方法。
9. ネットワークに接続するためのネットワークインターフェイスと、
   前記ネットワークインターフェイスに接続された制御部とを備え、
   前記制御部は、
   パケットを前記他のデバイスに関連付けられた第１の暗号鍵を用いて第１の暗号化パケットに暗号化する処理、および、前記第１の暗号化パケットを復号する処理を実行可能な第１の暗号化／復号部と、
   前記第１の暗号化パケットを前記第１の暗号化パケットの送出先となるデバイスに関連付けられた第２の暗号鍵を用いて第２の暗号化パケットに暗号化する処理、および、前記第２の暗号化パケットを復号する処理を実行可能な第２の暗号化／復号部と、
   他のデバイスを宛先とするパケットが前記第１の暗号化／復号部および前記第２の暗号化／復号部においてそれぞれ暗号化されることで生成される前記第２の暗号化パケットを送出先のデバイスに送信する送信管理部とを備え、
   前記送信管理部は、
   他のデバイスから受信した第２の暗号化パケットを前記第２の暗号化／復号部において復号することで生成される第１の暗号化パケットが自デバイス宛てであるか否かを判断し、
   前記生成された第１の暗号化パケットが自デバイス宛てでなければ、当該第１の暗号化パケットが前記第２の暗号化／復号部において暗号化されることで生成される第２の暗号化パケットをさらに別のデバイスに送信し、
   前記生成された第１の暗号化パケットが自デバイス宛てであれば、当該第１の暗号化パケットを前記第１の暗号化／復号部においてさらに復号し出力する、装置。
10. ネットワークに接続するためのネットワークインターフェイスを有するコンピュータのための通信処理プログラムであって、前記通信処理プログラムは前記コンピュータによって実行されると、前記コンピュータに請求項３〜８のいずれか１項に記載の通信処理方法を実行させる、通信処理プログラム。

Images