(58)【調査した分野】(Int.Cl.,DB名)
  前記シグネチャは、前記ネットワーク機能に対応する公開鍵証明書を使用して作成され、前記公開鍵証明書は、前記サービングネットワークに関連するネットワーク事業者によって供給される前記サービングネットワークの秘密鍵を使用して署名される、請求項1に記載の方法。
  前記証明書オブザーバトリの前記識別子は、インターネットプロトコル(IP)アドレスまたはユニバーサルリソースロケータ(URL)を含む、請求項10に記載の方法。
  前記シグネチャは、UEと前記ネットワーク機能との間で共有される鍵を使用するか、または前記サービングネットワークに関連するネットワーク事業者によって供給されるサービングネットワークの秘密鍵を使用して署名された公開鍵証明書を使用して作成される、請求項14に記載の装置。
  前記シグネチャは、前記UEと前記ネットワーク機能との間で共有されるセッション鍵を使用して作成されるメッセージ認証コード(MAC)を含み、前記第2のメッセージの署名に対称暗号が使用される、請求項18に記載の方法。
  前記シグネチャは、前記ネットワーク機能の秘密鍵を使用して作成されたデジタルシグネチャを含み、前記第2のメッセージの署名に対称暗号が使用され、前記ネットワーク機能の前記秘密鍵は、信頼できる環境内に記憶され、前記シグネチャは、前記信頼できる環境内に作成される、請求項18に記載の方法。
  前記ネットワーク機能はeNodeBを含み、前記第1のメッセージは無線リソース制御メッセージ(RRCメッセージ)を含み、前記第2のメッセージは前記RRCメッセージに対する応答を含む、請求項18に記載の方法。
  ユーザ機器(UE)がホームネットワークとのセキュアな接続を介してサービングネットワークを認証した後に前記UEから第1のメッセージを受信するための手段であって、前記第1のメッセージが、サービングネットワークのネットワーク機能を対象とし、ナンスとシグネチャ要求とを含む手段と、
  前記サービングネットワークにおいて信頼できる環境に維持される事業者署名付き証明書を使用してシグネチャを生成するための手段であって、前記信頼できる環境は攻撃者が鍵を取得することを防止する、手段と、
  前記UEに第2のメッセージを送信するための手段であって、前記シグネチャが前記第2のメッセージに添付される手段とを備え、
  前記第2のメッセージに添付される前記シグネチャは、装置が前記サービングネットワークのメンバーであることを前記UEに対して証明するために生成され、前記事業者署名付き証明書は、前記サービングネットワークの事業者によって署名された公開鍵証明書であり、前記UEが、前記シグネチャを使用して、前記UEに維持される信頼できるネットワークのリストに基づいて前記サービングネットワークを再認証するように構成される、装置。
【発明を実施するための形態】
【0012】
  添付の図面に関して以下に記載する詳細な説明は、様々な構成の説明として意図されており、本明細書において説明する概念が実践される場合がある唯一の構成を表すことは意図されていない。詳細な説明は、様々な概念の完全な理解を提供することを目的として具体的な詳細を含む。しかしながら、これらの概念がこれらの具体的な詳細なしに実践される場合があることは当業者に明らかであろう。場合によっては、そのような概念を曖昧にすることを回避するために、よく知られている構造および構成要素がブロック図の形態で示される。
 
【0013】
  次に、電気通信システムのいくつかの態様を様々な装置および方法を参照しながら提示する。これらの装置および方法について、以下の詳細な説明において説明し、様々なブロック、モジュール、構成要素、回路、ステップ、プロセス、アルゴリズムなど(「要素」と総称される)によって添付の図面に示す。これらの要素は、電子ハードウェア、コンピュータソフトウェア、またはこれらの任意の組合せを使用して実装されてよい。そのような要素がハードウェアとして実装されるかソフトウェアとして実装されるかは、システム全体に課される特定の適用および設計制約に依存する。
 
【0014】
  例として、要素、もしくは要素の任意の部分、または要素の任意の組合せは、1つまたは複数のプロセッサを含むコンピュータまたは「処理システム」を用いて実装されてもよい。プロセッサの例には、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ(DSP)、フィールドプログラマブルゲートアレイ(FPGA)、プログラマブル論理デバイス(PLD)、ステートマシン、ゲート論理、個別ハードウェア回路、および本開示全体にわたって説明される種々の機能を実行するように構成された他の適切なハードウェアが含まれる。処理システムの中の1つまたは複数のプロセッサは、ソフトウェアを実行してもよい。ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、または他の名称で呼ばれるかにかかわらず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、プロシージャ、機能などを意味するように広く解釈されるべきである。
 
【0015】
  したがって、1つまたは複数の例示的な実施形態では、説明される機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実施されてもよい。ソフトウェアにおいて実施される場合、機能は、コンピュータ可読媒体上の1つまたは複数の命令またはコードとして、記憶または符号化されてもよい。コンピュータ可読媒体はコンピュータ記憶媒体を含む。コンピュータ可読媒体は、1つまたは複数のプロセッサによって読み取られならびに/あるいは処理される場合がある一時的記憶媒体および非一時的記憶媒体を含んでもよい。ストレージ媒体は、コンピュータによってアクセスできる任意の利用可能な媒体であってよい。限定ではなく例として、そのようなコンピュータ可読媒体は、ランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、プログラマブルROM(PROM)、消去可能PROM(EPROM)、電気消去可能PROM(EEPROM)、コンパクトディスク読取り専用メモリ(CD-ROM)、もしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、または命令もしくはデータ構造の形態において所望のプログラムコードを搬送もしくは記憶するために使用することができコンピュータによってアクセスすることができる任意の他の媒体を含むことが可能である。ディスク(disk)およびディスク(disc)は、本明細書においては、コンパクトディスク(CD)、レーザーディスク(登録商標)、光学ディスク、デジタル多用途ディスク(DVD)、およびフロッピー(登録商標)ディスクを含み、ディスク(disk)は通常、データを磁気的に再生し、一方、ディスク(disc)は、データをレーザーによって光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲内に同じく含まれるものとする。
 
【0016】
  本明細書において開示するいくつかの態様は、無線リンクセットアップおよび/またはベアラ確立プロセスが確立される場合があるシステムおよび方法に関する。本開示のいくつかの態様は、第5世代(5G)以降のネットワークならびに第4世(4G)代以前のネットワークにおける無線アクセス技術(RAT)を含むより新しい世代の無線アクティブ化技術において生じる場合があるセキュリティ問題に対処する。本明細書では、例として、複数のRATに適用される場合があるいくつかの態様の説明を簡略化することを目的として、4G LTEネットワークアーキテクチャの構成および動作について説明する。
 
【0017】
  図1は、LTEネットワークアーキテクチャ100を示す図である。LTEネットワークアーキテクチャ100は、発展型パケットシステム(EPS)と呼ばれる場合がある。EPSは、1つまたは複数のユーザ機器(UE)102、発展型UMTS地上波無線アクセスネットワーク(E-UTRAN)104、発展型パケットコア(EPC)110、ホーム加入者サーバ(HSS)120、および事業者のインターネットプロトコル(IP)サービス122を含む場合がある。EPSは、他のアクセスネットワークと相互接続することができるが、簡単のために、それらのエンティティ/インターフェースは図示されない。図示のように、EPSはパケット交換サービスを提供するが、当業者は、本開示全体にわたって提示される様々な概念が、回路交換サービスを提供するネットワークに拡張される場合があることを容易に諒解するであろう。
 
【0018】
  E-UTRANは、発展型NodeB(eNodeB)106および他のeNodeB 108を含む。eNodeB 106は、UE 102へのユーザプレーンおよび制御プレーンプロトコル終端を実現する。eNodeB 106は、バックホール(たとえばX2インターフェース)を介して他のeNodeB 108に接続されてよい。eNodeB 106は、基地局、トランシーバ基地局、無線基地局、無線トランシーバ、トランシーバ機能、基本サービスセット(BSS)、拡張サービスセット(ESS)、eNBと呼ばれるか、または他の何らかの適切な用語で呼ばれることもある。eNodeB 106は、EPC 110へのアクセスポイントをUE 102に対して確保する。UE 102の例には、携帯電話、スマートフォン、セッション開始プロトコル(SIP)電話、ラップトップ、携帯情報端末(PDA)、衛星ラジオ、全地球測位システム、マルチメディアデバイス、ビデオデバイス、デジタルオーディオプレーヤ(たとえば、MP3プレーヤ)、カメラ、ゲーム機、仮想現実デバイス、タブレットコンピューティングデバイス、メディアプレーヤ、アプライアンス、ゲーミングデバイス、スマートウォッチまたは光学頭部装着ディスプレイなどのウェアラブルコンピューティングデバイス、あるいは同様の機能を有する他の任意のデバイスがある。UE 102は、当業者によって、移動局、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれることもある。
 
【0019】
  eNodeB 106は、「S1」インターフェースによってEPC 110に接続される。EPC 110は、MME 112と、他のMME 114と、サービングゲートウェイ116と、パケットデータネットワーク(PDN)ゲートウェイ118とを含む。MME 112は、UE 102とEPC 110との間のシグナリングを処理する制御ノードである。一般に、MME 112は、ベアラ管理および接続管理を行う。すべてのユーザIPパケットは、サービングゲートウェイ116を通じて転送され、サービングゲートウェイ116自体は、PDNゲートウェイ118に接続される。PDNゲートウェイ118は、UEのIPアドレス割振り、ならびに他の機能を実現する。PDNゲートウェイ118は、事業者のIPサービス122に接続される。事業者のIPサービス122は、インターネット、イントラネット、IPマルチメディアサブシステム(IMS)、およびPSストリーミングサービス(PSS)を含む場合がある。
 
【0020】
  図2は、LTEネットワークアーキテクチャにおけるアクセスネットワーク200の例を示す図である。この例では、アクセスネットワーク200は、いくつかのセルラー領域(セル)202に分割される。1つまたは複数の低電力クラスeNodeB 208が、セル202のうちの1つまたは複数と重なるセルラー領域210を有する場合がある。低電力クラスeNodeB 208は、フェムトセル(たとえば、ホームeNodeB(HeNB))、ピコセル、マイクロセル、またはリモート無線ヘッド(RRH)であってもよい。マクロeNodeB 204は各々、それぞれのセル202に割り当てられ、セル202中のすべてのUE 206にEPC 110へのアクセスポイントを実現するように構成される。アクセスネットワーク200のこの例では集中型コントローラはないが、代替的な構成では集中型コントローラが使用され得る。eNodeB 204は、無線ベアラ制御、アドミッション制御、モビリティ制御、スケジューリング、セキュリティ、およびサービングゲートウェイ116への接続性を含めた、すべての無線関連機能を担う。
 
