(57)【要約】  中継ノード認証のソリューションを提案する。このソリューションは、中継ノード及び中継UICCの相互認証、中継ノード及びネットワークの相互認証、中継UICCと中継ノードの間におけるセキュアチャネルの確立を含む。TS 33.401におけるAKA手順を再利用し、以てNASメッセージの追加を不要とする。IMEIが初期のNASメッセージでネットワークへ送信され、これに従い、MMEは、HSSからRNの公開キーを検索し、DeNBに対するアクセス制御を行うことができる。MME-RNは、IMSI、IMEI及びKasmeに基づいてセッションキーを生成し、RNの公開キーによりセッションキーを暗号化してRNへ送信するだろう。また、UICCが同一のキーを生成するだろうから、RNは、UICC及びネットワークの両者を認証できる。UICCとRNの間で送信されるキー又は他のパラメータが一致しない場合、UICC又はRNは、ネットワークへ知らせるための新たな要因を含むAuthentication Rejectメッセージを送出するだろう。【選択図】図１
2013537374.tif 000002
【特許請求の範囲】
【請求項１】
ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）と基地局との間でトラヒックを無線中継することが可能な中継ノードであって、
自中継ノードの識別子を、自中継ノード用の秘密キーで暗号化する第１の手段と、
前記暗号化した識別子及び平文の識別子を、前記基地局を介して、自中継ノード用の公開キーを有するネットワークへ送信する第２の手段と、
を備えた中継ノード。
【請求項２】
請求項１において、
前記基地局を介して前記ネットワークから、前記公開キーで暗号化され、且つ少なくとも自中継ノードへのバインドを許可されたＩＣＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）に関する情報を用いて導出された第１のセッションキーを受信する第３の手段と、
前記第１のセッションキーを、前記秘密キーで復号化する第４の手段と、をさらに備え、
前記第１の手段は、前記識別子を、前記復号化された第１のセッションキーで暗号化し、
前記第２の手段は、自中継ノードへバインドされたＩＣＣに対し、前記復号化した第１のセッションキーで暗号化された識別子と前記平文の識別子とを送信して、前記バインドされたＩＣＣに自中継ノードを認証させる、
ことを特徴とした中継ノード。
【請求項３】
請求項２において、
前記情報は、前記許可されたＩＣＣに付与される識別子、及び前記許可されたＩＣＣによって生成され得るパラメータの少なくとも一方である、
ことを特徴とした中継ノード。
【請求項４】
請求項２又は３において、
前記第１のセッションキーは、前記情報に加え、自中継ノードの前記識別子を用いて導出される、
ことを特徴とした中継ノード。
【請求項５】
請求項２〜４のいずれか一項において、
前記第３の手段は、前記バインドされたＩＣＣから、自中継ノードと前記バインドされたＩＣＣの間でセキュアに通信を行うための暗号化された第２のセッションキーを受信し、
前記第４の手段は、前記第２のセッションキーを、前記復号化した第１のセッションキーで復号化する、
ことを特徴とした中継ノード。
【請求項６】
請求項２〜５のいずれか一項において、
前記第１の手段は、前記バインドされたＩＣＣが自中継ノードの認証に成功した場合に、前記バインドされたＩＣＣの識別子を、前記復号化した第１のセッションキーで暗号化し、
前記第２の手段は、前記暗号化した前記バインドされたＩＣＣの識別子を、前記基地局を介して前記ネットワークへ送信する、
ことを特徴とした中継ノード。
【請求項７】
請求項２〜６のいずれか一項において、
前記第２の手段は、前記バインドされたＩＣＣが自中継ノードの認証に失敗した場合に、前記失敗の要因を、前記基地局を介して前記ネットワークへ送信する、
ことを特徴とした中継ノード。
【請求項８】
請求項１〜７のいずれか一項において、
前記第１の手段は、自中継ノードにバインドされたＩＣＣの識別子を、前記秘密キーで暗号化し、
前記第２の手段は、前記暗号化したＩＣＣの識別子を、前記基地局を介して前記ネットワークへ送信して、前記ネットワークに、前記バインドされたＩＣＣが自中継ノードへのバインドを許可されたＩＣＣであるか否かをチェックさせる、
ことを特徴とした中継ノード。
【請求項９】
基地局に対するアクセス制御を行うネットワークノードであって、
前記基地局を介して、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）と前記基地局との間でトラヒックを無線中継することが可能な中継ノードから、前記中継ノード用の秘密キーで暗号化された前記中継ノードの識別子と、平文の識別子とを受信する第１の手段と、
サーバから、前記中継ノード用の公開キーを検索する第２の手段と、
前記暗号化された識別子を、前記公開キーで復号化する第３の手段と、
前記復号化した識別子と前記平文の識別子とを比較して、前記中継ノードを認証する第４の手段と、
を備えたネットワークノード。
【請求項１０】
請求項９において、
少なくとも前記中継ノードへのバインドを許可されたＩＣＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）に関する情報を用いて、第１のセッションキーを導出する第５の手段と、
前記第１のセッションキーを、前記公開キーで暗号化する第６の手段と、
前記暗号化した第１のセッションキーを、前記基地局を介して前記中継ノードへ送信する第７の手段と、
をさらに備えたネットワークノード。
【請求項１１】
請求項１０において、
前記第５の手段は、前記情報として、前記許可されたＩＣＣに付与される識別子、及び前記許可されたＩＣＣによって生成され得るパラメータの少なくとも一方を用いる、
ことを特徴としたネットワークノード。
【請求項１２】
請求項１０又は１１において、
前記第５の手段は、前記情報に加え、前記中継ノードの識別子を用いて前記第１のセッションキーを導出する、
ことを特徴としたネットワークノード。
【請求項１３】
請求項９〜１２のいずれか一項において、
前記第１の手段は、前記基地局を介して前記中継ノードから、前記中継ノードにバインドされたＩＣＣの識別子であって、前記秘密キーで暗号化された識別子を受信し、
前記第３の手段は、前記バインドされたＩＣＣの識別子を、前記公開キーで復号化し、
前記第４の手段は、前記復号化したＩＣＣの識別子に基づき、前記バインドされたＩＣＣを認証する、
ことを特徴としたネットワークノード。
【請求項１４】
請求項１３において、
前記第４の手段は、前記サーバへ前記復号化したＩＣＣの識別子を通知して、前記バインドされたＩＣＣが前記中継ノードへのバインドを許可されているか否かをチェックすることによって、前記バインドされたＩＣＣを認証する、
ことを特徴としたネットワークノード。
【請求項１５】
請求項９〜１４のいずれか一項において、
前記中継ノードの識別子に基づき、前記中継ノードが前記基地局へのアクセスを許可されているか否かを判定する手段、
をさらに備えたネットワークノード。
【請求項１６】
請求項９〜１５のいずれか一項において、
前記第１の手段は、前記中継ノードにバインドされたＩＣＣが前記中継ノードの認証に失敗した場合に、前記失敗の要因を、前記基地局を介して前記中継ノードから受信する、
ことを特徴としたネットワークノード。
【請求項１７】
請求項１０〜１６のいずれか一項において、
前記第２の手段は、前記サーバから、前記中継ノードがアクセスすることを許可された１以上の基地局のリストを検索し、
前記第７の手段は、前記リストを、前記基地局を介して前記中継ノードへ送信する、
ことを特徴としたネットワークノード。
【請求項１８】
ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）と基地局との間でトラヒックを無線中継する中継ノードへバインドすることが可能なＩＣＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）であって、
前記中継ノードから、暗号化された前記中継ノードの識別子及び平文の識別子を受信する第１の手段と、
少なくとも自ＩＣＣに関する情報を用いて、第１のセッションキーを導出する第２の手段と、
前記暗号化された識別子を、前記第１のセッションキーで復号化する第３の手段と、
前記復号化した識別子と前記平文の識別子とを比較して、前記中継ノードを認証する第４の手段と、
を備えたＩＣＣ。
【請求項１９】
請求項１８において、
前記第２の手段は、前記情報として、自ＩＣＣに付与された識別子、及び自ＩＣＣで生成可能なパラメータの少なくとも一方を用いる、
ことを特徴としたＩＣＣ。
【請求項２０】
請求項１８又は１９において、
前記第２の手段は、前記情報に加え、自ＩＣＣがバインドすることを許可された中継ノードの識別子を用いて、前記第１のセッションキーを導出する、
ことを特徴としたＩＣＣ。
【請求項２１】
請求項１８〜２０のいずれか一項において、
前記中継ノードと自ＩＣＣとの間でセキュアに通信を行うための第２のセッションキーを導出する手段と、
前記第２のセッションキーを、前記第１のセッションキーで暗号化する手段と、
前記暗号化した第２のセッションキーを、前記中継ノードへ送信する手段と、
をさらに備えたＩＣＣ。
【請求項２２】
ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）と基地局との間でトラヒックを無線中継することが可能な中継ノードの制御方法であって、
前記中継ノードの識別子を、前記中継ノード用の秘密キーで暗号化し、
前記暗号化した識別子及び平文の識別子を、前記基地局を介して、前記中継ノード用の公開キーを有するネットワークへ送信する、
ことを含む方法。
【請求項２３】
請求項２２において、
前記基地局を介して前記ネットワークから、前記公開キーで暗号化され、且つ少なくとも前記中継ノードへのバインドを許可されたＩＣＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）に関する情報を用いて導出された第１のセッションキーを受信し、
前記第１のセッションキーを、前記秘密キーで復号化し、
前記識別子を、前記復号化された第１のセッションキーで暗号化し、
前記中継ノードへバインドされたＩＣＣに対し、前記復号化した第１のセッションキーで暗号化された識別子と前記平文の識別子とを送信して、前記バインドされたＩＣＣに前記中継ノードを認証させる、
ことをさらに含む方法。
【請求項２４】
請求項２３において、
前記バインドされたＩＣＣから、前記中継ノードと前記バインドされたＩＣＣの間でセキュアに通信を行うための暗号化された第２のセッションキーを受信し、
前記第２のセッションキーを、前記復号化した第１のセッションキーで復号化する、
ことをさらに含む方法。
【請求項２５】
請求項２３又は２４において、
前記バインドされたＩＣＣが前記中継ノードの認証に成功した場合に、前記バインドされたＩＣＣの識別子を、前記復号化した第１のセッションキーで暗号化し、
前記暗号化した前記バインドされたＩＣＣの識別子を、前記基地局を介して前記ネットワークへ送信する、
ことをさらに含む方法。
【請求項２６】
請求項２３〜２５のいずれか一項において、
前記バインドされたＩＣＣが前記中継ノードの認証に失敗した場合に、前記失敗の要因を、前記基地局を介して前記ネットワークへ送信する、
ことをさらに含む方法。
【請求項２７】
請求項２２〜２６のいずれか一項において、
前記中継ノードにバインドされたＩＣＣの識別子を、前記秘密キーで暗号化し、
前記暗号化したＩＣＣの識別子を、前記基地局を介して前記ネットワークへ送信して、前記ネットワークに、前記バインドされたＩＣＣが前記中継ノードへのバインドを許可されたＩＣＣであるか否かをチェックさせる、
ことをさらに含む方法。
【請求項２８】
基地局に対するアクセス制御を行うネットワークノードの制御方法であって、
前記基地局を介して、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）と前記基地局との間でトラヒックを無線中継することが可能な中継ノードから、前記中継ノード用の秘密キーで暗号化された前記中継ノードの識別子と、平文の識別子とを受信し、
サーバから、前記中継ノード用の公開キーを検索し、
前記暗号化された識別子を、前記公開キーで復号化し、
前記復号化した識別子と前記平文の識別子とを比較して、前記中継ノードを認証する、
ことを含む方法。
【請求項２９】
請求項２８において、
少なくとも前記中継ノードへのバインドを許可されたＩＣＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）に関する情報を用いて、第１のセッションキーを導出し、
前記第１のセッションキーを、前記公開キーで暗号化し、
前記暗号化した第１のセッションキーを、前記基地局を介して前記中継ノードへ送信する、
ことをさらに含む方法。
【請求項３０】
請求項２９において、
前記情報として、前記許可されたＩＣＣに付与される識別子、及び前記許可されたＩＣＣによって生成され得るパラメータの少なくとも一方を用いる、
ことを特徴とした方法。
【請求項３１】
請求項２９又は３０において、
前記情報に加え、前記中継ノードの識別子を用いて前記第１のセッションキーを導出する、
ことを特徴とした方法。
【請求項３２】
請求項２８〜３１のいずれか一項において、
前記基地局を介して前記中継ノードから、前記中継ノードにバインドされたＩＣＣの識別子であって、前記秘密キーで暗号化された識別子を受信し、
前記バインドされたＩＣＣの識別子を、前記公開キーで復号化し、
前記復号化したＩＣＣの識別子に基づき、前記バインドされたＩＣＣを認証する、
ことをさらに含む方法。
【請求項３３】
請求項３２において、
前記サーバへ前記復号化したＩＣＣの識別子を通知して、前記バインドされたＩＣＣが前記中継ノードへのバインドを許可されているか否かをチェックすることによって、前記バインドされたＩＣＣを認証する、
ことを特徴とした方法。
【請求項３４】
請求項２８〜３３のいずれか一項において、
前記中継ノードの識別子に基づき、前記中継ノードが前記基地局へのアクセスを許可されているか否かを判定する、
ことをさらに含む方法。
【請求項３５】
請求項２８〜３４のいずれか一項において、
前記中継ノードにバインドされたＩＣＣが前記中継ノードの認証に失敗した場合に、前記失敗の要因を、前記基地局を介して前記中継ノードから受信する、
ことをさらに含む方法。
【請求項３６】
請求項２８〜３５のいずれか一項において、
前記サーバから、前記中継ノードがアクセスすることを許可された１以上の基地局のリストを検索し、
前記リストを、前記基地局を介して前記中継ノードへ送信する、
ことをさらに含む方法。
【請求項３７】
ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）と基地局との間でトラヒックを無線中継する中継ノードへバインドすることが可能なＩＣＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）の制御方法であって、
前記中継ノードから、暗号化された前記中継ノードの識別子及び平文の識別子を受信し、
少なくとも前記ＩＣＣに関する情報を用いて、第１のセッションキーを導出し、
前記暗号化された識別子を、前記第１のセッションキーで復号化し、
前記復号化した識別子と前記平文の識別子とを比較して、前記中継ノードを認証する、
ことを含む方法。
【請求項３８】
請求項３７において、
前記情報として、前記ＩＣＣに付与された識別子、及び前記ＩＣＣで生成可能なパラメータの少なくとも一方を用いる、
ことを特徴とした方法。
【請求項３９】
請求項３７又は３８において、
前記情報に加え、前記ＩＣＣがバインドすることを許可された中継ノードの識別子を用いて、前記第１のセッションキーを導出する、
ことを特徴とした方法。
【請求項４０】
請求項３７〜３９のいずれか一項において、
前記中継ノードと前記ＩＣＣとの間でセキュアに通信を行うための第２のセッションキーを導出し、
前記第２のセッションキーを、前記第１のセッションキーで暗号化し、
前記暗号化した第２のセッションキーを、前記中継ノードへ送信する、
ことをさらに含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
中継ノード(ＲＮ：Ｒｅｌａｙ Ｎｏｄｅ)装置とネットワークの間における相互認証、中継ＵＩＣＣ(ｒｅｌａｙ−Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ)と中継装置の間における相互認証及びセキュアチャネルの確立のためのメカニズムを提案する。アタック(非特許文献２)を防止するため、非特許文献３におけるＡＫＡ(Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ)手順及び初期ＮＡＳ(Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒｕｍ)手順を再利用したソリューションを提供する。このソリューションは、中継ＵＩＣＣ、中継装置設定の不当な改変又は悪用、これらの間のメッセージの傍受及び改変を防止する。
【背景技術】
【０００２】
３ＧＰＰ(Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)のＬＴＥ(Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ)−Ａｄｖａｎｃｅｄでは、費用効率の高いスループット向上及びカバレッジ拡大のための中継が検討されている(非特許文献１参照)。その中継アーキテクチャにおいては、中継ＵＩＣＣ(以降、本発明ではＵＩＣＣを中継ＵＩＣＣのために用いるであろう)とネットワークの間、及び／又はＲＮとネットワークの間の通信がセキュアで無ければ、ＭｉｔＭ(ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ)アタック、通信ハイジャック及び幾つかの他のアタックが可能である。さらに、ＵＩＣＣ認証の間、認証パラメータが、ＲＮ並びにＵＩＣＣとＲＮプラットフォームの間のコネクションを介して転送される。侵入者が、メッセージ及び認証データをキャプチャ、改変又は注入し得る。
【０００３】
ＲＮ装置は、着脱可能なＵＩＣＣを有している(非特許文献２参照)。このため、ＵＩＣＣは、オペレータにより認証されていない他のＲＮへ挿入され得る。さらに、ＵＩＣＣとＲＮの間の通信は、セキュアに認証され且つ機密性が保護されるべきである。しかしながら、非特許文献３に開示されるＳＡＥ(Ｓｙｓｔｅｍ Ａｒｃｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ)／ＬＴＥのＡＫＡ手順は、プラットフォーム認証のためのソリューションを提供していないため、中継ノードのケースには適していない。
【０００４】
このため、相互認証が、ＵＩＣＣ及びネットワークのためだけで無く、ＲＮ及びネットワーク、並びにＵＩＣＣ及びＲＮプラットフォームのためにも提供されれば足りる。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】ＴＲ ３６．８０６、"Ｒｅｌａｙ ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｅ−ＵＴＲＡ (ＬＴＥ−Ａｄｖａｎｃｅｄ) (Ｒｅｌｅａｓｅ ９)"、Ｖ９．０．０、２０１０年３月
【非特許文献２】Ｓ３−１００８９６、"Ｌｉｖｉｎｇ Ｄｏｃｕｍｅｎｔ ｏｎ "Ｋｅｙ Ｓｅｃｕｒｉｔｙ Ｉｓｓｕｅｓ ｏｆ Ｒｅｌａｙ Ｎｏｄｅ Ａｒｃｈｉｔｅｃｔｕｒｅ""
【非特許文献３】ＴＳ ３３．４０１、"３ＧＰＰ Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ (ＳＡＥ)； Ｓｅｃｕｒｉｔｙ ａｒｃｈｉｔｅｃｔｕｒｅ (Ｒｅｌｅａｓｅ ９)"、Ｖ９．４．０、２０１０年６月
【発明の概要】
【０００６】
本明細書では、(１)ＵＩＣＣ及びネットワーク内の中継ノード装置の両者のための相互認証、(２)ＵＩＣＣ及び中継ノード装置のセキュアなバインディング、及び(３)ＵＩＣＣと中継ノード装置の間におけるセキュアチャネルの作成を提供する、中継ノード認証のためのソリューションを提案する。提案するソリューションは、非特許文献２で言及される脅威１〜５を緩和する。このソリューションは、ＡＫＡ手順の再利用、ＤｅＮＢ(Ｄｏｎｅｒ ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ)のみへ接続する中継ノード、及び中継ノードによるマルチホップ作成の防止といった中継ノードの他の要件も満たす。また、このソリューションは、モビリティに対する改修を施すこと無く使用可能であるため、陳腐化されない(目下、中継ノードの仕様は、その焦点がカバレッジ拡大のための固定配置に向けられている)。
【０００７】
認証
ＵＩＣＣにネットワーク相互認証を要求し、中継装置にネットワーク相互認証を要求し、且つＵＩＣＣと中継装置の間のバインディングを要求する。その全てが、以下の通りに達成される。
１．ＵＩＣＣ及びネットワークの相互認証は、ＥＰＳ(Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ) ＡＫＡにより達成される。
２．中継装置は、ネットワークにより、中継装置が秘密キーを用いて暗号化したメッセージに基づいて認証される。
３．提案するソリューションにおいては、キーＫｒｉ及びＫｒｃが、ＵＩＣＣと中継装置の間のセキュア通信のために生成される。Ｋｒｉ及びＫｒｃは、ネットワーク及びＵＳＩＭ(Ｕｎｉｖｅｒｓａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ)のみによって作成可能である。Ｋｒｉ及びＫｒｃは、自身の公開キーを使用する中継装置に対し、暗号化して送信される。これにより、中継装置のみが、メッセージを復号化し、ＭＡＣ(Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ)をＵＳＩＭからのＫｒｉを用いて検証することが可能である。よって、ネットワークがＵＳＩＭと同一のルートキーを保持するのであるから、中継装置がネットワークを認証する。
４．中継装置は、Ｋｒｃで暗号化された値(例えば、ＩＭＳＩ(Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ))を、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅに含めてネットワークへ送信し、以てＲＮキーと共に送信されたメッセージの秘密キーを保持していること、及びＵＳＩＭからのＲＥＳ(ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｓｐｏｎｓｅ)を有しているのであるから、ＵＩＣＣと一体化されていることを証明する。よって、ＵＩＣＣとＲＮの間のバインディングが立証される。
【０００８】
脅威の緩和
脅威１：中継装置、ＵＩＣＣの認証、及びこれらの間のバインディングによって緩和される。
脅威２：ＭＡＣが、認証の間にこの脅威を緩和する。認証後、ＭｉｔＭには、中継装置とネットワークの間のトラヒックの完全性及び機密性を保護するために用いるキーが必要となるであろう。
脅威３：ＵＰ(Ｕｓｅｒ Ｐｌａｎｅ)の機密性を利用したＥＰＳセキュリティ手順によって緩和され、完全性について、提案するソリューションは、ＩＰｓｅｃ(ｓｅｃｕｒｉｔｙ ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ)に依存するか、或いはＵＰの完全性保護のために新たなキーを作成する。
脅威４：上述した認証により対処される。
脅威５：ＵＳＩＭでのキーＫｒｉ及びＫｒｃの作成、及び中継装置での同一キーの使用は、そもそも最初からＵＳＩＭと中継装置の間のセキュア通信をもたらす、すなわち、ＣＫ(Ｃｉｐｈｅｒ Ｋｅｙ)前であっても、ＩＫ(Ｉｎｔｅｇｒｉｔｙ Ｋｅｙ)が転送される。
【０００９】
他の要件
ＡＫＡ手順は、維持される。
【００１０】
ＭｉｔＭ並びにマルチホップは、例えそのようなアクションが起こされても不可能であり、このことは、中継ノードからの通信に対するアタック無しでトラヒックを"中継"することのみをもたらすであろう。
【００１１】
ＮＡＳ ＳＭＣ(Ｓｅｃｕｒｉｔｙ Ｍｏｄｅ Ｃｏｍｍａｎｄ)の間に選択される、ＭＭＥ(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ)からのＡｔｔａｃｈ Ａｃｃｅｐｔは、中継ノードが通信を許可されたＤｅＮＢのリストを含み、以て中継が正しいＤｅＮＢへ接続されることをもたらす。
【発明の効果】
【００１２】
中継ノードプラットフォーム及びネットワークは、相互認証を得ることが可能である。また、中継ノードプラットフォーム及びＵＩＣＣが、相互認証を得ることも可能である。相互認証は、ＵＥ(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ)−ＵＩＣＣ又は他の不正なＵＩＣＣがＲＮに悪用されないことを保証し、オペレータに属さない中継装置を悪用することも防止する。
【００１３】
非特許文献３に開示されるＵＥ及びＭＭＥのためのＡＫＡ手順が再利用され、以てシグナリングが増大せず、キー階層も同様に維持される。
【００１４】
セキュアチャネルが、ＵＩＣＣとＲＮプラットフォームの間で確立され、以てＣＫ、ＩＫが暗号化されて送信される。
【図面の簡単な説明】
【００１５】
【図１】提案するソリューションの例を示したシーケンス図である。
【図２】本発明の実施の形態に係るネットワークシステムの構成例を示したブロック図である。
【図３】本発明の実施の形態に係る中継ノードの構成例を示したブロック図である。
【図４】本発明の実施の形態に係るネットワークノードの構成例を示したブロック図である。
【図５】本発明の実施の形態に係るＩＣＣの構成例を示したブロック図である。
【発明を実施するための形態】
【００１６】
以下、本発明に係る中継ノード、ネットワークノード及びＩＣＣ、並びにこれらを適用するネットワークシステムの実施の形態を、図１〜図５を参照して説明する。なお、各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
【００１７】
図２に示すように、本実施の形態に係るネットワークシステムは、ＵＩＣＣ １０と、ＲＮ ２０と、ＤｅＮＢ ３０と、ＭＭＥ ４０と、ＨＳＳ ５０とを含む。ＵＩＣＣ １０は、ＲＮ ２０へバインドされる。ＲＮ ２０は、ＵＥ(図示せず)とＤｅＮＢ ３０との間でトラヒックを無線中継する。ＭＭＥ ４０は、必要に応じてＨＳＳ ５０と通信することによって、ＤｅＮＢ ３０に対するアクセス制御を行う。なお、ＵＩＣＣ １０、ＲＮ ２０及びＭＭＥ ４０の構成例は、図３〜図５を参照して後述する。
【００１８】
本実施の形態においては、(１)ＵＩＣＣ及びネットワーク内の中継ノード装置の両者のための相互認証、(２)ＵＩＣＣ及び中継ノード装置のセキュアなバインディング、及び(３)ＵＩＣＣと中継ノード装置の間におけるセキュアチャネルの作成を提供する、中継ノード認証のためのソリューションを提案する。提案するソリューションは、非特許文献２で言及される脅威１〜５を緩和する。このソリューションは、ＡＫＡ手順の再利用、ＤｅＮＢのみへ接続する中継ノード、及び中継ノードによるマルチホップ作成の防止といった中継ノードの他の要件も満たす。また、このソリューションは、移動中継ノード(目下、標準化されている中継ノードは、固定化されたカバレッジ拡大のためのものである)に対する改修を施すこと無く使用可能であるため、陳腐化されない。
【００１９】
非特許文献３のＡＫＡ手順が、ＲＮ認証に対する改修を伴うこと無く再利用される。ソリューションは、下記１〜３を仮定している。
１．ＵＩＣＣは着脱可能である。
２．ＤｅＮＢとネットワークの間の通信はセキュアである。
３．ＲＮはディジタル証明書を有している。
【００２０】
以降の議論のため、Ｋｐｕｂは、ＲＮの公開キーであり、ＩＭＥＩ(Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙ)と仮定されるＲＮの識別子にマッピングされている。Ｋｐｒは、ＲＮの秘密キーである。
【００２１】
中継装置とＵＩＣＣの間のセキュア通信のために生成されるキーは、完全性保護のためのＫｒｉと、機密性保護のためのＫｒｃである。このキーペアをＲＮキーと名付ける。ＲＮキーは、Ｋａｓｍｅ(Ｋｅｙ Ａｃｃｅｓｓ Ｓｅｃｕｒｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ)、ＩＭＥＩ、及びＵＩＣＣへ付与されたＩＭＳＩを用いて生成される。なお、Ｋａｓｍｅは、ＵＩＣＣ及びネットワーク(本実施の形態ではＭＭＥ)のみが生成可能なパラメータである。Ｋａｓｍｅの使用は、ＵＩＣＣが、ＭＭＥを認証すること、及びＵＩＣＣとＲＮの間のセキュア通信を保証することを可能にするであろう。また、ＩＭＥＩの使用は、ＲＮが自身の不当な改修を発見することを可能にするであろう。これは、ＩＭＥＩが不当に変更された場合、後述するＣＫ及びＩＫがＲＮによって適切に復号化されず、以て不一致が発見され得るためである。
【００２２】
ＩＭＥＩは、認証目的で、ＵＩＣＣ及びネットワークの両者へ送信される。
【００２３】
ＲＮがアクセス可能なＤｅＮＢの許可リストは、アタッチ成功に際してＲＮへ送信される。
【００２４】
提案するソリューションのオプション的な特徴は、下記１及び２である。
１．このソリューションにおいて、ＵＩＣＣ及びＲＮが互いにロックされることはオプションである。このことは、ソリューションの必須部分では無いが、オペレータがそのようにすることがオプションであることを留意しておく。
２．ＨＳＳ(Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ)がＲＮ ＩＤ(本実施の形態ではＩＭＥＩ)及びこれに対応付けられたＵＳＩＭのリストを有することもオプションである。ソリューションは、このような事前の設定無しでも機能する。
【００２５】
中継認証手順
提案する認証手順を図１に示す。点線で示す部分は、オプションであるか又は特定の場所でオプションであり、その説明を以下の通りに与える。
【００２６】
初期設定
ソリューションのための初期設定として、ＨＳＳ ５０は、必要な時にＲＮ ２０の公開キーを検索し得るよう、中継ノードの特定のＩＭＥＩ(又は特定の識別子)を知っているべきである。
【００２７】
オプションとして、ＵＩＣＣ １０に実装されるＵＳＩＭ及びＲＮ ２０が互いにロックされ得る。すなわち、ＵＳＩＭは、特定のＲＮのみと共に動作するよう事前設定され、ＲＮ ２０は、特定のＵＳＩＭのみと共に動作するよう事前設定される。これにより、ＵＳＩＭがＲＮ ２０に設置されると、ＵＳＩＭ及びＲＮ ２０の両者が正しい場所に在るか否かをチェックするであろう。ソリューションは、このオプション的な特徴無しでも機能する。
【００２８】
メッセージシーケンス
図１に示すソリューションのメッセージシーケンスを、以下に説明する。
【００２９】
１．ＲＮ ２０は、Ｋｐｒで暗号化されたＩＭＥＩ(又は、ＲＮに用いられる任意の他の識別子)と平文のＩＭＥＩとを含むＡｔｔａｃｈ Ｒｅｑｕｅｓｔメッセージを送出する。
【００３０】
オプションとして、Ｋｐｒで暗号化されたＩＭＳＩも送出される。これにより、ＨＳＳ ５０が、ＲＮ ２０へのＵＩＣＣ １０のバインディングに関する初期チェックを行うことが可能であろう。
【００３１】
２．ＤｅＮＢ ３０(ｅＮＢでもあり得る)は、Ａｔｔａｃｈ ＲｅｑｕｅｓｔメッセージをＲＮ ２０からＭＭＥ−ＲＮ ４０へ転送し、オプションとして、自身の識別子(ＤｅＮＢ＿ＩＤ)をメッセージへ付加する。ｅＮＢ／ＤｅＮＢ識別子の送信は、ネットワークが、ＲＮが特定のＤｅＮＢへのアタッチを許可されているか否かを検証する手助けとなるであろう。これにより、ネットワークは、特定のＲＮが認証されなかった後にも関わらずアタッチ完了の後にｅＮＢ／ＤｅＮＢへアタッチしたままである場合に、アクションを起こすことが可能である。
【００３２】
３．ＭＭＥ−ＲＮ ４０は、ＩＭＳＩ及びＩＭＥＩを、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄａｔａ Ｒｅｑｕｅｓｔメッセージに含めてＨＳＳ ５０へ送信する。
【００３３】
４．ＨＳＳ ５０は、受信したＩＭＥＩ(又は、ＲＮに用いられる任意の他の識別子)に基づきＫｐｕｂを検索すると共に、ＲＮ ２０用の許可ＤｅＮＢリストを検索する。
【００３４】
ここで、オプションとして、ＨＳＳ ５０は、受信したＩＭＳＩに基づいて、ＵＩＣＣ １０が中継型又は特定のＲＮへバインドされるものであるか判定することができる。
【００３５】
５．ＨＳＳ ５０は、ステップ４で検索したデータを、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄａｔａ Ｒｅｓｐｏｎｓｅメッセージに含めてＭＭＥ−ＲＮ ４０へ送信する。
【００３６】
６．ＭＭＥ−ＲＮ ４０は、ＩＭＥＩを受信したＫｐｕｂで復号化して、暗号化されていないＩＭＥＩと比較し、以てＲＮ ２０を認証する。ＲＮ ２０のみが、Ｋｐｒと平文のＩＭＥＩと同一である復号化されたＩＭＥＩとを有しており、これは、メッセージが何ら改変されていないことを意味する。ＭＭＥ−ＲＮ ４０は、受信したＲＮリストに基づき、ＤｅＮＢ ３０に対するＲＮ ２０のアクセス制御を行うと共に、ＩＭＳＩ、ＩＭＥＩ及びＫａｓｍｅを用いて、一対のＲＮキー(Ｋｒｉ、Ｋｒｃ)を導出する。
【００３７】
７．ＭＭＥ−ＲＮ ４０は、Ｋｐｕｂで暗号化したＲＮキーを含む、オプションとしてＫｒｃで暗号化したＩＭＥＩを含むＡｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送出する。オプションとして、Ｋｐｕｂで暗号化したＲＡＮＤも送出可能である。メッセージは、Ｋｒｉによって完全性が保護される。
【００３８】
８．ＲＮ ２０は、Ｋｐｒを用いてＲＮキー(オプションとしてＲＡＮＤ(ｒａｎｄｏｍ ｎｕｍｂｅｒ))を復号化し、ＭＡＣを検証する。この検証に際して、ＲＮ ２０は、所定のＭＡＣアルゴリズムに従い、受信したメッセージ及びＫｒｉを用いてＭＡＣを生成する。そして、ＲＮ ２０は、生成したＭＡＣが受信したＭＡＣと一致するか否かをチェックする。
【００３９】
９．ＲＮ ２０は、ＲＡＮＤ及びＩＭＥＩをＵＩＣＣへ送信する。ＩＭＥＩ(オプションとして、全体のメッセージそのもの)は、Ｋｒｃで暗号化されたもの及び平文のものの両者が送信され、両者ともＫｒｉによって完全性が保護される。
【００４０】
１０．ＵＩＣＣ １０は、受信したＲＡＮＤを用いて通常のＡＫＡ手順を実行する(非特許文献３参照)。また、ＵＩＣＣ １０は、ＭＭＥ−ＲＮ ４０と同様にしてＲＮキー(Ｋｒｉ及びＫｒｃ)を導出すると共に、暗号化されたＩＭＥＩをＫｒｃを用いて検証し、Ｋｒｉを用いてメッセージの完全性を検証する。このステップは、ＵＩＣＣに対し、(ｉ) ＲＮがネットワークにより認証されていること、及び(ｉｉ)受信したＩＭＥＩが特定のＲＮに属することを証明する。
【００４１】
１１．ＵＩＣＣ １０は、暗号化され且つ完全性が保護されたＣＫ、ＩＫ及びＲＥＳを、ＲＮ ２０へ送信する。
【００４２】
１２．ＲＮ ２０は、ＵＩＣＣ １０から受信したメッセージのＭＡＣをチェックし、Ｋｒｃを用いてＣＫ、ＩＫ及びＲＥＳを復号化する。このことは、ＵＩＣＣ及びＲＮが同一のキーを有し、以て(ｉ)ＲＮの接続先のネットワークが正当なものであり、且つ(ｉｉ)ＵＩＣＣが正当なものであることを証明する。この結果、セキュアチャネルが、ＲＮとＵＩＣＣの間に作成される。
【００４３】
１３．ＲＮ ２０は、ＭＭＥ−ＲＮ ４０に対して、Ｋｒｃで暗号化したＲＥＳ及びＩＭＳＩを含むＡｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージを送信する。ＲＥＳの暗号化はオプションである。メッセージは、Ｋｒｉによって完全性が保護される。
【００４４】
１３'．オプションとして、ＲＮキーがＵＩＣＣ １０とＲＮ ２０の間で一致しない場合には、新たな要因を含むＡｕｔｈｅｎｔｉｃａｔｉｏｎ ＲｅｊｅｃｔメッセージがＭＭＥ−ＲＮ ４０へ送信され得る。
【００４５】
１４．ＭＭＥ−ＲＮ ４０は、ＲＥＳを、標準化されたＡＫＡ手順(非特許文献３参照)のように検証する。また、ＭＭＥ−ＲＮ ４０は、ＩＭＳＩを復号化する。このステップは、(ｉ)(再び)ＲＮを認証する、すなわち、通信中のＲＮがステップ８のＫｐｕｂで暗号化されたメッセージの秘密キーを有するものであること、(ｉｉ)ＲＥＳの検証により正当なＵＩＣＣがＲＮと一体化されているのが判明したこと、及び(ｉｉｉ)特定のＲＮ及びＵＩＣＣが組み合されていることを証明する。
【００４６】
１５．非特許文献３に示されるようなＳＭＣ手順が行われる。
【００４７】
１６．Ａｔｔａｃｈ Ａｃｃｅｐｔメッセージにおいて、許可ＤｅＮＢリストがＲＮ ２０へ送信される。例えば、許可ＤｅＮＢリストは、１以上のＩＭＥＩを、１以上のｅＮＢのＩＤと対応付けて記憶している。この場合、ＲＮ ２０は、自身のＩＭＥＩに対応付けられたＩＤを有するｅＮＢへアタッチできる。
【００４８】
次に、ＵＩＣＣ １０、ＲＮ ２０及びＭＭＥ ４０の構成例を、図３〜図５を参照して説明する。
【００４９】
図３に示すように、ＲＮ ２０は、暗号化部２１と、送信部２２と、受信部２３と、復号化部２４とを含む。
【００５０】
暗号化部２１は、ＩＭＥＩ及びＩＭＳＩの各々を、Ｋｐｒを用いて暗号化する。また、暗号化部２１は、ＩＭＥＩを、Ｋｒｃを用いて暗号化する。さらに、暗号化部２１は、ＩＭＳＩを、Ｋｒｃを用いて暗号化する。
【００５１】
送信部２２は、ＤｅＮＢ ３０を介してＭＭＥ ４０へ、暗号化したＩＭＥＩ及びＩＭＳＩの各々を、平文のＩＭＥＩ及びＩＭＳＩの各々と共に送信する。また、送信部２２は、ＵＩＣＣ １０へ、暗号化したＩＭＥＩを平文のＩＭＥＩと共に送信する。さらに、送信部２２は、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｊｅｃｔメッセージを、ＤｅＮＢ ３０を介してＭＭＥ ４０へ送信する。
【００５２】
受信部２３は、ＤｅＮＢ ３０を介してＭＭＥ ４０から、暗号化されたＫｒｃ及びＫｒｉを受信する。また、受信部２３は、ＵＩＣＣ １０から、暗号化されたＣＫ及びＩＫを受信する。
【００５３】
復号化部２４は、暗号化されたＫｒｃ及びＫｒｉを、Ｋｐｒを用いて復号化する。また、復号化部２４は、暗号化されたＣＫ及びＩＫを、復号化したＫｒｃを用いて復号化する。
【００５４】
これらのユニット２１〜２４は、例えば、ＵＥとＤｅＮＢ ３０の間でトラヒックを無線中継する中継器と、ＵＩＣＣ １０と通信するインタフェースと、これらの中継器及びインタフェースを制御すると共に、暗号化及び復号化を行って、図１に示した処理或いはこれに相当する処理を実行するコントローラとで構成できる。
【００５５】
図４に示すように、ＭＭＥ ４０は、受信部４１と、検索部４２と、復号化部４３と、認証部４４と、導出部４５と、暗号化部４６と、送信部４７と、判定部４８とを含む。
【００５６】
受信部４１は、ＤｅＮＢ ３０を介してＲＮ ２０から、暗号化されたＩＭＥＩ及びＩＭＳＩの各々を、平文のＩＭＥＩ及びＩＭＳＩの各々と共に受信する。また、受信部４１は、ＤｅＮＢ ３０を介してＲＮ ２０から、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｊｅｃｔメッセージを受信する。
【００５７】
検索部４２は、ＨＳＳ ５０からＫｐｕｂを検索する。また、検索部４２は、ＨＳＳ ５０から許可ＤｅＮＢリストを検索する。
【００５８】
復号化部４３は、暗号化されたＩＭＥＩを、Ｋｐｕｂを用いて復号化する。また、復号化部４３は、暗号化されたＩＭＳＩを、Ｋｐｕｂ又はＫｒｃを用いて復号化する。
【００５９】
認証部４４は、復号化したＩＭＥＩを平文のＩＭＥＩと比較することによって、ＲＮ ２０を認証する。また、認証部４４は、復号化したＩＭＳＩをＨＳＳ ６０へ通知してＵＩＣＣ １０がＲＮ ２０へのバインドを許可されているか否かをチェックさせることによって、ＵＩＣＣ １０を認証する。
【００６０】
導出部４５は、ＩＭＳＩ、ＩＭＥＩ及びＫａｓｍｅを用いて、Ｋｒｃ及びＫｒｉを導出する。
【００６１】
暗号化部４６は、Ｋｒｃ及びＫｒｉを、Ｋｐｕｂを用いて暗号化する。
【００６２】
送信部４７は、ＤｅＮＢ ３０を介してＲＮ ２０へ、暗号化したＫｒｃ及びＫｒｉを送信する。また、送信部４７は、ＤｅＮＢ ３０を介してＲＮ ２０へ、許可ＤｅＮＢリストを送信する。
【００６３】
判定部４８は、ＲＮ ２０がＤｅＮＢ ３０へのアクセスを許可されているか否かを判定する。例えば、ＲＮ ２０のＩＭＥＩがＤｅＮＢ ３０のＩＤと対応付けて許可ＤｅＮＢリストに記憶されている場合に、判定部４８は、ＲＮ ２０がＤｅＮＢ ３０へアクセスすることを許可する。
【００６４】
これらのユニット４１〜４８は、例えば、ＤｅＮＢ ３０及びＨＳＳ ５０とそれぞれ通信する送受信器と、これらの送受信器を制御すると共に、復号化、認証、導出、暗号化及び判定を行って、図１に示した処理或いはこれに相当する処理を実行するコントローラとで構成できる。
【００６５】
図５に示すように、ＵＩＣＣ １０は、受信部１１と、導出部１２と、復号化部１３と、認証部１４と、暗号化部１５と、送信部１６とを含む。受信部１１は、ＲＮ ２０から、暗号化されたＩＭＥＩと平文のＩＭＥＩとを受信する。導出部１２は、ＩＭＳＩ、ＩＭＥＩ及びＫａｓｍｅを用いて、Ｋｒｃ及びＫｒｉを導出する。また、導出部１２は、ＣＫ及びＩＫを導出する。復号化部１３は、暗号化されたＩＭＥＩを、Ｋｒｃを用いて復号化する。認証部１４は、復号化したＩＭＥＩを平文のＩＭＥＩと比較することによって、ＲＮ ２０を認証する。暗号化部１５は、ＣＫ及びＩＫを、Ｋｒｃを用いて暗号化する。送信部１６は、暗号化したＣＫ及びＩＫを、ＲＮ ２０へ送信する。
【００６６】
これらのユニット１１〜１６は、例えば、ＵＳＩＭと、ＲＮ ２０と通信するインタフェースと、これらのＵＳＩＭ及びインタフェースを制御すると共に、導出、復号化、認証及び暗号化を行って、図１に示した処理或いはこれに相当する処理を実行するコントローラとで構成できる。
【００６７】
なお、本発明は、上記の実施の形態によって限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。
【００６８】
この出願は、２０１０年９月１３日に出願された日本出願特願２０１０−２０４８６３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【００６９】
上記の実施の形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
【００７０】
(付記１)
ＵＩＣＣ及びＲＮは、(オプションとして)ネットワークとの通信前に事前チェックを行う。オペレータは、ＵＩＣＣ及びＲＮに関する事前設定を有しており、これらを互いに設定することが可能である。情報は、一意な識別子の一種である。ＵＩＣＣがＲＮへ挿入された場合、これらのＵＩＣＣ及びＲＮは、情報を使用して、例えばオペレータの設定に従ってバインドされているか、信頼できるものであるか等を検証することが可能である。
【００７１】
(付記２)
ＩＭＥＩが、ＲＮ装置認証に使用される。
ＩＭＥＩは、初期ＮＡＳメッセージにてネットワークへ送信される。これにより、ＨＳＳはＲＮの公開キーを検索可能であり、ＵＩＣＣはＩＭＥＩに基づき検証を行うことが可能であり、以てＲＮをネットワークによって認証することが可能である。
【００７２】
(付記３)
ＩＭＥＩが、キー生成に使用される。
ＵＩＣＣ及びＭＭＥ−ＲＮは、ＩＭＥＩを用いて、セッションキーＫｒを生成する。
ＩＭＥＩが不当に改変された場合、ＣＫ、ＩＫはＲＮによって適切には復号化されず、不一致が発見されるであろう。
【００７３】
(付記４)
ＭＭＥ−ＲＮは、ＤｅＮＢへアクセスするＲＮに対するアクセス制御を行う。
中継は、ＤｅＮＢを介してネットワークと通信する。ＭＭＥ−ＲＮは、ＲＮがＤｅＮＢへアクセスするのを認可するか否かを判定可能である。ＭＭＥ−ＲＮは、初期ＮＡＳメッセージにてＤｅＮＢから受信したＤｅＮＢ識別子に応じたＲＮリストを受信するであろう。
【００７４】
(付記５)
公開キー及びセッションキーのメカニズムが使用される。
中継公開キーを用いて、ネットワークによりＲＮを認証する。ネットワーク及びＵＩＣＣは、独立した機密性キー及び完全性キーを含む一対のセッションキーを生成する。セッションキーを用いて、ＩＭＥＩを暗号化し、ＭＡＣを生成し、ＣＫ、ＩＫを暗号化し、以てこれらが傍受され得ないようにする。
【００７５】
(付記６)
ＵＩＣＣとＲＮの間におけるセキュアチャネルの確立。
ＣＫ、ＩＫは、暗号化されてメッセージにて送信され、以て認証されたＲＮによってのみ得ることが可能である。
【００７６】
(付記７)
ＲＮは、暗号化したＲＡＮＤを、ネットワークへ送信する。
ＲＮからネットワークへのＡｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ中のＲＡＮＤは、ＲＮによりＫｒを用いて暗号化される。暗号化されたＲＡＮＤは、ＵＩＣＣが他では無くＲＮにあることを保証する。
【００７７】
(付記８)
Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｊｅｃｔ用の新たな要因。
ＲＮは、ＵＩＣＣから受信したＭＡＣを検証する。ＲＮは、検証に失敗した場合、新たな適切な要因を伴うＡｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｊｅｃｔを送信すべきである。
【００７８】
(付記９)
ＭＭＥ−ＲＮは、ＨＳＳから許可ＤｅＮＢリストを受信すると共に、許可ＤｅＮＢリストを、ＵＩＣＣ及びネットワークの両者によって認証されているＲＮへ送信し、以てＲＮが、アクセスを許可されたＤｅＮＢを認識し得るようにする。
【符号の説明】
【００７９】
１０  ＵＩＣＣ
１１, ２３, ４１  受信部
１２, ４５  導出部
１３, ２４, ４３  復号化部
１４, ４４  認証部
１５, ２１, ４６  暗号化部
１６, ２２, ４７  送信部
２０  ＲＮ
３０  ＤｅＮＢ
４０  ＭＭＥ
４２  検索部
４８  判定部
５０  ＨＳＳ
【図１】
2013537374.tif 000003
【図２】
2013537374.tif 000004
【図３】
2013537374.tif 000005
【図４】
2013537374.tif 000006
【図５】
2013537374.tif 000007
【国際調査報告】
2013537374.tif 000008
2013537374.tif 000009
2013537374.tif 000010