JP5250634B2 - 移動通信ネットワークにおいて使用するための方法及び装置 - Google Patents

Description

本発明は、通信ネットワークの分野に関し、詳細には、通信ネットワーク内の２つのノード間に暗号化関係を確立することに関するものである。

２００４年６月のＲＦＣ３７７５、Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、およびＪ．Ａｒｋｋｏ著「ＩＰｖ６におけるモビリティサポート（Mobility Support in IPv6）」の中で記載されているモバイルＩＰｖ６（ＭＩＰｖ６）は、移動通信デバイスのユーザが、どのネットワーク内にいるかに関らず、恒久的なＩＰアドレスを維持しながら１つのネットワークから別のネットワークへ移動することを可能にする。これによって、ユーザは、移動中も接続を維持することができる。例えば、あるユーザがボイスオーバＩＰ（Ｖｏｉｃｅ Ｏｖｅｒ ＩＰ）（ＶｏＩＰ）セッションに参加していて、セッションの間にそのユーザが１つのネットワークから別のネットワークへ移動した場合には、ＭＩＰｖ６サポートがなければユーザのＩＰアドレスは変わる可能性がある。これでは、ＶｏＩＰセッションでいくつかの問題が生じるであろう。

移動ノード（Ｍｏｂｉｌｅ Ｎｏｄｅ：ＭＮ）には、恒久的なホームアドレスと気付アドレス（ＣｏＡ）という２つのＩＰアドレスが割り当てられる。ＣｏＡは、ユーザが現時点で訪問しているアクセスネットワークであるＩＰサブネットに関連付けられている。ＭＮと通信するために、パケットは、ＭＮのホームアドレスへ送信される。これらのパケットは、ＭＮのホームネットワーク内のホームエージェント（Ｈｏｍｅ Ａｇｅｎｔ：ＨＡ）によって捕捉される。ＨＡは現在のＣｏＡの知識を持っている。次いで、ホームエージェントは、元のＩＰヘッダを維持しながら、新たなＩＰヘッダを使ってパケットをＭＮのＣｏＡへトンネルする。ＭＮによってパケットが受信されると、新たなＩＰヘッダを削除して元のＩＰヘッダを取得する。ＭＮは、ＨＡへとアドレス指定されたパケットの中にカプセル化されたかたちでパケットをＨＡへトンネルすることによって、パケットを別のノードへ送信する。各パケットについて、ＨＡは、カプセル化パケットを削除して元のパケットを復元し、そしてそれを意図する宛先ノードへ転送する。

プロキシモバイルＩＰｖ６（Ｐｒｏｘｙ Ｍｏｂｉｌｅ ＩＰｖ６）（ＰＭＩＰｖ６）、ＩＥＴＦ ｄｒａｆｔ−ｓｇｕｎｄａｖｅ−ｍｉｐ６−ｐｒｏｘｙｍｉｐ６−０７は、モバイルアクセスゲートウェイ（Ｍｏｂｉｌｅ Ａｃｃｅｓｓ Ｇａｔｅｗａｙ）（ＭＡＧ）機能について記載している。この機能は、ＭＮが自身のホームネットワーク上にいるかのようにＭＮに振舞わせることを目的としてホームリンクプロパティをエミュレートし、普通ならＭＩＰｖ６をサポートしないはずのネットワーク上での移動性をサポートすることを可能にする。ＰＭＩＰｖ６とＭＩＰｖ６との主な違いは、ＭＩＰｖ６を使用すると、ＭＮは自分自身の移動性シグナリングの制御権を有しているのに対し、ＰＩＭＰｖ６を使用すると、ＭＮは、自身の移動性シグナリングの制御権を有さないという点である。ＰＭＩＰｖ６アーキテクチャの基本的な構成要素が図１に示される。

ＭＡＧ１０１は、通常、アクセスルータに実装される。ＭＡＧ１０１は、移動性関連のシグナリングをＭＮ１０２に代わって送受信する。ＭＮ１０２がＭＡＧ１０１を有するアクセスルータに接続する場合、アクセス認証手順の一部として自身のアイデンティティをネットワークアクセス識別子（Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｆｉｅｒ）（ＮＡＩ）の形式で提示する。ＭＮ１０２が一旦認証されると、ＭＡＧは、ポリシー記憶装置からユーザプロファイルを取得する。ＭＡＧ１０１は、ユーザプロファイルとＮＡＩの知識を有しているで、今度はＭＮのホームネットワークをエミュレートすることができる。ＭＮ１０２は、その後、自身のホームアドレスをＭＡＧから取得する。また、ＭＡＧ１０１は、プロキシバインディング更新（Ｐｒｏｘｙ Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ）メッセージを使用してＭＮ１０２の現在位置をＭＮ１０２のローカルモビリティアンカー（Ｌｏｃａｌ Ｍｏｂｉｌｉｔｙ Ａｎｃｈｏｒ）（ＬＭＡ）１０３に通知する。プロキシバインディング更新（Ｐｒｏｘｙ Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ）メッセージは、ＭＮ１０２のＮＡＩを使用する。プロキシバインディング更新（Ｐｒｏｘｙ Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ）メッセージを受信すると、ＬＭＡ１０３は、ＭＡＧ１０１へのトンネルをセットアップし、プロキシバインディング確認応答（Ｐｒｏｘｙ Ｂｉｎｄｉｎｇ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージをＭＡＧへ送信する。ロキシバインディング確認応答（Ｐｒｏｘｙ Ｂｉｎｄｉｎｇ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージを受信すると、ＭＡＧ１０１は、事実上双方向トンネルを形成するかたちで、ＬＭＡへのトンネルをセットアップする。ＭＮ１０２で発着信するすべてのトラフィックは、双方向トンネルを介してＬＭＡ１０３を通ってルーティングされる。１つのＭＡＧは、同一のＬＭＡに関連付けられている多数のＭＮにサービスを提供することができる。ＭＡＧおよびＬＭＡは、各ＭＮについて専用の双方向トンネルを有する必要がない。その代わり、同一のＬＭＡに関連付けられ、かつ、同一のＭＡＧによって現時点でサービスが提供されているすべてのＭＮのトラフィックについて、同一の双方向トンネルを使用することができる。

ＬＭＡ１０３は、ＭＮ１０２へ送信されるパケットをいずれも捕捉して、その捕捉されたパケットをトンネルを通してＭＡＧ１０１へ転送する。パケットを受信すると、ＭＡＧ１０１は、トンネルヘッダを削除して、パケットをＭＮ１０２へ送信する。ＭＡＧ１０１は、アクセスリンク上のデフォルトルータとして動作する。ＭＮから送信されるパケットはいずれも、ＭＡＧ１０１を介してトンネルを通ってＬＭＡ１０３へ送信され、次いで、ＬＭＡ１０３は、パケットをその最終的な宛先へと送信する。

２００７年５月のＩＥＴＦ、ＲＦＣ４８６６、Ｊ．Ａｒｋｋｏ、Ｃ．Ｖｏｇｔ、およびＷ．Ｈａｄｄａｄ著「モバイルＩＰｖ６用の拡張ルート最適化（Ｅｎｈａｎｃｅｄ Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ ｆｏｒ Ｍｏｂｉｌｅ ＩＰｖ６）」の中で記載されている拡張ルート最適化（Ｅｎｈａｎｃｅｄ Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ）（ＥＲＯ）は、ＭＩＰｖ６ルート最適化に対する修正を規定している。ＥＲＯは、暗号化によって、かつ、検証可能な形でＭＮの公開鍵／秘密鍵ペアの公開成分にバインディングされたインタフェース識別子を使用することによって、ＭＮのホームアドレスのなりすましに対してセキュアにする。ＥＲＯによって、移動ノードと対向ノードとが、気付アドレステストを実行することによって双方向通信を並行して再開できるようになる。暗号化によって生成されたアドレス（Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ Ｇｅｎｅｒａｔｅｄ Ａｄｄｒｅｓｓ：ＣＧＡ）をＭＮのために使用することは、セキュリティの向上とシグナリングオーバヘッドの削減とにつながる。ＣＧＡは、２００５年３月のＩＥＴＦ、ＲＦＣ３９７２、Ｔ．Ａｕｒａ著「暗号化生成アドレス（Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ Ｇｅｎｅｒａｔｅｄ Ａｄｄｒｅｓｓ）（ＣＧＡ）」の中で記載されている。

