JP5058342B2

JP5058342B2 - Ｉｍｓユーザ装置、その制御方法、ホストデバイス、及びその制御方法

Info

Publication number: JP5058342B2
Application number: JP2010542448A
Authority: JP
Inventors: 慎吾村上; ルイスバリガ，; 稔周小田
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2008-05-23
Filing date: 2008-05-23
Publication date: 2012-10-24
Anticipated expiration: 2028-05-23
Also published as: EP2283430A1; WO2009141919A1; US8527759B2; JP2011523105A; EP2283430A4; EP2283430B1; US20110055565A1

Description

本発明は、概して、ＩＰマルチメディア・サブシステム（ＩＭＳ）ユーザ装置（ＵＥ）、ＩＭＳＵＥの制御方法、ホストデバイス、及びホストデバイスの制御方法に関する。本発明は、限定する訳ではないが特に、ホストデバイスのような他のデバイスによって管理されるＩＭＳ加入情報をＩＭＳＵＥが利用できるようにする技術に関する。

「ＩＰマルチメディア・サブシステム」（ＩＭＳ）と呼ばれるネットワークアーキテクチャが、パケットドメインでマルチメディアのサービス及びセッションを扱うためのオープンな標準として、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって開発されてきた。

ユニバーサルＩＣカード（ＵＩＣＣ）に格納されるＩＭＳ加入者ＩＤモジュール（ＩＳＩＭ）アプリケーション、或いはユニバーサル加入者ＩＤモジュール（ＵＳＩＭ）は、加入者情報を含んでいるのでＩＭＳＵＥにとって不可欠である。加入者情報は、ＩＭＳＵＥがＩＭＳネットワークにアクセスして様々なＩＭＳベースのサービスを受けるのに必要である。加入者情報は例えば、ＩＭＳプライベート・ユーザ・アイデンティティ（ＩＭＰＩ）、ＩＭＳパブリック・ユーザ・アイデンティティ（ＩＭＰＵ）、及び証明情報などのような、ユーザ識別情報を含む。

ＩＰＴＶシステムを例に挙げると、セットトップボックス（ＳＴＢ）やテレビのようなあらゆるＩＰＴＶ端末機能（ＩＴＦ）は、ＩＰＴＶサービスを受けるために、ＩＭＳネットワーク及びＩＰＴＶシステムによってＩＳＩＭを用いて認証される必要がある。

しかしながら、必ずしも全てのＩＭＳＵＥがＵＩＣＣを備える訳ではない。ＵＩＣＣを持たないＩＭＳＵＥは、ＩＭＳネットワークにアクセスするために、他の何らかの手段によって加入情報を取得しなければならない。更に、ＵＩＣＣを持つＩＭＳＵＥにとっても、ＩＭＳＵＥのユーザがＵＩＣＣの所有者と異なるかもしれないので、加入情報を外部から取得することが望ましい場合もある。それゆえ、リモートＩＳＩＭアクセスのための技術、即ち、ＩＭＳＵＥが他のデバイスのＩＳＩＭを利用できるようにする技術が、必要とされる。

現在のところ、リモートＳＩＭ／ＩＳＩＭアクセス技術のためのメカニズム、用例、或いはサービス要件を与えるいくつかの先行参照技術が、以下の通り知られている。

− 第３世代パートナーシップ・プロジェクト（３ＧＰＰ）ＴＳＧＳＡＷＧ３は、いくつかの異なるモデル及びシナリオを議論した。そこでは、ＩＭＳアクセス能力は、固定ＩＰネットワークに接続されるＰＣのようなデバイスとＵＩＣＣを持つＵＭＴＳＵＥという、２つのエンティティに分割されている。例えば、ＰＣ上のＩＭＳ機能とＵＭＴＳＵＥのＵＩＣＣに格納されているＩＳＩＭ（又はＵＳＩＭ）とが、何らかのインタフェースを介して結びつけられて、ＰＣ及びＵＭＴＳＵＥが協力してＵＩＣＣを持つＩＭＳＵＥとして振る舞うようになる。

− モバイルオペレータに対する認証のためにラップトップコンピュータやＰＤＡのような周辺デバイスによってＳＩＭアプリケーションが再利用されて、モバイルオペレータが提供する３ＧＰＰネットワーク及びＷＬＡＮネットワークに周辺デバイスがアクセスできるようにする環境における、問題、セキュリティ上の脅威、及び潜在的な要件などを提示する実現可能性の研究が、３ＧＰＰＴＲ３３．８１７において行われた。

− Fixed Mobile Convergence Alliance（ＦＭＣＡ）は、ＦＭＣＡが規定した固定移動融合環境のために移動体ハンドセット内のＳＩＭが他のユーザデバイス上で認証トークンとして使用されている場合の、ＳＩＭアクセス／認証サービスのためのサービス要件を与えている。

− ブルートゥースＳＩＭアクセスプロファイルは、自動車電話のような内蔵ＧＳＭ送受信機を持つデバイスがブルートゥースを用いて電話内のＳＩＭカードに接続することを可能にすることで、自動車電話自体は個別のＳＩＭカードを必要としないようにする手段を提供する。

＜既存のソリューションの課題＞
リモートＩＳＩＭアクセスを実現するためには、利用可能なＩＳＩＭ（又はＵＳＩＭ）アプリケーションを動的に発見して発見されたＩＳＩＭアプリケーションをＩＭＳＵＥとペアにするための、ローカル環境における何らかのメカニズムが、最終的に必要とされる。しかしながら、先行参照技術はいずれも、そのようなメカニズムを提供する完全で詳細なソリューションを提供してはいない。

ブルートゥースＳＩＭアクセスプロファイルは、リモートＩＳＩＭアクセスを実現するための１つのソリューションになり得る。しかしながら、イーサネット（登録商標）やＷＬＡＮと比べるとブルートゥースを備えたユーザデバイスは現在のマーケットにおける入手可能性に欠けることを考えれば、全てのホームユーザデバイスにブルートゥースアダプタを備えさせることは、困難である。

更に、先行参照技術はいずれも、ＩＭＳＵＥが他のデバイスによって維持管理されている加入情報を利用する際にＩＭＳＵＥとＩＭＳＡＳとの間で暗号化された通信を効率的に実現する具体的な技術を提供していない。

本発明は上述の課題に対処することを意図しており、ＩＭＳＵＥが他のデバイスによって維持管理されている加入情報を利用することを可能にする、新規な技術を導入することを特徴とする。このことは、添付の独立請求項に従う装置、方法、及びデバイスによって、また、従属請求項に従う実施形態によって、達成される。

本発明の第１の態様によれば、ＩＭＳユーザ装置（ＵＥ）が提供される。前記ＩＭＳＵＥは、ＵＰｎＰ技術に基づいて、ＵＰｎＰネットワークの中からＩＭＳ加入情報を持つホストデバイスを検索する検索手段と、前記検索手段によって発見されたホストデバイスとのセッションを確立する確立手段と、前記セッションを介して前記ホストデバイスから前記ＩＭＳ加入情報を引き出す加入情報引き出し手段と、前記ＩＭＳ加入情報を使用してＩＭＳネットワークに登録する登録手段と、前記セッションを介して前記ホストデバイスへ前記ＩＭＳネットワーク内のＩＭＳアプリケーションサーバ（ＡＳ）のＩＤを送信することにより、前記ＩＭＳＡＳと共有される第１の暗号鍵を、前記セッションを介して前記ホストデバイスから引き出す鍵引き出し手段と、前記第１の暗号鍵を使用して前記ＩＭＳＡＳと暗号化通信を実行する通信手段と、を備える。

いくつかの実施形態では、前記通信手段は、前記ＩＭＳＡＳから、第２の暗号鍵を使用して暗号化されたコンテンツと、前記第１の暗号鍵を使用して暗号化された前記第２の暗号鍵とを受信し、前記ＩＭＳＵＥは、前記第１の暗号鍵を使用して前記暗号化された前記第２の暗号鍵を復号する鍵復号手段と、前記第２の暗号鍵を使用して前記暗号化された前記コンテンツを復号するコンテンツ復号手段と、を更に備える。前記第２の暗号鍵は、ＭＢＭＳトラヒックキー（ＭＴＫ）であってもよい。

いくつかの実施形態では、前記確立手段は、前記ホストデバイスから鍵サーバのＩＤを受信し、前記鍵サーバから前記ホストデバイスと共有される第３の暗号鍵を受信し、前記第３の暗号鍵を使用して前記セッションを暗号化する。前記第３の鍵は、Ks_local_deviceであってもよい。

