JP2012503945A - Ｈｏｍｅｎｏｄｅ−ｂ装置およびセキュリティプロトコル - Google Patents

Abstract

Ｈ（ｅ）ＮＢ（Ｈｏｍｅ Ｎｏｄｅ ＢまたはＨｏｍｅ ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）装置および方法が開示される。Ｈ（ｅ）ＮＢは、ＴｒＥ（信頼された環境）、ならびに保護されないインターフェイス、暗号で保護されたインターフェイス、およびハードウェア保護されたインターフェイスを含むインターフェイスを含む。Ｈ（ｅ）ＮＢは、Ｈ（ｅ）ＮＢとＳＧＷ（セキュリティゲートウェイ）を含む外部ネットワーク要素との間の通信のためのセキュリティ／認証プロトコルを含む。

Description

本出願は、無線通信に関する。

３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ） ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）プログラムの目的は、より少ないコストで、ユーザ体験をより速くし、アプリケーションおよびサービスをより豊かにするために、スペクトル効率の向上、待ち時間の短縮、および無線リソースのより良い使用を提供する目的で、ＬＴＥ設定および構成の新しい技術、新しいアーキテクチャ、および新しい方法を開発することである。これらの取り組みの一部として、３ＧＰＰは、ＬＴＥネットワークのＨ（ｅ）ＮＢ（ｈｏｍｅ，ｅｖｏｌｖｅｄ ｎｏｄｅ Ｂ）の概念を導入している。３ＧＰＰは、ＷＣＤＭＡ（広帯域符号分割多元接続）のＨＮＢ（ｈｏｍｅ ＮＢ）も検討している。頭字語Ｈ（ｅ）ＮＢは、本出願において、以下Ｈ（ｅ）ＮＢおよびＨＮＢの両方を指すために使用される。

Ｈ（ｅ）ＮＢは、自宅および小規模事業所などの極めて小さいサービスエリアにわたって、ＬＴＥサービスへのアクセスをユーザに提供する（また、ＷＣＤＭＡ、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ） ＧＥＲＡＮ（Ｅｄｇｅ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）、および他のセルラーサービスも提供し得る）。ユーザは、個人であろうと組織であろうと、こうしたサービスが望まれるエリアにＨ（ｅ）ＮＢを配置することができる。Ｈ（ｅ）ＮＢの必須の認証、およびホスティングパーティのオプションの認証のためのＨ（ｅ）ＮＢとＳＧＷ（セキュリティゲートウェイ）との間の認証プロトコルのフレームワークも導入されている。プロトコルは、装置およびホスティングパーティの認証、後のＨ（ｅ）ＮＢとＳＧＷおよびＨＬＲ（ホームロケーションレジスタ）、ＡＡＡ（認証、許可、課金）サーバなど他のコアネットワークエンティティとの間のその他すべての暗号化された（ＩＰｓｅｃ下の）通信のための基本的なフレームワークを提供する。

Ｈ（ｅ）ＮＢ認証の文脈で、様々な可能性をサポートすることに関して（そのうちのどれが選択されるべきか、またはＨｅＮＢと交渉すべきか）、ＳＧＷの機能のインジケータとして、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤおよびＣＥＲＴＲＥＱなどいくつかのＩＫＥｖ２（インターネット鍵交換ｖ２）パラメータも導入されている。しかし、これらのパラメータの使用は、どのタイプの認証を選択することができるかの最終的な選択に関して、結果的に多くの「曖昧な」状況をもたらす。

上記のプロトコルにおいて、およびより具体的には、プロトコルを実行する装置および機器に対して、いくつかのセキュリティ脅威も識別されている。考えられる脅威は、それだけには限定されないが、脆弱な認証アルゴリズムを介した総当たり攻撃によるＨ（ｅ）ＮＢ認証トークンを危険にさらすもの、局所的な物理的侵入によるＨ（ｅ）ＮＢ認証トークンを危険にさらすもの、不正操作されたＨ（ｅ）ＮＢへの有効な認証トークンの挿入、Ｈ（ｅ）ＮＢ認証トークンのユーザの複製、Ｈ（ｅ）ＮＢの最初のネットワークアクセス時の中間者攻撃、不正ソフトウェアによるＨ（ｅ）ＮＢの起動（リフラッシュ）、不正ソフトウェアの更新／構成の変更、Ｈ（ｅ）ＮＢに対する物理的な改ざん、他のユーザのＵＴＲＡＮ（ｕｎｉｖｅｒｓａｌ ｔｅｒｒｅｓｔｒｉａｌ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ）またはＥ−ＵＴＲＡＮ（ｅｖｏｌｖｅｄ ＵＴＲＡＮ）のユーザデータの盗聴、他のユーザへのなりすまし、報告無しのＨ（ｅ）ＮＢ位置の変更、Ｈ（ｅ）ＮＢのソフトウェアシミュレーション、Ｈ（ｅ）ＮＢ間のトラフィックトンネリング、モデム／ルータにおけるファイヤウォールの構成ミス、Ｈ（ｅ）ＮＢに対するＤｏｓ攻撃、コアネットワークに対するＤｏｓ攻撃、アクティブなネットワークサービスの脆弱性を活用することによってＨ（ｅ）ＮＢを危険にさらすもの、ユーザのネットワークＩＤのＨ（ｅ）ＮＢの所有者への暴露、Ｈ（ｅ）ＮＢの構成ミス、ＡＣＬ（アクセス制御リスト）の構成ミスまたはＡＣＬを危険にさらすもの、無線リソース管理の改ざん、有効なＨ（ｅ）ＮＢへのなりすまし、ＣＳＧ（ｃｌｏｓｅｄ ｓｕｂｓｃｒｉｂｅｒ ｇｒｏｕｐ）を介した無線アクセスサービスの提供、Ｈ（ｅ）ＮＢがネットワークに誤った位置を知らせること、外部時間ソースの不正操作、およびＨ（ｅ）ＮＢに対する環境／サイドチャネル攻撃を含む。

また、Ｈ（ｅ）ＮＢの認証に位置情報を使用することも提案されている。固定アクセス回線位置（例えばＨ（ｅ）ＮＢのバックホールポートのＩＰアドレス）、マクロ３Ｇおよび２Ｇセルを含むマクロセルに関する情報、およびＨ（ｅ）ＮＢにおけるＧＰＳ（全地球測位システム）の３つのタイプの位置情報のうちの１つまたは任意の組み合わせを使用することによって、Ｈ（ｅ）ＮＢの位置を突き止めることができる。

位置登録（または証明）のステップおよび位置ベースの認証の後のステップも導入されている。しかし、これらの方法には、Ｈ（ｅ）ＮＢで得られた位置についての情報が、ネットワークに送信される前に装置内でセキュリティ保護されない状態で処理され得るという事実を含めて、いくつかの欠点がある。

ＬＴＥおよび他の無線通信システムにおけるＨ（ｅ）ＮＢの配置は、実装の成功のために対処する必要があるセキュリティ問題をもたらす。したがって、信頼された環境でのＨ（ｅ）ＮＢおよびいくつかの環境においてＵＩＣＣに実装することができるオプションのＨＰＭ（ホスティングパーティモジュール）の認証プロトコルが必要である。

Ｈ（ｅ）ＮＢ（Ｈｏｍｅ Ｎｏｄｅ Ｂおよび／またはＨｏｍｅ ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）装置およびセキュリティ／認証プロトコルが開示される。Ｈ（ｅ）ＮＢは、ＴｒＥ（信頼された環境）、ならびにＨ（ｅ）ＮＢとＳＧＷ（セキュリティゲートウェイ）を含む外部ネットワーク要素との間の通信のためのセキュリティ／認証プロトコルを含む。保護されていないインターフェイス、暗号で保護されたインターフェイス、およびハードウェア保護されたインターフェイスを含めて、ＴｒＥとＨ（ｅ）ＮＢとの間で使用されるインターフェイスも開示される。ＳＧＷとＨ（ｅ）ＮＢとの間のシグナリング規約を含めて認証方法が開示される。

一般に、ＳＧＷは、Ｈ（ｅ）ＮＢが、装置認証に加えて、ホスティングパーティ認証を実行するよう要求されているかどうかをＨ（ｅ）ＮＢに対して示す。また、ＳＧＷは、Ｈ（ｅ）ＮＢが証明書ベースの認証またはＥＡＰ−ＡＫＡ（拡張認証プロトコル−認証鍵合意）ベースの認証を実行するよう要求されているかどうかをＨ（ｅ）ＮＢに対して示す。一実施形態において、ＳＧＷは、ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答で、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤパラメータを使用して認証のタイプを示し、Ｈ（ｅ）ＮＢは、ＩＫＥ＿ＡＵＴＨ要求で、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤパラメータおよびＡＮＯＴＨＥＲ＿ＡＵＴＨ＿ＦＯＬＬＯＷＳパラメータにより認証のタイプを示し、ＳＧＷは、ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答で、ＣＥＲＴＲＥＱパラメータにより装置認証のタイプを示す。別の実施形態において、Ｈ（ｅ）ＮＢは、ＩＫＥｖ２プロトコルを使用して、装置認証のための情報の送信との組み合わせで、ＴｒＥによって実行される装置保全性チェックの結果をＳＧＷに対して示し、それによって共通のプロトコルを使用して、装置妥当性検査および装置認証を実現する。

例として示される以下の説明を添付の図面と併せ読めば、より詳しい理解が得られよう。
システムアーキテクチャ例を示す図である。 Ｈ（ｅ）ＮＢ（Ｈｏｍｅ ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）の機能ブロック図例である。 Ｈ（ｅ）ＮＢにおけるＴｒＥ（信頼された環境）のインターフェイス構成例を示す図である。 Ｈ（ｅ）ＮＢにおけるＴｒＥ（信頼された環境）の別のインターフェイス構成例を示す図である。 認証タイプを決定するためのフロー図例である。 プロファイルベースの認証のフロー図例である。 セキュリティプロトコル例を示す関係図である。 ＥＡＰ−ＡＫＡ（拡張認証プロトコル−認証および鍵合意）の信号図例である。 ＥＡＰ−ＡＫＡ（拡張認証プロトコル−認証および鍵合意）の信号図例である。 装置認証のフロー図例である。 装置およびホスティングパーティ認証のフロー図例である。 装置およびホスティングパーティ認証のフロー図例である。 ３方向のバインドのフロー図例である。 ２方向のバインドのフロー図例である。 ＩＫＥｖ２プロトコルを使用した装置認証、装置保全性チェック、および装置妥当性検査を結合するためのフロー図例である。

以下で言及するとき、「ＷＴＲＵ（無線送受信ユニット）」という用語は、それだけには限定されないが、ＵＥ（ユーザ機器）、移動局、固定式または携帯式の加入者ユニット、ページャ、携帯電話、ＰＤＡ（個人用デジタル補助装置）、コンピュータ、または無線環境で動作することができる他の任意のタイプのユーザ装置を含む。以下で言及するとき、「基地局」という用語は、それだけに限定されないが、Ｎｏｄｅ−Ｂ、サイトコントローラ、ＡＰ（アクセスポイント）、または無線環境で動作することができる他の任意のタイプのインターフェイス装置を含む。

本明細書で開示されているのは、無線通信のためのｈｏｍｅ ｅｖｏｌｖｅｄ ｎｏｄｅ ｂおよびｈｏｍｅ ｎｏｄｅ ｂ（まとめてＨ（ｅ）ＮＢ）を配置するためのシステムおよびアーキテクチャ、およびＨ（ｅ）ＮＢとＳＧＷ（セキュリティゲートウェイ）との間の認証シグナリング、および無線通信を確立するために使用され得る認証方法の説明である。

図１は、Ｈ（ｅ）ＮＢ１１０の配置のためのセキュリティシステムアーキテクチャ１００の例である。Ｈ（ｅ）ＮＢ１１０は、ＳＧＷ１３０を介してオペレータのコアネットワーク１２０にアクセスする。ＳＧＷ１３０は、Ｈ（ｅ）ＮＢ１１０との相互認証を実行する際のオペレータのコアネットワーク１２０を表す。相互認証は、認証サーバまたはＰＫＩ（公開鍵基盤）のサポートを必要とする場合がある。Ｈ（ｅ）ＮＢ１１０とＳＧＷ１３０との間のバックホール１４０は、安全ではない場合があり、バックホールリンク１４０で送信される情報を保護するために、セキュリティトンネルがＨ（ｅ）ＮＢ１１０とＳＧＷ１３０との間に確立されてもよい。Ｈ（ｅ）Ｎ１１０は、エアインターフェイスを介してＷＴＲＵ１５０と通信する。

図２は、Ｈ（ｅ）ＮＢ２００の一実施形態の機能ブロック図を示す。Ｈ（ｅ）ＮＢ２００は、ＴｒＥ（信頼された環境）２１０を含み、オプションで、ＨＰＭ（ホスティングパーティモジュール）２１５に接続される、またはそれと通信する（まとめて「接続される」）ことができる。例えば、ＨＰＭ２１５は、ＵＩＣＣ（ユニバーサル集積回路カード）によって組み込まれ得る。

ＴｒＥ２１０は、安全な実行環境２１２および安全格納エリア２１４をさらに含む。ＴｒＥ２１０は、ＭＰＵ（主処理装置）／アプリケーションプロセッサ２２０、１つまたは複数のＵＭＴＳ（ユニバーサル移動体通信システム）セルラーモデムプロセッサ２２５、電力ユニットおよびローカルインターフェイスを含む周辺装置２３０、位置決め装置２４０、１つまたは複数の非ＵＭＴＳセルラーまたは非セルラーのモデムプロセッサ２４５、およびクロックおよびタイム装置（ｃｌｏｃｋ ａｎｄ ｔｉｍｅ ｄｅｖｉｃｅ）２５０にさらに接続される。本明細書に列挙されている構成要素は例示であって、Ｈ（ｅ）ＮＢ２００は、構成要素のすべてまたは一部、および他の構成要素を含んでいてもよい。

ＭＰＵ２２０は、ＵＭＴＳセルラーモデムプロセッサ２２５、周辺装置２３０、位置決め装置２４０、非ＵＭＴＳセルラーまたは非セルラーのモデムプロセッサ２４５、およびクロックおよびタイム装置２５０にさらに接続される。ＭＰＵ２２０はＨＰＭ２１５にも接続され得る。位置決め装置２４０は、クロックおよびタイム装置２５０ならびにＵＭＴＳセルラーモデムプロセッサ２２５にさらに接続される。また、ＵＭＴＳセルラーモデムプロセッサ２２５は、ＰＡ（電力増幅器）／ＲＦ（無線周波数）モジュール２６０に接続され、これは次いでアンテナユニット２７０に接続される。ＨＰＭ２１５もＵＭＴＳセルラーモデムプロセッサ２２５に接続され得る。また、開示されているように、ＨＰＭ２１５は、Ｈ（ｅ）ＮＢ２００に含まれていてもよい。ＨＰＭ２１５が含まれるとき、ＨＰＭ２１５は、その構内においてＨ（ｅ）ＮＢ２００をホストするエンティティであるホスティングパーティのＡＫＡ（認証および鍵合意）ベースの認証サービスを提供する。ＨＰＭ２１５は、ＵＭＴＳモバイルネットワークオペレータの代わりに、ホスティングパーティの認証を実行することができる。

ＴｒＥ２１０は、Ｈ（ｅ）ＮＢ２００に物理的および論理的にバインドされ、Ｈ（ｅ）ＮＢ２００内の信頼されるエンティティとして動作し、Ｈ（ｅ）ＮＢ２００のアンカーを提供する。安全格納エリア２１４は、鍵、秘密、および他の機密データおよびプログラムの安全格納エリアを提供する。安全な実行環境２１２は、ＵＭＴＳネットワークに対するＨ（ｅ）ＮＢ２００のＡＫＡおよび証明書ベースの認証、およびＳＧＷの認証、およびそれを介したＵＭＴＳネットワークの認証を実行する環境を提供する。安全な実行環境２１２は、ＴｒＥ２１０が、本明細書に開示されるようないくつかのタスクを実行できるようにする。

例えば、ＴｒＥ２１０は、ＵＭＴＳおよび他のインターフェイスを介したデータおよびトラフィックの暗号化および解読などの他のセキュリティセンシティブな操作、およびＭＰＵ２２０の代わりに、およびＭＰＵ２２０とは無関係に、セキュリティセンシティブなプログラムおよびデータ操作の実行を行う。また、ＴｒＥ２１０は、ＳＧＷを介してネットワークに、それ自体、またはＨ（ｅ）ＮＢ２００の他の任意の構成要素もしくはその操作の妥当性を安全に示すことに関するすべてのタスクを実行することもできる。

また、ＴｒＥ２１０は、ＴｒＥ２１０がそれ自体、ならびにＭＰＵ２２０のハードウェアおよびソフトウェア（プログラムおよびデータを含む）、含まれている場合はＨＰＭ２１５、セルラーおよび非セルラーのモデム２２５および２４５、および他の周辺装置２３０およびインターフェイスを含めて、Ｈ（ｅ）ＮＢ２００の残りの妥当性（信憑性および／または保全性）をチェックする妥当性検査の操作を実行することもできる。ＴｒＥ２１０は、その妥当性チェックを介して無効な構成要素またはサブエンティティを検出すると、安全な順序付きの１組の（それ自体およびＨ（ｅ）ＮＢ２００の残りの）ロックダウン操作および／または（ロックダウン前のネットワークへの）報告操作を実行する。