【0021】
  アクセスネットワーク200によって採用される変調方式および多元接続方式は、利用されている特定の電気通信規格に応じて異なる場合がある。LTEの適用例では、OFDMがDL上で使用されSC-FDMAがUL上で使用されて、周波数分割複信(FDD)と時分割複信(TDD)の両方をサポートする。当業者が以下の詳細な説明から容易に理解するように、本明細書において提示される種々の概念は、LTEの適用例に適している。しかしながら、これらの概念は、他の変調技法および多元接続技法を用いる他の電気通信規格に容易に拡張される場合がある。例として、これらの概念は、エボリューションデータオプティマイズド(EV-DO)またはウルトラモバイルブロードバンド(UMB)に拡張されてもよい。EV-DOおよびUMBは、CDMA2000規格ファミリーの一部として第3世代パートナーシッププロジェクト2(3GPP2)によって公表されたエアインターフェース規格であり、CDMAを利用して移動局に対してブロードバンドインターネットアクセスを可能にする。これらの概念はまた、Wideband-CDMA(W-CDMA(登録商標))およびTD-SCDMAなどのCDMAの他の変形形態を採用するUniversal Terrestrial Radio Access(UTRA)、TDMAを採用するGlobal System for Mobile Communications(GSM(登録商標))、ならびにOFDMAを採用するEvolved UTRA(E-UTRA)、IEEE 802.11(Wi-Fi)、IEEE 802.16(WiMAX)、IEEE 802.20、およびFlash-OFDMに拡張されてもよい。UTRA、E-UTRA、UMTS、LTE、およびGSM(登録商標)については、3GPP団体による文書に記載されている。CDMA2000およびUMBについては、3GPP2団体による文書に記載されている。採用される実際のワイヤレス通信規格および多元接続技術は、具体的なアプリケーションおよびシステムに課される全体的な設計制約によって決まる。
 
【0022】
  eNodeB 204は、MIMO技術をサポートする複数のアンテナを有してもよい。MIMO技術の使用により、eNodeB 204は、空間領域を利用して、空間多重化、ビームフォーミング、および送信ダイバーシティをサポートすることができる。空間多重化は、同じ周波数で同時に様々なデータストリームを送信するために使用されてもよい。データストリームは、データレートを上げるために単一のUE 206に送信されてよく、または全体的なシステム容量を拡大するために複数のUE 206に送信されてもよい。このことは、各データストリームを空間的にプリコーディングし(すなわち、振幅および位相のスケーリングを適用し)、次いで、空間的にプリコーディングされた各ストリームを複数の送信アンテナを通じてDL上で送信することによって実現される。空間的にプリコーディングされたデータストリームは、異なる空間シグネチャとともにUE 206に到達し、これにより、UE 206の各々は、そのUE 206に向けられた1つまたは複数のデータストリームを復元することが可能になる。UL上では、各UE 206は、空間的にプリコーディングされたデータストリームを伝送し、これにより、eNodeB 204は、空間的にプリコーディングされた各データストリームのソースを特定することが可能になる。
 
【0023】
  空間多重化は一般に、チャネル状態が良好なときに使用される。チャネル状態がそれほど好ましくないとき、送信エネルギーを1つまたは複数の方向に集中させるために、ビームフォーミングが使用される場合がある。このことは、複数のアンテナを通して送信するためにデータを空間的にプリコーディングすることによって実現されてもよい。セルのエッジにおいて良好なカバレージを達成するために、単一ストリームビームフォーミング送信が、送信ダイバーシティと組み合わせて使用される場合がある。
 
【0024】
  以下の発明を実施するための形態では、アクセスネットワークの様々な態様について、DL上でOFDMをサポートするMIMOシステムを参照しながら説明する。OFDMは、OFDMシンボル内のいくつかのサブキャリアにわたってデータを変調するスペクトル拡散技法である。サブキャリアは、正確な周波数において離間される。離間は、受信機がサブキャリアからのデータを復元することを可能にする「直交性」をもたらす。時間領域では、OFDMシンボル間干渉をなくすために、各OFDMシンボルにガードインターバル(たとえば、サイクリックプレフィックス)が付加される場合がある。ULは、高いピーク対平均電力比(PAPR)を補償するために、DFT拡散OFDM信号の形態でSC-FDMAを使用してもよい。
 
【0025】
  図3は、LTEにおけるユーザプレーン用および制御プレーン用の無線プロトコルアーキテクチャの一例を示す
図300である。UEおよびeNodeBの無線プロトコルアーキテクチャは、レイヤ1、レイヤ2、およびレイヤ3という3つのレイヤによって示される。レイヤ1(L1レイヤ)は最下位レイヤであり、様々な物理レイヤ信号処理機能を実装する。L1レイヤは、本明細書において物理レイヤ306と呼ばれる。レイヤ2(L2レイヤ)308は、物理レイヤ306の上にあり、物理レイヤ306を介したUEとeNodeBとの間のリンクとして働く。
 
【0026】
  ユーザプレーンでは、L2レイヤ308は、メディアアクセス制御サブレイヤ(メディアアクセスサブレイヤ)310、無線リンク制御(RLC)サブレイヤ312、およびパケットデータ収束プロトコル(PDCP)サブレイヤ314を含み、これらは、ネットワーク側でeNodeBにおいて終端する。図示されていないが、UEは、L2レイヤ308の上にいくつかの上位レイヤを有することがあり、それらは、ネットワーク側のPDNゲートウェイ118において終端されるネットワークレイヤ(たとえば、IPレイヤ)、および接続の他端(たとえば、遠端UE、サーバなど)において終端されるアプリケーションレイヤを含む。
 
【0027】
  PDCPサブレイヤ314は、異なる無線ベアラと論理チャネルとの間で多重化を行う。PDCPサブレイヤ314はまた、無線送信オーバーヘッドを低減するための上位レイヤデータパケットのヘッダ圧縮と、データパケットを暗号化することによるセキュリティと、eNodeB間におけるUEに対するハンドオーバサポートとを可能にする。RLCサブレイヤ312は、上位層のデータパケットのセグメント化および再構築、失われたデータパケットの再送信、ならびに、ハイブリッド自動再送要求(HARQ)による順序の狂った受信を補償するためのデータパケットの再順序付けを行う。メディアアクセスサブレイヤ310は、論理チャネルとトランスポートチャネルとの間の多重化を実現する。メディアアクセスサブレイヤ310は、1つのセルの中の様々な無線リソース(たとえば、リソースブロック)をUE間で割り振る役目も果たす。メディアアクセスサブレイヤ310は、HARQ演算も担う。
 
【0028】
  制御プレーンでは、UEおよびeNodeBに関する無線プロトコルアーキテクチャは、物理レイヤ306およびL2レイヤ308についてはほぼ同じだが、例外として、制御プレーンにはヘッダ圧縮機能がない。制御プレーンはまた、レイヤ3(L3レイヤ)の中に無線リソース制御(RRC)サブレイヤ316を含む。RRCサブレイヤ316は、無線リソース(すなわち無線ベアラ)を得る役目を果たすとともに、eNodeBとUEとの間でRRCシグナリングを使用して下位レイヤを構成する役目を果たす。
 
【0029】
  図4は、アクセスネットワークにおいて通信するeNodeB 410とUE 450のブロック図である。DLでは、コアネットワークからの上位レイヤパケットが、コントローラ/プロセッサ475に供給される。コントローラ/プロセッサ475は、L2レイヤの機能を実施する。DLでは、コントローラ/プロセッサ475は、ヘッダ圧縮、暗号化、パケットのセグメント化および並べ替え、論理チャネルとトランスポートチャネルとの間の多重化、ならびに、様々な優先度メトリックに基づくUE 450への無線リソース割振りを行う。コントローラ/プロセッサ475はまた、HARQ動作、紛失したパケットの再送、およびUE 450へのシグナリングを担う。
 
【0030】
  送信(TX)プロセッサ416は、L1レイヤ(すなわち、物理レイヤ)のための種々の信号処理機能を実施する。信号処理機能は、UE 450における前方誤り訂正(FEC)を容易にするためのコーディングおよびインターリービング、ならびに様々な変調方式(たとえば、2位相シフトキーイング(BPSK)、4位相シフトキーイング(QPSK)、M位相シフトキーイング(M-PSK)、多値直交振幅変調(M-QAM))に基づく信号コンスタレーションへのマッピングを含む。次いで、コーディングおよび変調されたシンボルが、並列ストリームに分割される。次いで、各ストリームは、OFDMサブキャリアにマッピングされ、時間領域および/または周波数領域において基準信号(たとえば、パイロット)と多重化され、次いで、逆高速フーリエ変換(IFFT)を使用して合成されて、時間領域のOFDMシンボルストリームを搬送する物理チャネルを生成する。OFDMストリームは、複数の空間ストリームを生成するために空間的にプリコーディングされる。チャネル推定器474からのチャネル推定値が、コーディングおよび変調方式を決定するために、ならびに空間処理のために使用される場合がある。チャネル推定値は、UE 450によって送信された基準信号および/またはチャネル状態フィードバックから導出されてもよい。その後、各空間ストリームは、別のトランスミッタ418TXを介して異なるアンテナ420に与えられる。各トランスミッタ418TXは、送信する場合にそれぞれの空間ストリームによってRFキャリアを変調する。
 
【0031】
  UE 450において、各レシーバ454RXは、そのそれぞれのアンテナ452を介して信号を受信する。各受信機454RXは、RFキャリア上で変調されている情報を復元し、情報を受信(RX)プロセッサ456に供給する。RXプロセッサ456は、L1レイヤの種々の信号処理機能を実施する。RXプロセッサ456は、情報に関する空間処理を実行して、UE 450に向けられるあらゆる空間ストリームを再生する。複数の空間ストリームがUE 450に向けられている場合、それらはRXプロセッサ456によって単一のOFDMシンボルストリームに合成されてもよい。次いで、RXプロセッサ456は、高速フーリエ変換(FFT)を使用して、OFDMシンボルストリームを時間領域から周波数領域に変換する。周波数領域信号は、OFDM信号のサブキャリアごとに別個のOFDMシンボルストリームを備える。各サブキャリア上のシンボル、および基準信号は、eNodeB 410によって伝送された最も可能性の高い信号コンスタレーションポイントを決定することによって、復元および復調される。これらの軟判定は、チャネル推定器458によって計算されたチャネル推定値に基づいてもよい。次いで、軟判定は復号されデインタリーブされて、物理チャネル上でeNodeB 410によって最初に送信されたデータおよび制御信号が回復される。その後、データ信号および制御信号は、コントローラ/プロセッサ459に与えられる。
 
【0032】
  コントローラ/プロセッサ459はL2レイヤを実装する。コントローラ/プロセッサは、プログラムコードおよびデータを記憶するメモリ460に関連付けることができる。メモリ460は、コンピュータ可読媒体と呼ばれることがある。ULでは、コントローラ/プロセッサ459が、コアネットワークからの上位レイヤパケットを復元するために、トランスポートチャネルと論理チャネルとの間の逆多重化、パケット再アセンブリ、暗号化解除、ヘッダ圧縮解除、制御信号処理を行う。次いで、上位レイヤパケットはデータシンク462に供給され、データシンク462はL2レイヤの上のすべてのプロトコルレイヤを表す。様々な制御信号が、L3処理のためにデータシンク462に供給されてもよい。コントローラ/プロセッサ459はまた、HARQ動作をサポートするために、確認応答(ACK)および/または否定応答(NACK)のプロトコルを使用する誤り検出を担う。
 
【0033】
  ULでは、データソース467は、上位レイヤパケットをコントローラ/プロセッサ459に与えるために使用される。データソース467は、L2レイヤの上のすべてのプロトコルレイヤを代表する。eNodeB 410によるDL送信に関して説明された機能と同様に、コントローラ/プロセッサ459は、ヘッダ圧縮、暗号化、パケットのセグメント化および並べ替え、ならびに、eNodeB 410による無線リソース割振りに基づく論理チャネルとトランスポートチャネルとの間の多重化を行うことによって、ユーザプレーンおよび制御プレーンのL2レイヤを実装する。コントローラ/プロセッサ459はまた、HARQ動作、紛失パケットの再送信、およびeNodeB 410へのシグナリングも担う。
 
