特許 5745626 ホストベースのモビリティおよびマルチホーミングプロトコルに対する軽量セキュリティソリューションのための方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5745626

(24)【登録日】2015年5月15日

(45)【発行日】2015年7月8日

(54)【発明の名称】ホストベースのモビリティおよびマルチホーミングプロトコルに対する軽量セキュリティソリューションのための方法および装置

(51)【国際特許分類】

   H04L 9/08 20060101AFI20150618BHJP

   H04L 9/32 20060101ALI20150618BHJP

【ＦＩ】

   H04L9/00 601C

   H04L9/00 675A

【請求項の数】9

【全頁数】18

(21)【出願番号】特願2013-518456(P2013-518456)

(86)(22)【出願日】2011年6月20日

(65)【公表番号】特表2013-535862(P2013-535862A)

(43)【公表日】2013年9月12日

(86)【国際出願番号】US2011041028

(87)【国際公開番号】WO2012005930

(87)【国際公開日】20120112

【審査請求日】2013年2月22日

(31)【優先権主張番号】12/803,504

(32)【優先日】2010年6月29日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】391030332

【氏名又は名称】アルカテル−ルーセント

(74)【代理人】

【識別番号】110001173

【氏名又は名称】特許業務法人川口國際特許事務所

(72)【発明者】

【氏名】ハンペル，カール・ゲオルク

(72)【発明者】

【氏名】コレスニコフ，ビアジーミル・ワイ

【審査官】 打出 義尚

(56)【参考文献】

【文献】 米国特許出願公開第２００３／０２１１８４２（ＵＳ，Ａ１）

【文献】 特開平０６−２２４８９７（ＪＰ，Ａ）

【文献】 瀬下 正樹，竹内 元規，渡邊 晃，Ｍｏｂｉｌｅ ＰＰＣにおける移動端末の認証，マルチメディア，分散，協調とモバイル（ＤＩＣＯＭＯ ２００５）シンポジウム論文集，日本，社団法人情報処理学会，２００５年 ７月 ６日，第２００５巻，第６号，ｐｐ．１２９−１３２

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／０８

Ｈ０４Ｌ ９／３２

(57)【特許請求の範囲】

【請求項1】

モビリティセッションにおいてネットワークにわたりコレスポンデントノードＣＮに接続されたモビリティノードＭＮでセキュリティプロトコルを動作させる方法であって、
ＭＮにおいてランダムナンスＲ_ｉを引き継がれた暗号ハッシュを生成し、及び、ランダムナンスＲ_ｉをキャッシュに入れることと、
モビリティセッション中に、一連のメッセージのうちの、第ｉ番目のＭＮメッセージをＣＮに送信することを含み、第ｉ番目のＭＮメッセージは、ランダムナンスＲ_ｉの暗号ハッシュ、ランダムナンスＲ_ｉ−１及び、キャッシュされたランダム鍵Ａ_ｉ−１に基づくハッシュベースのメッセージ認証コード（ＨＭＡＣ（Ａ_ｉ−１｜ＭＳＧ））を含み、さらに、
ランダム鍵ｄＡとＨＭＡＣ（Ａ_ｉ−１｜ＭＳＧ）を含む第ｉ番目のＣＮメッセージを、ＣＮから受信することと、
ＭＮにおいて、ランダム鍵ｄＡをキャッシュされたランダム鍵Ａ_ｉ−１に加えることにより、ランダム鍵Ａ_ｉを生成し、ランダム鍵Ａ_ｉをキャッシュに入れることと、
新しいランダムナンスＲ_ｉ＋１を生成することと、
第ｉ＋１番目のＭＮメッセージをＭＮからＣＮに送信することを含み、第ｉ＋１番目のＭＮメッセージが、新しいランダムナンスＲ_ｉ＋１の暗号ハッシュ、ランダムナンスＲ_ｉと、ランダム鍵Ａ_ｉに基づくＨＭＡＣ（Ａ_ｉ｜ＭＳＧ）を含む、方法。

【請求項2】

ＣＮから第ｉ＋１番目のメッセージを受信するステップをさらに備え、前記メッセージは新しいランダム鍵ｄＡとランダム鍵Ａ_ｉに基づくＨＭＡＣ（Ａ_ｉ｜ＭＳＧ）を含む、請求項１に記載の方法。

【請求項3】

ＭＮが、接続ポイントにおいてネットワークノードに動作可能に接続された周辺デバイスを含み、周辺デバイスがＩＰアドレスを有する、請求項１に記載の方法。

【請求項4】

ランダムナンスＲ_ｉ−１が初期ナンスである、請求項１に記載の方法。

【請求項5】

モビリティノード（ＭＮ）であって、
メッセージを処理するために、ＭＮに動作可能に接続されたコンピュータプロセッサと、
コレスポンデントノード（ＣＮ）とメッセージを交換するために、コンピュータプロセッサに動作可能に接続された通信インタフェースとを有し、
コンピュータプロセッサが、ＭＮのＩＰアドレスが変化した場合にＩＰアドレス更新をＣＮに送信するための信号伝達メッセージを生成し、
ＭＮからＣＮへ送られた第ｉ番目のＭＮメッセージが、少なくともコンピュータプロセッサにより生成されキャッシュされたランダムナンスＲ_ｉの暗号ハッシュ、第ｉ−１番目のＭＮメッセージのランダムナンスＲ_ｉ−１、及び、第ｉ−１番目のＭＮメッセージのＣＮから受信されたランダム増分ｄＡを使用して計算された鍵Ａ_ｉ−１に基づくＭＡＣ（メッセージ認証コード）を含む、モビリティノード。

【請求項6】

モビリティセッションにおいてネットワークにわたりモビリティノードＭＮに接続されたコレスポンデントノードＣＮでセキュリティプロトコルを動作させる方法であって、
モビリティセッション中に、ランダムナンスＲ_ｉの暗号ハッシュ、ランダムナンスＲ_ｉ−１及び、キャッシュされたランダム鍵Ａ_ｉ−１に基づくハッシュベースのメッセージ認証コード（ＨＭＡＣ（Ａ_ｉ−１｜ＭＳＧ））を含む第ｉ番目のＭＮメッセージを受信することと、
受信したランダムナンスＲ_ｉ−１から計算した暗号ハッシュが、キャッシュに入れられたランダムナンスＲ_ｉ−１の暗号ハッシュと同一であることを確認することと、
ランダムナンスＲ_ｉの暗号ハッシュをキャッシュに入れることと、
ランダム鍵ｄＡを生成しおよび、Ａ_ｉがＡ_ｉ−１とランダム鍵ｄＡの和と等しくなるようにランダム鍵Ａ_ｉを計算し、ＣＮでランダム鍵Ａ_ｉをキャッシュに入れることと、
ランダム鍵ｄＡとＨＭＡＣ（Ａ_ｉ−１｜ＭＳＧ）を含む応答メッセージをＭＮへ送信することと、
ＭＮから第ｉ＋１番目のＭＮメッセージを受信することを有し、第ｉ＋１番目のＭＮメッセージは、新しいランダムナンスＲ_ｉ＋１の暗号ハッシュ、ランダムナンスＲ_ｉ及び、ＨＭＡＣ（Ａ_ｉ｜ＭＳＧ）を含む、方法。