ＴｒＥ２１０はさらに、プログラムおよび証明書を含むデータを保護することができ、位置決め装置ならびにクロックおよびタイム装置の妥当性検査を行い、その両方は、ネットワークによってＨ（ｅ）ＮＢ２００を許可することができる前、またはＨ（ｅ）ＮＢ２００がネットワークへの操作接続を確立する許可が与えられる前に必須である。ＴｒＥ２１０は、セキュリティセンシティブな任意の装置管理およびセキュリティセンシティブなデータまたはプログラムのＯＴＡ（無線の）タスクを実行することもできる。ＴｒＥ２１０は、Ｈ（ｅ）ＮＢ２００および／またはその個々の構成要素／サブエンティティ、またはそれ自体のセキュリティポリシーまたはセキュリティ制御を保護し、監視し、実行することができる。ＴｒＥ２１０は、それと、Ｈ（ｅ）ＮＢ２００および／またはネットワークエンティティ、例えばＨＰＭ、ＳＧＷ、ＡｕＣ（認証センター）もしくはＨＬＲ（ホームロケーションレジスタ）などの中の任意の他の構成要素との間の安全なチャネルをセットアップし、維持する（解体も含む）こともできる。ＴｒＥ２１０はさらに、内部セキュリティ操作のために、またはＳＧＷとの（装置および／またはホスティングパーティ認証のためのものを含む）バックホール通信を含めて外部通信のために、こうした他の構成要素に渡す必要のある任意のデータを格納し、保護し、抽出し、更新し、（Ｈ（ｅ）ＮＢ２００内の他の構成要素に）安全に提供することができる。

図２から明らかなように、ＴｒＥ２１０は、いくつかのＨ（ｅ）ＮＢ２００の機能構築ブロックと対話して、認証など、所望の機能を安全に実行する必要がある。必要な接続を確立するために、ＴｒＥ２１０は、Ｈ（ｅ）ＮＢ２００内のこうした機能およびリソースへの様々なインターフェイスへのアクセスを有していなければならない。ＴｒＥ２１０のこれらのインターフェイスは一般に、ＴｒＥ２１０の機能であり、これらは、ＴｒＥ２１０の安全な起動プロセスで開始され、したがって、正しく動作すると見なされる。こうした前提に基づいて、Ｈ（ｅ）ＮＢ２００の安全かつ効率的な設計を確立するために、そのセキュリティプロパティに関して、ＴｒＥ２１０を分析することができる。

一実施形態において、保護されていないインターフェイス、暗号で保護されたインターフェイス（安全なチャネル）、およびハードウェア保護されたインターフェイスを含む、ＴｒＥインターフェイスの３つの広範なセキュリティカテゴリがある。

保護されていないインターフェイスは、ＴｒＥ２１０と、改ざんおよび／または盗聴に対してセキュリティ保護されていると見なされないＨ（ｅ）ＮＢ２００の一般的なリソースとの間の通信を容易にする。それにも関わらず、保護されていないインターフェイスは、例えばＴｒＥ２１０が関係する鍵素材を所有し、セキュリティ保護されたメモリに後者を格納するとき、ＴｒＥ２１０によって暗号で保護されたデータへのアクセスを与えることができることに留意されたい。

暗号で保護されたインターフェイス（安全なチャネル）は、暗号化された通信を提供するセキュリティプロトコルによって保護される。さらに、これらは、ＴｒＥ２１０が通信するエンティティの認証および追加の所望の機能、例えばメッセージの認証などを追加で提供する安全なチャネルを確立することができる。

ハードウェア保護されたインターフェイスは、例えばサイドチャネル攻撃に対する対策など、攻撃に対する物理的な保護を提供する。

Ｈ（ｅ）ＮＢ２００の実施形態は、特定のＴｒＥインターフェイス構成の選択について関連する様々な態様を考慮に入れる。保護されていないインターフェイスは、通信側エンティティが伝えられるデータの保護を提供しないときに選択され得る。一例は、通信プロトコルで使用される一時的な秘密（ｅｐｈｅｍｅｒａｌ ｓｅｃｒｅｔ）とすることができる。暗号で保護されたインターフェイスは、ＴｒＥ２１０が通信するリソースが運ばれた情報への平文アクセスを必要とするとき、およびそれがその何らかの保護を提供することができるときに選択され得る。ハードウェア保護されたインターフェイスは、一般にＴｒＥ２１０をハードウェア保護されたリソースに接続して、システム全体の保護レベルを維持する。

図３は、Ｈ（ｅ）ＮＢ３００におけるＴｒＥ３１０のインターフェイス構成の一実施形態を示す。この例において、ＴｒＥ３１０は、シン構成をしており、これは、装置認証にＡＵＴＨ（認証部分）およびＲＥＳ（結果）モジュール３１２を使用して、Ｅｘｔｅｎｓｉｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｍｅｔｈｏｄ ｆｏｒ ＵＭＴＳ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ（ＥＡＰ−ＡＫＡ） ＲＥＳおよびＡＵＴＨパラメータを計算する機能を含めて、それ自体の中に相対的に限定された機能を有し、Ｈ（ｅ）ＮＢ３００の妥当性検査機能３１４を使用して妥当性検査を実行することを意味する。次いでＴｒＥ３１０は、Ｈ（ｅ）ＮＢ３００にある他の機能またはリソースとインターフェイスをとる。インターフェイスの中には、ハードウェア保護されているものもあり、暗号で保護されているものもあり、また保護されていないものもある。ハードウェア保護されているインターフェイスまたは暗号で保護されたインターフェイスを介してＴｒＥ３１０とインターフェイスをとるＴｒＥ３１０の外部のこうしたリソースおよび機能は、保護されたリソースおよび機能自体であると想定される。こうしたリソースおよび機能が保護されていない場合、ＴｒＥ３１０が保護されたインターフェイス上でそれらとインターフェイスをとる理由はほとんどない。

ＴｒＥ３１０は、例えば安全なメモリ３２２、暗号機能エンジン３２４、および必要に応じて（所望の場合は物理的な）乱数生成器３２６など、ＴｒＥ３１０によってのみアクセス可能な特別なハードウェア保護されたリソース３２０をベースにする。これらの特別なハードウェア保護されたリソースは、ＴｒＥ３１０のＲｏＴ（Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ）と呼ぶことができる。これらのリソースに、ハードウェア保護されたインターフェイス３２８を介してアクセスして、ＴｒＥ３１０自体の信用性を確立し、特にＴｒＥ３１０およびＨ（ｅ）ＮＢ３００の安全な起動プロセスを可能にする必要がある。Ｈ（ｅ）ＮＢ３００の他の機能構築ブロックは、様々なセキュリティプロパティを有することができ、安全なチャネル３３０を介してアクセスすることができる。例えば、乱数生成器モジュール３３２、乱数パラメータ制御３３４、ＷＴＲＵ認証リソース３３６、Ｈ（ｅ）ＮＢ認証３４０、ＩＰスタック３４２、およびホストプラットフォームモジュール３５０は、暗号で保護されたインターフェイスまたは安全なチャネル３３０を介してアクセスされる。例えば時間ソース３６２および位置決定３６４などの機密情報３６０は、暗号で保護されたインターフェイスまたは安全なチャネル３３０を介してアクセスされる。こうした場合、あるハードウェア保護対策との組み合わせは、オプションである。さらに、保護されていないインターフェイス３７０は、例えばＴｒＥ４１０のメモリを格納機能３８０で拡張するために、非機密リソース３７５および汎用リソースに接続される。本明細書に記載したように、インターフェイスは、セキュリティのニーズが様々である可能性があり、ＴｒＥは、各インターフェイスタイプに対応し、それと対話する必要がある。

図４は、ＴｒＥ４１０を有するＨ（ｅ）ＮＢ４００の別のインターフェイス構成を示す。この実施形態において、ＴｒＥ４１０は、例えば暗号化エンジン４１５、乱数生成器４１７、および安全なメモリ４１９などそれ自体の中にハードウェア暗号化リソースを含むより厚い構成をしている。ＴｒＥ４１０は、例えばＩＫＥｖ２（インターネット鍵交換）スタック４２２、装置認証４２４、およびＨ（ｅ）ＮＢ妥当性検査モジュール４２６を使用して、ＩＫＥｖ２を介して装置認証を実行するのに十分な機能をさらに含む。ＴｒＥ４１０は、モジュール４２８によりＷＴＲＵのＡＫＡ手順のサポートも行う。ＩＫＥｖ２プロトコルは、例示の目的で、説明を通じて使用され、それだけには限定されないが、例えば、ＴＬＳ（トランスポートレイヤセキュリティ）、ブロードバンドフォーラムＴＲ（技術要件）０６９、ＯＭＡ（オープンモバイルアライアンス） ＤＭ（装置管理）プロトコル、またはＴＬＳの拡張ための適した何らかのＩＥＴＦ（インターネット技術タスクフォース） ＲＦＣ（コメント要求）など、他のプロトコルが使用されてもよいことに留意されたい。

この実施形態において、乱数生成器モジュール４３２、乱数パラメータ制御４３４、ホストプラットフォームモジュール４５０、および例えば時間ソース４６２および位置決定４６４などの機密情報４６０も暗号で保護されたインターフェイスまたは安全なチャネル４３０を介してアクセスされる。さらに、保護されていないインターフェイス４７０は、例えばＴｒＥの記憶容量４８０を拡張するために、非機密リソース４７５および汎用リソースに接続される。

別の実施形態において、１つは保護されており、他方は保護されていない２つの広範なタイプのインターフェイスがある。例えば、それぞれ、図３および図４におけるハードウェア保護されたインターフェイスまたは暗号で保護されたインターフェイスのいずれかとして示されるインターフェイスは、単に保護されたインターフェイスと見なすことができ、保護されていないインターフェイスとして示されるインターフェイスは、単に保護されていないインターフェイスと見なすことができる。

本明細書で示すように、Ｈ（ｅ）ＮＢとＳＧＷとの間の認証プロトコルは、Ｈ（ｅ）ＮＢの必須の認証、およびホスティングパーティのオプションの認証のために導入されている。次に、本明細書に記載したＴｒＥの機能を使用する認証選択の方法について開示する。

ＩＫＥｖ２（インターネット鍵交換バージョン２）は、Ｈ（ｅ）ＮＢとコアネットワークとの間の安全な通信（認証のためのものを含む）の基本的なフレームワークとして使用することができる。ＩＫＥｖ２は、Ｈ（ｅ）ＮＢとＳＧＷとの間のＳＡ（セキュリティアソシエーション）をセットアップし、２つのエンティティの間のＩＰＳｅｃトンネルをセットアップするために使用することができるセキュリティ鍵を利用する。また、Ｈ（ｅ）ＮＢおよびホスティングパーティの結合された認証にＩＫＥｖ２を使用することもできる。

ＩＫＥｖ２は、相互認証を実行し、ＳＡ（セキュリティアソシエーション）を確立し、維持するために使用されるＩＰｅｃの構成要素である。Ｈ（ｅ）ＮＢの文脈で、「セキュリティゲートウェイトンネルへのエンドポイント」は、容易に適用可能である。したがって、エンドポイントとしてのＨ（ｅ）ＮＢとＳＧＷとの間で、ＩＫＥ＿ＳＡのセキュリティパラメータの交渉、ならびにランダムノンス（ｒａｎｄｏｍ ｎｏｎｃｅ）およびデルフィヘルマン値の送信を伴う第１の段階（ＩＫＥ＿ＳＡ＿ＩＮＩＴ）、および識別の送信およびＡＨ（認証ヘッダー）および／またはＥＳＰ（カプセル化されたセキュリティペイロード（Ｅｎｃａｐｓｕｌａｔｅｄ Ｓｅｃｕｒｉｔｙ Ｐａｙｌｏａｄ））のためのＳＡのセットアップを含む要求／応答ステップを含む第２の段階（ＩＫＥ＿ＡＵＴＨ）から成るＩＫＥｖ２ステップが結果として起こる。

少なくとも２つの異なる認証アクションが指定され、一方はＨ（ｅ）ＮＢ装置自体の認証（装置認証と呼ばれる）、他方はホスティングパーティの認証（ホスティングパーティ認証と呼ばれる）である。装置認証は必須である。装置認証は、ＥＡＰ−ＡＫＡ（拡張認証プロトコル−認証鍵合意）または証明書を使用することによって行うことができる。ホスティングパーティ認証は、ＨＰＭ（ホスティングパーティモジュール）を使用して行うことができる。ホスティングパーティ認証は、行われるとき、装置認証とは別に行うか、装置認証およびホスティングパーティ認証のステップを使用した複合方法で行うことができる。さらに、Ｈ（ｅ）ＮＢのＩＤ、およびＨＰＭのＩＤは、物理的または論理的にバインドすることができ、こうしたバインドのための可能なプロトコルが本明細書に紹介されている。

一般に、まず、Ｈ（ｅ）ＮＢが装置認証に加えてホスティングパーティ認証を実行するよう要求されているかどうかを、ＳＧＷがＨ（ｅ）ＮＢに対して示す認証プロトコルシグナリング方式が開示される。また、Ｈ（ｅ）ＮＢが証明書ベースの認証またはＥＡＰ−ＡＫＡベースの認証を実行するよう要求されているかどうかを、ＳＧＷがＨ（ｅ）ＮＢに対して示す。ＳＧＷは、ＩＫＥ＿ＳＡ＿ＩＮＴ応答で、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤパラメータを使用して認証のタイプを示し、ＩＫＥ＿ＳＡ＿ＩＮＴ応答で、ＣＥＲＴＲＥＱパラメータにより装置認証のタイプを示す。Ｈ（ｅ）ＮＢは、ＩＫＥ＿ＡＵＴＨ要求で、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤパラメータおよびＡＮＯＴＨＥＲ＿ＡＵＴＨ＿ＦＯＬＬＯＷＳパラメータにより認証のタイプを示す。

本明細書で説明するように、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤパラメータおよびＣＥＲＴＲＥＱパラメータは、ＳＧＷからＨ（ｅ）ＮＢに様々なＩＫＥｖ２応答メッセージで送信されるとき、Ｈ（ｅ）ＮＢに対する要件または要求として解釈されるはずである。とりわけ、ＳＧＷは、実際にどのタイプの認証方法を使用すべきかを「決定」し、次いでそれを要求または要件としてＨ（ｅ）ＮＢに送信する。これによって、選択手順における要求と応答の対のすべての可能な組み合わせのクリアで明白な結果が得られる。この方法の示された選択は、ＳＧＷによってサポートされていない場合、送信されないため、同じパラメータは、暗黙的にＳＧＷの機能のインジケータとしても解釈されることに留意されたい。

本明細書に示されるように、Ｈ（ｅ）ＮＢは、必須の装置認証およびオプションのＨＰ（ホスティングパーティ）認証を有する。これら２つの認証は、異なる方法で行うことができ、実際に、配置された製品（Ｈ（ｅ）ＮＢおよびＳＧＷ）は、必須の認証、またはオプションの認証および必須の認証の両方をサポートすることができる。したがって、（ＳＧＷを介して）オペレータネットワークに接続する所与のＨ（ｅ）ＮＢの認証のタイプを選択するための方法が必要である。ＳＧＷは、オペレータポリシーを実施するため、ＳＧＷによってＨ（ｅ）ＮＢに対して行われ、示される選択は信頼できる。

認証選択方法の一実施形態において、方法は、１）証明書またはＥＡＰ−ＡＫＡによる装置認証、および２）ＥＡＰ−ＡＫＡのホスティングパーティ認証を想定する。提示された方法の実施形態は、ＩＫＥｖ２多重認証（ＩＫＥｖ２ ｍｕｌｔｉｐｌｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎｓ）の使用を想定する。

以下で説明するように、必須の装置認証およびオプションのホスティングパーティ認証は、Ｈ（ｅ）ＮＢで行われる。認証は、証明書ベースの解決策またはＥＡＰ−ＡＫＡによって行うことができる。これによって、２つの認証方法および認証を必要とし得る２つのエンティティに関する以下の組み合わせ、１）証明書による、ＨＰ認証無しの装置認証、２）ＥＡＰ−ＡＫＡによる、ＨＰ認証無しの装置認証、３）証明書による、および証明書を使用したＨＰ認証による装置認証、４）ＥＡＰ−ＡＫＡによる、および証明書を使用したＨＰ認証による装置認証、５）証明書による、およびＥＡＰ−ＡＫＡを使用したＨＰ認証による装置認証、および６）ＥＡＰ−ＡＫＡによる、およびＥＡＰ−ＡＫＡを使用したＨＰ認証による装置認証がもたらされる。この実施形態では、ＨＰ認証にＥＡＰ−ＡＫＡを選択することができると想定される場合、認証の組み合わせ３および４は、却下することができる。

図５を参照すると、装置認証、または装置認証およびＨＰ認証があるかどうかを決定するためのＨ（ｅ）ＮＢ５０５とＳＧＷ５１０との間の方法５００が開示されている。方法５００は、一実施形態によるＩＫＥｖ２ベースの認証手順である。最初に、Ｈ（ｅ）ＮＢ５０５は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求メッセージをＳＧＷ５１０に送信する（５１５）。ＳＧＷ５１０は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答メッセージを送信する（５２０）。ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答メッセージがＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤを含まない場合、Ｈ（ｅ）ＮＢ５０５にとって、多重認証を行うことができないことは明らかである。したがって、証明書またはＥＡＰ−ＡＫＡベースの認証を使用して、装置認証のみが可能である。

Ｈ（ｅ）ＮＢ５０５は、ＩＫＥ＿ＡＵＴＨ要求メッセージを送信する（５２５）。ＳＧＷ５１０は、ＩＫＥ＿ＡＵＴＨ要求メッセージがＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤおよびＡＮＯＴＨＥＲ＿ＡＵＴＨ＿ＦＯＬＬＯＷＳを含むかどうかを決定する。ＩＫＥ＿ＡＵＴＨ要求メッセージが所与の値を含まない場合、これは、装置認証のみを行うことができることを意味する。所与の値がある場合、装置認証およびＨＰ認証の両方を行うことができる。