【0034】
  eNodeB 410によって送信された基準信号またはフィードバックからチャネル推定器458によって導出されたチャネル推定値が、適切な符号化変調方式を選択し空間処理を容易にするためにTXプロセッサ468によって使用されてもよい。TXプロセッサ468によって生成された空間ストリームは、別のトランスミッタ454TXを介して異なるアンテナ452に与えられる。各トランスミッタ454TXは、送信する場合にそれぞれの空間ストリームによってRFキャリアを変調する。
 
【0035】
  UL伝送は、eNodeB 410において、UE 450におけるレシーバ機能に関して説明した方法と同様の方法で処理される。各レシーバ418RXは、それのそれぞれのアンテナ420を通じて信号を受信する。各レシーバ418RXは、RFキャリア上に変調されている情報を復元し、その情報をRXプロセッサ470に供給する。RXプロセッサ470は、L1レイヤを実装してもよい。
 
【0036】
  コントローラ/プロセッサ475はL2レイヤを実装する。コントローラ/プロセッサ475は、プログラムコードおよびデータを記憶するメモリ476に関連付けることができる。メモリ476は、コンピュータ可読媒体と呼ばれることがある。ULでは、コントローラ/プロセッサ475が、UE 450からの上位レイヤパケットを復元するために、トランスポートチャネルと論理チャネルとの間の逆多重化、パケット再アセンブリ、暗号化解除、ヘッダ圧縮解除、制御信号処理を行う。コントローラ/プロセッサ475からの上位レイヤパケットは、コアネットワークに与えられる場合がある。また、コントローラ/プロセッサ475は、HARQ動作をサポートするために、ACKおよび/またはNACKプロトコルを使用する誤り検出も担う。
 
【0037】
LTEネットワークにおけるベアラセットアップ
  LTEネットワークにおける無線リンクセットアップでは、ネットワークへのアクセスを可能にするアクセスノードと通信デバイスとの間に1つまたは複数の無線ベアラが確立される場合がある。無線リンクセットアップは一般に、セキュリティアクティブ化交換を含む。その場合、論理ベアラである場合もあるいは論理チャネルである場合もあるセッションベラが、無線リンクを介して確立されてもよく、セッションベアラを介して1つまたは複数のサービスおよび/または通信が確立されてもよい。セッションベアラ、サービス、および/または通信は、1つまたは複数のセキュリティ鍵によってセキュアにされてもよい。
 
【0038】
  セッションベアラセットアップの一部として、認証要求および/または1つまたは複数の鍵交換が行われてもよい。LTE互換プロトコルに従って動作するネットワークでは、1つまたは複数のネットワークエンティティによって実現されるアルゴリズムに基づいて通信デバイスによって鍵が導出されてもよい。
 
【0039】
E-UTRAN鍵階層の例
  
図5は、通常のLTEネットワーク内に実装される場合がある典型的なE-UTRAN鍵階層500を示す図である。通信デバイスでは、ネットワーク側におけるネットワークエンティティ内のユニバーサル加入者識別モジュール(USIM)および認証センター(AuC)がマスター鍵(K)502を使用して暗号鍵(CK)504および完全性鍵(IK)506を生成する。暗号解読鍵(CK)504および完全性鍵(IK)506は次いで、アクセスセキュリティ管理エンティティ鍵(K
ASME)508を生成するためにネットワークエンティティ内の通信デバイスおよびホーム加入者サーバ(HSS)によって使用されてもよい。LTEネットワーク内で動作する通信デバイスのセキュリティアクティブ化は、認証および鍵一致手順(AKA)、非アクセス層(NAS)セキュリティモード構成(NAS SMC)およびアクセス層(AS)セキュリティモード構成(AS SMC)によって遂行されてもよい。AKAは、K
ASME 508を導出するのに使われ、この鍵は次いで、NAS鍵510および512ならびにAS鍵514、516、518、および520の算出のためのベース鍵として使われる。ネットワーク側にある通信デバイスおよびMMEは、次いで、K
ASME 508を使用して、これらのセキュリティ鍵の1つまたは複数を生成してもよい。
 
【0040】
  LTEパケット交換ネットワークは複数の階層プロトコルレイヤとして構造化されてもよく、下位プロトコルレイヤは上位レイヤにサービスを提供し、各レイヤは異なるタスクを受け持つ。たとえば、
図6は、LTEパケット交換ネットワークにおいて動作する通信デバイスに実装される場合があるプロトコルスタック600の例を示す。この例では、LTEプロトコルスタック600は、物理(PHY)レイヤ604と、メディアアクセス制御レイヤ606と、無線リンク制御(RLC)レイヤ608と、パケットデータコンバージェンスプロトコル(PDCP)レイヤ611と、RRCレイヤ612と、NASレイヤ614と、アプリケーション(APP)レイヤ616とを含む。NASレイヤ614の下のレイヤは、しばしばアクセス層(AS)レイヤ602と呼ばれる。
 
【0041】
  RLCレイヤ608は、1つまたは複数のチャネル610を含んでもよい。RRCレイヤ612は、接続状態とアイドル状態とを含む、UEに関する様々な監視モードを実施してもよい。NASレイヤ614は、通信デバイスのモビリティ管理コンテキスト、パケットデータコンテキストおよび/またはそのIPアドレスを維持してもよい。プロトコルスタック600中に(たとえば、図示のレイヤの上、下、および/または中間に)他のレイヤが存在してもよいが、説明のために省略されていることに留意されたい。たとえばRRCレイヤ612および/またはNASレイヤ614において無線/セッションベアラ613が確立されてもよい。したがって、NASレイヤ614は、セキュリティ鍵K
NAS enc 510およびK
NAS-int 512を生成するために通信デバイスおよびMMEによって使用されてもよい。同様に、RRCレイヤ612は、セキュリティ鍵K
UP-enc 516、K
RRC-enc 518、およびK
RRC-int 520を生成するために通信デバイスおよびeNodeBによって使用されてもよい。セキュリティ鍵K
UP-enc 516、K
RRC-enc 518、およびK
RRC-int 520はRRCレイヤ612において生成される場合があるが、これらの鍵は、シグナリングおよび/またはユーザ/データ通信をセキュアにするためにPDCPレイヤ611によって使用されてもよい。たとえば、鍵K
UP-enc 516は、ユーザ/データプレーン(UP)通信をセキュアにするためにPDCPレイヤ611によって使用されてもよく、一方、鍵K
RRC-enc 518およびK
RRC-int 520は、PDCPレイヤ611におけるシグナリング(すなわち、制御)通信をセキュアにするのに使用されてもよい。
 
【0042】
  一例では、これらのセキュリティ鍵(鍵K
NAS-enc 510、K
NAS-int 512、K
UP-enc 516、K
RRC-enc 518、および/またはK
RRC-int 520)を確立する前に、通信デバイスへの/からの通信が、セキュアにされていない共通制御チャネル(CCCH)を介して送信されてもよい(非保護または非暗号化)。これらのセキュリティ鍵が確立された後に、これらの同じユーザデータおよび/または制御/シグナリング通信が専用制御チャネル(DCCH)を介して送信されてもよい。
 
【0043】
  LTE対応ネットワークにおける接続セットアップ/セッションベアラセットアップ手順の間、以前のセットアップセッションによって既存のネイティブNASセキュリティコンテキストがすでに存在する場合、AKAおよびNAS SMC手順は省略されてもよい。既存のNASコンテキストがサービス要求、接続要求、およびTAU要求の時点で再使用されてもよい。TAU要求は、UEによって周期的に送信されるか、あるいはUEがUEに関連付けられていないトラッキングエリアに入ったときに送信されてもよい。トラッキングエリア(またはルーティングエリア)は、UEが最初にネットワークを更新しなくても移動することのできるエリアであってもよい。
 
【0044】
  AS(ユーザプレーンおよびRRC)とNASの両方において暗号化アルゴリズムおよび完全性アルゴリズムに使用されるセキュリティ鍵は、一方の入力として供給される個々のアルゴリズム識別情報を使用して導出されてもよい。NASレベル(たとえば、NASレイヤ614)では、この鍵は、アクセスノード(eNodeB)によってNAS SMC手順の間にNASセキュリティモードコマンドにおいて通信デバイスに供給される。ASレベルでは、使用すべきアルゴリズムは、無線リソース制御(RRC)セキュリティモードコマンドによって実施される。鍵生成は、HMAC-SHA-256関数などの鍵導出関数(KDF)によって行われてもよい。NASセキュリティ鍵K
NAS-enc 510および完全性鍵K
NAS-int 512ならびにRRCセキュリティ鍵K
UP-enc 516、K
RRC-enc 518、および完全性鍵K
RRC-int 520を生成する際、鍵導出関数KDFは、セキュリティアクティブ化交換の間にネットワークによって供給される入力アルゴリズム識別情報を含む数種類の入力を得る。たとえば、入力アルゴリズム識別情報は、高度暗号化規格(AES)または「SNOW-3G」のいずれかを識別してもよい。
 
【0045】
  いくつかの実装形態では、すべてのセキュリティ鍵(たとえば、NAS暗号化鍵および完全性鍵ならびにRRC暗号化鍵および完全性鍵)が、ルート/ベース鍵(たとえば、K
ASME)、1つまたは複数の固定入力、および複数の考えられる入力アルゴリズム識別情報のうちの1つを使用する同じ鍵導出関数(KDF)、たとえば、HMAC-SHA-256を使用して生成される(すなわち、セキュリティ鍵=KDF(ルート/ベース鍵、固定入力、アルゴリズム識別情報))ことに留意されたい。
 
【0046】
AKA手順の一例
  
図7は、LTEワイヤレスネットワークにおける認証の一例を示す流れ
図700である。UE 702は、ネットワーク事業者によって実施されるホームネットワーク706からサービスを取得するためにサービングネットワーク704を通してネットワークに接続する場合がある。ベアラセットアップの間、UE 702は、ホームネットワーク706のHSS 712とセキュアな接続を確立してもよい。UE 702は、HSS 712を信頼してもよく、一方、サービングネットワーク704のeNodeB 708は信頼されない場合がある。UE 702は、NAS接続要求720を国際モバイル加入者識別情報(IMSI)などの識別情報とともに送信してもよい。MME 710は、NAS接続要求720を受信し、要求720を認証情報要求メッセージ722においてHSS 712に転送する。認証情報要求メッセージ722は、UE 702のIMSIとサービングネットワーク識別子(SN_id)とを含んでもよい。HSS 712は、認証値(AUTN)と、期待結果値(XRES)と、乱数と、K
ASMEとを含む認証情報応答メッセージ724によって応答してもよい。AUTNは、AuCによって生成され、RANDとともに、HSS 712をUE 702に対して認証する。MME 710とHSS 712との間のメッセージ722、724は、リンク740上で伝達され、認証、許可、およびアカウンティングプロトコル(ダイアメータ)によって保護される。
 
【0047】
  MME 710は、NAS認証要求726をUE 702に送信し、UE 702は、NAS認証応答メッセージ728によって応答する。NAS認証要求726は、AUTNと、RANDと、鍵セット識別子(KSI
ASME)とを含む。MME 710は、非アクセス層(NAS)セキュリティモード設定(NAS SMC)メッセージ730をUE 702に送信してもよい。UE 702は次いで、MME 710に「NASセキュリティモード完了」メッセージ732を送信し、MME 710は、eNodeB 708に「S1AP初期コンテキストセットアップ」メッセージ734をシグナリングする。eNodeB 708は次いで、UE 702にRRC非アクセス層(NAS)セキュリティモード設定(RRC SMC)メッセージ736を送信してもよく、UE 702は、準備ができたときにRRCセキュリティモード完了メッセージ738によって応答する。
 