【請求項7】

受信したランダムナンスＲ_ｉから計算した暗号ハッシュが、キャッシュに入れられたランダムナンスＲ_ｉの暗号ハッシュと同一であることを確認するステップと、
ＨＭＡＣ（Ａ_ｉ｜ＭＳＧ）を確認するステップと、
新しいランダムナンスＲ_ｉ＋１の暗号ハッシュをキャッシュに入れるステップと、
第２のランダム鍵ｄＡを生成しおよび、Ａ_ｉ＋１がＡ_ｉと第２のランダム鍵ｄＡの和と等しくなるようにランダム鍵Ａ_ｉ＋１を計算し、ランダム鍵Ａ_ｉ＋１をキャッシュに入れるステップと、
ＭＮへ第２のランダム鍵ｄＡとＨＭＡＣ（Ａ_ｉ｜ＭＳＧ）を転送するステップとをさらに含む、請求項６に記載の方法。

【請求項8】

ＭＮから後続のメッセージを受信した後、後続のランダム鍵ｄＡをＭＮに、ＣＮによって送信するステップをさらに備える、請求項７に記載の方法。

【請求項9】

トランスポート接続がＣＮからＭＮに形成され、ＣＮがトランスポート接続を介してモビリティセッション中にＣＮの接続ポイントへの変更でＭＮを更新する、請求項７に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般に、ホストベースのモビリティおよびマルチホーミングプロトコルに関し、さらに具体的には、妥当なコストで十分なセキュリティを提供しつつ、トランスポート接続の変更を効率的かつ高い費用対効果で更新するモビリティプロトコルに関する。

【背景技術】

【0002】

モバイルインターネットトラフィックは、近年飛躍的に増大しており、スマートフォンの最新世代の登場以来その増加は顕著である。電話技術の進歩はインターネットトラフィックを飛躍的に増大させ、研究団体では、ＩＰモビリティおよびマルチホーミングの既存概念を考え直すことを余儀なくされている。ＩＰモビリティの１つの基本的なテナントは、ホストがＬ３接続ポイント、すなわちＩＰアドレスを進行中のトランスポートセッション中に変更できることである。進行中のセッションを、たとえば３Ｇ無線ネットワークからＷｉＦｉのような異なるインターフェイスに選択的に切り替え可能であることが必要とされるマルチホーミングホストはまた、ＩＰ接続ポイントを変更できる必要もある。

【0003】

公共インフラストラクチャを介する通信デバイス向けのプロトコルを設計することは本質的に、たとえばインターネットの公共性に起因するセキュリティの問題を真剣に考慮することを伴う。公共フォーラムにおいて、敵対者は、情報を悪用して、悪意の目的でトランスポートセッションをリダイレクトすることができる。そのようなリダイレクト攻撃により、敵対者は、たとえば通信セッションをハイジャックして、セッションのエンドポイントの１つに成り代わってセッションを続行することができるようになる。

【0004】

敵対者はまた、サービス妨害（ＤｏＳ：Ｄｅｎｉａｌ−ｏｆ−Ｓｅｒｖｉｃｅ）攻撃を行なうためにセッションへのアクセスを使用することもでき、そこで敵対者は被害者ホストに大量のトラフィックを振り向ける。ＤｏＳ攻撃はまた、フラッディング（ｆｌｏｏｄｉｎｇ）としても知られる。

【0005】

リダイレクトおよびフラッディングはそれぞれ、多くの場合極めて異なる解決策を備えるさまざまなセキュリティの問題をもたらす。

【0006】

たとえば、リダイレクト攻撃を防御するために使用可能なメカニズムは、モビリティ技術に依存する。Ｗ−ＣＤＭＡ、ＬＴＥ、ＷｉＭＡＸのような、現在のモビリティ規格は、ネットワークベースのモビリティを使用する。それらの技術は、モバイルノード（ＭＮ：Ｍｏｂｉｌｅ Ｎｏｄｅ）とそのピアとの間のすべてのトラフィックを中継するためにネットワーク側アンカーを採用する。すべてのモビリティ関連の信号伝達は、ＭＮとネットワーク（側アンカー？）との間で交換され、加入者とそのサービスプロバイダ間に存在する信頼関係を活用することによって保護されうる。

【0007】

あるいは、ホストベースのモビリティにより、ＭＮがそのＩＰアドレスを変更した場合にはＭＮがコレスポンデントノード（ＣＮ：Ｃｏｒｒｅｓｐｏｎｄｅｎｔ Ｎｏｄｅ）を更新することができる。対応して、ＣＮは、データパケットをＮＭの新しいアドレスに直接送信することができる。その結果、ホストベースのモビリティプロトコルは、ネットワーク側アンカーの必要性を解消するので、より一層費用対効果が高く、多用途であり、拡張性を備えている。ホストベースのモビリティシステムの利点は、適切な低コストのホストベースのモビリティプロトコルを確立しようと試みる多数の研究活動を活性化させた。そのようなプロトコルの例は、今日までさらによく知られるプロトコルのほんの一例をあげると、Ｈｏｓｔ−Ｉｄｅｎｔｉｆｉｅｒ Ｐｒｏｔｏｃｏｌ（ＨＩＰ）、経路最適化Ｍｏｂｉｌｅ ＩＰｖ６（ＭＩＰｖ６ Ｒ／Ｏ）、ＴＣＰ−ＲおよびＥＭＩＰｖ６を含むことができる。

【0008】

知られているホストベースプロトコルの一部は、マルチホーミングのシナリオをサポートする。具体的には、マルチホーミングのシナリオにおいて、ホストは、複数のＩＰアドレスを代替ルーティングパスとしてＣＮに通知することができる。そのようなプロトコルの例は、ＳＣＴＰ、ＨＩＰ、マルチホーミングＴＣＰ（ＭＨ ＴＣＰ）、およびＳＨＩＭ６を含む。モビリティおよびマルチホーミングアドレスはいずれも密接に関わる問題であるため、両方の現象に対処する場合、通常はモビリティに言及する。

【0009】