再度図５を参照すると、装置認証のタイプが証明書ベースであるかＥＡＰ−ＡＫＡベースであるかを決定する方法が開示されている。Ｈ（ｅ）ＮＢ５０５は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答（５２０）におけるＣＥＲＴＲＥＱの入手可能性を決定する。Ｈ（ｅ）ＮＢ５０５に対するＩＫＥ＿ＳＡ＿ＩＮＩＴ応答においてＣＥＲＴＲＥＱがある場合、これは、ＳＧＷ５１０が証明書ベースの装置認証をサポートすること、およびＥＡＰ−ＡＫＡベースの認証もサポートし得ることを含意する。ＳＧＷ５１０からＨ（ｅ）ＮＢ５０５に対するＩＫＥ＿ＳＡ＿ＩＮＩＴ応答においてＣＥＲＴＲＥＱがない場合、これは、ＳＧＷ５１０がＥＡＰ−ＡＫＡベースの認証をサポートすることを含意する。

証明書ベースの装置認証は、Ｈ（ｅ）ＮＢ５０５からＳＧＷ５１０へのＩＫＥ＿ＡＵＴＨ要求（５２５）がＡＵＴＨを含むかどうかを決定することによって、ＳＧＷ５１０によって実行することもできる。ＡＵＴＨがある場合、これは、証明書ベースの装置認証が実行されることを意味し、そうでない場合、ＥＡＰ−ＡＫＡベースの認証が実行されることを意味する。本明細書で記載するように、ＨＰ（ホスティングパーティ）認証は、ＥＡＰ−ＡＫＡを使用する。

認証選択方法の一実施形態において、認証機構の選択は、本明細書で説明する原理を使用する。Ｈ（ｅ）ＮＢは、証明書またはＥＡＰ−ＡＫＡを使用して装置認証をサポートするものとする。上記の２つの方法（すなわち、証明書ベースの装置認証方法またはＥＡＰ−ＡＫＡベースの装置認証方法）のどちらに関する決定は、配置固有の決定として実際に選択される。Ｈ（ｅ）ＮＢは、装置認証に証明書またはＥＡＰ−ＡＫＡ、およびホスティングパーティ認証にＥＡＰ−ＡＫＡを使用した結合された認証をサポートすることができる。ＳＧＷは、両方の認証機構をサポートする場合でさえ、オペレータポリシーに基づいてそれらのうちの一方の使用を拒否することができる。ＳＧＷは、Ｈ（ｅ）ＮＢに、装置認証およびホスティングパーティ認証の両方を実行することを要求するか、装置認証のみを実行することを要求するか、ならびにＨ（ｅ）ＮＢに証明書ベースの装置認証を実行することを要求するか、ＥＡＰ−ＡＫＡベースの装置認証を実行することを要求するかを、Ｈ（ｅ）ＮＢに対して明白に示す。

上述した基準に基づいて、認証選択方法を以下の表１〜４に示す。表の内容は、認証方法の選択の最終結果を指す。表１〜４は、一実施形態による認証方法の選択をまとめている。表において、Ｍ＿Ａ＿ＳはＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤ、Ｉ＿Ｓ＿ＩはＩＫＥ＿ＳＡ＿ＩＮＩＴ、Ａ＿Ａ＿ＦはＡＮＯＴＨＥＲ＿ＡＵＴＨ＿ＦＯＬＬＯＷＳである。

表１は、Ｈ（ｅ）ＮＢが、４つの異なるＳＧＷ ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答に応答して、ＩＫＥ＿ＡＵＴＨ要求メッセージでＡＵＴＨ、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤ、およびＡＮＯＴＨＥＲ＿ＡＵＴＨ＿ＦＯＬＬＯＷＳを戻すシナリオを表す。ケース１では、ＳＧＷは、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤおよびＣＥＲＴＲＥＱを含むＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する。Ｈ（ｅ）ＮＢ要求メッセージは、証明書ベースの装置およびＥＡＰ−ＡＫＡベースのホスティングパーティ認証を実行することに対応する。ケース２では、ＳＧＷは、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤを含み、ＣＥＲＴＲＥＱを含まないＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＳＧＷがＥＡＰ−ＡＫＡベースの装置認証およびＥＡＰ−ＡＫＡベースのホスティングパーティ認証を要求し、しかしＨ（ｅ）ＮＢは、証明ベースの装置認証で応答するときのエラー状態に対応する。これが起こった場合、最終結果に関するＳＧＷの決定は、オペレータポリシーに依存するものとする。ケース３では、ＳＧＷは、ＣＥＲＴＲＥＱのみを含むＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＳＧＷは証明ベースの装置認証のみを要求し、しかしＨ（ｅ）ＮＢは、装置認証およびホスティングパーティ認証の両方の試行で応答するときのエラー状態に対応する。これが起こった場合、結果に関するＳＧＷの最終決定は、オペレータポリシーに依存するものとする。ケース４では、ＳＧＷは、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤまたはＣＥＲＴＲＥＱを含まないＩＫＥ＿ＳＡ＿ＩＮＩＴを送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＳＧＷがＨ（ｅ）ＮＢにＥＡＰ−ＡＫＡベースの装置認証のみを実行するよう要求し、しかしＨ（ｅ）ＮＢは、装置認証およびホスティングパーティ認証の両方を実行するよう応答するときのエラー状態に対応する。これが起こった場合、結果に関するＳＧＷの決定は、オペレータポリシーに依存するものとする。

表２は、Ｈ（ｅ）ＮＢが、４つの異なるＳＧＷ ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答に応答して、ＩＫＥ＿ＡＵＴＨ要求メッセージでＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤおよびＡＮＯＴＨＥＲ＿ＡＵＴＨ＿ＦＯＬＬＯＷＳを戻すが、ＡＵＴＨは戻さないシナリオを表す。ケース５では、ＳＧＷは、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤおよびＣＥＲＴＲＥＱを含むＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＳＧＷメッセージが証明書ベースの装置認証を要求し、しかしＨ（ｅ）ＮＢは、ＡＵＴＨをスキップすることによって、証明書ベースの装置認証をサポートしないことを示すときのエラー状態に対応する。これが起こった場合、結果に関するＳＧＷの決定は、オペレータポリシーに依存するものとする。ケース６では、ＳＧＷは、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤを含み、ＣＥＲＴＲＥＱを含まないＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＥＡＰ−ＡＫＡベースの装置およびホスティングパーティ認証を実行することに対応する。ケース７では、ＳＧＷは、ＣＥＲＴＲＥＱのみを含むＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＳＧＷがＨ（ｅ）ＮＢに証明書による装置認証を要求し、しかしＨ（ｅ）ＮＢは、装置認証およびホスティングパーティ認証の両方を実行するよう試みるときのエラー状態に対応する。これが起こった場合、結果に関するＳＧＷの最終決定は、オペレータポリシーに依存するものとする。ケース８では、ＳＧＷは、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤまたはＣＥＲＴＲＥＱを含まないＩＫＥ＿ＳＡ＿ＩＮＩＴを送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＳＧＷがＥＡＰ−ＡＫＡに基づく装置認証のみを実行するよう要求し、しかしＨ（ｅ）ＮＢは、装置認証およびホスティングパーティ認証の両方を実行するよう試みるときのエラー状態に対応する。これが起こった場合、結果に関するＳＧＷの決定は、オペレータポリシーに依存するものとする。

表３は、Ｈ（ｅ）ＮＢが、４つの異なるＳＧＷ ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答に応答して、ＩＫＥ＿ＡＵＴＨ要求メッセージでＡＵＴＨを戻すが、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤおよびＡＮＯＴＨＥＲ＿ＡＵＴＨ＿ＦＯＬＬＯＷＳを戻さないシナリオを表す。ケース９では、ＳＧＷは、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤおよびＣＥＲＴＲＥＱを含むＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＳＧＷが証明ベースの装置認証およびホスティングパーティ認証を要求し、しかしＨ（ｅ）ＮＢは、証明書ベースの装置認証のみを実行しようと試みるときのエラー状態に対応する。これが起こった場合、結果に関するＳＧＷの決定は、オペレータポリシーに依存するものとする。ケース１０では、ＳＧＷは、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤを含み、ＣＥＲＴＲＥＱを含まないＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＳＧＷがＥＡＰ−ＡＫＡベースの装置認証およびＥＡＰ−ＡＫＡベースのホスティングパーティ認証を要求し、しかしＨ（ｅ）ＮＢは、証明書ベースの装置認証のみを実行しようと試みるときのエラー状態に対応する。これが起こった場合、結果に関するＳＧＷの決定は、オペレータポリシーに依存するものとする。ケース１１では、ＳＧＷは、ＣＥＲＴＲＥＱのみを含むＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する。Ｈ（ｅ）ＮＢは、証明書ベースの装置認証を実行することによって対応する。ケース１２では、ＳＧＷは、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤまたはＣＥＲＴＲＥＱを含まないＩＫＥ＿ＳＡ＿ＩＮＩＴを送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＳＧＷがＨ（ｅ）ＮＢにＥＡＰ−ＡＫＡに基づく装置認証を実行するよう要求し、しかしＨ（ｅ）ＮＢは、証明書ベースの装置認証を実行するよう試みるときのエラー状態に対応する。これが起こった場合、結果に関するＳＧＷの決定は、オペレータポリシーに依存するものとする。

表４は、Ｈ（ｅ）ＮＢが、４つの異なるＳＧＷ ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答に応答して、ＩＫＥ＿ＡＵＴＨ要求メッセージでＡＵＴＨ、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤ、およびＡＮＯＴＨＥＲ＿ＡＵＴＨ＿ＦＯＬＬＯＷＳを戻さないシナリオを表す。ケース１３では、ＳＧＷは、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤおよびＣＥＲＴＲＥＱを含むＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＳＧＷが証明書ベースの装置認証およびホスティングパーティ認証を要求し、Ｈ（ｅ）ＮＢは、ＥＡＰ−ＡＫＡベースの装置認証を実行しようと試みるときのエラー状態に対応する。これが起こった場合、結果に関するＳＧＷの決定は、オペレータポリシーに依存するものとする。ケース１４では、ＳＧＷは、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤを含み、ＣＥＲＴＲＥＱを含まないＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＳＧＷがＥＡＰ−ＡＫＡベースの装置認証およびＥＡＰ−ＡＫＡベースのホスティングパーティ認証を要求し、しかしＨ（ｅ）ＮＢは、ＥＡＰ−ＡＫＡベースの装置認証のみを実行しようと試みるときのエラー状態に対応する。これが起こった場合、結果に関するＳＧＷの決定は、オペレータポリシーに依存するものとする。ケース１５では、ＳＧＷは、ＣＥＲＴＲＥＱのみを含むＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する。Ｈ（ｅ）ＮＢ要求メッセージは、ＳＧＷがＨ（ｅ）ＮＢに証明書ベースの装置認証を実行するよう要求し、しかしＨ（ｅ）ＮＢは、ＥＡＰ−ＡＫＡベースの装置認証を実行するよう試みるときのエラー状態に対応する。これが起こった場合、結果に関するＳＧＷの決定は、オペレータポリシーに依存するものとする。ケース１６では、ＳＧＷは、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤまたはＣＥＲＴＲＥＱを含まないＩＫＥ＿ＳＡ＿ＩＮＩＴを送信する。Ｈ（ｅ）ＮＢは、ＥＡＰ−ＡＫＡベースの装置認証を実行することに対応する。

ケース１、６、１１、および１６は、結果的に有効な要求／応答の対をもたらす。すべての他のケースは、結果的にエラー状態をもたらし、この場合、結果に関するＳＧＷの決定は、オペレータポリシーに依存するものとする。ポリシーの決定は、さらに、Ｈ（ｅ）ＮＢの認証機能をＳＧＷが知っていることに基づき得る。例えば、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求メッセージにおけるＨ（ｅ）ＮＢによって提供されるＨ（ｅ）ＮＢ ＩＤに基づいて、ＳＧＷは、例えばＨ（ｅ）ＮＢの認証タイプなど、Ｈ（ｅ）ＮＢ認証情報プロファイルを格納するＨ（ｅ）ＮＢ認証情報サーバからＨ（ｅ）ＮＢの認証機能プロファイルを導出することができる。ＳＧＷは、認証プロファイルに基づいて、証明書ベースの装置認証を要求すべきか、ＥＡＰ−ＡＫＡベースの認証を要求すべきかを決定することができる。Ｈ（ｅ）ＮＢ認証情報サーバは、必ずしも物理的サーバとして実装されるのではなく、他の機能と同じ場所に配置されるようにしてもよい。

図６を参照すると、Ｈ（ｅ）ＮＢ認証情報サーバ６０５からのプロファイル情報を使用する方法６００の一実施形態が示されている。ＳＧＷ６１０は、Ｈ（ｅ）ＮＢ６１５から受信されたＨ（ｅ）ＮＢ識別（１）に基づいて、Ｈ（ｅ）ＮＢ認証情報サーバ６０５からの認証プロファイル（２および３）を取り出すものとする。次いでＳＧＷ６１０は、Ｈ（ｅ）ＮＢ６１５認証プロファイルに従って要求すべき装置認証のタイプを決定する（４）。ＳＧＷ６１０は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する（５）。

認証タイプが「装置認証のみ」を実行すべき旨を含意する場合、ＳＧＷ６１０は、Ｈ（ｅ）ＮＢ６１５からＩＫＥ＿ＡＵＴＨ要求を受け付ける（６）。ＳＧＷ６１０は、ＡＵＴＨ応答メッセージをＨ（ｅ）ＮＢ６１５に送信し、認証手順を続行する（７ａ）。

認証タイプが「装置認証およびＨＰ認証の両方」を実行すべき旨を含意する場合、ＳＧＷ６１０は、前のＩＫＥ＿ＡＵＴＨ要求メッセージ（６）およびホスティングパーティ認証についての別のＩＫＥ＿ＡＵＴＨ要求メッセージ（７ｂ）に従うようにＨ（ｅ）ＮＢ６１５に対して示すために、「認証拒否」メッセージでＩＫＥ＿ＡＵＴＨ応答を送信する。認証拒否メッセージは、単に引き続いてホスティングパーティ認証を行うことをＨ（ｅ）ＮＢ６１５に対して示すためのものであり、ＳＧＷ６１０が前のＩＫＥ＿ＡＵＴＨ要求メッセージ（６）で取得された装置認証に関する情報を破棄することを含意するものではない。代わりに、ＳＧＷ６１０は、前のＩＫＥ＿ＡＵＴＨ要求メッセージ（６）からの情報を保持し、それを使用して、Ｈ（ｅ）ＮＢ６１５が装置認証ＩＫＥ＿ＡＵＴＨ要求、およびホスティングパーティ認証のための認証情報を含む別のＩＫＥ＿ＡＵＴＨ要求に従った後、最終的な認証成功（または拒否）メッセージをＨ（ｅ）ＮＢ６１５に送信する。ＳＧＷ６１０は、ＳＧＷ６１０が取り出したＨ（ｅ）ＮＢ６１５の認証プロファイルに応じて７ａおよび７ｂを実行する。

以下の認証は、Ｈ（ｅ）ＮＢ認証に必要である。まず、Ｈ（ｅ）ＮＢ装置およびオペレータのネットワークの相互認証を行う必要がある。ＴｒＥに格納されている信用証明書を使用した認証方法は、ＴｒＥの中で実行されるものとする。この相互認証は、プラットフォーム保全性（すなわちＴｒＥプロパティ）の妥当性検査を含む（またはそれに密にバインドされる）ものとする。相互認証の２つの部分は、以下のプロパティを有する。１）Ｈ（ｅ）ＮＢの識別は、ネットワークによって認証され、この認証の信用証明書は、Ｈ（ｅ）ＮＢにおいてＴｒＥに格納されるものとする。２）オペレータのネットワークの識別（例えば、ＳＧＷによって表される）は、Ｈ（ｅ）ＮＢのＴｒＥによって認証され、この認証は、一般にオペレータのネットワークを認証するか、Ｈ（ｅ）ＮＢによって連絡された特定のＳＧＷを認証することができる。ＳＧＷの識別は、ＳＧＷから送信されたメッセージにおけるＳＧＷに属する秘密暗号鍵の使用を識別するＴｒＥによって認証することができ、この場合、こうした秘密鍵は、ＴｒＥには知られている。というのは、秘密鍵は、ＴｒＥが参照することができるＳＧＷ証明書に保持されるからである。ＴｒＥは、このＳＧＷ証明書を安全に格納し、処理することができる。ＳＧＷ証明書は、ＳＧＷから適したＩＫＥｖ２メッセージ内でＴｒＥに送信することができる。ＴｒＥは、ルート証明書が事前に構成され、その後ルート証明書を安全に格納し、処理し、それを使用してＳＧＷ証明書を検証することができる。あるいは、ＴｒＥは、ＯＣＳＰ（オンライン証明書状態プロトコル）サーバなどの外部認証局と連絡をとってＳＧＷ証明書を検証することができる。

該当する場合、オペレータのネットワークによるホスティングパーティの認証も必要である。ホスティングパーティの識別は、オペレータのネットワークによって認証される。この認証は、次の２つの方法で実行することができる。１）ホスティングパーティの認証は、Ｈ（ｅ）ＮＢにおける個別のＨＰＭ（ホスティングパーティモジュール）に含まれる信用証明書に基づき、相互認証を介した追加のステップとして実行される。または２）ホスティングパーティの認証は、装置認証とバンドルされる。すなわち、相互認証後、追加の認証ステップがない。ホスティングパーティが存在しない（例えば、オペレータ自体がＨ（ｅ）ＮＢを提供する）場合、この後者の認証は、該当しない場合がある。

現在の基本的なセキュリティプロトコルは、Ｈ（ｅ）ＮＢとコアネットワークとの間の装置認証およびホスティングパーティ認証を含めて、安全な通信を提供するが、現在のプロトコルは、Ｈ（ｅ）ＮＢまたはその中の（オプションの）ＨＰＭについて、「認証」情報以外はほとんど何も提供しないという点で、いくつかの問題を抱えている。Ｈ（ｅ）ＮＢは、（例えば人の家など）あまり安全でない物理的な環境において動作するようにされている可能性があるため、知られている秘密を使用した「認証」は、十分ではない可能性があり、セキュリティプロトコルは、ＳＧＷにアクセスするための不可欠のステップとして、ＴｒＥおよび／またはＨ（ｅ）ＮＢ、またはその構成要素のうちの任意のものの「予想された状態」についての情報を明確に使用することが必要となり得る。このステップは、装置妥当性検査手順と呼ばれる。