本発明の第２の態様によれば、ＩＭＳユーザ装置（ＵＥ）の制御方法が提供される。前記制御方法は、ＵＰｎＰ技術に基づいて、ＵＰｎＰネットワークの中からＩＭＳ加入情報を持つホストデバイスを検索するステップと、前記検索するステップにおいて発見されたホストデバイスとのセッションを確立するステップと、前記セッションを介して前記ホストデバイスから前記ＩＭＳ加入情報を引き出すステップと、前記ＩＭＳ加入情報を使用してＩＭＳネットワークに登録するステップと、前記セッションを介して前記ホストデバイスへ前記ＩＭＳネットワーク内のＩＭＳアプリケーションサーバ（ＡＳ）のＩＤを送信することにより、前記ＩＭＳＡＳと共有される第１の暗号鍵を、前記セッションを介して前記ホストデバイスから引き出すステップと、前記第１の暗号鍵を使用して前記ＩＭＳＡＳと暗号化通信を実行するステップと、を備える。

いくつかの実施形態では、前記実行するステップは、前記ＩＭＳＡＳから、第２の暗号鍵を使用して暗号化されたコンテンツと、前記第１の暗号鍵を使用して暗号化された前記第２の暗号鍵とを受信し、前記制御方法は、前記第１の暗号鍵を使用して前記暗号化された前記第２の暗号鍵を復号するステップと、前記第２の暗号鍵を使用して前記暗号化された前記コンテンツを復号するステップと、を更に備える。前記第２の暗号鍵は、ＭＢＭＳトラヒックキー（ＭＴＫ）であってもよい。

いくつかの実施形態では、前記確立するステップは、前記ホストデバイスから鍵サーバのＩＤを受信し、前記鍵サーバから前記ホストデバイスと共有される第３の暗号鍵を受信し、前記第３の暗号鍵を使用して前記セッションを暗号化する。前記第３の鍵は、Ks_local_deviceであってもよい。

本発明の第３の態様によれば、ホストデバイスが提供される。前記ホストデバイスは、ＵＰｎＰ技術に基づいて、ＩＭＳユーザ装置（ＵＥ）とのセッションを確立する確立手段と、メモリからＩＭＳ加入情報を引き出す加入情報引き出し手段と、前記セッションを介して前記ＩＭＳＵＥへ前記ＩＭＳ加入情報を送信する加入情報送信手段と、前記セッションを介して前記ＩＭＳＵＥから受信した、ＩＭＳネットワーク内のＩＭＳアプリケーションサーバ（ＡＳ）のＩＤに基づいて、前記ＩＭＳＡＳと共有される第１の暗号鍵を引き出す鍵引き出し手段と、前記セッションを介して前記ＩＭＳＵＥへ前記第１の暗号鍵を送信する鍵送信手段と、を備える。

いくつかの実施形態では、前記鍵引き出し手段は、ブートストラッピングサーバ機能（ＢＳＦ）と共有されるマスタ鍵を作成するブートストラッピング手段と、前記マスタ鍵と前記ＩＭＳＡＳの前記ＩＤとに基づいて前記第１の暗号鍵を算出する算出手段と、を備える。前記マスタ鍵は、Ｋｓであってもよい。

いくつかの実施形態では、前記確立手段は、前記ＩＭＳＵＥへ鍵サーバのＩＤを送信し、前記鍵サーバの前記ＩＤに基づいて、前記ＩＭＳＵＥと共有される第２の暗号鍵を算出し、前記第２の暗号鍵を使用して前記セッションを暗号化する。前記第２の鍵は、Ks_local_deviceであってもよい。

本発明の第４の態様によれば、ホストデバイスの制御方法が提供される。前記制御方法は、ＵＰｎＰ技術に基づいて、ＩＭＳユーザ装置（ＵＥ）とのセッションを確立するステップと、メモリからＩＭＳ加入情報を引き出すステップと、前記セッションを介して前記ＩＭＳＵＥへ前記ＩＭＳ加入情報を送信するステップと、前記セッションを介して前記ＩＭＳＵＥから受信した、ＩＭＳネットワーク内のＩＭＳアプリケーションサーバ（ＡＳ）のＩＤに基づいて、前記ＩＭＳＡＳと共有される第１の暗号鍵を引き出すステップと、前記セッションを介して前記ＩＭＳＵＥへ前記第１の暗号鍵を送信するステップと、を備える。

いくつかの実施形態では、前記第１の暗号鍵を引き出す前記ステップは、ブートストラッピングサーバ機能（ＢＳＦ）と共有されるマスタ鍵を作成するステップと、前記マスタ鍵と前記ＩＭＳＡＳの前記ＩＤとに基づいて前記第１の暗号鍵を算出するステップと、を含む。前記マスタ鍵は、Ｋｓであってもよい。

いくつかの実施形態では、前記確立するステップは、前記ＩＭＳＵＥへ鍵サーバのＩＤを送信し、前記鍵サーバの前記ＩＤに基づいて、前記ＩＭＳＵＥと共有される第２の暗号鍵を算出し、前記第２の暗号鍵を使用して前記セッションを暗号化する。前記第２の鍵は、Ks_local_deviceであってもよい。

本発明の主な利点は、次の通りである。ＩＭＳＵＥはＩＭＳ加入情報を持つＵＰｎＰネットワーク内の利用可能なホストデバイス（換言すれば、ＩＳＩＭアプリケーション又はＵＳＩＭアプリケーションを持つ利用可能なホストデバイス）を動的に発見することができ、そのホストデバイスによって維持管理されているＩＭＳ加入情報を使用してＩＭＳベースのサービスを受けることができるので、ユーザは自分自身のＵＩＣＣをＩＭＳＵＥに挿入する負担から解放される。更に、本発明は、ＩＭＳＵＥが、ＩＭＳベースのサービスに関連する暗号化通信のために使用される暗号鍵を効率的に取得することができるという点で、便利である。

本発明の更なる特徴は、添付の図面を参照する典型的な実施形態に関する以下の説明から、明らかになるであろう。添付の図面において、全図を通して、同様の参照符号は同一又は類似の部分を示す。

本発明の概要を示す。本発明の実施形態に従う、ＩＰＴＶ端末機能（ＩＴＦ）及びホストデバイスの構成を示す概略ブロック図である。複数のＩＰマルチメディア・サブシステム（ＩＭＳ）加入者ＩＤモジュール（ＩＳＩＭ）を格納したユニバーサルＩＣカード（ＵＩＣＣ）を概略的に示す。本発明の実施形態に従う、リモートＩＳＩＭクライアント及びリモートＩＳＩＭサーバの詳細な構成、及び、リモートＩＳＩＭクライアントがリモートＩＳＩＭサーバを発見する手順を示す。本発明の実施形態に従う、リモートＩＳＩＭクライアントが発見されたリモートＩＳＩＭサーバからＩＳＩＭリストを受信する手順を示す。ＩＳＩＭリスト及びＩＳＩＭ選択画面の例を示す。本発明の実施形態に従う、ＵＰｎＰコントロールポイント（ＣＰ）とＵＰｎＰＩＳＩＭサービスとの間のＨＴＴＰダイジェストベースの認証の流れを示す。本発明の実施形態に従う、デバイス認証及び鍵確立の概要を示す。本発明の実施形態に従う、リモートＩＳＩＭクライアントとリモートＩＳＩＭサーバとの間の、デバイス認証及び鍵確立のメカニズムを概略的に示す。本発明の実施形態に従う、リモートＩＳＩＭクライアントがリモートＩＳＩＭサーバとのセキュアな関係（ＳＡ，secure association）を確立する手順を示す。本発明の実施形態に従う、ユーザがユーザＩＳＩＭプロファイルを選択するための選択画面を示す。本発明の実施形態に従う、ＩＴＦがＩＭＳネットワークに対してＩＭＳ登録を実行する手順を示す。本発明の実施形態に従う、ＩＰＴＶクライアントがホストデバイスからKs_(ext)_NAFを引き出す手順を示す。本発明の実施形態に従う、ＩＰＴＶクライアントが暗号化されたＭＴＫを引き出してコンテンツを復号できるようにする手順を示す。

以下、添付の図面を参照して、本発明の実施形態を説明する。以下で説明される各実施形態は、一般的な概念からより具体的な概念までに亘る多様な概念を理解するのに役立つであろう。

なお、本発明の技術的範囲は、特許請求の範囲によって規定されるのであって、以下の個別の実施形態によって限定される訳ではない。また、実施形態の中で説明されている特徴の組み合わせすべてが、本発明を実現するために必須とは限らない。

以下の説明において、ＩＭＳベースのサービス、ＩＭＳＵＥ、及びＩＭＳＡＳの例として、ＩＰＴＶサービス、ＩＴＦ、及びＩＰＴＶＡＳを採用する。しかしながら、本発明は、あらゆる種類のＩＭＳベースのサービス、及び、対応するＩＭＳＵＥ及びＩＭＳＡＳに適用可能である。更に、ＩＳＩＭがＩＭＳ加入情報の情報源（ソース）として説明されるが、本発明は、ＩＳＩＭの代わりにＵＳＩＭが使用される場合にも適用可能である。