ホストベースのモビリティプロトコルにおけるセキュリティに関する限り、ホストベースのモビリティは、トラフィック接続を維持するエンドノードに限定される。その結果、信頼関係は通常、モビリティ関連の信号伝達メッセージを保護するためには使用することができない。たとえば、ＨＩＰのフレームワーク内において、ＰＫＩを使用して、グローバルレベルで、すなわちインターネット上のすべてのホストに対して、信頼関係を作成することが提案された。その結果、信頼関係の構築に関わる作業、ならびに拡張性および取り消しの問題は、ホストベースのモビリティの主要な利点を大幅に損なってしまう。したがって、一部の提案では、接続のために以前準備された信頼関係を必要とする、ＩＰｓｅｃのようなメカニズムを採用する。

【0010】

その結果、ホストベースのモビリティプロトコルは、ランダムナンスのオープンな交換、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ交換による鍵配列、およびルーティング可能性検査のような、弱い認証の方法に依存してきた。そのような解決策は、不十分な保護をもたらすか、またはエンドノードに不必要な処理負荷を課す。

【発明の概要】

【課題を解決するための手段】

【0011】

トランスポート接続システムが示される。システムは、メッセージを送信および受信するように構成された第１のデバイスを含む。メッセージを送信および受信するように構成された第２のデバイスもまた、提供される。第１のデバイスにより生成されたメッセージｉは、前のメッセージｉ−１で第１のデバイスから第２のデバイスに送信されたＨａｓｈ（Ｒｉ−１）への秘密Ｒｉ−１を含む。メッセージｉはランダム鍵Ａｉ−１により署名され、ランダム鍵は前のメッセージからの鍵Ａｉ−２の更新から導かれており、メッセージｉ−１は鍵Ａｉ−２により署名される。

【図面の簡単な説明】

【0012】

【図1】本明細書の原理により設計されたシステムのＩＮＩＴハンドシェークの実施形態を示す図である。

【図2】本明細書の原理により構築された１つのモビリティアソシエーション（ＭＡ：Ｍｏｂｉｌｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ）のためのＩＮＩＴハンドシェークの実施形態を示す図である。

【図3】本明細書の原理により構築されたバインディング更新ハンドシェークの実施形態を示す図である。

【図4】本明細書の原理により構築されたバインディング更新の実施形態を示す図である。

【図5】本明細書の原理により構築された２つのＭＡのためのＩＮＩＴハンドシェークの実施形態を示す図である。

【図6】本明細書の原理により構築されたＢＴハンドシェーク、本明細書の原理により構築されたＭＡペア鍵更新を示す図である。

【図7】本明細書の原理により構築されたＭＡペアバインディング更新を示す図である。

【図8】本明細書の原理により構築されたＭＡペア鍵更新の実施形態を示す図である。

【図9】本明細書の原理により構築された多重化信号伝達および帯域外信号伝達のトラフィック接続を連結するための実施形態を示す図である。

【発明を実施するための形態】

【0013】

リダイレクトおよびフラッディング攻撃からホストベースのモビリティプロトコルを保護するための軽量セキュリティソリューションが示される。本明細書において称されるホストモビリティとは、１つのＩＰアドレスから別のＩＰアドレスへのトランスポート接続エンドポイントの移行であり、モビリティイベントおよびマルチホーミングのシナリオに適用される。本明細書におけるソリューションは、弱い認証の方法と、セッション所有権証明機能を結合する。ソリューションにより、敵対者は、攻撃を首尾よく開始するために、インターネット上の既存の信号伝達プロトコルに対する同等の攻撃よりも、追加の、および場合によっては実質的に多大な作業が必要となる。有利なことに、ソリューションは、経路最適化を備えるＭｏｂｉｌｅ ＩＰｖ６を改良するために使用されてもよい。

【0014】

本明細書の原理によれば、ネットワーク側アンカーのような、相互信頼関係および／またはネットワークベースのインフラストラクチャの要件は除外される。ソリューションは、接続のいずれの端部でも保持されるべき処理および状態情報を最小限しか必要としないという点において、軽量である。セキュリティレベルは、既存のインターネットセキュリティソリューションと比較して十分である。ソリューションは少なくとも、リダイレクト攻撃を防御するための知られているプロトコルと同等に安全である。ソリューションは、フラッディング攻撃を回避するための知られているセキュリティプロトコルよりも優れている。

【0015】

本明細書の原理によれば、各モビリティセッションは、２つのホスト間のモビリティ関連の信号伝達およびセキュリティをサポートする。トラフィック接続は、モビリティセッションと並行して実行する。各モビリティセッションは、少なくとも１つのモビリティアソシエーション（ＭＡ）を定義する。ＭＡは、モビリティノード（ＭＮ）とコレスポンデントノード（ＣＮ）との間に単信モビリティセッションを確立する。ＣＮがＩＰアドレス更新を送信せず、ＭＮのみが送信するので、単信ＭＡはまた、リダイレクト攻撃の危険を低減する。単信特性のホストベースのモビリティセッションは、セキュリティ関連の信号伝達および処理作業、ならびに接続の各々の端部で保持される必要のある状態の量を軽減する。

【0016】

各ＭＡは、２つのホストのうちの１つによって所有され、所有者ホストにモビリティサポートを提供する。ＭＮは、ＭＡの所有権証明をＣＮに提供し、ＣＮは単一の分岐ＲＲＴを通じてＭＮへのルーティング可能性を確認する。ＭＮは、対称認証鍵を保持および使用することによりＭＡの所有権を証明することができる。ＭＮは、ＣＮのメッセージに基づいて鍵を定期的に更新することができる。ＭＮは、受動的攻撃者から保護するため、前のメッセージに関連する秘密を関連付けて同一送信者の証明のチェーンを作成することにより、要求をさらに認証することができる。所有権の証明は、セッションハイジャックおよびセッション中断を防御する。

【0017】

両方のホストがモバイルである場合、本明細書におけるシステムは、二重モビリティセッションを確立するように構成されてもよく、各ホストは同一モビリティセッション内の各自のＭＡをサポートする必要がある。言い換えれば、セッションは２つの重ね合わされた単信モビリティセッションを含み、その結果外見上は二重であるが処理要件が低減されたセッションをもたらす。各ホストは、所有するＭＡを介して、進行中のトランスポート接続を切断することなくＩＰアドレスを変更することができ、無線ネットワークならびに無線マルチホーミングのシナリオに適用されてもよい。ＭＡは、攻撃者がＭＡを既存のトラフィック接続にオーバーレイすること、またはセットアップ後にセッションをハイジャックすることを禁じるために、関連するトラフィック接続セットアップ前、またはセットアップ中に確立される必要がある。さらに、システムは、もしくはＤＨベースの鍵交換または相互信頼関係のネットワークサポートまたは処理オーバーヘッドを必要とすることなく、セッションハイジャックに対してＭＩＰｖ６よりも確実なセキュリティをもたらす。ＭＮはまた、ピアがホストベースのモビリティをサポートするかどうかを決定するためにＭＡを使用することもできる。