具体的には、Ｈ（ｅ）ＮＢとＳＧＷとの間の認証およびセキュリティアソシエーションのセットアップにＩＫＥｖ２を使用するセキュリティプロトコルは、Ｈ（ｅ）ＮＢ機器ＩＤ（Ｈ（ｅ）ＮＢ＿ＥＩ）およびホスティングパーティＩＤ（Ｈ＿ＩＤ）以外のどんな情報も含まない。これらのＩＤは、ＴｒＥおよびオプションのＨＰＭ内にそれぞれ安全に保護されるが、それらの有無（および保全性）が、妥当性検査されるＨ（ｅ）ＮＢを、コアネットワークとの対話に関して信頼することができるという妥当性検査に関して、十分ではない可能性がある。

したがって、セキュリティプロトコルまたは方法の実施形態が開示される。

一実施形態において、必須の装置（およびオプションのホスティングパーティ）認証の前提条件は、起動時における、および場合によっては（スケジュールされたまたはイベントドリブンの）実行時におけるＴｒＥによる不可欠の起動およびシステム状態の達成である。

別の実施形態において、ＩＫＥ＿ＩＮＩＴ段階中またはその後、Ｈ（ｅ）ＮＢは、適切なＩＫＥｖ２ペイロード（例えばＣＰまたはＶペイロード、または通知（Ｎ）メッセージ）で、その信用性をプラットフォームとして示す情報を送信する。こうした情報は、証明書、または、ＴｒＥ、Ｈ（ｅ）ＮＢ、もしくはＨＰＭを含めて任意の構成要素（の組み合わせ）の予想される状態を記述するステートメント、ＴｒＥもしくはＨ（ｅ）ＮＢの他の構成要素によって実行される局所的な保全性チェックプロセスで不合格になる構成要素のリストを含み得る。この情報は、ＴｒＥ内で保護される秘密鍵によって署名することができる。

別の実施形態において、ＣＡまたはＴＴＰ（例えばＴｒＥまたはＨ（ｅ）ＮＢ製造業者／サプライヤ）で確認することができる証明書を配布することもできる（Ｈ（ｅ）ＮＢがＳＧＷを介してそれをＨＬＲ／ＡＡＡに送信することによって、またはＨＬＲ／ＡＡＡが帯域外プロセスからそれらを取得すると仮定することによって）。こうした証明書は、ＴｒＥ内で保持された秘密鍵の公開鍵を証明する。したがって、秘密鍵の使用は、ＴｒＥ、またはＨ（ｅ）ＮＢの他の部分が完全な状態であることを示すことになる。ＩＫＥｖ２の交換中、Ｈ（ｅ）ＮＢは、コアネットワークに対して、Ｈ（ｅ）ＮＢのどの構成要素を、信憑性または保全性について妥当性検査すべきであるかも示し得る。構成要素固有の鍵は、特定の構成要素の妥当性について署名し、保証するために、ＴｒＥによって使用され得る。ＴｒＥ、またはＨ（ｅ）ＮＢの他の任意の部分の証明書またはステートメントがプロトコル自体で運ばれる場合、ＣＰおよびＶなどのＩＫＥｖ２パラメータは、その情報を運ぶために使用され得る。あるいは、こうした情報は、Ｈ（ｅ）ＮＢからＳＧＷに、ＩＫＥ＿ＡＵＴＨ要求メッセージの通知（Ｎ）フィールドで運ぶことができる。こうしたフィールドは、ＴｒＥ、またはＨ（ｅ）ＮＢの他の部分によって実行される任意の装置妥当性検査および保全性チェックのプロセス、エンティティ、および／または結果についての情報も含み得る。ＳＫ｛｝機構による保護も考慮に入れることができる。

別の実施形態において、証明書を介して（またはプロトコル時に事前に配布されたまたは交換された）、または明確なメッセージング（場合によっては、保全性および機密性のために保護された）を介して、Ｈ（ｅ）ＮＢは、ＳＧＷに対して、およびＳＧＷを介してコアネットワークに対して、Ｈ（ｅ）ＮＢが保証し得る通信、アクセス、およびアプリケーション特権の種類にコアネットワークがアクセスするのに有用なＴｒＥ自体についての情報を示す。この場合もまた、こうした情報は、ＩＫＥｖ２に含まれ、適した既存のパラメータで運ぶことができる。

別の実施形態において、ＩＫＥｖ２とは異なる通信プロトコルを、Ｈ（ｅ）ＮＢの結合された認証および装置妥当性検査のために使用することができる。こうしたプロトコルの例には、それだけには限定されないが、ＴＬＳ（トランスポートレイヤセキュリティ）、ブロードバンドフォーラムＴＲ（技術要件）０６９、ＯＭＡ（オープンモバイルアライアンス） ＤＭ（装置管理）プロトコル、または装置認証および装置妥当性検査のメッセージを結合された方法で示すことができるＴＬＳの拡張のための何らかの適したＩＥＴＦ（インターネット技術タスクフォース） ＲＦＣ（コメント要求）などがあり得る。

開示された認証プロトコル実施形態によれば、前提条件手順またはその一部として、ＴｒＥは、ＴｒＥと、ＭＰＵ、ＨＰＭ（含まれている場合）、セルラー式モデムプロセッサ、非セルラー式モデムプロセッサ、位置決め装置、および／またはクロック／タイミング装置を含むＨ（ｅ）ＮＢの他の部分との間の安全なチャネルをセットアップすることができる。こうした安全なチャネルの確立の証拠は、次いで、ＴｒＥによって保護された鍵を使用して暗号化された保護の下で、Ｈ（ｅ）ＮＢからＳＧＷを介してＨＬＲ／ＡＡＡに運ばれる。ＨＬＲ／ＡＡＡは、次いでこうした情報を使用して、Ｈ（ｅ）ＮＢおよび／またはホスティングパーティ認証の一部として、またはその前提条件として、Ｈ（ｅ）ＮＢの信用性にアクセスすることができる。

別の実施形態において、ＴｒＥは、Ｈ（ｅ）ＮＢ、またはアプリケーションまたはサービスサーバへのアプリケーションレイヤ通信アクセスのためのＨＰＭ、位置決め装置、もしくはクロック／タイミング装置を含むその構成要素のうちの任意のものの特定のシステム状態を定義し、実施するために使用することができる。したがって、Ｈ（ｅ）ＮＢは、安全に起動されたＴｒＥの監視下で、ＴｒＥおよびＨ（ｅ）ＮＢの任意の他の部分の安全な起動の後、「起動」され、ＩＫＥｖ２を使用して、ＨＬＲ／ＡＡＡとの「ネットワークレベルセキュリティアソシエーション」を達成することができる。しかし、その後、ＴｒＥは、特定のアプリケーションサーバに対するアプリケーションまたはサービスレベル認証を可能にする前に、オペレータまたはサービスプロバイダのセキュリティポリシー下で、それ自体、および／またはＨ（ｅ）ＮＢの他の任意の部分の追加の「システム状態」チェックを実行することもできる。こうしたサービスは、ＯＡＭサービス、ならびにＨ（ｅ）ＮＢ位置および／または参照タイミングを更新するためのサービスを含み得る。

図７における関連図として示される別の実施形態において、セキュリティプロトコルは、Ｈ（ｅ）ＮＢ７０５の信用性が評価され、（ネットワークおよびアプリケーションアクセスの）そのアクセス権が、ＴＣＧ（Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ） ＴＮＣ（Ｔｒｕｓｔｅｄ Ｎｅｔｗｏｒｋ Ｃｏｎｎｅｃｔ） ＰＤＰ（Ｐｏｌｉｃｙ Ｄｅｃｉｓｉｏｎ Ｐｏｉｎｔ）として働くコアネットワークエンティティまたはＨＬＲ／ＡＡＡ７１０によって決定される手順も含み得る。次いで、アクセス制御ポリシーは、ＴＣＧ ＴＮＣ ＰＥＰ（Ｐｏｌｉｃｙ Ｅｎｆｏｒｃｅｍｅｎｔ Ｐｏｉｎｔ）として働くＳＧＷ７１５によって実施される。したがって、Ｈ（ｅ）ＮＢ７０５は、ＴＣＧ ＴＮＣ ＡＲ（Ａｃｃｅｓｓ Ｒｅｑｕｅｓｔｏｒ）として働く。

別の実施形態において、認証のものなど、セキュリティプロトコルの文脈で、ＴＮＣ ＡＲとして働くＨ（ｅ）ＮＢは、それ自体で、またはＳＧＷもしくはＨＬＲ／ＡＡＡからの要求によって保全性メトリックスを提供する。次いでこうした保全性メトリックスは、ＳＧＷを介してＨＬＲ／ＡＡＡに転送され、この場合、ＨＬＲ／ＡＡＡは、ＴＣＧ ＴＮＣ ＰＥＰとして働く。Ｈ（ｅ）ＮＢから受信される保全性メトリックスが必要な「信頼レベル」を満たすかどうかを評価した後、ＨＬＲ／ＡＡＡは次いで、Ｈ（ｅ）ＮＢに与えられるべきネットワークアクセスのレベルを決定する。こうした「レベル」は、サービス範囲、帯域幅、トラフィックタイプおよびボリューム、Ｈ（ｅ）ＮＢおよび／またはＨ（ｅ）ＮＢを介してコアネットワークと通信する任意のＷＴＲＵのアプリケーションアクセスなどの粒状の組み合わせを含み得る。次いでポリシー決定は、ＨＬＡ／ＡＡＡからＳＧＷに転送され、これは次いでＴＣＮ ＰＥＰとして働き、Ｈ（ｅ）ＮＢについて与えられたアクセスを管理するＨＬＲ／ＡＡＡからアクセス制御ポリシーを実施する。また、図７には、このアーキテクチャ例の関連のＴＮＣ仕様（例えばＩＦ−Ｍ、ＩＦ−ＩＭＣ、ＩＦ−ＩＭＶ、ＩＦ−ＴＮＣＣＳ、ＩＦ−Ｔ、およびＩＦ−ＰＥＰ）が示される。

装置および／またはホスティングパーティ認証プロトコルの一部として、Ｈ（ｅ）ＮＢの位置およびＨ（ｅ）ＮＢの操作の「イベントの説明またはログ」は、ＳＧＷを介してＨ（ｅ）ＮＢからＨＬＲ／ＡＡＡに運ばれる情報の一部として含まれる、Ｈ（ｅ）ＮＢ自体のタイミング機能によって提供されるＴｒＥおよび／またはＨ（ｅ）ＮＢのタイムスタンプ付きバージョンの安全な起動履歴などの局所的なタイムスタンプ付きで開示される。こうした位置情報および／またはタイムスタンプ付きの「イベントの説明またはログ」情報は、ＴｒＥ内で保護された鍵で暗号化される。ＨＬＲ／ＡＡＡは次いで、Ｈ（ｅ）ＮＢ＿ＥＩまたはＨＰＭ＿ＩＤだけではなく、Ｈ（ｅ）ＮＢの１つまたは複数の位置、および／またはＨ（ｅ）ＮＢに関するタイムスタンプ付きの「イベントの説明および／またはログ」を含む情報によってもＨ（ｅ）ＮＢの信用性を評価する。

上記の開示されたセキュリティプロトコルについて、ＣＰまたはＶなどの適したＩＫＥｖ２ペイロード、または通知メッセージ（Ｎ）は、Ｈ（ｅ）ＮＢとコアネットワーク（およびＳＧＷ）との間の追加の情報を運ぶために使用され得る。

次に図８（Ａ）および図８（Ｂ）を参照すると、ＥＡＰ−ＡＫＡベースの認証の信号図例が示されている。図８（Ａ）および図８（Ｂ）の認証プロトコルは、ＴｒＥ８１０の強力なセキュリティプロパティを使用して、Ｈ（ｅ）ＮＢ８０５のＥＡＰ−ＡＫＡベースの装置認証プロトコルの全体的なセキュリティを強化する。アルファベット（例えばＡ、Ｂ、Ｃなど）で指し示されるステップは、装置認証の目的で、ＴｒＥ８１０とＨ（ｅ）ＮＢ８０５の他の機能との間の対話を伴うことに留意されたい。

装置認証の前提条件として、Ｈ（ｅ）ＮＢ８０５は、信頼の置けるプラットフォームとしてＳＧＷ８２０に対してそれ自体を妥当性検査する必要がある（０）。Ｈ（ｅ）ＮＢ８０５は、そのＴｒＥ８１０に依存して、Ｈ（ｅ）ＮＢ８０５のプラットフォームの妥当性の暗号で保護された証拠を安全に提供し、Ｈ（ｅ）ＮＢ８０５は次いでこれをＳＧＷ８２０に転送する。ＳＧＷ８２０は、証拠を評価し、Ｈ（ｅ）ＮＢ８０５が装置認証を引き続き行うことができるほど十分信用できるかどうかを決定する。

Ｈ（ｅ）ＮＢ８０５は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求をＳＧＷ８２０に送信する（１）。ＳＧＷ８２０は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する（２）。Ｈ（ｅ）ＮＢ８０５は、ＩＫＥ＿ＳＫＡ＿ＩＮＩＴ応答をＴｒＥ８１０に転送することによって、ＴｒＥ８１０にＨＮＢ＿ＩＤを要求する（Ａ）。ＴｒＥ８１９は、ＩＫＥ＿ＳＫＡ＿ＩＮＩＴ応答の保全性をチェックし、ＨＮＢ＿ＩＤからＩＤｉを構成する（Ｂ）。ＴｒＥ８１０は、ＩＤｉペイロードおよびステータス（例えば、ＴｒＥ８１０によるＨＮＢ＿ＩＤからのＩＤｉの構成の完了を述べる）をＨ（ｅ）ＮＢ８０５に送信する（Ｃ）。

Ｈ（ｅ）ＮＢ８０５は、ＩＤｉペイロードをＳＧＷ８２０に送信し、子セキュリティアソシエーションの交渉を開始する（３）。Ｈ（ｅ）ＮＢ８０５がＥＡＰ認証の実行を望んでいる旨をＳＧＷ８２０に知らせるために、ＡＵＴＨが省略される。Ｈ（ｅ）ＮＢ８０５のリモートＩＰアドレスを動的に構成する必要がある場合、構成ペイロードは、このメッセージで運ばれる。また、Ｈ（ｅ）ＮＢ８０５は、ＳＧＷ８２０に証明書を要求する。ＩＤｉペイロードで提示されるＮＡＩ（ネットワーク識別子）によって選択されたユーザプロファイルが認証の選択（証明書、ＥＡＰ−ＡＫＡ、または証明書−ＥＰＡ−ＡＫＡ多重認証）を実施することに留意されたい。

ＳＧＷ８２０は、ＩＫＥ＿ＡＵＴＨ要求メッセージで受信した識別を含む認証要求メッセージを、空のＥＡＰ ＡＶＰ（属性値の対）と共にＡＡＡサーバ８３０に送信する（４）。必要な場合、ＡＡＡサーバ８３０は、装置プロファイルおよび認証ベクトルをＨＳＳ／ＨＬＲ８４０または他の何らかの認証エンティティから取り出す（５）。次いでＡＡＡサーバ８３０は、認証チャレンジを開始する（６）。

ＳＧＷ８２０は、ＩＫＥ＿ＡＵＴＨ応答をＨ（ｅ）ＮＢ８０５に送信する（７）。ＩＫＥｖ２を介したＥＡＰ手順を開始するために、ＡＡＡサーバ８３０から受信したＥＡＰメッセージ（ＥＡＰ−要求／ＡＫＡ−チャレンジ）が含まれる。Ｈ（ｅ）ＮＢのＴｒＥ８１０がＳＧＷ８２０の証明書に基づいてＳＧＷ８２０を認証する必要がある場合、ＳＧＷ８２０の識別、証明書、および（ＩＫＥ＿ＳＡ＿ＩＮＩＴ交換における）前のメッセージを保護するために使用されるＡＵＴＨパラメータは、このメッセージでＨ（ｅ）ＮＢ８０５に送信される。

ＳＧＷ８２０認証および認証チャレンジに対する応答の計算に必要な素材がＴｒＥ８１０に転送される（Ｄ）。Ｈ（ｅ）ＮＢ８０５がＳＧＷ８２０の証明書に基づいてＳＧＷ８２０を認証する必要がある場合、ＴｒＥ８１０は、ＲＡＮＤ、ＡＵＴＮからＲＥＳを計算し、オプションで認証パラメータをチェックする（Ｅ）。ＴｒＥ８１０は、ＳＧＷ８２０の認証の成功時に、オプションのステータスメッセージと共に、ＲＥＳをＨ（ｅ）ＮＢ８０５に配信する（Ｆ）。

Ｈ（ｅ）ＮＢ８０５は、認証チャレンジに応答する（８）。ＩＫＥｖ２メッセージにおける唯一のペイロード（ヘッダーは別として）は、ＥＡＰメッセージである。ＳＧＷ８２０は、ＥＡＰ−応答／ＡＫＡ−チャレンジメッセージをＡＡＡサーバ８３０に転送する（９）。すべてのチェックが成功すると、ＡＡＡサーバ８３０は、ＥＡＰの成功および鍵素材を含む認証の回答をＳＧＷ８２０に送信する（１０）。この鍵素材は、認証プロセス中に生成されたＭＳＫ（マスターセッション鍵）から成るものとする。