図１は、本発明の概要を示す。ホームネットワーク１００は、ＵＰｎＰ技術に基づく通信ネットワークである。ホームネットワーク１００は、ＩＴＦ１０１、及び、ＵＩＣＣ１０３を備えるホストデバイス１０２を含む。ホストデバイスに物理的に挿入されるＵＩＣＣ１０３の中にＩＳＩＭ（又はＵＳＩＭ）が実装されているものとするが、そのようなＩＤモジュールは、他の形式で実装されてもよい。例えば、ＩＳＩＭ（又はＵＳＩＭ）は、ホストデバイス１０２の信頼された実行環境へネットワーク経由でダウンロード可能な、リモート管理されるソフトウェアオブジェクトとして実現されてもよいし、ホストデバイス１０２内の埋め込みチップ（インダストリアル・フォーム・ファクタとも呼ばれる）の中に実装されてもよい。後者もリモート管理可能である。

ＩＭＳネットワーク１５０は、呼セッション制御機能（ＣＳＣＦ）１５１、及び、ネットワークアプリケーション機能（ＮＡＦ）の一種であるＩＰＴＶＡＳ１５２を含む。ＩＭＳネットワーク１５０はまた、ホーム加入者サーバ（ＨＳＳ）（不図示）も含む。ホストデバイスからアクセス可能なブートストラッピングサーバ機能（ＢＳＦ）１１１も存在する。

ＩＴＦ１０１はＩＭＳ機能を備えるので、ＩＭＰＩ及びＩＭＰＵのようなＩＭＳ加入情報を有する限り、標準規格のＧｍインタフェース及びＵａインタフェースを介してＩＭＳネットワーク１５０と直接通信することができる。しかしながら、本実施形態では、ＩＴＦ１０１はＵＩＣＣを持たないか、又は、ＵＩＣＣを持ってはいるが何らかの理由で自分自身のＵＩＣＣを使用しないことになっている。従って、ＩＴＦ１０１は、ＵＩＣＣ１０３の中で維持管理されているＩＭＳ加入情報をホストデバイス１０２から引き出す。

ホストデバイス１０２は、ＩＴＦ１０１に対してＩＭＳ加入情報を提供可能である限り、いかなる種類のデバイスであってもよい。たとえば、ホストデバイス１０２は、専用サーバ、移動体電話、又はＷＯ２００６／０４５７０６に開示されるようなホームＩＭＳゲートウェイなどであってもよい。ホストデバイス１０２は、自分自身でＣＳＣＦ１５１及びＩＰＴＶＡＳ１５２にアクセスするＩＴＦであってさえもよい。

図２は、ＩＴＦ１０１及びホストデバイス１０２の構成を示す概略ブロック図である。ここで、ＩＴＦ１０１及びホストデバイス１０２の中の各ブロックは、専用ハードウェアを使用して実装されてもよいし、プロセッサ（不図示）によって実行されるソフトウェアを使用して実装されてもよいし、その組み合わせによって実装されてもよい。

ホストデバイス１０２は、ＵＩＣＣ１０３（図２においては不図示）に格納されるＩＳＩＭ２０１を含む。本実施形態では、ＵＩＣＣ１０３は、図３に示すように複数のＩＳＩＭ２０１を格納しており、また、各ＩＳＩＭ２０１は、１つのＩＭＰＩと１以上のＩＭＰＵとを含むものとする。このことには利点がある。というのも、各ユーザが自分自身のＩＳＩＭを所有し、これを自分自身の個人識別番号（ＰＩＮ）で保護することができるからである。更に、各ユーザは、自分自身のＩＳＩＭを用いて、個々人でＩＭＳネットワークに登録することができる。しかしながら、全てのユーザが単一のＩＳＩＭを共有することもできる。

ホストデバイス１０２はまた、汎用ブートストラッピングアーキテクチャ（ＧＢＡ）クライアント２０３を含むＩＳＩＭマネージャ２０２、及び、リモートＩＳＩＭサーバ２０４も含む。

注目すべきこととして、本実施形態は、ＩＳＩＭ２０１がＧＢＡ＿Ｕをサポートする場合と、ＩＳＩＭ２０１がＧＢＡ＿ＵをサポートしないがＧＢＡクライアント２０３がＧＢＡ＿ＭＥをサポートする場合との両方に、適用可能である。ＧＢＡ＿Ｕは、ＵＩＣＣベースの機能強化を伴うＧＢＡであり、ＧＢＡ固有の機能は、移動体端末（ＭＥ）とＵＩＣＣとの間で分割されている。ＧＢＡ＿Ｕでは、マスタ鍵（Ｋｓ）はＵＩＣＣの中に残り、ＵＩＣＣの中で生成されるKs_ext_NAFだけがＭＥへ届けられる。他方、ＧＢＡ＿ＭＥでは、全てのＧＢＡ固有の機能がＭＥの中で実行される。ＵＩＣＣはＧＢＡを意識することがなく、即ち、マスタ鍵（Ｋｓ）がＭＥへ届けられ、ＭＥの中でＮＡＦ固有の鍵(Ks_NAF)がＫｓから生成される。なお、"Ks_(ext)_NAF"は、ＧＢＡ＿Ｕの文脈ではKs_ext_NAFを意味し、ＧＢＡ＿ＭＥの文脈ではKs_NAFを意味する。

ＩＴＦ１０１は、ＩＰＴＶクライアント２０５、ＩＭＳミドルウェア２０６、ＧＢＡクライアント２１１を含むＩＳＩＭマネージャ２０７、及び、リモートＩＳＩＭクライアント２０８を含む。ＩＴＦ１０１はＩＳＩＭ２０９を有してもよいが、本実施形態では、ＩＴＦ１０１はこれを使用しない。様々な情報を表示するディスプレイ２１０が、ＩＴＦ１０１に接続されている。

ＩＳＩＭ２０１の役割の１つは、ＩＭＳ認証及び鍵合意（ＡＫＡ）証明情報（即ち、ＲＥＳ、Ｃｋ、及びＩｋ）を生成することである。ＩＭＳミドルウェア２０６は、Ｇｍインタフェースを介して、ＩＭＳＡＫＡ証明情報を用いてＩＭＳ登録を行う。

ＩＳＩＭ２０１の他の役割は、ＮＡＦ鍵の導出である。ＩＰＴＶクライアント２０５は、マスタ鍵（即ち、Ｋｓ）から導出された暗号鍵である"Ks_(ext)_NAF"を用いてセキュアにされたＵａインタフェースを介して、ＩＰＴＶＡＳ１５２と通信する。Ｋｓは、ＧＢＡクライアント２０３が実行するブートストラッピング手順の結果として、ホストデバイス１０２とＢＳＦ１１１との間で共有される。

Ｕａインタフェースは、サーバ証明書ベースのＴＬＳ又はKs_(ext)_NAFベースのＴＬＳ（即ち、ＲＦＣ４２７９で規定される事前共有鍵ＴＬＳ）などを用いて、Ks_(ext)_NAFにより実際にセキュアにされる。

ＩＳＩＭマネージャ２０２は、ＩＳＩＭ２０１へのアクセスを可能にするＡＰＩを備える。ＩＳＩＭマネージャ２０２がＵｂインタフェース及びＧＢＡ＿ＭＥをサポートするＧＢＡクライアント２０３を含むので、ＩＳＩＭ２０１がＧＢＡ＿Ｕをサポートする必要はない。

リモートＩＳＩＭサーバ２０４及びリモートＩＳＩＭクライアント２０８は協力して、ＩＴＦ１０１がリモートＩＳＩＭアクセスを実行できるようにする。より具体的には、ＩＳＩＭマネージャ２０７及びＧＢＡクライアント２１１は、それぞれ、ＩＳＩＭマネージャ２０２及びＧＢＡクライアント２０３と同様の機能を有する。ＩＴＦ１０１がＩＳＩＭにアクセスする必要がある場合、ＩＳＩＭマネージャ２０７は、リモートＩＳＩＭクライアント２０８及びリモートＩＳＩＭサーバ２０４を介してＩＳＩＭ２０１にアクセスする。

リモートＩＳＩＭクライアント２０８は、ＩＳＩＭマネージャ２０７の後ろに配置されているので、ＩＰＴＶクライアント２０５及びＩＭＳミドルウェア２０６を含む全てのＩＴＦ１０１の機能から隠されている。これにより、ＩＰＴＶクライアント２０５及びＩＭＳミドルウェア２０６の観点からは透過的なＩＳＩＭアクセスが可能になる。即ち、ＩＰＴＶクライアント２０５及びＩＭＳミドルウェア２０６は、ＩＴＦ１０１がローカルのＩＳＩＭ２０９にアクセスしているのかリモートのＩＳＩＭ２０１にアクセスしているのかを意識する必要がない。