【0048】
  いくつかのネットワーク実装形態では、サービングネットワーク704は、認証が遂行された後にある期間にわたって信頼される。一例では、サービングネットワーク704は、認証後、HSS 712との別の認証プロセス(AKA)が実行されるまで信頼されてもよい。確立された信頼が存続する持続時間は、ネットワーク事業者によって決定されてもよい。ネットワーク事業者は、信頼期間を数時間、数日、または数週間に設定してもよい。
 
【0049】
進化するネットワーク技術におけるセキュリティ問題の例
  4G、5G、およびその他のネットワーキング技術が開発されたことに起因して、いくつかのネットワーク機能がネットワークエッジに押しやられる場合がある。いくつかの例では、1つまたは複数のネットワーク機能の再配置によって、セルラーコアネットワークに対する信頼が低下するかまたは無効になることがある。
 
【0050】
  一例では、フェムトセルまたはホームeNodeB(HeNB)が、ブロードバンド接続によって局所化されたワイヤレスサービスを実現するように利用される場合がある。フェムトセルは、一般に家庭環境またはスモールビジネス環境において使用されるように設計された小形低電力セルラー基地局として特徴付けられる場合がある。フェムトセルは、一般にワイドエリアネットワークまたは接続を通してネットワーク事業者のネットワークに接続する限られた範囲および/または限られた数の接続されたアクティブなUEを有する任意の小形セルであってもよい。フェムトセルは、WCDMA(登録商標)ネットワーク、GSM(登録商標)ネットワーク、CDMA2000ネットワーク、TD-SCDMAネットワーク、WiMAXネットワーク、およびLTEネットワークを含む1つまたは複数のネットワークにおいて動作可能であってもよい。より新しい技術を利用し、ならびに/あるいはフェムトセルを使用すると、より攻撃を受けやすい保護および/または分離の点で劣る位置においてネットワーク機能が取り扱われる場合がある。これらの理由およびその他の理由で、スモールセルまたはリレーノードによって実現されるセキュリティのレベルは、マクロセルによって実現されるセキュリティに対して著しく低下する場合がある。スモールセルの利用の増大、およびネットワーク内の複数のホップに対するサポートへの中継を予期することができる。
 
【0051】
  別の例では、いくつかのより新しい技術におけるネットワーク機能が共有システムに配置され、ならびに/あるいはクラウド環境に設けられる場合がある。そのようなシステムおよび環境では、ネットワーキング機能およびコンピューティング機能が仮想化される場合があり、しばしば第三者機関プロバイダによって管理される。ネットワーク事業者は、クラウドへのアクセスパスをセキュアにすることができる場合があるが、クラウド内部のセキュリティを保証することはできない。場合によっては、仮想(クラウド)環境の内部セキュリティと仮想化されたシステム性能とのトレードオフが生じる。場合によっては、ネットワーク事業者は、UE同士を接続するのに使用されるネットワーク機器を所有する必要がなく、ならびに/あるいはネットワークにおけるネットワーク機器の様々な構成要素がそれぞれに異なる事業者によって所有されてもよい。事業者間の分離が低下する場合があり、一部のネットワーク事業者が他のネットワーク事業者の証明書により容易にアクセスできるようになる場合がある。たとえば、両方のネットワーク事業者が共通のeNodeBまたはMMEを共有するときに第1のネットワーク事業者の証明書が第2のネットワーク事業者によってより容易に悪用される場合がある。
 
【0052】
  ある種のセキュリティ仮定が無効化されるとネットワークが非セキュアであると示される場合がある。4G AKAでは、たとえば、HSSは信頼されるネットワークエンティティであり、HSSは信頼のルートであってもよい。UEとサービングネットワークとの相互認証は、HSSとサービングネットワークとの間のセキュリティに応じて行われてもよい。HSSは、UEの代わりにサービングネットワークを認証し、UEの認証証明書をセキュアなチャネルを通してサービングネットワークに供給する。
 
【0053】
  図8は、UE 802がホームネットワーク812からサービスを取得するためにサービングネットワーク804に接続するネットワーク環境を示す簡略ブロック
図800である。図示の例では、UE 802は、サービングネットワーク804の一部として動作させられるE-UTRANに設けられたeNodeB 808を通してMME 810とのワイヤレス接続814を確立してもよい。MME 810は、リンク818を通してホームネットワーク812のHSS 806に接続される。
 
【0054】
  サービングネットワークのeNodeB 808および/またはMME 810は、ネットワークハードウェアの共用、ネットワーク機能のネットワークエッジへの再配置、および/またはeNodeB 808および/またはMME 810の公共の場所または場合によってはセキュアでない物理位置への配置に起因して損害を受ける場合がある。
 
【0055】
  図9は、サービングネットワーク804のある種の脆弱性を示す簡略ブロック
図900である。攻撃者902がセッション証明書を取得するためにある種のプロトコル脆弱性および/またはソフトウェア脆弱性を利用する場合がある。攻撃者902は、セッション証明書を使用して(通信リンク904を通して)妥当な事業者のサービングネットワーク804になりすまし、攻撃者902によって損害を与えられた事業者ネットワーク804との接続を確立することを試みるUE 802から情報を取り込むことのできる機能を含んでもよい。
 
【0056】
  一例では、攻撃者902が他の点では正常なセキュリティプロトコルにおける実装上の欠陥を利用するときにハードブリードアタックと特徴付けられる場合がある。攻撃者902は、MME 810に送信される認証ベクトル(AV)908および/またはeNodeB 808によって使用、維持、または生成される暗号化鍵(KeNB)906などの証明書を取得するためにネットワーク機器またはネットワーク機能のコロケーションを利用する場合がある。証明書は、eNodeB 808、MME 810から取得され、ならびに/あるいは共有ネットワーク機器または機能を実現するコロケートされたハードウェアに利用可能な相互接続部814、816の部分から取得されてもよい。
 
【0057】
  セッション証明書は、まれにHSS 806から取り出され、時間、日単位で測定可能である場合がある期間にわたって有効であってもよい。証明書をインターセプトした攻撃者902は、HSS 806との次の認証手順が実行されるまでサービングネットワーク804になりすますことができる。
 
【0058】
  一例では、攻撃者902はAKA手順の後に証明書をインターセプトしてもよい。攻撃者902は、妥当なネットワーク事業者によって実現されるサービングネットワーク804になりすますことができる不正なパブリックランドモバイルネットワーク(PLMN)である場合がある。UE 802に関連するIMSI、鍵906、およびUE 802による接続の確立またはUE 802に代わる接続の確立に関係する認証ベクトル908などの他の証明書を含む情報を取り込むために、eNodeB 808、MME 810、および/または相互接続部814, 816の脆弱性が、攻撃者によって監視される場合がある。場合によっては、攻撃者902におけるMMEが妥当なサービングネットワーク804におけるMME 810になりすまし、インターセプトされたIMSI、認証ベクトル908および鍵906を使用してUE 802との通信リンク904を確立することがある。その場合、攻撃者902のネットワークエンティティが、UE 802に関する情報にアクセスする場合があり、UE 802から発信される通信を監視する場合がある。
 
【0059】
サービングネットワークの強化された認証
  本明細書において開示するいくつかの態様によれば、ネットワークのセキュリティは、ネットワーク接続が確立されている間サービングネットワーク804を認証することによって強化されてもよい。UE 802は、サービングネットワーク804をできるだけ完全にかつ必要に応じて認証するように適合または構成されてもよい。すなわち、UE 802は、サービングネットワークとの接続がアクティブであり、事前の認証に基づいてサービングネットワークを信頼することができるときに不要な認証手順を回避するように構成されてもよい。
 
【0060】
  サービングネットワークを認証し、UE 802に関する認証ベクトルなどのセッション秘密の取得に基づく攻撃を回避するために、UE 802において信頼できるネットワークのリストが維持される場合があり、この場合、リストは、信頼できるネットワークに対応する公開鍵または共有鍵、証明書、および/またはその他の証明情報を識別する。一例では、UE 802には、信頼できるPLMNのリストおよび対応する公開鍵証明書がプロビジョニングされてもよい。eNodeB 808およびMME 810には、そのそれぞれの事業者によって署名された公開鍵証明書がプロビジョニングされてもよく、この場合の事業者は、同じ事業者であってもよく、サービングネットワーク804の事業者を含んでもよい。eNodeB 808およびMME 810を含むネットワーク機能によって使用される公開鍵に対応する秘密鍵は、セキュアなストレージまたはTrEなどのセキュアな実行環境に維持され、攻撃者は一般に、TrEに保持された秘密鍵を取得することはできない。
 
【0061】
  図10、
図11、および
図12は、公開鍵に基づく手法を使用するサービングネットワーク804を認証するためのオンデマンドプロセスの例を示すメッセージ流れ
図1000、1100、1200である。事業者署名付き公開鍵は、サービングネットワーク804を認証するのに使用される。サービングネットワーク804には、ベリサインまたはインターネット番号割当て機関(IANA)などの信頼できる第三者機関(TTP)によって署名された証明書がプロビジョニングされてもよい。場合によっては、サービングネットワーク804は、信頼できる認証局(CA)のリストにおけるUE 802のホームネットワーク812によって与えられる自己署名証明書を用いてもよい。信頼できるCAのリストは、事業者およびその対応する公開鍵を含んでもよい。信頼できるCAおよび公開鍵または証明書のリストは、セキュアなチャネルを通してローミングパートナーに配布されてもよい。
 
【0062】
  MME 810およびeNodeB 808を含むネットワーク機能は、事業者署名付き証明書を使用してサービングネットワーク804のメンバーシップを証明してもよい。ネットワーク機能に関して発行された公開鍵に対応する秘密鍵を有さない攻撃者はそれ自体をUE 802に対して認証することができない。
 
【0063】
  本明細書において開示するいくつかの態様によれば、サービングネットワーク804のオンデマンド認証を有効化するために、UE 802によって開始されるシグナリングおよび/またはメッセージが活用されてもよい。ベースラインオーバーヘッドが回避される場合があり、そのようなシグナリングに対するサービングネットワーク804の「ピギーバッキング」認証によってアイドル状態オーバーヘッドが解消される場合がある。
 
【0064】
  eNodeB 808を認証するためにRRCメッセージが使用されてもよい。そのようなRRCメッセージの例には、RRC接続要求およびRRC接続再確立要求が含まれる。UE 802は、eNodeB 808と交換される接続メッセージに署名することを要求する場合がある。場合によっては、UE 802は、eNodeB 808の公開鍵を要求してもよい。
 
【0065】
  MME 810を認証するためにTAUメッセージまたはサービス要求メッセージが使用されてもよい。一例では、UE 802が、MME 810と交換されるTAUメッセージまたはサービス要求受付メッセージに署名することを要求する場合がある。場合によっては、UE 802は、MME 810の公開鍵を要求してもよい。
 
【0066】
  図10は、eNodeB 808を介したサービングネットワーク804のオンデマンド認証にRRCメッセージ1004を使用する第1の例を示すメッセージ流れ
図1000である。UE 802はAKA手順1002を開始してもよい。AKA手順1002が首尾よく完了すると、UE 802は、RRCメッセージ1004を使用してサービングネットワーク804を認証してもよい。RRC接続要求(または接続確立要求)1010が認証の一部として用いられてもよい。一例では、アイドルモードからの遷移の間にeNodeB 808にRRC接続要求1010が送信されてもよい。UE 802がアイドルモードに入ると、eNodeB 808は、電力節約を目的としてUE 802のセキュリティコンテキストを中断してもよい。いくつかの態様によれば、UE 802は、追加のフィールドを含むRRC接続要求1010を送信してもよい。追加のフィールドには、ナンスとeNodeB 808のシグネチャを求める要求とを含めてもよい。場合によっては、追加のフィールドに、eNodeB 808の公開鍵を求める要求を含めてもよい。ナンスは、以前の通信を応答アタックにおいて再使用できないようにするのに使用される任意の数、乱数、または擬似乱数であってもよい。eNodeB 808は、その秘密鍵を使用して署名されたRRC接続セットアップ応答1012を送信してもよく、eNodeB 808の真正性が検証されたときに、UE 802はRRC接続セットアップ完了1014をシグナリングしてもよい。
 