ＩＫＥ＿ＳＡ＿ＩＮＩＴ段階メッセージを認証するために、ＳＧＷ８２０はＭＳＫを使用して、ＡＵＴＨパラメータを生成するものとする（１１）。ＥＡＰ成功メッセージは、ＩＫＥｖ２を介してＨ（ｅ）ＮＢ８０５に転送される（１２）。ＥＡＰ成功メッセージは、ＴｒＥ８１０に転送される（Ｇ）。ＴｒＥ８１０は、最初のＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージを認証するためのＡＵＴＨパラメータを生成するための入力としてＭＳＫのそれ自体のコピーを使用する（Ｈ）。次いでＴｒＥ８１０は、ＡＵＴＨをＨ（ｅ）ＮＢ８０５に転送する（Ｉ）。

Ｈ（ｅ）ＮＢ８０５は、ＩＫＥ＿ＡＵＴＨ要求を構成し、それをＡＵＴＨパラメータによりＳＧＷ８２０に送信する（１３）。次いでＳＧＷ８２０は、Ｈ（ｅ）ＮＢ８０５から受信したＡＵＴＨの正当性をチェックし、第２のＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージを認証するＡＵＴＨパラメータを計算する。ＳＧＷ８２０は、Ｈ（ｅ）ＮＢ８０５がＣＦＧ＿ＲＥＱＵＥＳＴを介してリモートＩＰアドレスを要求した場合、構成ペイロード（ＣＦＧ＿ＲＥＰＬＹ）で割り当てられたリモートＩＰアドレスを送信するものとする。次いでＡＵＴＨパラメータは、構成ペイロード、セキュリティアソシエーション、およびＩＫＥｖ２パラメータの残りと共にＨ（ｅ）ＮＢ８０５に送信され、ＩＫＥｖ２交渉が終了する（１４）。

ＳＧＷ８２０は、そのＨ（ｅ）ＮＢ８０５の古いＩＫＥ ＳＡがすでに存在していることを検出した場合、ＩＫＥ ＳＡを削除し、Ｈ（ｅ）ＮＢ８０５における古いＩＫＥ ＳＡを削除するために、Ｈ（ｅ）ＮＢ８０５に、ＤｅｌｅｔｅペイロードでＩＮＦＯＲＭＡＴＩＯＮＡＬ交換を送信する（１５）。

別の実施形態において、装置認証のプロトコルは、図９を参照して示されるように、証明書に基づいていてもよい。ＩＫＥｖ２証明書ベースの相互認証は、ＲＦＣ−４３０６ ＩＫＥｖ２（インターネット鍵交換）プロトコルに従って実行される。証明書の処理およびプロファイルは、所与の仕様に準拠するが、前の証明書の登録および取り消しプロセスの実施の複雑さ、ならびに、例えば満了またはその装置の証明書に関する他の問題のために認証チェックに不合格になる装置を処理するためのブラックリストまたはホワイトリストの使用など、より簡単な代替の有望な可用性のために、証明書の登録および証明書の取り消しは必要ではない場合がある。図９におけるアルファベット（例えばＡ、Ｂ、Ｃなど）で指し示されるステップは、装置認証の目的で、ＴｒＥ９１０とＨ（ｅ）ＮＢ９０５の他の機能との間の対話を伴うことに留意されたい。

ＥＡＰ−ＡＫＡベースの装置認証の前提条件として、Ｈ（ｅ）ＮＢ９０５は、信用できるプラットフォームとしてＳＧＷ９２０に対してそれ自体を妥当性検査する必要がある（０）。Ｈ（ｅ）ＮＢ９０５は、そのＴｒＥ９１０に依存して、Ｈ（ｅ）ＮＢ９０５のプラットフォームの妥当性の暗号で保護された証拠を安全に提供し、Ｈ（ｅ）ＮＢ９０５は次いでこれをＳＧＷ９２０に転送する。ＳＧＷ９２０は、証拠を評価し、Ｈ（ｅ）ＮＢ９０５が装置認証を引き続き行うことができるほど十分信用できるかどうかを決定する。

Ｈ（ｅ）ＮＢ９０５は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求をＳＧＷ９２０に送信する（１）。ＳＧＷ９２０は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信して、Ｈ（ｅ）ＮＢ９０５に証明書を要求する（２）。Ｈ（ｅ）ＮＢ９０５は、ＩＫＥ＿ＳＫＡ＿ＩＮＩＴ応答をＴｒＥ９１０に転送することによって、ＴｒＥ９１０にＨＮＢ＿ＩＤを要求する（Ａ）。ＴｒＥ９１０は、ＩＫＥ＿ＳＫＡ＿ＩＮＩＴ応答の保全性をチェックし、ＨＮＢ＿ＩＤからＩＤｉを構成し、装置ＣＥＲＴを取り出し、装置ＣＥＲＴを使用してＡＵＴＨを計算する（Ｂ）。ＴｒＥ９１０は、ＩＤｉ、ＡＵＴＨ、ＣＥＲＴ、およびステータス（例えば、ＴｒＥ９１０によるＨＮＢ＿ＩＤからのＩＤｉの構成、ＡＵＴＨの計算、ＣＥＲＴの取り出しの完了などを述べる）をＨ（ｅ）ＮＢ９０５に送信する（Ｃ）。

Ｈ（ｅ）ＮＢ９０５は、ＩＤｉペイロードを送信し、子セキュリティアソシエーションの交渉を開始する（３）。また、Ｈ（ｅ）ＮＢ９０５は、ＡＵＴＨペイロード、それ自体の証明書、およびＳＧＷ９２０への証明書の要求の送信も行う。Ｈ（ｅ）ＮＢ９０５のリモートＩＰアドレスを動的に構成する必要がある場合、構成ペイロードは、このメッセージで運ばれる。ＩＤｉペイロードで提示されるＮＡＩ（ネットワークアドレス識別子）によって選択されたユーザプロファイルが認証の選択（証明書、ＥＡＰ−ＡＫＡ、または証明書−ＥＰＡ−ＡＫＡ多重認証）を実施する。

ＳＧＷ９２０は、Ｈ（ｅ）ＮＢ９０５から受信したＡＵＴＨの正当性をチェックし、第２のＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージを認証するＡＵＴＨパラメータを計算する（４）。ＳＧＷ９２０は、Ｈ（ｅ）ＮＢ９０５から受信した証明書を確認する。ＳＧＷ９２０は、ＡＵＴＨパラメータおよびその証明書を、構成ペイロード、セキュリティアソシエーション、およびＩＫＥｖ２パラメータの残りと共にＨ（ｅ）ＮＢ９０５に送信し、ＩＫＥｖ２交渉が終了する（５）。Ｈ（ｅ）ＮＢ９０５がＣＦＧ＿ＲＥＱＵＥＳＴを介してリモートＩＰアドレスを要求した場合、リモートＩＰアドレスは、構成ペイロード（ＣＦＧ＿ＲＥＰＬＹ）で割り当てられる。

Ｈ（ｅ）ＮＢ９０５は、ＳＧＷ９２０の証明書をＴｒＥ（９１０）に転送する（Ｄ）。ＴｒＥ９１０は、その安全に格納されたルート証明書によりＳＧＷ９２０の証明書を検証する（Ｅ）。Ｈ（ｅ）ＮＢ９０５は、ＳＧＷ９２０の証明書をさらに妥当性検査することができる。ＴｒＥ９１０は、ＳＧＷ ＣＥＲＴ検証のステータスをＨ（ｅ）ＮＢ９０５に転送する（Ｆ）。ＳＧＷ９２０は、そのＨ（ｅ）ＮＢ９０５の古いＩＫＥ ＳＡがすでに存在していることを検出した場合、ＩＫＥ ＳＡを削除し、Ｈ（ｅ）ＮＢ９０５における古いＩＫＥ ＳＡを削除するために、Ｈ（ｅ）ＮＢ９０５に、ＤｅｌｅｔｅペイロードでＩＮＦＯＲＭＡＴＩＯＮＡＬ交換を送信する（６）。

ＴｒＥおよびＨＰＭ（例えばＵＩＣＣ）がＨ（ｅ）ＮＢおよびＳＧＷの残りと対話する必要がある場合、ホスティングパーティ認証が後に続く結合された証明書ベースの装置認証を使用することができる。特に、ＴｒＥは、ホスティングパーティまたは装置の認証のために、ＨＰＭが生成または受信する任意の情報を保護することができる。さらに、認証プロトコル中にＨＰＭが受信または送信する任意の情報を安全なチャネルによって保護することができるように、ＴｒＥは、ＨＰＭとの安全なチャネルをセットアップすることができる。

図１０（Ａ）および図１０（Ｂ）は、結合されたＥＡＰ−ＡＫＡおよび証明書ベースの認証の信号図の一実施形態を示す。図１０（Ａ）および図１０（Ｂ）におけるアルファベット（例えばＡ、Ｂ、Ｃなど）で指し示されるステップは、この結合された認証手順の目的で、ＨＰＭ１０５０を含めて、ＴｒＥ１０１０とＨ（ｅ）ＮＢ１００５の他の機能との間の対話を伴う。

信号フローは、Ｈ（ｅ）ＮＢ１００５とＳＧＷ１０２０との間の証明書ベースの相互認証、次いでＨ（ｅ）ＮＢ１００５とＡＡＡサーバ１０３０との間のＥＡＰ−ＡＫＡ ａｕｔｈ交換を示す。最初に、Ｈ（ｅ）ＮＢ１００５は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求をＳＧＷ１０２０に送信する（１）。ＳＧＷ１０２０は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信して、Ｈ（ｅ）ＮＢ１００５に証明書を要求する（２）。ＳＧＷ１０２０は、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤペイロードを含めることによって、それが多重認証をサポートすることを示す。

Ｈ（ｅ）ＮＢ１００５は、子セキュリティアソシエーションの交渉を開始する（３）。まず、Ｈ（ｅ）ＮＢ１００５は、（ＨｅＮＢ＿ＥＩから）ＩＤｉペイロードを構成し、以下の暗号化されたパッケージを計算し、転送するようＴｒＥ１０１０に要求する。
ＳＫ｛ＳＡ，ＴＳｉ，ＴＳｒ，ＩＤｉ＝ＮＡＩ，ＩＤｒ，ＣＰ（ＣＦＧ＿ＲＥＱＵＥＳＴ），ＡＵＴＨ，ＣＥＲＴＲＥＱ，ＣＥＲＴ，Ｎ（ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤ），Ｎ（ＡＮＯＴＨＥＲ＿ＡＵＴＨ＿ＦＯＬＬＯＷＳ）｝
Ｈ（ｅ）ＮＢ１００５は、ＨＤＲ（ヘッダー）および暗号化されたペイロードＳＫ｛．．．｝から成るＩＫＥ＿ＡＵＴＨ要求をＳＧＷ１０２０に転送する。暗号化されたペイロードは、ＡＵＴＨペイロード、Ｈ（ｅ）ＮＢ１００５自体の証明書、およびＳＧＷ１０２０への証明書の要求も含む。Ｈ（ｅ）ＮＢ１００５のリモートＩＰアドレスを動的に構成する必要がある場合、構成ペイロードは、このメッセージで運ばれる。Ｈ（ｅ）ＮＢ１００５は、ＭＵＬＴＩＰＬＥ＿ＡＵＴＨ＿ＳＵＰＰＯＲＴＥＤおよびＡＮＯＴＨＥＲ＿ＡＵＴＨ＿ＦＯＬＬＯＷＳ属性を含めることによって、それが多重認証をサポートし、第２の認証を行うことを望むことを示す。ＩＤｉペイロードで提示されるＮＡＩによって選択されたユーザプロファイルが認証の選択（証明書、ＥＡＰ−ＡＫＡ、または証明書−ＥＰＡ−ＡＫＡ多重認証）を行う。

ＳＧＷ１０２０は、Ｈ（ｅ）ＮＢ１００５から受信したＡＵＴＨの正当性をチェックし、第２のＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージを認証するＡＵＴＨパラメータを計算する（４）。ＳＧＷ１０２０は、Ｈ（ｅ）ＮＢ１００５から受信した証明書を検証する。ＳＧＷ１０２０は、ＡＵＴＨパラメータおよびその証明書をＨ（ｅ）ＮＢ１００５に送信する（５）。

Ｈ（ｅ）ＮＢ１００５は、暗号化されたペイロードＳＫ｛ＩＤｒ，ＡＵＴＨ，ＳＧＷ Ｃｅｒｔｉ｝をＴｒＥ１０１０に転送し、これは、ペイロードを解読し、ＩＤｒ、ＡＵＴＨ、およびＳＧＷ Ｃｅｒｔｉを抽出する。次いでＴｒＥ１０１０は、その格納されたルート証明書によりＳＧＷ１０２０の証明書を検証する（６）。Ｈ（ｅ）ＮＢ１００５は、オペレータの制御下にあるとき、ＳＧＷ１０２０の証明書をさらに妥当性検査することができる。

Ｈ（ｅ）ＮＢ１００５は、ＴｒＥ１０１０に、別のＩＫＥ＿ＡＵＴＨ要求メッセージの暗号化された部分を形成するよう要求し、この場合、Ｈ（ｅ）ＮＢ１００５がＥＡＰ認証を実行することを望んでいる旨をＳＧＷ１０２０に知らせるために、ＡＵＴＨペイロードが省略される（７）。暗号化された部分は、ＳＫ｛ＩＤｉ＝ＮＡＩ，ＩＤｒ｝である。次いでＨ（ｅ）ＮＢ１００５は、ＨＤＲ（ヘッダー）を作成し、ＨＤＲ、ＳＫ｛ＩＤｉ＝ＮＡＩ，ＩＤｒ｝をＳＧＷ１０２０に送信する。

ＳＧＷ１０２０は、ＩＫＥ＿ＡＵＴＨ要求メッセージで受信した識別を含む認証要求メッセージを、空のＥＡＰ ＡＶＰと共にＡＡＡサーバ１０３０に送信する（８）。ＡＡＡサーバ１０３０は、ユーザプロファイルおよび認証ベクトルをＨＳＳ／ＨＬＲ（ホーム加入者サーバ／ホームロケーションレジスタ）１０４０から取り出すものとする（９）。ＡＡＡサーバ１０３０は、認証チャレンジを開始する（１０）。

ＳＧＷ１０２０は、ＩＫＥ＿ＡＵＴＨ応答をＨ（ｅ）ＮＢ１００５に送信する（１１）。ＩＫＥｖ２を介したＥＡＰ手順を開始するために、ＡＡＡサーバ１０３０から受信したＥＡＰメッセージ（ＥＡＰ−要求／ＡＫＡ−チャレンジ）が含まれる。Ｈ（ｅ）ＮＢ１００５がＳＧＷ１０２０の証明書に基づいてＳＧＷ１０２０を認証する必要がある場合、ＳＧＷ１０２０の識別、ＳＧＷ証明書、および（ＩＫＥ＿ＳＡ＿ＩＮＩＴ交換において）Ｈ（ｅ）ＮＢ１００５に送信した前のメッセージを保護するために使用されるＡＵＴＨパラメータがこのメッセージに含まれる。

ＴｒＥ１０１０は、まずＳＡ（セキュリティアソシエーション）を交換することによってＨＰＭ１０５０との安全なチャネルを確立する。こうした安全なチャネルの確立の結果、ＴｒＥ１０１０、およびＨＰＭ１０５０は、次いでＲＡＮＤおよびＡＵＴＮを使用して認証セッションにバインドされるようになる。次いでＴｒＥ１０１０は、認証チャレンジをＨＰＭ１０５０に転送する（Ａ）。

ＨＰＭ１０５０は、ＲＥＳ（ＡＫＡ応答）を計算する（Ｂ）。ＨＰＭ１０５０は、安全なチャネルを介してＴｒＥ１０１０にＲＥＳ（ＡＫＡ応答）を送信する（Ｃ）。

Ｈ（ｅ）ＮＢ１００５は、認証チャレンジに応答する（１２）。ＩＫＥｖ２メッセージにおける唯一のペイロード（ヘッダーは別として）は、ＥＡＰメッセージであり、これは、ＨＰＭ１０５０によって計算され、次いでＴｒＥ１０１０によってＩＫＥｖ２を介して暗号化され、次いでＨ（ｅ）ＮＢ１００５に転送されるＲＥＳを含む。Ｈ（ｅ）ＮＢ１００５がＳＧＷ１０２０の証明書に基づいてＳＧＷ１０２０を認証する必要がある場合、Ｈ（ｅ）ＮＢ１００５は、認証パラメータをチェックする。

ＳＧＷ１０２０は、ＥＡＰ−応答／ＡＫＡ−チャレンジメッセージをＡＡＡサーバ１０３０に転送する（１３）。すべてのチェックが成功すると、ＡＡＡサーバ１０４０は、ＥＡＰの成功および鍵素材を含む認証の回答をＳＧＷ１０２０に送信する（１４）。この鍵素材は、認証プロセス中に生成されたＭＳＫから成るものとする。ＩＫＥ＿ＳＡ＿ＩＮＩＴ段階メッセージを認証するために、ＳＧＷ１０２０はＭＳＫを使用して、ＡＵＴＨパラメータを生成するものとする（１５）。ＥＡＰ成功メッセージは、ＩＫＥｖ２を介してＨ（ｅ）ＮＢ１００５に転送される（１６）。

Ｈ（ｅ）ＮＢ１００５は、暗号化されたＥＡＰ成功メッセージ（すなわちＳＫ｛ＥＡＰ成功メッセージ｝をＴｒＥ１０１０に転送する（１７）。ＴｒＥ１０１０は、最初のＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージを認証するためのＡＵＴＨパラメータを生成するための入力としてＭＳＫのそれ自体のコピーを取得するものとする。ＡＵＴＨパラメータは、ＴｒＥ１０１０からＨ（ｅ）ＮＢ１００５に送信され、ＩＫＥｖ２を介して暗号化される。Ｈ（ｅ）ＮＢ１００５は、暗号化されたＡＵＴＨパラメータをＳＧＷ１０２０に送信する。