本実施形態では、以下の理由により、ＧＢＡクライアント２１１ではなくＧＢＡクライアント２０３がＵｂインタフェースを介したブートストラッピング手順を実行する。ＧＢＡクライアント２１１がリモートのＩＳＩＭ２０１からの支援を受けて自身のＵｂインタフェースを走らせる場合、ＩＴＦ１０１とホストデバイス１０２との間の情報交換が複雑になる。一方、ＧＢＡクライアント２０３がＵｂインタフェースを走らせる場合、ブートストラッピング手順の目的でＩＴＦ１０１とホストデバイス１０２との間で情報を交換する必要がない。更に、ホストデバイス１０２もＩＴＦのようなＩＭＳＵＥである場合、ホストデバイス１０２に内在するローカルのＵａアプリケーションにとっても利用可能でなければならないＫｓ／ブートストラップ・トランザクションＩＤ（Ｂ−ＴＩＤ）の更新を追跡する必要がある。この場合、ホストデバイス１０２がＵｂインタフェースを走らせてＫｓ／Ｂ−ＴＩＤを自分自身で管理すれば、情報交換の複雑さが緩和される。

しかしながら、注目すべきこととして、ＧＢＡクライアント２１１が自分自身のＵｂインタフェースを介してブートストラッピング手順を実行しても構わない。

図４から図６を参照して、ＩＴＦ１０１が１以上のホストデバイス１０２を発見し、特定のＩＭＳベースのサービスを受けるために、発見されたホストデバイス１０２が維持管理するＩＳＩＭ（より正確には、ＩＳＩＭのＩＭＰＵ群のうちの１つ）を選択する手順（以下、「発見プロセス」と呼ぶ）を、説明する。

図４に示すように、リモートＩＳＩＭクライアント２０８はＵＰｎＰコントロールポイント（ＣＰ）４０１を含み、リモートＩＳＩＭサーバ２０４は、ＵＰｎＰサービスの一種であるＵＰｎＰＩＳＩＭサービス４０３を含んだＵＰｎＰルートデバイス４０２を含む。リモートＩＳＩＭサーバ２０４はＩＳＩＭマネージャ２０２にアクセスするので、ＵＰｎＰＩＳＩＭサービス４０３は、ＵＰｎＰスキームを介してＩＳＩＭ２０１を間接的に露出することができる。

ＩＭＳ加入情報を取得するために、ＩＴＦ１０１のリモートＩＳＩＭクライアント２０８は、以下のように、ＵＰｎＰネットワークであるホームネットワーク１００の中からホストデバイス１０２のリモートＩＳＩＭサーバ２０４を検索する。なお、ホームネットワーク１００内に２以上のホストデバイス１０２が存在してもよく、その場合、２以上のリモートＩＳＩＭサーバ２０４が発見され得る。

ステップＳ４０１−Ｓ４０６で、ＵＰｎＰＣＰ４０１は、標準規格のＵＰｎＰディスカバリー手順を実行する。発見すべきサービスタイプが、ＵＰｎＰＩＳＩＭサービス４０３に対するユニフォーム・リソース・ネーム（ＵＲＮ）の形式で、規定されているサービス識別子に設定される。

本実施形態では、ＵＰｎＰアクションである"Get ISIM List ()"が定義されてＵＰｎＰＩＳＩＭサービス４０３によって露出されることで、ユーザは、リモートＩＳＩＭサーバ２０４の後ろにある利用可能なＩＳＩＭアプリケーションを見ることができる。図５に示すように、ＵＰｎＰＣＰ４０１は、このアクション要求を発見された全てのＵＰｎＰＩＳＩＭサービス４０３に対して送信し（ステップＳ５０１及びＳ５０３）、それに応えて、各ホストデバイス１０２が維持管理するＩＳＩＭのリスト（ＩＳＩＭリスト）を受信する（ステップＳ５０２及びＳ５０４）。

ＩＳＩＭリストの例は、図６に示すような、ＸＭＬによってエンコードされたテキストデータである。ＩＳＩＭリスト内の各ＩＳＩＭインスタンスは、ＵＰｎＰＩＳＩＭサービス４０３によって割り当てられた持続性のＩＤ（ＩＳＩＭ−ＩＤ）（例えば、ＩＭＰＩ及び全ＩＭＰＵのハッシュ値）によって識別可能である。ＩＳＩＭリストは、少なくとも１つのＩＭＰＵと、これに関連付けられたサービス名（例えば、プッシュ・トゥ・トーク・オーバー・セルラ（ＰｏＣ）及びＩＰＴＶなど）とを含む。元々、ＩＳＩＭアプリケーション自体は、各ＩＭＰＵに関連付けられたサービスに関する情報を何も含んでいない。しかしながら、そのようなサービス名情報をＩＳＩＭリストに含めることは、そうすることによりユーザが所望のサービス加入に関連付けられた特定のＩＭＰＵを正確に選択できるようになるので、有益である。

この目的のために、本実施形態に従うホストデバイス１０２は、次のメカニズムをサポートする。即ち、ＩＳＩＭマネージャ２０２は、事前にＨＳＳからＩＳＩＭ毎にサービスプロファイルをダウンロードする。このダウンロードは、標準規格のＵｔインタフェースを介して実行可能である。サービスプロファイルは、どのＩＭＰＵがどのＩＭＳベースのサービスに関連付けられているかに関する情報を含み、この情報により、ＩＳＩＭマネージャ２０２は、どのＩＭＰＵがどのサービスに関連付けられているかを維持管理するマッピング情報をＩＳＩＭ毎に生成することができる。この情報に基づき、リモートＩＳＩＭサーバ２０４は図６に示すように、各ＩＭＰＵに関連付けられたサービス名を含んだＩＳＩＭリストを生成する。

ＩＴＦは、図６に示すように、ＩＳＩＭリストの内容をディスプレイ２１０に表示する。この場合、ＩＭＰＵに関連付けられたサービス名は、ユーザにとって所望のＩＭＰＵを選択するためのヒントとしての役割を果たす。ユーザはＩＳＩＭリストからＩＳＩＭを選択し、更に、（ＩＳＩＭが２以上のＩＭＰＵを含む場合は）選択したＩＳＩＭの中でＩＭＰＵを選択する。ＩＴＦ１０１は、選択したＩＭＳ加入情報（即ち、選択したＩＭＰＵ、及び選択したＩＳＩＭのＩＭＰＩなど）を用いて、ＩＭＳネットワーク１５０に登録する。

図７から図１０を参照して、リモートＩＳＩＭクライアント２０８がリモートＩＳＩＭサーバ２０４とのセキュアな関係（ＳＡ）を確立する手順（以下、「ペアリングプロセス」と呼ぶ）を説明する。

ユーザがＩＳＩＭリストからＩＳＩＭを選択すると、リモートＩＳＩＭクライアント２０８は最初に、選択されたＩＳＩＭを使用するようにユーザを認証可能か否かを検証する。ＩＳＩＭは組み込みのＰＩＮベースのユーザ認証をサポートするので、ユーザ認証はＰＩＮに基づく。

ＰＩＮベースの認証をサポートするプロトコルを実装するために、ＵＰｎＰアクション要求である"Paring ()"が定義される。このアクション要求は、ＩＳＩＭリストから取得されたＩＳＩＭ−ＩＤを引数として伴う。このアクション要求、及び応答メッセージは、関連するＨＴＴＰダイジェスト・ヘッダフィールドを搬送するので、ＰＩＮベースの認証はＨＴＴＰダイジェストに基づいて実行される。ＵＰｎＰ技術はＨＴＴＰベースの技術なので、ＨＴＴＰダイジェストベースの認証を実行可能である。図７は、ＨＴＴＰダイジェストベースの認証の流れを示す。

ステップＳ７０１で、ＵＰｎＰＣＰ４０１は、ＵＰｎＰアクション要求である"Paring (ISIM-ID, Device_ID)"をＵＰｎＰＩＳＩＭサービス４０３へ送信する。本実施形態では、ＵＰｎＰアクション要求は、ＩＳＩＭ−ＩＤに加えてデバイスＩＤ（Ｄｅｖｉｃｅ＿ＩＤ）を含む。Ｄｅｖｉｃｅ＿ＩＤは、鍵確立のために使用される（詳細は図１０を参照して後述する）。

ステップＳ７０２で、ＵＰｎＰＩＳＩＭサービス４０３は、チャレンジを含む401 Unauthorized応答をＵＰｎＰＣＰ４０１へ送信する。401 Unauthorized応答の受信後、ＵＰｎＰＣＰ４０１はユーザに対して、例えばディスプレイ２１０を介して、選択されたＩＳＩＭ２０１のＰＩＮを入力するように促し、入力されたＰＩＮを受信する。

ステップＳ７０３で、ＵＰｎＰＣＰは、再びＵＰｎＰアクション要求である"Paring (ISIM-ID, Device_ID)"をＵＰｎＰＩＳＩＭサービス４０３へ送信するが、今回は、アクション要求はＰＩＮから導出された応答を含む。