しかしながら、ＰＭＩＰｖ６に従えば、ＭＮは「移動性に気付かない」状態であるべきであることから、ＥＲＯをＰＭＩＰｖ６対応ネットワークに適用することはできない。ＭＮに代わってＥＲＯをＰＭＩＰｖ６対応ネットワークに適用することは、ＭＮが自身のＣＧＡ秘密鍵を訪問先ネットワーク内に位置する各ノード（例えば、ＭＡＧ）と共有することが必要となるであろう。これはセキュリティの観点から、明らかに望ましくない。また、ＭＮが、自身の秘密鍵を共有する必要があるという事実は、ＭＮが移動性に完全に気付かないわけにはいかないということを意味する。

ＣＧＡ技術は、現在、ＭＡＧ、ＨＡ、ＬＭＡ、ＣＮを含む、ＰＭＩＰｖ６対応ネットワークで使用されていて、多数の冗長な移動性シグナリングメッセージを削減しており、従って、ＣＧＡ技術を使用するＰＭＩＰｖ６用のルート最適化メカニズムがあれば、有利であろう。

従って、ＣＧＡ技術を使用し、かつ訪問先ネットワーク内でＭＮのために使用することが可能であるけれどもＭＮが自身の秘密鍵を訪問先ネットワーク内の他の各ノードと共有することを要求しないようなルート最適化メカニズムを考案することは、望ましいことであろう。さらに、セキュア近隣ディスカバリ（Ｓｅｃｕｒｅ Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ）（ＳｅＮＤ）状況において、ＰＭＩＰｖ６ネットワーク内でＭＮがＳｅＮＤメッセージを送信することを、例えば、Ａｃｃｅｓｓ Ｒｏｕｔｅｒのようなプロキシノードに委任できるようにすることは、有益であろう。ＳｅＮＤメッセージに関する研究については、２００７年２月１２日−１４日の第９回高度通信技術における国際会議でのＰａｒｋ他による「セキュア近隣ディスカバリとマルチキー暗号化生成アドレスの外観（Ａ Ｓｕｒｖｅｙ ｏｆ ｔｈｅ Ｓｅｃｕｒｅ Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ（ＳｅＮＤ）ａｎｄ Ｍｕｌｔｉ−Ｋｅｙ Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ Ｇｅｎｅｒａｔｅｄ Ａｄｄｒｅｓｓｅｓ）（ＭＳＧＡｓ）」、Ｖｏｌ．３、２１２４−２１２７ページで調査されている。

ＭＮが一定のタスクをセキュアな方法でプロキシノードに委任することができることは、例えば、演算負荷／処理負荷からＭＮを解放することは、望ましいであろう。ここでセキュアな方法とは、プロキシノードがＭＮに代わって動作を実行することを認可されていて、かつ、プロキシノードがそれを行うことに同意していることを第三者が検証することが可能であるべきだということを意味する。

これを行う１つの方法は、プロキシノードとＭＮとが相互に、例えば、相手の公開鍵に署名することによって、「相互認証する」ことであろう。しかしながら、これには２つの大きな欠点がある。第１に、そのような手法の一般性に起因して、ＭＮがそれによってどのタイプのタスクを委任することに合意するのかが若干不明確であることである。逆に言えば、プロキシノードがＭＮに代わって何をすることに合意したのかが若干不明確であることである。第２に、電子署名を実行することが必要であるため、ＭＮに演算負荷を課すことになる。

本発明者らは、第１のノードについての暗号化生成アドレス（Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ Ｇｅｎｅｒａｔｅｄ Ａｄｄｒｅｓｓ）を生成するための新たな手法を考案している、これによって、第１のノードは、第２のノードと暗号化関係を確立することができる。これによって、第２のノードは、自身が第１のノードと関係を有することを別の各ノードに証明することができる。第１のノードがプロキシモバイルＩＰ（Ｐｒｏｘｙ Ｍｏｂｉｌｅ ＩＰ）ネットワーク内の移動ノードであり、第２のノードがその移動ノードにサービスを提供しているホームエージェント（Ｈｏｍｅ Ａｇｅｎｔ）である場合、秘密の暗号化材料を訪問先ネットワーク内の他のノードと共有することをＭＮに要求することなく、ＭＮとＨＡとの間の暗号化関係が、ＨＡがＭＮのためのルート最適化を提供する目的で使用される。第１のノードが移動ノードであり、第２のノードがアクセスルータ（Ａｃｃｅｓｓ Ｒｏｕｔｅｒ）である場合、暗号化関係によって、ＭＮは、セキュア近隣ディスカバリ（ＳｅＮＤ）プロトコルの責任をアクセスルータに委任することができ、それは、ＡＲが、自身がＭＮと暗号化関係を有することを他の各ノードに示すことができるからである。

本発明の第１の態様に従えば、通信ネットワークにおいて第１のノードと第２のノードとの間で暗号化関係を確立する方法を提供する。この方法は、第１のノードにおいて、第２のノードから、その第２のノードに属する暗号化属性の少なくとも一部を受信することを含んでいる。次いで、第１のノードは、第１のノードの識別子を生成するために、受信した暗号化属性の少なくとも一部と、第１のノードに属する暗号化属性の少なくとも一部とを使用する。第１のノードの識別子を生成するために第２のノードの暗号化属性を使用することは、必要に応じて第三者に実証することのできる、２つのノード間の信頼関係を確立する。識別子が第１のノードでの一定の方法で生成されるという事実は、第１のノードが第２のノードとの信頼関係を喜んで築いていることを実証する目的で使用することが可能であり、そして、第２のノードが、第１のノードの同意なく第１のノードとの信頼関係を実証しようとすることを阻止する。

オプションで、第１のノードの識別子は、暗号化によって生成されたＩＰアドレス（Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ Ｇｅｎｅｒａｔｅｄ ＩＰ ａｄｄｒｅｓｓ）を含み、そして、この暗号化属性は、第２のノードに属する公開鍵であってもよい。また、この方法は、オプションで、第１のノードにおいて、第２のノードに属する暗号化属性をランダム値と連結することと、連結された結果をハッシュすることと、そして、第１のノードにおいて、結果として得られたハッシュ値の少なくとも一部を識別子を生成するための修飾子として使用することとを含んでいる。この場合、この方法は、オプションで、第２のノードにおいて、第１のノードの識別子とランダム値とを第３のノードへ送信することと、そして、第３のノードにおいて、第２のノードが第１のノードと信頼関係を有することを検証するために、第１のノードに属する識別子とランダム値とを使用することとを含んでいる。「ランダム値」という用語は、本明細書では、ランダムにまたは擬似ランダムに生成されている値を示すために使用される。オプションとして、この方法は、さらに、第２のノードにおいて、第１のノードに属する識別子とランダム値とを含むメッセージに署名することを含んでもよい。

通信ネットワークは、オプションで、プロキシモバイルＩＰネットワークを含み、ここで、第１のノードは移動ノードであり、第２のノードはその移動ノードに関連付けられているホームエージェントである。これによって、ホームエージェントは、移動ノードに代わってルート最適化を提供することができる。

オプションで、第１のノードは移動ノードであり、第２のノードは、それを介して移動ノードが通信ネットワークに接続するプロキシノードである。これは、例えば、それぞれ移動ノードと移動アクセスゲートウェイ（Ｍｏｂｉｌｅ Ａｃｃｅｓｓ Ｇａｔｅｗａｙ）とであってもよい。オプションで、プロキシノードは、移動ノードに代わってセキュア近隣ディスカバリ（Ｓｅｃｕｒｅ Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ）メッセージを送信する。

この方法は、オプションで、さらに、第２のノードにおいて、第１のノードに関するフラッディング攻撃を検出することを含んでいる。その検出の結果として、第２のノードは、フラッシュリクエストメッセージを第３のノードへ送信する。このフラッシュリクエストメッセージは、第１のノードに関するすべてのバインディングキャッシュエントリ（Ｂｉｎｄｉｎｇ Ｃａｃｈｅ Ｅｎｔｒｉｅｓ）をフラッシュすることを第３のノードに命令するものである。フラッシュリクエストメッセージは、第１のノードに属する識別子と、識別子を生成するために使用されるその他の暗号化材料とを含んでいる。このようにして、第１のノードがフラッディング攻撃を開始し、次いでネットワークを離れている場合には、プロキシノードは、自身が第１のノードに代わって動作する権限を有することを第３のノードに示すことができ、次いで、第３のノードは、第１のノードに関するすべてのバインディングキャッシュエントリ（Ｂｉｎｄｉｎｇ Ｃａｃｈｅ Ｅｎｔｒｉｅｓ）を削除することによって、フラッディング攻撃を停止することができる。

本発明の第２の態様に従えば、通信ネットワークで使用するためのノードが提供される。このノードは、第２のノードに属する暗号化属性の少なくとも一部を第２のノードから受信するための受信器と、受信した第２のノードに属する暗号化属性の少なくとも一部と、そのノードに属する暗号化属性の少なくとも一部とを使用して、そのノードのための識別子を生成するためのプロセッサとを備えており、それによって、そのノードと第２のノードとの間の暗号化関係を確立する。