【0018】

図１に示されるように、１つのＭＡのみをポートするモビリティセッションを含むシステムは、必要とする状態情報および各ホスト上の処理がより少なくてすむ。そのようなシステムは、セッションハイジャックが定常ホストに成り代わって実行されることがないので、知られているシステムよりも強化されたセキュリティをもたらす。モバイルインターネットトラフィックの大きな割合が定常サーバを占めているので、これらの利点は重要である。

【0019】

モビリティについて概ね１００で示され、マルチホーミングについて１１０で示されるＭＡは、一般にＩＮＩＴとして知られる任意の適切な初期ハンドシェークを介して確立され、ＩＮＩＴはたとえば、ＩＮＩＴ要求１１２、１１４、およびＩＮＩＴ応答１１６、１１８を含むことができる。初期ハンドシェークは、すべてのホストベースモビリティ、およびマルチホーミングプロトコルによってサポートされる。初期ハンドシェークはまた、モビリティセッション自体を定義する。

【0020】

初期ハンドシェーク後、すべてのさらなるハンドシェークは、１つのＭＡに代行して発生する、すなわちハンドシェークは、モビリティイベントを通知した所有者ホストに関連するセキュリティパラメータにしか影響を与えない。これにより、モビリティセッションの両方のエンドポイントは、一時的な重複によりモビリティ関連の信号伝達ハンドシェークを実行することができる。

【0021】

モビリティ関連の信号伝達を保護するため、すべてのモビリティ関連のイベントは、要求１２０、１２２メッセージおよび応答１２４、１２６メッセージで構成される両方向ハンドシェークを要求すると仮定し、この両方向ハンドシェークをバインディング更新（ＢＵ：Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ）交換と称する。要求１２０、１２２は、ＩＰアドレスの追加、削除、または変更を通知するためにＭＡ所有者によって送信される。要求１２０、１２２は、応答１２８、１３０でピアによって確認される。そのようなハンドシェークは、一般に、ホストベースモビリティプロトコルに従う。

【0022】

ＤｏＳまたはフラッディング攻撃、およびセッションハイジャックを防御するため、ＢＵ要求１２０、１２２の送信者は、ＭＡの所有権、すなわちモビリティセッションのエンドポイントであることを表明する必要がある。これは、ホスト所有者が以前のＭＡ関連のすべての要求を生成して送信し、初期ＩＮＩＴ交換メッセージ１１２、１１４を含む以前のＭＡ関連のすべての応答を受信したことを認めさせることに相当する。

【0023】

ホスト所有者は、以前の要求に関連する秘密を明らかにすることによって、要求を認証する。これは、ホスト所有者が実際に同一の送信者であることの「証明のチェーン」を作成することになる。秘密は、要求ごとに生成される乱数Ｒにわたる暗号Ｈａｓｈであってもよい。

【0024】

ホスト所有者は、対称認証鍵で要求に署名し、この対称認証鍵は応答メッセージごとにピア（すなわちＣＮ）によって更新される。このことは、ホストが以前のすべての応答を受信したことを証明する。このようにして、メッセージは連結され、システムのセキュリティをもたらす。メッセージを連結することで、ｉ番目のメッセージの送信者がセッションの第１のメッセージの送信者と同一であることが証明される。

【0025】

図２は、概ね２００で示される、１つのＭＡをサポートするモビリティセッションのＩＮＩＴハンドシェークを示す。ＭＡ所有者、またはホスト所有者は、たとえば、ピアＣＮ２２０を持つＭＮ２１０である。

【0026】

２３０において、ＭＮ２１０は、ＭＡ識別子ＭＩＤを生成して、キャッシュに入れる。ＭＩＤ２３０は、乱数であってもよい。２４０において、ＭＮ２１０はまた、乱数、またはナンスＲ_０を生成して、キャッシュに入れる。次いで、ＭＮ２１０は、要求ＭＩＤ、Ｈａｓｈ（Ｒ_０）、２５０でＣＮ２２０に送信する。２６０において、ＣＮは、Ｒ_０をキャッシュに入れる。次いで、２７０において、ＣＮは、ランダム鍵Ａ_０を生成して、キャッシュに入れる。次いで、ＣＮは、ＭＩＤおよびランダム鍵Ａ_０を、オープンにＭＮ２１０に送信する。次いで、ＭＮ２１０は、Ａ_０をキャッシュに入れる。

【0027】

Ｒ_０およびＡ_０はいずれも、乱数でなければならない。ＭＮはＨａｓｈ（Ｒ_０）しか送信しないので、メッセージを盗聴している敵対者は、Ｒ_０自体を推測することができない。対応するハッシュ関数は、たとえば、ＳＨＡ１、ＳＨＡ２５６のような任意の適切なハッシュ関数、または任意の他の適切なハッシュ関数であってもよい。ピアが初期鍵Ａ_０をオープンに返すことに留意されたい。このようにして、ＭＮが以前のメッセージを送信したことを、ＭＮはメッセージごとに証明する。

【0028】

ＭＩＤにより、ノードは、メッセージが異なるＩＰアドレスから着信する場合であっても、送信側ピアおよびモビリティセッションを認識することができる。現在のシナリオにおいて、ＭＡごとに１つのＭＩＤが導入される。また、単に、モビリティセッションあたり１つの共通ＭＩＤを使用することも可能である。モビリティおよびマルチホーミングプロトコルは通常、そのような特性を含む。

【0029】

図３に示されるように、システムはここで、ｉ番目のバインディング更新（ＢＵ）ハンドシェークを実行することができる。

【0030】

インデックスｉ−１は、前のＢＵを示し、また、ｉ＝１に対してはＩＮＩＴを示す。ＢＵハンドシェークはまた、たとえば図４に関して後段に示される特定のプロトコル実施に依存する、ＭＮの新しいＩＰアドレスのような、モビリティイベントに関連するパラメータも含む。

【0031】

図３を参照すると、ＨＭＡＣ（Ａ｜ＭＳＧ）という用語は、鍵Ａに基づき、メッセージ本文全体に適用されるハッシュベースの、または任意の他の種類のメッセージ認証コード（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）を表す。ＨＭＡＣは、たとえば、ＳＨＡファミリーメンバーに基づいてもよい。＋符号は、ビット単位のＸＯＲ演算を示す。たとえば、グループ内の追加など、入力のいずれか１つがランダムである場合に結果を完全にランダム化する任意の他の演算が、選択されてもよい。ＸＯＲ演算は、その効率性で選択された。