【0067】
  図11は、eNodeB 808を介したサービングネットワーク804のオンデマンド認証にRRCメッセージ1104を使用する第2の例を示すメッセージ流れ
図1100である。UE 802はAKA手順1102を開始してもよい。AKA手順1102が首尾よく完了すると、UE 802は、RRCメッセージ1104を使用してサービングネットワーク804を認証してもよい。たとえば、接続失敗復元時に、RRC接続再確立要求1110が用いられてもよい。いくつかの態様によれば、UE 802は、追加のフィールドを含むRRC接続再確立要求1110を送信してもよい。追加のフィールドには、ナンスとeNodeB 808のシグネチャを求める要求とを含めてもよい。場合によっては、追加のフィールドに、eNodeB 808の公開鍵を求める要求を含めてもよい。eNodeB 808は、その秘密鍵を使用して署名された接続再確立応答1112を送信してもよく、eNodeB 808の真正性が検証されたときに、UE 802はRRC接続セットアップ完了1114をシグナリングしてもよい。
図11のメッセージ流れ
図1100の例によって示されるプロセスは、失敗復元手順時に証明情報をインターセプトするために切断を生じさせる攻撃を防止する場合がある。
 
【0068】
  UE 802は、送信すべきデータまたは受信すべきデータがあるとき、あるいは別のネットワーク機能へのハンドオーバの前または後に、必要に応じてRRCメッセージを使用してサービングネットワーク804を認証してもよい。RRC接続要求、RRC確立要求、および/またはRRC再確立要求はUE 802によって開始され、そのような要求はeNodeB 808からの応答を要求する。場合によっては、UE 802は、サービングネットワーク804を連続的に認証することが不要であると判定してもよい。たとえば、UE 802がアイドル状態であり、ハンドオーバが示されていないときは、認証を実行する必要はない。シグネチャがオンデマンドで与えられるとき、ベースラインプロトコルに関連するオーバーヘッドを最小限に抑えることができる。eNodeB 808は一般に、要求時にのみネットワーク機能証明書を供給する。
 
【0069】
  図12は、MME 810を介したサービングネットワークのオンデマンド認証にTAUメッセージ1204を使用する第1の例を示すメッセージ流れ
図1200である。UE 802はAKA手順1202を開始してもよい。AKA手順1202が首尾よく完了すると、UE 802は、TAUメッセージを使用してサービングネットワーク804を認証してもよい。TAU要求1210は、たとえば、周期的登録時またはハンドオーバ後に用いられてもよい。いくつかの態様によれば、UE 802は、ナンス、およびMME 810のシグネチャを求める要求を含む場合がある追加のフィールドを有するTAU要求1210を送信してもよい。場合によっては、追加のフィールドに、MME 810の公開鍵を求める要求を含めてもよい。MME 810は、その秘密鍵を使用して署名された応答1212を送信してもよく、MME 810の真正性が検証されたときに、UE 802はRRC接続セットアップ完了1214をシグナリングしてもよい。
 
【0070】
  図13、
図14、および
図15は、攻撃者が、NAS鍵およびAS鍵などのセッション秘密を取得するためにシステム脆弱性またはプロトコル脆弱性を狙い利用する場合がある攻撃を妨害するための共有鍵ベースの手法を使用してサービングネットワーク804を認証するためのオンデマンドプロセスの例を示すメッセージ流れ
図1300、1400、1500である。eNodeB 808およびMME 810などのネットワーク機能には、信頼できる実行環境がプロビジョニングされてもよく、この環境は、ネットワーク機能用の鍵導出鍵を維持するのに使用されてもよい。攻撃者は一般に、信頼できる実行環境に格納された鍵を取得することはできない。一例では、MME 810用の信頼できる実行環境に格納される鍵導出鍵はK
ASME鍵であり、eNodeB 808用の信頼できる実行環境に格納される鍵導出鍵はK
eNB鍵である。鍵導出鍵が暗号化および完全性保護に直接使用されることはなく、これらの鍵は一般に、暗号化および完全性保護に使用することのできる鍵を生成するのに使用される。ネットワーク機能は、そのそれぞれの鍵導出鍵を使用してサービングネットワーク804に対する各機能のメンバーシップを証明してもよい。信頼できる実行環境に格納された鍵導出鍵にアクセスできない攻撃者は、なりすましているメンバーシップをサービングネットワーク804に対して証明することができない。
 
【0071】
  共有鍵を使用してサービングネットワーク804を認証するための特定のオンデマンドプロセスは、UE 802によって開始されるメッセージを利用する場合がある。認証プロセスは、ベースラインプロトコルオーバーヘッドを制限し、場合によってはアイドル状態オーバーヘッドをなくすためにオンデマンドプロセスとして実施されてもよい。
 
【0072】
  eNodeB 808を認証するためにRRCメッセージが使用されてもよい。そのようなRRCメッセージの例には、RRC接続要求およびRRC接続再確立要求が含まれる。UE 802は、eNodeB 808と交換される接続メッセージに署名することを要求する場合がある。場合によっては、eNodeB 808は、RRC接続セットアップメッセージが送信されたときにKeNBを有していない場合がある。したがって、シグネチャまたはメッセージ認証コード(MAC)がセキュリティモード制御手順の後にUE 802に送信される。MACコードは、ハッシュ関数などを使用して生成される情報を含んでもよく、メッセージを認証し、ならびに/あるいはメッセージの完全性を保証してもよい。
 
【0073】
  MME 810を認証するためにTAUメッセージが使用されてもよい。一例では、UE 802が、MME 810と交換されるTAU受付メッセージに署名することを要求する場合がある。
 
【0074】
  図13は、eNodeB 808を介したサービングネットワーク804のオンデマンド認証にRRCメッセージを使用する第3の例を示すメッセージ流れ
図1300である。UE 802はAKA手順1302を開始してもよい。AKA手順1302が首尾よく完了すると、UE 802は、RRCメッセージ1304を使用してサービングネットワーク804を認証してもよい。たとえば、アイドルモードからの遷移時に、RRC接続要求1310が用いられてもよい。いくつかの態様によれば、UE 802は、追加のフィールドを含むRRC接続要求1310を送信してもよい。追加のフィールドには、ナンスおよびシグネチャ要求を含めてもよい。eNodeB 808は、KeNBを使用してその応答1312に署名し、eNodeB 808の真正性が検証されたときに、UE 802は、RRC接続セットアップ完了1314をシグナリングすることによって手順の完了について肯定応答してもよい。
 
【0075】
  図14は、eNodeB 808を介したサービングネットワーク804のオンデマンド認証にRRCメッセージ1404を使用する第4の例を示すメッセージ流れ
図1400である。UE 802は、AKA手順1402を開始してもよく、AKA手順1402が首尾よく完了すると、RRCメッセージ1404を使用してサービングネットワーク804を認証してもよい。たとえば、接続失敗復元時に、RRC接続再確立要求1410が用いられてもよい。いくつかの態様によれば、UE 802は、追加のフィールドを含むRRC接続再確立要求1410を送信してもよい。追加のフィールドには、ナンスおよびシグネチャ要求を含めてもよい。eNodeB 808は、KeNBを使用して署名された応答1412を送信してもよく、eNodeB 808の真正性が検証されたときに、UE 802はRRC接続セットアップ完了1414をシグナリングしてもよい。
 
【0076】
  UE 802は、必要に応じて、送信すべきデータまたは受信すべきデータがあるとき、あるいは別のネットワーク機能へのハンドオーバの前または後に、RRCメッセージを使用してサービングネットワーク804を認証してもよい。RRC接続再確立要求、RRC確立要求、および/またはRRC再確立要求はUE 802によって開始され、そのような要求はeNodeB 808からの応答を要求する。場合によっては、UE 802は、サービングネットワーク804を連続的に認証することが不要であると判定してもよい。たとえば、UE 802がアイドル状態であり、ハンドオーバが示されていないときは、認証を実行する必要はない。シグネチャがオンデマンドで与えられるとき、ベースラインプロトコルに関連するオーバーヘッドを最小限に抑えることができる。eNodeB 808は一般に、要求時にのみネットワーク機能証明書を供給する。
 
【0077】
  図15は、MME 810を介したサービングネットワークのオンデマンド認証にTAUメッセージ1504を使用する第2の例を示すメッセージ流れ
図1500である。UE 802はAKA手順1502を開始してもよい。AKA手順1502が首尾よく完了すると、UE 802は、TAUメッセージ1504を使用してサービングネットワーク804を認証してもよい。TAU要求1510は、たとえば、周期的登録時またはハンドオーバ後に用いられてもよい。いくつかの態様によれば、UE 802は、ナンスおよびシグネチャ要求を含む場合がある追加のフィールドを有するTAU要求1510を送信してもよい。MME 810は、K
ASME鍵を使用して署名された応答1512を送信してもよく、MME 810の真正性が検証されたときに、UE 802はRRC接続セットアップ完了1514をシグナリングしてもよい。
 
【0078】
物理的にアクセス可能なネットワーク機能に関係するセキュリティ問題
  
図16は、攻撃者1602がサービングネットワーク804の特定のネットワーク機能(たとえば、eNodeB 808および/またはMME 810)を実現するネットワーク機器に物理的にアクセスするときに生じる場合があるサービングネットワーク804の特定の脆弱性を示す簡略ブロック
図1600である。この攻撃形態では、攻撃者1602は、永久鍵1606、1608ならびにセッション証明情報を含む永久証明情報にアクセスする場合がある。たとえば、攻撃者1602は、ネットワーク機器の秘密鍵などの永久鍵1606および/または1608ならびに/あるいはeNodeB 808またはMME 810などのネットワーク機能にアクセスする場合がある。秘密鍵は、メッセージに署名するのに使用されてもよい。この攻撃形態では、攻撃者1602は、UE 802との通信1604に対して持続的にサービングネットワーク804になりすますとともに、HSS 806との通信1610に対して持続的にサービングネットワーク804になりすますことができる。
 
【0079】
  ネットワーク機器に物理的にアクセスする攻撃者1602は、ネットワーク機能に関連するネットワーク機器に損害を与えることによってネットワーク機能に関して発行されたすべての証明情報を取得することが可能である場合がある。ネットワーク機能は、UE 802に関する認証ベクトルおよび/またはネットワーク事業者によって署名された証明書の秘密鍵などの証明情報を維持または供給するか、あるいはそのような証明情報に関連付けられてもよい。
 
【0080】
  図17を参照する。ネットワーク事業者がネットワーク機能(たとえば、eNodeB 1708および/またはMME 1710)に公開鍵証明書をプロビジョニングし、証明書オブザーバトリ(CertOb)1714のサービスを用いるとき、ネットワークのセキュリティが強化される場合がある。CertOb 1714は、損害を与えることができない信頼できる第三者機関によって動作させられてもよい。CertOb 1714は、事業者によって発行されたネットワーク機能証明書の完全性を証明するのに使用されてもよい。CertOb 1714は、IPアドレスおよび/またはユニバーサルリソースロケータ(URL)を含む証明書オブザーバトリの識別子を使用して識別および/またはアクセスされてもよい。サービングネットワークは、公開鍵ベースの認証プロセスを使用して認証されてもよく、ネットワーク機能(たとえば、eNodeB 1708またはMME 1710)の証明書ステータスが検証されてもよい。
 