ＳＧＷ１０２０は、Ｈ（ｅ）ＮＢ１００５から受信したＡＵＴＨの正当性を解読し、チェックし、第２のＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージを認証するＡＵＴＨパラメータを計算する（１８）。ＳＧＷ１０２０は、Ｈ（ｅ）ＮＢ１００５がＣＦＧ＿ＲＥＱＵＥＳＴを介してリモートＩＰアドレスを要求した場合、構成ペイロード（ＣＦＧ＿ＲＥＰＬＹ）で割り当てられたリモートＩＰアドレスを送信するものとする。次いでＡＵＴＨパラメータは、構成ペイロード、セキュリティアソシエーション、およびＩＫＥｖ２パラメータの残りと共にＨ（ｅ）ＮＢ１００５に送信され、ＩＫＥｖ２交渉が終了する。

ＳＧＷ１０２０は、そのＨ（ｅ）ＮＢ１００５の古いＩＫＥ ＳＡがすでに存在していることを検出した場合、ＩＫＥ ＳＡを削除し、Ｈ（ｅ）ＮＢ１００５における古いＩＫＥ ＳＡを削除するために、Ｈ（ｅ）ＮＢ１００５に、ＤｅｌｅｔｅペイロードでＩＮＦＯＲＭＡＴＩＯＮＡＬ交換を送信する（１９）。

認証手順中のＨ（ｅ）ＮＢ ＴｒＥ、ＨＰＭ、およびＨ（ｅ）ＮＢ自体のバインドが使用され得る。いくつかの想定がなされる。ほとんどの機器が一意のＩＤを有すると仮定する。例えば、Ｈ（ｅ）ＮＢ＿ＥＩは、Ｈ（ｅ）ＮＢの製造業者によって割り当てられ、ＴｒＥ＿ＩＤは、ＴｒＥの製造業者によって割り当てられ、ＨＰＭ＿ＩＤは、ＨＰＭの製造業者によって割り当てられる。また、オペレータのコアネットワークを表すＳＧＷはＨ（ｅ）ＮＢとの相互認証を実行することも理解されたい。また、ＨＬＲ／ＡＡＡサーバがＨ（ｅ）ＮＢのＨＬＲ（ホームロケーションレジスタ）および認証センターを含むことが知られている。ＨＬＲは、Ｈ（ｅ）ＮＢ＿ＥＩ、ならびにそれぞれのＩＤ、すなわちＴｒＥ＿ＩＤ、Ｈ（ｅ）ＮＢ＿ＥＩ、およびＨＰＭ＿ＩＤの使用による、ＴｒＥ、Ｈ（ｅ）ＮＢ、およびＨＰＭのバインドの関係を表すすべてのＨＰＭ＿ＩＤに対応するＴｒＥ＿ＩＤのレコードを格納する。ＡＡＡサーバは、これらのレコードに基づくバインド認証を行う。

３つのＩＤをバインドする方法の一実施形態が開示される。Ｈ（ｅ）ＮＢは、ＳＧＷに、Ｈ（ｅ）ＮＢ＿ＥＩ、ＴｒＥ＿ＩＤ、およびオプションのＨＰＭ＿ＩＤを転送する。ＳＧＷは、Ｈ（ｅ）ＮＢから受信するＨ（ｅ）ＮＢ＿ＥＩをＨＬＲ／ＡＡＡサーバに転送する。ＨＬＲ／ＡＡＡサーバは、そのレコードに有するＨ（ｅ）ＮＢ＿ＥＩに対応するＴｒＥ＿ＩＤおよびＨＰＭ＿ＩＤを見つける。ＨＬＲのレコードに見つけられるＴｒＥ＿ＩＤおよびＨＰＭ＿ＩＤがＨ（ｅ）ＮＢから受信されたＳＧＷのものと同じである場合、それは、Ｈ（ｅ）ＮＢがＴｒＥおよびＨＰＭにバインドする正当な機器であることを確認することができる。

以下で記述するプロトコルによって運ばれる認証アサーションの信用性について、すべての機密データは、ＴｒＥおよびＨＰＭによって保護されたままであり得る。特に、Ｈ（ｅ）ＮＢおよびＨ（ｅ）ＮＢ＿ＥＩのバインド認証を表すＨ（ｅ）ＮＢの認証秘密は、ＴｒＥに安全に格納され得る。ＴｒＥは、ＴｒＥ＿ＩＤを安全に格納することもできる。さらに、ＨＰＭ＿ＩＤおよび対応する認証秘密は、ＨＰＭによってのみ安全に格納され、処理されるようにしてもよい。安全なチャネルは、ＴｒＥまたはＨＰＭからＳＧＷにこのデータをトランスポートするために使用することができる。

図１１は、３方向バインド認証の一実施形態を示す。最初に、ＴｒＥ１１１０は、それが安全に保持するＴｒＥ＿ＩＤおよびＨ（ｅ）ＮＢ＿ＥＩを取り出す（１）。次いでＴｒＥ１１１０は、ＡＫＡ ＲＡＮＤおよびＡＵＴＮを使用して、ＨＰＭ１１２０との安全なチャネルをセットアップする（２）。ＴｒＥ１１１０は、ＨＰＭ１１２０にＨＰＭ＿ＩＤを要求し、それを受信する（３）。ＨＰＭ＿ＩＤは、安全なチャネルを介して送信され、その下で保護される（４）。次いでＴｒＥ１１１０は、ＴｒＥ＿ＩＤ、Ｈ（ｅ）ＮＢ＿ＥＩ、およびＨＰＭ＿ＩＤをＳＧＷ１１３０に転送する（５）。

ＳＧＷ１１３０は、ＴｒＥ＿ＩＤ、Ｈ（ｅ）ＮＢ＿ＥＩ、およびＨＰＭ＿ＩＤをＨＬＲ／ＡＡＡ１１４０に転送する（６）。これらのＩＤを受信した後、ＨＬＲ／ＡＡＡ１１４０のＨＬＰ部分は、ＴｒＥ＿ＩＤおよびＨＰＭ＿ＩＤに対応するＨ（ｅ）ＮＢ＿ＥＩを検索する（７）。次いでＨＬＲ／ＡＡＡ１１４０のＡＡＡ部分は、ＴｒＥ＿ＩＤおよびＨＰＭ＿ＩＤに対応するＨ（ｅ）ＮＢ＿ＥＩによりＳＧＷ１１３０から受信したＨ（ｅ）ＮＢ＿ＥＩを検証する（８）。ＨＬＲ／ＡＡＡ１１４０のＨＬＲ部分は、次いでＳＧＷ１１３０に、ＴｒＥ１１１０およびＨＰＭ１１２０のバインド認証を送信する（９）。次にＳＧＷ１１３０は、ＴｒＥ１１１０およびＨＰＭ１１２０のバインド認証をＴｒＥ１１１０に転送する（１０）。ＴｒＥ１１１０は、安全なチャネルを介してＨＰＭ１１２０のバインド認証をＨＰＭ１１２０に転送する（１１）。

ＴｒＥがＨ（ｅ）ＮＢに密に統合されるとき（例えば、ＴｒＥがＨ（ｅ）ＮＢ上のチップであるなど）、ＴｒＥが物理的にＨ（ｅ）ＮＢ＿ＥＩにバインドされるため、ＴｒＥをＨ（ｅ）ＮＢに明確にバインドする必要がない場合がある。この場合、Ｈ（ｅ）ＮＢとＨＰＭとの間で２方向のバインドを取得することができる。事実上、この場合、Ｈ（ｅ）ＮＢの識別は、ＴｒＥの識別の認証によって認証することができ、すなわち、Ｈ（ｅ）ＮＢ＿ＥＩは、ＴｒＥ＿ＩＤとまったく同一である。

図１２は、２方向バインド認証の一実施形態を示す。最初に、ＴｒＥ１２１０は、それが安全に保持するＨ（ｅ）ＮＢ＿ＥＩを取り出す（１）。Ｈ（ｅ）ＮＢ＿ＥＩはＴｒＥ＿ＩＤと同じであることに留意されたい。ＴｒＥ１２１０は、ＡＫＡ ＲＡＮＤおよびＡＵＴＮを使用して、ＨＰＭ１２２０との安全なチャネルをセットアップする（２）。次にＴｒＥ１２１０は、安全なチャネル下でＨＰＭにＨＰＭ＿ＩＤを要求し（３）、それを受信する（４）。次いでＴｒＥ１２１０は、Ｈ（ｅ）ＮＢ＿ＥＩおよびＨＰＭ＿ＩＤをＳＧＷ１２３０に転送する（５）。

ＳＧＷ１２３０は、Ｈ（ｅ）ＮＢ＿ＥＩおよびＨＰＭ＿ＩＤをＨＬＲ／ＡＡＡ１２４０に転送する（６）。次いでＨＬＲ／ＡＡＡ１２４０のＨＬＲ部分は、ＨＰＭ＿ＩＤに対応するＨ（ｅ）ＮＢ＿ＥＩを検索する（７）。次いでＨＬＲ／ＡＡＡ１２４０のＡＡＡ部分は、ＳＧＷ１２３０から受信したＨ（ｅ）ＮＢ＿ＥＩをＨＰＭ＿ＩＤに対応するそのレコード内のＨ（ｅ）ＮＢ＿ＥＩと比較することによってＨ（ｅ）ＮＢ＿ＥＩを検証する（８）。次いでＨＬＲ／ＡＡＡ１２４０のＨＬＲ部分は、ＴｒＥ１２１０（この場合、Ｈ（ｅ）ＮＢを認証することに等しい）およびＨＰＭ１２２０のバインド認証をＳＧＷ１２３０に送信する（９）。次にＳＧＷ１２２０は、ＴｒＥ１２１０（およびすなわちＨ（ｅ）ＮＢの）およびＨＰＭ１２２０のバインド認証をＨ（ｅ）ＮＢのＴｒＥ１２１０に転送する（１０）。ＴｒＥ１２１０は、ＨＰＭ１２２０のバインド認証を、安全なチャネル下で保護されるＨＰＭ１１２０に転送する（１１）。

図１３は、認証および装置の妥当性検査が結合された方法で行われる方法の一実施形態を示す。この実施形態において、装置の妥当性検査および装置認証を結合するために、ＩＫＥｖ２プロトコルが使用される。しかし、装置または機器の認証に使用される他のプロトコルには、それだけには限定されないが、ＴＬＳ（トランスポートレイヤセキュリティ）、ＨＴＴＰＳ（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ ｓｅｃｕｒｅ）、ＯＭＡ ＤＭ、ＴＲ０６９などがある。

最初に、Ｈ（ｅ）ＮＢ１３１０のＴｒＥは、安全な起動を実行し、Ｈ（ｅ）ＮＢ１３１０の保全性をチェックする（１）。次いでＨ（ｅ）ＮＢ１３１０は、ＩＫＥｖ２セッションを開始し、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求メッセージをＳＧＷ１３２０に送信し、この場合、メッセージは、ＨＤＲ、ＳＡ（セキュリティアソシエーション）、ＫＥ（デルフィヘルマン鍵要素）、およびＮｉ（ｉｎｉｔｉａｔｏｒ ｎｏｎｃｅ）を含む（２）。この信号を受信すると、ＳＧＷ１３２０は、Ｈ（ｅ）ＮＢ１３１０に、ＨＤＲ、ＳＡ、ＫＥ、Ｎｒ（ｒｅｓｐｏｎｄｅｎｔ ｎｏｎｃｅ）、およびＣＥＲＴＲＥＱ（装置証明書の要求）を含むＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を送信する（３）。両端でＫＥを使用するとき、次にＨ（ｅ）ＮＢ１３１０およびＳＧＷ１３２０はそれぞれ、ＩＫＥｖ２セッション中にさらなるメッセージ交換の機密性および保全性保護に使用するための暗号鍵を生成する。

次いでＨ（ｅ）ＮＢ１３１０は、ＩＫＥ＿ＡＵＴＨ要求メッセージをＳＧＷ１３２０に送信し、この場合、メッセージは、デルフィヘルマンで生成された鍵によって機密性および保全性について保護される（４）。メッセージの内容は、保護されていないＨＤＲ（ヘッダー）、およびＳＡ（セキュリティアソシエーション）、ＴＳｉ（開始側のトラフィックセレクタ）、ＴＳｒ（応答側のトラフィックセレクタ）、ＩＤｉ（Ｈ（ｅ）ＮＢ１３１０のＮＡＩフォーマットのＩＤ）、ＩＤｒ（ＳＧＷ１３２０のＩＤ）、およびＣＰ（構成パラメータ）を含む保護されている部分、Ｈ（ｅ）ＮＢ１３１０によって実行される装置保全性チェックのプロセスまたは結果を示すデータ（ここではＶＡＬ＿ＤＡＴＡと呼ばれる）を含む通知メッセージ、Ｈ（ｅ）ＮＢが有効な装置証明書を保持することの証拠としてＨ（ｅ）ＮＢ１３１０のＴｒＥが計算するＡＵＴＨパラメータ、ＣＥＲＴＲＥＱ（サーバ側認証に使用されるべきサーバ側の証明書の要求）、およびＣＥＲＴ（Ｈ（ｅ）ＮＢ１３１０を認証するためにＳＧＷ１３２０が使用する装置証明書）を含む。

このメッセージを受信すると、ＳＧＷ１３２０は次いで装置保全性チェックデータ（ＶＡＬ＿ＤＡＴＡ）を抽出し、それを妥当性検査エンティティ１３３０に送信し（５）、これは次いで、転送されたＶＡＬ＿ＤＡＴＡおよびそれが有し得る他の参照情報を使用して、Ｈ（ｅ）ＮＢ１３１０の信用性または保全性を評価し（６）、次いで図の装置保全性ポイントからＨ（ｅ）ＮＢ１３１０が正しいことを評価した場合、ＳＧＷ１３２０に妥当性検査応答信号を返信する（７）。妥当性検査エンティティ１３３０から正の妥当性検査応答を受信すると、ＳＧＷ１３２０は、次いでＨ（ｅ）ＮＢ１３１０から受信したＨ（ｅ）ＮＢのＣＥＲＴ（証明書）を検証し、Ｈ（ｅ）ＮＢ１３１０を認証することができるかどうかをチェックする（８）ことができる。正である場合、ＳＧＷ１３２０は、次いでＨＤＲ（保護されていないヘッダー）および（それ自体のサーバ側認証の証拠の）ＡＵＴＨ、ＣＰ、ＳＡ、ＴＳｉ、およびＴＳｉ）を含む保護されている部分を含むＩＫＥ＿ＡＵＴＨ応答メッセージを送信することができる（９）。

あるいは、ＳＧＷ１３２０と妥当性検査エンティティ１３３０との間のＶＡＬ＿ＤＡＴＡをチェックするためのステップは、ＳＧＷ１３２０がＨ（ｅ）ＮＢの証明書を検証し、Ｈ（ｅ）ＮＢ１３１０を認証し、ＩＫＥ＿ＡＵＴＨ応答メッセージをＨ（ｅ）ＮＢ１３１０に送信した後で行うことができる。

Ｈ（ｅ）ＮＢ１３１０は、ＩＫＥ＿ＡＵＴＨ応答メッセージを受信すると、サーバＣＥＲＴを使用して、それがＳＧＷ１３２０から受信したことを検証することができる（１０）。

ＴｒＥは、Ｈ（ｅ）ＮＢの認証の位置情報を使用するためのセキュリティを保証することもできる。まず、Ｈ（ｅ）ＮＢのＴｒＥは、認証における取り出し、格納、保護、および使用を含めて、いくつかの機能を実行して、位置情報の処理のセキュリティを保護することができる。より詳細には、本明細書に記載される位置決め方法のうちの任意のものによって証明される任意の位置情報は、信頼される方法で格納され、処理され得る。このことは、こうした情報は、Ｈ（ｅ）ＮＢ ＴｒＥの保護下で格納され、処理され得ることを意味する。より詳細には、Ｈ（ｅ）ＮＢ ＴｒＥは、こうした情報のソースから暗号で保護された位置情報を受信することができる。また、これは、こうした暗号化された位置情報を安全に解読することもできる。さらに、これは、ＴｒＥに格納されている間、またはＴｒＥ内に安全に保護された鍵を使用して、暗号化による保護により外部で、位置情報を安全に保護することができる。ＴｒＥは、ＴｒＥ内で保持された、または外部メモリから位置情報を抽出することができる。ＴｒＥは、それをＳＧＷに転送する前に暗号化によって位置情報を保護することができる。またＴｒＥは、装置認証プロトコルに含めるために、暗号化された位置情報をＳＧＷに転送することができる。

また、位置登録（または証明書）プロセスまたは位置認証プロセス中、Ｈ（ｅ）ＮＢ ＴｒＥは、位置情報のＨＬＲへの送信中に、暗号化手段を使用して、Ｈ（ｅ）ＮＢがＨＬＲに送信する位置情報の保全性および／または機密性を保護することができる。また、これは、Ｈ（ｅ）ＮＢがＨＬＲから受信する任意の暗号で保護された位置関連の情報の、解読および保全性チェックを含む、安全な暗号化処理を提供することもできる。Ｈ（ｅ）ＮＢにおいてこれらの目的で使用される任意の暗号鍵は、Ｈ（ｅ）ＮＢ ＴｒＥによって保護することができる。さらに、Ｈ（ｅ）ＮＢ ＴｒＥは、機密の位置情報を取得し、格納し、処理することに関する、Ｈ（ｅ）ＮＢ内の機能の信憑性およびオプションで保全性を保証することもできる。

本明細書において、選択された特定の位置情報に基づく位置登録および位置認証の実施形態が開示される。

Ｈ（ｅ）ＮＢは、何らかのアクセス装置（例えば、ＤＳＬモデム、ケーブルモデム、ホームルータなど）を介してＩＰネットワークに接続され、広帯域アクセスプロバイダによって割り当てられたＩＰアドレスを有し得る。広帯域のアクセスネットワークの物理的な部分を地理的な情報とバインドすることによって、オペレータは、Ｈ（ｅ）ＮＢを探し出すことができる。