【0032】

概ね３００で示されるように、バインディング更新（ＢＵ）ハンドシェークは、図２の初期ハンドシェークにより得られたパラメータを使用して、ＢＵを生成する。３１２において、ＭＮ３１０は最初に、乱数Ｒｉを生成して、キャッシュに入れる。次いで、３２０において、ＭＮ３１０は、要求ＭＩＤ、Ｒ_ｉ−１、Ｈａｓｈ（Ｒｉ）、ＨＭＡＣ（Ａ_ｉ−１｜ＭＳＧ）をＣＮ３３０に送信する。ＭＮが前のメッセージを送信した同一のホストであることを確認することができるように、ＣＮ３３０は、３４０においてＨａｓｈ（Ｒ_ｉ−１）のキャッシュを確認し、３５０においてＨＭＡＣ（Ａ_ｉ−１｜ＭＳＧ）を確認する。

【0033】

次いで、３６０において、ＣＮ３３０は、新しいランダムナンスのＨａｓｈＲｉをキャッシュに入れる。これにより、ＭＮは、後続のＫＵハンドシェークで証明を繰り返すことができる。受動的な攻撃者はナンスＲｉを計算することができないので、ハッシュ保護チェーンに打ち勝つことができるのは能動的な攻撃者だけである。３７０において、ＣＮ３３０は、ランダム鍵ｄＡを生成して、３８０においてＡｉ＝Ａ_ｉ−１＋ＤＡをキャッシュに入れる。ＣＮは、ＭＮが増分を受信するように、次の演算でｄＡのみを転送する。

【0034】

次いで、ＣＮ３３０は、３９０において示されるように、たとえばＭＩＤ、ｄＡ、ＨＭＡＣ（Ａ_ｉ−１｜ＭＳＧ）のような応答をＭＮ３１０に送信することができる。次いで、３９５において、ＭＮ３１０は、Ａｉ＝Ａ_ｉ−１＋ｄＡをキャッシュに入れることができる。ＣＮがランダム鍵の増分しかＭＮに転送しないので、攻撃者は、すべてのメッセージを取得するためにセッション中ずっと居続けなくてはならないか、または鍵が何であるかを知る必要がある。インデックスｉ−１は、前の鍵更新、またはｉ＝１の場合のＭＡ確立を示す。Ｒｉ−１、ＨａｓｈＲｉシーケンスは、時間内に連結されたチェーンが確立されることを保証し、これはＭＮがすべての以前のメッセージの送信者であることを証明する。

【0035】

図３に示される、セキュリティメカニズムまたは連結チェーンの保護を破るために、攻撃者は、ＭＮからＣＮへのリンクを盗聴し、ＭＮのＩＰアドレスをスプーフィングしながら、ＭＮから次のＢＵが着信するまで待ってこのメッセージの伝搬を止め、Ｈａｓｈ（Ｒｉ）の新しい自選の値を持つこのメッセージのコピーを再度差し入れる必要があり、ＩＮＩＴ以降にＭＮに宛てられたＣＮからのすべてのパケットをリッスンしてＡ_ｉ−１の知識を得て偽造した要求に署名する必要がある。

【0036】

ＭＮはまた、ＣＮに送信された各鍵更新を鍵Ａｉ−１で署名し、基本鍵Ａ_０はＭＡ確立中にＣＮによってＭＮに送信される。Ｒｉ−１、ＨａｓｈＲｉシーケンスと結合された鍵更新は、ＭＮがＭＡを確立した証明をＣＮにもたらす。

【0037】

図４に示されるように、バインディング更新ＢＵの実施形態は、たとえば、概ね４００で示されるように、ＲＲＴを鍵更新と結合することを含むことができる。４４０において新しいＩＰアドレスを一時的にキャッシュに入れた後、４６０において、新しいＩＰアドレスをキャッシュに入れる前に送信者を確認するため、チャレンジ応答４５０がＣＮ４２０によって生成されてもよい。

【0038】

攻撃者はセッション全体にわたり、またはＩＮＩＴ以降の時間フレームにわたって居続ける必要があり、さらに、ＭＮにより発行された正当なＢＵ要求を待つ必要があるので、ＢＵハンドシェークのチェーンは、さらに高いレベルの保護をもたらす。

【0039】

ＣＮの応答はさらに、更新された鍵Ａ_ｉ−１によって署名される。このＨＭＡＣは、攻撃者が鍵Ａを破ってＨａｓｈ（Ｒ_ｉ）を書き換えた場合には、追加のセキュリティを提供しない。しかし、これは、ＭＮがＭＡ自体へのＤｏＳ攻撃を軽減できるようにする。つまり、ＨＭＡＣがなければ、一時的な攻撃者は、任意の鍵更新を送信することによりモビリティ接続を容易に破ることもできる。

【0040】

上記のＢＵメッセージのうちの１つが失敗する場合、ＢＵハンドシェークは完全ではない。この場合、ＭＮは、ＢＵを再送信する必要がある。再送信されるメッセージは、以前のメッセージの正確なコピーでなければならない。ＣＮは確かに以前のメッセージを受信したが応答が失われた場合、ＣＮは、再送信されたメッセージに含まれるＨａｓｈ（Ｒ）値がすでに保持している値と同じであることを認識する。これにより、ＣＮは、新しいＢＵメッセージと再送信されたＢＵメッセージを区別することができる。ＣＮは、以前の応答で送信したものと同じｄＡで再送信に応答する必要がある。この目的のため、ＣＮは、応答が送信された後の一定期間ｄＡをキャッシュに入れる必要がある。

【0041】

すべてのＢＵが新しい秘密を含み、ソリューションは敵対者には知られていないので、上記のＢＵ交換はまた、リプレイ攻撃に対しても保護される。ＣＮが応答を再送信として受け入れるよう期待して敵対者がＢＵ要求をリプレイする場合、ＣＮはリプレイされたＢＵ要求と元のＢＵ要求との内容不一致を検出して、リプレイされたメッセージを廃棄することができる。

【0042】

ＨＭＡＣは単に、ＭＮが鍵Ａｉ−１のその知識を表明する証明としての役割を果たすだけなので、ＢＵ要求の内容全体をカバーする必要はない。これは、ネットワークアドレス変換機構（ＮＡＴ：ｎｅｔｗｏｒｋ ａｄｄｒｅｓｓ ｔｒａｎｓｌａｔｏｒ）の背後から送信されるＢＵ要求にとっては重要であり、ここではパケットのソースアドレスがＮＡＴによって変更され、ＣＮがパケットヘッダ自体からＭＮの新しいＩＰアドレスを取り出す必要がある。したがって、本発明のセキュリティソリューションは、ＮＡＴに準拠する。

【0043】