【0081】
  証明書サーバ関数(CSF)1712は、ネットワーク機能証明書を管理し、ネットワーク機能証明書を要求時にUE 1702に供給する。CSF 1712は、証明書ステータス変更をCertOb 1714に報告する。ステータス変更には発行イベント、失効イベントなどを含めてもよい。CertOb 1714は、事業者の証明書完全性情報を記憶し、情報をHSS 1706およびUE 1702に供給する。証明書完全性情報は、サービングネットワーク1704に関するすべての現在の証明書のハッシュとして供給されてもよい。一例では、ハッシュは、事業者ネットワークに対応する複数の領域に関連する証明書の効率的でセキュアな検証を可能にするMerkelハッシュツリーとして与えられてもよい。
 
【0082】
  UE 1702は、サービングネットワークによって供給される証明書完全性情報の第1のコピーをUE 1702においてCertOb 1714から受信した証明書完全性情報の第2のコピーと比較することによって、最初に証明書の妥当性を検査してもよい。証明書完全性情報の第1のコピーと第2のコピーが一致しない場合、UE 1702は、UE 1702がアクティブに通信しているネットワーク機能を認証するために、CSF 1712にサービングネットワーク1704に関する1つまたは複数の証明書を供給するよう要求してもよい。
 
【0083】
  図18、
図19、および
図20は、サービングネットワーク1704を認証するために使用される事業者署名付き公開鍵に基づく手法を使用するサービングネットワーク1704を認証するためのオンデマンドプロセスの例を示すメッセージ流れ
図1800、1900、2000である。サービングネットワーク1704には、ベリサインまたはインターネット番号割当て機関(IANA)などの信頼できる第三者機関(TTP)によって署名された証明書がプロビジョニングされてもよい。場合によっては、サービングネットワーク1704は、信頼できる認証局(CA)のリストにおけるUE 1702にホームネットワークによって供給される自己署名証明書を用いてもよい。信頼できるCAのリストは、事業者およびその対応する公開鍵を含んでもよい。CAリストおよび公開鍵または証明書のリストは、セキュアなチャネルを通してローミングパートナーに配布されてもよい。
 
【0084】
  図18は、eNodeB 1708を介したサービングネットワーク1704のオンデマンド認証にRRCメッセージ1804を使用する第5の例を示すメッセージ流れ
図1800である。UE 1702はAKA手順1802を開始してもよい。UE 1702は、AKA手順1802の間または後にHSS 1706からサービングネットワーク1704の証明書完全性情報を受信してもよい。AKA手順1802が首尾よく完了すると、UE 1702は、RRCメッセージ1804を使用してサービングネットワーク1704を認証してもよい。たとえば、アイドルモードからの遷移時に、RRC接続要求1810が用いられてもよい。UE 1702がアイドルモードに入ると、eNodeB 1708は、電力節約を目的としてUE 1702のセキュリティコンテキストを中断してもよい。いくつかの態様によれば、UE 1702は、追加のフィールドを含むRRC接続要求1810を送信してもよい。追加のフィールドには、ナンスとeNodeB 1708のシグネチャを求める要求とを含めてもよい。場合によっては、追加のフィールドに、eNodeB 1708の公開鍵を求める要求を含めてもよい。ナンスは、以前の通信を応答アタックにおいて再使用できないようにするのに使用される任意の数、乱数、または擬似乱数であってもよい。eNodeB 1708は、その秘密鍵を使用して署名された応答1812を送信してもよく、eNodeB 1708の真正性が検証されたときに、UE 1702はRRC接続セットアップ完了1814をシグナリングしてもよい。
 
【0085】
  UE 1702は、CertOb 1714からサービングネットワーク1704の現在の証明書完全性情報を取り出してもよい(1806)。UE 1702は次いで、現在の証明書完全性情報がHSS 1706によって供給される現在の証明書完全性情報と同じであることを検証してもよい。サービングネットワークの現在の証明書完全性情報が、初期接続時にHSS 1706によって供給される現在の証明書完全性情報と異なる場合、UE 1702は、たとえばCSF 1712に問い合わせる(1808)ことによってeNodeB 1708のネットワーク機能証明書を検証する。
 
【0086】
  図19は、eNodeB 1708を介したサービングネットワーク1704のオンデマンド認証にRRCメッセージ1904を使用する第6の例を示すメッセージ流れ
図1900である。UE 1702はAKA手順1902を開始してもよい。UE 1702は、AKA手順1802の間または後にHSS 1706からサービングネットワーク1704の証明書完全性情報を受信してもよい。AKA手順1902が首尾よく完了すると、UE 1702は、RRCメッセージ1904を使用してサービングネットワーク1704を認証してもよい。たとえば、接続失敗復元時に、RRC接続再確立要求1910が用いられてもよい。いくつかの態様によれば、UE 1702は、追加のフィールドを含むRRC接続再確立要求1910を送信してもよい。追加のフィールドには、ナンスとeNodeB 1708のシグネチャを求める要求とを含めてもよい。場合によっては、追加のフィールドに、eNodeB 1708の公開鍵を求める要求を含めてもよい。eNodeB 1708は、その秘密鍵を使用して署名された応答1912を送信してもよく、eNodeB 1708の真正性が検証されたときに、UE 1702はRRC接続セットアップ完了1914をシグナリングしてもよい。
 
【0087】
  UE 1702は、CertOb 1714からサービングネットワーク1704の現在の証明書完全性情報を取り出してもよい(1906)。UE 1702は次いで、現在の証明書完全性情報がHSS 1706によって供給される現在の証明書完全性情報と同じであることを検証してもよい。サービングネットワークの現在の証明書完全性情報が、初期接続時にHSS 1706によって供給される現在の証明書完全性情報と異なる場合、UE 1702は、たとえばCSF 1712に問い合わせる(1908)ことによってeNodeB 1708のネットワーク機能証明書を検証する。
 
【0088】
  UE 1702は、必要に応じて、送信すべきデータまたは受信すべきデータがあるとき、あるいは別のネットワーク機能へのハンドオーバの前または後に、RRCメッセージを使用してサービングネットワーク1704を認証してもよい。RRC接続/再確立要求はUE 1702によって開始され、そのような要求はeNodeB 1708からの応答を要求する。場合によっては、UE 1702は、サービングネットワーク1704を連続的に認証することが不要であると判定してもよい。たとえば、UE 1702がアイドル状態であり、ハンドオーバが示されていないときは、認証を実行する必要はない。シグネチャがオンデマンドで与えられるとき、ベースラインプロトコルに関連するオーバーヘッドを最小限に抑えることができる。eNodeB 1708は一般に、要求時にのみネットワーク機能証明書を供給する。
 
【0089】
  図20は、MME 1710を介したサービングネットワークのオンデマンド認証にTAUメッセージ2004を使用する第3の例を示すメッセージ流れ
図2000である。UE 1702はAKA手順2002を開始してもよい。UE 1702は、AKA手順2002の間または後にHSS 1706からサービングネットワーク1704の証明書完全性情報を受信してもよい。AKA手順2002が首尾よく完了すると、UE 1702は、TAUメッセージを使用してサービングネットワーク1704を認証してもよい。TAU要求1210は、たとえば、周期的登録時またはハンドオーバ後に用いられてもよい。いくつかの態様によれば、UE 1702は、ナンス、およびMME 1710のシグネチャを求める要求を含む場合がある追加のフィールドを有するTAU要求2010を送信してもよい。場合によっては、追加のフィールドに、MME 1710の公開鍵を求める要求を含めてもよい。MME 1710は、その秘密鍵を使用して署名された応答2012を送信してもよく、MME 1710の真正性が検証されたときに、UE 1702はRRC接続セットアップ完了2014をシグナリングしてもよい。
 
【0090】
  UE 1702は、CertOb 1714からサービングネットワーク1704の現在の証明書完全性情報を取り出してもよい(2006)。UE 1702は次いで、現在の証明書完全性情報がHSS 1706によって供給される現在の証明書完全性情報と同じであることを検証してもよい。サービングネットワークの現在の証明書完全性情報が、初期接続時にHSS 1706によって供給される現在の証明書完全性情報と異なる場合、UE 1702は、たとえばCSF 1712に問い合わせる(2008)ことによってMME 1710のネットワーク機能証明書を検証する。
 
【0091】
いくつかの態様のさらなる説明
  
図21は、本明細書において開示する1つまたは複数の機能を実行するように構成される場合がある処理回路2102を用いる装置のためのハードウェア実装形態の簡略化された例を示す概念
図2100である。本開示の様々な態様によると、本明細書で開示するような要素、または要素の任意の部分、または要素の任意の組合せは、処理回路2102を使用して実装されてもよい。処理回路2102は、ハードウェアモジュールとソフトウェアモジュールの何らかの組合せによって制御される1つまたは複数のプロセッサ2104を含む場合がある。プロセッサ2104の例には、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ(DSP)、フィールドプログラマブルゲートアレイ(FPGA)、プログラマブル論理デバイス(PLD)、ステートマシン、シーケンサ、ゲート論理、個別ハードウェア回路、および本開示全体にわたって記載された様々な機能を実施するように構成された他の適切なハードウェアが含まれる。1つまたは複数のプロセッサ2104は、特定の機能を実施し、ソフトウェアモジュール2116のうちの1つによって構成され、増強され、または制御されてもよい専用プロセッサを含んでもよい。1つまたは複数のプロセッサ2104は、初期化中にロードされたソフトウェアモジュール2116の組合せを介して構成され、動作中に1つまたは複数のソフトウェアモジュール2116のローディングまたはアンローディングによってさらに構成されてもよい。
 
【0092】
  図示の例では、処理回路2102は、バス2110によって概略的に表されるバスアーキテクチャを用いて実装されてもよい。バス2110は、処理回路2102の特定の適用例および全体的な設計制約に応じて、任意の数の相互接続バスおよびブリッジを含んでもよい。バス2110は、1つまたは複数のプロセッサ2104および記憶装置2106を含む様々な回路を互いにリンクする。ストレージ2106は、メモリデバイスおよび大容量ストレージデバイスを含んでもよく、本明細書ではコンピュータ可読媒体および/またはプロセッサ可読媒体と呼ばれる場合がある。バス2110は、タイミングソース、タイマー、周辺機器、電圧調整器、および電力管理回路などの様々な他の回路をリンクさせてもよい。バスインターフェース2108は、バス2110と1つまたは複数のトランシーバ2112との間のインターフェースを実現してもよい。トランシーバ2112は、処理回路によってサポートされるネットワーキング技術ごとに設けられてもよい。場合によっては、複数のネットワーキング技術が、トランシーバ2112内に設けられる回路または処理モジュールの一部または全部を共有してもよい。各トランシーバ2112は、伝送媒体を介して様々な他の装置と通信するための手段を構成する。装置の性質に応じて、ユーザインターフェース2118(たとえば、キーパッド、ディスプレイ、スピーカ、マイクロフォン、ジョイスティック)が設けられてもよく、直接またはバスインターフェース2108を通じてバス2110に通信可能に結合されてもよい。
 
【0093】
  プロセッサ2104は、バス2110を管理することと、ストレージ2106を含む場合があるコンピュータ可読媒体内に記憶されたソフトウェアの実行を含む場合がある一般的な処理とを担ってもよい。この点で、プロセッサ2104を含む処理回路2102は、本明細書において開示する方法、機能および技法のうちのいずれかを実装するために使用されてもよい。ストレージ2106は、ソフトウェアを実行するとき、プロセッサ2104によって処理されるデータを記憶するために使用されてよく、ソフトウェアは、本明細書で開示する方法のうちの任意の1つを実施するように構成されてよい。
 
