UEUserEquipmentと基地局との間でトラヒックを無線中継することが可能な中継ノードであって、自中継ノードの識別子を、自中継ノード用の秘密キーで暗号化する第1の手段と、前記暗号化した識別子及び平文の識別子を、前記基地局を介して、自中継ノード用の公開キーを有するネットワークへ送信する第2の手段と、を備えた中継ノード。請求項1において、前記基地局を介して前記ネットワークから、前記公開キーで暗号化され、且つ少なくとも自中継ノードへのバインドを許可されたICCIntegratedCircuitCardに関する情報を用いて導出された第1のセッションキーを受信する第3の手段と、前記第1のセッションキーを、前記秘密キーで復号化する第4の手段と、をさらに備え、前記第1の手段は、前記識別子を、前記復号化された第1のセッションキーで暗号化し、前記第2の手段は、自中継ノードへバインドされたICCに対し、前記復号化した第1のセッションキーで暗号化された識別子と前記平文の識別子とを送信して、前記バインドされたICCに自中継ノードを認証させる、ことを特徴とした中継ノード。請求項2において、前記情報は、前記許可されたICCに付与される識別子、及び前記許可されたICCによって生成され得るパラメータの少なくとも一方である、ことを特徴とした中継ノード。請求項2又は3において、前記第1のセッションキーは、前記情報に加え、自中継ノードの前記識別子を用いて導出される、ことを特徴とした中継ノード。請求項2~4のいずれか一項において、前記第3の手段は、前記バインドされたICCから、自中継ノードと前記バインドされたICCの間でセキュアに通信を行うための暗号化された第2のセッションキーを受信し、前記第4の手段は、前記第2のセッションキーを、前記復号化した第1のセッションキーで復号化する、ことを特徴とした中継ノード。請求項2~5のいずれか一項において、前記第1の手段は、前記バインドされたICCが自中継ノードの認証に成功した場合に、前記バインドされたICCの識別子を、前記復号化した第1のセッションキーで暗号化し、前記第2の手段は、前記暗号化した前記バインドされたICCの識別子を、前記基地局を介して前記ネットワークへ送信する、ことを特徴とした中継ノード。請求項2~6のいずれか一項において、前記第2の手段は、前記バインドされたICCが自中継ノードの認証に失敗した場合に、前記失敗の要因を、前記基地局を介して前記ネットワークへ送信する、ことを特徴とした中継ノード。請求項1~7のいずれか一項において、前記第1の手段は、自中継ノードにバインドされたICCの識別子を、前記秘密キーで暗号化し、前記第2の手段は、前記暗号化したICCの識別子を、前記基地局を介して前記ネットワークへ送信して、前記ネットワークに、前記バインドされたICCが自中継ノードへのバインドを許可されたICCであるか否かをチェックさせる、ことを特徴とした中継ノード。基地局に対するアクセス制御を行うネットワークノードであって、前記基地局を介して、UEUserEquipmentと前記基地局との間でトラヒックを無線中継することが可能な中継ノードから、前記中継ノード用の秘密キーで暗号化された前記中継ノードの識別子と、平文の識別子とを受信する第1の手段と、サーバから、前記中継ノード用の公開キーを検索する第2の手段と、前記暗号化された識別子を、前記公開キーで復号化する第3の手段と、前記復号化した識別子と前記平文の識別子とを比較して、前記中継ノードを認証する第4の手段と、を備えたネットワークノード。請求項9において、少なくとも前記中継ノードへのバインドを許可されたICCIntegratedCircuitCardに関する情報を用いて、第1のセッションキーを導出する第5の手段と、前記第1のセッションキーを、前記公開キーで暗号化する第6の手段と、前記暗号化した第1のセッションキーを、前記基地局を介して前記中継ノードへ送信する第7の手段と、をさらに備えたネットワークノード。請求項10において、前記第5の手段は、前記情報として、前記許可されたICCに付与される識別子、及び前記許可されたICCによって生成され得るパラメータの少なくとも一方を用いる、ことを特徴としたネットワークノード。請求項10又は11において、前記第5の手段は、前記情報に加え、前記中継ノードの識別子を用いて前記第1のセッションキーを導出する、ことを特徴としたネットワークノード。請求項9~12のいずれか一項において、前記第1の手段は、前記基地局を介して前記中継ノードから、前記中継ノードにバインドされたICCの識別子であって、前記秘密キーで暗号化された識別子を受信し、前記第3の手段は、前記バインドされたICCの識別子を、前記公開キーで復号化し、前記第4の手段は、前記復号化したICCの識別子に基づき、前記バインドされたICCを認証する、ことを特徴としたネットワークノード。請求項13において、前記第4の手段は、前記サーバへ前記復号化したICCの識別子を通知して、前記バインドされたICCが前記中継ノードへのバインドを許可されているか否かをチェックすることによって、前記バインドされたICCを認証する、ことを特徴としたネットワークノード。請求項9~14のいずれか一項において、前記中継ノードの識別子に基づき、前記中継ノードが前記基地局へのアクセスを許可されているか否かを判定する手段、をさらに備えたネットワークノード。請求項9~15のいずれか一項において、前記第1の手段は、前記中継ノードにバインドされたICCが前記中継ノードの認証に失敗した場合に、前記失敗の要因を、前記基地局を介して前記中継ノードから受信する、ことを特徴としたネットワークノード。請求項10~16のいずれか一項において、前記第2の手段は、前記サーバから、前記中継ノードがアクセスすることを許可された1以上の基地局のリストを検索し、前記第7の手段は、前記リストを、前記基地局を介して前記中継ノードへ送信する、ことを特徴としたネットワークノード。UEUserEquipmentと基地局との間でトラヒックを無線中継する中継ノードへバインドすることが可能なICCIntegratedCircuitCardであって、前記中継ノードから、暗号化された前記中継ノードの識別子及び平文の識別子を受信する第1の手段と、少なくとも自ICCに関する情報を用いて、第1のセッションキーを導出する第2の手段と、前記暗号化された識別子を、前記第1のセッションキーで復号化する第3の手段と、前記復号化した識別子と前記平文の識別子とを比較して、前記中継ノードを認証する第4の手段と、を備えたICC。請求項18において、前記第2の手段は、前記情報として、自ICCに付与された識別子、及び自ICCで生成可能なパラメータの少なくとも一方を用いる、ことを特徴としたICC。請求項18又は19において、前記第2の手段は、前記情報に加え、自ICCがバインドすることを許可された中継ノードの識別子を用いて、前記第1のセッションキーを導出する、ことを特徴としたICC。請求項18~20のいずれか一項において、前記中継ノードと自ICCとの間でセキュアに通信を行うための第2のセッションキーを導出する手段と、前記第2のセッションキーを、前記第1のセッションキーで暗号化する手段と、前記暗号化した第2のセッションキーを、前記中継ノードへ送信する手段と、をさらに備えたICC。UEUserEquipmentと基地局との間でトラヒックを無線中継することが可能な中継ノードの制御方法であって、前記中継ノードの識別子を、前記中継ノード用の秘密キーで暗号化し、前記暗号化した識別子及び平文の識別子を、前記基地局を介して、前記中継ノード用の公開キーを有するネットワークへ送信する、ことを含む方法。請求項22において、前記基地局を介して前記ネットワークから、前記公開キーで暗号化され、且つ少なくとも前記中継ノードへのバインドを許可されたICCIntegratedCircuitCardに関する情報を用いて導出された第1のセッションキーを受信し、前記第1のセッションキーを、前記秘密キーで復号化し、前記識別子を、前記復号化された第1のセッションキーで暗号化し、前記中継ノードへバインドされたICCに対し、前記復号化した第1のセッションキーで暗号化された識別子と前記平文の識別子とを送信して、前記バインドされたICCに前記中継ノードを認証させる、ことをさらに含む方法。請求項23において、前記バインドされたICCから、前記中継ノードと前記バインドされたICCの間でセキュアに通信を行うための暗号化された第2のセッションキーを受信し、前記第2のセッションキーを、前記復号化した第1のセッションキーで復号化する、ことをさらに含む方法。請求項23又は24において、前記バインドされたICCが前記中継ノードの認証に成功した場合に、前記バインドされたICCの識別子を、前記復号化した第1のセッションキーで暗号化し、前記暗号化した前記バインドされたICCの識別子を、前記基地局を介して前記ネットワークへ送信する、ことをさらに含む方法。請求項23~25のいずれか一項において、前記バインドされたICCが前記中継ノードの認証に失敗した場合に、前記失敗の要因を、前記基地局を介して前記ネットワークへ送信する、ことをさらに含む方法。請求項22~26のいずれか一項において、前記中継ノードにバインドされたICCの識別子を、前記秘密キーで暗号化し、前記暗号化したICCの識別子を、前記基地局を介して前記ネットワークへ送信して、前記ネットワークに、前記バインドされたICCが前記中継ノードへのバインドを許可されたICCであるか否かをチェックさせる、ことをさらに含む方法。基地局に対するアクセス制御を行うネットワークノードの制御方法であって、前記基地局を介して、UEUserEquipmentと前記基地局との間でトラヒックを無線中継することが可能な中継ノードから、前記中継ノード用の秘密キーで暗号化された前記中継ノードの識別子と、平文の識別子とを受信し、サーバから、前記中継ノード用の公開キーを検索し、前記暗号化された識別子を、前記公開キーで復号化し、前記復号化した識別子と前記平文の識別子とを比較して、前記中継ノードを認証する、ことを含む方法。請求項28において、少なくとも前記中継ノードへのバインドを許可されたICCIntegratedCircuitCardに関する情報を用いて、第1のセッションキーを導出し、前記第1のセッションキーを、前記公開キーで暗号化し、前記暗号化した第1のセッションキーを、前記基地局を介して前記中継ノードへ送信する、ことをさらに含む方法。請求項29において、前記情報として、前記許可されたICCに付与される識別子、及び前記許可されたICCによって生成され得るパラメータの少なくとも一方を用いる、ことを特徴とした方法。請求項29又は30において、前記情報に加え、前記中継ノードの識別子を用いて前記第1のセッションキーを導出する、ことを特徴とした方法。請求項28~31のいずれか一項において、前記基地局を介して前記中継ノードから、前記中継ノードにバインドされたICCの識別子であって、前記秘密キーで暗号化された識別子を受信し、前記バインドされたICCの識別子を、前記公開キーで復号化し、前記復号化したICCの識別子に基づき、前記バインドされたICCを認証する、ことをさらに含む方法。請求項32において、前記サーバへ前記復号化したICCの識別子を通知して、前記バインドされたICCが前記中継ノードへのバインドを許可されているか否かをチェックすることによって、前記バインドされたICCを認証する、ことを特徴とした方法。請求項28~33のいずれか一項において、前記中継ノードの識別子に基づき、前記中継ノードが前記基地局へのアクセスを許可されているか否かを判定する、ことをさらに含む方法。請求項28~34のいずれか一項において、前記中継ノードにバインドされたICCが前記中継ノードの認証に失敗した場合に、前記失敗の要因を、前記基地局を介して前記中継ノードから受信する、ことをさらに含む方法。請求項28~35のいずれか一項において、前記サーバから、前記中継ノードがアクセスすることを許可された1以上の基地局のリストを検索し、前記リストを、前記基地局を介して前記中継ノードへ送信する、ことをさらに含む方法。UEUserEquipmentと基地局との間でトラヒックを無線中継する中継ノードへバインドすることが可能なICCIntegratedCircuitCardの制御方法であって、前記中継ノードから、暗号化された前記中継ノードの識別子及び平文の識別子を受信し、少なくとも前記ICCに関する情報を用いて、第1のセッションキーを導出し、前記暗号化された識別子を、前記第1のセッションキーで復号化し、前記復号化した識別子と前記平文の識別子とを比較して、前記中継ノードを認証する、ことを含む方法。請求項37において、前記情報として、前記ICCに付与された識別子、及び前記ICCで生成可能なパラメータの少なくとも一方を用いる、ことを特徴とした方法。請求項37又は38において、前記情報に加え、前記ICCがバインドすることを許可された中継ノードの識別子を用いて、前記第1のセッションキーを導出する、ことを特徴とした方法。請求項37~39のいずれか一項において、前記中継ノードと前記ICCとの間でセキュアに通信を行うための第2のセッションキーを導出し、前記第2のセッションキーを、前記第1のセッションキーで暗号化し、前記暗号化した第2のセッションキーを、前記中継ノードへ送信する、ことをさらに含む方法。中継ノードプラットフォーム及びネットワークは、相互認証を得ることが可能である。また、中継ノードプラットフォーム及びUICCが、相互認証を得ることも可能である。相互認証は、UE-UICC又は他の不正なUICCがRNに悪用されないことを保証し、オペレータに属さない中継装置を悪用することも防止する。非特許文献3に開示されるUE及びMMEのためのAKA手順が再利用され、以てシグナリングが増大せず、キー階層も同様に維持される。セキュアチャネルが、UICCとRNプラットフォームの間で確立され、以てCK、IKが暗号化されて送信される。以下、本発明に係る中継ノード、ネットワークノード及びICC、並びにこれらを適用するネットワークシステムの実施の形態を、図1~図5を参照して説明する。なお、各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。図2に示すように、本実施の形態に係るネットワークシステムは、UICC10と、RN20と、DeNB30と、MME40と、HSS50とを含む。UICC10は、RN20へバインドされる。RN20は、UEとDeNB30との間でトラヒックを無線中継する。MME40は、必要に応じてHSS50と通信することによって、DeNB30に対するアクセス制御を行う。なお、UICC10、RN20及びMME40の構成例は、図3~図5を参照して後述する。本実施の形態においては、UICC及びネットワーク内の中継ノード装置の両者のための相互認証、UICC及び中継ノード装置のセキュアなバインディング、及びUICCと中継ノード装置の間におけるセキュアチャネルの作成を提供する、中継ノード認証のためのソリューションを提案する。提案するソリューションは、非特許文献2で言及される脅威1~5を緩和する。このソリューションは、AKA手順の再利用、DeNBのみへ接続する中継ノード、及び中継ノードによるマルチホップ作成の防止といった中継ノードの他の要件も満たす。また、このソリューションは、移動中継ノードに対する改修を施すこと無く使用可能であるため、陳腐化されない。非特許文献3のAKA手順が、RN認証に対する改修を伴うこと無く再利用される。ソリューションは、下記1~3を仮定している。1.UICCは着脱可能である。2.DeNBとネットワークの間の通信はセキュアである。3.RNはディジタル証明書を有している。以降の議論のため、Kpubは、RNの公開キーであり、IMEIと仮定されるRNの識別子にマッピングされている。Kprは、RNの秘密キーである。中継装置とUICCの間のセキュア通信のために生成されるキーは、完全性保護のためのKriと、機密性保護のためのKrcである。このキーペアをRNキーと名付ける。RNキーは、Kasme、IMEI、及びUICCへ付与されたIMSIを用いて生成される。なお、Kasmeは、UICC及びネットワークのみが生成可能なパラメータである。Kasmeの使用は、UICCが、MMEを認証すること、及びUICCとRNの間のセキュア通信を保証することを可能にするであろう。また、IMEIの使用は、RNが自身の不当な改修を発見することを可能にするであろう。これは、IMEIが不当に変更された場合、後述するCK及びIKがRNによって適切に復号化されず、以て不一致が発見され得るためである。IMEIは、認証目的で、UICC及びネットワークの両者へ送信される。RNがアクセス可能なDeNBの許可リストは、アタッチ成功に際してRNへ送信される。提案するソリューションのオプション的な特徴は、下記1及び2である。1.このソリューションにおいて、UICC及びRNが互いにロックされることはオプションである。このことは、ソリューションの必須部分では無いが、オペレータがそのようにすることがオプションであることを留意しておく。2.HSSがRNID及びこれに対応付けられたUSIMのリストを有することもオプションである。ソリューションは、このような事前の設定無しでも機能する。中継認証手順提案する認証手順を図1に示す。点線で示す部分は、オプションであるか又は特定の場所でオプションであり、その説明を以下の通りに与える。初期設定ソリューションのための初期設定として、HSS50は、必要な時にRN20の公開キーを検索し得るよう、中継ノードの特定のIMEIを知っているべきである。オプションとして、UICC10に実装されるUSIM及びRN20が互いにロックされ得る。すなわち、USIMは、特定のRNのみと共に動作するよう事前設定され、RN20は、特定のUSIMのみと共に動作するよう事前設定される。これにより、USIMがRN20に設置されると、USIM及びRN20の両者が正しい場所に在るか否かをチェックするであろう。ソリューションは、このオプション的な特徴無しでも機能する。メッセージシーケンス図1に示すソリューションのメッセージシーケンスを、以下に説明する。1.RN20は、Kprで暗号化されたIMEIと平文のIMEIとを含むAttachRequestメッセージを送出する。オプションとして、Kprで暗号化されたIMSIも送出される。これにより、HSS50が、RN20へのUICC10のバインディングに関する初期チェックを行うことが可能であろう。2.DeNB30は、AttachRequestメッセージをRN20からMME-RN40へ転送し、オプションとして、自身の識別子をメッセージへ付加する。eNB/DeNB識別子の送信は、ネットワークが、RNが特定のDeNBへのアタッチを許可されているか否かを検証する手助けとなるであろう。これにより、ネットワークは、特定のRNが認証されなかった後にも関わらずアタッチ完了の後にeNB/DeNBへアタッチしたままである場合に、アクションを起こすことが可能である。3.MME-RN40は、IMSI及びIMEIを、AuthenticationDataRequestメッセージに含めてHSS50へ送信する。4.HSS50は、受信したIMEIに基づきKpubを検索すると共に、RN20用の許可DeNBリストを検索する。ここで、オプションとして、HSS50は、受信したIMSIに基づいて、UICC10が中継型又は特定のRNへバインドされるものであるか判定することができる。5.HSS50は、ステップ4で検索したデータを、AuthenticationDataResponseメッセージに含めてMME-RN40へ送信する。6.MME-RN40は、IMEIを受信したKpubで復号化して、暗号化されていないIMEIと比較し、以てRN20を認証する。RN20のみが、Kprと平文のIMEIと同一である復号化されたIMEIとを有しており、これは、メッセージが何ら改変されていないことを意味する。MME-RN40は、受信したRNリストに基づき、DeNB30に対するRN20のアクセス制御を行うと共に、IMSI、IMEI及びKasmeを用いて、一対のRNキーを導出する。7.MME-RN40は、Kpubで暗号化したRNキーを含む、オプションとしてKrcで暗号化したIMEIを含むAuthenticationRequestメッセージを送出する。オプションとして、Kpubで暗号化したRANDも送出可能である。メッセージは、Kriによって完全性が保護される。8.RN20は、Kprを用いてRNキーを復号化し、MACを検証する。この検証に際して、RN20は、所定のMACアルゴリズムに従い、受信したメッセージ及びKriを用いてMACを生成する。そして、RN20は、生成したMACが受信したMACと一致するか否かをチェックする。9.RN20は、RAND及びIMEIをUICCへ送信する。IMEIは、Krcで暗号化されたもの及び平文のものの両者が送信され、両者ともKriによって完全性が保護される。10.UICC10は、受信したRANDを用いて通常のAKA手順を実行する。また、UICC10は、MME-RN40と同様にしてRNキーを導出すると共に、暗号化されたIMEIをKrcを用いて検証し、Kriを用いてメッセージの完全性を検証する。このステップは、UICCに対し、RNがネットワークにより認証されていること、及び受信したIMEIが特定のRNに属することを証明する。11.UICC10は、暗号化され且つ完全性が保護されたCK、IK及びRESを、RN20へ送信する。12.RN20は、UICC10から受信したメッセージのMACをチェックし、Krcを用いてCK、IK及びRESを復号化する。このことは、UICC及びRNが同一のキーを有し、以てRNの接続先のネットワークが正当なものであり、且つUICCが正当なものであることを証明する。この結果、セキュアチャネルが、RNとUICCの間に作成される。13.RN20は、MME-RN40に対して、Krcで暗号化したRES及びIMSIを含むAuthenticationResponseメッセージを送信する。RESの暗号化はオプションである。メッセージは、Kriによって完全性が保護される。13.オプションとして、RNキーがUICC10とRN20の間で一致しない場合には、新たな要因を含むAuthenticationRejectメッセージがMME-RN40へ送信され得る。14.MME-RN40は、RESを、標準化されたAKA手順のように検証する。また、MME-RN40は、IMSIを復号化する。このステップは、RNを認証する、すなわち、通信中のRNがステップ8のKpubで暗号化されたメッセージの秘密キーを有するものであること、RESの検証により正当なUICCがRNと一体化されているのが判明したこと、及び特定のRN及びUICCが組み合されていることを証明する。15.非特許文献3に示されるようなSMC手順が行われる。16.AttachAcceptメッセージにおいて、許可DeNBリストがRN20へ送信される。例えば、許可DeNBリストは、1以上のIMEIを、1以上のeNBのIDと対応付けて記憶している。この場合、RN20は、自身のIMEIに対応付けられたIDを有するeNBへアタッチできる。次に、UICC10、RN20及びMME40の構成例を、図3~図5を参照して説明する。図3に示すように、RN20は、暗号化部21と、送信部22と、受信部23と、復号化部24とを含む。暗号化部21は、IMEI及びIMSIの各々を、Kprを用いて暗号化する。また、暗号化部21は、IMEIを、Krcを用いて暗号化する。さらに、暗号化部21は、IMSIを、Krcを用いて暗号化する。送信部22は、DeNB30を介してMME40へ、暗号化したIMEI及びIMSIの各々を、平文のIMEI及びIMSIの各々と共に送信する。また、送信部22は、UICC10へ、暗号化したIMEIを平文のIMEIと共に送信する。さらに、送信部22は、AuthenticationRejectメッセージを、DeNB30を介してMME40へ送信する。受信部23は、DeNB30を介してMME40から、暗号化されたKrc及びKriを受信する。また、受信部23は、UICC10から、暗号化されたCK及びIKを受信する。復号化部24は、暗号化されたKrc及びKriを、Kprを用いて復号化する。また、復号化部24は、暗号化されたCK及びIKを、復号化したKrcを用いて復号化する。これらのユニット21~24は、例えば、UEとDeNB30の間でトラヒックを無線中継する中継器と、UICC10と通信するインタフェースと、これらの中継器及びインタフェースを制御すると共に、暗号化及び復号化を行って、図1に示した処理或いはこれに相当する処理を実行するコントローラとで構成できる。図4に示すように、MME40は、受信部41と、検索部42と、復号化部43と、認証部44と、導出部45と、暗号化部46と、送信部47と、判定部48とを含む。受信部41は、DeNB30を介してRN20から、暗号化されたIMEI及びIMSIの各々を、平文のIMEI及びIMSIの各々と共に受信する。また、受信部41は、DeNB30を介してRN20から、AuthenticationRejectメッセージを受信する。検索部42は、HSS50からKpubを検索する。また、検索部42は、HSS50から許可DeNBリストを検索する。復号化部43は、暗号化されたIMEIを、Kpubを用いて復号化する。また、復号化部43は、暗号化されたIMSIを、Kpub又はKrcを用いて復号化する。認証部44は、復号化したIMEIを平文のIMEIと比較することによって、RN20を認証する。また、認証部44は、復号化したIMSIをHSS60へ通知してUICC10がRN20へのバインドを許可されているか否かをチェックさせることによって、UICC10を認証する。導出部45は、IMSI、IMEI及びKasmeを用いて、Krc及びKriを導出する。暗号化部46は、Krc及びKriを、Kpubを用いて暗号化する。送信部47は、DeNB30を介してRN20へ、暗号化したKrc及びKriを送信する。また、送信部47は、DeNB30を介してRN20へ、許可DeNBリストを送信する。判定部48は、RN20がDeNB30へのアクセスを許可されているか否かを判定する。例えば、RN20のIMEIがDeNB30のIDと対応付けて許可DeNBリストに記憶されている場合に、判定部48は、RN20がDeNB30へアクセスすることを許可する。これらのユニット41~48は、例えば、DeNB30及びHSS50とそれぞれ通信する送受信器と、これらの送受信器を制御すると共に、復号化、認証、導出、暗号化及び判定を行って、図1に示した処理或いはこれに相当する処理を実行するコントローラとで構成できる。図5に示すように、UICC10は、受信部11と、導出部12と、復号化部13と、認証部14と、暗号化部15と、送信部16とを含む。受信部11は、RN20から、暗号化されたIMEIと平文のIMEIとを受信する。導出部12は、IMSI、IMEI及びKasmeを用いて、Krc及びKriを導出する。また、導出部12は、CK及びIKを導出する。復号化部13は、暗号化されたIMEIを、Krcを用いて復号化する。認証部14は、復号化したIMEIを平文のIMEIと比較することによって、RN20を認証する。暗号化部15は、CK及びIKを、Krcを用いて暗号化する。送信部16は、暗号化したCK及びIKを、RN20へ送信する。これらのユニット11~16は、例えば、USIMと、RN20と通信するインタフェースと、これらのUSIM及びインタフェースを制御すると共に、導出、復号化、認証及び暗号化を行って、図1に示した処理或いはこれに相当する処理を実行するコントローラとで構成できる。なお、本発明は、上記の実施の形態によって限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。この出願は、2010年9月13日に出願された日本出願特願2010-204863を基礎とする優先権を主張し、その開示の全てをここに取り込む。上記の実施の形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。UICC及びRNは、ネットワークとの通信前に事前チェックを行う。オペレータは、UICC及びRNに関する事前設定を有しており、これらを互いに設定することが可能である。情報は、一意な識別子の一種である。UICCがRNへ挿入された場合、これらのUICC及びRNは、情報を使用して、例えばオペレータの設定に従ってバインドされているか、信頼できるものであるか等を検証することが可能である。IMEIが、RN装置認証に使用される。IMEIは、初期NASメッセージにてネットワークへ送信される。これにより、HSSはRNの公開キーを検索可能であり、UICCはIMEIに基づき検証を行うことが可能であり、以てRNをネットワークによって認証することが可能である。IMEIが、キー生成に使用される。UICC及びMME-RNは、IMEIを用いて、セッションキーKrを生成する。IMEIが不当に改変された場合、CK、IKはRNによって適切には復号化されず、不一致が発見されるであろう。MME-RNは、DeNBへアクセスするRNに対するアクセス制御を行う。中継は、DeNBを介してネットワークと通信する。MME-RNは、RNがDeNBへアクセスするのを認可するか否かを判定可能である。MME-RNは、初期NASメッセージにてDeNBから受信したDeNB識別子に応じたRNリストを受信するであろう。公開キー及びセッションキーのメカニズムが使用される。中継公開キーを用いて、ネットワークによりRNを認証する。ネットワーク及びUICCは、独立した機密性キー及び完全性キーを含む一対のセッションキーを生成する。セッションキーを用いて、IMEIを暗号化し、MACを生成し、CK、IKを暗号化し、以てこれらが傍受され得ないようにする。UICCとRNの間におけるセキュアチャネルの確立。CK、IKは、暗号化されてメッセージにて送信され、以て認証されたRNによってのみ得ることが可能である。RNは、暗号化したRANDを、ネットワークへ送信する。RNからネットワークへのAuthenticationResponseメッセージ中のRANDは、RNによりKrを用いて暗号化される。暗号化されたRANDは、UICCが他では無くRNにあることを保証する。AuthenticationReject用の新たな要因。RNは、UICCから受信したMACを検証する。RNは、検証に失敗した場合、新たな適切な要因を伴うAuthenticationRejectを送信すべきである。MME-RNは、HSSから許可DeNBリストを受信すると共に、許可DeNBリストを、UICC及びネットワークの両者によって認証されているRNへ送信し、以てRNが、アクセスを許可されたDeNBを認識し得るようにする。