オプションで、この識別子は、暗号化によって生成されたＩＰアドレスであり、そしてこの暗号化属性は、第２のノードに属する公開鍵であってもよい。

ノードは、オプションで、第２のノードに属する暗号化属性をランダム値と連結するための手段と、連結された結果をハッシュするための手段と、そして、結果として得られたハッシュ値の少なくとも一部をそのノード用の識別子を生成するための修飾子として使用するための手段とを備える。

本発明の第３の態様に従えば、通信ネットワークで使用するプロキシノードが提供される。このプロキシノードは、プロキシノードに関連付けられている第１のノードの識別子を記憶するためのメモリを備え、その識別子は、プロキシノードに属する暗号化属性の少なくとも一部と、第１のノードに属する暗号化属性の少なくとも一部とを使用して、生成されているものである。プロキシノードは、さらに、識別子と、識別子を生成するために使用される暗号化材料とを次のノードへ送信するための送信器を備える。次いで、この識別子と暗号化材料とは、プロキシノードが第１のノードに代わってメッセージを送信する権限を有することを検証するために、次のノードによって使用されることができる。

オプションで、この識別子は、暗号化によって生成されたＩＰアドレスであり、そして、暗号化属性は、プロキシノードに属する公開鍵である。

オプションとして、プロキシノードは、さらに、第１のノードに関するフラッディング攻撃を検出するための手段と、次のノードにフラッシュリクエストメッセージを送信するための手段とを備える。このフラッシュリクエストメッセージは、第１のノードに関するすべてのバインディングキャッシュエントリ（Ｂｉｎｄｉｎｇ Ｃａｃｈｅ Ｅｎｔｒｉｅｓ）をフラッシュすることを次のノードに命令するものであり、このフラッシュリクエストメッセージは、第１のノードに属する識別子と、識別子を生成するために使用されるその他の暗号化材料とを含んでいる。このようにして、第１のノードがフラッディング攻撃を開始し、次いでネットワークを離れる場合、プロキシノードは、自身が第１のノードに代わって動作する権限を有することを第３のノードに示すことができ、次いで、第３のノードは、第１のノードに関するすべてのバインディングキャッシュエントリ（Ｂｉｎｄｉｎｇ Ｃａｃｈｅ Ｅｎｔｒｉｅｓ）を削除することによって、フラッディング攻撃を停止させることができる。

当業者には明らかであろうが、第１のノードの識別子には、そのＩＰアドレス、ノード名、またはノードに関連付けられている他のタイプのアドレスを含んでいてもよい。例えば、Ｒ．Ｍｏｓｋｏｗｉｔｚ他、ｄｒａｆｔ−ｉｅｔｆ−ｈｉｐ−ｂａｓｅ−１０、ＩＥＴＦによるホストアイデンティティタグ（Ｈｏｓｔ Ｉｄｅｎｔｉｔｙ Ｔａｇ（ＨＩＴ））が識別子として使用されてもよいだろう。

プロキシモバイルＩＰｖ６アーキテクチャをブロック図で概略的に示す図である。 暗号化によって生成されたＩＰアドレスパラメータを概略的に示す図である。 本発明の第１の実施形態の基本ステップを示すフロー図である。 本発明の一実施形態に従うホームエージェントと対向ノードとの間のバインディングを確立するためのシグナリングを概略的に示す図である。 本発明の実施形態に従うネットワークノードを概略的に示すブロック図である。 本発明の一実施形態に従うプロキシノードを概略的に示すブロック図である。

以下の記載は、例えば、特定の実施形態、手順、技術等のような具体的詳細について、限定する目的ではなく説明を目的として説明する。場合によっては、周知の方法、インタフェース、回路およびデバイスの詳細記載は、不要な詳細で記載をあいまいにしないようにするために省略する。また、一部の図面では、個別のブロックが示される。これらのブロックの機能は、個別のハードウェア回路を使用して、適切にプログラムされているデジタルマイクロプロセッサまたは汎用コンピュータと協働するソフトウェアプログラムおよびデータを使用して、または、特定用途向集積回路を使用して、および／または、１つ以上のデジタル信号プロセッサを使用して実装されてもよいことが理解されるであろう。

高いレベルでは、本発明は、以下の特徴を有する方法について記載する。

１．第１のステップで、ＭＮは、ＭＮの属性（例えば、自分のＩＰアドレスのような識別子）に関連付けられている一定のタスクを快くプロキシに委任することを示している。この目的を達成するために、ＭＮは、プロキシの一部の属性（例えば、プロキシの公開鍵）に依存して、対応する属性を生成する。これは、第三者が委任を（効率的に）検証できるように、かつ、ＭＮが一定の責任を特定のプロキシに委任していることに疑問の余地がないように、暗号化によって「バインディングする」方法で行われる。例えば、ＭＮは、対応するＭＮの属性を変更することなく、別のプロキシに委任していることは主張することはできない。例えば、ＭＮの属性は、暗号化ハッシュ関数をプロキシの属性（の少なくとも一部）に適用する結果として生成される。

２．第２のオプションのステップで、プロキシはＭＮの委任の検証を行い、そして、プロキシが委任されたタスクを受け入れる場合、プロキシは、プロキシの属性とＭＮの属性との間のバインディングの公的に検証可能な証明（プルーフ）を発行する。このプルーフは、例えば、ＭＮの属性の電子署名によって実行されてもよいだろう。

ステップ２が実装される場合、できれば前記プルーフの中に第三者によって供給される「ナンス（nonce）」を含めることによって、第三者が委任の有効性を検証することを要望する度に実行されることが望ましい。

また、プロキシに委任されるタスクの「範囲」も、ＭＮの属性の生成の中に含まれてもよいだろう。その後、どのタスクをＭＮ／プロキシが委任することに合意しているのかを正確に検証できるように、この範囲が、機械が読み取れる形式でまたは人間が読み取れる形式で含まれることが好ましい。その他の場合では、どのタスクが委任されているかの「暗黙の」了解が存在してもよい。例えば、属性がＭＮのＩＰアドレスである場合、委任のデフォルトの範囲は、ＭＮに代わってシグナリングをプロキシすることであってもよいだろう。

本発明の第１の実施形態では、移動ノード（ＭＮ）についての暗号化によって生成されたアドレス（ＣＧＡ）を生成するための新たな手法が提供される、すなわち、ＭＮの属性はＣＧＡである。ＭＮは、ホームエージェント（ＨＡ）を有しており、ＭＮは、ＭＮについてのＩＰｖ６ホームアドレスの６４ビットのインタフェース識別子（ＩＩＤ）を生成する場合、ＨＡの公開鍵（ＨＫｐ）を含んでいる。ＭＮのＩＰｖ６ホームアドレスの中にＨＫｐを含める方法の一例は以下の通りである。

ＲＦＣ３９７２に記載されるＣＧＡ手法では、ＭＮは、修飾子（ＭＤ）と呼ばれるランダムの１２８ビットパラメータを導出する。ネットワークプレフィックスやＭＮのＣＧＡ公開鍵（Ｐｕｂｌｉｃ Ｋｅｙ）（Ｋｐ）のような他のパラメータのうちで、６４ビットＩＤを生成するためにＭＤが使用される。図２に、ＣＧＡパラメータが示されている。本発明の第１の実施形態に従えば、ＨＫｐをランダムの１２８ビット値（例えば、先行技術のＣＧＡにおけるＭＤの値）と連結し、次いでその結果をハッシュすることによってＭＤを生成する場合に、ＨＫｐが使用される。結果として得られるハッシュ値の先頭の１２８ビットが、新たなＭＤとして使用される。これは、以下のように表すことができる。

新たなＭＤ＝先頭の［１２８，Ｈａｓｈ（ＨＫｐ｜ＲＡＮ（１２８））］
ここで、「ＲＡＮ（１２８）」は、ランダムな１２８ビットのパラメータである。

同一の「新たなＭＤ」を生成する多くの値（ＨＫｐ、ＲＡＮ（１２８））が存在しうるだろうから、暗号化（耐コリジョン（衝突）性の）ハッシュ関数が使用される場合、（ＭＮまたは、プロキシを含むいずれかの他の当事者が）同一のＭＤを与える別の（ＨＫｐ、ＲＡＮ（１２８））ペアを見つけることは、演算的に実行不可能であると想定することができる。ＲＡＮパラメータの長さは、１２８ビットより長いことも短いこともありうるだろう。ＲＡＮパラメータの主たる目的は「新しさ」を提供することであるから、たとえ同一のＨＫｐが使用される場合でも、同一の新たなＭＤを常に（再）生成する可能性は低い。また、ＭＮは、ＲＡＮをリモートノードに開示して、自身はプロキシノードが自身に代わって動作することに合意していることを、さらに証明することができる。