【0094】
  処理回路2102の中の1つまたは複数のプロセッサ2104は、ソフトウェアを実行してもよい。ソフトウェアは、コンピュータ可読の形でストレージ2106中または外部コンピュータ可読媒体中に存在してもよい。外部コンピュータ可読媒体および/またはストレージ2106は、非一時的コンピュータ可読媒体を含んでもよい。非一時的コンピュータ可読媒体は、例として、磁気ストレージデバイス(たとえば、ハードディスク、フロッピー(登録商標)ディスク、磁気ストリップ)、光ディスク(たとえば、CDまたはDVD)、スマートカード、フラッシュメモリデバイス(たとえば、「フラッシュドライブ」、カード、スティック、またはキードライブ)、RAM、ROM、PROM、EPROM、EEPROM、レジスタ、リムーバブルディスク、ならびに、コンピュータがアクセスし読み取ることができるソフトウェアおよび/または命令を記憶するための任意の他の適切な媒体を含む。コンピュータ可読媒体および/またはストレージ2106は、例として、搬送波、伝送路、ならびに、コンピュータがアクセスし読み取ることができるソフトウェアおよび/または命令を送信するための任意の他の適切な媒体も含んでもよい。コンピュータ可読可読媒体および/またはストレージ2106は、処理回路2102中に存在するか、プロセッサ2104中に存在するか、処理回路2102の外部に存在するか、または処理回路2102を含む複数のエンティティにわたって分散されてもよい。コンピュータ可読媒体および/またはストレージ2106は、コンピュータプログラム製品において具現化されてもよい。例として、コンピュータプログラム製品は、パッケージング材料の中のコンピュータ可読媒体を含んでよい。特定の適用例および全体的なシステムに課された全体的な設計制約に応じて、本開示全体にわたって提示される前述の機能がどのようにすれば最も適切に実装されるかを、当業者は認識するだろう。
 
【0095】
  ストレージ2106は、本明細書でソフトウェアモジュール2116と呼ばれる場合がある、ロード可能なコードセグメント、モジュール、アプリケーション、プログラムなどにおいて維持かつ/または構成されるソフトウェアを維持してもよい。ソフトウェアモジュール2116の各々は、処理回路2102にインストールまたはロードされ、1つまたは複数のプロセッサ2104によって実行されるとき、1つまたは複数のプロセッサ2104の動作を制御するランタイムイメージ2114に寄与する命令およびデータを含んでもよい。いくつかの命令は、実行されたときに、処理回路2102に、本明細書で説明するいくつかの方法、アルゴリズム、およびプロセスに従って機能を実行させてもよい。
 
【0096】
  ソフトウェアモジュール2116のうちのいくつかは、処理回路2102の初期化中にロードされてもよく、これらのソフトウェアモジュール2116は、本明細書で開示する様々な機能の実施を可能にするように処理回路2102を構成してもよい。たとえば、いくつかのソフトウェアモジュール2116は、プロセッサ2104の内部デバイスおよび/または論理回路2122を構成してもよく、トランシーバ2112、バスインターフェース2108、ユーザインターフェース2118、タイマー、数学的コプロセッサなどの外部デバイスへのアクセスを管理してもよい。ソフトウェアモジュール2116は、割込みハンドラおよびデバイスドライバと対話し、処理回路2102によって提供される様々なリソースへのアクセスを制御する制御プログラムおよび/またはオペレーティングシステムを含んでもよい。リソースは、メモリ、処理時間、トランシーバ2112へのアクセス、ユーザインターフェース2118などを含んでもよい。
 
【0097】
  処理回路2102の1つまたは複数のプロセッサ2104は、多機能であってもよく、それにより、ソフトウェアモジュール2116のうちのいくつかがロードされ、異なる機能または同じ機能の異なるインスタンスを実行するように構成される。1つまたは複数のプロセッサ2104は、さらに、たとえば、ユーザインターフェース2118、トランシーバ2112、およびデバイスドライバからの入力に応答して開始されるバックグラウンドタスクを管理するように適合されてもよい。複数の機能の実行をサポートするために、1つまたは複数のプロセッサ2104は、マルチタスク環境を提供するように構成されてもよく、それにより、複数の機能の各々が、必要または要望に応じて、1つまたは複数のプロセッサ2104によってサービスされるタスクのセットとして実装される。一例では、マルチタスク環境は、異なるタスク間でプロセッサ2104の制御を渡す時分割プログラム2120を使用して実装されてもよく、それにより、各タスクは、任意の未処理動作が完了したときに、ならびに/あるいは割込みなどの入力に応答して、時分割プログラム2120に1つまたは複数のプロセッサ2104の制御を戻す。あるタスクが1つまたは複数のプロセッサ2104の制御を有するとき、処理回路は、制御中のタスクに関連する機能によって対処される目的に事実上特化される。時分割プログラム2120は、オペレーティングシステム、ラウンドロビンベースで制御を移すメインループ、機能の優先度付けに従って1つもしくは複数のプロセッサ2104の制御を割り振る機能、および/または、1つもしくは複数のプロセッサ2104の制御を処理機能によって実行することによって外部イベントに応答する割込み駆動のメインループを含んでもよい。
 
【0098】
  以下のフローチャートは、本明細書において開示するいくつかの態様に従って適合または構成されるネットワーク要素に対して実行されるかまたは動作可能な方法およびプロセスを示す。これらの方法およびプロセスは、ほんのいくつかの例を挙げれば、3G技術、4G技術、および5G技術を含む任意の適切なネットワーク技術において実施されてもよい。したがって、特許請求の範囲は単一のネットワーク技術に制限されない。この点について、「UE」が参照される場合、移動局、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、または他の何らかの適切な用語も参照されることが理解されよう。「eNodeB」が参照される場合、基地局、トランシーバ基地局、無線基地局、無線トランシーバ、トランシーバ機能、基本サービスセット、拡張サービスセット、または何らかの他の適切な用語が参照されることが理解されよう。MMEが参照される場合、サービングネットワークにおけるオーセンティケータとして働くエンティティおよび/またはたとえばモバイルスイッチングセンターなどの一次サービス提供ノードが参照される場合もある。HSSが参照される場合、ユーザ関連情報および加入者関連情報を含み、たとえば、ホームロケーションレジスタ(HLR)、認証センター(AuC)、および/または認証、許可、およびアカウンティング(AAA)サーバを含む、モビリティ管理、呼およびセッションセットアップ、ならびに/あるいはユーザ認証およびアクセス許可におけるサポート機能を実現するデータベースが参照される場合もある。
 
【0099】
  図22は、UEとサービングネットワークとの間のワイヤレス通信をセキュアにする方法のフローチャート2200である。
 
【0100】
  ブロック2202において、UEは、UEとサービングネットワークとの間にセキュリティアソシエーションが確立された後に、接続要求またはトラッキングエリア要求をサービングネットワークにおけるネットワーク機能に送信してもよい。この要求は、ナンスとシグネチャ要求とを含んでもよい。サービングネットワークに送信される要求は、UEがアイドルモードから遷移している間またはアイドルモードからのそのような遷移の後に送信されてもよい。場合によっては、サービングネットワークに送信される要求はRRCメッセージであってもよい。RRCメッセージは、RRC接続要求、RRC接続再確立要求、および/またはRRC再構成完了メッセージであってもよい。場合によっては、サービングネットワークに送信される要求はTAU要求であってもよい。
 
【0101】
  ブロック2204において、UEは、ネットワーク機能から接続要求またはトラッキングエリア要求に対する応答を受信してもよい。この応答はネットワーク機能のシグネチャを含んでもよい。
 
【0102】
  ブロック2206において、UEは、ネットワーク機能のシグネチャおよびネットワーク機能に対応する公開鍵証明書に基づいてサービングネットワークを認証してもよい。公開鍵証明書は、サービングネットワークに関連するネットワーク事業者によって供給されるサービングネットワークの秘密鍵を使用して署名されてもよい。UEは、信頼できるネットワークに対応する公開鍵または公開鍵証明書を識別する信頼できるネットワークのリストを維持してもよい。UEは、信頼できるネットワークのリストを使用してネットワーク機能の公開鍵およびネットワーク機能によって生成されるシグネチャを検証することによってサービングネットワークを認証してもよい。サービングネットワークは、信頼できる第三者機関を使用してネットワーク機能に対応する公開鍵証明書を検証することによって認証されてもよい。
 
【0103】
  場合によっては、証明書完全性情報要求がネットワークに送信されてもよく、ネットワークからの応答において受信された第1の証明書完全性情報が、ホーム加入者サーバから受信された第2の証明書完全性情報を使用して検証されてもよい。証明書完全性情報要求は、第2の証明書完全性情報に対応する証明書オブザーバトリ(
図17のCertOb 1714など)の識別子を含んでもよい。CertOb 1714は、ネットワークに関する証明書のセットの完全性を維持するように構成されてもよい。CertOb 1714の識別子はIPアドレスまたはURLであってもよい。第1の証明書完全性情報は、CertOb 1714の公開鍵を使用して証明書完全性情報要求に対する応答を認証することによって検証されてもよい。場合によっては、第1の証明書完全性情報は、第1の証明書完全性情報を第2の証明書完全性情報と比較し、第1の証明書完全性情報と第2の証明書完全性情報との間に違いがあると判定されたときに証明書ステータス要求をCSF 1712に送信し、CSF 1712からの応答に基づいてネットワーク機能証明書のステータスを検証することによって検証されてもよい。証明書ステータス要求は、ネットワーク機能を識別する第1の識別情報と、ネットワーク機能証明書を識別する第2の識別情報と、ネットワーク機能証明書のバージョン番号とを含んでもよい。CSF 1712からの応答は、ネットワーク機能証明書のステータスと、ネットワークの公開鍵と、ネットワークの秘密鍵を使用してCSF 1712によって作成される証明書ステータス応答のシグネチャとを含む証明書ステータス応答を含んでもよい。ネットワークの公開鍵を使用して証明書ステータス応答の検証が実行されてもよい。
 
【0104】
  図23は、処理回路2302を用いる装置2300のためのハードウェア実装形態の簡略化された例を示す図である。処理回路は、一般に、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、シーケンサ、およびステートマシンのうちの1つまたは複数を含む場合があるプロセッサ2316を有する。処理回路2302は、概してバス2320によって表されるバスアーキテクチャを用いて実装されてもよい。バス2320は、処理回路2302の特定の適用例および全体的な設計制約に応じて、任意の数の相互接続バスおよびブリッジを含んでもよい。バス2320は、プロセッサ2316と、モジュールまたは回路2304、2306および2308と、アンテナ2314を介して通信するように適合されたワイヤレストランシーバ2312と、コンピュータ可読記憶媒体2318とによって表された、1つまたは複数のプロセッサおよび/またはハードウェアモジュールを含む様々な回路同士をリンクする。バス2320は、タイミングソース、周辺機器、電圧レギュレータ、および電源管理回路などの種々の他の回路をリンクしてもよいが、これらの回路は当技術分野でよく知られており、したがってこれ以上は説明しない。
 