モビリティセッションのいずれのホストもモバイルである場合、各ホストは各自のＭＡをサポートするように構成されてもよく、初期ハンドシェークは引き続き、たとえば図５に示されるような両方向メッセージ交換に組み入れられてもよい。セッションは、二重モビリティセッションと称されてもよく、各ホストは各自のＭＡを所有する。ＭＡ確立および鍵更新は対称的に実行されてもよく、各ＭＡに関連する対応するハンドシェークはメッセージに混ぜ入れられてもよいが、これは送信されるべきメッセージの数を減らすことになる。

【0044】

概ね５００で示されるように、たとえばホスト１ ５１０およびホスト２ ５２０のような各ホストは、ランダムナンスおよびランダム鍵を生成して、キャッシュに入れることができる。ホスト１は、ランダムナンス５３０およびランダム鍵５４０を生成して、５５０において、ホスト２ ５２０に送信する。次いで、ホスト２ ５２０は、ホスト１からのナンスおよび鍵を、それぞれ５６０および５７０においてキャッシュに入れる。次いで、ホスト２は、第２のランダムナンス５８０および第２のランダム鍵５９０を生成して、５９５において、ホスト１に送信する。

【0045】

ホスト１のＭＡのＲ１_０およびＡ１_０のそれぞれのパラメータは、ホスト２のＭＡのＲ２_０およびＡ２_０である。ホスト１は、ホスト２がモバイルであると仮定して、事前対応的にＩＮＩＴ要求でＡ２_０を渡す。ホスト２がモバイルではない場合、ホスト１は単にこのパラメータを無視して、上記の以前のＩＮＩＴ交換に示されるように続行する。それ以外の場合、ホスト１は、すべての演算を実行して、図５に示されるパラメータのようなパラメータを渡す。

【0046】

ＩＰアドレスは対称的には生じることはないので、バインディング更新は、それぞれのＭＡに対して各ホストごとに個別に処理されるが、鍵交換は対称的に生じうる。さらに、シーケンス番号がＢＵに対して使用される場合、各ＭＡはそのそれぞれのシーケンス番号をサポートする必要がある。加えて、２つのＭＡは、同じＭＩＤを共有することができる。その結果のハンドシェークは、たとえば図５の実施形態に示されるものであってもよい。

【0047】

敵対者がモビリティ信号伝達を使用してフラッディング攻撃を実施する場合、敵対者自身がモビリティセッションを確立するので、ＢＵメッセージをセキュリティ保護することでは攻撃に対する防御を行なうことにならない。したがって、追加のセキュリティメカニズムが必要とされる。好ましくは、追加のシステムは、図６に示されるバインディング検査（ＢＴ）のような、単純なルーティング可能性検査を使用する。

【0048】

ＭＮがＭＡを保持するホストであると仮定して、ＢＴハンドシェークは、ＭＮが新しいＩＰアドレスを通知するとＣＮによって開始される。ＢＴハンドシェークは、ＢＵ要求が古いアドレスから送信された場合であっても、ＭＮの新しいアドレスを伴う必要がある。ＣＮが複数のＩＰアドレスを維持する場合、ＭＮが新しい場所で到達されうることを保証するので、ルーティング可能性検査に対してそれらのうちの１つだけを使用すれば十分である。すべてのＣＮのＩＰアドレスからＭＮの新しいアドレスへのルーティング可能性検査を実施する技術的な理由があってもよい。たとえば、そのような手順は特定のパスの可用性を決定することができる。

【0049】

ルーティング可能性検査は、６００において概ね示される、ＣＮによりＭＮに送信されるチャレンジを伴う。ＣＮ６１０は、ＭＮ６２０によって応答で回答される必要があるチャレンジを送信する。ＣＮ６１０は、より大量のトラフィックをＭＮ６２０の新しいＩＰアドレスに送信する前に、ＢＴハンドシェークの完了を保証する必要がある。

【0050】

ホスト１および２は、任意の適切なホストであってもよい。たとえば、ホスト１および２がモバイルである場合、ホストは、たとえばサーバ、ラップトップ、ＰＣ、スマートフォン、テレビジョン、ＰＤＡ、ゲーム機、プッシュツートークデバイス、および周辺デバイスのような、適切なモバイルデバイスであってもよい。

【0051】

図６に示されるように、ＢＴハンドシェークは、ＢＵハンドシェークに組み入れられてもよい。６３０において、チャレンジメッセージは乱数Ｘを含む。６４０において、応答は、現行鍵Ａ_ｉ−１に基づくＸの署名を含む。これは、ＭＮ６２０が新しく通知されたＩＰアドレスで到達可能であり、ＢＴ応答６４０が偽造されたものではないことをＣＮ６１０に確認する。

【0052】

図７は、初期ＩＰアドレスからＢＵ要求を送信して新しいＩＰアドレスを通知するマルチホーミングＭＮのための７００において概ね示されるメッセージフローを示す。ＢＴハンドシェークはＭＮの新しいＩＰアドレスを使用するが、エンベロープＢＵハンドシェークはＭＮの初期ＩＰアドレスを使用する。チャレンジメッセージ７１０は、ここでは単信モビリティセッションで応答するために鍵署名が必要とされないように、ＨＭＡＣ（Ｂ_ｉ｜ＭＳＧ）によって保護される。

【0053】

図６および図７は例示的な実施形態に過ぎず、同じ原理の保護をもたらすルーティング可能性検査を実施するその他の方法もあるので、ルーティング可能性検査が本明細書の原理に従って実行されうる方法を限定することを意図してはいない。

【0054】

加えて、ＭＮは、ＭＡ鍵更新ハンドシェークをＣＮとのすべてのデータ交換に組み入れる必要がある。インデックス_ｉの鍵更新は、たとえば、図８に示されるように、鍵更新をバインディング更新に組み入れることを含むことができる。ＲＲＴは１つのＭＡに対してしか実行されないが、鍵交換は対称的に実行されてもよい。乱数の長さ、すなわち秘密Ｒ、鍵Ａ、およびチャレンジＸは、力づくによる攻撃に注意を向けるのに十分な大きさで選択される必要がある。力づく方式を通じてこれらの数を解読する平均尤度は、２^{（Ｌ−１）}により与えられ、Ｌは対応する数のビット長である。Ｌ＝５０から６０ビットの値は、現在および近い将来の計算能力を考慮すれば、十分過ぎるほどである。

【0055】

