(57)【特許請求の範囲】
【請求項１】
モバイル通信システムであって、
ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）と、
ＳＣＳ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ  Ｓｅｒｖｅｒ）と、
ＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）と、
ＭＴＣ−ＩＷＦ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ−Ｉｎｔｅｒｗｏｒｋｉｎｇ  Ｆｕｎｃｔｉｏｎ）と、
を備え、
前記ＳＣＳは、トリガすべき前記ＵＥの識別子を含むデバイストリガを前記ＭＴＣ−ＩＷＦに送信し、
前記ＭＴＣ−ＩＷＦは、前記識別子を含む要求メッセージを前記ＨＳＳに送信し、
前記ＨＳＳは、セキュリティキーに関するパラメータ情報を含む応答メッセージを前記ＭＴＣ−ＩＷＦに送信し、
前記ＭＴＣ−ＩＷＦは、前記応答メッセージに基づき前記セキュリティキーを導出する、モバイル通信システム。
【請求項２】
ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）と、
ＳＣＳ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ  Ｓｅｒｖｅｒ）と、
ＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）と、
ＭＴＣ−ＩＷＦ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ−Ｉｎｔｅｒｗｏｒｋｉｎｇ  Ｆｕｎｃｔｉｏｎ）と、
を含む、モバイル通信システムの方法であって、
前記ＭＴＣ−ＩＷＦがトリガすべき前記ＵＥの識別子を含むデバイストリガを受信し、
前記識別子を含む要求メッセージを受信した前記ＨＳＳより、セキュリティキーに関するパラメータ情報を含む応答メッセージを受信し、
前記ＭＴＣ−ＩＷＦが前記応答メッセージに基づき前記セキュリティキーを導出する、モバイル通信システムの方法。
【請求項３】
ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）と、
ＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）と、
ＳＣＳ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ  Ｓｅｒｖｅｒ）と、
を含む、モバイル通信システムのＭＴＣ−ＩＷＦ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ−Ｉｎｔｅｒｗｏｒｋｉｎｇ  Ｆｕｎｃｔｉｏｎ）であって、
前記ＳＣＳより、トリガすべき前記ＵＥの識別子を含むデバイストリガを受信する受信部と、
前記ＨＳＳに、前記識別子を含む要求メッセージを送信する送信部と、
前記ＨＳＳよりセキュリティキーに関するパラメータ情報を含む応答メッセージを受信することにより、前記セキュリティキーを導出する制御部と、
を具備する、ＭＴＣ−ＩＷＦ。
【請求項４】
ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）と、
ＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）と、
ＳＣＳ（Ｓｅｒｖｉｃｅ  Ｃａｐａｂｉｌｉｔｙ  Ｓｅｒｖｅｒ）と、
を含む、モバイル通信システムのＭＴＣ−ＩＷＦ（Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ−Ｉｎｔｅｒｗｏｒｋｉｎｇ  Ｆｕｎｃｔｉｏｎ）の方法であって、
前記ＳＣＳより、トリガすべき前記ＵＥの識別子を含むデバイストリガを受信し、
前記ＨＳＳに、前記識別子を含む要求メッセージを送信し、
前記ＨＳＳよりセキュリティキーに関するパラメータ情報を含む応答メッセージを受信することにより、前記セキュリティキーを導出する、ＭＴＣ−ＩＷＦの方法。
【請求項５】
前記セキュリティキーは、前記ＳＣＳと前記ＵＥ間の通信を保護する、請求項１記載のモバイル通信システム。
【請求項６】
前記セキュリティキーは、前記ＳＣＳと前記ＵＥ間の通信を保護する、請求項２記載のモバイル通信システムの方法。
【請求項７】
前記セキュリティキーは、前記ＳＣＳと前記ＵＥ間の通信を保護する、請求項３記載のＭＴＣ−ＩＷＦ。
【請求項８】
前記セキュリティキーは、前記ＳＣＳと前記ＵＥ間の通信を保護する、請求項４記載のＭＴＣ−ＩＷＦの方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＭＴＣ(Ｍａｃｈｉｎｅ−Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ)システムにおけるキー管理に関し、特にＭＴＣ−ＩＷＦ(ＭＴＣ Ｉｎｔｅｒ−Ｗｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ)とＭＴＣ ＵＥ(Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ)との間の通信を保護するために、キーをネットワークからＭＴＣ ＵＥへ送信する技術に関する。
【背景技術】
【０００２】
非特許文献１に記載されるように、ＭＴＣデバイスとＭＴＣ−ＩＷＦとの間のインタフェース上のセキュリティが検討されるべきである。なお、ＭＴＣデバイスは、ＭＴＣに対する機能を備えたＵＥであり、以降の説明において“ＭＴＣ ＵＥ”又は“ＵＥ”と呼称することがある。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】３ＧＰＰ ＴＲ ３３．８６８、“Ｓｅｃｕｒｉｔｙ ａｓｐｅｃｔｓ ｏｆ Ｍａｃｈｉｎｅ−Ｔｙｐｅ ａｎｄ ｏｔｈｅｒ Ｍｏｂｉｌｅ Ｄａｔａ Ａｐｐｌｉｃａｔｉｏｎｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｅｎｈａｎｃｅｍｅｎｔｓ； (Ｒｅｌｅａｓｅ １２)”、Ｖ０．１０．０、２０１２年９月
【非特許文献２】３ＧＰＰ ＴＲ ２３．８８７、“Ｍａｃｈｉｎｅ−Ｔｙｐｅ ａｎｄ ｏｔｈｅｒ Ｍｏｂｉｌｅ Ｄａｔａ Ａｐｐｌｉｃａｔｉｏｎｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｅｎｈａｎｃｅｍｅｎｔｓ (Ｒｅｌｅａｓｅ １２)”、Ｖ０．３．０、２０１２年１０月
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、３ＧＰＰ(３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ)において、検討は遂行されていない。このため、ＭＴＣデバイスとＭＴＣ−ＩＷＦとの間に、セキュアな通信ソリューションが必要である。
【０００５】
従って、本発明の目的は、ＭＴＣデバイスとＭＴＣ−ＩＷＦとの間にセキュア通信を保証することにある。
【課題を解決するための手段】
【０００６】
上記の目的を達成するため、本発明は、如何にしてルートキーＫ＿ｉｗｆを、ネットワークで導出しＵＥへ送信するかといった事項を扱う。
【０００７】
本発明は、ＵＥとＭＴＣ−ＩＷＦとの間のセキュア通信を目的として、ルートキーＫ＿ｉｗｆを導出し、Ｋ＿ｉｗｆをＵＥへ送信するネットワークのソリューションを提供する。なお、ここで、ネットワークとは、キーＫ＿ｉｗｆを導出するネットワークノードを意味する。どのネットワークがキーＫ＿ｉｗｆを導出するかについては、複数のオプションがある。このことは、本発明を通じた説明に適用される。
【発明の効果】
【０００８】
本発明によれば、上述した課題を解決し、以てＭＴＣデバイスとＭＴＣ−ＩＷＦとの間にセキュア通信を保証することが可能である。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施の形態に係る通信システムの構成例を示したブロック図である。
【図２】実施の形態に係る通信システムにおいて、通信がＵＥにより開始される場合のＵＥへのキー送信の動作例を示したシーケンス図である。
【図３】実施の形態に係る通信システムにおいて、通信がトリガにより開始される場合のＵＥへのキー送信の動作例を示したシーケンス図である。
【図４】実施の形態に係る第１のネットワークノードの構成例を示したブロック図である。
【図５】実施の形態に係る第２のネットワークノードの構成例を示したブロック図である。
【図６】実施の形態に係る第３のネットワークノードの構成例を示したブロック図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施の形態を、図面を参照して説明する。
【００１１】
図１に示すように、本実施の形態に係る通信システムは、コアネットワーク(３ＧＰＰネットワーク)と、ＭＴＣに対する機能を備えたＵＥであり、ＲＡＮ(Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ)を介してコアネットワークへ接続する１以上のＭＴＣ ＵＥ １０と、を含む。図示を省略するが、ＲＡＮは、複数の基地局(すなわち、ｅＮＢ(ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂｓ))によって形成される。
【００１２】
ＭＴＣ ＵＥ １０は、コアネットワークへアタッチする。ＭＴＣ ＵＥ １０は、１又は複数のＭＴＣアプリケーションをホスト(ｈｏｓｔ)することが可能である。外部ネットワークにおける対応ＭＴＣアプリケーションは、ＳＣＳ(Ｓｅｒｖｉｃｅ Ｃａｐａｂｉｌｉｔｙ Ｓｅｒｖｅｒ) ５０上でホストされる。ＳＣＳ ５０は、コアネットワークへ接続して、ＭＴＣ ＵＥ １０と通信する。
【００１３】
また、コアネットワークは、ネットワークノードの一つとして、ＭＴＣ−ＩＷＦ ２０を含む。ＭＴＣ−ＩＷＦ ２０は、ＳＣＳ ５０に対するコアネットワークへのゲートウェイとして機能する。ＭＴＣ−ＩＷＦ ２０は、ＭＴＣ ＵＥ １０とＳＣＳ ５０との間でメッセージを中継する。コアネットワークは、他のネットワークノードとして、ＨＳＳ(Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ) ３０、ＭＭＥ(Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ)、ＳＧＳＮ(Ｓｅｒｖｉｎｇ ＧＰＲＳ(Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ) Ｓｕｐｐｏｒｔ Ｎｏｄｅ)、ＭＳＣ(Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｒｅ)等を含む。以降の説明において、ＭＭＥ、ＳＧＳＮ及びＭＳＣを、“ＭＭＥ／ＳＧＳＮ／ＭＳＣ”と呼称し、符号４０で総称又は単称することがある。ＭＴＣ ＵＥ １０とＭＴＣ−ＩＷＦ ２０との間の通信は、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０を介して行われる。
【００１４】
次に、本実施の形態の動作例を、図２及び図３を参照して詳細に説明する。
【００１５】
１．初期化(キー提供)
どのネットワーク、すなわちＨＳＳ ３０、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０又はＭＴＣ−ＩＷＦ ２０のいずれがルートキーＫ＿ｉｗｆを導出するかについて、３つのオプションがある。
【００１６】
従って、ＭＴＣ−ＩＷＦ ２０に対するキーＫ＿ｉｗｆの提供方法にも３つの方法がある。
【００１７】
１）ＨＳＳ ３０が、ルートキーＫ＿ｉｗｆを導出し、例えばＳｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅ(非特許文献２に記載)、又はＵｐｄａｔｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎと呼称する新たなメッセージにおいてＭＴＣ−ＩＷＦ ２０へ送信する。Ｋ＿ｉｗｆの送信は、ＵＥ １０とのＡＫＡ(Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｍａｎａｇｅｍｅｎｔ)手順が成功裏に完了した後である。また、Ｋ＿ｉｗｆを、例えばＡｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄａｔａ ＲｅｓｐｏｎｓｅにおいてＭＭＥ ４０へ送信し、以てＭＭＥ ４０が後にＫ＿ｉｗｆをＵＥ １０へ送信できるようにする。なお、以降の説明において、ＭＭＥについての記載は、ＳＧＳＮ及びＭＳＣに対しても同様に適用される。
【００１８】
２）ＭＭＥ ４０が、ルートキーＫ＿ｉｗｆを導出し、ＨＳＳ ３０を介して、又は新たなメッセージ(例えば、ｒｅｐｏｒｔ.ｔｙｐｅ＝“ＵＥ ｉｓ ａｕｔｈｅｎｔｉｃａｔｅｄ”、ＵＥ ＩＤ、Ｋ＿ｉｗｆを含むＲｅｐｏｒｔメッセージ)を用いてダイレクトにＭＴＣ−ＩＷＦ ２０へ送信する。
【００１９】
３）ＭＴＣ−ＩＷＦ ２０が、自身でルートキーＫ＿ｉｗｆを導出する。ＭＴＣ−ＩＷＦ ２０は、Ｋ＿ｉｗｆを、図１に示したインタフェースＴ５上でＭＭＥ ４０へ送信し、以てＭＭＥ ４０が後にＫ＿ｉｗｆをＵＥ １０へ送信できるようにする。
【００２０】
ＵＥ １０及び(例えばＳＣＳ ５０によりトリガされた)ネットワークの両者が、互いの相手側への通信を開始できる。このため、ＵＥ １０へのルートキーＫ＿ｉｗｆの送信は、各ケースにおいて異なる。以下、キー送信について説明する。
【００２１】
２．ルートキーＫ＿ｉｗｆ送信手順についての詳細な説明
＜ケース１：ＵＥが通信を開始＞
ルートキーＫ＿ｉｗｆは、ＨＳＳ ３０が、ＵＥ １０がＭＴＣタイプの通信を持つことを許可され且つネットワークに対し認証されたことを検証した後に、導出されるべきである。Ｋ＿ｉｗｆを、最初のＡｔｔａｃｈ手順の間、又は最初のＡｔｔａｃｈ手順が完了した時点で、ＵＥ １０へ送信することができる。
【００２２】
ＮＡＳ(Ｎｏｎ Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ)セキュリティ・コンフィデンシャリティ(ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ：機密性)が開始された場合、ルートキーＫ＿ｉｗｆを、ＮＡＳ ＳＭＣ(Ｓｅｃｕｒｉｔｙ Ｍｏｄｅ Ｃｏｍｍａｎｄ)又はＡｔｔａｃｈ ＡｃｃｅｐｔメッセージにおいてＭＭＥ ４０からＵＥ １０へ送信することができる。Ｋ＿ｉｗｆをＮＡＳ ＳＭＣメッセージにおいて送信する場合、Ｋ＿ｉｗｆを、ＮＡＳコンフィデンシャリティ・キーにより保護すべきである。Ｋ＿ｉｗｆをＡｔｔａｃｈ Ａｃｃｅｐｔメッセージにおいて送信する場合には、Ａｔｔａｃｈ ＡｃｃｅｐｔメッセージがＮＡＳセキュリティコンテキストで秘密裏に保護されているので、キー自体は保護不要である。上述した通り、ＭＭＥ ４０は、Ｋ＿ｉｗｆを、自身で導出するか、或いはＨＳＳ ３０又はＭＴＣ−ＩＷＦ ２０から受信し得る。
【００２３】
詳細を、図２に示す。
【００２４】
ステップＳ１：セキュア通信が、ネットワークノード、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０、ＨＳＳ ３０及びＭＴＣ−ＩＷＦ ２０の間に確立される。
【００２５】
ステップＳ２：ＵＥ １０は、自身がＭＴＣタイプのＵＥであることを示すＵＥケイパビリティ(ｃａｐａｂｉｌｉｔｙ)を含むＡｔｔａｃｈ Ｒｅｑｕｅｓｔを、ＭＭＥ ４０へ送信する。
【００２６】
ステップＳ３：ＡＫＡ手順が開始され得る。
【００２７】
ステップＳ４：ＵＥケイパビリティに応じて、ＨＳＳ ３０は、ＵＥ １０がＭＴＣデバイスであるか否か及びＭＴＣ−ＩＷＦ ２０との通信を許可されているか否かを検証する。検証が成功裏に完了した場合、キーの導出及び送信が実行される。
【００２８】
ステップＳ５〜Ｓ７：ＨＳＳ ３０がルートキーＫ＿ｉｗｆを導出する場合、ＨＳＳ ３０は、キーを、“Ｕｐｄａｔｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ”と呼称され得る、ＵＥケイパビリティを含む新たなメッセージにおいてＭＴＣ−ＩＷＦ ２０へ送信する。一方、ＨＳＳ ３０は、Ｋ＿ｉｗｆを、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄａｔａ ＲｅｓｐｏｎｓｅメッセージにおいてＭＭＥ ４０へ送信する。
【００２９】
ステップＳ８〜Ｓ１１：ＭＭＥ ４０がルートキーＫ＿ｉｗｆを導出する場合、ＨＳＳ ３０は、(必要に応じて)パラメータを、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄａｔａ ＲｅｓｐｏｎｓｅメッセージにおいてＭＭＥ ４０へ送信する。ＭＭＥ ４０は、Ｋ＿ｉｗｆを導出した後、２つの方法でＫ＿ｉｗｆをＭＴＣ−ＩＷＦ ２０へ送信することが可能である。
【００３０】
一の方法(ステップＳ１０ａ及びＳ１０ｂ)は、ＭＭＥ ４０が、Ｋ＿ｉｗｆを新たなメッセージにおいてＨＳＳ ３０へ送信し、そしてＨＳＳ ３０が、Ｋ＿ｉｗｆを、Ｕｐｄａｔｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎと呼称される新たなメッセージにおいてＭＴＣ−ＩＷＦ ２０へ送信するものである。
【００３１】
他の方法(ステップＳ１１)は、ＭＭＥ ４０が、Ｋ＿ｉｗｆを、インタフェースＴ５上で、新たなメッセージ又はＲｅｐｏｒｔメッセージにおいてＭＴＣ−ＩＷＦ ２０へダイレクトに送信するものである。
【００３２】
ステップＳ１２〜Ｓ１４：ＭＴＣ−ＩＷＦ ２０がルートキーＫ＿ｉｗｆを導出する場合、ＨＳＳ ３０は、必要に応じて、キー導出パラメータを、Ｕｐｄａｔｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎと呼称される新たなメッセージにおいて送信する。ＭＴＣ−ＩＷＦ ２０は、Ｋ＿ｉｗｆを導出した後、Ｋ＿ｉｗｆを、インタフェースＴ５上で、新たなメッセージにおいてＭＭＥ ４０へ送信する。
【００３３】
ステップＳ１５：ＭＭＥ ４０は、ルートキーＫ＿ｉｗｆを、Ｋ＿ｉｗｆがＮＡＳセキュリティコンテキストにより暗号化されるＮＡＳ ＳＭＣメッセージ、或いはコンフィデンシャリティ・セキュリティを有するＡｔｔａｃｈ Ａｃｃｅｐｔメッセージにおいて送信する。
【００３４】
＜ケース２：トリガにより開始される通信＞
同様に、キーＫ＿ｉｗｆが、ネットワークで導出され、ＵＥ １０へ送信される。キー自体、或いは必要なキー導出パラメータが、ＭＴＣ−ＩＷＦ ２０へ送信される。
【００３５】
詳細を、図３に示す。
【００３６】
ステップＳ２１：セキュア通信が、ＨＳＳ ３０とＭＴＣ−ＩＷＦ ２０との間に確立される。
【００３７】
ステップＳ２２：ＳＣＳ ５０は、トリガすべきＵＥ ＩＤを含むＭＴＣデバイストリガを、ＭＴＣ−ＩＷＦ ２０へ送信する。
【００３８】
ステップＳ２３：ＭＴＣ−ＩＷＦ ２０は、トリガとしてのメッセージタイプ及びＵＥ ＩＤを含むＳｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを、ＨＳＳ ３０へ送信する。
【００３９】
ステップＳ２４：ＵＥ １０が未だ認証されていない場合、ＵＥ １０との認証が実行される。
【００４０】
ステップＳ２５〜Ｓ２７：ＨＳＳ ３０は、ルートキーＫ＿ｉｗｆを導出すると、キーをＳｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ ＲｅｓｐｏｎｓｅメッセージにおいてＭＴＣ−ＩＷＦ ２０へ送信する。一方、ＨＳＳ ３０は、Ｋ＿ｉｗｆを、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄａｔａ ＲｅｓｐｏｎｓｅメッセージにおいてＭＭＥ ４０へ送信する。
【００４１】
ステップＳ８〜Ｓ１１：この手順は、ケース１と同様である。
【００４２】
ステップＳ３１：ＭＴＣ−ＩＷＦ ２０がルートキーＫ＿ｉｗｆを導出する場合、ＨＳＳ ３０は、必要に応じてキー導出パラメータを、Ｓｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージにおいて送信する。ＭＴＣ−ＩＷＦ ２０は、Ｋ＿ｉｗｆを導出した後、Ｋ＿ｉｗｆを、インタフェースＴ５上で新たなメッセージにおいてＭＭＥ ４０へ送信する。
【００４３】
ステップＳ１３〜Ｓ１５：この手順は、ケース１と同様である。
【００４４】
なお、ケース１のステップＳ６、Ｓ１０及びＳ１２において、Ｕｐｄａｔｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎは、新たなメッセージの一例として用いられている。ＨＳＳ ３０は、次回のＳｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ ＲｅｑｕｅｓｔがＭＴＣ−ＩＷＦ ２０から受信されるのを待機し、そして、Ｋ＿ｉｗｆをＳｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージにおいて送信することもできる。
【００４５】
ＨＳＳ ３０は、キー導出パラメータを、インストールしておくか、又はＭＴＣ−ＩＷＦ ２０から受信することができる。また、ＭＭＥ ４０が、キー導出パラメータを、ＨＳＳ ３０の代わりにＭＴＣ−ＩＷＦ ２０から受信することもできる。
【００４６】
或いは、ＭＴＣ−ＩＷＦ ２０は、Ｋ＿ｉｗｆをＵＥ １０へダイレクトに送信することができる。この場合、Ｋ＿ｉｗｆをＭＭＥ ４０へ送信する必要は無く、以てステップＳ７、Ｓ１５及びＳ２７は不要である。
【００４７】
或いは、ＭＴＣ−ＩＷＦ ２０は、ＡＫＡ手順が開始される前であっても、Ｋ＿ｉｗｆを導出してＨＳＳ ３０へ送信することができ、ＨＳＳ ３０は、ＵＥ １０が一旦認証されると、Ｋ＿ｉｗｆをＵＥ １０へ送信することができる。
【００４８】
或いは、ネットワークは、ルートキーを送信する代わりに、サブキーをＵＥ １０へ送信することができる。この場合、ＵＥ １０は、後述する如く自身でサブキーを導出する必要が無い。このことは、ＵＥへのインパクトを低減する一方で、ネットワークでのシグナリングを増大させる。
【００４９】
(ＭＴＣデバイスでは無い)ＵＥは、ＭＴＣ−ＩＷＦと通信することを許可されないか、或いはＭＴＣ−ＩＷＦとの通信を要求しないであろうから、このような場合には、新たなキー階層を確立すべきで無い。
【００５０】
３．サブキー及びメッセージ保護
ＵＥ １０及びＭＴＣ−ＩＷＦ ２０は、ルートキーＫ＿ｉｗｆを有する場合、サブキーＫ＿ｄｉ＿ｃｏｎｆ及びＫ＿ｄｉ＿ｉｎｔを導出することが可能である。サブキーＫ＿ｄｉ＿ｃｏｎｆは、ＭＴＣ ＵＥ １０とＭＴＣ−ＩＷＦ ２０との間で転送されるメッセージを暗号化及び復号化するためのコンフィデンシャリティ・キーである。サブキーＫ＿ｄｉ＿ｉｎｔは、ＭＴＣ ＵＥ １０とＭＴＣ−ＩＷＦ ２０との間で転送されるメッセージのインテグリティ(ｉｎｔｅｇｒｉｔｙ：完全性)をチェックするためのインテグリティ・キーである。ＵＥ １０とＭＴＣ−ＩＷＦ ２０との間の通信は、サブキーによりコンフィデンシャリティ及びインテグリティの両者が保護されるべきである。
【００５１】
ＭＴＣ−ＩＷＦ ２０は、自身が保持するものとは異なるキーにより保護されたメッセージをＵＥ １０から受信した場合、当該メッセージを廃棄すべきである。オプションとして、このことをＨＳＳ ３０へ知らせ、以てＨＳＳ ３０が、例えばキー更新手順、ＵＥ再認証又はデタッチといった適切なアクションを引き受けるようにすることもできる。
【００５２】
ＵＥ １０は、自身が保持するものとは異なるキーにより保護されたメッセージをＭＴＣ−ＩＷＦ ２０から受信した場合、新たなキーを要求できる。
【００５３】
本実施の形態に係るＭＴＣ−ＩＷＦ ２０、ＨＳＳ ３０及びＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０の構成例を、図４〜図６を参照して説明する。なお、以降の説明においては、本実施の形態に特有の構成要素のみを記載する。但し、当然のことながら、ＭＴＣ−ＩＷＦ ２０、ＨＳＳ ３０及びＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０は、それぞれ、一般的なＭＴＣ−ＩＷＦ、ＨＳＳ及びＭＭＥ／ＳＧＳＮ／ＭＳＣとして機能するための構成要素も含む。
【００５４】
図４に示すように、ＭＴＣ−ＩＷＦ ２０は、受信部２１及び送信部２２の少なくとも一方を含む。ＨＳＳ ３０又はＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０がルートキーＫ＿ｉｗｆを導出する場合、受信部２１は、図２のステップＳ６、Ｓ１０及びＳ１１並びに図３のステップＳ２６に示したように、ルートキーＫ＿ｉｗｆを、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０からダイレクトに又はＨＳＳ ３０を介して受信する。送信部２２は、キー導出パラメータを、ＨＳＳ ３０又はＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０へ送信できる。また、送信部２２は、ルートキーＫ＿ｉｗｆを、ＭＥＣ ＵＥ １０へダイレクトに送信できる。なお、これらのユニット２１及び２２は、バス等を介して相互接続される。これらのユニット２１及び２２は、例えば、ＨＳＳ ３０及びＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０とそれぞれ通信するトランシーバと、これらのトランシーバを制御するＣＰＵ(Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ)等のコントローラと、で構成できる。
【００５５】
図５に示すように、ＨＳＳ ３０は、判定部３１及び送信部３２の少なくとも一方を含む。判定部３１は、図２のステップＳ４に示した検証を行う。ＨＳＳ ３０がルートキーＫ＿ｉｗｆを導出する場合、送信部３２は、図２のステップＳ６及びＳ７並びに図３のステップＳ２６及びＳ２７に示したように、ルートキーＫ＿ｉｗｆをＭＴＣ−ＩＷＦ ２０及びＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０へ送信する。一方、ＭＴＣ−ＩＷＦ ２０又はＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０がルートキーＫ＿ｉｗｆを導出する場合、送信部３２は、図２のステップＳ８及びＳ１２並びに図３のステップＳ３１に示したように、キー導出パラメータをＭＴＣ−ＩＷＦ ２０又はＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０へ送信する。なお、これらのユニット３１及び３２は、バス等を介して相互接続される。これらのユニット３１及び３２は、例えば、ＭＴＣ−ＩＷＦ ２０及びＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０とそれぞれ通信するトランシーバと、これらのトランシーバを制御するＣＰＵ等のコントローラと、で構成できる。
【００５６】
図６に示すように、ＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０は、送信部４１を含む。送信部３１は、図２及び図４各々のステップＳ１５に示したように、ルートキーＫ＿ｉｗｆをＭＴＣ ＵＥ １０へ送信する。ＭＭＥ／ＳＧＳＮ／ＭＳＣ ４０がルートキーＫ＿ｉｗｆを導出する場合、送信部３１は、図２及び図３各々のステップＳ１０及びＳ１１に示したように、ルートキーＫ＿ｉｗｆを、ＭＴＣ−ＩＷＦ ２０へダイレクトに又はＨＳＳ ３０を介して送信する。この送信部３１は、例えば、ＭＴＣ ＵＥ １０、ＭＴＣ−ＩＷＦ ２０及びＨＳＳ ３０とそれぞれ通信するトランシーバと、これらのトランシーバを制御するＣＰＵ等のコントローラと、で構成できる。
【００５７】
なお、本発明は、上記の実施の形態によって限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。
【００５８】
上記の実施の形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
【００５９】
(付記１)
ネットワークは、ＵＥがＭＴＣ通信を有するか否か、及びＫ＿ｉｗｆをＭＴＣタイプのＵＥのみへ送信可能であるか否かを判定する。
【００６０】
(付記２)
ＭＭＥは、Ｋ＿ｉｗｆをＮＡＳ ＳＭＣ又はＡｔｔａｃｈ ＡｃｃｅｐｔメッセージにおいてＵＥへ送信し、キーを、Ｔ５インタフェース上でＭＴＣ−ＩＷＦへ、例えばＲｅｐｏｒｔメッセージにおいて送信するか、或いはＨＳＳを介しＳｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ又は新たなメッセージ“Ｕｐｄａｔｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ”において送信する。
【００６１】
(付記３)
ＨＳＳは、キーＫ＿ｉｗｆ導出し、ＭＭＥを介してＵＥへ送信し、キーを、ＳｕｂｓｃｒｉｂｅｒＲｅｓｐｏｎｓｅメッセージ又は新たなメッセージ“Ｕｐｄａｔｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ”においてＭＴＣ−ＩＷＦへ送信する。
【００６２】
(付記４)
ＭＴＣ−ＩＷＦは、キーＫ＿ｉｗｆを導出する。導出、又はＨＨＳ若しくはＭＭＥからの受信の後、ＭＴＣ−ＩＷＦは、Ｋ＿ｉｗｆを、ＭＭＥを介して又はダイレクトメッセージにおいてＵＥへ送信する。
【００６３】
(付記５)
ＨＳＳは、キー導出パラメータをＡｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄａｔａ ＲｅｓｐｏｎｓｅにおいてＭＭＥへ送信し、或いはＭＴＣ−ＩＷＦが、キー導出パラメータをＭＭＥへ提供する。
【００６４】
(付記６)
ＨＳＳは、キー導出パラメータをＳｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ又は新たなメッセージ“Ｕｐｄａｔｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｎｆｏｒｍａｔｉｏｎ”においてＭＴＣ−ＩＷＦへ送信し、或いはＭＴＣ−ＩＷＦが、キー導出パラメータをＨＳＳへ提供する。
【００６５】
この出願は、２０１２年１２月６日に出願された日本出願特願２０１２−２６７２５６を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【００６６】
１０  ＭＴＣ ＵＥ
２０  ＭＴＣ−ＩＷＦ
２１  受信部
２２, ３２, ４１  送信部
３０  ＨＳＳ
３１  判定部
４０  ＭＭＥ／ＳＧＳＮ／ＭＳＣ
５０  ＳＣＳ
【図１】
0006418230.tif 000002
【図２】
0006418230.tif 000003
【図３】
0006418230.tif 000004
【図４】
0006418230.tif 000005
【図５】
0006418230.tif 000006
【図６】
0006418230.tif 000007