ステップＳ７０４で、ＵＰｎＰＩＳＩＭサービス４０３は応答を検証し、ユーザ認証の成功を示す200 OK応答を、ＵＰｎＰＣＰ４０１へ返す。200 OK応答は、鍵確立のために使用されるＢ−ＴＩＤ及びＮＡＦ＿ＩＤを含む（詳細は図１０を参照して後述する）。

ユーザ認証の成功後、デバイス認証及び鍵確立が、図８に示すように実行される。

ステップＳ８０１で、リモートＩＳＩＭサーバ２０４は、リモートＩＳＩＭクライアント２０８が「信頼された」ものであることを検証する。その反対も行われる。

ステップＳ８０２で、リモートＩＳＩＭクライアント２０８及びリモートＩＳＩＭサーバ２０４は、両者の間で暗号鍵を確立する。その後、確立された鍵を使用して、両者の間でセキュア伝送チャネル（例えば、トランスポート・レイヤ・セキュリティ（ＴＬＳ）セッション）がセットアップされる。それゆえ、本実施形態によれば、ペアリングの成功は、リモートＩＳＩＭクライアント２０８とリモートＩＳＩＭサーバ２０４との間のＴＬＳセッションの確立という結果をもたらす。

本実施形態によれば、リモートＩＳＩＭクライアント２０８及びリモートＩＳＩＭサーバ２０４は、３ＧＰＰによって規定されるメカニズムに基づいて、デバイス認証及び鍵確立を行う。このメカニズムを使用すると、（"Ks_local_device"と呼ばれる）共有秘密鍵が、リモートＩＳＩＭクライアント２０８とリモートＩＳＩＭサーバ２０４との間で確立される。次いで、リモートＩＳＩＭクライアント２０８及びリモートＩＳＩＭサーバ２０４は、確立されたKs_local_deviceを使用してＴＬＳセッションを確立する。

図９を参照して、デバイス認証及び鍵確立のメカニズムの概要を説明する。

ＨＴＴＰダイジェストを使用するＰＩＮベースのユーザ認証の後（図７参照）、リモートＩＳＩＭクライアント２０８は、ＮＡＦキーセンター９０１に対してＨＴＴＰＳセッションを確立する。この場合、リモートＩＳＩＭクライアント２０８は、自身のデバイス証明書を用いてＮＡＦキーセンター９０１に対して認証される。次いで、リモートＩＳＩＭクライアント２０８は、ホストデバイス１０２と共有されるKs_local_deviceを、ＮＡＦキーセンター９０１から受信する。この意味で、ＮＡＦキーセンター９０１は事実上、ＩＴＦ１０１のようなＩＭＳＵＥが信頼されるということを検証する、オペレータの認証センターとして振る舞う。このメカニズムはまた、オペレータに対して以下の利益ももたらす。

− 動的なデバイス認証が可能である。換言すれば、ＮＡＦキーセンター９０１を用いると、オペレータは自身のポリシーに基づいて、どのＩＭＳＵＥがどのリモートＩＳＩＭ（即ち、ホストデバイスによって維持管理されているＩＳＩＭ）に対してリモートＩＳＩＭアクセスを実行することが許可されるかを決定することができる。

− オペレータにとって、全リモートＩＳＩＭアクセスの追跡及びログ記録が可能である。このことは例えば、ユーザに対する課金を容易にする。

上述のように、リモートＩＳＩＭクライアント２０８は、自身のデバイス証明書を用いてＮＡＦキーセンター９０１に対して認証される。一方、リモートＩＳＩＭクライアント２０８は、確立されたKs_local_deviceに基づいてＴＬＳハンドシェイクの間にリモートＩＳＩＭサーバ２０４を認証することができる。というのも、リモートＩＳＩＭサーバ２０４は、それが真正のものである場合にのみ共有秘密（即ち、Ks_local_device）を生成することができるからである。従って、リモートＩＳＩＭサーバ２０４は、リモートＩＳＩＭクライアント２０８がリモートＩＳＩＭサーバ２０４を認証するためにデバイス証明書を持つ必要がない。

図１０は、ペアリングプロセスの流れを示す。上述のように、ペアリングプロセスは、ＵＰｎＰＣＰ４０１がＵＰｎＰアクション要求である"Pairing ()"をＵＰｎＰＩＳＩＭサービス４０３へ送信すると、開始する。アクション要求は、ＩＳＩＭ−ＩＤ、及びリモートＩＳＩＭクライアント２０８のＤｅｖｉｃｅ＿ＩＤを含む。Ｄｅｖｉｃｅ＿ＩＤは、ステップＳ１００９に関連して説明するように、Ks_local_deviceを導出するために、リモートＩＳＩＭサーバ２０４が必要とする。

ステップＳ７０３の後、ステップＳ１００１で、リモートＩＳＩＭサーバ２０４はＩＳＩＭマネージャ２０２に対してＢ−ＴＩＤを要求する。

ステップＳ１００２−Ｓ１００３で、ＩＳＩＭマネージャ２０２は、ＩＳＩＭ２０１からＢ−ＴＩＤを引き出す。ＧＢＡ＿ＭＥの場合、ＩＳＩＭマネージャ２０２がＢ−ＴＩＤを維持管理するので、これらのステップは、不要である。

ステップＳ１００４で、ＩＳＩＭマネージャ２０２は、リモートＩＳＩＭサーバ２０４へＢ−ＴＩＤを返す。

ステップＳ７０４で、ＵＰｎＰＩＳＩＭサービス４０３は、リモートＩＳＩＭクライアント２０８へ200 OK応答を返す。この応答は、ＮＡＦキーセンター９０１のＮＡＦ＿ＩＤと共にＢ−ＴＩＤを含む。なお、ＮＡＦ＿ＩＤは、事前にリモートＩＳＩＭサーバ２０４内に設定しておくことができる。

ステップＳ１００５−Ｓ１００８で、リモートＩＳＩＭサーバ２０４は、ＩＳＩＭマネージャ２０２からKs_(ext)_NAFを引き出す。なお、ステップＳ１００６−Ｓ１００７において、ＧＢＡ＿Ｕの場合、ＩＳＩＭマネージャ２０２はＩＳＩＭ２０１からKs_ext_NAFを引き出す。他方、ＧＢＡ＿ＭＥの場合、ＩＳＩＭマネージャ２０２はＩＳＩＭ２０１からＣｋ及びＩｋを引き出す。

ステップＳ１００９で、リモートＩＳＩＭサーバ２０４は、Ｂ−ＴＩＤ、ＮＡＦ＿ＩＤ、Ks_(ext)_NAF、及びＤｅｖｉｃｅ＿ＩＤに基づいて、Ks_local_deviceを導出する。

ステップＳ１０１０−Ｓ１０１３で、図８を参照して説明するように、リモートＩＳＩＭクライアント２０８は自身のデバイス証明書を用いてＮＡＦキーセンター９０１とのＨＴＴＰＳセッションを確立し、ＮＡＦキーセンター９０１からKs_local_deviceを引き出す。

最後に、ステップＳ１０１４で、リモートＩＳＩＭクライアント２０８は、事前共有暗号鍵（即ち、Ks_local_device）を用いてリモートＩＳＩＭサーバ２０４との事前共有鍵（ＰＳＫ）ＴＬＳセッションを確立し、ペアリングプロセスが完了する。

いくつかの実施形態では、ＩＴＦ１０１は、ユーザ認証（図１０のステップＳ７０１−Ｓ７０４参照）の後で「ユーザＩＳＩＭプロファイル」を作成してもよい。ユーザＩＳＩＭプロファイルを用いると、ＩＴＦ１０１は、次に対象のリモートＩＳＩＭにアクセスするときに、ディスカバリプロセス、及びペアリングプロセスの一部を省略することができる。ユーザＩＳＩＭプロファイルは、ステップＳ７０４の手順の後で、リモートＩＳＩＭクライアント２０８によって作成されて維持管理される（不図示）。

ユーザは、ユーザＩＳＩＭプロファイルに対して、"Alice"や"Bob"のようなユーザフレンドリーな名前を与えることができる。このユーザフレンドリーな名前を使用して、ユーザは簡単に、リモートＩＳＩＭクライアント２０８によって維持管理されている多数のプロファイルの中から自分のユーザＩＳＩＭプロファイルを選択することができる。

ユーザＩＳＩＭプロファイルは、
− ＵＰｎＰＩＳＩＭサービス４０３のコントロールＵＲＬ
− ＩＳＩＭ−ＩＤ
− ＰＩＮコード
を含む。

ユーザＩＳＩＭプロファイルの生成過程で、リモートＩＳＩＭクライアント２０８はユーザに対して、他人によるユーザＩＳＩＭプロファイルの悪用を防ぐためにユーザＩＳＩＭプロファイルのためのパスワードを設定するように促してもよい。或いは、ユーザは、対象のリモートＩＳＩＭのためのＰＩＮコードがユーザＩＳＩＭプロファイルの中に含まれないという、他の選択肢を選択してもよい。この場合、ペアリングプロセスが実装されるときは毎回、ユーザはＰＩＮを入力する必要がある。