本明細書の原理によれば、ＭＳは、ＭＡ確立中またはＭＡ確立後に確立された接続のホストベースのモビリティセキュリティのみを提供する。その結果、ＭＮおよびＣＮは、ＭＡの下で移行されうる接続を指定するＭＡごとにテーブルを保持する必要がある。テーブルにおいて、接続は、｛プロトコルタイプ、ソースＩＰアドレス、宛先アドレス、ソースポート番号、宛先ポート番号｝を含む５タプルを介するような、適切な方法で指定されてもよい。ＭＡを確立する前にＭＮとＣＮ間で保持された接続は、テーブルに追加されることはなく、ＭＡが確立された後の新しい接続だけが追加される。

【0056】

本明細書の原理によれば、トラフィック接続（複数可）とＭＡまたはＭＡペアとの間の１対１のマッピングを有することが可能である。この場合には、ＭＡまたはＭＡペアに関連付けられているすべての情報は、トラフィック接続のプロトコル制御ブロックに保持されうるので、接続テーブルは必要ではなくなる。

【0057】

加えて、接続のサブセットに指定されたポリシーまたはＩＰアドレス、あるいはその他の関連情報のような、すべての非セキュリティ関連のメッセージングは、ＭＡ内のＫＵおよびＢＵハンドシェークに結合処理されてもよい。

【0058】

図９に示されるように、モビリティセッションは、ＭＮとＣＮ間の接続を攻撃者に占有されないように、トラフィック接続に適正に連結される必要がある。この脆弱性を回避するため、モビリティセッションは、トラフィック接続の形成と同時、またはそれに先だって開始される必要がある。さらに、トラフィック接続のＩＰアドレスとモビリティセッションのＩＰアドレスは同一でなければならない。加えて、モビリティセッションは、対応するトラフィック接続が終了したら直ちに終了する必要がある。そうすることで、ＭＮとＣＮ間の将来のトラフィック接続をハイジャックするために、敵対者が、ＭＮのアドレスをスプーフィングしてＣＮとのモビリティセッションを先手を取って作成することを防止する。

【0059】

ホスト間の信号伝達は、たとえばＵＤＰのような、適切な方法を介して実行されてもよい。たとえば、ＨＩＰに対して行なわれたように、新しいプロトコルタイプもまた、この目的のために導入されてもよい。さらに、メッセージは、たとえばＴＣＰ移行により、提案されたようにパケットヘッダを介してトラフィック接続に多重化されてもよい。

【0060】

本明細書の原理によれば、トランスポート接続システムは、
メッセージを送信および受信するように構成された第１のデバイスと、メッセージを送信および受信するように構成された第２のデバイスとを備え、第１のデバイスにより生成されたメッセージｉは、前のメッセージｉ−１で第１のデバイスから第２のデバイスに送信されたＨａｓｈ（Ｒｉ−１）への秘密Ｒｉ−１を含み、メッセージｉはランダム鍵Ａｉ−１により署名され、ランダム鍵は鍵Ａｉ−２の更新から導かれており、前のメッセージｉ−１は鍵Ａｉ−２により署名される。第１のデバイスは、以前のネットワークロケーションにおいて維持された前のメッセージを通じて第２のデバイスとの関連を証明するために、異なるネットワークロケーションからメッセージを送信することができる。

【0061】

コレスポンデントノード（ＣＮ）に選択的に接続するように構成されたモバイルノードは、メッセージを生成するためにモビリティノード（ＭＮ）に動作可能に接続されたプロセッサを含むことができ、メッセージｉは、ＭＮによって生成されキャッシュに入れられた新しいランダムＲｉの暗号化ハッシュ、前のメッセージのランダムＲｉ−１、およびＣＮから受信した鍵に基づくＭＡＣを含む。

【0062】

ネットワークにわたりトランスポート接続を維持する２つのホスト間のセキュリティプロトコルを操作する方法は、メッセージを生成および受信するために、モビリティノードＭＮを提供するステップと、ＭＮからのメッセージを生成、認証、および受信するために、ＭＮをコレスポンデントノードＣＮに選択的に接続するステップと、ＭＮにおいてランダムナンスＲ_ｉ−１を引き継がれた第１の暗号ハッシュを含む第１のＭＮメッセージを生成して、ＭＮにおいてランダムナンスＲ_ｉ−１をキャッシュに入れるステップと、セッション中に、ナンスＲ_ｉ−１の第１の暗号ハッシュを含む第１のＭＮメッセージをＣＮに送信するステップと、ＣＮによりランダムナンスＲ_ｉ−１の第１の暗号ハッシュをキャッシュに入れるステップと、ＣＮにおいてランダム鍵を含む第１のＣＮメッセージを生成して、ＣＮにおいてランダム鍵をキャッシュに入れるステップと、ランダム鍵を含む第１のＣＮメッセージをＭＮに送信するステップと、ＭＮにおいてランダム鍵をキャッシュに入れるステップと、ＭＮにより新しいランダムナンスＲｉを生成するステップと、第２のＭＮメッセージをＭＮからＣＮに送信するステップであって、第２のＭＮメッセージは新しいランダムナンスＲｉの暗号ハッシュ、ランダムナンスＲ_ｉ−１、およびＣＮによりＭＮに提供されるランダム鍵に基づくＭＡＣを含むステップとを含み、鍵の反復を含むＭＮとＣＮ間の連結されたメッセージのチェーンは、ＭＮがセッション所有者であることを認めさせる。

【0063】

方法はまた、ＣＮにより第２のＭＮメッセージを受信するステップと、ＣＮにおいてランダムナンスＲ_ｉ−１のハッシュを確認するステップと、ＣＮにおいてランダム鍵のＨＭＡＣおよび関連するメッセージを確認するステップと、ＣＮにおいて新しいランダムナンスＲｉの暗号ハッシュをキャッシュに入れるステップと、ＣＮにおいてランダム鍵ｄＡを作成してキャッシュに入れるステップと、ＣＮにおいてランダム鍵にランダム鍵ｄＡを加えたものと同等の新しい鍵をキャッシュに入れるステップと、ランダム鍵ｄＡおよびランダム鍵に基づくＭＡＣをＭＮに転送するステップとを含むこともできる。

【0064】

方法はまた、ＭＮから後続のメッセージを受信した後、ランダム鍵ｄＡｉの後続の増分をＭＮに送信するステップを含むこともできる。

【0065】

ＭＮは、接続ポイントにおいてネットワークノードに動作可能に接続された周辺デバイスによってさらに定義されてもよく、周辺デバイスはＩＰアドレスを有する。

【0066】

ランダムナンスＲ_ｉ−１は、初期ナンスであってもよい。

【0067】

ＣＮからＭＮへの各メッセージは、前のナンスを含む戻りメッセージ本文の少なくとも一部にわたりＭＡＣを含むことができる。

【0068】

ＭＡＣは、ハッシュベースのＭＡＣによってさらに定義されてもよい。

【0069】