【0105】
  プロセッサ2316は、コンピュータ可読記憶媒体2318上に記憶されたソフトウェアの実行を含む全体的な処理を担う。ソフトウェアは、プロセッサ2316によって実行されたときに、処理回路2302に、任意の特定の装置のための上記で説明した様々な機能を実施させる。コンピュータ可読記憶媒体2318はまた、ソフトウェアを実行するときに、データレーンおよびクロックレーンとして構成されてもよいアンテナ2314を介して送信されたシンボルから復号されるデータを含む、プロセッサ2316によって処理されるデータを記憶するために使用されてもよい。処理回路2302は、モジュール2304、2306、および2308のうちの少なくとも1つをさらに含む。モジュール2304、2306、および2308は、コンピュータ可読記憶媒体2318に存在する/記憶される、プロセッサ2316内で動作しているソフトウェアモジュール、プロセッサ2316に結合された1つもしくは複数のハードウェアモジュール、またはそれらの何らかの組合せであってもよい。モジュール2304、2306、および/または2308は、マイクロコントローラ命令、ステートマシン構成パラメータ、またはそれらの何らかの組合せを含んでもよい。
 
【0106】
  一構成では、ワイヤレス通信用の装置2300は、ホームネットワークとの接続を認証しならびに/あるいはセキュアにするように構成されたモジュールおよび/または回路2304と、サービングネットワークを認証するように構成されたモジュールおよび/または回路2306と、サービングネットワークとの間でメッセージを送受信するように構成されたモジュールおよび/または回路2308とを含む。
 
【0107】
  一例では、ワイヤレストランシーバ2312は、サービングネットワークにおけるワイヤレス基地局にメッセージを送信し、ワイヤレス基地局からメッセージを受信するように構成されてもよい。モジュールおよび/または回路2304は、装置とホームネットワークとの間にセキュアな接続を確立するための手段を含んでもよい。認証された接続は、ワイヤレストランシーバを通してHSSに送信される第1の認証メッセージに応答して確立されてもよい。モジュールおよび/または回路2308、2312は、セキュアな接続が確立されてから第2の認証要求がホームネットワークのHSSに送信されるまでの間、サービングネットワークにおけるネットワーク機能に、ナンスおよびシグネチャ要求が添付された要求を送信し、ネットワーク機能のシグネチャを含む要求に対する応答をネットワーク機能から受信するための手段を含んでもよい。モジュールおよび/または回路2306は、ネットワーク機能のシグネチャおよびネットワーク機能に対応しネットワーク事業者によって署名された公開鍵証明書に基づいてサービングネットワークを認証するための手段を含んでもよい。ネットワーク機能に対応する公開鍵証明書は、装置によって維持される信頼できるネットワークおよびそのそれぞれの公開鍵証明書のリストに含まれてもよい。
 
【0108】
  モジュールおよび/または回路2308、2312は、ネットワークに証明書完全性情報要求を送信するための手段を含んでもよく、モジュールおよび/または回路2306は、ネットワークから受信される第1の証明書完全性情報を、HSSから受信される第2の証明書完全性情報を使用して検証するための手段を含んでもよい。証明書完全性情報要求は、第2の証明書完全性情報に対応するCertOb 1714の識別子を含む。CertOb 1714は、ネットワークに関する証明書のセットの完全性を維持するように構成されてもよい。
 
【0109】
  モジュールおよび/または回路2306は、第1の証明書完全性情報を第2の証明書完全性情報と比較し、第1の証明書完全性情報と第2の証明書完全性情報との間に違いがあると判定されたときにモジュールおよび/または回路2308、2312に証明書ステータス要求をCSF 1712に送信させ、CSF 1712からの応答に基づいてネットワーク機能証明書のステータスを検証するように構成されてもよい。証明書ステータス要求は、ネットワーク機能の識別子と、ネットワーク機能証明書の識別子と、ネットワーク機能証明書のバージョン番号とを含んでもよい。
 
【0110】
  図24は、サービングネットワークのメンバーシップを証明する方法のフローチャート2400である。この方法は、サービングネットワークのネットワークノード(またはネットワーク機能)によって実行されてもよい。
 
【0111】
  ブロック2202において、ネットワークノードは、UEがホームネットワークとのセキュアな接続を確立した後にUEから第1のメッセージを受信してもよい。このメッセージは、サービングネットワークのネットワーク機能を対象としてもよい。このメッセージは、ナンスとシグネチャ要求とを含んでもよい。
 
【0112】
  ブロック2204において、ネットワークノードは、サービングネットワークのネットワーク機能によって維持される事業者署名付き証明書を使用してシグネチャを生成してもよい。事業者署名付き証明書は、サービングネットワークの事業者によって署名された公開鍵証明書であってもよい。事業者署名付き証明書に対応する秘密鍵は、セキュアなストレージもしくはセキュアな実行環境および/または信頼できる環境に維持されてもよい。
 
【0113】
  ブロック2206において、ネットワークノードは、UEに第2のメッセージを送信してもよい。シグネチャは第2のメッセージに添付されてもよい。
 
【0114】
  場合によっては、シグネチャは、UEとネットワーク機能との間で共有されるセッション鍵を使用して作成されるMACを含む。第2のメッセージ応答の署名に対称暗号が使用されてもよい。
 
【0115】
  場合によっては、ネットワークノードはMMEであってもよく、セッション鍵はK
ASMEであってもよい。MMEは、MMEの公開鍵を使用して暗号化されたメッセージにおいてHSSからK
ASMEを受信し、信頼できる環境内に記憶された秘密鍵を使用してK
ASMEを解読し、解読されたK
ASMEを信頼できる環境内に記憶してもよい。認証要求は、TAU要求において受信されてもよい。
 
【0116】
  場合によっては、ネットワークノードはeNodeBであってもよく、セッション鍵はKeNBであってもよい。eNodeBは、eNodeBの公開鍵を使用して暗号化されたメッセージにおいてMMEからKeNBを受信し、信頼できる環境内に記憶された秘密鍵を使用してKeNBを解読し、解読されたKeNBを信頼できる環境内に記憶してもよい。第1のメッセージは無線リソース制御(RRC)メッセージであり、第2のメッセージはRRCメッセージに対する応答であってもよい。たとえば、RRCメッセージは、RRC接続確立要求、RRC接続再確立要求、またはRRC再構成完了メッセージであってもよい。
 
【0117】
  場合によっては、シグネチャは、ネットワークノードの秘密鍵を使用して作成されたデジタルシグネチャを含む。認証応答の署名に非対称暗号が使用されてもよい。ネットワークノードの秘密鍵は信頼できる環境内に記憶されてもよく、シグネチャは信頼できる環境内で作成されてもよい。
 
【0118】
  図25は、処理回路2502を用いる装置2500のためのハードウェア実装形態の簡略化された例を示す図である。処理回路は、一般に、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、シーケンサ、およびステートマシンのうちの1つまたは複数を含む場合があるプロセッサ2516を有する。処理回路2502は、バス2520によって概略的に表されたバスアーキテクチャを用いて実装されてもよい。バス2520は、処理回路2502の特定の適用例および全体的な設計制約に応じて、任意の数の相互接続バスおよびブリッジを含んでもよい。バス2520は、プロセッサ2516と、モジュールまたは回路2504、2506および2508と、アンテナ2514を介して通信するように適合されたワイヤレストランシーバ2512と、コンピュータ可読記憶媒体2518とによって表された、1つまたは複数のプロセッサおよび/またはハードウェアモジュールを含む様々な回路同士をリンクする。バス2520は、タイミングソース、周辺機器、電圧レギュレータ、および電源管理回路などの種々の他の回路をリンクしてもよいが、これらの回路は当技術分野でよく知られており、したがってこれ以上は説明しない。
 
【0119】
  プロセッサ2516は、コンピュータ可読記憶媒体2518上に記憶されたソフトウェアの実行を含む全体的な処理を担う。ソフトウェアは、プロセッサ2516によって実行されたときに、処理回路2502に、任意の特定の装置のための上記で説明した様々な機能を実施させる。コンピュータ可読記憶媒体2518はまた、ソフトウェアを実行するときに、データレーンおよびクロックレーンとして構成されてもよいアンテナ2514を介して送信されたシンボルから復号されるデータを含む、プロセッサ2516によって処理されるデータを記憶するために使用されてもよい。処理回路2502は、モジュール2504、2506、および2508のうちの少なくとも1つをさらに含む。モジュール2504、2506、および2508は、コンピュータ可読記憶媒体2518に存在する/記憶される、プロセッサ2516内で動作しているソフトウェアモジュール、プロセッサ2516に結合された1つもしくは複数のハードウェアモジュール、またはそれらの何らかの組合せであってもよい。モジュール2504、2506、および/または2508は、マイクロコントローラ命令、ステートマシン構成パラメータ、またはそれらの何らかの組合せを含んでもよい。
 
【0120】
  一構成では、ワイヤレス通信用の装置2500は、認証シグネチャを生成するように構成されたモジュールおよび/または回路2504と、UEにメッセージを送信するように構成されたモジュールおよび/または回路2506と、UEからメッセージを受信するように構成されたモジュールおよび/または回路2508とを含む。
 
【0121】
  一例では、モジュールおよび/または回路2508は、UEがホームネットワークとのセキュアな接続を確立した後にUEから第1のメッセージを受信するための手段を構成してもよい。このメッセージは、サービングネットワークのネットワーク機能を対象としてもよく、ナンスとシグネチャ要求とを含み、モジュールおよび/または回路2504は、サービングネットワークのネットワーク機能によって維持される事業者署名付き証明書を使用してシグネチャを生成するための手段を構成してもよく、モジュールおよび/または回路2506は、UEに第2のメッセージを送信するための手段を構成してもよく、この場合、シグネチャは第2のメッセージに添付されてもよい。第2のメッセージに添付されるシグネチャは、装置2500がサービングネットワークのメンバーであることをUEに証明するために生成されてもよい。事業者署名付き証明書は、サービングネットワークの事業者によって署名された公開鍵証明書であってもよい。
 
【0122】
  場合によっては、ネットワークノードはeNodeBであり、第1のメッセージはRRCメッセージであり、第2のメッセージはRRCメッセージに対する応答である。
 
【0123】
  場合によっては、ネットワークノードはMMEであり、認証要求はTAU要求において受信される。
 
【0124】
  開示したプロセスにおけるステップの特定の順序または階層は、例示的な手法の例示であることを理解されたい。設計上の選好に基づいて、プロセスにおけるステップの特定の順序または階層は再構成されてもよいことを理解されたい。さらに、いくつかのステップは、組み合わせられるか、または省略される場合がある。添付の方法クレームは、種々のステップの要素を見本的な順序において提示したものであり、提示された特定の順序または階層に限定されるものではない。
 
【0125】
  上記の説明は、本明細書において説明した種々の態様を任意の当業者が実践できるようにするために提供される。これらの態様に対する種々の変更形態は、当業者に容易に明らかになり、本明細書において規定する一般原理は、他の態様に適用される場合がある。したがって、特許請求の範囲は本明細書に示された態様に限定されるものではなく、文言通りの特許請求の範囲に一致するすべての範囲を与えられるべきであり、単数形の要素への言及は、そのように明記されていない限り、「唯一無二の」を意味するものではなく、「1つまたは複数の」を意味するものである。別段に明記されていない限り、「いくつかの」という用語は1つまたは複数を指している。当業者にとって既知の、または後に既知となる、本開示全体を通じて説明された種々の態様の要素に対するすべての構造的および機能的均等物が、参照により本明細書に明白に組み込まれ、特許請求の範囲によって包含されることが意図される。さらに、本明細書において開示されるものは、そのような開示が特許請求の範囲において明示的に列挙されているかどうかにかかわらず、公に供されることは意図されていない。いかなるクレーム要素も、要素が「ための手段」という語句を用いて明確に記述されていない限り、ミーンズプラスファンクションとして解釈されるべきではない。