ユーザＩＳＩＭプロファイルがリモートＩＳＩＭクライアント２０８によって作成された場合、ユーザは、ＩＴＦ１０１を用いてＩＭＳネットワーク１５０にアクセスすることを望むときに、例えば図１１に示されるような選択画面を介して自分のＩＳＩＭプロファイルを選択する。

ＰＩＮはユーザＩＳＩＭプロファイルの中に含まれているので、ユーザは、図１０のステップＳ７０２とＳ７０３の間でＰＩＮを入力する必要がない。ステップＳ７０３で、リモートＩＳＩＭクライアント２０８は、ユーザＩＳＩＭプロファイルからＰＩＮを引き出し、抽出されたＰＩＮに基づいて応答を導出し、この応答を含むアクション要求をリモートＩＳＩＭサーバ２０４へ送信する。

いくつかの実施形態では、ＵＰｎＰアクション"User Authentication ()"が、ＵＰｎＰＣＰ４０１及びＵＰｎＰＩＳＩＭサービス４０３に実装されてもよい。"User Authentication ()"は、ＵＰｎＰＣＰ４０１及びＵＰｎＰＩＳＩＭサービス４０３がペアリングプロセスを開始しないという点で、"Paring ()"と異なる。ＵＰｎＰＣＰ４０１及びＵＰｎＰＩＳＩＭサービス４０３は、ユーザＩＳＩＭプロファイルの作成を目的として、ユーザ認証のみを実行する。この場合、リモートＩＳＩＭサーバ２０４は、図１０のステップＳ１００１−Ｓ１００４の手順を実行しない。ステップＳ７０４の後、リモートＩＳＩＭクライアント２０８はユーザＩＳＩＭプロファイルを作成し、図１０のフローを終了する。

図１２を参照して、ＩＴＦ１０１がＩＭＳネットワーク１５０に対してＩＭＳ登録を実行する手順（以下、「登録プロセス」と呼ぶ）を説明する。登録プロセスは、ペアリング成功の後に実行される（図１０のステップＳ１０１４参照）。

本実施形態によれば、"Get IMS Registration Info ()"及び"AKA Request ()"という名前の２つのＵＰｎＰアクション要求が定義される。アクション要求及び応答は、ステップＳ１０１４において確立されたＴＬＳセッションによって保護される。

ステップＳ１２０１−Ｓ１２０３で、ＵＰｎＰＣＰ４０１は、ＵＰｎＰＩＳＩＭサービス４０３へ"Get IMS Registration Info (ISIM-ID)"を送信する。リモートＩＳＩＭサーバは、ＩＴＦ１０１が最初のＳＩＰ登録要求を送信するために必要なＩＭＳ加入情報を、ＩＳＩＭマネージャ２０２経由でＩＳＩＭ２０１から引き出す。これは、ＩＭＰＩ、ＩＭＰＵ、Ｐ−ＣＳＣＦアドレス、及びホームドメインＵＲＩなどを含む。次いで、ＵＰｎＰＩＳＩＭサービス４０３は、ＵＰｎＰＣＰ４０１へＩＭＳ加入情報を返す。ＵＰｎＰＩＳＩＭサービス４０３から２以上のＩＭＰＵが返された場合、ユーザは次のステップの前に、登録すべき１つのＩＭＰＵを選択する必要がある。或いは、図６に示す画面を介してＩＭＰＵ群のうちの１つが既に選択されている場合、フローは、ユーザの選択なしに次のステップへ進んでもよい。

ステップＳ１２０４−Ｓ１２０５で、ＩＭＳミドルウェア２０６は、ＳＩＰ加入情報を使用してＣＳＣＦ１５１へ最初のＳＩＰ登録要求を送信する。ＩＭＳミドルウェア２０６は次いで、ランダムなチャレンジ（ＲＡＮＤ）及びネットワーク認証トークン（ＡＵＴＮ）を含んだ401 Unauthorized応答をＣＳＣＦ１５１から受信する。

ステップＳ１２０６−Ｓ１２０７で、ＵＰｎＰＣＰ４０１は、ＲＡＮＤ及びＡＵＴＮを引数として"AKA Request ()"アクションを呼び出す。リモートＩＳＩＭサーバ２０４は、ＲＥＳ、Ｃｋ、及びＩｋを取得するために、ＩＳＩＭマネージャ２０２経由でＩＳＩＭ２０１にＲＡＮＤ及びＡＵＴＮを入力する。ＲＥＳ、Ｃｋ、及びＩｋは、最終的にはＵＰｎＰＣＰ４０１へ送り返される。

ステップＳ１２０８−Ｓ１２０９で、ＩＭＳミドルウェア２０６は、Ｃｋ及びＩｋを使用してＣＳＣＦ１５１に対するＩＰＳｅｃチャネルを確立し、ＲＥＳを含んだＳＩＰ登録要求をＣＳＣＦ１５１へ再送する。その結果、ＩＭＳ登録が成功する。

本実施形態によれば、ＩＰＴＶクライアント２０５がＩＰＴＶＡＳ１５２からコンテンツの受信を開始する前に、ＩＰＴＶＡＳ１５２と暗号化された通信を実行するために、ホストデバイス１０２からKs_(ext)_NAFを引き出す。

図１３は、ＩＰＴＶクライアント２０５がホストデバイス１０２からKs_(ext)_NAFを引き出す手順を示す。この目的で、ＵＰｎＰアクション要求である"Get NAF Key ()"が定義される。

ステップＳ１３０１−Ｓ１３０２で、ＩＰＴＶクライアント２０５は、目的のＩＭＳＡＳ（即ち、ＩＰＴＶＡＳ１５２）のＮＡＦ＿ＩＤを含んだ鍵要求を、ＩＳＩＭマネージャ２０７経由でリモートＩＳＩＭクライアント２０８へ送信する。

ステップＳ１３０３で、ＵＰｎＰＣＰ４０１は、ＩＳＩＭ−ＩＤ及びＮＡＦ＿ＩＤを含んだアクション要求"Get NAF Key ()"をＵＰｎＰＩＳＩＭサービス４０３へ送信する。

ステップＳ１３０４−Ｓ１３０９で、リモートＩＳＩＭサーバ２０４は、ＩＳＩＭマネージャ２０２及びＩＳＩＭ２０１からＢ−ＴＩＤ及びKs_(ext)_NAFを引き出す。なお、図１３はＧＢＡ＿Ｕの場合を描写している。ＧＢＡ＿ＭＥの場合、ＩＳＩＭマネージャ２０２がＢ−ＴＩＤを維持管理するので、ステップＳ１３０５−Ｓ１３０６は不要である。更に、ステップＳ１３０７−Ｓ１３０８では、ＩＳＩＭマネージャ２０２は、Ks_ext_NAFの代わりにＣｋ及びＩｋをＩＳＩＭ２０１から引き出し、Ｃｋ及びＩｋに基づいてKs_NAFを算出する。

ステップＳ１３１０で、ＵＰｎＰＩＳＩＭサービス４０３は、Ｂ−ＴＩＤ、Ks_(ext)_NAF、及びその存続期間を、ＵＰｎＰＣＰ４０１へ返す。なお、ステップＳ１３０３及びＳ１３１０における通信は、ペアリングプロセス（図１０参照）の結果として確立されたＴＬＳセッションを介して実行される。

ステップＳ１３１１−Ｓ１３１２で、ＩＰＴＶクライアント２０５は、ＩＳＩＭマネージャ２０７経由でリモートＩＳＩＭクライアント２０８から、ステップＳ１３０１の要求に対する応答としてＢ−ＴＩＤ及びKs_(ext)_NAFを受信する。

ステップＳ１３１３で、ＩＰＴＶクライアント２０５は、Ks_(ext)_NAFを使用してＩＰＴＶＡＳ１５２とセキュリティの関係（例えば、ＰＳＫＴＬＳセッション）をセットアップし、これにより、ＩＰＴＶＡＳ１５２との暗号化された通信を実行する。ＩＰＴＶＡＳ１５２は、セキュリティの関係の交渉中にＩＰＴＶクライアント２０５から受信したＢ−ＴＩＤと、ＮＡＦ＿ＩＤとを含んだ、鍵材料要求をＢＳＦ１１１へ送信することにより、Ks_(ext)_NAFを取得する。ＢＳＦ１１１が鍵材料要求を受信すると、ＢＳＦ１１１はKs_(ext)_NAFを生成し、これをＩＰＴＶＡＳ１５２へ返す。

いくつかの実施形態では、ＩＰＴＶＡＳ１５２は、例えば３ＧＰＰＴＳ３３．２４６Ｖ７．２．０により知られているような、スマートカードベースのサービス保護を実装してもよい。ここでは説明の目的で３ＧＰＰＭＢＭＳ（３ＧＰＰＴＳ３３．２４６Ｖ７．２．０）において規定される用語を使用するが、この実施形態は３ＧＰＰＭＢＭＳに限定されない。