割り当てられたＩＰアドレス、ユーザ識別、およびＩＰアドレスに関連する位置情報は、Ｈ（ｅ）ＮＢの位置情報の最初の登録後、ネットワークデータベースに格納される。ＣＮ（コアネットワーク）は、ネットワークデータベースに対してクエリを行って、ＩＰアドレス、ＩＰアドレスにバインドされたポート番号、および／またはアドレス情報（経度および緯度の値）を取得することができる。位置ロック機構は、１）Ｈ（ｅ）ＮＢ位置情報の登録、および２）Ｈ（ｅ）ＮＢの位置の認証から成る。

位置登録は、Ｈ（ｅ）ＮＢが最初にオンになり、ＩＰのバックホールを介してコアネットワークに接続されると行われる。最初に、Ｈ（ｅ）ＮＢは、そのＩＰアドレスをこのメッセージで運ぶ要求メッセージをＨＬＲに送信する。次いでＨＬＲは、受信したＩＰアドレスを運ぶ位置情報クエリメッセージをネットワークデータベースに送信する。ＩＰアドレスに基づいて、データベースは、テーブルに対してクエリを行って、ＩＰアドレスにバインドされたポート番号、（入手可能な場合）経度および緯度など上記のＨ（ｅ）ＮＢのアクセス回線位置情報を取得する。次いでＨＬＲは、取得した情報に基づいて、Ｈ（ｅ）ＮＢの位置を決定する。次いでＨＬＲは、このＨ（ｅ）ＮＢの位置を登録する。次いでＨＬＲは、Ｈ（ｅ）ＮＢに対して応答メッセージで答える。位置登録後、ＨＬＲは、Ｈ（ｅ）ＮＢプロファイルの属性として、位置を格納することができ、それを位置判定基準と見なす。

位置認証は、Ｈ（ｅ）ＮＢがアクセスネットワークに要求を行うたびに行われる。したがって、登録の必要はない。最初に、Ｈ（ｅ）ＮＢは、そのＩＰアドレスを運ぶアクセス要求メッセージをＨＬＲに送信する。Ｈ（ｅ）ＮＢのＴｒＥは、その送信中に、それ自体によって保護された暗号鍵を使用して、こうしたＩＰアドレス情報の保全性および／または機密性を保護することができる。すべての暗号化処理は、ＴｒＥ内で行うことができる。

Ｈ（ｅ）ＮＢのＩＰアドレスを受信した後、ＨＬＲは、まずＩＰアドレスの保全性をチェックし、それがチェックした場合、位置情報を取得するために、再度データベースに対してクエリを行う。次いでＨＬＲは、Ｈ（ｅ）ＮＢから取得したアクセス回線位置情報が同じＨ（ｅ）ＮＢのデータベースから取り出した位置情報に対応するかどうかを認証する。それが同じである場合、ＨＬＲは、そのデータベースにＨ（ｅ）ＮＢの既存の位置を保持する。

ＨＬＲは、応答メッセージにおける位置認証結果でＨ（ｅ）ＮＢに応答する。Ｈ（ｅ）ＮＢから新しく取得されたアクセス回線位置情報がＨ（ｅ）ＮＢプロファイルにおけるものに一致していない場合、ＨＬＲは、Ｈ（ｅ）ＮＢアクセスを拒否するためのＨ（ｅ）ＮＢアクセス応答メッセージを戻し、原因値として「無効な位置」を示す。アクセス回線位置情報が一致する場合、ＨＬＲは、Ｈ（ｅ）ＮＢアクセスを許可するためのＨ（ｅ）ＮＢアクセス応答を戻す。

Ｈ（ｅ）ＮＢの位置は、位置認証を使用して認証することができるが、ＩＰアドレススプーフィング攻撃が可能であり得る。例えば、プロキシサーバは、Ｈ（ｅ）ＮＢが別のエリアに再配置されると、正当に登録されたＨ（ｅ）ＮＢと同じＩＰアドレスを獲得し得る。次いでこうしたプロキシサーバは、位置に関してのみ、それ自体を正当なＨ（ｅ）ＮＢとして隠すことができる。

Ｈ（ｅ）ＮＢがＨＬＲから情報またはメッセージを受信する上記のステップのうちの任意のものにおいて、こうした任意の情報が暗号で保護されている場合、こうした情報またはメッセージの解読および保全性チェックは、Ｈ（ｅ）ＮＢ ＴｒＥ内で、Ｈ（ｅ）ＮＢ ＴｒＥによって保護される鍵を使用することによって実行され得る。

次に、隣接するマクロセルに基づいた一実施形態が開示される。マクロセルの情報に基づいて探し出すためには、Ｈ（ｅ）ＮＢは、マクロセルのカバレージにインストールされ、３Ｇまたは２Ｇ受信機を有していなければならず、Ｈ（ｅ）ＮＢの隣接マクロ３Ｇまたは２Ｇセルをスキャンする受信機の作業状態に切り替えることができる。マクロセルに基づく位置ロック機構は、上記のものと似ているが、位置情報は、ＰＬＭＮ（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）ＩＤ、ＬＡＩ（位置エリア情報）、またはＣｅｌｌ ＩＤなど、マクロセルについての情報の形で提示される。

最初のステップは、Ｈ（ｅ）ＮＢ位置情報を登録することである。Ｈ（ｅ）ＮＢは、オンになった後、隣接するマクロセルをスキャンする。次いでＨ（ｅ）ＮＢは、Ｈ（ｅ）ＮＢ要求メッセージをＨＬＲに送信する。メッセージは、位置エリアなどの情報、および隣接するマクロセルのセルＩＤを運ぶ。Ｈ（ｅ）ＮＢのＴｒＥは、それ自体によって保護された鍵を使用して、こうした位置エリアおよびセルＩＤ情報の保全性、および／または機密性を保護することができる。すべての暗号化処理は、ＴｒＥ内で行うことができる。ＨＬＲは、隣接するマクロセルのセルＩＤをＨ（ｅ）ＮＢプロファイルの属性として登録し、Ｈ（ｅ）ＮＢ応答メッセージをＨ（ｅ）ＮＢに送信する。

次のステップは、Ｈ（ｅ）ＮＢ位置を認証することである。Ｈ（ｅ）ＮＢは、アクセス要求メッセージをＨＬＲに送信する。メッセージは、隣接するマクロセルの位置エリアおよびセルＩＤなどの情報を運ぶ。Ｈ（ｅ）ＮＢのＴｒＥは、それ自体によって保護された鍵を使用して、ＨＬＲへの送信中に、こうした位置エリアおよびセルＩＤ情報の保全性、および／または機密性を暗号で保護することができる。すべての暗号化処理は、ＴｒＥ内で行うことができる。ＨＬＲは、隣接するマクロセルの情報を保存されたＨ（ｅ）ＮＢプロファイルと比較して、Ｈ（ｅ）ＮＢがバインドされたセルまたは位置エリアを介してネットワークに接続できるかどうかを決定する。隣接するマクロセルの情報がＨ（ｅ）ＮＢプロファイルに一致していない場合、ＨＬＲは、Ｈ（ｅ）ＮＢアクセスを拒否するためのＨ（ｅ）ＮＢアクセス応答メッセージを戻し、原因値として「無効な位置」を示す。隣接するマクロセルの情報がＨ（ｅ）ＮＢプロファイルに一致する場合、ＨＬＲは、Ｈ（ｅ）ＮＢアクセスを許可するためのＨ（ｅ）ＮＢアクセス応答を戻す。

Ｈ（ｅ）ＮＢがＨＬＲから情報またはメッセージを受信する上記の手順のうちの任意のものにおいて、こうした任意の情報が暗号で保護されている場合、こうした情報またはメッセージの解読および保全性チェックは、Ｈ（ｅ）ＮＢ ＴｒＥ内で、Ｈ（ｅ）ＮＢ ＴｒＥによって保護される鍵を使用することによって実行され得る。

マクロセルは、広いエリアのカバレージを有する。したがって、単にセル情報を使用することは、いくつかの使用ケースの精度要件を満たさない場合がある。ＩＰアドレスとマクロセル情報との組み合わせの使用は、精度を向上させることができる。

ＩＰアドレスと隣接するマクロセルとの組み合わせに基づいた一実施形態が開示される。最初のステップは、Ｈ（ｅ）ＮＢ位置情報登録である。Ｈ（ｅ）ＮＢは、そのＩＰアドレスおよび隣接セルＩＤをこのメッセージで運ぶ要求メッセージをＨＬＲに送信する。Ｈ（ｅ）ＮＢのＴｒＥは、それ自体によって保護された暗号鍵を使用して、ＨＬＲへの送信中に、ＩＰアドレスおよびセルＩＤ情報の保全性、および／または機密性を暗号で保護することができる。すべての暗号化処理は、ＴｒＥ内で行うことができる。

次いでＨＬＲは、受信したＩＰアドレスを運ぶ位置情報クエリメッセージを固定のネットワークデータベースに送信する。ＩＰアドレスに基づいて、ＨＬＲは、Ｈ（ｅ）ＮＢ ＩＰアドレスにバインドされたアクセス回線位置情報を取得するために、データベースに対してクエリを行う。アクセス回線位置情報および隣接するマクロセルＩＤによって、ＨＬＲは、Ｈ（ｅ）ＮＢのホームエリアを決定する。ＨＬＲは、このＨ（ｅ）ＮＢのアクセス回線位置情報を、受信したセルＩＤと共に、Ｈ（ｅ）ＮＢの属性として格納する。

次のステップは、Ｈ（ｅ）ＮＢ位置を認証することである。ＨＬＲは、Ｈ（ｅ）ＮＢからアクセス要求メッセージを受信し、これは、そのＩＰアドレスおよび周囲のマクロセルのセルＩＤを運ぶ。新しいＩＰアドレスによって、ＨＬＲは、アクセス回線位置情報を得るために、データベースに対して再度クエリを行う。次いでＨＬＲは、新しく取得されたアクセス回線位置情報が格納されたものと同じであるか、およびさらに受信されたセルＩＤが格納されたものと同じであるかどうかを判定する。それらがいずれも同じである場合、Ｈ（ｅ）ＮＢ位置は、変更されない。ＨＬＲは次に、Ｈ（ｅ）ＮＢに対して、アクセス応答メッセージ内の位置認証結果を答える。

Ｈ（ｅ）ＮＢがＨＬＲから情報またはメッセージを受信する上記の手順のうちの任意のものにおいて、こうした任意の情報が暗号で保護されている場合、こうした情報またはメッセージの解読および保全性チェックは、Ｈ（ｅ）ＮＢ ＴｒＥ内で、Ｈ（ｅ）ＮＢ ＴｒＥによって保護される鍵を使用することによって実行され得る。

Ｈ（ｅ）ＮＢは、別の未登録のアドレスに移動した場合でさえ、Ｈ（ｅ）ＮＢは、同じマクロセル内に依然として配置され得ることに留意されたい。この配置は、位置認証方式のセキュリティを向上させ得る。

ＧＰＳ（全地球測位システム）に基づく一実施形態が開示される。Ｈ（ｅ）ＮＢがＧＰＳ機能を組み込んでいるとき、その位置情報は、Ｈ（ｅ）ＮＢ内のＧＰＳを介して取得することができ、その後、アクセス要求中にＨ（ｅ）ＮＢからＣＮに送信することができる。しかし、いくつかの室内環境では、ＧＰＳがあまり上手く働かない場合がある。

Ｈ（ｅ）ＮＢのＴｒＥは、それ自体によって保護された鍵を使用して、それがＨＬＲに送信する任意のＧＰＳ位置情報の保全性および／または機密性を暗号で保護することができる。Ｈ（ｅ）ＮＢのＴｒＥは、ＴｒＥ内で保護された鍵を使用して、Ｈ（ｅ）ＮＢがＨＬＲから受信する任意の暗号で保護された情報またはメッセージのすべての暗号化処理を安全に処理することができる。

ＧＰＳベースの位置証明方法のセキュリティも、特にＧＰＳ機能が別のチップに分離されている場合、耐改ざん（ｔａｍｐｅｒ−ｒｅｓｉｓｔａｎｔ）または改ざん明示（ｔａｍｐｅｒ−ｅｖｉｄｅｎｔ）ＧＰＳ装置を使用することによって保護され得る。例えばセキュリティ堅牢化ＧＰＳチップを使用することができる。

別の実施形態において、Ｈ（ｅ）ＮＢのＴｒＥは、定期的に、および／またはいくつかの予め定義されたイベントの発現後、「最後の適切な位置」を安全に格納することもできる。こうした「最後の適切な位置」は、ネットワークオペレータの位置サーバによって証明される位置情報である。Ｈ（ｅ）ＮＢの新しい起動後、Ｈ（ｅ）ＮＢのＴｒＥは、格納された「最後の適切な位置」を調べ、それを、ＴｒＥがその位置識別方法から新しく取得した位置と比較することができる。次いでＴｒＥは、こうした比較の結果を使用して、Ｈ（ｅ）ＮＢの位置の変化の可能性があるかどうかを自主的に決定することができる。ＴｒＥは、ネットワークにおける位置サーバにこうした結果を報告することもできる。

次に、Ｈ（ｅ）ＮＢ位置ポリシーのオプションおよび構成について説明する。どの手法を使用すべきかは、例えばオペレータが要求するセキュリティレベルおよび精度レベル、Ｈ（ｅ）ＮＢの機能、既存のマクロカバレージなど、いくつかの要因によって決まる。ポリシーは、使用すべき方法を決定することを助けるために適用され得る。ポリシーは、Ｈ（ｅ）ＮＢにおいて予め構成され、Ｈ（ｅ）ＮＢが自動的にそれに適応することが示唆される。位置証明方法の任意のセキュリティポリシーは、Ｈ（ｅ）ＮＢのＴｒＥから管理することができる。

ＩＰアドレスのみを使用することは、十分に安全ではない場合がある。ＧＰＳは、いくつかの室内環境では上手く働かない場合があり、Ｈ（ｅ）ＮＢにコストを追加する可能性もある。実現性および安全要件を考慮して、ＩＰアドレスおよび隣接するマクロセルに基づく位置ロック機構を検討することができる。この方法は、ポリシーリストにおいて第一にランク付けされ得る。マクロセルカバレージがない場合、ポリシーにおける優先順に応じて他の方法を使用することができる。ＧＰＳがコストに加算され、すべてのＨ（ｅ）ＮＢがＧＰＳを搭載しているとは限らないため、ＧＰＳベースの位置決め方法は、より低い優先順で配置され得る。表５に示されるように、シナリオおよびポリシーの様々な組み合わせ、および示されていないものも存在し得る。

（実施形態）
１．ＴｒＥ（信頼された環境）を含むＨ（ｅ）ＮＢ（Ｈｏｍｅ Ｎｏｄｅ Ｂ／Ｈｏｍｅ ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）。

２．Ｈ（ｅ）ＮＢ機能モジュールを含む実施形態１に記載のＨ（ｅ）ＮＢ。

３．複数のレベルのセキュリティを提供するように構成されたＴｒＥとＨ（ｅ）ＮＢ機能モジュールとの間のインターフェイスを含む前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

４．ＴｒＥは、Ｈ（ｅ）ＮＢ機能モジュールと対話して、セキュリティおよび認証を提供するように構成された前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

５．セキュリティおよび認証は、ＴｒＥまたはＨ（ｅ）ＮＢの認証および条件付きホスティングパーティ認証のうちの少なくとも１つを含む前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

６．ＴｒＥは、鍵、秘密、機密データおよびプログラムのうちの少なくとも１つをセキュリティ保護するための格納エリアを含む前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

７．ＴｒＥは、ＴｒＥまたはＨ（ｅ）ＮＢのうちの少なくとも１つのＡＫＡ（認証および鍵合意）および証明書ベースの認証のうちの少なくとも１つを実行するための安全な実行環境を含む前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

８．ＴｒＥは、安全な実行環境が、少なくともＴｒＥの妥当性をネットワークに対して安全に示すことに関連するセキュリティセンシティブな操作を実行することを含む前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

９．安全な実行環境は、Ｈ（ｅ）ＮＢの位置を保護し、妥当性検査を行う前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

１０．ネットワーク許可は、位置が妥当性検査されるという条件で提供される前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

１１．ホスティングパーティのＡＫＡ（認証および鍵合意）ベースの認証を提供するＨＰＭ（ホスティングパーティモジュール）を含み、ＨＰＭは、ＴｒＥに接続される前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

１２．ＨＰＭは、ＵＩＣＣ（ユニバーサル集積回路カード）によって組み込まれる前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

１３．ＴｒＥは、Ｈ（ｅ）ＮＢの装置保全性の妥当性検査を行い、装置認証指示と結合された保全性指示をＳＧＷ（セキュリティゲートウェイ）に送信するように構成された前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

１４．ＴｒＥは、多重認証をサポートするように構成された前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

１５．ＴｒＥは、相互認証をサポートするように構成された前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

１６．ＴｒＥは、Ｈ（ｅ）ＮＢ、ＴｒＥ、および条件付きホスト側プラットフォーム（ｃｏｎｄｉｔｉｏｎａｌ ｈｏｓｔｉｎｇ ｐｌａｔｆｏｒｍ）のレコードおよび識別に基づいてバインド認証を実行するように構成された前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

１７．ＴｒＥは、位置ロックを実行するように構成され、位置ロックは、Ｈ（ｅ）ＮＢ位置情報の登録、および／またはＨ（ｅ）ＮＢの位置情報の認証を含む前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

１８．位置情報は、隣接するマクロセルに基づく前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

１９．位置情報は、ＩＰアドレスに基づく前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

２０．位置情報は、ＩＰアドレスおよびマクロセルに基づく前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

２１．位置情報は、全地球測位システムに基づく前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

２２．認証のタイプは、ＩＫＥｖ２プロトコルのＩＫＥ＿ＡＵＴＨ要求を使用して示される前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

