以下で言及するとき、「WTRU(無線送受信ユニット)」という用語は、それだけには限定されないが、UE(ユーザ機器)、移動局、固定式または携帯式の加入者ユニット、ページャ、携帯電話、PDA(個人用デジタル補助装置)、コンピュータ、または無線環境で動作することができる他の任意のタイプのユーザ装置を含む。以下で言及するとき、「基地局」という用語は、それだけに限定されないが、Node−B、サイトコントローラ、AP(アクセスポイント)、または無線環境で動作することができる他の任意のタイプのインターフェイス装置を含む。
本明細書で開示されているのは、無線通信のためのhome evolved node bおよびhome node b(まとめてH(e)NB)を配置するためのシステムおよびアーキテクチャ、およびH(e)NBとSGW(セキュリティゲートウェイ)との間の認証シグナリング、および無線通信を確立するために使用され得る認証方法の説明である。
図1は、H(e)NB110の配置のためのセキュリティシステムアーキテクチャ100の例である。H(e)NB110は、SGW130を介してオペレータのコアネットワーク120にアクセスする。SGW130は、H(e)NB110との相互認証を実行する際のオペレータのコアネットワーク120を表す。相互認証は、認証サーバまたはPKI(公開鍵基盤)のサポートを必要とする場合がある。H(e)NB110とSGW130との間のバックホール140は、安全ではない場合があり、バックホールリンク140で送信される情報を保護するために、セキュリティトンネルがH(e)NB110とSGW130との間に確立されてもよい。H(e)N110は、エアインターフェイスを介してWTRU150と通信する。
図2は、H(e)NB200の一実施形態の機能ブロック図を示す。H(e)NB200は、TrE(信頼された環境)210を含み、オプションで、HPM(ホスティングパーティモジュール)215に接続される、またはそれと通信する(まとめて「接続される」)ことができる。例えば、HPM215は、UICC(ユニバーサル集積回路カード)によって組み込まれ得る。
TrE210は、安全な実行環境212および安全格納エリア214をさらに含む。TrE210は、MPU(主処理装置)/アプリケーションプロセッサ220、1つまたは複数のUMTS(ユニバーサル移動体通信システム)セルラーモデムプロセッサ225、電力ユニットおよびローカルインターフェイスを含む周辺装置230、位置決め装置240、1つまたは複数の非UMTSセルラーまたは非セルラーのモデムプロセッサ245、およびクロックおよびタイム装置(clock and time device)250にさらに接続される。本明細書に列挙されている構成要素は例示であって、H(e)NB200は、構成要素のすべてまたは一部、および他の構成要素を含んでいてもよい。
MPU220は、UMTSセルラーモデムプロセッサ225、周辺装置230、位置決め装置240、非UMTSセルラーまたは非セルラーのモデムプロセッサ245、およびクロックおよびタイム装置250にさらに接続される。MPU220はHPM215にも接続され得る。位置決め装置240は、クロックおよびタイム装置250ならびにUMTSセルラーモデムプロセッサ225にさらに接続される。また、UMTSセルラーモデムプロセッサ225は、PA(電力増幅器)/RF(無線周波数)モジュール260に接続され、これは次いでアンテナユニット270に接続される。HPM215もUMTSセルラーモデムプロセッサ225に接続され得る。また、開示されているように、HPM215は、H(e)NB200に含まれていてもよい。HPM215が含まれるとき、HPM215は、その構内においてH(e)NB200をホストするエンティティであるホスティングパーティのAKA(認証および鍵合意)ベースの認証サービスを提供する。HPM215は、UMTSモバイルネットワークオペレータの代わりに、ホスティングパーティの認証を実行することができる。
TrE210は、H(e)NB200に物理的および論理的にバインドされ、H(e)NB200内の信頼されるエンティティとして動作し、H(e)NB200のアンカーを提供する。安全格納エリア214は、鍵、秘密、および他の機密データおよびプログラムの安全格納エリアを提供する。安全な実行環境212は、UMTSネットワークに対するH(e)NB200のAKAおよび証明書ベースの認証、およびSGWの認証、およびそれを介したUMTSネットワークの認証を実行する環境を提供する。安全な実行環境212は、TrE210が、本明細書に開示されるようないくつかのタスクを実行できるようにする。
例えば、TrE210は、UMTSおよび他のインターフェイスを介したデータおよびトラフィックの暗号化および解読などの他のセキュリティセンシティブな操作、およびMPU220の代わりに、およびMPU220とは無関係に、セキュリティセンシティブなプログラムおよびデータ操作の実行を行う。また、TrE210は、SGWを介してネットワークに、それ自体、またはH(e)NB200の他の任意の構成要素もしくはその操作の妥当性を安全に示すことに関するすべてのタスクを実行することもできる。
また、TrE210は、TrE210がそれ自体、ならびにMPU220のハードウェアおよびソフトウェア(プログラムおよびデータを含む)、含まれている場合はHPM215、セルラーおよび非セルラーのモデム225および245、および他の周辺装置230およびインターフェイスを含めて、H(e)NB200の残りの妥当性(信憑性および/または保全性)をチェックする妥当性検査の操作を実行することもできる。TrE210は、その妥当性チェックを介して無効な構成要素またはサブエンティティを検出すると、安全な順序付きの1組の(それ自体およびH(e)NB200の残りの)ロックダウン操作および/または(ロックダウン前のネットワークへの)報告操作を実行する。
TrE210はさらに、プログラムおよび証明書を含むデータを保護することができ、位置決め装置ならびにクロックおよびタイム装置の妥当性検査を行い、その両方は、ネットワークによってH(e)NB200を許可することができる前、またはH(e)NB200がネットワークへの操作接続を確立する許可が与えられる前に必須である。TrE210は、セキュリティセンシティブな任意の装置管理およびセキュリティセンシティブなデータまたはプログラムのOTA(無線の)タスクを実行することもできる。TrE210は、H(e)NB200および/またはその個々の構成要素/サブエンティティ、またはそれ自体のセキュリティポリシーまたはセキュリティ制御を保護し、監視し、実行することができる。TrE210は、それと、H(e)NB200および/またはネットワークエンティティ、例えばHPM、SGW、AuC(認証センター)もしくはHLR(ホームロケーションレジスタ)などの中の任意の他の構成要素との間の安全なチャネルをセットアップし、維持する(解体も含む)こともできる。TrE210はさらに、内部セキュリティ操作のために、またはSGWとの(装置および/またはホスティングパーティ認証のためのものを含む)バックホール通信を含めて外部通信のために、こうした他の構成要素に渡す必要のある任意のデータを格納し、保護し、抽出し、更新し、(H(e)NB200内の他の構成要素に)安全に提供することができる。
図2から明らかなように、TrE210は、いくつかのH(e)NB200の機能構築ブロックと対話して、認証など、所望の機能を安全に実行する必要がある。必要な接続を確立するために、TrE210は、H(e)NB200内のこうした機能およびリソースへの様々なインターフェイスへのアクセスを有していなければならない。TrE210のこれらのインターフェイスは一般に、TrE210の機能であり、これらは、TrE210の安全な起動プロセスで開始され、したがって、正しく動作すると見なされる。こうした前提に基づいて、H(e)NB200の安全かつ効率的な設計を確立するために、そのセキュリティプロパティに関して、TrE210を分析することができる。
一実施形態において、保護されていないインターフェイス、暗号で保護されたインターフェイス(安全なチャネル)、およびハードウェア保護されたインターフェイスを含む、TrEインターフェイスの3つの広範なセキュリティカテゴリがある。
保護されていないインターフェイスは、TrE210と、改ざんおよび/または盗聴に対してセキュリティ保護されていると見なされないH(e)NB200の一般的なリソースとの間の通信を容易にする。それにも関わらず、保護されていないインターフェイスは、例えばTrE210が関係する鍵素材を所有し、セキュリティ保護されたメモリに後者を格納するとき、TrE210によって暗号で保護されたデータへのアクセスを与えることができることに留意されたい。
暗号で保護されたインターフェイス(安全なチャネル)は、暗号化された通信を提供するセキュリティプロトコルによって保護される。さらに、これらは、TrE210が通信するエンティティの認証および追加の所望の機能、例えばメッセージの認証などを追加で提供する安全なチャネルを確立することができる。
ハードウェア保護されたインターフェイスは、例えばサイドチャネル攻撃に対する対策など、攻撃に対する物理的な保護を提供する。
H(e)NB200の実施形態は、特定のTrEインターフェイス構成の選択について関連する様々な態様を考慮に入れる。保護されていないインターフェイスは、通信側エンティティが伝えられるデータの保護を提供しないときに選択され得る。一例は、通信プロトコルで使用される一時的な秘密(ephemeral secret)とすることができる。暗号で保護されたインターフェイスは、TrE210が通信するリソースが運ばれた情報への平文アクセスを必要とするとき、およびそれがその何らかの保護を提供することができるときに選択され得る。ハードウェア保護されたインターフェイスは、一般にTrE210をハードウェア保護されたリソースに接続して、システム全体の保護レベルを維持する。
図3は、H(e)NB300におけるTrE310のインターフェイス構成の一実施形態を示す。この例において、TrE310は、シン構成をしており、これは、装置認証にAUTH(認証部分)およびRES(結果)モジュール312を使用して、Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement(EAP−AKA) RESおよびAUTHパラメータを計算する機能を含めて、それ自体の中に相対的に限定された機能を有し、H(e)NB300の妥当性検査機能314を使用して妥当性検査を実行することを意味する。次いでTrE310は、H(e)NB300にある他の機能またはリソースとインターフェイスをとる。インターフェイスの中には、ハードウェア保護されているものもあり、暗号で保護されているものもあり、また保護されていないものもある。ハードウェア保護されているインターフェイスまたは暗号で保護されたインターフェイスを介してTrE310とインターフェイスをとるTrE310の外部のこうしたリソースおよび機能は、保護されたリソースおよび機能自体であると想定される。こうしたリソースおよび機能が保護されていない場合、TrE310が保護されたインターフェイス上でそれらとインターフェイスをとる理由はほとんどない。
TrE310は、例えば安全なメモリ322、暗号機能エンジン324、および必要に応じて(所望の場合は物理的な)乱数生成器326など、TrE310によってのみアクセス可能な特別なハードウェア保護されたリソース320をベースにする。これらの特別なハードウェア保護されたリソースは、TrE310のRoT(Root of Trust)と呼ぶことができる。これらのリソースに、ハードウェア保護されたインターフェイス328を介してアクセスして、TrE310自体の信用性を確立し、特にTrE310およびH(e)NB300の安全な起動プロセスを可能にする必要がある。H(e)NB300の他の機能構築ブロックは、様々なセキュリティプロパティを有することができ、安全なチャネル330を介してアクセスすることができる。例えば、乱数生成器モジュール332、乱数パラメータ制御334、WTRU認証リソース336、H(e)NB認証340、IPスタック342、およびホストプラットフォームモジュール350は、暗号で保護されたインターフェイスまたは安全なチャネル330を介してアクセスされる。例えば時間ソース362および位置決定364などの機密情報360は、暗号で保護されたインターフェイスまたは安全なチャネル330を介してアクセスされる。こうした場合、あるハードウェア保護対策との組み合わせは、オプションである。さらに、保護されていないインターフェイス370は、例えばTrE410のメモリを格納機能380で拡張するために、非機密リソース375および汎用リソースに接続される。本明細書に記載したように、インターフェイスは、セキュリティのニーズが様々である可能性があり、TrEは、各インターフェイスタイプに対応し、それと対話する必要がある。
図4は、TrE410を有するH(e)NB400の別のインターフェイス構成を示す。この実施形態において、TrE410は、例えば暗号化エンジン415、乱数生成器417、および安全なメモリ419などそれ自体の中にハードウェア暗号化リソースを含むより厚い構成をしている。TrE410は、例えばIKEv2(インターネット鍵交換)スタック422、装置認証424、およびH(e)NB妥当性検査モジュール426を使用して、IKEv2を介して装置認証を実行するのに十分な機能をさらに含む。TrE410は、モジュール428によりWTRUのAKA手順のサポートも行う。IKEv2プロトコルは、例示の目的で、説明を通じて使用され、それだけには限定されないが、例えば、TLS(トランスポートレイヤセキュリティ)、ブロードバンドフォーラムTR(技術要件)069、OMA(オープンモバイルアライアンス) DM(装置管理)プロトコル、またはTLSの拡張ための適した何らかのIETF(インターネット技術タスクフォース) RFC(コメント要求)など、他のプロトコルが使用されてもよいことに留意されたい。
この実施形態において、乱数生成器モジュール432、乱数パラメータ制御434、ホストプラットフォームモジュール450、および例えば時間ソース462および位置決定464などの機密情報460も暗号で保護されたインターフェイスまたは安全なチャネル430を介してアクセスされる。さらに、保護されていないインターフェイス470は、例えばTrEの記憶容量480を拡張するために、非機密リソース475および汎用リソースに接続される。
別の実施形態において、1つは保護されており、他方は保護されていない2つの広範なタイプのインターフェイスがある。例えば、それぞれ、図3および図4におけるハードウェア保護されたインターフェイスまたは暗号で保護されたインターフェイスのいずれかとして示されるインターフェイスは、単に保護されたインターフェイスと見なすことができ、保護されていないインターフェイスとして示されるインターフェイスは、単に保護されていないインターフェイスと見なすことができる。
本明細書で示すように、H(e)NBとSGWとの間の認証プロトコルは、H(e)NBの必須の認証、およびホスティングパーティのオプションの認証のために導入されている。次に、本明細書に記載したTrEの機能を使用する認証選択の方法について開示する。
IKEv2(インターネット鍵交換バージョン2)は、H(e)NBとコアネットワークとの間の安全な通信(認証のためのものを含む)の基本的なフレームワークとして使用することができる。IKEv2は、H(e)NBとSGWとの間のSA(セキュリティアソシエーション)をセットアップし、2つのエンティティの間のIPSecトンネルをセットアップするために使用することができるセキュリティ鍵を利用する。また、H(e)NBおよびホスティングパーティの結合された認証にIKEv2を使用することもできる。
IKEv2は、相互認証を実行し、SA(セキュリティアソシエーション)を確立し、維持するために使用されるIPecの構成要素である。H(e)NBの文脈で、「セキュリティゲートウェイトンネルへのエンドポイント」は、容易に適用可能である。したがって、エンドポイントとしてのH(e)NBとSGWとの間で、IKE_SAのセキュリティパラメータの交渉、ならびにランダムノンス(random nonce)およびデルフィヘルマン値の送信を伴う第1の段階(IKE_SA_INIT)、および識別の送信およびAH(認証ヘッダー)および/またはESP(カプセル化されたセキュリティペイロード(Encapsulated Security Payload))のためのSAのセットアップを含む要求/応答ステップを含む第2の段階(IKE_AUTH)から成るIKEv2ステップが結果として起こる。
少なくとも2つの異なる認証アクションが指定され、一方はH(e)NB装置自体の認証(装置認証と呼ばれる)、他方はホスティングパーティの認証(ホスティングパーティ認証と呼ばれる)である。装置認証は必須である。装置認証は、EAP−AKA(拡張認証プロトコル−認証鍵合意)または証明書を使用することによって行うことができる。ホスティングパーティ認証は、HPM(ホスティングパーティモジュール)を使用して行うことができる。ホスティングパーティ認証は、行われるとき、装置認証とは別に行うか、装置認証およびホスティングパーティ認証のステップを使用した複合方法で行うことができる。さらに、H(e)NBのID、およびHPMのIDは、物理的または論理的にバインドすることができ、こうしたバインドのための可能なプロトコルが本明細書に紹介されている。
一般に、まず、H(e)NBが装置認証に加えてホスティングパーティ認証を実行するよう要求されているかどうかを、SGWがH(e)NBに対して示す認証プロトコルシグナリング方式が開示される。また、H(e)NBが証明書ベースの認証またはEAP−AKAベースの認証を実行するよう要求されているかどうかを、SGWがH(e)NBに対して示す。SGWは、IKE_SA_INT応答で、MULTIPLE_AUTH_SUPPORTEDパラメータを使用して認証のタイプを示し、IKE_SA_INT応答で、CERTREQパラメータにより装置認証のタイプを示す。H(e)NBは、IKE_AUTH要求で、MULTIPLE_AUTH_SUPPORTEDパラメータおよびANOTHER_AUTH_FOLLOWSパラメータにより認証のタイプを示す。
本明細書で説明するように、MULTIPLE_AUTH_SUPPORTEDパラメータおよびCERTREQパラメータは、SGWからH(e)NBに様々なIKEv2応答メッセージで送信されるとき、H(e)NBに対する要件または要求として解釈されるはずである。とりわけ、SGWは、実際にどのタイプの認証方法を使用すべきかを「決定」し、次いでそれを要求または要件としてH(e)NBに送信する。これによって、選択手順における要求と応答の対のすべての可能な組み合わせのクリアで明白な結果が得られる。この方法の示された選択は、SGWによってサポートされていない場合、送信されないため、同じパラメータは、暗黙的にSGWの機能のインジケータとしても解釈されることに留意されたい。
本明細書に示されるように、H(e)NBは、必須の装置認証およびオプションのHP(ホスティングパーティ)認証を有する。これら2つの認証は、異なる方法で行うことができ、実際に、配置された製品(H(e)NBおよびSGW)は、必須の認証、またはオプションの認証および必須の認証の両方をサポートすることができる。したがって、(SGWを介して)オペレータネットワークに接続する所与のH(e)NBの認証のタイプを選択するための方法が必要である。SGWは、オペレータポリシーを実施するため、SGWによってH(e)NBに対して行われ、示される選択は信頼できる。
認証選択方法の一実施形態において、方法は、1)証明書またはEAP−AKAによる装置認証、および2)EAP−AKAのホスティングパーティ認証を想定する。提示された方法の実施形態は、IKEv2多重認証(IKEv2 multiple authentications)の使用を想定する。
以下で説明するように、必須の装置認証およびオプションのホスティングパーティ認証は、H(e)NBで行われる。認証は、証明書ベースの解決策またはEAP−AKAによって行うことができる。これによって、2つの認証方法および認証を必要とし得る2つのエンティティに関する以下の組み合わせ、1)証明書による、HP認証無しの装置認証、2)EAP−AKAによる、HP認証無しの装置認証、3)証明書による、および証明書を使用したHP認証による装置認証、4)EAP−AKAによる、および証明書を使用したHP認証による装置認証、5)証明書による、およびEAP−AKAを使用したHP認証による装置認証、および6)EAP−AKAによる、およびEAP−AKAを使用したHP認証による装置認証がもたらされる。この実施形態では、HP認証にEAP−AKAを選択することができると想定される場合、認証の組み合わせ3および4は、却下することができる。
図5を参照すると、装置認証、または装置認証およびHP認証があるかどうかを決定するためのH(e)NB505とSGW510との間の方法500が開示されている。方法500は、一実施形態によるIKEv2ベースの認証手順である。最初に、H(e)NB505は、IKE_SA_INIT要求メッセージをSGW510に送信する(515)。SGW510は、IKE_SA_INIT応答メッセージを送信する(520)。IKE_SA_INIT応答メッセージがMULTIPLE_AUTH_SUPPORTEDを含まない場合、H(e)NB505にとって、多重認証を行うことができないことは明らかである。したがって、証明書またはEAP−AKAベースの認証を使用して、装置認証のみが可能である。
H(e)NB505は、IKE_AUTH要求メッセージを送信する(525)。SGW510は、IKE_AUTH要求メッセージがMULTIPLE_AUTH_SUPPORTEDおよびANOTHER_AUTH_FOLLOWSを含むかどうかを決定する。IKE_AUTH要求メッセージが所与の値を含まない場合、これは、装置認証のみを行うことができることを意味する。所与の値がある場合、装置認証およびHP認証の両方を行うことができる。
再度図5を参照すると、装置認証のタイプが証明書ベースであるかEAP−AKAベースであるかを決定する方法が開示されている。H(e)NB505は、IKE_SA_INIT応答(520)におけるCERTREQの入手可能性を決定する。H(e)NB505に対するIKE_SA_INIT応答においてCERTREQがある場合、これは、SGW510が証明書ベースの装置認証をサポートすること、およびEAP−AKAベースの認証もサポートし得ることを含意する。SGW510からH(e)NB505に対するIKE_SA_INIT応答においてCERTREQがない場合、これは、SGW510がEAP−AKAベースの認証をサポートすることを含意する。
証明書ベースの装置認証は、H(e)NB505からSGW510へのIKE_AUTH要求(525)がAUTHを含むかどうかを決定することによって、SGW510によって実行することもできる。AUTHがある場合、これは、証明書ベースの装置認証が実行されることを意味し、そうでない場合、EAP−AKAベースの認証が実行されることを意味する。本明細書で記載するように、HP(ホスティングパーティ)認証は、EAP−AKAを使用する。
認証選択方法の一実施形態において、認証機構の選択は、本明細書で説明する原理を使用する。H(e)NBは、証明書またはEAP−AKAを使用して装置認証をサポートするものとする。上記の2つの方法(すなわち、証明書ベースの装置認証方法またはEAP−AKAベースの装置認証方法)のどちらに関する決定は、配置固有の決定として実際に選択される。H(e)NBは、装置認証に証明書またはEAP−AKA、およびホスティングパーティ認証にEAP−AKAを使用した結合された認証をサポートすることができる。SGWは、両方の認証機構をサポートする場合でさえ、オペレータポリシーに基づいてそれらのうちの一方の使用を拒否することができる。SGWは、H(e)NBに、装置認証およびホスティングパーティ認証の両方を実行することを要求するか、装置認証のみを実行することを要求するか、ならびにH(e)NBに証明書ベースの装置認証を実行することを要求するか、EAP−AKAベースの装置認証を実行することを要求するかを、H(e)NBに対して明白に示す。
上述した基準に基づいて、認証選択方法を以下の表1〜4に示す。表の内容は、認証方法の選択の最終結果を指す。表1〜4は、一実施形態による認証方法の選択をまとめている。表において、M_A_SはMULTIPLE_AUTH_SUPPORTED、I_S_IはIKE_SA_INIT、A_A_FはANOTHER_AUTH_FOLLOWSである。
表1は、H(e)NBが、4つの異なるSGW IKE_SA_INIT応答に応答して、IKE_AUTH要求メッセージでAUTH、MULTIPLE_AUTH_SUPPORTED、およびANOTHER_AUTH_FOLLOWSを戻すシナリオを表す。ケース1では、SGWは、MULTIPLE_AUTH_SUPPORTEDおよびCERTREQを含むIKE_SA_INIT応答を送信する。H(e)NB要求メッセージは、証明書ベースの装置およびEAP−AKAベースのホスティングパーティ認証を実行することに対応する。ケース2では、SGWは、MULTIPLE_AUTH_SUPPORTEDを含み、CERTREQを含まないIKE_SA_INIT応答を送信する。H(e)NB要求メッセージは、SGWがEAP−AKAベースの装置認証およびEAP−AKAベースのホスティングパーティ認証を要求し、しかしH(e)NBは、証明ベースの装置認証で応答するときのエラー状態に対応する。これが起こった場合、最終結果に関するSGWの決定は、オペレータポリシーに依存するものとする。ケース3では、SGWは、CERTREQのみを含むIKE_SA_INIT応答を送信する。H(e)NB要求メッセージは、SGWは証明ベースの装置認証のみを要求し、しかしH(e)NBは、装置認証およびホスティングパーティ認証の両方の試行で応答するときのエラー状態に対応する。これが起こった場合、結果に関するSGWの最終決定は、オペレータポリシーに依存するものとする。ケース4では、SGWは、MULTIPLE_AUTH_SUPPORTEDまたはCERTREQを含まないIKE_SA_INITを送信する。H(e)NB要求メッセージは、SGWがH(e)NBにEAP−AKAベースの装置認証のみを実行するよう要求し、しかしH(e)NBは、装置認証およびホスティングパーティ認証の両方を実行するよう応答するときのエラー状態に対応する。これが起こった場合、結果に関するSGWの決定は、オペレータポリシーに依存するものとする。
表2は、H(e)NBが、4つの異なるSGW IKE_SA_INIT応答に応答して、IKE_AUTH要求メッセージでMULTIPLE_AUTH_SUPPORTEDおよびANOTHER_AUTH_FOLLOWSを戻すが、AUTHは戻さないシナリオを表す。ケース5では、SGWは、MULTIPLE_AUTH_SUPPORTEDおよびCERTREQを含むIKE_SA_INIT応答を送信する。H(e)NB要求メッセージは、SGWメッセージが証明書ベースの装置認証を要求し、しかしH(e)NBは、AUTHをスキップすることによって、証明書ベースの装置認証をサポートしないことを示すときのエラー状態に対応する。これが起こった場合、結果に関するSGWの決定は、オペレータポリシーに依存するものとする。ケース6では、SGWは、MULTIPLE_AUTH_SUPPORTEDを含み、CERTREQを含まないIKE_SA_INIT応答を送信する。H(e)NB要求メッセージは、EAP−AKAベースの装置およびホスティングパーティ認証を実行することに対応する。ケース7では、SGWは、CERTREQのみを含むIKE_SA_INIT応答を送信する。H(e)NB要求メッセージは、SGWがH(e)NBに証明書による装置認証を要求し、しかしH(e)NBは、装置認証およびホスティングパーティ認証の両方を実行するよう試みるときのエラー状態に対応する。これが起こった場合、結果に関するSGWの最終決定は、オペレータポリシーに依存するものとする。ケース8では、SGWは、MULTIPLE_AUTH_SUPPORTEDまたはCERTREQを含まないIKE_SA_INITを送信する。H(e)NB要求メッセージは、SGWがEAP−AKAに基づく装置認証のみを実行するよう要求し、しかしH(e)NBは、装置認証およびホスティングパーティ認証の両方を実行するよう試みるときのエラー状態に対応する。これが起こった場合、結果に関するSGWの決定は、オペレータポリシーに依存するものとする。
表3は、H(e)NBが、4つの異なるSGW IKE_SA_INIT応答に応答して、IKE_AUTH要求メッセージでAUTHを戻すが、MULTIPLE_AUTH_SUPPORTEDおよびANOTHER_AUTH_FOLLOWSを戻さないシナリオを表す。ケース9では、SGWは、MULTIPLE_AUTH_SUPPORTEDおよびCERTREQを含むIKE_SA_INIT応答を送信する。H(e)NB要求メッセージは、SGWが証明ベースの装置認証およびホスティングパーティ認証を要求し、しかしH(e)NBは、証明書ベースの装置認証のみを実行しようと試みるときのエラー状態に対応する。これが起こった場合、結果に関するSGWの決定は、オペレータポリシーに依存するものとする。ケース10では、SGWは、MULTIPLE_AUTH_SUPPORTEDを含み、CERTREQを含まないIKE_SA_INIT応答を送信する。H(e)NB要求メッセージは、SGWがEAP−AKAベースの装置認証およびEAP−AKAベースのホスティングパーティ認証を要求し、しかしH(e)NBは、証明書ベースの装置認証のみを実行しようと試みるときのエラー状態に対応する。これが起こった場合、結果に関するSGWの決定は、オペレータポリシーに依存するものとする。ケース11では、SGWは、CERTREQのみを含むIKE_SA_INIT応答を送信する。H(e)NBは、証明書ベースの装置認証を実行することによって対応する。ケース12では、SGWは、MULTIPLE_AUTH_SUPPORTEDまたはCERTREQを含まないIKE_SA_INITを送信する。H(e)NB要求メッセージは、SGWがH(e)NBにEAP−AKAに基づく装置認証を実行するよう要求し、しかしH(e)NBは、証明書ベースの装置認証を実行するよう試みるときのエラー状態に対応する。これが起こった場合、結果に関するSGWの決定は、オペレータポリシーに依存するものとする。
表4は、H(e)NBが、4つの異なるSGW IKE_SA_INIT応答に応答して、IKE_AUTH要求メッセージでAUTH、MULTIPLE_AUTH_SUPPORTED、およびANOTHER_AUTH_FOLLOWSを戻さないシナリオを表す。ケース13では、SGWは、MULTIPLE_AUTH_SUPPORTEDおよびCERTREQを含むIKE_SA_INIT応答を送信する。H(e)NB要求メッセージは、SGWが証明書ベースの装置認証およびホスティングパーティ認証を要求し、H(e)NBは、EAP−AKAベースの装置認証を実行しようと試みるときのエラー状態に対応する。これが起こった場合、結果に関するSGWの決定は、オペレータポリシーに依存するものとする。ケース14では、SGWは、MULTIPLE_AUTH_SUPPORTEDを含み、CERTREQを含まないIKE_SA_INIT応答を送信する。H(e)NB要求メッセージは、SGWがEAP−AKAベースの装置認証およびEAP−AKAベースのホスティングパーティ認証を要求し、しかしH(e)NBは、EAP−AKAベースの装置認証のみを実行しようと試みるときのエラー状態に対応する。これが起こった場合、結果に関するSGWの決定は、オペレータポリシーに依存するものとする。ケース15では、SGWは、CERTREQのみを含むIKE_SA_INIT応答を送信する。H(e)NB要求メッセージは、SGWがH(e)NBに証明書ベースの装置認証を実行するよう要求し、しかしH(e)NBは、EAP−AKAベースの装置認証を実行するよう試みるときのエラー状態に対応する。これが起こった場合、結果に関するSGWの決定は、オペレータポリシーに依存するものとする。ケース16では、SGWは、MULTIPLE_AUTH_SUPPORTEDまたはCERTREQを含まないIKE_SA_INITを送信する。H(e)NBは、EAP−AKAベースの装置認証を実行することに対応する。
ケース1、6、11、および16は、結果的に有効な要求/応答の対をもたらす。すべての他のケースは、結果的にエラー状態をもたらし、この場合、結果に関するSGWの決定は、オペレータポリシーに依存するものとする。ポリシーの決定は、さらに、H(e)NBの認証機能をSGWが知っていることに基づき得る。例えば、IKE_SA_INIT要求メッセージにおけるH(e)NBによって提供されるH(e)NB IDに基づいて、SGWは、例えばH(e)NBの認証タイプなど、H(e)NB認証情報プロファイルを格納するH(e)NB認証情報サーバからH(e)NBの認証機能プロファイルを導出することができる。SGWは、認証プロファイルに基づいて、証明書ベースの装置認証を要求すべきか、EAP−AKAベースの認証を要求すべきかを決定することができる。H(e)NB認証情報サーバは、必ずしも物理的サーバとして実装されるのではなく、他の機能と同じ場所に配置されるようにしてもよい。
図6を参照すると、H(e)NB認証情報サーバ605からのプロファイル情報を使用する方法600の一実施形態が示されている。SGW610は、H(e)NB615から受信されたH(e)NB識別(1)に基づいて、H(e)NB認証情報サーバ605からの認証プロファイル(2および3)を取り出すものとする。次いでSGW610は、H(e)NB615認証プロファイルに従って要求すべき装置認証のタイプを決定する(4)。SGW610は、IKE_SA_INIT応答を送信する(5)。
認証タイプが「装置認証のみ」を実行すべき旨を含意する場合、SGW610は、H(e)NB615からIKE_AUTH要求を受け付ける(6)。SGW610は、AUTH応答メッセージをH(e)NB615に送信し、認証手順を続行する(7a)。
認証タイプが「装置認証およびHP認証の両方」を実行すべき旨を含意する場合、SGW610は、前のIKE_AUTH要求メッセージ(6)およびホスティングパーティ認証についての別のIKE_AUTH要求メッセージ(7b)に従うようにH(e)NB615に対して示すために、「認証拒否」メッセージでIKE_AUTH応答を送信する。認証拒否メッセージは、単に引き続いてホスティングパーティ認証を行うことをH(e)NB615に対して示すためのものであり、SGW610が前のIKE_AUTH要求メッセージ(6)で取得された装置認証に関する情報を破棄することを含意するものではない。代わりに、SGW610は、前のIKE_AUTH要求メッセージ(6)からの情報を保持し、それを使用して、H(e)NB615が装置認証IKE_AUTH要求、およびホスティングパーティ認証のための認証情報を含む別のIKE_AUTH要求に従った後、最終的な認証成功(または拒否)メッセージをH(e)NB615に送信する。SGW610は、SGW610が取り出したH(e)NB615の認証プロファイルに応じて7aおよび7bを実行する。
以下の認証は、H(e)NB認証に必要である。まず、H(e)NB装置およびオペレータのネットワークの相互認証を行う必要がある。TrEに格納されている信用証明書を使用した認証方法は、TrEの中で実行されるものとする。この相互認証は、プラットフォーム保全性(すなわちTrEプロパティ)の妥当性検査を含む(またはそれに密にバインドされる)ものとする。相互認証の2つの部分は、以下のプロパティを有する。1)H(e)NBの識別は、ネットワークによって認証され、この認証の信用証明書は、H(e)NBにおいてTrEに格納されるものとする。2)オペレータのネットワークの識別(例えば、SGWによって表される)は、H(e)NBのTrEによって認証され、この認証は、一般にオペレータのネットワークを認証するか、H(e)NBによって連絡された特定のSGWを認証することができる。SGWの識別は、SGWから送信されたメッセージにおけるSGWに属する秘密暗号鍵の使用を識別するTrEによって認証することができ、この場合、こうした秘密鍵は、TrEには知られている。というのは、秘密鍵は、TrEが参照することができるSGW証明書に保持されるからである。TrEは、このSGW証明書を安全に格納し、処理することができる。SGW証明書は、SGWから適したIKEv2メッセージ内でTrEに送信することができる。TrEは、ルート証明書が事前に構成され、その後ルート証明書を安全に格納し、処理し、それを使用してSGW証明書を検証することができる。あるいは、TrEは、OCSP(オンライン証明書状態プロトコル)サーバなどの外部認証局と連絡をとってSGW証明書を検証することができる。
該当する場合、オペレータのネットワークによるホスティングパーティの認証も必要である。ホスティングパーティの識別は、オペレータのネットワークによって認証される。この認証は、次の2つの方法で実行することができる。1)ホスティングパーティの認証は、H(e)NBにおける個別のHPM(ホスティングパーティモジュール)に含まれる信用証明書に基づき、相互認証を介した追加のステップとして実行される。または2)ホスティングパーティの認証は、装置認証とバンドルされる。すなわち、相互認証後、追加の認証ステップがない。ホスティングパーティが存在しない(例えば、オペレータ自体がH(e)NBを提供する)場合、この後者の認証は、該当しない場合がある。
現在の基本的なセキュリティプロトコルは、H(e)NBとコアネットワークとの間の装置認証およびホスティングパーティ認証を含めて、安全な通信を提供するが、現在のプロトコルは、H(e)NBまたはその中の(オプションの)HPMについて、「認証」情報以外はほとんど何も提供しないという点で、いくつかの問題を抱えている。H(e)NBは、(例えば人の家など)あまり安全でない物理的な環境において動作するようにされている可能性があるため、知られている秘密を使用した「認証」は、十分ではない可能性があり、セキュリティプロトコルは、SGWにアクセスするための不可欠のステップとして、TrEおよび/またはH(e)NB、またはその構成要素のうちの任意のものの「予想された状態」についての情報を明確に使用することが必要となり得る。このステップは、装置妥当性検査手順と呼ばれる。
具体的には、H(e)NBとSGWとの間の認証およびセキュリティアソシエーションのセットアップにIKEv2を使用するセキュリティプロトコルは、H(e)NB機器ID(H(e)NB_EI)およびホスティングパーティID(H_ID)以外のどんな情報も含まない。これらのIDは、TrEおよびオプションのHPM内にそれぞれ安全に保護されるが、それらの有無(および保全性)が、妥当性検査されるH(e)NBを、コアネットワークとの対話に関して信頼することができるという妥当性検査に関して、十分ではない可能性がある。
したがって、セキュリティプロトコルまたは方法の実施形態が開示される。
一実施形態において、必須の装置(およびオプションのホスティングパーティ)認証の前提条件は、起動時における、および場合によっては(スケジュールされたまたはイベントドリブンの)実行時におけるTrEによる不可欠の起動およびシステム状態の達成である。
別の実施形態において、IKE_INIT段階中またはその後、H(e)NBは、適切なIKEv2ペイロード(例えばCPまたはVペイロード、または通知(N)メッセージ)で、その信用性をプラットフォームとして示す情報を送信する。こうした情報は、証明書、または、TrE、H(e)NB、もしくはHPMを含めて任意の構成要素(の組み合わせ)の予想される状態を記述するステートメント、TrEもしくはH(e)NBの他の構成要素によって実行される局所的な保全性チェックプロセスで不合格になる構成要素のリストを含み得る。この情報は、TrE内で保護される秘密鍵によって署名することができる。
別の実施形態において、CAまたはTTP(例えばTrEまたはH(e)NB製造業者/サプライヤ)で確認することができる証明書を配布することもできる(H(e)NBがSGWを介してそれをHLR/AAAに送信することによって、またはHLR/AAAが帯域外プロセスからそれらを取得すると仮定することによって)。こうした証明書は、TrE内で保持された秘密鍵の公開鍵を証明する。したがって、秘密鍵の使用は、TrE、またはH(e)NBの他の部分が完全な状態であることを示すことになる。IKEv2の交換中、H(e)NBは、コアネットワークに対して、H(e)NBのどの構成要素を、信憑性または保全性について妥当性検査すべきであるかも示し得る。構成要素固有の鍵は、特定の構成要素の妥当性について署名し、保証するために、TrEによって使用され得る。TrE、またはH(e)NBの他の任意の部分の証明書またはステートメントがプロトコル自体で運ばれる場合、CPおよびVなどのIKEv2パラメータは、その情報を運ぶために使用され得る。あるいは、こうした情報は、H(e)NBからSGWに、IKE_AUTH要求メッセージの通知(N)フィールドで運ぶことができる。こうしたフィールドは、TrE、またはH(e)NBの他の部分によって実行される任意の装置妥当性検査および保全性チェックのプロセス、エンティティ、および/または結果についての情報も含み得る。SK{}機構による保護も考慮に入れることができる。
別の実施形態において、証明書を介して(またはプロトコル時に事前に配布されたまたは交換された)、または明確なメッセージング(場合によっては、保全性および機密性のために保護された)を介して、H(e)NBは、SGWに対して、およびSGWを介してコアネットワークに対して、H(e)NBが保証し得る通信、アクセス、およびアプリケーション特権の種類にコアネットワークがアクセスするのに有用なTrE自体についての情報を示す。この場合もまた、こうした情報は、IKEv2に含まれ、適した既存のパラメータで運ぶことができる。
別の実施形態において、IKEv2とは異なる通信プロトコルを、H(e)NBの結合された認証および装置妥当性検査のために使用することができる。こうしたプロトコルの例には、それだけには限定されないが、TLS(トランスポートレイヤセキュリティ)、ブロードバンドフォーラムTR(技術要件)069、OMA(オープンモバイルアライアンス) DM(装置管理)プロトコル、または装置認証および装置妥当性検査のメッセージを結合された方法で示すことができるTLSの拡張のための何らかの適したIETF(インターネット技術タスクフォース) RFC(コメント要求)などがあり得る。
開示された認証プロトコル実施形態によれば、前提条件手順またはその一部として、TrEは、TrEと、MPU、HPM(含まれている場合)、セルラー式モデムプロセッサ、非セルラー式モデムプロセッサ、位置決め装置、および/またはクロック/タイミング装置を含むH(e)NBの他の部分との間の安全なチャネルをセットアップすることができる。こうした安全なチャネルの確立の証拠は、次いで、TrEによって保護された鍵を使用して暗号化された保護の下で、H(e)NBからSGWを介してHLR/AAAに運ばれる。HLR/AAAは、次いでこうした情報を使用して、H(e)NBおよび/またはホスティングパーティ認証の一部として、またはその前提条件として、H(e)NBの信用性にアクセスすることができる。
別の実施形態において、TrEは、H(e)NB、またはアプリケーションまたはサービスサーバへのアプリケーションレイヤ通信アクセスのためのHPM、位置決め装置、もしくはクロック/タイミング装置を含むその構成要素のうちの任意のものの特定のシステム状態を定義し、実施するために使用することができる。したがって、H(e)NBは、安全に起動されたTrEの監視下で、TrEおよびH(e)NBの任意の他の部分の安全な起動の後、「起動」され、IKEv2を使用して、HLR/AAAとの「ネットワークレベルセキュリティアソシエーション」を達成することができる。しかし、その後、TrEは、特定のアプリケーションサーバに対するアプリケーションまたはサービスレベル認証を可能にする前に、オペレータまたはサービスプロバイダのセキュリティポリシー下で、それ自体、および/またはH(e)NBの他の任意の部分の追加の「システム状態」チェックを実行することもできる。こうしたサービスは、OAMサービス、ならびにH(e)NB位置および/または参照タイミングを更新するためのサービスを含み得る。
図7における関連図として示される別の実施形態において、セキュリティプロトコルは、H(e)NB705の信用性が評価され、(ネットワークおよびアプリケーションアクセスの)そのアクセス権が、TCG(Trusted Computing Group) TNC(Trusted Network Connect) PDP(Policy Decision Point)として働くコアネットワークエンティティまたはHLR/AAA710によって決定される手順も含み得る。次いで、アクセス制御ポリシーは、TCG TNC PEP(Policy Enforcement Point)として働くSGW715によって実施される。したがって、H(e)NB705は、TCG TNC AR(Access Requestor)として働く。
別の実施形態において、認証のものなど、セキュリティプロトコルの文脈で、TNC ARとして働くH(e)NBは、それ自体で、またはSGWもしくはHLR/AAAからの要求によって保全性メトリックスを提供する。次いでこうした保全性メトリックスは、SGWを介してHLR/AAAに転送され、この場合、HLR/AAAは、TCG TNC PEPとして働く。H(e)NBから受信される保全性メトリックスが必要な「信頼レベル」を満たすかどうかを評価した後、HLR/AAAは次いで、H(e)NBに与えられるべきネットワークアクセスのレベルを決定する。こうした「レベル」は、サービス範囲、帯域幅、トラフィックタイプおよびボリューム、H(e)NBおよび/またはH(e)NBを介してコアネットワークと通信する任意のWTRUのアプリケーションアクセスなどの粒状の組み合わせを含み得る。次いでポリシー決定は、HLA/AAAからSGWに転送され、これは次いでTCN PEPとして働き、H(e)NBについて与えられたアクセスを管理するHLR/AAAからアクセス制御ポリシーを実施する。また、図7には、このアーキテクチャ例の関連のTNC仕様(例えばIF−M、IF−IMC、IF−IMV、IF−TNCCS、IF−T、およびIF−PEP)が示される。
装置および/またはホスティングパーティ認証プロトコルの一部として、H(e)NBの位置およびH(e)NBの操作の「イベントの説明またはログ」は、SGWを介してH(e)NBからHLR/AAAに運ばれる情報の一部として含まれる、H(e)NB自体のタイミング機能によって提供されるTrEおよび/またはH(e)NBのタイムスタンプ付きバージョンの安全な起動履歴などの局所的なタイムスタンプ付きで開示される。こうした位置情報および/またはタイムスタンプ付きの「イベントの説明またはログ」情報は、TrE内で保護された鍵で暗号化される。HLR/AAAは次いで、H(e)NB_EIまたはHPM_IDだけではなく、H(e)NBの1つまたは複数の位置、および/またはH(e)NBに関するタイムスタンプ付きの「イベントの説明および/またはログ」を含む情報によってもH(e)NBの信用性を評価する。
上記の開示されたセキュリティプロトコルについて、CPまたはVなどの適したIKEv2ペイロード、または通知メッセージ(N)は、H(e)NBとコアネットワーク(およびSGW)との間の追加の情報を運ぶために使用され得る。
次に図8(A)および図8(B)を参照すると、EAP−AKAベースの認証の信号図例が示されている。図8(A)および図8(B)の認証プロトコルは、TrE810の強力なセキュリティプロパティを使用して、H(e)NB805のEAP−AKAベースの装置認証プロトコルの全体的なセキュリティを強化する。アルファベット(例えばA、B、Cなど)で指し示されるステップは、装置認証の目的で、TrE810とH(e)NB805の他の機能との間の対話を伴うことに留意されたい。
装置認証の前提条件として、H(e)NB805は、信頼の置けるプラットフォームとしてSGW820に対してそれ自体を妥当性検査する必要がある(0)。H(e)NB805は、そのTrE810に依存して、H(e)NB805のプラットフォームの妥当性の暗号で保護された証拠を安全に提供し、H(e)NB805は次いでこれをSGW820に転送する。SGW820は、証拠を評価し、H(e)NB805が装置認証を引き続き行うことができるほど十分信用できるかどうかを決定する。
H(e)NB805は、IKE_SA_INIT要求をSGW820に送信する(1)。SGW820は、IKE_SA_INIT応答を送信する(2)。H(e)NB805は、IKE_SKA_INIT応答をTrE810に転送することによって、TrE810にHNB_IDを要求する(A)。TrE819は、IKE_SKA_INIT応答の保全性をチェックし、HNB_IDからIDiを構成する(B)。TrE810は、IDiペイロードおよびステータス(例えば、TrE810によるHNB_IDからのIDiの構成の完了を述べる)をH(e)NB805に送信する(C)。
H(e)NB805は、IDiペイロードをSGW820に送信し、子セキュリティアソシエーションの交渉を開始する(3)。H(e)NB805がEAP認証の実行を望んでいる旨をSGW820に知らせるために、AUTHが省略される。H(e)NB805のリモートIPアドレスを動的に構成する必要がある場合、構成ペイロードは、このメッセージで運ばれる。また、H(e)NB805は、SGW820に証明書を要求する。IDiペイロードで提示されるNAI(ネットワーク識別子)によって選択されたユーザプロファイルが認証の選択(証明書、EAP−AKA、または証明書−EPA−AKA多重認証)を実施することに留意されたい。
SGW820は、IKE_AUTH要求メッセージで受信した識別を含む認証要求メッセージを、空のEAP AVP(属性値の対)と共にAAAサーバ830に送信する(4)。必要な場合、AAAサーバ830は、装置プロファイルおよび認証ベクトルをHSS/HLR840または他の何らかの認証エンティティから取り出す(5)。次いでAAAサーバ830は、認証チャレンジを開始する(6)。
SGW820は、IKE_AUTH応答をH(e)NB805に送信する(7)。IKEv2を介したEAP手順を開始するために、AAAサーバ830から受信したEAPメッセージ(EAP−要求/AKA−チャレンジ)が含まれる。H(e)NBのTrE810がSGW820の証明書に基づいてSGW820を認証する必要がある場合、SGW820の識別、証明書、および(IKE_SA_INIT交換における)前のメッセージを保護するために使用されるAUTHパラメータは、このメッセージでH(e)NB805に送信される。
SGW820認証および認証チャレンジに対する応答の計算に必要な素材がTrE810に転送される(D)。H(e)NB805がSGW820の証明書に基づいてSGW820を認証する必要がある場合、TrE810は、RAND、AUTNからRESを計算し、オプションで認証パラメータをチェックする(E)。TrE810は、SGW820の認証の成功時に、オプションのステータスメッセージと共に、RESをH(e)NB805に配信する(F)。
H(e)NB805は、認証チャレンジに応答する(8)。IKEv2メッセージにおける唯一のペイロード(ヘッダーは別として)は、EAPメッセージである。SGW820は、EAP−応答/AKA−チャレンジメッセージをAAAサーバ830に転送する(9)。すべてのチェックが成功すると、AAAサーバ830は、EAPの成功および鍵素材を含む認証の回答をSGW820に送信する(10)。この鍵素材は、認証プロセス中に生成されたMSK(マスターセッション鍵)から成るものとする。
IKE_SA_INIT段階メッセージを認証するために、SGW820はMSKを使用して、AUTHパラメータを生成するものとする(11)。EAP成功メッセージは、IKEv2を介してH(e)NB805に転送される(12)。EAP成功メッセージは、TrE810に転送される(G)。TrE810は、最初のIKE_SA_INITメッセージを認証するためのAUTHパラメータを生成するための入力としてMSKのそれ自体のコピーを使用する(H)。次いでTrE810は、AUTHをH(e)NB805に転送する(I)。
H(e)NB805は、IKE_AUTH要求を構成し、それをAUTHパラメータによりSGW820に送信する(13)。次いでSGW820は、H(e)NB805から受信したAUTHの正当性をチェックし、第2のIKE_SA_INITメッセージを認証するAUTHパラメータを計算する。SGW820は、H(e)NB805がCFG_REQUESTを介してリモートIPアドレスを要求した場合、構成ペイロード(CFG_REPLY)で割り当てられたリモートIPアドレスを送信するものとする。次いでAUTHパラメータは、構成ペイロード、セキュリティアソシエーション、およびIKEv2パラメータの残りと共にH(e)NB805に送信され、IKEv2交渉が終了する(14)。
SGW820は、そのH(e)NB805の古いIKE SAがすでに存在していることを検出した場合、IKE SAを削除し、H(e)NB805における古いIKE SAを削除するために、H(e)NB805に、DeleteペイロードでINFORMATIONAL交換を送信する(15)。
別の実施形態において、装置認証のプロトコルは、図9を参照して示されるように、証明書に基づいていてもよい。IKEv2証明書ベースの相互認証は、RFC−4306 IKEv2(インターネット鍵交換)プロトコルに従って実行される。証明書の処理およびプロファイルは、所与の仕様に準拠するが、前の証明書の登録および取り消しプロセスの実施の複雑さ、ならびに、例えば満了またはその装置の証明書に関する他の問題のために認証チェックに不合格になる装置を処理するためのブラックリストまたはホワイトリストの使用など、より簡単な代替の有望な可用性のために、証明書の登録および証明書の取り消しは必要ではない場合がある。図9におけるアルファベット(例えばA、B、Cなど)で指し示されるステップは、装置認証の目的で、TrE910とH(e)NB905の他の機能との間の対話を伴うことに留意されたい。
EAP−AKAベースの装置認証の前提条件として、H(e)NB905は、信用できるプラットフォームとしてSGW920に対してそれ自体を妥当性検査する必要がある(0)。H(e)NB905は、そのTrE910に依存して、H(e)NB905のプラットフォームの妥当性の暗号で保護された証拠を安全に提供し、H(e)NB905は次いでこれをSGW920に転送する。SGW920は、証拠を評価し、H(e)NB905が装置認証を引き続き行うことができるほど十分信用できるかどうかを決定する。
H(e)NB905は、IKE_SA_INIT要求をSGW920に送信する(1)。SGW920は、IKE_SA_INIT応答を送信して、H(e)NB905に証明書を要求する(2)。H(e)NB905は、IKE_SKA_INIT応答をTrE910に転送することによって、TrE910にHNB_IDを要求する(A)。TrE910は、IKE_SKA_INIT応答の保全性をチェックし、HNB_IDからIDiを構成し、装置CERTを取り出し、装置CERTを使用してAUTHを計算する(B)。TrE910は、IDi、AUTH、CERT、およびステータス(例えば、TrE910によるHNB_IDからのIDiの構成、AUTHの計算、CERTの取り出しの完了などを述べる)をH(e)NB905に送信する(C)。
H(e)NB905は、IDiペイロードを送信し、子セキュリティアソシエーションの交渉を開始する(3)。また、H(e)NB905は、AUTHペイロード、それ自体の証明書、およびSGW920への証明書の要求の送信も行う。H(e)NB905のリモートIPアドレスを動的に構成する必要がある場合、構成ペイロードは、このメッセージで運ばれる。IDiペイロードで提示されるNAI(ネットワークアドレス識別子)によって選択されたユーザプロファイルが認証の選択(証明書、EAP−AKA、または証明書−EPA−AKA多重認証)を実施する。
SGW920は、H(e)NB905から受信したAUTHの正当性をチェックし、第2のIKE_SA_INITメッセージを認証するAUTHパラメータを計算する(4)。SGW920は、H(e)NB905から受信した証明書を確認する。SGW920は、AUTHパラメータおよびその証明書を、構成ペイロード、セキュリティアソシエーション、およびIKEv2パラメータの残りと共にH(e)NB905に送信し、IKEv2交渉が終了する(5)。H(e)NB905がCFG_REQUESTを介してリモートIPアドレスを要求した場合、リモートIPアドレスは、構成ペイロード(CFG_REPLY)で割り当てられる。
H(e)NB905は、SGW920の証明書をTrE(910)に転送する(D)。TrE910は、その安全に格納されたルート証明書によりSGW920の証明書を検証する(E)。H(e)NB905は、SGW920の証明書をさらに妥当性検査することができる。TrE910は、SGW CERT検証のステータスをH(e)NB905に転送する(F)。SGW920は、そのH(e)NB905の古いIKE SAがすでに存在していることを検出した場合、IKE SAを削除し、H(e)NB905における古いIKE SAを削除するために、H(e)NB905に、DeleteペイロードでINFORMATIONAL交換を送信する(6)。
TrEおよびHPM(例えばUICC)がH(e)NBおよびSGWの残りと対話する必要がある場合、ホスティングパーティ認証が後に続く結合された証明書ベースの装置認証を使用することができる。特に、TrEは、ホスティングパーティまたは装置の認証のために、HPMが生成または受信する任意の情報を保護することができる。さらに、認証プロトコル中にHPMが受信または送信する任意の情報を安全なチャネルによって保護することができるように、TrEは、HPMとの安全なチャネルをセットアップすることができる。
図10(A)および図10(B)は、結合されたEAP−AKAおよび証明書ベースの認証の信号図の一実施形態を示す。図10(A)および図10(B)におけるアルファベット(例えばA、B、Cなど)で指し示されるステップは、この結合された認証手順の目的で、HPM1050を含めて、TrE1010とH(e)NB1005の他の機能との間の対話を伴う。
信号フローは、H(e)NB1005とSGW1020との間の証明書ベースの相互認証、次いでH(e)NB1005とAAAサーバ1030との間のEAP−AKA auth交換を示す。最初に、H(e)NB1005は、IKE_SA_INIT要求をSGW1020に送信する(1)。SGW1020は、IKE_SA_INIT応答を送信して、H(e)NB1005に証明書を要求する(2)。SGW1020は、MULTIPLE_AUTH_SUPPORTEDペイロードを含めることによって、それが多重認証をサポートすることを示す。
H(e)NB1005は、子セキュリティアソシエーションの交渉を開始する(3)。まず、H(e)NB1005は、(HeNB_EIから)IDiペイロードを構成し、以下の暗号化されたパッケージを計算し、転送するようTrE1010に要求する。
SK{SA,TSi,TSr,IDi=NAI,IDr,CP(CFG_REQUEST),AUTH,CERTREQ,CERT,N(MULTIPLE_AUTH_SUPPORTED),N(ANOTHER_AUTH_FOLLOWS)}
H(e)NB1005は、HDR(ヘッダー)および暗号化されたペイロードSK{...}から成るIKE_AUTH要求をSGW1020に転送する。暗号化されたペイロードは、AUTHペイロード、H(e)NB1005自体の証明書、およびSGW1020への証明書の要求も含む。H(e)NB1005のリモートIPアドレスを動的に構成する必要がある場合、構成ペイロードは、このメッセージで運ばれる。H(e)NB1005は、MULTIPLE_AUTH_SUPPORTEDおよびANOTHER_AUTH_FOLLOWS属性を含めることによって、それが多重認証をサポートし、第2の認証を行うことを望むことを示す。IDiペイロードで提示されるNAIによって選択されたユーザプロファイルが認証の選択(証明書、EAP−AKA、または証明書−EPA−AKA多重認証)を行う。
SGW1020は、H(e)NB1005から受信したAUTHの正当性をチェックし、第2のIKE_SA_INITメッセージを認証するAUTHパラメータを計算する(4)。SGW1020は、H(e)NB1005から受信した証明書を検証する。SGW1020は、AUTHパラメータおよびその証明書をH(e)NB1005に送信する(5)。
H(e)NB1005は、暗号化されたペイロードSK{IDr,AUTH,SGW Certi}をTrE1010に転送し、これは、ペイロードを解読し、IDr、AUTH、およびSGW Certiを抽出する。次いでTrE1010は、その格納されたルート証明書によりSGW1020の証明書を検証する(6)。H(e)NB1005は、オペレータの制御下にあるとき、SGW1020の証明書をさらに妥当性検査することができる。
H(e)NB1005は、TrE1010に、別のIKE_AUTH要求メッセージの暗号化された部分を形成するよう要求し、この場合、H(e)NB1005がEAP認証を実行することを望んでいる旨をSGW1020に知らせるために、AUTHペイロードが省略される(7)。暗号化された部分は、SK{IDi=NAI,IDr}である。次いでH(e)NB1005は、HDR(ヘッダー)を作成し、HDR、SK{IDi=NAI,IDr}をSGW1020に送信する。
SGW1020は、IKE_AUTH要求メッセージで受信した識別を含む認証要求メッセージを、空のEAP AVPと共にAAAサーバ1030に送信する(8)。AAAサーバ1030は、ユーザプロファイルおよび認証ベクトルをHSS/HLR(ホーム加入者サーバ/ホームロケーションレジスタ)1040から取り出すものとする(9)。AAAサーバ1030は、認証チャレンジを開始する(10)。
SGW1020は、IKE_AUTH応答をH(e)NB1005に送信する(11)。IKEv2を介したEAP手順を開始するために、AAAサーバ1030から受信したEAPメッセージ(EAP−要求/AKA−チャレンジ)が含まれる。H(e)NB1005がSGW1020の証明書に基づいてSGW1020を認証する必要がある場合、SGW1020の識別、SGW証明書、および(IKE_SA_INIT交換において)H(e)NB1005に送信した前のメッセージを保護するために使用されるAUTHパラメータがこのメッセージに含まれる。
TrE1010は、まずSA(セキュリティアソシエーション)を交換することによってHPM1050との安全なチャネルを確立する。こうした安全なチャネルの確立の結果、TrE1010、およびHPM1050は、次いでRANDおよびAUTNを使用して認証セッションにバインドされるようになる。次いでTrE1010は、認証チャレンジをHPM1050に転送する(A)。
HPM1050は、RES(AKA応答)を計算する(B)。HPM1050は、安全なチャネルを介してTrE1010にRES(AKA応答)を送信する(C)。
H(e)NB1005は、認証チャレンジに応答する(12)。IKEv2メッセージにおける唯一のペイロード(ヘッダーは別として)は、EAPメッセージであり、これは、HPM1050によって計算され、次いでTrE1010によってIKEv2を介して暗号化され、次いでH(e)NB1005に転送されるRESを含む。H(e)NB1005がSGW1020の証明書に基づいてSGW1020を認証する必要がある場合、H(e)NB1005は、認証パラメータをチェックする。
SGW1020は、EAP−応答/AKA−チャレンジメッセージをAAAサーバ1030に転送する(13)。すべてのチェックが成功すると、AAAサーバ1040は、EAPの成功および鍵素材を含む認証の回答をSGW1020に送信する(14)。この鍵素材は、認証プロセス中に生成されたMSKから成るものとする。IKE_SA_INIT段階メッセージを認証するために、SGW1020はMSKを使用して、AUTHパラメータを生成するものとする(15)。EAP成功メッセージは、IKEv2を介してH(e)NB1005に転送される(16)。
H(e)NB1005は、暗号化されたEAP成功メッセージ(すなわちSK{EAP成功メッセージ}をTrE1010に転送する(17)。TrE1010は、最初のIKE_SA_INITメッセージを認証するためのAUTHパラメータを生成するための入力としてMSKのそれ自体のコピーを取得するものとする。AUTHパラメータは、TrE1010からH(e)NB1005に送信され、IKEv2を介して暗号化される。H(e)NB1005は、暗号化されたAUTHパラメータをSGW1020に送信する。
SGW1020は、H(e)NB1005から受信したAUTHの正当性を解読し、チェックし、第2のIKE_SA_INITメッセージを認証するAUTHパラメータを計算する(18)。SGW1020は、H(e)NB1005がCFG_REQUESTを介してリモートIPアドレスを要求した場合、構成ペイロード(CFG_REPLY)で割り当てられたリモートIPアドレスを送信するものとする。次いでAUTHパラメータは、構成ペイロード、セキュリティアソシエーション、およびIKEv2パラメータの残りと共にH(e)NB1005に送信され、IKEv2交渉が終了する。
SGW1020は、そのH(e)NB1005の古いIKE SAがすでに存在していることを検出した場合、IKE SAを削除し、H(e)NB1005における古いIKE SAを削除するために、H(e)NB1005に、DeleteペイロードでINFORMATIONAL交換を送信する(19)。
認証手順中のH(e)NB TrE、HPM、およびH(e)NB自体のバインドが使用され得る。いくつかの想定がなされる。ほとんどの機器が一意のIDを有すると仮定する。例えば、H(e)NB_EIは、H(e)NBの製造業者によって割り当てられ、TrE_IDは、TrEの製造業者によって割り当てられ、HPM_IDは、HPMの製造業者によって割り当てられる。また、オペレータのコアネットワークを表すSGWはH(e)NBとの相互認証を実行することも理解されたい。また、HLR/AAAサーバがH(e)NBのHLR(ホームロケーションレジスタ)および認証センターを含むことが知られている。HLRは、H(e)NB_EI、ならびにそれぞれのID、すなわちTrE_ID、H(e)NB_EI、およびHPM_IDの使用による、TrE、H(e)NB、およびHPMのバインドの関係を表すすべてのHPM_IDに対応するTrE_IDのレコードを格納する。AAAサーバは、これらのレコードに基づくバインド認証を行う。
3つのIDをバインドする方法の一実施形態が開示される。H(e)NBは、SGWに、H(e)NB_EI、TrE_ID、およびオプションのHPM_IDを転送する。SGWは、H(e)NBから受信するH(e)NB_EIをHLR/AAAサーバに転送する。HLR/AAAサーバは、そのレコードに有するH(e)NB_EIに対応するTrE_IDおよびHPM_IDを見つける。HLRのレコードに見つけられるTrE_IDおよびHPM_IDがH(e)NBから受信されたSGWのものと同じである場合、それは、H(e)NBがTrEおよびHPMにバインドする正当な機器であることを確認することができる。
以下で記述するプロトコルによって運ばれる認証アサーションの信用性について、すべての機密データは、TrEおよびHPMによって保護されたままであり得る。特に、H(e)NBおよびH(e)NB_EIのバインド認証を表すH(e)NBの認証秘密は、TrEに安全に格納され得る。TrEは、TrE_IDを安全に格納することもできる。さらに、HPM_IDおよび対応する認証秘密は、HPMによってのみ安全に格納され、処理されるようにしてもよい。安全なチャネルは、TrEまたはHPMからSGWにこのデータをトランスポートするために使用することができる。
図11は、3方向バインド認証の一実施形態を示す。最初に、TrE1110は、それが安全に保持するTrE_IDおよびH(e)NB_EIを取り出す(1)。次いでTrE1110は、AKA RANDおよびAUTNを使用して、HPM1120との安全なチャネルをセットアップする(2)。TrE1110は、HPM1120にHPM_IDを要求し、それを受信する(3)。HPM_IDは、安全なチャネルを介して送信され、その下で保護される(4)。次いでTrE1110は、TrE_ID、H(e)NB_EI、およびHPM_IDをSGW1130に転送する(5)。
SGW1130は、TrE_ID、H(e)NB_EI、およびHPM_IDをHLR/AAA1140に転送する(6)。これらのIDを受信した後、HLR/AAA1140のHLP部分は、TrE_IDおよびHPM_IDに対応するH(e)NB_EIを検索する(7)。次いでHLR/AAA1140のAAA部分は、TrE_IDおよびHPM_IDに対応するH(e)NB_EIによりSGW1130から受信したH(e)NB_EIを検証する(8)。HLR/AAA1140のHLR部分は、次いでSGW1130に、TrE1110およびHPM1120のバインド認証を送信する(9)。次にSGW1130は、TrE1110およびHPM1120のバインド認証をTrE1110に転送する(10)。TrE1110は、安全なチャネルを介してHPM1120のバインド認証をHPM1120に転送する(11)。
TrEがH(e)NBに密に統合されるとき(例えば、TrEがH(e)NB上のチップであるなど)、TrEが物理的にH(e)NB_EIにバインドされるため、TrEをH(e)NBに明確にバインドする必要がない場合がある。この場合、H(e)NBとHPMとの間で2方向のバインドを取得することができる。事実上、この場合、H(e)NBの識別は、TrEの識別の認証によって認証することができ、すなわち、H(e)NB_EIは、TrE_IDとまったく同一である。
図12は、2方向バインド認証の一実施形態を示す。最初に、TrE1210は、それが安全に保持するH(e)NB_EIを取り出す(1)。H(e)NB_EIはTrE_IDと同じであることに留意されたい。TrE1210は、AKA RANDおよびAUTNを使用して、HPM1220との安全なチャネルをセットアップする(2)。次にTrE1210は、安全なチャネル下でHPMにHPM_IDを要求し(3)、それを受信する(4)。次いでTrE1210は、H(e)NB_EIおよびHPM_IDをSGW1230に転送する(5)。
SGW1230は、H(e)NB_EIおよびHPM_IDをHLR/AAA1240に転送する(6)。次いでHLR/AAA1240のHLR部分は、HPM_IDに対応するH(e)NB_EIを検索する(7)。次いでHLR/AAA1240のAAA部分は、SGW1230から受信したH(e)NB_EIをHPM_IDに対応するそのレコード内のH(e)NB_EIと比較することによってH(e)NB_EIを検証する(8)。次いでHLR/AAA1240のHLR部分は、TrE1210(この場合、H(e)NBを認証することに等しい)およびHPM1220のバインド認証をSGW1230に送信する(9)。次にSGW1220は、TrE1210(およびすなわちH(e)NBの)およびHPM1220のバインド認証をH(e)NBのTrE1210に転送する(10)。TrE1210は、HPM1220のバインド認証を、安全なチャネル下で保護されるHPM1120に転送する(11)。
図13は、認証および装置の妥当性検査が結合された方法で行われる方法の一実施形態を示す。この実施形態において、装置の妥当性検査および装置認証を結合するために、IKEv2プロトコルが使用される。しかし、装置または機器の認証に使用される他のプロトコルには、それだけには限定されないが、TLS(トランスポートレイヤセキュリティ)、HTTPS(hypertext transfer protocol secure)、OMA DM、TR069などがある。
最初に、H(e)NB1310のTrEは、安全な起動を実行し、H(e)NB1310の保全性をチェックする(1)。次いでH(e)NB1310は、IKEv2セッションを開始し、IKE_SA_INIT要求メッセージをSGW1320に送信し、この場合、メッセージは、HDR、SA(セキュリティアソシエーション)、KE(デルフィヘルマン鍵要素)、およびNi(initiator nonce)を含む(2)。この信号を受信すると、SGW1320は、H(e)NB1310に、HDR、SA、KE、Nr(respondent nonce)、およびCERTREQ(装置証明書の要求)を含むIKE_SA_INIT応答を送信する(3)。両端でKEを使用するとき、次にH(e)NB1310およびSGW1320はそれぞれ、IKEv2セッション中にさらなるメッセージ交換の機密性および保全性保護に使用するための暗号鍵を生成する。
次いでH(e)NB1310は、IKE_AUTH要求メッセージをSGW1320に送信し、この場合、メッセージは、デルフィヘルマンで生成された鍵によって機密性および保全性について保護される(4)。メッセージの内容は、保護されていないHDR(ヘッダー)、およびSA(セキュリティアソシエーション)、TSi(開始側のトラフィックセレクタ)、TSr(応答側のトラフィックセレクタ)、IDi(H(e)NB1310のNAIフォーマットのID)、IDr(SGW1320のID)、およびCP(構成パラメータ)を含む保護されている部分、H(e)NB1310によって実行される装置保全性チェックのプロセスまたは結果を示すデータ(ここではVAL_DATAと呼ばれる)を含む通知メッセージ、H(e)NBが有効な装置証明書を保持することの証拠としてH(e)NB1310のTrEが計算するAUTHパラメータ、CERTREQ(サーバ側認証に使用されるべきサーバ側の証明書の要求)、およびCERT(H(e)NB1310を認証するためにSGW1320が使用する装置証明書)を含む。
このメッセージを受信すると、SGW1320は次いで装置保全性チェックデータ(VAL_DATA)を抽出し、それを妥当性検査エンティティ1330に送信し(5)、これは次いで、転送されたVAL_DATAおよびそれが有し得る他の参照情報を使用して、H(e)NB1310の信用性または保全性を評価し(6)、次いで図の装置保全性ポイントからH(e)NB1310が正しいことを評価した場合、SGW1320に妥当性検査応答信号を返信する(7)。妥当性検査エンティティ1330から正の妥当性検査応答を受信すると、SGW1320は、次いでH(e)NB1310から受信したH(e)NBのCERT(証明書)を検証し、H(e)NB1310を認証することができるかどうかをチェックする(8)ことができる。正である場合、SGW1320は、次いでHDR(保護されていないヘッダー)および(それ自体のサーバ側認証の証拠の)AUTH、CP、SA、TSi、およびTSi)を含む保護されている部分を含むIKE_AUTH応答メッセージを送信することができる(9)。
あるいは、SGW1320と妥当性検査エンティティ1330との間のVAL_DATAをチェックするためのステップは、SGW1320がH(e)NBの証明書を検証し、H(e)NB1310を認証し、IKE_AUTH応答メッセージをH(e)NB1310に送信した後で行うことができる。
H(e)NB1310は、IKE_AUTH応答メッセージを受信すると、サーバCERTを使用して、それがSGW1320から受信したことを検証することができる(10)。
TrEは、H(e)NBの認証の位置情報を使用するためのセキュリティを保証することもできる。まず、H(e)NBのTrEは、認証における取り出し、格納、保護、および使用を含めて、いくつかの機能を実行して、位置情報の処理のセキュリティを保護することができる。より詳細には、本明細書に記載される位置決め方法のうちの任意のものによって証明される任意の位置情報は、信頼される方法で格納され、処理され得る。このことは、こうした情報は、H(e)NB TrEの保護下で格納され、処理され得ることを意味する。より詳細には、H(e)NB TrEは、こうした情報のソースから暗号で保護された位置情報を受信することができる。また、これは、こうした暗号化された位置情報を安全に解読することもできる。さらに、これは、TrEに格納されている間、またはTrE内に安全に保護された鍵を使用して、暗号化による保護により外部で、位置情報を安全に保護することができる。TrEは、TrE内で保持された、または外部メモリから位置情報を抽出することができる。TrEは、それをSGWに転送する前に暗号化によって位置情報を保護することができる。またTrEは、装置認証プロトコルに含めるために、暗号化された位置情報をSGWに転送することができる。
また、位置登録(または証明書)プロセスまたは位置認証プロセス中、H(e)NB TrEは、位置情報のHLRへの送信中に、暗号化手段を使用して、H(e)NBがHLRに送信する位置情報の保全性および/または機密性を保護することができる。また、これは、H(e)NBがHLRから受信する任意の暗号で保護された位置関連の情報の、解読および保全性チェックを含む、安全な暗号化処理を提供することもできる。H(e)NBにおいてこれらの目的で使用される任意の暗号鍵は、H(e)NB TrEによって保護することができる。さらに、H(e)NB TrEは、機密の位置情報を取得し、格納し、処理することに関する、H(e)NB内の機能の信憑性およびオプションで保全性を保証することもできる。
本明細書において、選択された特定の位置情報に基づく位置登録および位置認証の実施形態が開示される。
H(e)NBは、何らかのアクセス装置(例えば、DSLモデム、ケーブルモデム、ホームルータなど)を介してIPネットワークに接続され、広帯域アクセスプロバイダによって割り当てられたIPアドレスを有し得る。広帯域のアクセスネットワークの物理的な部分を地理的な情報とバインドすることによって、オペレータは、H(e)NBを探し出すことができる。
割り当てられたIPアドレス、ユーザ識別、およびIPアドレスに関連する位置情報は、H(e)NBの位置情報の最初の登録後、ネットワークデータベースに格納される。CN(コアネットワーク)は、ネットワークデータベースに対してクエリを行って、IPアドレス、IPアドレスにバインドされたポート番号、および/またはアドレス情報(経度および緯度の値)を取得することができる。位置ロック機構は、1)H(e)NB位置情報の登録、および2)H(e)NBの位置の認証から成る。
位置登録は、H(e)NBが最初にオンになり、IPのバックホールを介してコアネットワークに接続されると行われる。最初に、H(e)NBは、そのIPアドレスをこのメッセージで運ぶ要求メッセージをHLRに送信する。次いでHLRは、受信したIPアドレスを運ぶ位置情報クエリメッセージをネットワークデータベースに送信する。IPアドレスに基づいて、データベースは、テーブルに対してクエリを行って、IPアドレスにバインドされたポート番号、(入手可能な場合)経度および緯度など上記のH(e)NBのアクセス回線位置情報を取得する。次いでHLRは、取得した情報に基づいて、H(e)NBの位置を決定する。次いでHLRは、このH(e)NBの位置を登録する。次いでHLRは、H(e)NBに対して応答メッセージで答える。位置登録後、HLRは、H(e)NBプロファイルの属性として、位置を格納することができ、それを位置判定基準と見なす。
位置認証は、H(e)NBがアクセスネットワークに要求を行うたびに行われる。したがって、登録の必要はない。最初に、H(e)NBは、そのIPアドレスを運ぶアクセス要求メッセージをHLRに送信する。H(e)NBのTrEは、その送信中に、それ自体によって保護された暗号鍵を使用して、こうしたIPアドレス情報の保全性および/または機密性を保護することができる。すべての暗号化処理は、TrE内で行うことができる。
H(e)NBのIPアドレスを受信した後、HLRは、まずIPアドレスの保全性をチェックし、それがチェックした場合、位置情報を取得するために、再度データベースに対してクエリを行う。次いでHLRは、H(e)NBから取得したアクセス回線位置情報が同じH(e)NBのデータベースから取り出した位置情報に対応するかどうかを認証する。それが同じである場合、HLRは、そのデータベースにH(e)NBの既存の位置を保持する。
HLRは、応答メッセージにおける位置認証結果でH(e)NBに応答する。H(e)NBから新しく取得されたアクセス回線位置情報がH(e)NBプロファイルにおけるものに一致していない場合、HLRは、H(e)NBアクセスを拒否するためのH(e)NBアクセス応答メッセージを戻し、原因値として「無効な位置」を示す。アクセス回線位置情報が一致する場合、HLRは、H(e)NBアクセスを許可するためのH(e)NBアクセス応答を戻す。
H(e)NBの位置は、位置認証を使用して認証することができるが、IPアドレススプーフィング攻撃が可能であり得る。例えば、プロキシサーバは、H(e)NBが別のエリアに再配置されると、正当に登録されたH(e)NBと同じIPアドレスを獲得し得る。次いでこうしたプロキシサーバは、位置に関してのみ、それ自体を正当なH(e)NBとして隠すことができる。
H(e)NBがHLRから情報またはメッセージを受信する上記のステップのうちの任意のものにおいて、こうした任意の情報が暗号で保護されている場合、こうした情報またはメッセージの解読および保全性チェックは、H(e)NB TrE内で、H(e)NB TrEによって保護される鍵を使用することによって実行され得る。
次に、隣接するマクロセルに基づいた一実施形態が開示される。マクロセルの情報に基づいて探し出すためには、H(e)NBは、マクロセルのカバレージにインストールされ、3Gまたは2G受信機を有していなければならず、H(e)NBの隣接マクロ3Gまたは2Gセルをスキャンする受信機の作業状態に切り替えることができる。マクロセルに基づく位置ロック機構は、上記のものと似ているが、位置情報は、PLMN(Public Land Mobile Network)ID、LAI(位置エリア情報)、またはCell IDなど、マクロセルについての情報の形で提示される。
最初のステップは、H(e)NB位置情報を登録することである。H(e)NBは、オンになった後、隣接するマクロセルをスキャンする。次いでH(e)NBは、H(e)NB要求メッセージをHLRに送信する。メッセージは、位置エリアなどの情報、および隣接するマクロセルのセルIDを運ぶ。H(e)NBのTrEは、それ自体によって保護された鍵を使用して、こうした位置エリアおよびセルID情報の保全性、および/または機密性を保護することができる。すべての暗号化処理は、TrE内で行うことができる。HLRは、隣接するマクロセルのセルIDをH(e)NBプロファイルの属性として登録し、H(e)NB応答メッセージをH(e)NBに送信する。
次のステップは、H(e)NB位置を認証することである。H(e)NBは、アクセス要求メッセージをHLRに送信する。メッセージは、隣接するマクロセルの位置エリアおよびセルIDなどの情報を運ぶ。H(e)NBのTrEは、それ自体によって保護された鍵を使用して、HLRへの送信中に、こうした位置エリアおよびセルID情報の保全性、および/または機密性を暗号で保護することができる。すべての暗号化処理は、TrE内で行うことができる。HLRは、隣接するマクロセルの情報を保存されたH(e)NBプロファイルと比較して、H(e)NBがバインドされたセルまたは位置エリアを介してネットワークに接続できるかどうかを決定する。隣接するマクロセルの情報がH(e)NBプロファイルに一致していない場合、HLRは、H(e)NBアクセスを拒否するためのH(e)NBアクセス応答メッセージを戻し、原因値として「無効な位置」を示す。隣接するマクロセルの情報がH(e)NBプロファイルに一致する場合、HLRは、H(e)NBアクセスを許可するためのH(e)NBアクセス応答を戻す。
H(e)NBがHLRから情報またはメッセージを受信する上記の手順のうちの任意のものにおいて、こうした任意の情報が暗号で保護されている場合、こうした情報またはメッセージの解読および保全性チェックは、H(e)NB TrE内で、H(e)NB TrEによって保護される鍵を使用することによって実行され得る。
マクロセルは、広いエリアのカバレージを有する。したがって、単にセル情報を使用することは、いくつかの使用ケースの精度要件を満たさない場合がある。IPアドレスとマクロセル情報との組み合わせの使用は、精度を向上させることができる。
IPアドレスと隣接するマクロセルとの組み合わせに基づいた一実施形態が開示される。最初のステップは、H(e)NB位置情報登録である。H(e)NBは、そのIPアドレスおよび隣接セルIDをこのメッセージで運ぶ要求メッセージをHLRに送信する。H(e)NBのTrEは、それ自体によって保護された暗号鍵を使用して、HLRへの送信中に、IPアドレスおよびセルID情報の保全性、および/または機密性を暗号で保護することができる。すべての暗号化処理は、TrE内で行うことができる。
次いでHLRは、受信したIPアドレスを運ぶ位置情報クエリメッセージを固定のネットワークデータベースに送信する。IPアドレスに基づいて、HLRは、H(e)NB IPアドレスにバインドされたアクセス回線位置情報を取得するために、データベースに対してクエリを行う。アクセス回線位置情報および隣接するマクロセルIDによって、HLRは、H(e)NBのホームエリアを決定する。HLRは、このH(e)NBのアクセス回線位置情報を、受信したセルIDと共に、H(e)NBの属性として格納する。
次のステップは、H(e)NB位置を認証することである。HLRは、H(e)NBからアクセス要求メッセージを受信し、これは、そのIPアドレスおよび周囲のマクロセルのセルIDを運ぶ。新しいIPアドレスによって、HLRは、アクセス回線位置情報を得るために、データベースに対して再度クエリを行う。次いでHLRは、新しく取得されたアクセス回線位置情報が格納されたものと同じであるか、およびさらに受信されたセルIDが格納されたものと同じであるかどうかを判定する。それらがいずれも同じである場合、H(e)NB位置は、変更されない。HLRは次に、H(e)NBに対して、アクセス応答メッセージ内の位置認証結果を答える。
H(e)NBがHLRから情報またはメッセージを受信する上記の手順のうちの任意のものにおいて、こうした任意の情報が暗号で保護されている場合、こうした情報またはメッセージの解読および保全性チェックは、H(e)NB TrE内で、H(e)NB TrEによって保護される鍵を使用することによって実行され得る。
H(e)NBは、別の未登録のアドレスに移動した場合でさえ、H(e)NBは、同じマクロセル内に依然として配置され得ることに留意されたい。この配置は、位置認証方式のセキュリティを向上させ得る。
GPS(全地球測位システム)に基づく一実施形態が開示される。H(e)NBがGPS機能を組み込んでいるとき、その位置情報は、H(e)NB内のGPSを介して取得することができ、その後、アクセス要求中にH(e)NBからCNに送信することができる。しかし、いくつかの室内環境では、GPSがあまり上手く働かない場合がある。
H(e)NBのTrEは、それ自体によって保護された鍵を使用して、それがHLRに送信する任意のGPS位置情報の保全性および/または機密性を暗号で保護することができる。H(e)NBのTrEは、TrE内で保護された鍵を使用して、H(e)NBがHLRから受信する任意の暗号で保護された情報またはメッセージのすべての暗号化処理を安全に処理することができる。
GPSベースの位置証明方法のセキュリティも、特にGPS機能が別のチップに分離されている場合、耐改ざん(tamper−resistant)または改ざん明示(tamper−evident)GPS装置を使用することによって保護され得る。例えばセキュリティ堅牢化GPSチップを使用することができる。
別の実施形態において、H(e)NBのTrEは、定期的に、および/またはいくつかの予め定義されたイベントの発現後、「最後の適切な位置」を安全に格納することもできる。こうした「最後の適切な位置」は、ネットワークオペレータの位置サーバによって証明される位置情報である。H(e)NBの新しい起動後、H(e)NBのTrEは、格納された「最後の適切な位置」を調べ、それを、TrEがその位置識別方法から新しく取得した位置と比較することができる。次いでTrEは、こうした比較の結果を使用して、H(e)NBの位置の変化の可能性があるかどうかを自主的に決定することができる。TrEは、ネットワークにおける位置サーバにこうした結果を報告することもできる。
次に、H(e)NB位置ポリシーのオプションおよび構成について説明する。どの手法を使用すべきかは、例えばオペレータが要求するセキュリティレベルおよび精度レベル、H(e)NBの機能、既存のマクロカバレージなど、いくつかの要因によって決まる。ポリシーは、使用すべき方法を決定することを助けるために適用され得る。ポリシーは、H(e)NBにおいて予め構成され、H(e)NBが自動的にそれに適応することが示唆される。位置証明方法の任意のセキュリティポリシーは、H(e)NBのTrEから管理することができる。
IPアドレスのみを使用することは、十分に安全ではない場合がある。GPSは、いくつかの室内環境では上手く働かない場合があり、H(e)NBにコストを追加する可能性もある。実現性および安全要件を考慮して、IPアドレスおよび隣接するマクロセルに基づく位置ロック機構を検討することができる。この方法は、ポリシーリストにおいて第一にランク付けされ得る。マクロセルカバレージがない場合、ポリシーにおける優先順に応じて他の方法を使用することができる。GPSがコストに加算され、すべてのH(e)NBがGPSを搭載しているとは限らないため、GPSベースの位置決め方法は、より低い優先順で配置され得る。表5に示されるように、シナリオおよびポリシーの様々な組み合わせ、および示されていないものも存在し得る。
(実施形態)
1.TrE(信頼された環境)を含むH(e)NB(Home Node B/Home evolved Node B)。
2.H(e)NB機能モジュールを含む実施形態1に記載のH(e)NB。
3.複数のレベルのセキュリティを提供するように構成されたTrEとH(e)NB機能モジュールとの間のインターフェイスを含む前記実施形態のいずれかに記載のH(e)NB。
4.TrEは、H(e)NB機能モジュールと対話して、セキュリティおよび認証を提供するように構成された前記実施形態のいずれかに記載のH(e)NB。
5.セキュリティおよび認証は、TrEまたはH(e)NBの認証および条件付きホスティングパーティ認証のうちの少なくとも1つを含む前記実施形態のいずれかに記載のH(e)NB。
6.TrEは、鍵、秘密、機密データおよびプログラムのうちの少なくとも1つをセキュリティ保護するための格納エリアを含む前記実施形態のいずれかに記載のH(e)NB。
7.TrEは、TrEまたはH(e)NBのうちの少なくとも1つのAKA(認証および鍵合意)および証明書ベースの認証のうちの少なくとも1つを実行するための安全な実行環境を含む前記実施形態のいずれかに記載のH(e)NB。
8.TrEは、安全な実行環境が、少なくともTrEの妥当性をネットワークに対して安全に示すことに関連するセキュリティセンシティブな操作を実行することを含む前記実施形態のいずれかに記載のH(e)NB。
9.安全な実行環境は、H(e)NBの位置を保護し、妥当性検査を行う前記実施形態のいずれかに記載のH(e)NB。
10.ネットワーク許可は、位置が妥当性検査されるという条件で提供される前記実施形態のいずれかに記載のH(e)NB。
11.ホスティングパーティのAKA(認証および鍵合意)ベースの認証を提供するHPM(ホスティングパーティモジュール)を含み、HPMは、TrEに接続される前記実施形態のいずれかに記載のH(e)NB。
12.HPMは、UICC(ユニバーサル集積回路カード)によって組み込まれる前記実施形態のいずれかに記載のH(e)NB。
13.TrEは、H(e)NBの装置保全性の妥当性検査を行い、装置認証指示と結合された保全性指示をSGW(セキュリティゲートウェイ)に送信するように構成された前記実施形態のいずれかに記載のH(e)NB。
14.TrEは、多重認証をサポートするように構成された前記実施形態のいずれかに記載のH(e)NB。
15.TrEは、相互認証をサポートするように構成された前記実施形態のいずれかに記載のH(e)NB。
16.TrEは、H(e)NB、TrE、および条件付きホスト側プラットフォーム(conditional hosting platform)のレコードおよび識別に基づいてバインド認証を実行するように構成された前記実施形態のいずれかに記載のH(e)NB。
17.TrEは、位置ロックを実行するように構成され、位置ロックは、H(e)NB位置情報の登録、および/またはH(e)NBの位置情報の認証を含む前記実施形態のいずれかに記載のH(e)NB。
18.位置情報は、隣接するマクロセルに基づく前記実施形態のいずれかに記載のH(e)NB。
19.位置情報は、IPアドレスに基づく前記実施形態のいずれかに記載のH(e)NB。
20.位置情報は、IPアドレスおよびマクロセルに基づく前記実施形態のいずれかに記載のH(e)NB。
21.位置情報は、全地球測位システムに基づく前記実施形態のいずれかに記載のH(e)NB。
22.認証のタイプは、IKEv2プロトコルのIKE_AUTH要求を使用して示される前記実施形態のいずれかに記載のH(e)NB。
23.IKE_AUTH要求における所定のパラメータは、証明書ベースのH(e)NBもしくはTrE認証またはEAP−AKA(拡張認証プロトコル−認証鍵合意)ベースのH(e)NBもしくはTrE認証のうちの1つを示す前記実施形態のいずれかに記載のH(e)NB。
24.条件付きホスティングパーティ認証は、EAP−AKA(拡張認証プロトコル−認証鍵合意)を使用して実行される前記実施形態のいずれかに記載のH(e)NB。
25.H(e)NB機能モジュール、TrEおよびネットワークの間で対話するプロトコルは、IKEv2(インターネット鍵交換)、TLS(トランスポートレイヤセキュリティ)、広帯域フォーラムTR(技術要件)069、またはOMA(オープンモバイルアライアンス) DM(装置管理)のうちの少なくとも1つを含む前記実施形態のいずれかに記載のH(e)NB。
26.H(e)NB(Home Node B/Home evolved Node B)を認証するための方法であって、ネットワークへの安全なアクセスを開始するステップを含む方法。
27.装置認証、または装置認証およびホスティングパーティ認証のうちの1つを示す第1の要件を受信するステップを含む実施形態26に記載の方法。
28.証明ベースの認証またはEAP−AKA(拡張認証プロトコル−認証および鍵合意)認証のうちの1つを示す第2の要件を受信するステップを含む実施形態26〜27のいずれかに記載の方法。
29.装置認証、または装置認証およびホスティングパーティ認証のうちの1つを支持する第1のパラメータで応答するステップを含む実施形態26〜28のいずれかに記載の方法。
30.証明ベースの認証またはEAP−AKA認証のうちの1つを支持する第2のパラメータで応答するステップを含む実施形態26〜29のいずれかに記載の方法。
31.第1の要件および第2の要件が第1のパラメータおよび第2のパラメータと一致するという条件下で第1の要件および第2の要件を使用して認証を実行するステップを含む実施形態26〜30のいずれかに記載の方法。
32.H(e)NB識別を使用して取り出される認証プロファイルに基づく第1のパラメータ応答の受け取りを受信するステップを含む実施形態26〜31のいずれかに記載の方法。
33.H(e)NB識別を使用して取り出される認証プロファイルに基づく第1のパラメータ応答の拒否を受信するステップを含む実施形態26〜32のいずれかに記載の方法。
34.ホスティングパーティ認証を支持する別の第1のパラメータで応答するステップを含む実施形態26〜33のいずれかに記載の方法。
35.少なくともTrE(信頼された環境)またはH(e)NBのプラットフォームの信用性または予測される状態の少なくとも1つをネットワークに対して示す情報を提供するステップを含む実施形態26〜34のいずれかに記載の方法。
36.情報は、TrE内で保護される秘密鍵によって署名される実施形態26〜35のいずれかに記載の方法。
37.情報は、ネットワークおよびアプリケーションに対するアクセス権を決定するために、ネットワークによって使用される実施形態26〜36のいずれかに記載の方法。
38.プラットフォームの妥当性のTrEによる暗号で保護された証拠をネットワークに提供するステップを含む実施形態26〜37のいずれかに記載の方法。
39.TrEによって、第1および第2の要件の保全性をチェックするステップを含む実施形態26〜38のいずれかに記載の方法。
40.TrEによって、ネットワークに識別情報を転送するステップを含む実施形態26〜39のいずれかに記載の方法。
41.TrEおよびHPM(ホスティングパーティモジュール)を使用することによってホスティングパーティ認証を実行するステップを含み、TrEは、HPM情報を保護し、HPMと安全に通信する実施形態26〜40のいずれかに記載の方法。
42.TrEまたはH(e)NBの少なくとも1つの識別値、およびHPMの1つの識別値を使用してTrE、H(e)NB、およびHPMをバインドするステップを含む実施形態26〜41のいずれかに記載の方法。
43.H(e)NB機能モジュール、TrEおよびネットワークの間で対話するプロトコルは、IKEv2(インターネット鍵交換)、TLS(トランスポートレイヤセキュリティ)、広帯域フォーラムTR(技術要件)069、またはOMA(オープンモバイルアライアンス) DM(装置管理)のうちの少なくとも1つを含む実施形態26〜42のいずれかに記載の方法。
44.TrE(信頼された環境)にH(e)NB位置情報を安全に格納するステップを含む、H(e)NB(Home Node B/Home evolved Node B)をネットワークに対して認証するための方法。
45.格納されたH(e)NB位置情報をTrEを介してネットワークに安全に送信するステップを含む実施形態44に記載の方法。
46.TrEにおけるH(e)NBの最後の適切な位置を安全に格納するステップを含む実施形態44〜45のいずれかに記載の方法。
47.TrEを使用して格納された「最後の適切な位置」を新しく取得された位置情報と比較するステップを含む実施形態44〜46のいずれかに記載の方法。
48.TrEによる比較の結果を、ネットワーク上の位置サーバに対して示すステップを含む実施形態44〜47のいずれかに記載の方法。
49.H(e)NB、TrE、およびネットワークの間で対話するプロトコルは、IKEv2(インターネット鍵交換)、TLS(トランスポートレイヤセキュリティ)、広帯域フォーラムTR(技術要件)069、またはOMA(オープンモバイルアライアンス) DM(装置管理)のうちの少なくとも1つを含む実施形態44〜48のいずれかに記載の方法。
上記では特徴および要素が特定の組み合わせで記載されているが、各特徴または要素は、他の特徴および要素無しに単独で、または他の特徴および要素の有無にかかわらず様々な組み合わせで使用することができる。本明細書に提供された方法またはフロー図は、汎用コンピュータまたはプロセッサによって実行するために、コンピュータ可読記憶媒体に組み込まれるコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実施することができる。コンピュータ可読記憶媒体の例には、ROM(読み取り専用メモリ)、RAM(ランダムアクセスメモリ)、レジスタ、キャッシュメモリ、半導体メモリ装置、内蔵ハードディスクおよび取外式ディスクなどの磁気媒体、光磁気媒体、ならびにCD−ROMディスクおよびDVD(デジタルビデオディスク)などの光媒体などがある。
適したプロセッサには、一例として、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、DSP(デジタル信号プロセッサ)、複数のマイクロプロセッサ、DSPコアと関連する1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ASIC(特定用途向け集積回路)、FPGA(フィールドプログラマブルゲートアレイ)回路、他の任意のタイプのIC(集積回路)および/または状態機械などがある。
ソフトウェアと関連するプロセッサは、WTRU(無線送受信ユニット)、UE(ユーザ機器)、端末、基地局、RNC(無線ネットワークコントローラ)、または任意のホストコンピュータで使用するための無線周波数送受信機を実施するために使用することができる。WTRUは、カメラ、ビデオカメラモジュール、テレビ電話、スピーカフォン、振動装置、スピーカ、マイクロフォン、テレビ送受信機、ハンズフリーヘッドセット、キーボード、Bluetooth(登録商標)モジュール、FM(周波数変調)無線ユニット、LCD(液晶ディスプレイ)表示装置、OLED(有機発光ダイオード)表示装置、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および/または任意のWLAN(無線ローカルエリアネットワーク)またはUWB(超広帯域)モジュールなど、ハードウェアおよび/またはソフトウェアに実装されるモジュールと共に使用することができる。