より具体的には、ＩＰＴＶＡＳ１５２は最初に、ＭＢＭＳリクエストキー（ＭＲＫ）を用いてＩＰＴＶクライアント２０５を認証し、他方、ＩＰＴＶクライアント２０５は、ＩＰＴＶＡＳ１５２に対して登録する。登録成功後、ＩＰＴＶＡＳ１５２は、ＭＢＭＳトラヒックキー（ＭＴＫ）を使用してコンテンツを暗号化し、ＭＢＭＳサービスキー（ＭＳＫ）を使用してＭＴＫを暗号化し、ＭＢＭＳユーザキー（ＭＵＫ）に相当するKs_(ext)_NAFを使用してＭＳＫを暗号化する。次いで、ＩＰＴＶＡＳ１５２は、暗号化されたコンテンツをＩＰＴＶクライアント２０５へ送信する。ＩＰＴＶＡＳ１５２は、暗号化されたコンテンツがＩＰＴＶクライアント２０５へ送信される間に、暗号化されたＭＴＫをMultimedia Internet Keying（ＭＩＫＥＹ）メッセージの中に埋め込むことにより暗号化されたＭＴＫを配信し、また、ＩＰＴＶクライアント２０５がＭＳＫを要求した後、又はＩＰＴＶＡＳ１５２がＭＳＫの更新の時であると判断したときに、ＭＩＫＥＹメッセージを使用してＩＰＴＶクライアント２０５へ暗号化されたＭＳＫを配信する。

図１４は、ＩＰＴＶクライアント２０５が暗号化されたＭＴＫを引き出してコンテンツを復号できるようにする手順を示す。この目的で、ＩＳＩＭマネージャ２０７は、図１４に示すようにＩＰＴＶ鍵マネージャ（ＫＭ）１４０１を有する。ＩＰＴＶＫＭ１４０１は、３ＧＰＰＴＳ３３．２４６Ｖ７．２．０に規定されるＭＧＶ−Ｓ／Ｆに類似したエンティティである。それゆえ当業者は、以下の説明を参照すればＩＰＴＶＫＭ１４０１をどのように実装するかを理解できるであろう。

ステップＳ１４０１−Ｓ１４０２で、ＩＰＴＶクライアント２０５は、ＭＲＫ要求メッセージを、ＩＳＩＭマネージャ２０７経由でＩＰＴＶＫＭ１４０１へ送信する。

ステップＳ１４０３で、ＩＰＴＶＫＭ１４０１は、目的のＩＭＳＡＳ（即ち、ＩＰＴＶＡＳ１５２）のＮＡＦ＿ＩＤを含んだ鍵要求を、リモートＩＳＩＭクライアント２０８へ送信する。

次いで、ＵＰｎＰＣＰ４０１は、図１３のステップＳ１３０３−Ｓ１３１０で説明したのと同じやり方で、Ｂ−ＴＩＤ、Ks_(ext)_NAF、及びその存続期間をＵＰｎＰＩＳＩＭサービス４０３から引き出す。

ステップＳ１４０４で、リモートＩＳＩＭクライアント２０８は、Ks_(ext)_NAF、及びその存続期間をＩＰＴＶＫＭ１４０１へ返す。

ステップＳ１４０５で、ＩＰＴＶＫＭ１４０１は、Ks_(ext)_NAFをＭＵＫと見做し、Ks_(ext)_NAFからＭＲＫを導出する。

ステップＳ１４０６−Ｓ１４０７で、ＩＰＴＶＫＭ１４０１は、ＩＳＩＭマネージャ２０７経由でＩＰＴＶクライアント２０５へＭＲＫを送信する。

ステップＳ１４０８で、ＩＰＴＶクライアント２０５は、ＩＰＴＶＡＳ１５２に登録する。このとき、ＩＰＴＶクライアント２０５は、ＩＰＴＶＡＳ１５２に対してＭＲＫを用いて認証される。

ステップＳ１４０８での登録後、ステップＳ１４０９−Ｓ１４１８で、ＩＰＴＶクライアント２０５はＭＳＫ更新メッセージ及びＭＴＫ更新メッセージを定期的に受信する。ＩＰＴＶクライアント２０５は、ＭＳＫ更新メッセージ及びＭＴＫ更新メッセージをＩＰＴＶＫＭ１４０１へ送信する。ＩＰＴＶＫＭ１４０１は、Ks_(ext)_NAFを使用してＭＳＫ更新メッセージを復号することによりＭＳＫを取得し、ＭＳＫを使用してＭＴＫ更新メッセージを復号することによりＭＴＫを取得し、ＭＴＫをＩＰＴＶクライアント２０５へ送信する。

その結果、ステップＳ１４１９で、ＩＰＴＶクライアント２０５は、ＩＰＴＶＡＳ１５２からの暗号化されたコンテンツをＭＴＫを使用して復号することができる。

上述のように、３ＧＰＰＭＢＭＳによれば、サービスの保護を強化するために様々な鍵が使用される。しかしながら、重要なことは、ＩＰＴＶＡＳ１５２が所与の暗号鍵を使用してコンテンツを暗号化し、その所与の暗号鍵もまた暗号化されて、暗号化されたコンテンツと共にＩＰＴＶクライアント２０５へ送信され、ＩＰＴＶクライアント２０５はＩＰＴＶＫＭ１４０１がKs_(ext)_NAFを持っている場合にその所与の暗号鍵を復号できるということである。従って、理解すべきこととして、当業者はサービスの保護に関するコンセプトから逸脱することなしに、図１４の手順を修正（典型的には、単純化）することができるはずである。

＜発明の利点＞
本発明は次の点で利点がある。即ち、ＩＭＳＵＥはＩＭＳ加入情報を持つＵＰｎＰネットワーク内の利用可能なホストデバイス（換言すれば、ＩＳＩＭアプリケーション又はＵＳＩＭアプリケーションを持つ利用可能なホストデバイス）を動的に発見することができ、そのホストデバイスによって維持管理されているＩＭＳ加入情報を使用してＩＭＳベースのサービスを受けることができるので、ユーザは自分自身のＵＩＣＣをＩＭＳＵＥに挿入する負担から解放される。更に、ＩＭＳＵＥはＵＩＣＣスロットを備える必要がなく、それゆえ、ＩＭＳＵＥの複雑さ及びコストを削減することができる。

更に、本発明は、ＩＭＳＵＥが、ＩＭＳベースのサービスに関連する暗号化通信のために使用される暗号鍵（例えば、Ks_(ext)_NAF）を効率的に取得することができるという点で、便利である。

典型的な実施形態を参照して本発明を説明してきたが、理解すべきこととして、本発明は開示された典型的な実施形態には限定されない。以下の請求項の範囲には、そのような全ての修正、及び、均等な構造及び機能を包含するように、最も広い解釈が与えられる。

Claims