戻りメッセージ本文は秘密を含むことができ、ＣＮからＭＮへの各メッセージのＭＡＣは、前のナンスおよび秘密をカバーすることができる。

【0070】

セッションは、トランスポート接続の形成の前、または形成と同時に開始することができる。

【0071】

セッションは、ＭＮとＣＮ間で維持された複数のトランスポート接続のトランスポート接続の形成の前、または形成と同時に開始することができる。

【0072】

セッションは、ＭＮとＣＮ間のトランスポート接続の少なくとも１つ、および複数のトランスポート接続が終了した後に終了することができる。

【0073】

第２のトランスポート接続は、ＣＮからＭＮに形成されてもよく、ＣＮは、第２のトランスポート接続を介してセッション中にその接続ポイントへの変更でＭＮを更新することができる。

【0074】

方法は、ＣＮにおいてネットワーク接続ポイント変更メッセージを受信するステップをさらに含むことができ、ＣＮは、さらにメッセージを処理する前に、ランダムナンスＲ_ｉ−１を引き継いだ第１の暗号ハッシュが、ネットワーク接続ポイント変更メッセージに含まれているランダムナンスＲ_ｉ−１と同一であるかどうかを確認する。

【0075】

方法はまた、ＣＮにおいてランダム鍵更新に含まれるＭＡＣを確認するステップを含むこともできる。

【0076】

ホストのうちの少なくとも１つは、サーバ、ラップトップ、ＰＣ、スマートフォン、テレビジョン、ＰＤＡ、ゲーム機、プッシュツートークデバイス、および周辺デバイスのうちの少なくとも１つによりさらに定義されてもよい。

【0077】

方法は、ＭＮとの複数の物理または論理Ｌ２インターフェイス接続を提供するステップをさらに含むことができ、複数のインターフェイスの各インターフェイスは個々のＩＰアドレスをサポートする。

【0078】

方法は、複数のＩＰアドレスをサポートするＭＮとの１つの物理または論理Ｌ２インターフェイス接続を提供するステップをさらに含むことができる。

【0079】

方法において、ＭＮおよびＣＮはトランスポート接続のサブセットを維持することができ、更新をトランスポート接続のサブセットのうちの１つに適用するステップをさらに備える。

【0080】

方法において、複数のＩＰアドレスのうちの１つはアクティブなＩＰアドレスであり、ＭＮは、アクティブなＩＰアドレスのアイデンティティが変化した場合、第２のメッセージでＣＮを更新する。

【0081】

本明細書の原理によるモビリティノード（ＮＭ）は、メッセージを生成および受信するために、モビリティノード（ＭＮ）に動作可能に接続されたプロセッサを含むことができ、プロセッサは、モビリティノードのＩＰアドレスが変化した場合、ＩＰアドレス更新をコレスポンデントノード（ＣＮ）に送信するための信号伝達メッセージを生成することができ、信号伝達メッセージは、ランダム鍵のハッシュおよび秘密を含み、認証コード（ＭＡＣ）は信号伝達メッセージの少なくとも一部に適用される。

【0082】

ＭＮは、ＵＳＢメモリストレージデバイスに動作可能に接続されたプロセッサを有することができ、ＵＳＢメモリストレージデバイスは、プロセッサと共に信号伝達メッセージを生成、送信、受信、および格納するための自動実行アルゴリズムを含むことができる。

【0083】

モビリティノード（ＮＭ）とのモビリティアソシエーション（ＭＡ）を容易にするためにコレスポンデントノード（ＣＮ）は、モビリティノードから鍵および秘密を含むメッセージを受信、確認、および生成するためのＣＮに動作可能に接続されたプロセッサを含むことができ、認証コード（ＭＡＣ）はメッセージの少なくとも一部に適用され、ＣＮはＭＮからのすべての以前のメッセージを確認する。

【0084】

セキュリティプロトコルは、ネットワークにわたりトランスポート接続を維持する２つのモバイルホストに、動作可能な接続で提供され、２つのモバイルホスト間で交換されてもよい。セキュリティプロトコルは、コレスポンデントノード（ＣＮ）へのトランスポート接続を形成するモビリティノード（ＮＭ）を含むことができ、ＭＮは第１のモバイルホスト（ＦＭＨ）であり、ＣＮは第２のモバイルホスト（ＳＭＨ）であり、ＣＮはＭＮへの第２のトランスポート接続を形成し、ＦＭＨおよびＳＭＨはいずれも、セッション中または時間フレーム内に、信号伝達メッセージを介して、それぞれ第１および第２のトランスポート接続経由で接続ポイントの変更に関する更新を選択的に送信し、信号伝達メッセージは、秘密番号の暗号ハッシュを採用するナンス更新であって、秘密番号は、信号伝達メッセージがセッションに対して生成された最初のメッセージである場合を除いて、前のメッセージのナンスを生成するために使用されるナンス更新と、ＦＭＨおよびＳＭＨによりセッション中に合意された鍵を含む信号伝達メッセージの少なくとも一部に適用される認証コード（ＭＡＣ）とを含む。

【0085】

セキュリティプロトコルは、ネットワークにわたりトランスポート接続を維持する２つのモバイルホストに、動作可能な接続で提供され、２つのモバイルホスト間で交換されてもよく、ＦＭＨは第１のトランスポート接続のための第１の独立鍵（ＦＩＫ）を生成し、ＳＭＨは第２のトランスポート接続のための第２の独立鍵（ＳＩＫ）を生成する。

【0086】

本明細書において示されるすべての実施形態は、コンピュータ、携帯電話、ＰＤＡ、テレビジョンなどのような、通信デバイス間の安全な通信を動作可能に容易にするように構成され構築されたシステムおよび方法を介して達成される原理を含む。そのようなものとして、本明細書における各々の例示的なシステムまたは方法は、暗号が通信デバイス間で伝送されうる通信、無線、またはその他のネットワークへの信号の動作可能な接続を考慮する。

【0087】

本明細書における実施形態は、例示の目的のために説明され示されたものに過ぎず、本発明の原理を限定するものとして解釈されるべきではない。変更は当業者には明らかであり、本明細書における原理の精神を逸脱することのないすべての変更は、添付の特許請求の範囲に含まれることが意図されている。当業者であれば、本開示が基にする概念が、本発明の原理の複数の目的を実行するためのその他の構造体、方法、およびシステムの設計ための基礎として容易に活用されうることを理解するであろう。

【0088】

したがって、前述の説明は、本明細書における原理の例示に過ぎないものと見なされる。さらに、多数の変形および変更が当業者には容易に考案されるので、示され説明される厳密な構造体および操作に本原理を限定することは望ましくなく、したがって、本明細書において説明される原理の範囲内に含まれるすべての適切な変更および等価物が用いられてもよい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】