２３．ＩＫＥ＿ＡＵＴＨ要求における所定のパラメータは、証明書ベースのＨ（ｅ）ＮＢもしくはＴｒＥ認証またはＥＡＰ−ＡＫＡ（拡張認証プロトコル−認証鍵合意）ベースのＨ（ｅ）ＮＢもしくはＴｒＥ認証のうちの１つを示す前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

２４．条件付きホスティングパーティ認証は、ＥＡＰ−ＡＫＡ（拡張認証プロトコル−認証鍵合意）を使用して実行される前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

２５．Ｈ（ｅ）ＮＢ機能モジュール、ＴｒＥおよびネットワークの間で対話するプロトコルは、ＩＫＥｖ２（インターネット鍵交換）、ＴＬＳ（トランスポートレイヤセキュリティ）、広帯域フォーラムＴＲ（技術要件）０６９、またはＯＭＡ（オープンモバイルアライアンス） ＤＭ（装置管理）のうちの少なくとも１つを含む前記実施形態のいずれかに記載のＨ（ｅ）ＮＢ。

２６．Ｈ（ｅ）ＮＢ（Ｈｏｍｅ Ｎｏｄｅ Ｂ／Ｈｏｍｅ ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）を認証するための方法であって、ネットワークへの安全なアクセスを開始するステップを含む方法。

２７．装置認証、または装置認証およびホスティングパーティ認証のうちの１つを示す第１の要件を受信するステップを含む実施形態２６に記載の方法。

２８．証明ベースの認証またはＥＡＰ−ＡＫＡ（拡張認証プロトコル−認証および鍵合意）認証のうちの１つを示す第２の要件を受信するステップを含む実施形態２６〜２７のいずれかに記載の方法。

２９．装置認証、または装置認証およびホスティングパーティ認証のうちの１つを支持する第１のパラメータで応答するステップを含む実施形態２６〜２８のいずれかに記載の方法。

３０．証明ベースの認証またはＥＡＰ−ＡＫＡ認証のうちの１つを支持する第２のパラメータで応答するステップを含む実施形態２６〜２９のいずれかに記載の方法。

３１．第１の要件および第２の要件が第１のパラメータおよび第２のパラメータと一致するという条件下で第１の要件および第２の要件を使用して認証を実行するステップを含む実施形態２６〜３０のいずれかに記載の方法。

３２．Ｈ（ｅ）ＮＢ識別を使用して取り出される認証プロファイルに基づく第１のパラメータ応答の受け取りを受信するステップを含む実施形態２６〜３１のいずれかに記載の方法。

３３．Ｈ（ｅ）ＮＢ識別を使用して取り出される認証プロファイルに基づく第１のパラメータ応答の拒否を受信するステップを含む実施形態２６〜３２のいずれかに記載の方法。

３４．ホスティングパーティ認証を支持する別の第１のパラメータで応答するステップを含む実施形態２６〜３３のいずれかに記載の方法。

３５．少なくともＴｒＥ（信頼された環境）またはＨ（ｅ）ＮＢのプラットフォームの信用性または予測される状態の少なくとも１つをネットワークに対して示す情報を提供するステップを含む実施形態２６〜３４のいずれかに記載の方法。

３６．情報は、ＴｒＥ内で保護される秘密鍵によって署名される実施形態２６〜３５のいずれかに記載の方法。

３７．情報は、ネットワークおよびアプリケーションに対するアクセス権を決定するために、ネットワークによって使用される実施形態２６〜３６のいずれかに記載の方法。

３８．プラットフォームの妥当性のＴｒＥによる暗号で保護された証拠をネットワークに提供するステップを含む実施形態２６〜３７のいずれかに記載の方法。

３９．ＴｒＥによって、第１および第２の要件の保全性をチェックするステップを含む実施形態２６〜３８のいずれかに記載の方法。

４０．ＴｒＥによって、ネットワークに識別情報を転送するステップを含む実施形態２６〜３９のいずれかに記載の方法。

４１．ＴｒＥおよびＨＰＭ（ホスティングパーティモジュール）を使用することによってホスティングパーティ認証を実行するステップを含み、ＴｒＥは、ＨＰＭ情報を保護し、ＨＰＭと安全に通信する実施形態２６〜４０のいずれかに記載の方法。

４２．ＴｒＥまたはＨ（ｅ）ＮＢの少なくとも１つの識別値、およびＨＰＭの１つの識別値を使用してＴｒＥ、Ｈ（ｅ）ＮＢ、およびＨＰＭをバインドするステップを含む実施形態２６〜４１のいずれかに記載の方法。

４３．Ｈ（ｅ）ＮＢ機能モジュール、ＴｒＥおよびネットワークの間で対話するプロトコルは、ＩＫＥｖ２（インターネット鍵交換）、ＴＬＳ（トランスポートレイヤセキュリティ）、広帯域フォーラムＴＲ（技術要件）０６９、またはＯＭＡ（オープンモバイルアライアンス） ＤＭ（装置管理）のうちの少なくとも１つを含む実施形態２６〜４２のいずれかに記載の方法。

４４．ＴｒＥ（信頼された環境）にＨ（ｅ）ＮＢ位置情報を安全に格納するステップを含む、Ｈ（ｅ）ＮＢ（Ｈｏｍｅ Ｎｏｄｅ Ｂ／Ｈｏｍｅ ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）をネットワークに対して認証するための方法。

４５．格納されたＨ（ｅ）ＮＢ位置情報をＴｒＥを介してネットワークに安全に送信するステップを含む実施形態４４に記載の方法。

４６．ＴｒＥにおけるＨ（ｅ）ＮＢの最後の適切な位置を安全に格納するステップを含む実施形態４４〜４５のいずれかに記載の方法。

４７．ＴｒＥを使用して格納された「最後の適切な位置」を新しく取得された位置情報と比較するステップを含む実施形態４４〜４６のいずれかに記載の方法。

４８．ＴｒＥによる比較の結果を、ネットワーク上の位置サーバに対して示すステップを含む実施形態４４〜４７のいずれかに記載の方法。

４９．Ｈ（ｅ）ＮＢ、ＴｒＥ、およびネットワークの間で対話するプロトコルは、ＩＫＥｖ２（インターネット鍵交換）、ＴＬＳ（トランスポートレイヤセキュリティ）、広帯域フォーラムＴＲ（技術要件）０６９、またはＯＭＡ（オープンモバイルアライアンス） ＤＭ（装置管理）のうちの少なくとも１つを含む実施形態４４〜４８のいずれかに記載の方法。

上記では特徴および要素が特定の組み合わせで記載されているが、各特徴または要素は、他の特徴および要素無しに単独で、または他の特徴および要素の有無にかかわらず様々な組み合わせで使用することができる。本明細書に提供された方法またはフロー図は、汎用コンピュータまたはプロセッサによって実行するために、コンピュータ可読記憶媒体に組み込まれるコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実施することができる。コンピュータ可読記憶媒体の例には、ＲＯＭ（読み取り専用メモリ）、ＲＡＭ（ランダムアクセスメモリ）、レジスタ、キャッシュメモリ、半導体メモリ装置、内蔵ハードディスクおよび取外式ディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびＤＶＤ（デジタルビデオディスク）などの光媒体などがある。

適したプロセッサには、一例として、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、ＤＳＰ（デジタル信号プロセッサ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ（特定用途向け集積回路）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）回路、他の任意のタイプのＩＣ（集積回路）および／または状態機械などがある。

ソフトウェアと関連するプロセッサは、ＷＴＲＵ（無線送受信ユニット）、ＵＥ（ユーザ機器）、端末、基地局、ＲＮＣ（無線ネットワークコントローラ）、または任意のホストコンピュータで使用するための無線周波数送受信機を実施するために使用することができる。ＷＴＲＵは、カメラ、ビデオカメラモジュール、テレビ電話、スピーカフォン、振動装置、スピーカ、マイクロフォン、テレビ送受信機、ハンズフリーヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、ＦＭ（周波数変調）無線ユニット、ＬＣＤ（液晶ディスプレイ）表示装置、ＯＬＥＤ（有機発光ダイオード）表示装置、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および／または任意のＷＬＡＮ（無線ローカルエリアネットワーク）またはＵＷＢ（超広帯域）モジュールなど、ハードウェアおよび／またはソフトウェアに実装されるモジュールと共に使用することができる。

Claims (35)

1. Ｈ（ｅ）ＮＢ（Ｈｏｍｅ Ｎｏｄｅ Ｂ／Ｈｏｍｅ ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）であって、
   ＴｒＥ（信頼された環境）と、
   Ｈ（ｅ）ＮＢ機能モジュールと、
   複数のレベルのセキュリティを提供するように構成された前記ＴｒＥとＨ（ｅ）ＮＢ機能モジュールとの間のインターフェイスと
   を含み、前記ＴｒＥは、前記Ｈ（ｅ）ＮＢ機能モジュールと対話して、セキュリティおよび認証を提供するように構成され、
   セキュリティおよび認証は、ＴｒＥまたはＨ（ｅ）ＮＢ認証および条件付きホスティングパーティのうちの少なくとも１つを含む
   ことを特徴とするＨ（ｅ）ＮＢ。
2. 前記ＴｒＥは、
   鍵、秘密、機密データおよびプログラムのうちの少なくとも１つをセキュリティ保護するための格納エリアと、
   前記ＴｒＥまたはＨ（ｅ）ＮＢのうちの少なくとも１つのＡＫＡ（認証および鍵合意）および証明書ベースの認証のうちの少なくとも１つを実行するための安全な実行環境と
   を含むことを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
3. 前記安全な実行環境は、少なくとも前記ＴｒＥの妥当性をネットワークに対して安全に示すことに関連するセキュリティセンシティブな操作を実行することを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
4. 前記安全な実行環境は、前記Ｈ（ｅ）ＮＢの位置を保護し、妥当性検査を行うことを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
5. ネットワーク許可は、位置が妥当性検査されるという条件で提供されることを特徴とする請求項４に記載のＨ（ｅ）ＮＢ。
6. ホスティングパーティのＡＫＡ（認証および鍵合意）ベースの認証を提供するＨＰＭ（ホスティングパーティモジュール）をさらに含み、前記ＨＰＭは、前記ＴｒＥに接続される
   ことを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
7. 前記ＨＰＭは、ＵＩＣＣ（ユニバーサル集積回路カード）によって組み込まれることを特徴とする請求項６記載のＨ（ｅ）ＮＢ。
8. 前記ＴｒＥは、前記Ｈ（ｅ）ＮＢの装置保全性の妥当性検査を行い、装置認証指示と結合された保全性指示をＳＧＷ（セキュリティゲートウェイ）に送信するように構成されたことを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
9. 前記ＴｒＥは、多重認証をサポートするように構成されたことを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
10. 前記ＴｒＥは、相互認証をサポートするように構成されたことを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
11. 前記ＴｒＥは、前記Ｈ（ｅ）ＮＢ、ＴｒＥ、および条件付きホスト側プラットフォームのレコードおよび識別に基づいてバインド認証を実行するように構成されたことを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
12. 前記ＴｒＥは、位置ロックを実行するように構成され、位置ロックは、Ｈ（ｅ）ＮＢ位置情報の登録、および／または前記Ｈ（ｅ）ＮＢの位置情報の認証を含むことを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
13. 位置情報は、隣接するマクロセルに基づくことを特徴とする請求項１２に記載のＨ（ｅ）ＮＢ。
14. 位置情報は、ＩＰアドレスに基づくことを特徴とする請求項１２に記載のＨ（ｅ）ＮＢ。
15. 位置情報は、ＩＰアドレスおよびマクロセルに基づくことを特徴とする請求項１２に記載のＨ（ｅ）ＮＢ。
16. 位置情報は、全地球測位システムに基づくことを特徴とする請求項１２に記載のＨ（ｅ）ＮＢ。
17. 認証のタイプは、ＩＫＥｖ２プロトコルのＩＫＥ＿ＡＵＴＨ要求を使用して示されることを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
18. ＩＫＥ＿ＡＵＴＨ要求における所定のパラメータは、証明書ベースのＨ（ｅ）ＮＢもしくはＴｒＥ認証またはＥＡＰ−ＡＫＡ（拡張認証プロトコル−認証鍵合意）ベースのＨ（ｅ）ＮＢもしくはＴｒＥ認証のうちの１つを示すことを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
19. 前記条件付きホスティングパーティ認証は、ＥＡＰ−ＡＫＡ（拡張認証プロトコル−認証鍵合意）を使用して実行されることを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
20. 前記Ｈ（ｅ）ＮＢ機能モジュール、前記ＴｒＥおよびネットワークの間で対話するプロトコルは、ＩＫＥｖ２（インターネット鍵交換）、ＴＬＳ（トランスポートレイヤセキュリティ）、広帯域フォーラムＴＲ（技術要件）０６９、またはＯＭＡ（オープンモバイルアライアンス） ＤＭ（装置管理）のうちの少なくとも１つを含むことを特徴とする請求項１に記載のＨ（ｅ）ＮＢ。
21. Ｈ（ｅ）ＮＢ（Ｈｏｍｅ Ｎｏｄｅ Ｂ／Ｈｏｍｅ ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）をネットワークに対して認証するための方法であって、
    前記ネットワークへの安全なアクセスを開始するステップと、
    装置認証、または装置認証およびホスティングパーティ認証のうちの１つを示す第１の要件を受信するステップと、
    証明ベースの認証またはＥＡＰ−ＡＫＡ（拡張認証プロトコル−認証および鍵合意）認証のうちの１つを示す第２の要件を受信するステップと、
    装置認証、または装置認証およびホスティングパーティ認証のうちの１つを支持する第１のパラメータで応答するステップと、
    証明ベースの認証またはＥＡＰ−ＡＫＡ認証のうちの１つを支持する第２のパラメータで応答するステップと、
    前記第１の要件および前記第２の要件が前記第１のパラメータおよび前記第２のパラメータと一致するという条件下で前記第１の要件および前記第２の要件を使用して認証を実行するステップと
    を含むことを特徴とする方法。
22. Ｈ（ｅ）ＮＢ識別を使用して取り出される認証プロファイルに基づく前記第１のパラメータ応答の受け取りを受信するステップ
    をさらに含むことを特徴とする請求項２１に記載の方法。
23. Ｈ（ｅ）ＮＢ識別を使用して取り出される認証プロファイルに基づく前記第１のパラメータ応答の拒否を受信するステップ
    をさらに含むことを特徴とする請求項２１に記載の方法。
24. ホスティングパーティ認証を支持する別の第１のパラメータで応答するステップ
    をさらに含むことを特徴とする請求項２１に記載の方法。
25. 少なくともＴｒＥ（信頼された環境）または前記Ｈ（ｅ）ＮＢのプラットフォームの信用性または予測される状態の少なくとも１つを前記ネットワークに対して示す情報を提供するステップ
    をさらに含むことを特徴とする請求項２１に記載の方法。
26. 前記情報は、前記ＴｒＥ内で保護される秘密鍵によって署名されることを特徴とする請求項２５に記載の方法。
27. 前記情報は、前記ネットワークおよびアプリケーションに対するアクセス権を決定するために、前記ネットワークによって使用されることを特徴とする請求項２５に記載の方法。
28. プラットフォームの妥当性のＴｒＥによる暗号で保護された証拠を前記ネットワークに提供するステップ
    をさらに含むことを特徴とする請求項２１に記載の方法。
29. ＴｒＥによって、前記第１および第２の要件の前記保全性をチェックするステップと、
    ＴｒＥによって、前記ネットワークに識別情報を転送するステップと
    をさらに含むことを特徴とする請求項２１に記載の方法。
30. 前記ＴｒＥおよびＨＰＭ（ホスティングパーティモジュール）を使用することによってホスティングパーティ認証を実行するステップをさらに含み、前記ＴｒＥは、ＨＰＭ情報を保護し、前記ＨＰＭと安全に通信する
    ことを特徴とする請求項２１に記載の方法。
31. ＴｒＥまたはＨ（ｅ）ＮＢの少なくとも１つの識別値、および前記ＨＰＭの１つの識別値を使用して前記ＴｒＥ、Ｈ（ｅ）ＮＢ、およびＨＰＭをバインドするステップ
    をさらに含むことを特徴とする請求項２１に記載の方法。
32. 前記Ｈ（ｅ）ＮＢ機能モジュール、ＴｒＥおよびネットワークの間で対話するプロトコルは、ＩＫＥｖ２（インターネット鍵交換）、ＴＬＳ（トランスポートレイヤセキュリティ）、広帯域フォーラムＴＲ（技術要件）０６９、またはＯＭＡ（オープンモバイルアライアンス） ＤＭ（装置管理）のうちの少なくとも１つを含むことを特徴とする請求項２１に記載の方法。
33. Ｈ（ｅ）ＮＢ（Ｈｏｍｅ Ｎｏｄｅ Ｂ／Ｈｏｍｅ ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）をネットワークに対して認証するための方法であって、
    ＴｒＥ（信頼された環境）にＨ（ｅ）ＮＢ位置情報を安全に格納するステップと、
    前記格納されたＨ（ｅ）ＮＢ位置情報を前記ＴｒＥを介して前記ネットワークに安全に送信するステップと
    を含むことを特徴とする方法。
34. 前記ＴｒＥに前記Ｈ（ｅ）ＮＢの最後の適切な位置を安全に格納するステップと、
    前記ＴｒＥを使用して前記格納された「最後の適切な位置」を新しく取得された位置情報と比較するステップと、
    前記ＴｒＥによる前記比較の結果を、前記ネットワーク上の位置サーバに対して示すステップと
    をさらに含むことを特徴とする請求項３３に記載の方法。
35. 前記Ｈ（ｅ）ＮＢ、前記ＴｒＥおよび前記ネットワークの間で対話するプロトコルは、ＩＫＥｖ２（インターネット鍵交換）、ＴＬＳ（トランスポートレイヤセキュリティ）、広帯域フォーラムＴＲ（技術要件）０６９、またはＯＭＡ（オープンモバイルアライアンス） ＤＭ（装置管理）のうちの少なくとも１つを含むことを特徴とする請求項３３に記載の方法。

Images