ＩＭＳユーザ装置（ＵＥ）（１０１）であって、
ＵＰｎＰ技術に基づいて、ＵＰｎＰネットワークの中から、ＩＭＰＩ及び何らかのＩＭＳベースのサービスに関連付けられたＩＭＰＵを含むＩＭＳ加入情報と、ブートストラッピングサーバ機能（ＢＳＦ）を介してＩＭＳネットワーク内のＩＭＳアプリケーションサーバ（ＡＳ）と共有される第１の暗号鍵と、を提供するように構成されるＵＰｎＰサービス（４０３）を持つホストデバイスを検索する検索手段（４０１）と、
前記ホストデバイスから、前記ホストデバイスが維持管理するＩＭＳ加入情報のリストを受信する受信手段（４０１）と、
前記リストの中からＩＭＳ加入情報を選択する選択手段（４０１）と、
前記検索手段によって発見されたホストデバイスとのセッションを確立する確立手段（２０８，４０１）であって、前記選択されたＩＭＳ加入情報に対応する第２の暗号鍵を使用して前記セッションを暗号化する確立手段（２０８，４０１）と、
前記セッションを介して前記ホストデバイスの前記ＵＰｎＰサービスから前記選択されたＩＭＳ加入情報を引き出す加入情報引き出し手段（４０１）と、
前記引き出されたＩＭＳ加入情報を使用して前記ＩＭＳネットワークに登録する登録手段（２０６）と、
前記セッションを介して前記ホストデバイスへ前記ＩＭＳＡＳのＩＤを送信することにより、前記第１の暗号鍵を、前記セッションを介して前記ホストデバイスの前記ＵＰｎＰサービスから引き出す鍵引き出し手段（４０１）と、
前記第１の暗号鍵を使用して前記ＩＭＳＡＳと暗号化通信を実行する通信手段（２０５）と、
を備える、ＩＭＳＵＥ。
前記確立手段は、
前記ホストデバイスから鍵サーバ（９０１）のＩＤと前記選択手段により選択されたＩＭＳ加入情報に対応するブートストラップ・トランザクションＩＤ（Ｂ−ＴＩＤ）とを受信し、
前記Ｂ−ＴＩＤを使用して、前記鍵サーバから前記ホストデバイスと共有される前記第２の暗号鍵を受信する、
請求項１に記載のＩＭＳＵＥ。
前記ＩＭＳ加入情報は、前記ホストデバイス内のＩＳＩＭアプリケーション（２０１）の中で維持管理される、
請求項１又は２に記載のＩＭＳＵＥ。
前記ＩＭＳＡＳは、ＩＰＴＶＡＳ（１５２）である、
請求項１乃至３のいずれか１項に記載のＩＭＳＵＥ。
前記第１の暗号鍵は、Ks_(ext)_NAFである、
請求項１乃至４のいずれか１項に記載のＩＭＳＵＥ。
ＩＭＳユーザ装置（ＵＥ）（１０１）の制御方法であって、
ＵＰｎＰ技術に基づいて、ＵＰｎＰネットワークの中から、ＩＭＰＩ及び何らかのＩＭＳベースのサービスに関連付けられたＩＭＰＵを含むＩＭＳ加入情報と、ブートストラッピングサーバ機能（ＢＳＦ）を介してＩＭＳネットワーク内のＩＭＳアプリケーションサーバ（ＡＳ）と共有される第１の暗号鍵と、を提供するように構成されるＵＰｎＰサービス（４０３）を持つホストデバイスを検索するステップ（Ｓ４０１−Ｓ４０６）と、
前記ホストデバイスから、前記ホストデバイスが維持管理するＩＭＳ加入情報のリストを受信するステップ（Ｓ５０２，Ｓ５０４）と、
前記リストの中からＩＭＳ加入情報を選択するステップ（Ｓ７０１）と、
前記検索するステップにおいて発見されたホストデバイスとのセッションを確立するステップ（Ｓ１０１４）であって、前記選択されたＩＭＳ加入情報に対応する第２の暗号鍵を使用して前記セッションを暗号化するステップ（Ｓ１０１４）と、
前記セッションを介して前記ホストデバイスの前記ＵＰｎＰサービスから前記選択されたＩＭＳ加入情報を引き出すステップ（Ｓ１２０１，Ｓ１２０３）と、
前記引き出されたＩＭＳ加入情報を使用して前記ＩＭＳネットワークに登録するステップ（Ｓ１２０４，Ｓ１２０８）と、
前記セッションを介して前記ホストデバイスへ前記ＩＭＳＡＳのＩＤを送信することにより、前記第１の暗号鍵を、前記セッションを介して前記ホストデバイスの前記ＵＰｎＰサービスから引き出すステップ（Ｓ１３０３，Ｓ１３１０）と、
前記第１の暗号鍵を使用して前記ＩＭＳＡＳと暗号化通信を実行するステップ（Ｓ１３１３）と、
を備える、制御方法。
前記確立するステップは、
前記ホストデバイスから鍵サーバ（９０１）のＩＤと前記選択するステップにおいて選択されたＩＭＳ加入情報に対応するブートストラップ・トランザクションＩＤ（Ｂ−ＴＩＤ）とを受信し、
前記Ｂ−ＴＩＤを使用して、前記鍵サーバから前記ホストデバイスと共有される前記第２の暗号鍵を受信する、
請求項６に記載の制御方法。
前記ＩＭＳ加入情報は、前記ホストデバイス内のＩＳＩＭアプリケーション（２０１）の中で維持管理される、
請求項６又は７に記載の制御方法。
前記ＩＭＳＡＳは、ＩＰＴＶＡＳ（１５２）である、
請求項６乃至８のいずれか１項に記載の制御方法。
前記第１の暗号鍵は、Ks_(ext)_NAFである、
請求項６乃至９のいずれか１項に記載の制御方法。
ホストデバイス（１０２）であって、
前記ホストデバイスがメモリ（１０３）の中で維持管理するＩＭＳ加入情報であってＩＭＰＩ及び何らかのＩＭＳベースのサービスに関連付けられたＩＭＰＵを含むＩＭＳ加入情報のリストを、ＵＰｎＰ技術に基づいて、ＩＭＳユーザ装置（ＵＥ）へ送信するリスト送信手段（４０３）と、
ＵＰｎＰ技術に基づいて、前記ＩＭＳＵＥとのセッションを確立する確立手段（４０３）であって、前記ＩＭＳＵＥにより前記リストの中から選択されたＩＭＳ加入情報に対応する第２の暗号鍵を使用して前記セッションを暗号化する確立手段（４０３）と、
前記メモリ（１０３）から前記選択されたＩＭＳ加入情報を引き出す加入情報引き出し手段（２０２）と、
ＵＰｎＰ技術に基づいて、前記セッションを介して前記ＩＭＳＵＥへ前記引き出されたＩＭＳ加入情報を送信する加入情報送信手段（４０３）と、
ＵＰｎＰ技術に基づいて、前記セッションを介して前記ＩＭＳＵＥから、ＩＭＳネットワーク内のＩＭＳアプリケーションサーバ（ＡＳ）のＩＤを受信するＩＤ受信手段（４０３）と、
前記ＩＭＳＡＳの前記ＩＤに基づいて、ブートストラッピングサーバ機能（ＢＳＦ）を介して前記ＩＭＳＡＳと共有される第１の暗号鍵を引き出す鍵引き出し手段（２０２）と、
ＵＰｎＰ技術に基づいて、前記セッションを介して前記ＩＭＳＵＥへ前記第１の暗号鍵を送信する鍵送信手段（４０３）と、
を備える、ホストデバイス。
前記確立手段は、
前記ＩＭＳＵＥへ鍵サーバ（９０１）のＩＤを送信し、
前記鍵サーバの前記ＩＤに基づいて、前記ＩＭＳＵＥと共有される前記第２の暗号鍵を算出する、
請求項１１に記載のホストデバイス。
前記ＩＭＳ加入情報は、前記メモリ内に格納されるＩＳＩＭアプリケーション（２０１）の中で維持管理される、
請求項１１又は１２に記載のホストデバイス。
前記ＩＭＳＡＳは、ＩＰＴＶＡＳ（１５２）である、
請求項１１乃至１３のいずれか１項に記載のホストデバイス。
前記第１の暗号鍵は、Ks_(ext)_NAFである、
請求項１１乃至１４のいずれか１項に記載のホストデバイス。
ホストデバイス（１０２）の制御方法であって、
前記ホストデバイスがメモリ（１０３）の中で維持管理するＩＭＳ加入情報であってＩＭＰＩ及び何らかのＩＭＳベースのサービスに関連付けられたＩＭＰＵを含むＩＭＳ加入情報のリストを、ＵＰｎＰ技術に基づいて、ＩＭＳユーザ装置（ＵＥ）へ送信するステップ（Ｓ５０２，Ｓ５０４）と、
ＵＰｎＰ技術に基づいて、前記ＩＭＳＵＥとのセッションを確立するステップ（Ｓ１０１４）であって、前記ＩＭＳＵＥにより前記リストの中から選択されたＩＭＳ加入情報に対応する第２の暗号鍵を使用して前記セッションを暗号化するステップ（Ｓ１０１４）と、
前記メモリ（１０３）から前記選択されたＩＭＳ加入情報を引き出すステップ（Ｓ１２０２）と、
ＵＰｎＰ技術に基づいて、前記セッションを介して前記ＩＭＳＵＥへ前記引き出されたＩＭＳ加入情報を送信するステップ（Ｓ１２０３）と、
ＵＰｎＰ技術に基づいて、前記セッションを介して前記ＩＭＳＵＥから、ＩＭＳネットワーク内のＩＭＳアプリケーションサーバ（ＡＳ）のＩＤを受信するステップ（Ｓ１３０３）と、
前記ＩＭＳＡＳの前記ＩＤに基づいて、ブートストラッピングサーバ機能（ＢＳＦ）を介して前記ＩＭＳＡＳと共有される第１の暗号鍵を引き出すステップ（Ｓ１３０４−Ｓ１３０９）と、
ＵＰｎＰ技術に基づいて、前記セッションを介して前記ＩＭＳＵＥへ前記第１の暗号鍵を送信するステップ（Ｓ１３１０）と、
を備える、制御方法。
前記確立するステップは、
前記ＩＭＳＵＥへ鍵サーバ（９０１）のＩＤを送信し、
前記鍵サーバの前記ＩＤに基づいて、前記ＩＭＳＵＥと共有される前記第２の暗号鍵を算出する、
請求項１６に記載の制御方法。
前記ＩＭＳ加入情報は、前記メモリ内に格納されるＩＳＩＭアプリケーション（２０１）の中で維持管理される、
請求項１６又は１７に記載の制御方法。
前記ＩＭＳＡＳは、ＩＰＴＶＡＳ（１５２）である、
請求項１６乃至１８のいずれか１項に記載の制御方法。
前記第１の暗号鍵は、Ks_(ext)_NAFである、
請求項１６乃至１９のいずれか１項に記載の制御方法。