図２で「修飾子」２０１は、１２８ビットの符号なし整数を含むフィールドであり、それはいかなる値であってもよいことに注意されたい。この修飾子は、ハッシュの拡張部分を実装するため、かつ、ランダムさをアドレスに加えることによってプライバシを向上させるために、ＣＧＡ生成の間に使用される。しかしながら、ＭＮの公開鍵もまた必要であり、従って、ＭＮを「追跡する」ために使用されうることから、完全なプライバシは不可能であることに注意されたい。

このメカニズムは、ＭＮのＩＰｖ６アドレスをそのＨＡの公開鍵に「バインディング」させ、それによって、ＭＮとそのＨＡとの間の「暗号化」関係を構築する。ＩＰｖ６アドレスとＨＫｐとのこのバインディングが一旦行われると、他のノードは、ＲＡＮ（１２８）パラメータを使用することができる場合であって、かつ、ＩＰｖ６アドレスを生成するために必要とされるすべてのパラメータを自身が提供できるように装うことができる場合であっても、この特定のアドレスとの同様の関係を主張することができない。悪意のあるノードは、この特定のアドレスに関連付けられているＭＤを生成する際に使用されるＭＮの公開鍵の「所有権」を示す必要があるであろう。所有権を示すためには、悪意のあるノードは、公開鍵に対応する秘密鍵の知識を必要とするであろうし、これは明らかに実行不可能である。ここで、これはＭＮの公開鍵のことを言うことに注意されたい。ＨＡが関係を「証明する」ことを第三者から求められる場合、ＨＡは、（その秘密鍵／公開鍵を用いて）ＲＡＮ（１２８）パラメータに署名することによって、これを行うであろう。この場合、関係を構築することは、ＨＡの秘密鍵の知識を意味するであろう。

さらに、暗号化関数の適切な選択によって、悪意のあるノードが既存のＩＰｖ６アドレスとの暗号化関係をエミュレートすることは、同一のＩＰｖ６アドレスを生成することを目的として自分自身の公開鍵に合致するＣＧＡパラメータを見つけ出すことが必要であることから、演算的に実行不可能であると想定することができる。従って、暗号化関係は一意であるとみなしうることになる。

ＭＮについてのＩＰｖ６アドレスを生成する基本ステップを図３に示すが、それは以下の通りである。

３０１． ＭＮがＨＡの公開鍵であるＫｐを取得する。

３０２． Ｋｐが、例えば、ＭＮによってランダムに選択された、ランダムな１２８ビット値（１２８）と連結される。

３０３． 連結された結果がハッシュされる。

３０４． ハッシュ値の先頭の１２８ビットが、修飾子ＭＤとして使用される。

３０５． ＭＮについてのＣＧＡを生成するためにＭＤが使用される。

本発明の第２の実施形態に従えば、ＭＮのためのルート最適化（Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ：ＲＯ）を提供するために、ＭＮとＨＡとの間の暗号化関係が利用されてＰＭＩＰｖ６環境に適用される。

ＨＡは、上記の第１の実施形態で説明される公式に応じて生成されるものではないホームアドレスを搬送するものであるならば、ＭＮまたはその対向ノード（Ｃｏｒｒｅｓｐｏｎｄｅｎｔ Ｎｏｄｅ：ＣＮ）によって送信された、いかなるホームテストイニト／ホームテスト（Ｈｏｍｅ Ｔｅｓｔ Ｉｎｉｔ／Ｈｏｍｅ Ｔｅｓｔ）（ＨｏＴＩ／ＨｏＴ）メッセージをも破棄する。これは、自分自身のＣＧＡホームアドレスを生成する時には、ＨＡによってサービスが提供されるすべてのＭＮがＨＡの公開鍵であるＨＫｐを使用しなければならないことを必要とする。

ＭＮは、自身のＨＡが、ＭＮのＣＧＡホームアドレスの所有権を、それをＲＡＮ（１２８）およびそのＨＫｐにバインディングさせる前にチェックすることを可能にする（すなわち、新たなＭＤを生成するために、両方のパラメータが使用される）。アドレスの所有権が有効であることが一旦証明され、かつ、ＨＫｐとＲＡＮ（１２８）とＭＮのホームアドレスとの間のバインディングが一旦完了すると、ＨＡは、ＭＮとＨＫｐとの間に関係があることを証明することができ、そして、それは、信頼の証拠をＣＮに提供して、直接ＭＮと通信しなくてもＭＮにサービス提供するＭＡＧと直接通信することでＭＮにサービス提供することをＣＮに促す。本発明の一実施形態では、アドレスの所有権を証明することは、ＨＡが少なくともＲＡＮ（１２８）に署名することと、ＣＮによって提供されるナンスとによって実行される。ナンスは、悪意のあるＣＮがすでに取得されている署名を使用して、それを他のＣＮに対して「再生」することを防ぐという点で、有益である。オプションで、ＨＡがＣＮとの共有鍵を有する場合、この共有鍵がＨＡの公開鍵／秘密鍵ペアの代わりに使用されてもよいだろう。

図４は、リターンルータビリティ（Ｒｅｔｕｒｎ Ｒｏｕｔａｂｉｌｉｔｙ）（ＲＲ）手順のためのシグナリングをしている。その手順において、ＨＡ４０１は、ＣＮ４０２との長期間のセキュリティ関係を確立する。ＣＮ４０２は、ＨＡ４０１と現在ＭＮにサービスを提供しているＭＡＧ４０３との間で双方向トンネリング（Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｔｕｎｎｅｌｉｎｇ：ＢＴ）モードを使用してデータパケットをＭＮとすでに交換している。図４の番号を使用すると、ステップは、以下の通りである。

Ｓ１． ＭＮの現在のＭＡＧ４０３によって送信される有効なプロキシバインディング更新（Ｐｒｏｘｙ Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ）（ＰＢＵ）メッセージの受信に続いて、ＭＮのＨＡ４０１は、(例えば、特定のトラフィック／フローについて）ＲＯモードのサービスをＭＮに提供するための決定を行う。ＨＡ４０１は、ＨｏＴＩメッセージをＣＮ４０３へ送信する。ＨｏＴＩメッセージには、「デュアルアドレス（Ｄｕａｌ Ａｄｄｒｅｓｓ）（ＤＡ）」と呼ばれる新たなオプションを有しており、これは、ＭＡＧ４０３によって送信される新たなＣｏＡをＨＡ４０１へ搬送する。ここ、ＣｏＡは、さまざまな手段を使用して送信されうる。例えば、ＣｏＡは、ＰＢＵメッセージの中で搬送される特定のホームアドレスについてＲＯモードをトリガするか否かというＨＡ４０１の決定に関らず、ＰＢＵメッセージの中で搬送されるオプションとしてＭＡＧ４０３へ送信されてもよいだろう。ＨｏＴＩメッセージに挿入されるＤＡのオプションは、ホームキージェネレータトークン（Ｈｏｍｅ Ｋｅｙｇｅｎ Ｔｏｋｅｎ）（ＨｏＴｏＫ）を演算する場合にＣＮ４０２がＣｏＡを含めるための特別なリクエストを構築する。ＣＮ４０２へ送信されるＨｏＴＩメッセージで使用されるＩＰｖ６ソースアドレスは、ＨＡ４０１に属していなければならず、そのＨＫｐを使用して導出されるＣＧＡアドレスであるべきである。

ＤＡのオプションを導入することによって、ＨＡ４０１は、悪意のあるノードによって送信されるＨｏＴＩメッセージを検出することができ、ここで、その悪意のあるノードとは、ＨＡと「暗号」関係を確立しているが、ネットワークに対してまたはＣＮ４０２自身に対してフラッディング攻撃を仕掛けることを目的としてＣＮとの特別なバインディングを確立しようとしているノードである。ＨＡ４０１は、特定のＣＮ４０２との特別なバインディングを確立することが許可されている唯一のエンティティであり、それによって、ＭＮにＲＯモードサービスを提供することを目的としてＭＮと自身との「暗号」関係を使用することが可能になる。

Ｓ２． また、ＨｏＴＩ／ＨｏＴメッセージのペアをＣＮ４０２と交換することと並行して、ＭＡＧ／ＬＭＡ４０３が、ＭＮのためのＲＯモードをトリガすることを目的としてＲＲ手順を完了する際にＭＮのＨＡ４０１を支援してもよい。この場合、ＭＡＧ／ＬＭＡ４０３は、気付アドレスイニット／気付アドレステスト（Ｃａｒｅ−ｏｆ Ａｄｄｒｅｓｓ Ｉｎｉｔ／Ｃａｒｅ−ｏｆ Ａｄｄｒｅｓｓ ｔｅｓｔ）（ＣｏＴＩ／ＣｏＴ）メッセージのペアをＣＮ４０２と交換することによって、かつ、それに対する返信として気付キージェネレータトークン（Ｃａｒｅ−ｏｆ Ｋｅｙｇｅｎ Ｔｏｋｅｎ）（ＣｏＴｏｋ）を受信することによって、ＨＡ４０１へ送信されるＣｏＡについてのアドレス到達性テストを実行する。ＨＡ４０１がＲＯモードの完全な制御を維持することを保証することを目的として、ＨＡ４０１は、ＣｏＴＩ／ＣｏＴ交換を実行する。これのために、ＨＡ４０１は、ＣｏＴＩメッセージをＭＡＧ／ＬＭＡ４０３へトンネルし、次に、ＭＡＧ／ＬＭＡ４０３は、ＣｏＴＩメッセージのカプセルを除去して、それをＣＮ４０２へ転送する。ＣＮ４０２は、ＭＡＧ／ＬＭＡ４０３にリプライし、従って、このリプライが、次に、ＨＡ４０１へトンネルによって戻される。

Ｓ３． ＨＡ４０１によって送信されるＨｏＴＩメッセージを受信した後、ＣＮ４０２は、ＨｏＴｏｋを搬送するＨｏＴメッセージを送信することによってリプライする。ＣＮはステートレスのままである。

Ｓ４． ＭＡＧ／ＬＭＡ４０３から転送されるＣｏＴｏｋを受信すると、ＨＡ４０１は、ＲＦＣ３７７５に記載されるように、一時的な共有シークレット（秘密）（Ｋｓ）を生成することを目的として、ＣＮ４０２から受信されるＨｏＴｏｋとＣｏＴｏｋとを組み合わせる。次いで、ＨＡ４０１は、（Ｋｓでそれを認証することに加えて）自身の秘密鍵で署名されるＢＵメッセージを送信して、ＣＮ４０２に対して所有権のプルーフ（証明）を提供することを目的として、すべてのＣＧＡパラメータを（すなわち、ＨＫｐを含めて）ＢＵメッセージに挿入する。ＨＡ４０１は、ＨｏＴｏｋがＨＡのＩＰｖ６アドレスとＣｏＡとの両方を使用して生成されていることをＣＮ４０２に催促することを目的として、新たなビットをＢＵメッセージ内に設定することを必要とすることがある。また、新たなビットは、ＨＡアドレスのプレフィックス部分だけをＣｏＡにバインディングするようＣＮ４０２にリクエストする働きをする。これは、バインディングは６４ビットのプレフィックスと通常のＩＰｖ６アドレスとの間で行われるであろうから、従って、普通なら悪意のある盗聴ノードによって悪用される可能性があったはずの、２つのノード間のデータパケット交換をもたらさないであろうということを意味する。

Ｓ５． 有効なＢＵメッセージを受信した後、ＣＮ４０２は、長期間のシークレット（秘密）（Ｋｂｍ）を生成し、ＨＫｐを使ってそれを暗号化し、そして、それをバインディング確認応答（Ｂｉｎｄｉｎｇ Ａｃｋｎｏｅｌｅｄｇｅｍｅｎｔ）（ＢＡ）メッセージの中でＨＡ４０１へ返信する。ここで、バインディング応答確認（Ｂｉｎｄｉｎｇ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）（ＢＡ）メッセージもまた、Ｋｓを使って認証される（そして、ＣＮのＣＧＡ鍵を使って署名されうる）。また、ＣＮ４０２も、ＨＡアドレスのプレフィックスとＣｏＡとの間のリクエストされたバインディングが成功していることをＨＡ４０１に示すことを目的として、「プレフィックスバインディング（Ｐｒｅｆｉｘ Ｂｉｎｄｉｎｇ）（ＰＢ）」と呼ばれる新たなビットを設定する。ＣＮは、ＨＡの公開鍵（すなわち、ＨＫｐ）を、Ｋｂｍ、ＨＡのＩＰアドレスのプレフィックス、ＣｏＡ、およびＣＮのＩＰアドレスと一緒に、対応するバインディングキャッシュエントリ（Ｂｉｎｄｉｎｇ Ｃａｃｈｅ Ｅｎｔｒｙ）（ＢＣＥ）の中に記憶する。

Ｓ６． ＨＡ４０１は、有効なＢＡメッセージをＣＮ４０２から受信すると、「リンク化ホームアドレス（Ｌｉｎｋｅｄ Ｈｏｍｅ Ａｄｄｒｅｓｓ）（ＬＨＡ）」のオプションと呼ばれるオプションの中で、ＭＮのホームアドレスを含む新たなＢＵメッセージをＣＮ４０２に送信する。ＨＡ４０１は、（ＲＡＮ（１２８）値を含む）自身のＩＰｖ６アドレスをＨＫｐから導出するために、ＭＮによって使用されているすべてのＣＧＡパラメータを含んでいる。ＨＡ４０１は、Ｋｂｍを使用してＢＵメッセージを認証する。ＨＡ４０１とＭＮとの間の関係を示すことによって、（ＭＮアドレスプレフィックスと同一である）ＨＡアドレスプレフィックスとＣｏＡとの間に構築されるバインディングにＭＮのホームアドレスを追加することを、ＣＮ４０２に対してリクエストするために、このＢＵメッセージが使用される。

ＨＡ４０１は、自身がＭＮによって使用されるプレフィックスと同一のプレフィックスで到達可能であることをすでにＣＮ４０２に示しているので、ＭＮのホームアドレスを使用してＨｏＴＩ／ＨｏＴメッセージをＣＮ４０２と交換する必要はない。しかしながら、ＣｏＴＩ／ＣｏＴの交換は、ＭＮとの「暗号化」関係を有するＨＡ４０１が、ＭＡＧインタフェースに割り当てられているＣｏＡに対応するＣｏＴｏｋをいつでも捕捉することができるということをＣＮ４０２に証明するために有用である場合がある。この場合、ＨＡは、ステップＳ４のＢＵメッセージの中でＣｏＴｏｋを送信する。これは、それを新たなオプションの中に挿入することによって、または、それをＫｂｍとマージすることによって、のいずれか一方によって行うことができる。また、後者の場合、ＣＮ４０２は、ステップＳ５でＨＡ４０１へ送信されるＢＡメッセージを認証するためにも、同一の新たな鍵を使用するべきである。ＭＮが別のＭＡＧへ移動していないのならば、ＣｏＴＩ／ＣｏＴの交換を周期的に繰り返す必要はない。

上記の実施形態への代替案では、第２のＢＵメッセージの内容が第１のＢＵメッセージに含まれる。ＨＡ４０１は、ＭＮのＨｏＡだけでなく、ＲＡＮ（１２８）値も含む、そのＣＧＡパラメータも、リターンルータビリティ（Ｒｅｔｕｒｎ Ｒｏｕｔａｂｉｌｉｔｙ）（ＲＲ）手順に続いてＣＮ４０２へ送信される第１のＢＵメッセージに挿入する。ＭＮのＨｏＡとの「暗号化」関係のプルーフ（証明）を提供することによって、ＨＡ４０１は、ＭＮに代わって実行されうる任意のＲＲ手順についてもＨｏＴｏｋとＣｏＴｏｋとを捕捉することもできるということを、暗示的にＣＮ４０２に示唆する（ここで、そのようなＲＲでは、ＨｏＴＩメッセージは、ＭＮのＨｏＡをソースアドレスとして使用するであろうし、そして、ＨｏＴメッセージはＭＮのＨｏＡへ送信されるであろうし、そして、ＣｏＴＩ／ＣｏＴ交換には、ＨＡ４０１によって使用されるＣｏＡと同一のＣｏＡを含むであろうことに注意されたい。）この場合、ＨＡ４０１によって使用されるもの以外には、いかなる追加のＣｏＴＩ／ＣｏＴメッセージを交換する必要もない。

ここで、悪意のあるノードが、自身の制御下にある他のノードの各々と「暗号化」関係を有することを目的としてそれらを構成することが可能であることに注意されたい。この関係は、ネットワーク／ノードに対する攻撃を開始するために、後で利用されうる。ＭＩＰｖ６および／またはＰＭＩＰｖ６環境において、最初の、かつ、重要な防衛線は、悪意のあるノードがＣＮ４０２とのプレフィックスバインディングを確立し、次いで、自身の制御下にあるすべてのノードを同一のＣｏＡ４０２にリダイレクトするという攻撃のいかなる可能性をもＨＡ４０１が阻止することを要求する。それを行うためには、攻撃者は、上述の新たなＤＡオプションを搬送するＨｏＴＩメッセージを送信する必要があるであろう。このオプションはＲＲ手順の全般的なセキュリティを向上させる一方で、ＨＡ４０１が、単純にＨｏＴＩメッセージを調べることによって、非常に初期の段階で攻撃を検出することも可能にする。この攻撃は、パケットを破棄することによって阻止される。

また、訪問先ネットワークが、フラッディング攻撃を撃退することもできる。ＭＩＰｖ６プロトコルに従えば、ネットワークのフラッディング攻撃に対抗する防衛策の１つは、リターンルータビリティ（戻り経路可能性）手順を周期的に（例えば、７分おきに）繰り返すことである。ＭＮが移動中でない場合であっても、上記のＨｏＴＩ、ＨｏＴ、およびＣｏＴＩ／ＣｏＴシグナリングの交換が周期的に実行される。これには、かなりの量のシグナリングが必要である。

悪意のあるノード（ＭＮ）が、ネットワークに対してフラッディング攻撃を仕掛けることがある。一旦攻撃が検出されると、ＭＡＧ／ＬＭＡ４０３は、認証されるシグナリングメッセージをＨＡ４０１がＣＮ４０２へ送信して、ＢＣＥ（群）に対応する悪意のあるノード（群）をフラッシュ（flush）することを、ＣＮ４０２に明示的にリクエストする。また、「撃退」タイプの防衛策を、ＭＡＧ／ＬＭＡ４０３に完全に実装することもでき、その場合、ＭＡＧ／ＬＭＡ４０３は、ＨＡ４０１を経由せずに、直接ＣＮ（群）４０２へ「フラッシュリクエスト」メッセージを送信する。これは、バインディングが確立された後でＨＡ自身が改ざんされるような状況において、有益である。この場合、ＭＡＧ４０３は、ＣＮ４０２を使ってＣｏＡテストを実行し、次いで、特別な「バインディングフラッシュリクエスト（Ｂｉｎｄｉｎｇ Ｆｌｕｓｈ Ｒｅｑｕｅｓｔ）」を送信する。バインディングフラッシュ（Ｂｉｎｄｉｎｇ Ｆｌｕｓｈ）リクエストメッセージは、ＭＡＧとＭＮとが暗号化関係を有するというプルーフ（証明）と一緒に、ＭＮのＣｏＡを含んでおり、従って、ＭＡＧの秘密鍵を使って署名されている。

フラッシュリクエストを受信すると、まず、ＣＮ４０２は、対象のＣｏＡがＣＮのバインディングキャッシュエントリ（Ｂｉｎｄｉｎｇ Ｃａｃｈｅ Ｅｎｔｒｙ）（ＢＣＥ）テーブルに記憶されていることを確認する。ＭＡＧがＭＮに代わって動作する権限を有することを一旦検証すると、ＣＮは、ＭＮのＣｏＡをそのＢＣＥテーブルからフラッシュし、そして、そのＣｏＡを使用しているすべての進行中のセッションを終了させる。また、ＣＮは、フラッシュ確認応答をＭＡＧへ送信する。

本発明の別の実施形態に従えば、２つのノード間の暗号化関係は、ＭＮがセキュア近隣ディスカバリ（Ｓｅｃｕｒｅ Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ）（ＳｅＮＤ）プロトコルの責任を、例えば、アクセスルータ（Ａｃｃｅｓｓ Ｒｏｕｔｅｒ）（ＡＲ）のようなプロキシノードに委任することを可能にすることができる。ＳｅＮＤ（２００５年３月のＲＦＣ３９７１、Ｊ．Ａｒｋｋｏ、Ｊ．Ｋｅｍｐｆ、Ｂ．Ｓｏｍｍｅｒｆｉｅｌｄ、Ｂ．ＺｉｌｌおよびＰ．Ｎｉｋａｎｄｅｒ著「セキュア近隣ディスカバリ（Ｓｅｃｕｒｅ Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ）（ＳｅＮＤ）」を参照されたい。）によって、同一のリンクに接続するホスト間、および／または、ホストとそのアクセスルータ（ＡＲ）群間の関係を確立できるようになる。ＳｅＮＤは、ホスト側でＩＰｖ６ ＣＧＡを使用し、そして、アクセスネットワークにはローカルな公開鍵インフラストラクチャを展開する。

ＳｅＮＤプロトコルを使用して、すべてのルータ広告（ＲｔＡｄｖ）メッセージだけでなく、ＡＲによって送信される（２００７年９月のＲＦＣ４８６１、Ｔ．Ｎａｒｔｅｎ、Ｅ．Ｎｏｒｄｍａｒｋ、Ｗ．ＳｉｍｐｓｏｎおよびＨ．Ｓｏｌｉｍａｎ著「ＩＰバージョン６用の近隣ディスカバリ（Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ ｆｏｒ ＩＰ ｖｅｒｓｉｏｎ ６）（ＩＰｖ６）」の中で記載される）いかなる近隣ディスカバリプロトコルメッセージも、署名される。加えて、いかなるホストも、ＣＧＡベースのＩＰｖ６アドレスを構成することができ、そして、同一のリンクに位置する他のホストと近隣ディスカバリプロトコルメッセージを交換する場合には、そのプロパティを使用して「所有権のプルーフ（証明）」を提供することができる。

上述のように、２つのノード間の暗号化関係を使用することによって、ＣＧＡ ＩＰｖ６アドレスを使用するホストは、ＳｅＮＤのタスクを委任して、そのＡＲにプロキシすることができる。

ＣＧＡ対応ノードが、ＡＲがＳｅＮＤを使用してそのＲｔＡｄｖメッセージに署名しているリンクに接続する場合、ノードは、ＡＲの公開鍵（Ｋｐ）のコピーをセキュアな方法で取得して、ノードとＡＲとの間の暗号化関係を確立することができる。１２８ビットのランダムパラメータが、ノードのＣＧＡ ＩＰｖ６アドレスを再演算するために使用される。ノードがＡＲとの暗号化関係を確立できるようにするためには、１２８ビットのランダムパラメータの修正が必要である。１２８ビットのランダムパラメータは、ランダムパラメータ（例えば、１２８ビットまたは２５６ビット）を生成した後に、このパラメータをＡＲのＫｐと連結して、その後連結をハッシュすることによって作成される、別のパラメータと置換される。次いで、ノードは、結果として得られるハッシュの先頭の１２８ビットを切り取って、それを新たなランダム１２８ビットパラメータとして使用して、そのＣＧＡ ＩＰｖ６アドレスの６４ビット識別子を生成する。

新たな１２８ビットのランダムパラメータを演算するためのルールは、以下で表すことができる。

新たなＣＧＡ １２８ビットランダムパラメータ＝先頭の［１２８，Ｈａｓｈ（Ｋｐ｜ＲＡＮ（１２８）］
ここで、先頭の（サイズ、入力）は、「入力」データの先を切ることを示し、従って、先頭の「サイズ」ビットだけが依然として使用される。ＲＡＮ（ｚ）はｚビットのランダムパラメータであり、「｜」は、連結を示している。推奨されるハッシュ関数はＳＨＡ２５６である。

新たな１２８ビットパラメータを演算した後、ノードは、ＣＧＡ仕様に定義されるような自身のＩＰｖ６アドレスを演算することへと進む。しかしながら、ノードは、ＡＲに暗号化関係に気付かせることを目的として、ＲＡＮ（１２８）をそのＡＲへ送信しなければならない。ノードは、ＲＡＮ（１２８）を、搬送されることになる新たなオプション（ＳＲＯと呼ばれる）に、例えば、ＡＲに送信されるルータ要請（ＲｔＳｏｌ）メッセージに挿入することができる。セキュリティを加えるために、ノードは、ＡＲのＫｐを使用してＳＲＯを暗号化する。

ＳＲＯを搬送するＲｔＳｏｌメッセージを受信すると、ＡＲは、まず、暗号化関係の有効性をチェックする。ＳＲＯは復号されることが好ましく、そして、ＡＲは、ＣＧＡ ＩＰｖ６アドレスがＡＲのＫｐを使用して生成されたことをチェックする。ＡＲが、ＣＧＡ ＩＰｖ６アドレスがＡＲのＫｐを使用して生成されたと判定する場合には、ＡＲは、アドレスの所有権をチェックして署名を検証することへと進む。その後、ＡＲは、ノードのＲＡＮ（１２８）を、そのアドレスおよびすべての関連するＣＧＡパラメータと一緒に記憶する。

ノードが、暗号化関係をそのＡＲに明かさないことを決定する場合には、ノードは、その新たな１２８ビットのＣＧＡパラメータだけをＡＲに開示することによって、ＳｅＮＤを使用し続けることができる。

ＡＲが、自身がＭＮに替わって動作する権限を有することを第三者に証明することが必要な場合、ＡＲは、「関係のプルーフ（証明）」を提供するために、暗号化関係を第三者に開示する。これは、ＭＮのＩＰｖ６アドレスと、それを生成するためにＭＮが使用しているすべてのＣＧＡ成分とを、第三者に通知することによって行われる。これらの成分には、１２８ビットのランダムパラメータの代わりにＲＡＮ（１２８）値を含んでいる。加えて、ＡＲは、この情報を含む、第三者へ送信されるメッセージに署名する。また、ＡＲは、この署名の中に、第三者によって提供されるナンスも含んでいることが好ましい。いかなる他のノードも、署名を偽造できない限り、ノードに代わって動作するという同一の特権を主張することはできないし、そのような署名の偽造は実行不可能だと想定されうる。また、悪意のあるノードが別の鍵ペアを生成して、ＭＮによって使用される同一のＩＰｖ６アドレスをもたらすようなパラメータの連鎖全体を再構築することを試行することも実行不可能であると想定されうる。

非ＣＧＡ移動ノードとの暗号化関係を使用することは可能であるかもしれない。ＭＮは、上述のルールと同一のルールではあるが、先頭の６４ビットを取り出してそれらをＩＰｖ６アドレスを構成するためのインタフェース識別子として使用する必要があるという点で違いがあるようなルールを適用することによって、そのＩＰｖ６アドレスを導出する。この状況に従えば、ホストがＲｔＳｏｌメッセージをＡＲへ送信する。ここで、ホストはＳＲＯを含んでおり、それをＡＴのＫｐで暗号化する。ここで、ＲｔＳｏｌメッセージは、この場合は署名されないであろうが、移動ノードは、ＡＲがソースアドレスの有効性をチェックできるようにすることを目的として、６４ビットのインタフェース識別子をＩＰｖ６ソースアドレスの中に使用することに注意されたい。このサービスは、近隣ディスカバリプロキシ実行タスクをそのＡＲに委任することを可能にすることから、低処理力のデバイスにとって有益でありうる。

暗号化関係は、ステートフルなアドレス構成が行われている場合、すなわち、ＭＮが自身のアドレスを自由に選択しない場合、ＭＮとそのＡＲとの間で自動的に確立されてもよい。これは、リンクに接続しているＭＮ群に割り当てられることになるＩＰｖ６アドレスを生成するためにＤＨＣＰを可能にすることによって、行われてもよい。次いで、ＤＨＣＰは、ＭＮに関与させることなく、ＲＡＮ（１２８）をＡＲと共有する。この状況では、ＡＲは、ＲｔＡｄｖメッセージの中に１ビットを設定することによって、ＭＮに代わって動作するその能力をＭＮに信号で伝達してもよい。

上述のように、暗号化関係は、ＳｅＮＤプロキシ実行を移動／固定ホストが行えるようにするために使用することができる。そのようにするためには、各ＭＮは、そのＡＲと暗号化関係を確立し（すなわち、その証明をチェックした後で）、次いで、対応するＲＡＮ（１２８）パラメータをそのＣＧＡパラメータと一緒に、ＡＲへ送信しなければならない。ここで、ＳｅＮＤ近隣ディスカバリプロトコル（ＮＤＰ）プロキシ実行タスクをＡＲへ委任する１つの方法は、暗号化関係を、ＭＮによって送信されうるＲｔＳｏｌメッセージの中でＡＲに開示することである。ＳＲＯを搬送するＲｔＳｏｌメッセージを送信した後で、送信ノード（すなわち、プロキシノードと暗号化関係を確立しているノード）が、近隣ディスカバリプロトコルのクエリへの応答を中止する。換言すれば、送信ノードが、自身が適切であると判断する時にはいつでも、リンクから「消える」時を決定する。

プライバシ目的のために、ＭＮは、ＮＤＰメッセージに署名する場合に自分自身のＣＧＡ公開鍵を公開することを避けることを目的として、リンクに物理的に接続している間であってもプロキシ実行タスクを自身のＡＲに委任することを決定してもよい。実際、特にＭＮが１つ以上の擬似ＩＰｖ６アドレスを使用している場合に、公開鍵を開示することは、匿名性（ｕｎｌｉｎｋａｂｉｌｉｔｙ）の側面を大きく損なう可能性がある。異なるＡＲ間をＭＮが切り替わる場合、ＭＮは、普通ならＣＧＡ公開鍵を開示することによって損なわれるはずの、ある程度の位置プライバシを維持することを望む可能性がある。

特定のホストに代わってＳｅＮＤプロキシとして動作する場合、ＡＲは、ＮＤＰメッセージの有効性をチェックする前に、第三者ノードがＡＲのＫｐを使用してＭＮのＩＰｖ６アドレスを導出できるようにするために、ＭＮに代わって送信される各ＮＤＰメッセージの中に、ＲＡＮ（１２８）値だけでなくＭＮのＣＧＡパラメータすべてを含ませる。第三者ノードが、提供されるＭＮのＩＰｖ６アドレスをＡＲによって送信されるパラメータから演算できない場合、第三者ノードはメッセージを破棄する。

暗号化関係を構築するために有益でありうるもう１つの設定は、ホストアイデンティティプロトコル（Ｈｏｓｔ Ｉｄｅｎｔｉｔｙ Ｐｒｏｔｏｃｏｌ）（ＨＩＰ）のコンテキストにある。ここで、（移動）ノードは、ホストアイデンティティタグ（Ｈｏｓｔ Ｉｄｅｎｔｉｔｙ Ｔａｇ）（ＨＩＴ）属性を有する。このホストアイデンティティタグ（Ｈｏｓｔ Ｉｄｅｎｔｉｔｙ Ｔａｇ）（ＨＩＴ）属性は、ノードの公開鍵をハッシュすることによって生成される、すなわち、ＨＩＴ＝ＨＡＳＨ（．．．，ＰＫｎ，．．．）である。また、上述の諸実施形態と同様に、ノードは、ＨＩＴを作成する時に何らかの他のエンティティの公開鍵も含んでいる。一般に、ノードが一時的な「識別子」または他の属性を生成する場合に、本発明を使用することができる。例えば、ＥＡＰ（拡張認証プロトコル（Ｅｘｔｅｎｓｉｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＩＥＴＦ ＲＦＣ ３７４８）雅号またはＧＰＲＳ Ｐ−ＴＭＳＩが、この方法に従って生成されてもよい。また、本発明によって（一時的な）「アカウント番号」を生成することによって「金融」取引を委任することも可能である。

上述のすべての実施形態に従えば、プロキシノードが不正に振舞って、実行されるべきでない行為を第１のノードに代わって実行することには利点が存在する可能性があることから、第１のノード（例えば、移動ノード）によって供給されるＲＡＮは、それ自体で、第１のノードに代わってプロキシノードが動作しているという絶対的なプルーフ（証明）を構築しない。また、そのような場合、第１のノードは、ＩＰアドレスを生成するためにその公開鍵も使用しなければならず、従って、第１のノードは、プロキシノードが移動ノードに代わって動作する権限を有することを第３のノードが検証することを目的として、その公開鍵も第３のノードに提供しなければならない。

次に図５を参照すると、ここでは本発明の一実施形態に従うネットワークノード５０１が示されている。この例では、ネットワークノードは、移動ノード５０１であり、そして、移動ノードに関連付けられているプロキシノードの公開鍵を受信するための受信器５０２と、ＭＮについての暗号化によって生成されるＩＰアドレスを生成するためのプロセッサ５０３とを備える。移動ノードは、さらに、プロキシノードと通信するための送信器５０４と、生成されるＩＰアドレスを記憶するためのメモリ５０５とを備える。

図６は、プロキシノード６０１を示している。ここで、プロキシノード６０１は、プロキシノードに関連付けられているＭＮに属する識別子を記憶するためのメモリ６０２を備えており、この識別子は上述のようにして生成されているものである。識別子と識別子を生成するために使用される暗号材料とこれらの値の署名とを次のノードに送信するために第１の送信器６０３が提供され、それによって、プロキシノードが第１のノードに代わってメッセージを送信する権限を有することを、次のノードが検証できるようになる。署名を作成するために第１の処理機能６０４が提供され、そして、署名を次のノードに送信して、プロキシノードが第１のノードに代わってメッセージを送信する権限を有することを次のノードが検証できるようにするために、第２の送信器６０５が提供される。

各種の実施形態を示し、詳細に記載してきているが、請求項は、いずれかの特定の実施形態や例に限定されるものではない。上述の記載はいずれも、いずれかの特定の要素、ステップまたは機能が、それが請求項の範囲に含まれなければならない程度に必須であることを意味していると解釈されるべきではない。特許で保護される範囲は、請求項によって定義される。

本明細書では、下記の頭字語が使用される。

ＢＡ バインディング応答確認（Binding Acknowledgment）
ＢＣＥ バインディングキャッシュエントリ（Binding Cache Entry）
ＢＴ 双方向トンネリングモード（Bidirectional Tunneling Mode(MIPv6)）
ＢＵ バインディング更新（Binding Update）
ＣＧＡ 暗号化生成アドレス（Cryptographically Generated Address）
ＣＮ 対向ノード（Correspondent Node）
ＣｏＴ 気付アドレステストメッセージ（Care-of Address Test Message）
ＣｏＴＩ 気付アドレスイニットメッセージ（Care-of Address Init Message）
ＣｏＴｏｋ 気付キージェネレータトークン（Care-of Keygen Token）
ＨＡ ホームエージェント（Home Agent）
ＨＫｐ ホームエージェント公開鍵（Home Agent public key）
ＨＫｒ ホームエージェント秘密鍵（Home Agent private key）
ＨｏＴ ホームテストメッセージ（Home Test Message）
ＨｏＴＩ ホームテストイニットメッセージ（Home Test Init Message）
ＨｏＴｏｋ ホームキージェネレータトークン（Home Keygen Token）
ＩＥＴＦ インターネットエンジニアリングタスクフォース（Internet Engineering Task Force）
Ｋｐ 移動ノードＣＧＡ公開鍵（Mobile Node CGA public key）
Ｋｓ ＨＡとＣＮ間の共有鍵（Shared Key between the HA and the CN）
ＬＭＡ ローカルモビリティアンカー（Local Mobility Anchor）
ＭＡＧ 移動アクセスゲートウェイ（Mobile Access Gateway）
ＭＤ 修飾子（Modifier）
ＭＩＰｖ６ （Mobile IPv6）
ＭＮ 移動ノード（Mobile Node）
ＮＤＰ 近隣ディスカバリプロトコル（Neighbour Discovery Protocol）
ＰＭＩＰｖ６ プロキシＭＩＰｖ６（Proxy MIPv6）
ＲＯ ルート最適化モード（Route Optimization Mode(MIPv6)）
ＲＲ リターンルータビリティ手順（Return Routability Procedure）
ＰＢＵ プロキシバインディング更新メッセージ（Proxy Binding Update Message）
ＳｅＮＤ セキュア近隣ディスカバリ（Secure Neighbor Discovery）

Claims (15)

1. 通信ネットワークにおいて、移動ノードとプロキシノードとの間で暗号化関係を確立する方法であって
   前記移動ノードが、前記プロキシノードから、該プロキシノードの暗号化属性の少なくとも一部を受信するステップと、
   前記移動ノードが、前記プロキシノードから受信される前記暗号化属性をランダム値と連結するステップと、
   前記移動ノードが、連結された結果をハッシュするステップと、
   前記移動ノードが、該移動ノードの識別子を生成するために、受信した前記暗号化属性の少なくとも一部と、前記移動ノードの暗号化属性の少なくとも一部とを使用するとともに、前記ハッシュするステップの結果として得られたハッシュ値の少なくとも一部を修飾子として使用するステップと、
   前記プロキシノードが、前記移動ノードに属する前記識別子と前記ランダム値とを第３のノードへ送信するステップと、
   前記第３のノードが、前記プロキシノードが前記移動ノードと信頼関係を有し、かつ前記移動ノードに代わってメッセージを送信する権限を有することを検証するために、前記移動ノードに属する前記識別子と前記ランダム値とを使用するステップと
   を備えることを特徴とする方法。
2. 前記移動ノードの識別子は、暗号化によって生成されたＩＰアドレスである
   ことを特徴とする請求項１に記載の方法。
3. 前記暗号化属性は、前記プロキシノードに属する公開鍵を備える
   ことを特徴とする請求項１または２に記載の方法。
4. 前記プロキシノードにおいて、前記移動ノードに属する前記識別子と前記ランダム値とを含むメッセージに署名するステップを更に備える
   ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記通信ネットワークは、プロキシモバイルＩＰネットワークを備え
   前記プロキシノードは、前記移動ノードに関連付けられているホームエージェントである
   ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記ホームエージェントを介して、前記移動ノードにルート最適化を提供するステップを更に備える
   ことを特徴とする請求項５に記載の方法。
7. 前記プロキシノードは、それを介して前記移動ノードが前記通信ネットワークに接続するプロキシノードである
   ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
8. 前記移動ノードに代わって前記プロキシノードから、セキュア近隣ディスカバリメッセージを送信するステップを更に備える
   ことを特徴とする請求項７に記載の方法。
9. 前記プロキシノードにおいて、前記移動ノードに関するフラッディング攻撃を検出するステップと、
   前記検出の結果として、フラッシュリクエストメッセージを第３のノードへ送信するステップとを更に備え、
   前記フラッシュリクエストメッセージは、前記移動ノードに関するすべてのバインディングキャッシュエントリをフラッシュすることを前記第３のノードに命令するものであり、
   前記フラッシュリクエストメッセージは、前記移動ノードに属する前記識別子と、前記識別子を生成するために使用されるその他の暗号化材料とを備える
   ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. 通信ネットワークで使用する移動ノードであって、
    プロキシノードに属する暗号化属性の少なくとも一部を、前記プロキシノードから受信するための受信器と、
    前記プロキシノードに属する前記暗号化属性をランダム値と連結するための手段と、
    連結された結果をハッシュするための手段と、
    受信した前記プロキシノードに属する前記暗号化属性の少なくとも一部と、当該移動ノードに属する暗号化属性の少なくとも一部とを使用するとともに、前記ハッシュするための手段の結果として得られたハッシュ値の少なくとも一部を当該移動ノードの識別子を生成するための修飾子として使用して、当該移動ノードの識別子を生成するためのプロセッサとを備え、
    前記識別子と前記ランダム値とは、当該プロキシノードが前記移動ノードに代わってメッセージを送信する権限を有することを次のノードに検証することを可能にする
    ことを特徴とする移動ノード。
11. 前記識別子は、暗号化によって生成されたＩＰアドレスである
    ことを特徴とする請求項１０に記載の移動ノード。
12. 前記プロキシノードに属する前記暗号化属性は、公開鍵である
    ことを特徴とする請求項１０または１１に記載の移動ノード。
13. 通信ネットワークで使用するプロキシノードであって
    前記プロキシノードに関連付けられている移動ノードに属する識別子を記憶するためのメモリと、
    前記移動ノードに属する前記識別子と、前記識別子を生成するために使用されるランダム値を含む暗号化材料を次のノードに送信するための送信機とを備え、
    前記識別子は、当該プロキシノードに属する暗号化属性の少なくとも一部と、前記移動ノードに属する暗号化属性の少なくとも一部とを使用するとともに、当該プロキシノードに属する前記暗号化属性を前記ランダム値と連結し、連結された結果をハッシュし、ハッシュしたことの結果として得られたハッシュ値の少なくとも一部を修飾子として使用することによって、生成されているものであり、
    前記識別子と前記暗号化材料とは、当該プロキシノードが前記移動ノードに代わってメッセージを送信する権限を有することを検証するために、前記次のノードによって使用されるものである
    ことを特徴とするプロキシノード。
14. 前記識別子は、暗号化によって生成されたＩＰアドレスであり、
    前記プロキシノードに属する暗号化属性は、公開鍵である
    ことを特徴とする請求項１３に記載のプロキシノード。
15. 前記移動ノードに関するフラッディング攻撃を検出するための手段と、
    前記次のノードにフラッシュリクエストメッセージを送信するための手段とを備え、
    前記フラッシュリクエストメッセージは、前記移動ノードに関するすべてのバインディングキャッシュエントリをフラッシュすることを前記次のノードに命令するものであり、
    前記フラッシュリクエストメッセージは、前記移動ノードに属する識別子と、前記識別子を生成するために使用されるその他の暗号化材料とを備える
    ことを特徴とする請求項１３または１４に記載のプロキシノード。

Images