鍵情報を配信する方法及び装置
アプリケーションサーバとアクセスドメインを介して通信ネットワークにアクセスするユーザ機器との間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵をアプリケーションサーバに配信する方法。方法は、ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするためにユーザ機器とホームドメインとの間でＡＫＡ（Authentication and Key Agreement）手順を実行することを有する。鍵材料の少なくとも一部は、ユーザ機器とアクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために使用され、１つ以上のアプリケーション鍵は、鍵材料の少なくとも一部を使用してホームドメイン内で導出される。アプリケーション鍵はアプリケーションサーバに提供され、同一のアプリケーション鍵がユーザ機器において導出される。この場合、アクセスエンフォースメントポイントはアプリケーション鍵を導出できないか又はアプリケーション鍵に対するアクセス権を有することができない。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、鍵情報を配信する方法及び装置に関し、特に、サービスに関連する鍵情報を配信する方法及び装置に関するが、必ずしもそのような方法及び装置に関連しなくてもよい。本発明は、特に、ユーザ機器に対して無線アクセスを容易にするユニバーサル移動通信システムネットワークを含む通信システムにおける鍵情報の配布に適用可能であるが、必ずしもそのような配布に適用されなくてもよい。
【背景技術】
【０００２】
第３世代パートナーシッププロジェクト（３ＧＰＰ）は、ＧＳＭ発展型コアネットワーク及び無線アクセス技術であるＵＴＲＡ（Universal Terrestrial Radio Access）に基づく第３世代移動システムに関する世界的に適用可能な技術仕様の標準化を目的として、多くの規格本体をまとめる提携協定として形成された。
【０００３】
３ＧＰＰは、ユニバーサル移動通信システム（ＵＭＴＳ）ネットワークにおいて認証及びセッション鍵の配布を実行するＡＫＡ（Authentication and Key Agreement）として知られるプロトコルを規定した。ＵＭＴＳ ＡＫＡは3GPP TS.33.102において規定され、対称暗号法を使用するチャレンジレスポンス方式の機構である。通常、ＡＫＡはＵＳＩＭ（UMTS Services Identity Module）において実行する。ＵＳＩＭは、共有秘密の改竄を防止するように格納するスマートカードに類似するデバイス（Universal Integrated Circuit Card又はＵＩＣＣと呼ばれる）上に常駐する。ＡＫＡは、ユーザ機器（ＵＥ−この場合、ＵＥは移動局（ＭＳ）とＵＳＩＭとの組み合わせとして定義される）をホームネットワークに登録及び再登録する際に実行される。ＡＫＡは２Ｇネットワーク（すなわちＧＳＭ）において採用されてもよく、その場合、ＵＩＣＣにはＵＳＩＭ及びＳＩＭ（Subscriber Identity Module）アプリケーションの双方が提供される。更に、次世代アーキテクチャ（現在標準化が行われているＬＴＥ（Long Term Evolution）アーキテクチャを含む）はＡＫＡ又はＡＫＡに基づくセキュリティプロトコルを使用する可能性が高い。
【０００４】
ＵＭＴＳ ＡＫＡの重要な目的の１つは、ユーザ機器（ＵＥ）と、アクセスポリシーがＵＭＴＳアクセスネットワーク内で実行されるエンフォースメントポイント（ＥＰ）との間のリンクにおいてデータのセキュリティ保護を提供することである。音声通話等の回路交換接続の場合、このＥＰは無線ネットワークコントローラ（ＲＮＣ）内にあり、パケット交換接続の場合、ＥＰはサービングゲートウェイサポートノード（ＳＧＳＮ）内にある。ＧＳＭネットワークの場合、ＥＰは基地局トランシーバ（ＢＴＳ）内にある。ＬＴＥネットワークにおいては、例えば、ＥＰはユーザプレーンエンティティ（ＵＰＥ）内にあってもよく、この場合、複数のＥＰが単一の接続に対して存在することもある。ＡＫＡは、ＵＥ上のＵＳＩＭとホームロケーションレジスタ（ＨＬＲ）／認証センタ（ＡｕＣ）との間で共有される秘密Ｋを使用して生成される鍵材料をアクセスネットワークに配信することにより、適切なセキュリティレベルを達成する。尚、ＩＰマルチメディアサブシステム機能性によって高性能化されたＨＬＲ／ＡＵＣはホーム加入者サーバ（ＨＳＳ）と呼ばれる。
【０００５】
パケット交換アクセスネットワークを考慮して、ＡＫＡに関連付けられる信号伝送を図１に示す。図１において、ＵＥ（ＵＳＩＭとＭＥとの組み合わせ）がアクセスネットワーク内のＳＧＳＮにアタッチ（接続）要求を送信することにより処理は開始される。次に、ＳＧＳＮはＵＥのホームネットワーク内のＨＳＳに認証ベクトル（ＡＶ）を要求し、ＨＳＳは認証センタ（ＡｕＣ）にＡＶを要求する。図１はパケット交換ドメインのみを示すが、回路交換ドメインにおいては訪問先ロケーションレジスタ（ＶＬＲ：Visited Location Register）がＳＧＳＮの機能に対応する機能を実行することが理解されるだろう。以下の説明において「ＳＧＳＮ」を参照する場合、回路交換ドメインにおいてはＶＬＲが等価な機能性を提供することが理解されるだろう。
【０００６】
ＵＭＴＳ ＡＫＡの実行の結果、２つの鍵、すなわち暗号鍵（ＣＫ）及び秘匿鍵（ＩＫ）が得られる。ＣＫ及びＩＫは、ＨＳＳとＵＥのＵＳＩＭとの間で共有される秘密及びランダム値ＲＡＮＤに基づいてＨＳＳにおいて生成される。ＨＳＳは、共有秘密及びランダム値に適切な関数を適用することにより、期待される結果ＸＲＥＳを更に生成する。鍵はＲＡＮＤ値、ＸＲＥＳ及び認証トークン（ＡＵＴＮ）と共に、ＨＳＳによってＳＧＳＮへ送信される。ＳＧＳＮはＲＡＮＤ値及びＡＵＴＮ値をＵＥに転送し、ＵＥにおいてこれらの値はＵＳＩＭに配信される。更に、ＳＧＳＮは鍵ＣＫ及びＩＫをＳＧＳＮ内のエンフォースメント機能に渡す。ＵＳＩＭはＨＳＳを認証し、それによってホームネットワークとＥＰとの間の信頼関係をＡＵＴＮ値を使用して確認する。更に、ＵＳＩＭは、ＲＡＮＤ値及び共有秘密を使用して鍵ＣＫ及びＩＫを生成する。鍵ＣＫ及びＩＫに基づいて、セキュアトンネルがＳＧＳＮ内のＥＰとＵＥとの間に確立される。これはアクセスネットワーク、特にエアインタフェースを介する通信をセキュリティ保護する。ＵＳＩＭは、共有秘密及びＲＡＮＤ値を使用して結果ＲＥＳを更に生成し、これをＳＧＳＮに返送する。ＳＧＳＮはＲＥＳとＸＲＥＳとを比較し、２つが一致する場合、トラフィックはセキュアトンネルを介して流れることを許可される。
【０００７】
多くの場合、特定のアプリケーション（すなわちサービス）をＵＥに提供するには、ＵＥがアプリケーションサーバに対して認証されること及びＵＥとアプリケーションサーバとの間にサービス又はアプリケーションの配信を実行する際に介するセキュアチャネルが確立されることが必要である。例えば、移動テレビサービスを配信する場合を想定してもよい。この場合、媒体はサービスに加入した（及びサービスに対して支払いを行った）ユーザに対してのみ配信されなければならない。
【０００８】
３ＧＰＰ技術仕様書TS33.220は、いわゆる汎用ブートストラッピングアーキテクチャ（ＧＢＡ）を規定する。ＧＢＡは、ＡＫＡ手順（この手順は、ＵＥの登録時又は再登録時に実行される初期ＡＫＡ処理とは区別される必要がある）の再実行中に取得される鍵ＣＫ及びＩＫに基づいて、クライアント端末（ＵＥ）がネットワーク認証機能（ＮＡＦ）、すなわちサービスノード又はサービスプロバイダと、ＵＥとＮＡＦとの間で使用するために取得されるセキュアセッション鍵（Ｋｓ＿ＮＡＦ）とに対して認証される機構を提供する。ブートストラッピングサーバ機能（ＢＳＦ）はＵＥのホームネットワークに導入され、ＡＫＡの再実行はＵＥとＢＳＦとの間で行なわれる。
【０００９】
ＧＢＡアーキテクチャの単純なネットワークモデルを図２に概略的に示す。ブートストラッピング手順が必要であることをＵＥが知っている場合、最初に、ＵＥはｈｔｔｐダイジェストＡＫＡ手順（ＲＦＣ３３１０）を使用してＢＳＦと共にブートストラッピング認証を実行する。鍵ＣＫ及びＩＫはＵＥとＢＳＦとの間で一致する（これらの鍵は、登録又は再登録の際に一致し且つ無線リンクをセキュリティ保護するために使用される鍵とは区別される必要がある）。更に、ＢＳＦは、特有のブートストラッピングトランザクション識別子（Ｂ−ＴＩＤ）をＵＥに提供する。ＵＥ及びＮＡＦがＢＳＦからセッション鍵を取得することを希望する場合、ＵＥはＢ−ＴＩＤをＮＡＦに配信し、ＮＡＦはそれをＢＳＦに転送する。Ｂ−ＴＩＤは、ＢＳＦがＵＥを識別し且つ適切なＮＡＦ専用鍵（Ｋｓ＿ＮＡＦ）を取得するために使用する指標を含む。その後、ＮＡＦ専用鍵はＮＡＦに転送される。鍵材料の寿命は、ＢＳＦのローカルポリシーに従って設定される。
【００１０】
ＡＫＡ及びＧＢＡの双方は、いわゆるＩＰマルチメディアコアネットワークサブシステム（ＩＭＳ）に対して及びその内部でセキュリティを提供するために採用される。ＩＭＳは、移動通信ネットワークを介してＩＰマルチメディアサービスを提供するために第３世代パートナーシッププロジェクト（３ＧＰＰ）により定義される技術である（3GPP TS22.228、TS23.228、TS24.229、TS29.228、TS29.229、TS29.328及びTS29.329、Release 5及びRelease 6）。ＩＭＳは、サービスの統合及び対話を介してエンドユーザの個人対個人の通信体験を豊かにするために鍵特徴を提供する。ＩＭＳによって、ＩＰ系ネットワークを介する新しい豊富な個人対個人（クライアント対クライアント）の通信及び個人対コンテンツ（クライアント対サーバ）の通信が可能になる。ＩＭＳは、ユーザ端末間（又はユーザ端末とアプリケーションサーバとの間）の通話又はセッションを設定及び制御するためにセッション開始プトロコル（ＳＩＰ）を利用する。ＳＩＰ信号伝送により実行されるセッション記述プロトコル（ＳＤＰ）は、セッションの媒体構成要素の記述及び交渉に使用される。ＳＩＰはユーザ対ユーザプロトコルとして作成されたが、ＩＭＳによって、オペレータ及びサービスプロバイダはサービスに対するユーザのアクセスを制御し、それによってユーザに課金することができる。
【００１１】
図３は、ＧＰＲＳ／ＰＳアクセスネットワークの場合にＩＭＳが移動ネットワークアーキテクチャに適合する方法を概略的に示す。コール／セッション制御機能（ＣＳＣＦ）は、ＩＭＳとのＳＩＰプロキシとして動作する。３ＧＰＰアーキテクチャは、ＳＩＰ端末に対するＩＭＳ内の第１の接触点であるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、ユーザが加入しているサービスをユーザに提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）、及び問合せＣＳＣＦ（Ｉ−ＣＳＣＦ）の３種類のＣＳＣＦを定義する。Ｉ−ＣＳＣＦの役割は、正しいＳ−ＣＳＣＦを識別し、ＳＩＰ端末からＰ−ＣＳＣＦを介して受信される要求をそのＳ−ＣＳＣＦに転送することである。
【００１２】
ユーザは、指定されたＳＩＰ登録方法を使用してＩＭＳに登録する。これは、ＩＭＳにアタッチし、ＳＩＰユーザアイデンティティに到達するアドレスをＩＭＳに通知する機構である。３ＧＰＰにおいて、ＳＩＰ端末が登録を実行する場合、ＩＭＳはユーザを認証し、使用可能なＳ−ＣＳＣＦの組から１つのＳ−ＣＳＣＦをそのユーザに割り当てる。Ｓ−ＣＳＣＦの割り当てに関する基準は３ＧＰＰにより規定されていないが、これらは負荷分割及びサービス要件を含んでもよい。尚、Ｓ−ＣＳＣＦの割り当ては、ＩＭＳに基づくサービスに対するユーザのアクセスを制御する（及びそのようなアクセスに対して課金する）ための重要な点である。オペレータは、ユーザ対ユーザの直接のＳＩＰセッションを防止する機構を提供してもよく、その機構がない場合にはそれらセッションはＳ−ＣＳＣＦを迂回するだろう。
【００１３】
登録処理中、Ｓ−ＣＳＣＦが既に選択されていない場合はＩ−ＣＳＣＦがＳ−ＣＳＣＦを選択しなければならない。Ｉ−ＣＳＣＦは、ホームネットワークのホーム加入者サーバ（ＨＳＳ）から必要なＳ−ＣＳＣＦ機能を受信し、受信した機能に基づいて適切なＳ−ＣＳＣＦを選択する。尚、ユーザが別の人により呼び出され且つユーザが現時点でＳ−ＣＳＣＦを割り当てられていない場合にも、Ｓ−ＣＳＣＦの割り当てはＩ−ＣＳＣＦによってユーザ対して実行される。その後、登録ユーザがＩＭＳにセッション要求を送信する場合、Ｐ−ＣＳＣＦは、登録処理中にＳ−ＣＳＣＦから受信した情報に基づいて、選択されたＳ−ＣＳＣＦにその要求を転送できる。
【００１４】
全てのＩＭＳユーザは１つ以上の個人ユーザアイデンティティを所有する。個人アイデンティティはホームネットワークオペレータにより割り当てられ、例えば、登録、認証、許可及び課金のためにＩＭＳによって使用される。このアイデンティティは、ＲＦＣ２４８６［１４］に定義されるようなネットワークアクセス識別子（ＮＡＩ）の形態をとる。国際移動電話加入者識別番号（ＩＭＳＩ）の表現は個人アイデンティティのためのＮＡＩに含まれてもよい。個人ユーザアイデンティティに加えて、全てのＩＭＳユーザは１つ以上の公開ユーザアイデンティティを有する。公開ユーザアイデンティティは、任意のユーザが他のユーザとの通信を要求するために使用される。例えば、ユーザは名刺に公開ユーザアイデンティティを含んでもよい（但し、個人ユーザアイデンティティは含まない）。
【００１５】
図４において、ＩＭＳ認証手順を非常に高いレベルで説明する。ＵＥ内において、ＡＫＡはＩＳＩＭ（IP Multimedia Services Identity Module）により処理される。ＡＫＡプロトコルは、Ｓ−ＣＳＣＦに対するユーザ機器（ＵＥ）の認証及びＵＥに対するＳ−ＣＳＣＦの認証を実行する。これは、上述のＡＫＡ処理に類似する。認証ベクトル（ＡＶ）はＳ−ＣＳＣＦにより取得され、Ｉ−ＣＳＣＦを介してＰ−ＣＳＣＦに配信される。図５は、ＧＢＡがＩＭＳアーキテクチャにマッピングされる方法を示す。この場合、ＢＳＦ機能性はＳ−ＣＳＣＦにおいて実現され、Ｐ−ＣＳＣＦはＳ−ＣＳＣＦとＵＥとの間に位置する。ＥＰはＰ−ＣＳＣＦ内に存在する。これは、ETSI TISPAN working group proposal 07-TD-17において考察される。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
上述したように、ＧＢＡは、アプリケーション／サービス専用（ＮＡＦ）鍵を生成するために使用される新規の鍵材料（ＣＫ、ＩＫ）を確立するためにＡＫＡ手順を再実行する。これは、セッションのセットアップ時間を増加し、帯域幅を浪費し、ＵＥにおいて及びネットワーク内での２つの異なる手順の規定及び実行を必要とする。初期ＡＫＡ手順において生成された鍵材料がＧＢＡ手順により再利用され、それによってＡＫＡの再実行の必要性を回避する機構を実現することは効率的である。
【００１７】
当然、初期鍵材料を使用してアプリケーション／サービス専用（ＮＡＦ）鍵を生成することは可能である。しかしながら、図１から明らかになるように、初期鍵材料はＥＰに対して使用可能になる。従って、ＥＰは、ＵＥとアプリケーション／サービスプロバイダとの間で交換されたトラフィックを導出された鍵情報を使用して復号化でき、アプリケーション／サービスプロバイダに対してＵＥを装うこともできる。多くの場合において、ＥＰは信頼ノード（ＵＥのホームドメインにより信頼される）であるが、ＥＰが常に信頼ノードであるわけではなく（例えば、「ローミング」の例において）、信頼を想定することはできない。これはＩＭＳの場合（図４を参照）も同様に当てはまる。ＩＭＳの場合、ホーム（ＩＭＳ）ネットワークにより必ずしも信頼されるとは限らないＰ−ＣＳＣＦは、初期鍵材料を使用可能である。
【００１８】
本発明の目的は、ユーザ機器とアクセスネットワークとの間のトラフィックをセキュリティ保護するために使用される鍵とアプリケーション／サービス配信に使用される鍵との間で鍵を厳密に分離できるアプリケーション／サービス鍵配信手順を提供することである。
【課題を解決するための手段】
【００１９】
本発明の第１の面によると、アプリケーションサーバとアクセスドメインを介して通信ネットワークにアクセスするユーザ機器との間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵をアプリケーションサーバに配信する方法であって、
ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするためにユーザ機器とホームドメインとの間でＡＫＡ（Authentication and Key Agreement）手順を実行し、ユーザ機器とアクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために鍵材料の少なくとも一部を使用する工程と、
鍵材料の少なくとも一部を使用してホームドメイン内で１つ以上のアプリケーション鍵を導出し、アプリケーション鍵をアプリケーションサーバに提供し、ユーザ機器において同一のアプリケーション鍵を導出する工程と、
を有し、
アクセスエンフォースメントポイントはアプリケーション鍵を導出できないか又はアプリケーション鍵に対するアクセス権を有することができないことを特徴とする方法が提供される。
【００２０】
本明細書で使用される用語「ユーザ機器」は、特定のプロトコル又はネットワークアーキテクチャに限定されない。ユーザ機器は、ユーザ端末とSubscriber Identity Moduleカードとの組み合わせであってもよく、又はユーザ端末のみであってもよい。本発明の機能性は、ユーザ端末上のみで実現されてもよく、又はユーザ端末とSubscriber Identity Moduleカードとの組み合わせ上で実現されてもよい。
【００２１】
ＡＫＡ手順の実行は、ユーザ機器をホームドメインに登録又は再登録する際に行われるのが好ましい。これは、加入者を登録することによりアクセス保護を確立するため及びアプリケーション鍵が導出される鍵材料を確立するための双方のために、手順を一度だけ実行する必要があるという利点を有する。
【００２２】
アクセスエンフォースメントポイントを介するドメインアクセスは、アクセスエンフォースメントポイントコントローラにより制御されるのが好ましい。ユーザ機器とホームドメインとの間でＡＫＡ手順を実行する工程は、ランダム値を含む認証ベクトルとランダム値から導出可能な２次暗号鍵及び２次秘匿鍵とをホームドメインからアクセスエンフォースメントポイントコントローラへ送信し、ランダム値をユーザ機器に転送することを含む。ユーザ機器は、その後、１次暗号鍵及び１次秘匿鍵を生成するために第１の鍵導出関数をランダム値に適用し、２次暗号鍵及び２次秘匿鍵を生成するために第２の鍵導出関数を１次暗号鍵及び１次秘匿鍵に適用する。２次暗号鍵及び２次秘匿鍵は、アクセスエンフォースメントポイントコントローラによりアクセスエンフォースメントポイントに渡され、セキュアトンネルは、２次暗号鍵及び２次秘匿鍵に基づいてアクセスエンフォースメントポイントとユーザ機器との間に確立される。この場合、鍵材料はランダム値と２次暗号鍵及び２次秘匿鍵とを含む。
【００２３】
アプリケーション鍵は、１次暗号鍵及び１次秘匿鍵のうちの一方又は双方を使用して、ユーザ機器及びホームドメインにおいて導出されるのが好ましい。
【００２４】
本発明の一実施形態において、鍵材料は、第１のランダム値及び第２のランダム値と第１のランダム値から導出可能な第１の暗号鍵及び第１の秘匿鍵とを含み、方法は、ランダム値をアクセスエンフォースメントポイントコントローラからユーザ機器に転送する工程を有し、ユーザ機器は、第１の暗号鍵及び第１の秘匿鍵を生成するために第１の鍵導出関数を第１のランダム値に適用し、それによって、セキュアトンネルは、第１の暗号鍵及び第１の秘匿鍵に基づいてアクセスエンフォースメントポイントとユーザ機器との間に確立される。
【００２５】
アプリケーション鍵は、第２のランダム値を使用してユーザ機器において及びホームドメイン内で導出されてもよい。
【００２６】
方法は、第２のランダム値から第２の暗号鍵及び第２の秘匿鍵を導出し、その後、アプリケーション鍵を生成するために鍵導出関数を第２の暗号鍵及び第２の秘匿鍵に適用する工程を有してもよい。
【００２７】
ホームドメイン内及びユーザ機器においてアプリケーション鍵を導出する工程は、鍵材料の少なくとも一部からアプリケーションサービス鍵を導出するために、ホームドメインとユーザ機器との間で共有される秘密を利用する工程を有してもよい。
【００２８】
アプリケーションサービス鍵は、鍵導出関数を暗号鍵及び秘匿鍵とサービスノード識別子とに適用することにより導出されてもよい。
【００２９】
アクセスエンフォースメントポイントは、ＩＰマルチメディアサブシステム（ＩＭＳ）のプロキシコールセッション制御機能（Ｐ−ＣＳＣＦ）内に提供されてもよい。アクセスエンフォースメントポイントコントローラは、プロキシコールセッション制御機能内に更に提供されてもよい。ホームドメイン内において、サービングコールセッション制御機能（Ｓ−ＣＳＣＦ）は、ＡＫＡ手順をホーム加入者サーバと関連して処理する役割を有する。
【００３０】
アクセスエンフォースメントポイント及びアクセスエンフォースメントポイントコントローラは、２Ｇ又は３ＧネットワークのサービングＧＰＲＳサポートノード（ＳＧＳＮ）内にあってもよい。回路交換ドメインの場合、アクセスエンフォースメントポイントは無線ネットワークコントローラ内にあってもよく、この場合、アクセスエンフォースメントポイントコントローラはビジターロケーションレジスタ内にある。
【００３１】
アクセスネットワークがLong Term Evolution（ＬＴＥ）アクセスネットワークを含む場合、アクセスエンフォースメントポイントは、ユーザプレーンエンティティ（ＵＰＥ）／移動性管理エンティティ（ＭＭＥ）／ｅＮｏｄｅＢであってもよく、アクセスエンフォースメントポイントコントローラはＭＭＥである。尚、これは３ＧＰＰにおいて暫定的にのみ決定されている。
【００３２】
ユーザ証明書管理サーバは、ホーム加入者サーバとアクセスエンフォースメントポイントコントローラとの間に設けられてもよい。このサーバの役割は、２次暗号鍵及び２次秘匿鍵を導出すること及び要求時にアプリケーション鍵をアプリケーションサーバに提供することである。
【００３３】
本発明の第２の面によると、アプリケーションサーバとアクセスドメインを介して通信ネットワークにアクセスするユーザ機器との間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵をアプリケーションサーバに配信するネットワーク系装置であって、
ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするためにユーザ機器と共にＡＫＡ手順を実行し、それによって、ユーザ機器とアクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために鍵材料の少なくとも一部が使用される手段と、
鍵材料の少なくとも一部を使用して１つ以上のアプリケーション鍵を導出し、アプリケーション鍵をアプリケーションサーバに提供し、鍵材料によってユーザ機器はアプリケーション鍵を同様に導出できるがアクセスエンフォースメントポイントは鍵を導出できない手段と、
を具備することを特徴とする装置が提供される。
【００３４】
本発明の第３の面によると、アクセスドメインを介して通信ネットワークにアクセスするユーザ機器であって、
ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするためにホームドメインと共にＡＫＡ手順を実行し、ユーザ機器とアクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために鍵材料の少なくとも一部を使用する手段と、
鍵材料の少なくとも一部を使用して１つ以上のアプリケーション鍵を導出し、アプリケーションサーバとの通信トンネルをセキュリティ保護するためにアプリケーション鍵を使用する手段と、
を具備することを特徴とするユーザ機器が提供される。
【００３５】
本発明の第４の面によると、アプリケーションサーバとアクセスドメインを介して通信ネットワークにアクセスするユーザ機器との間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵をアプリケーションサーバに配信する方法であって、
ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするためにユーザ機器とホームドメインとの間でＡＫＡ手順を実行し、ユーザ機器とアクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために鍵材料の少なくとも一部を使用する工程と、
鍵材料の少なくとも一部を使用してアクセスエンフォースメントポイントにおいて１つ以上のアプリケーション鍵を導出し、アプリケーション鍵をアプリケーションサーバに提供し、ユーザ機器において同一のアプリケーション鍵を導出する工程と、
を有することを特徴とする方法が提供される。
【発明を実施するための最良の形態】
【００３６】
本発明の他の面は添付の請求の範囲において特定される。
【００３７】
２Ｇ／３Ｇコアネットワークアクセス及びＩＭＳアクセスドメインの双方の場合において、ＡＫＡプロトコル及びＧＢＡプロコルを図１〜図５を参照して上述した。最初にＩＭＳの場合において、次にＳＡＥ／ＬＴＥ高性能３Ｇネットワークの場合において、ＡＫＡの再実行を必要とせずにＧＢＡを実現できる機構を以下に説明する。
【００３８】
図４を参照して既に上述したように、セキュアＩＰｓｅｃトンネルは、暗号鍵ＣＫ及び秘匿鍵ＩＫに基づいて、ユーザ機器（ＵＥ）とＰ−ＣＳＣＦとの間に確立される。Ｓ−ＣＳＣＦが更なる鍵ＣＫ’及びＩＫ’を以下のように導出する場合を以下に考察する。
【００３９】
ＣＫ’＝ＫＤＦ(ＣＫ,P_CSCF_ID)
ＩＫ'＝ＫＤＦ(ＩＫ,P_CSCF_ID)
式中、ＫＤＦは鍵導出関数（例えば、ＧＢＡに対して定義されるような関数）である。Ｓ−ＣＳＣＦは、ＣＫ及びＩＫをＰ−ＣＳＣＦに提供するのではなく、導出された鍵ＣＫ’及びＩＫ’をＩＰｓｅｃトンネルに対して使用する鍵として提供する。しかしながら、Ｓ−ＣＳＣＦによりＰ−ＣＳＣＦを介してＵＥに提供されるＲＡＮＤ値は、１次鍵ＣＫ及びＩＫを生成するのに使用されたＲＡＮＤ値のままである。従って、ＵＥは、関数ＫＤＦと導出された鍵ＣＫ’及びＩＫ’とを使用してＣＫ及びＩＫを生成できる。
【００４０】
詳細な処理のステップを図６に示す。
・ＵＥはＳＩＰ Ｒｅｇｉｓｔｅｒ（ＳＩＰレジスタ）をＳ−ＣＳＣＦへ送信する。
・Ｓ−ＣＳＣＦは、認証ベクトルＡＶ＝（ＲＡＮＤ、ＣＫ、ＩＫ、ＸＲＥＳ、ＡＵＴＮ）をＨＳＳから取り出す。
・Ｓ−ＣＳＣＦは、例えば以下のような任意のＫＤＦを使用して、２つの新規の鍵ＣＫ’及びＩＫ’をそれぞれＣＫ及びＩＫから導出する。
ＣＫ’＝ＫＤＦ(ＣＫ,P_CSCF_ID)
ＩＫ'＝ＫＤＦ(ＩＫ,P_CSCF_ID)
・Ｓ−ＣＳＣＦは、Ｐ−ＣＳＣＦに対する新規の特別なＡＶ’＝（ＲＡＮＤ、ＣＫ’、ＩＫ’、ＸＲＥＳ、ＡＵＴＮ）を作成する。
・Ｐ−ＣＳＣＦはＡＶ’を受信し、ＲＡＮＤ／ＡＵＴＮをＵＥに転送する（このステップを図６に丸１で示す）。
・ＵＥはＲＡＮＤ／ＡＵＴＮを受信し、このタプルをＩＳＩＭを介して実行する。この動作の結果、ＵＥはＩＳＩＭからＣＫ及びＩＫを取り戻す。ここで、ＵＥは、ＣＫ’及びＩＫ’を計算するために、Ｓ−ＣＳＣＦにより使用されたのと同一のＫＤＦを適用する。このステップを図中に丸２で示す。
・ＵＥ及びＰ−ＣＳＣＦは、ＣＫ’及びＩＫ’に基づいてＩＰｓｅｃトンネルを確立する。
・図中に丸３で示すステップにおいて、ＵＥは、通信を希望する特定のＮＡＦに対するサービス専用鍵Ｋｓ＿ＮＡＦを導出する。これは、先に使用されたものと潜在的に同一のＫＤＦをＣＫ、ＩＫ及びＮＡＦ＿ＩＤに適用することにより実行されてもよい。あるいは、Ｋｓ＿ＮＡＦは、例えば以下のように、ＫＤＦを鍵ＣＫ”及びＩＫ”とＮＡＦ＿ＩＤとに適用することにより導出される：
ＣＫ"＝ＫＤＦ(ＣＫ,＜some GBA ID＞,＜other param＞)
ＩＫ"＝ＫＤＦ(ＩＫ,＜some GBA ID＞,＜other param＞)
ＣＫ”及びＩＫ”を導出する理由は、ＮＡＦがＵＥとＮＡＦとの間で使用されるセキュリティプロトコルに対する別個の秘匿鍵及び暗号化鍵を有することを希望する場合があるからである。その場合、ＮＡＦはＣＫ”及びＩＫ”を直接使用できる。＜some GBA ID＞パラメータは、高性能ＧＢＡシステムを識別するＩＤであり（例えば、文字列「eGBA」又は文字列「eGBA@operator.com」）、生成された鍵をこの特定の鍵配布システムに結び付けるため及び潜在的な鍵の衝突を回避するために使用される。
・その後、ＵＥはＮＡＦに接触し、ＩＭＳ登録の結果生じたＣＫ／ＩＫを一意に識別するアイデンティティをＮＡＦに提供する。このアイデンティティは（ＧＢＡにおいては）Ｂ−ＴＩＤと呼ばれ、ＡＫＡ手順中にＢＳＦからＵＥに提供される。すなわち、このアイデンティティは、（ＡＫＡが実行される場合は）ＩＭＳ登録手順中にＳ−ＣＳＣＦにより提供される。
・ＮＡＦはＳ−ＣＳＣＦに接触し、所定のＢ−ＴＩＤに対応するＫｓ＿ＮＡＦを要求する。
・Ｓ−ＣＳＣＦは、ＵＥが行なったのと同一の方法でＣＫ及びＩＫからＫｓ＿ＮＡＦを導出する。Ｓ−ＣＳＣＦは、Ｋｓ＿ＮＡＦをＮＡＦに返送する。例えば、Ｋｓ_NAF＝ＫＤＦ(ＣＫ",ＩＫ",NAF_ID,＜other param＞)である。
・この時点で、ＵＥ及びＮＡＦは、Ｋｓ＿ＮＡＦに基づいてセキュア接続を確立できる。
【００４１】
この処理を実現するには、Ｓ−ＣＳＣＦに対する変更及び場合によってはより重大なＵＥに対する変更が必要である。この変更は、ある特定のＵＥがＧＢＡ処理により提供される追加の機能性を利用することを要求しない場合であっても必要である。これは、従来のＵＥに対する単なるソフトウェアのアップグレードを含んでもよいが、更新が面倒な場合がある。この問題は、別の処理を実現することにより回避される。これは、ＲＡＮＤ／ＡＵＴＮの第２の対（すなわち、ＲＡＮＤ’及びＡＵＴＮ’）を初期ＩＭＳ ＡＫＡ交換に含むことを伴う。このように、ＵＥ及びＳ−ＣＳＣＦは、２組の共有鍵（ＣＫ、ＩＫ及びＣＫ’、ＩＫ’）を確立できる。第１の鍵の組はＰ−ＣＳＣＦとＵＥとの間にＩＰｓｅｃトンネルを確立するのに使用され、第２の組はＩＭＳアプリケーションサーバに対する鍵を導出するのに使用される。この別の処理を図７に示す。ＵＥが高性能ＧＢＡ機能性をサポートしない従来のＵＥの場合、ＵＥはＲＡＮＤ’値及びＡＵＴＮ’値を単に参照しないか又は無視し、ＲＡＮＤ及びＡＵＴＮのみを通常通り処理する。
【００４２】
詳細な処理ステップは以下の通りである：
・ＵＥは、ＳＩＰ ＲｅｇｉｓｔｅｒをＳ−ＣＳＣＦへ送信する。
・Ｓ−ＣＳＣＦは、ＡＶ＝（ＲＡＮＤ、ＣＫ、ＩＫ、ＸＲＥＳ、ＡＵＴＮ）及びＡＶ’＝（ＲＡＮＤ’、ＣＫ’、ＩＫ’、ＸＲＥＳ’、ＡＵＴＮ’）をＨＳＳから取り出す。
・Ｓ−ＣＳＣＦは、ＡＶ及びＡＶ’をＰ−ＣＳＣＦへ送信する。
・Ｐ−ＣＳＣＦはＡＶ及びＡＶ’を受信し、ＲＡＮＤ／ＡＵＴＮ及びＲＡＮＤ’／ＡＵＴＮ’をＵＥに転送する（このステップを図７に丸１で示す）。
・ＵＥはＲＡＮＤ／ＡＵＴＮ及びＲＡＮＤ’／ＡＵＴＮ’を受信し、ＩＳＩＭを介してＲＡＮＤ／ＡＵＴＮを実行する。この動作の結果、ＵＥはＩＳＩＭからＣＫ及びＩＫを取り戻す。ＵＥは、ＣＫ及びＩＫを使用してＰ−ＣＳＣＦとのＩＰｓｅｃトンネルを確立する。ＵＥはＩＳＩＭを介してＲＡＮＤ’／ＡＵＴＮ’を実行し、その結果、ＩＳＩＭからＣＫ’及びＩＫ’を取り戻す。このステップを図中に丸２で示す。
・図中に丸３で示すステップにおいて、ＵＥは、通信を希望する特定のＮＡＦに対するサービス専用鍵Ｋｓ＿ＮＡＦを導出する。これは、ＫＤＦをＣＫ’、ＩＫ’及びＮＡＦ＿ＩＤに適用することにより実行される。
・ＵＥはＮＡＦに接触し、ＩＭＳ登録の結果生じたＣＫ’／ＩＫ’を一意に識別するアイデンティティ（例えばＢ−ＴＩＤ）をＮＡＦに提供する。
・ＮＡＦはＳ−ＣＳＣＦに接触し、所定のＢ−ＴＩＤに対応するＫｓ＿ＮＡＦを要求する。
・Ｓ−ＣＳＣＦは、ＵＥが行なったのと同一の方法でＣＫ’及びＩＫ’からＫｓ＿ＮＡＦを導出する。Ｓ−ＣＳＣＦはＫｓ＿ＮＡＦをＮＡＦに返送する。
・この時点で、ＵＥ及びＮＡＦは、Ｋｓ＿ＮＡＦに基づいてセキュア接続を確立できる。
【００４３】
この別の方法も、高性能機能性が動作するためにＳ−ＣＳＣＦに対する変更を必要とするが、ＲＡＮＤ’／ＡＵＴＮ’は、従来のＵＥがネットワーク内で依然として機能できるように、すなわち、Ｐ−ＣＳＣＦとのセキュアトンネルを確立できるように、初期ＩＭＳ ＡＫＡに含まれる。例えば、ＲＡＮＤ’／ＡＵＴＮ’は、従来のＵＥによって認識されない（従って、無視される）新規のＳＩＰヘッダ内に存在してもよい。当然、従来のＵＥは、ＲＡＮＤ’／ＡＵＴＮ’の組から導出される鍵を必要とするアプリケーションサーバに依然としてアクセスできない。
【００４４】
更に別の処理において、アプリケーションサービス鍵は、従来のＩＭＳ ＡＫＡ処理、すなわち図４に示すような処理に従い且つ結果として得られる鍵ＣＫ／ＩＫをＫＤＦを使用して後処理することにより導出される。これは、Ｓ−ＣＳＣＦ及びＵＥのみが知る更なる引数、すなわち共有秘密をＫＤＦに含むことにより達成される。この場合も、Ｐ−ＣＳＣＦはアプリケーションサービス鍵を導出できない。例えば、ＫＤＦの一部（又は全部）は、ＵＥ内のソフトＳＩＭ、あるいはＵＥによりアクセスされるスマートカード内の新規又は既存のＳＩＭアプリケーションとして実現される。ＫＤＦは、例えば、通常のＳＩＭアプリケーションをサブ機能として含むことができる。ネットワークの観点から、共有秘密は認証センタ（ＡｕＣ）に格納される。これは、認証ベクトルを導出するために使用されるものと潜在的に同一の共有秘密である。これは、特定の関数（関数はＡｕＣの一部であってもよく、又はＳ−ＣＳＣＦにより供給されてもよい）を介して所定のＲＡＮＤを実行した結果をＡｕＣに要求できることを必要とする。また、共有秘密は、Ｓ−ＣＳＣＦからの所定のＲＡＮＤに対して関数を計算するためのクエリに応答する他の任意のデータベースに格納されてもよい。
【００４５】
前の段落で説明した鍵導出ステップが通常のＩＭＳ登録の後に実行される場合、この解決策は従来のＵＥに影響を与えないが、当然、従来のＵＥはアプリケーションサービス鍵を導出できない。しかしながら、ＵＥにおいて及びＩＭＳ内で重大な変更が必要とされるため、この別の処理は必ずしも最適ではない。
【００４６】
Ｓ−ＣＳＣＦは、登録中に受信される公開ユーザアイデンティティに基づいてアプリケーションサービス鍵の使用を制限してもよい。Ｓ−ＣＳＣＦは、このために現在のＩＭＳ加入処理機構を再使用できる。ユーザがＩＭＳに登録する場合、ユーザは１つ以上の公開アイデンティティを登録してもよく、そのうちのいくつかは禁止アイデンティティ（限定的な使用の場合以外は許可されない）として分類されてもよい。更に、Ｓ−ＣＳＣＦは、アプリケーションサーバ（Ｓ−ＣＳＣＦがＡＳ鍵を要求するアプリケーションサーバ）から受信するアイデンティティと禁止アイデンティティとを比較することにより、禁止アイデンティティが高性能ＧＢＡにより使用されないことを保証できる。当然、Ｓ−ＣＳＣＦは、他のサービスに対するユーザのアクセス権とは関係なく、高性能ＧＢＡ機能性を所定のユーザ又は公開ユーザアイデンティティに対して許可するため又は許可しないためにローカルポリシーを適用してもよい。
【００４７】
上述の方法は、アプリケーションサーバ（ＮＡＦ）がＳ−ＣＳＣＦのアイデンティティを知っており且つＳ−ＣＳＣＦと通信可能であると想定する。これは、アプリケーションサーバがＳ−ＣＳＣＦと同一のネットワーク内に位置する場合に当てはまる。しかしながら、これが当てはまらないこともあり、アプリケーションサーバは、例えば、Ｐ−ＣＳＣＦと同一の訪問先ネットワーク内に位置してもよい。この場合、Ｐ−ＣＳＣＦは訪問先ネットワーク内のＡＳに対してＢＳＦ機能性を有してもよい。これを図８に示す。訪問先ネットワーク内のＡＳは、ＡＳ鍵を入手するために、Ｐ−ＣＳＣＦに接触するか又はローカルＳ−ＣＳＣＦ（非ローミングユーザの場合）に接触するかを判定できなければならない。ＡＳは、ＵＥにより与えられるＳＩＰ ＵＲＩ／ＩＭＰＵ又はＢ−ＴＩＤ（Ｂ−ＴＩＤはＵＥのホームオペレータの名称を含む）に基づいてこの判定を行うことができる。ＵＥのホームオペレータは、ＧＢＡ鍵（ＣＫ及びＩＫ）をＰ−ＣＳＣＦに配布するか否かを選択することにより、訪問先ＡＳに対してローミングを許可するかを決定できる。図９は、この場合のメッセージの流れを示す。この第１の例の場合、２次鍵（ＣＫ”、ＩＫ”）の導出はＰ−ＣＳＣＦ内でローカルに行なわれる。最初に、ＵＥとＰ−ＣＳＣＦとの間のＩＰｓｅｃトンネルをセキュリティ保護するために、ＣＫ’及びＩＫ’が導出される：
ＣＫ’＝ＫＤＦ(ＣＫ,ＵＥ＿ＩＤ)
ＩＫ'＝ＫＤＦ(ＩＫ,ＵＥ＿ＩＤ)
次に、ＣＫ”及びＩＫ”が導出される：
ＣＫ"＝ＫＤＦ(ＣＫ,ＧＢＡ−ＩＤ,＜other param＞)
ＩＫ"＝ＫＤＦ(ＩＫ,ＧＢＡ−ＩＤ,＜other param＞)
ＣＫ”及びＩＫ”は、ＡＳ鍵を（ＡＳ−ＳＥＲＶ−ＩＤを用いて）導出するために使用される。
【００４８】
別個のクインテットがアクセスセキュリティ及びＧＢＡに対して使用される場合、図１０に詳細に示す処理になる。尚、この場合、ＣＫ”及びＩＫ”はＰ−ＣＳＣＦに配布され、Ｐ−ＣＳＣＦは訪問先ネットワーク内の異なるローカルＡＳに対するアプリケーションサービス（ＡＳ）鍵を導出できる。
【００４９】
ＩＭＳにおける本発明の手順の実現は、以下に示す利点の１つ以上を提供してもよい：・サービス鍵を確立するためにＧＢＡが本質的に必要ではないことによる実現の複雑性の低減、並びにＵＥ、アプリケーションサーバ及びＨＳＳにより必要とされるインタフェースの数の減少。
・セキュアＩＭＳサービスが確立される前に必要な往復処理の数の減少。
・個別のサービスの鍵の間の厳密な鍵の分離。
・アクセス保護鍵とサービス鍵との暗号化による分離。
・ＩＭＳシステムによる他のアプリケーションサービスの厳密なポリシー制御。
・ＩＭＳアクセスとサービスアクセスとの相関性。
・アプリケーションサービスアクセスを許可するための追加のインフラストラクチャ要素又は追加のインタフェースの必要性の回避。
・アプリケーションサービスに対する透過性（Ｚｎインタフェースが影響を受けないような）。
【００５０】
本発明の手順の適用はＩＭＳに限定されない。図１１は、現在考えられているＳＥＡ／ＬＴＥ（System Architecture Evolution/Long Term Evolution）アクセスネットワークを用いて高性能化される３Ｇネットワークのシステム構成要素を概略的に示す。従来のネットワークにおけるユーザの認証は、パケット交換ドメイン内のＳＧＳＮ及び回路交換ドメイン内のＶＬＲによって処理される。移行の観点から、ＳＧＳＮ／ＶＬＲが新規の特徴を実現する必要がないことが重要である。従って、インタフェース「Ｂ」及び「Ｃ」を介するプロトコルは変更されていない。従って、Ｂインタフェースは、ＨＬＲとＳＧＳＮ／ＶＬＲとの間の現在のインタフェースと同一である。新規のアクセスネットワークにおける認証は、鍵を必要とするネットワークエンティティに鍵を同様に配布する認証管理サーバ（ＡＭＳ）により処理される。図示するアーキテクチャの例において、鍵は、ユーザプレーン（ＵＰ）のデータ保護及び２種類の制御プレーン（ＣＰ１、ＣＰ２）のデータ保護のために、新規のアクセスネットワークを使用するＵＥ毎に必要とされる。
【００５１】
ユーザ証明書マネージャサーバ（ＵＣＭＳ：User Credential Manager Server）は、ＨＬＲ／ＡｕＣとＡＭＳとの間及びＨＬＲ／ＡｕＣと従来のＳＧＳＮ／ＶＬＲとの間に位置する新規のエンティティである。ＵＣＭＳはＢＳＦに類似する機能を実行し、提案される新規の機能性が使用される場合に、基本鍵を作成し、この鍵を使用してアクセスネットワークエンティティＡＭＳ及びＶＬＲが必要とする鍵を導出する。また、ＵＣＭＳ内のＢＳＦに類似する機能は、後段でＮＡＦとＵＥとの間にサービス鍵を確立するために、ＮＡＦに対するＺｎインタフェース実現する（任意の中間エンティティがＵＣＭＳの代わりにＺｎインタフェースを提供する場合を除く）。ＵＣＭＳは、従来のＳＩＭを使用する認証と新規の高性能ＵＳＩＭ（「ＸＳＩＭ」）が使用される場合とを区別する。ＸＳＩＭが使用される場合、ＡＭＳ又はＳＧＳＮ／ＶＬＲにＡＶ’を求める要求はＢＳＦに類似する機能性をトリガする。一方、従来のＳＩＭが使用される場合、ＵＣＭＳは透過的なエンティティとして動作し、ＡＭＳＳＧＳＮ／ＶＬＲとＨＬＲ／ＡｕＣとの間の要求及び応答を単に転送する。
【００５２】
認証要求（Ａｕｔｈ Ｒｅｑ：Authentication Request）がＵＣＭＳにより受信される場合を考察する。ＵＣＭＳは、要求がＸＳＩＭに関すると判定する。ＸＳＩＭが使用されることは、例えば、ＩＭＳＩの特別な範囲が使用される場合は加入者のＩＭＳＩから認識されてもよく、又はＨＬＲ／ＡｕＣからの応答において他の任意の方法、例えばＡＶの符号化で示されてもよい。ＵＣＭＳは、ＢＳＦが通常のＧＢＡトランザクションを処理するのと同様の方法でＡＶを処理する。ＵＣＭＳは、ＡＶ内のＣＫ及びＩＫから鍵Ｋｓを形成する。すなわち、ＣＫ’＝f(ＣＫ,ＩＫ)、ＩＫ'＝ｇ(ＣＫ,ＩＫ)、及びＫｓ＝ｈ(ＣＫ,ＩＫ)である。ただし、一方向関数ｆ、ｇ及びｈにおいて、ｆ!＝ｇ!＝ｈである。ＵＣＭＳはＫｓ及び関連するＢ−ＴＩＤを格納し、その後更なる暗号化鍵ＣＫ’及び秘匿鍵ＩＫ’を導出する。ＵＣＭＳはベクトル（ＲＡＮＤ、ＡＵＴＮ、ＣＫ’、ＩＫ’、ＸＲＥＳ）をＡＭＳ又はＳＧＳＮ／ＶＬＲに転送する。ＩＭＳの場合を参照して上述したように、ＡＭＳ又はＳＧＳＮ／ＶＬＲはＲＡＮＤ及びＡＵＴＮをＵＥに転送する。
【００５３】
端末側において、ＲＡＮＤ及びＡＵＴＮはＸＳＩＭに入力され、ＸＳＩＭはＣＫ及びＩＫのＧＢＡ導出を実行し、その後ＣＫ’及びＩＫ’のＧＢＡ導出を実行し、アクセスネットワークにおける保護に使用される他の任意の必要な鍵のＧＢＡ導出を実行する。ＣＫ’及びＩＫ’（並びに、他の任意の必要な鍵）はＭＥに配信される。ＫｓはＸＳＩＭに格納され、ＵＥがＧＢＡに基づく任意のサービスの使用を希望する場合、ＩＭＳの場合を参照して上述したように、ＮＡＦ専用鍵の更なる導出の基本となる。ＵＳＩＭはＲＥＳを生成し、これをＡＭＳ／ＶＬＲに返送する。ＡＭＳ／ＶＬＲは、この値がＸＲＥＳに一致することを確認する。一致する場合、ＡＭＳ／ＶＬＲは鍵ＣＫ’及びＩＫ’をＥＰに渡す。
【００５４】
ＵＥが現在のＵＭＴＳネットワークにおける情報の種類と同一種類の情報、すなわちＲＡＮＤ、ＡＵＴＮを受信すること及びＭＥとＸＳＩＭとの間のインタフェースがＲＥＬ−６インタフェースを使用してＲＡＮＤ、ＡＵＴＮを送信し且つ結果をサブセットとして受信することが理解されるだろう。これは、この機構を使用可能なＸＳＩＭを有するＲＥＬ−６ＵＥが依然として機能することを意味する。
【００５５】
図１２の信号フローは、ＵＥが認証及び鍵の確立の実行を希望する旨をネットワークに通知した後に行われる処理を示す。ＵＥが既にネットワークにアタッチされている場合、ネットワークは、同一の信号フローに従って再認証手順を開始してもよい。
【００５６】
処理ステップをより詳細に考察する。
【００５７】
ＡＭＳ又はＳＧＳＮ／ＶＬＲは、認証処理の結果をＵＣＭＳに通知してもよい。この信号伝送は図１２には示さないが、ホームネットワークがユーザの所在の記録を保持したい場合には必要である（これを以下に更に説明する）。加入者の現在のアタッチに関する情報がＨＬＲ内に保持される場合、ＵＣＭＳはＡＭＳ又はＳＧＳＮ／ＶＬＲからこの情報を受信する際にＨＬＲを更新してもよい。
【００５８】
上述の処理は、ＡｕＣ／ＨＬＲがＣＫ’及びＩＫ’を導出できるようにすることにより変更されてもよい。このエンティティは、ＣＫ’、ＩＫ’及びＫｓを含む拡張ＡＶ（ｅＡＶ）をＵＣＭＳに送信する。ＵＣＭＳではなくＡＭＳ／ＶＬＲがＣＫ’及びＩＫ’に対する鍵導出を実行することも可能である。しかしながら、これは、ＡＭＳ／ＶＬＲがＫｓ及びそれから導出される全てのＮＡＦ専用鍵を更に導出できることを意味する。ある特定の信頼モデルの下で、これは許容可能であってもよい。
【００５９】
場合によっては、ＵＣＭＳエンティティを組み込むネットワークアーキテクチャがＵＣＭＳエンティティを組み込まないアーキテクチャと共存しなければならない場合が考えられる。そのような移行フェーズにおいて、新規の鍵導出を実行する必要があるか否かを示す通知をネットワークがＸＳＩＭに信号伝送することは有利である。このような信号伝送が行われる複数の方法がある。このような信号伝送が行われる２つの方法を以下に示す。
【００６０】
１．ＡｕＣは、ＲＡＮＤ内の特定ビットを常に０に設定する（例えばＬＳＢとする）。ＵＣＭＳ内のＢＳＦ機能性は、新規の鍵導出が使用される場合はＬＳＢを１に設定し、通常の鍵導出が実行される場合はＬＳＢを０に設定する。ＸＳＩＭが（ＲＡＮＤ、ＡＵＴＮ）を受信すると、ＸＳＩＭはどちらの鍵導出が実行されるかを確認するためにＬＳＢを調べ、必要であればＬＳＢを０にリセットして続行する。しかしながら、この方法の問題は、「ハッキングされた」電話を所有する悪意のあるユーザが、ＲＡＮＤ、ＡＵＴＮをＸＳＩＭに渡す前にＲＡＮＤのＬＳＢを０に設定できることである。ＸＳＩＭは実際のＣＫ／ＩＫをＭＳに返送する。ユーザは、ネットワークにアクセスできるだけではなく、ＣＫ’及びＩＫ’を導出することもでき、従って、任意のサービスをセキュリティ保護するために使用されるＮＡＦ鍵を導出できる。
【００６１】
２．第２の方法は、例えば、偶数のシーケンス番号に基づく全てのＡＶが新規の鍵導出手順に使用され且つ奇数のシーケンス番号に基づく全てのＡＶが従来の鍵導出手順に使用されると指定することである。この方法の利点は、シーケンス番号がＡｕＣとＸＳＩＭとの間で共有される鍵Ｋによって保護される秘匿性である。従って、攻撃者は解決策１で挙げられた攻撃と同様の攻撃を実行できない。しかしながら、欠点は、新規の鍵導出又は従来の鍵導出のみを使用するＸＳＩＭの場合、シーケンス番号の空間の半分が浪費されることである。
【００６２】
加入者の認証が常にホームネットワークによって実行される場合、訪問先ネットワーク内のＡＭＳ又はＳＧＳＮ／ＶＬＲはホームネットワーク内のＵＣＭＳとＵＥとの間の中継点として使用される。これは、ＡＭＳ又はＳＧＳＮ／ＶＬＲがオーセンティケータを介する通路の役割を想定するような、すなわち、それらが認証トラフィックのみを中継するような拡張可能認証プロトコル（ＥＡＰ）ＡＫＡに非常に類似した動作になる。ＵＥがＵＣＭＳにより認証されると、ＵＣＭＳは鍵ＣＫ’及びＩＫ’のみをＡＭＳ又はＳＧＳＮ／ＶＬＲに転送する。ＵＣＭＳが、例えば、ＣＫ’＝ＫＤＦ("visited_NW_name",ＣＫ)及びＩＫ'＝ＫＤＦ("visited_NW_name",ＩＫ)によって、訪問先ネットワーク専用の鍵を導出することも可能である。これを図１３に示す。当然、ＣＫ’及びＩＫ’は、ＲＡＮＤ値及びＡＵＴＮ値と共に事前に送信される。
【００６３】
訪問先ネットワーク内で認証が行われる場合、ＢＳＦは、通常通り（図１２を参照）訪問先ネットワーク内のＡＭＳ又はＳＧＳＮ／ＶＬＲと単純に対話する。当然、ＵＣＭＳとＡＭＳ又はＳＧＳＮ／ＶＬＲとの間の信号伝送は機密性を保護されなければならない。
【００６４】
Ｓ−ＣＳＣＦに常駐するＢＳＦに類似する機能性とＵＣＭＳとが同一であるため、上述のＩＭＳ及びアクセスモデルは組み合わされてもよい。この場合、従来のＳ−ＣＳＣＦを変更する必要はない。しかしながら、Ｓ−ＣＳＣＦは通常のインタフェースをＨＳＳに対して実行するのではなく、このインタフェースをＵＣＭＳに対して実行する。共通のＵＣＭＳ機能は、別個のエンティティとしてＨＳＳにおいて実現されてもよく、又はＢＳＦと組み合わされてもよい。
【００６５】
本発明の範囲を逸脱せずに、上述の実施形態に対して種々の変形が実施されてもよいことが当業者には理解されるだろう。例えば、新規の機能性を実現するために高性能ＵＳＩＭ（すなわち、ＸＳＩＭ）を提供するのではなく、新規の機能性は、Ｋｓ及びＢ−ＴＩＤがＭＥに格納され且つＭＥが鍵導出を実行する高性能ＭＳにおいて実現されてもよい。
【図面の簡単な説明】
【００６６】
【図１】ユーザ機器とホームドメインとの間でアクセスネットワークを介して行なわれるパケットドメインにおけるＡＫＡ手順に関連付けられる信号伝送を示す図である。
【図２】ＧＢＡアーキテクチャを概略的に示す図である。
【図３】セルラ通信ネットワーク内のＩＰマルチメディアサブシステムアーキテクチャを概略的に示す図である。
【図４】ユーザ機器に対するＩＭＳ認証手順を示す図である。
【図５】汎用ＧＢＡアーキテクチャ及びＩＭＳにマッピングされたＧＢＡアーキテクチャを概略的に示す図である。
【図６】本発明の第１の実施形態に従って、ＵＥとＩＭＳのＮＡＦとの間で共有される鍵情報を確立する処理を示す図である。
【図７】本発明の第２の実施形態に従って、ＵＥとＩＭＳのＮＡＦとの間で共有される鍵情報を確立する処理を示す図である。
【図８】ＩＭＳのＰ−ＣＳＣＦにおけるＢＳＦ機能性の実現を示すブロック図である。
【図９】本発明の更なる実施形態に従って、ＵＥとＩＭＳのＮＡＦとの間で共有される鍵情報を確立する処理を示す図である。
【図１０】本発明の更に別の実施形態に従って、ＵＥとＩＭＳのＮＡＦとの間で共有される鍵情報を確立する処理を示す図である。
【図１１】ＳＡＥ／ＬＴＥアクセスネットワークを組み込んだ３Ｇネットワークを概略的に示す図である。
【図１２】図１１のネットワークにおいて認証がホームネットワークから訪問先ネットワークに委譲される初期鍵確立処理を示す図である。
【図１３】図１１のネットワークにおいて認証がホームネットワークを使用して実行される初期鍵確立処理を示す図である。
【技術分野】
【０００１】
本発明は、鍵情報を配信する方法及び装置に関し、特に、サービスに関連する鍵情報を配信する方法及び装置に関するが、必ずしもそのような方法及び装置に関連しなくてもよい。本発明は、特に、ユーザ機器に対して無線アクセスを容易にするユニバーサル移動通信システムネットワークを含む通信システムにおける鍵情報の配布に適用可能であるが、必ずしもそのような配布に適用されなくてもよい。
【背景技術】
【０００２】
第３世代パートナーシッププロジェクト（３ＧＰＰ）は、ＧＳＭ発展型コアネットワーク及び無線アクセス技術であるＵＴＲＡ（Universal Terrestrial Radio Access）に基づく第３世代移動システムに関する世界的に適用可能な技術仕様の標準化を目的として、多くの規格本体をまとめる提携協定として形成された。
【０００３】
３ＧＰＰは、ユニバーサル移動通信システム（ＵＭＴＳ）ネットワークにおいて認証及びセッション鍵の配布を実行するＡＫＡ（Authentication and Key Agreement）として知られるプロトコルを規定した。ＵＭＴＳ ＡＫＡは3GPP TS.33.102において規定され、対称暗号法を使用するチャレンジレスポンス方式の機構である。通常、ＡＫＡはＵＳＩＭ（UMTS Services Identity Module）において実行する。ＵＳＩＭは、共有秘密の改竄を防止するように格納するスマートカードに類似するデバイス（Universal Integrated Circuit Card又はＵＩＣＣと呼ばれる）上に常駐する。ＡＫＡは、ユーザ機器（ＵＥ−この場合、ＵＥは移動局（ＭＳ）とＵＳＩＭとの組み合わせとして定義される）をホームネットワークに登録及び再登録する際に実行される。ＡＫＡは２Ｇネットワーク（すなわちＧＳＭ）において採用されてもよく、その場合、ＵＩＣＣにはＵＳＩＭ及びＳＩＭ（Subscriber Identity Module）アプリケーションの双方が提供される。更に、次世代アーキテクチャ（現在標準化が行われているＬＴＥ（Long Term Evolution）アーキテクチャを含む）はＡＫＡ又はＡＫＡに基づくセキュリティプロトコルを使用する可能性が高い。
【０００４】
ＵＭＴＳ ＡＫＡの重要な目的の１つは、ユーザ機器（ＵＥ）と、アクセスポリシーがＵＭＴＳアクセスネットワーク内で実行されるエンフォースメントポイント（ＥＰ）との間のリンクにおいてデータのセキュリティ保護を提供することである。音声通話等の回路交換接続の場合、このＥＰは無線ネットワークコントローラ（ＲＮＣ）内にあり、パケット交換接続の場合、ＥＰはサービングゲートウェイサポートノード（ＳＧＳＮ）内にある。ＧＳＭネットワークの場合、ＥＰは基地局トランシーバ（ＢＴＳ）内にある。ＬＴＥネットワークにおいては、例えば、ＥＰはユーザプレーンエンティティ（ＵＰＥ）内にあってもよく、この場合、複数のＥＰが単一の接続に対して存在することもある。ＡＫＡは、ＵＥ上のＵＳＩＭとホームロケーションレジスタ（ＨＬＲ）／認証センタ（ＡｕＣ）との間で共有される秘密Ｋを使用して生成される鍵材料をアクセスネットワークに配信することにより、適切なセキュリティレベルを達成する。尚、ＩＰマルチメディアサブシステム機能性によって高性能化されたＨＬＲ／ＡＵＣはホーム加入者サーバ（ＨＳＳ）と呼ばれる。
【０００５】
パケット交換アクセスネットワークを考慮して、ＡＫＡに関連付けられる信号伝送を図１に示す。図１において、ＵＥ（ＵＳＩＭとＭＥとの組み合わせ）がアクセスネットワーク内のＳＧＳＮにアタッチ（接続）要求を送信することにより処理は開始される。次に、ＳＧＳＮはＵＥのホームネットワーク内のＨＳＳに認証ベクトル（ＡＶ）を要求し、ＨＳＳは認証センタ（ＡｕＣ）にＡＶを要求する。図１はパケット交換ドメインのみを示すが、回路交換ドメインにおいては訪問先ロケーションレジスタ（ＶＬＲ：Visited Location Register）がＳＧＳＮの機能に対応する機能を実行することが理解されるだろう。以下の説明において「ＳＧＳＮ」を参照する場合、回路交換ドメインにおいてはＶＬＲが等価な機能性を提供することが理解されるだろう。
【０００６】
ＵＭＴＳ ＡＫＡの実行の結果、２つの鍵、すなわち暗号鍵（ＣＫ）及び秘匿鍵（ＩＫ）が得られる。ＣＫ及びＩＫは、ＨＳＳとＵＥのＵＳＩＭとの間で共有される秘密及びランダム値ＲＡＮＤに基づいてＨＳＳにおいて生成される。ＨＳＳは、共有秘密及びランダム値に適切な関数を適用することにより、期待される結果ＸＲＥＳを更に生成する。鍵はＲＡＮＤ値、ＸＲＥＳ及び認証トークン（ＡＵＴＮ）と共に、ＨＳＳによってＳＧＳＮへ送信される。ＳＧＳＮはＲＡＮＤ値及びＡＵＴＮ値をＵＥに転送し、ＵＥにおいてこれらの値はＵＳＩＭに配信される。更に、ＳＧＳＮは鍵ＣＫ及びＩＫをＳＧＳＮ内のエンフォースメント機能に渡す。ＵＳＩＭはＨＳＳを認証し、それによってホームネットワークとＥＰとの間の信頼関係をＡＵＴＮ値を使用して確認する。更に、ＵＳＩＭは、ＲＡＮＤ値及び共有秘密を使用して鍵ＣＫ及びＩＫを生成する。鍵ＣＫ及びＩＫに基づいて、セキュアトンネルがＳＧＳＮ内のＥＰとＵＥとの間に確立される。これはアクセスネットワーク、特にエアインタフェースを介する通信をセキュリティ保護する。ＵＳＩＭは、共有秘密及びＲＡＮＤ値を使用して結果ＲＥＳを更に生成し、これをＳＧＳＮに返送する。ＳＧＳＮはＲＥＳとＸＲＥＳとを比較し、２つが一致する場合、トラフィックはセキュアトンネルを介して流れることを許可される。
【０００７】
多くの場合、特定のアプリケーション（すなわちサービス）をＵＥに提供するには、ＵＥがアプリケーションサーバに対して認証されること及びＵＥとアプリケーションサーバとの間にサービス又はアプリケーションの配信を実行する際に介するセキュアチャネルが確立されることが必要である。例えば、移動テレビサービスを配信する場合を想定してもよい。この場合、媒体はサービスに加入した（及びサービスに対して支払いを行った）ユーザに対してのみ配信されなければならない。
【０００８】
３ＧＰＰ技術仕様書TS33.220は、いわゆる汎用ブートストラッピングアーキテクチャ（ＧＢＡ）を規定する。ＧＢＡは、ＡＫＡ手順（この手順は、ＵＥの登録時又は再登録時に実行される初期ＡＫＡ処理とは区別される必要がある）の再実行中に取得される鍵ＣＫ及びＩＫに基づいて、クライアント端末（ＵＥ）がネットワーク認証機能（ＮＡＦ）、すなわちサービスノード又はサービスプロバイダと、ＵＥとＮＡＦとの間で使用するために取得されるセキュアセッション鍵（Ｋｓ＿ＮＡＦ）とに対して認証される機構を提供する。ブートストラッピングサーバ機能（ＢＳＦ）はＵＥのホームネットワークに導入され、ＡＫＡの再実行はＵＥとＢＳＦとの間で行なわれる。
【０００９】
ＧＢＡアーキテクチャの単純なネットワークモデルを図２に概略的に示す。ブートストラッピング手順が必要であることをＵＥが知っている場合、最初に、ＵＥはｈｔｔｐダイジェストＡＫＡ手順（ＲＦＣ３３１０）を使用してＢＳＦと共にブートストラッピング認証を実行する。鍵ＣＫ及びＩＫはＵＥとＢＳＦとの間で一致する（これらの鍵は、登録又は再登録の際に一致し且つ無線リンクをセキュリティ保護するために使用される鍵とは区別される必要がある）。更に、ＢＳＦは、特有のブートストラッピングトランザクション識別子（Ｂ−ＴＩＤ）をＵＥに提供する。ＵＥ及びＮＡＦがＢＳＦからセッション鍵を取得することを希望する場合、ＵＥはＢ−ＴＩＤをＮＡＦに配信し、ＮＡＦはそれをＢＳＦに転送する。Ｂ−ＴＩＤは、ＢＳＦがＵＥを識別し且つ適切なＮＡＦ専用鍵（Ｋｓ＿ＮＡＦ）を取得するために使用する指標を含む。その後、ＮＡＦ専用鍵はＮＡＦに転送される。鍵材料の寿命は、ＢＳＦのローカルポリシーに従って設定される。
【００１０】
ＡＫＡ及びＧＢＡの双方は、いわゆるＩＰマルチメディアコアネットワークサブシステム（ＩＭＳ）に対して及びその内部でセキュリティを提供するために採用される。ＩＭＳは、移動通信ネットワークを介してＩＰマルチメディアサービスを提供するために第３世代パートナーシッププロジェクト（３ＧＰＰ）により定義される技術である（3GPP TS22.228、TS23.228、TS24.229、TS29.228、TS29.229、TS29.328及びTS29.329、Release 5及びRelease 6）。ＩＭＳは、サービスの統合及び対話を介してエンドユーザの個人対個人の通信体験を豊かにするために鍵特徴を提供する。ＩＭＳによって、ＩＰ系ネットワークを介する新しい豊富な個人対個人（クライアント対クライアント）の通信及び個人対コンテンツ（クライアント対サーバ）の通信が可能になる。ＩＭＳは、ユーザ端末間（又はユーザ端末とアプリケーションサーバとの間）の通話又はセッションを設定及び制御するためにセッション開始プトロコル（ＳＩＰ）を利用する。ＳＩＰ信号伝送により実行されるセッション記述プロトコル（ＳＤＰ）は、セッションの媒体構成要素の記述及び交渉に使用される。ＳＩＰはユーザ対ユーザプロトコルとして作成されたが、ＩＭＳによって、オペレータ及びサービスプロバイダはサービスに対するユーザのアクセスを制御し、それによってユーザに課金することができる。
【００１１】
図３は、ＧＰＲＳ／ＰＳアクセスネットワークの場合にＩＭＳが移動ネットワークアーキテクチャに適合する方法を概略的に示す。コール／セッション制御機能（ＣＳＣＦ）は、ＩＭＳとのＳＩＰプロキシとして動作する。３ＧＰＰアーキテクチャは、ＳＩＰ端末に対するＩＭＳ内の第１の接触点であるプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、ユーザが加入しているサービスをユーザに提供するサービングＣＳＣＦ（Ｓ−ＣＳＣＦ）、及び問合せＣＳＣＦ（Ｉ−ＣＳＣＦ）の３種類のＣＳＣＦを定義する。Ｉ−ＣＳＣＦの役割は、正しいＳ−ＣＳＣＦを識別し、ＳＩＰ端末からＰ−ＣＳＣＦを介して受信される要求をそのＳ−ＣＳＣＦに転送することである。
【００１２】
ユーザは、指定されたＳＩＰ登録方法を使用してＩＭＳに登録する。これは、ＩＭＳにアタッチし、ＳＩＰユーザアイデンティティに到達するアドレスをＩＭＳに通知する機構である。３ＧＰＰにおいて、ＳＩＰ端末が登録を実行する場合、ＩＭＳはユーザを認証し、使用可能なＳ−ＣＳＣＦの組から１つのＳ−ＣＳＣＦをそのユーザに割り当てる。Ｓ−ＣＳＣＦの割り当てに関する基準は３ＧＰＰにより規定されていないが、これらは負荷分割及びサービス要件を含んでもよい。尚、Ｓ−ＣＳＣＦの割り当ては、ＩＭＳに基づくサービスに対するユーザのアクセスを制御する（及びそのようなアクセスに対して課金する）ための重要な点である。オペレータは、ユーザ対ユーザの直接のＳＩＰセッションを防止する機構を提供してもよく、その機構がない場合にはそれらセッションはＳ−ＣＳＣＦを迂回するだろう。
【００１３】
登録処理中、Ｓ−ＣＳＣＦが既に選択されていない場合はＩ−ＣＳＣＦがＳ−ＣＳＣＦを選択しなければならない。Ｉ−ＣＳＣＦは、ホームネットワークのホーム加入者サーバ（ＨＳＳ）から必要なＳ−ＣＳＣＦ機能を受信し、受信した機能に基づいて適切なＳ−ＣＳＣＦを選択する。尚、ユーザが別の人により呼び出され且つユーザが現時点でＳ−ＣＳＣＦを割り当てられていない場合にも、Ｓ−ＣＳＣＦの割り当てはＩ−ＣＳＣＦによってユーザ対して実行される。その後、登録ユーザがＩＭＳにセッション要求を送信する場合、Ｐ−ＣＳＣＦは、登録処理中にＳ−ＣＳＣＦから受信した情報に基づいて、選択されたＳ−ＣＳＣＦにその要求を転送できる。
【００１４】
全てのＩＭＳユーザは１つ以上の個人ユーザアイデンティティを所有する。個人アイデンティティはホームネットワークオペレータにより割り当てられ、例えば、登録、認証、許可及び課金のためにＩＭＳによって使用される。このアイデンティティは、ＲＦＣ２４８６［１４］に定義されるようなネットワークアクセス識別子（ＮＡＩ）の形態をとる。国際移動電話加入者識別番号（ＩＭＳＩ）の表現は個人アイデンティティのためのＮＡＩに含まれてもよい。個人ユーザアイデンティティに加えて、全てのＩＭＳユーザは１つ以上の公開ユーザアイデンティティを有する。公開ユーザアイデンティティは、任意のユーザが他のユーザとの通信を要求するために使用される。例えば、ユーザは名刺に公開ユーザアイデンティティを含んでもよい（但し、個人ユーザアイデンティティは含まない）。
【００１５】
図４において、ＩＭＳ認証手順を非常に高いレベルで説明する。ＵＥ内において、ＡＫＡはＩＳＩＭ（IP Multimedia Services Identity Module）により処理される。ＡＫＡプロトコルは、Ｓ−ＣＳＣＦに対するユーザ機器（ＵＥ）の認証及びＵＥに対するＳ−ＣＳＣＦの認証を実行する。これは、上述のＡＫＡ処理に類似する。認証ベクトル（ＡＶ）はＳ−ＣＳＣＦにより取得され、Ｉ−ＣＳＣＦを介してＰ−ＣＳＣＦに配信される。図５は、ＧＢＡがＩＭＳアーキテクチャにマッピングされる方法を示す。この場合、ＢＳＦ機能性はＳ−ＣＳＣＦにおいて実現され、Ｐ−ＣＳＣＦはＳ−ＣＳＣＦとＵＥとの間に位置する。ＥＰはＰ−ＣＳＣＦ内に存在する。これは、ETSI TISPAN working group proposal 07-TD-17において考察される。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
上述したように、ＧＢＡは、アプリケーション／サービス専用（ＮＡＦ）鍵を生成するために使用される新規の鍵材料（ＣＫ、ＩＫ）を確立するためにＡＫＡ手順を再実行する。これは、セッションのセットアップ時間を増加し、帯域幅を浪費し、ＵＥにおいて及びネットワーク内での２つの異なる手順の規定及び実行を必要とする。初期ＡＫＡ手順において生成された鍵材料がＧＢＡ手順により再利用され、それによってＡＫＡの再実行の必要性を回避する機構を実現することは効率的である。
【００１７】
当然、初期鍵材料を使用してアプリケーション／サービス専用（ＮＡＦ）鍵を生成することは可能である。しかしながら、図１から明らかになるように、初期鍵材料はＥＰに対して使用可能になる。従って、ＥＰは、ＵＥとアプリケーション／サービスプロバイダとの間で交換されたトラフィックを導出された鍵情報を使用して復号化でき、アプリケーション／サービスプロバイダに対してＵＥを装うこともできる。多くの場合において、ＥＰは信頼ノード（ＵＥのホームドメインにより信頼される）であるが、ＥＰが常に信頼ノードであるわけではなく（例えば、「ローミング」の例において）、信頼を想定することはできない。これはＩＭＳの場合（図４を参照）も同様に当てはまる。ＩＭＳの場合、ホーム（ＩＭＳ）ネットワークにより必ずしも信頼されるとは限らないＰ−ＣＳＣＦは、初期鍵材料を使用可能である。
【００１８】
本発明の目的は、ユーザ機器とアクセスネットワークとの間のトラフィックをセキュリティ保護するために使用される鍵とアプリケーション／サービス配信に使用される鍵との間で鍵を厳密に分離できるアプリケーション／サービス鍵配信手順を提供することである。
【課題を解決するための手段】
【００１９】
本発明の第１の面によると、アプリケーションサーバとアクセスドメインを介して通信ネットワークにアクセスするユーザ機器との間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵をアプリケーションサーバに配信する方法であって、
ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするためにユーザ機器とホームドメインとの間でＡＫＡ（Authentication and Key Agreement）手順を実行し、ユーザ機器とアクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために鍵材料の少なくとも一部を使用する工程と、
鍵材料の少なくとも一部を使用してホームドメイン内で１つ以上のアプリケーション鍵を導出し、アプリケーション鍵をアプリケーションサーバに提供し、ユーザ機器において同一のアプリケーション鍵を導出する工程と、
を有し、
アクセスエンフォースメントポイントはアプリケーション鍵を導出できないか又はアプリケーション鍵に対するアクセス権を有することができないことを特徴とする方法が提供される。
【００２０】
本明細書で使用される用語「ユーザ機器」は、特定のプロトコル又はネットワークアーキテクチャに限定されない。ユーザ機器は、ユーザ端末とSubscriber Identity Moduleカードとの組み合わせであってもよく、又はユーザ端末のみであってもよい。本発明の機能性は、ユーザ端末上のみで実現されてもよく、又はユーザ端末とSubscriber Identity Moduleカードとの組み合わせ上で実現されてもよい。
【００２１】
ＡＫＡ手順の実行は、ユーザ機器をホームドメインに登録又は再登録する際に行われるのが好ましい。これは、加入者を登録することによりアクセス保護を確立するため及びアプリケーション鍵が導出される鍵材料を確立するための双方のために、手順を一度だけ実行する必要があるという利点を有する。
【００２２】
アクセスエンフォースメントポイントを介するドメインアクセスは、アクセスエンフォースメントポイントコントローラにより制御されるのが好ましい。ユーザ機器とホームドメインとの間でＡＫＡ手順を実行する工程は、ランダム値を含む認証ベクトルとランダム値から導出可能な２次暗号鍵及び２次秘匿鍵とをホームドメインからアクセスエンフォースメントポイントコントローラへ送信し、ランダム値をユーザ機器に転送することを含む。ユーザ機器は、その後、１次暗号鍵及び１次秘匿鍵を生成するために第１の鍵導出関数をランダム値に適用し、２次暗号鍵及び２次秘匿鍵を生成するために第２の鍵導出関数を１次暗号鍵及び１次秘匿鍵に適用する。２次暗号鍵及び２次秘匿鍵は、アクセスエンフォースメントポイントコントローラによりアクセスエンフォースメントポイントに渡され、セキュアトンネルは、２次暗号鍵及び２次秘匿鍵に基づいてアクセスエンフォースメントポイントとユーザ機器との間に確立される。この場合、鍵材料はランダム値と２次暗号鍵及び２次秘匿鍵とを含む。
【００２３】
アプリケーション鍵は、１次暗号鍵及び１次秘匿鍵のうちの一方又は双方を使用して、ユーザ機器及びホームドメインにおいて導出されるのが好ましい。
【００２４】
本発明の一実施形態において、鍵材料は、第１のランダム値及び第２のランダム値と第１のランダム値から導出可能な第１の暗号鍵及び第１の秘匿鍵とを含み、方法は、ランダム値をアクセスエンフォースメントポイントコントローラからユーザ機器に転送する工程を有し、ユーザ機器は、第１の暗号鍵及び第１の秘匿鍵を生成するために第１の鍵導出関数を第１のランダム値に適用し、それによって、セキュアトンネルは、第１の暗号鍵及び第１の秘匿鍵に基づいてアクセスエンフォースメントポイントとユーザ機器との間に確立される。
【００２５】
アプリケーション鍵は、第２のランダム値を使用してユーザ機器において及びホームドメイン内で導出されてもよい。
【００２６】
方法は、第２のランダム値から第２の暗号鍵及び第２の秘匿鍵を導出し、その後、アプリケーション鍵を生成するために鍵導出関数を第２の暗号鍵及び第２の秘匿鍵に適用する工程を有してもよい。
【００２７】
ホームドメイン内及びユーザ機器においてアプリケーション鍵を導出する工程は、鍵材料の少なくとも一部からアプリケーションサービス鍵を導出するために、ホームドメインとユーザ機器との間で共有される秘密を利用する工程を有してもよい。
【００２８】
アプリケーションサービス鍵は、鍵導出関数を暗号鍵及び秘匿鍵とサービスノード識別子とに適用することにより導出されてもよい。
【００２９】
アクセスエンフォースメントポイントは、ＩＰマルチメディアサブシステム（ＩＭＳ）のプロキシコールセッション制御機能（Ｐ−ＣＳＣＦ）内に提供されてもよい。アクセスエンフォースメントポイントコントローラは、プロキシコールセッション制御機能内に更に提供されてもよい。ホームドメイン内において、サービングコールセッション制御機能（Ｓ−ＣＳＣＦ）は、ＡＫＡ手順をホーム加入者サーバと関連して処理する役割を有する。
【００３０】
アクセスエンフォースメントポイント及びアクセスエンフォースメントポイントコントローラは、２Ｇ又は３ＧネットワークのサービングＧＰＲＳサポートノード（ＳＧＳＮ）内にあってもよい。回路交換ドメインの場合、アクセスエンフォースメントポイントは無線ネットワークコントローラ内にあってもよく、この場合、アクセスエンフォースメントポイントコントローラはビジターロケーションレジスタ内にある。
【００３１】
アクセスネットワークがLong Term Evolution（ＬＴＥ）アクセスネットワークを含む場合、アクセスエンフォースメントポイントは、ユーザプレーンエンティティ（ＵＰＥ）／移動性管理エンティティ（ＭＭＥ）／ｅＮｏｄｅＢであってもよく、アクセスエンフォースメントポイントコントローラはＭＭＥである。尚、これは３ＧＰＰにおいて暫定的にのみ決定されている。
【００３２】
ユーザ証明書管理サーバは、ホーム加入者サーバとアクセスエンフォースメントポイントコントローラとの間に設けられてもよい。このサーバの役割は、２次暗号鍵及び２次秘匿鍵を導出すること及び要求時にアプリケーション鍵をアプリケーションサーバに提供することである。
【００３３】
本発明の第２の面によると、アプリケーションサーバとアクセスドメインを介して通信ネットワークにアクセスするユーザ機器との間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵をアプリケーションサーバに配信するネットワーク系装置であって、
ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするためにユーザ機器と共にＡＫＡ手順を実行し、それによって、ユーザ機器とアクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために鍵材料の少なくとも一部が使用される手段と、
鍵材料の少なくとも一部を使用して１つ以上のアプリケーション鍵を導出し、アプリケーション鍵をアプリケーションサーバに提供し、鍵材料によってユーザ機器はアプリケーション鍵を同様に導出できるがアクセスエンフォースメントポイントは鍵を導出できない手段と、
を具備することを特徴とする装置が提供される。
【００３４】
本発明の第３の面によると、アクセスドメインを介して通信ネットワークにアクセスするユーザ機器であって、
ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするためにホームドメインと共にＡＫＡ手順を実行し、ユーザ機器とアクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために鍵材料の少なくとも一部を使用する手段と、
鍵材料の少なくとも一部を使用して１つ以上のアプリケーション鍵を導出し、アプリケーションサーバとの通信トンネルをセキュリティ保護するためにアプリケーション鍵を使用する手段と、
を具備することを特徴とするユーザ機器が提供される。
【００３５】
本発明の第４の面によると、アプリケーションサーバとアクセスドメインを介して通信ネットワークにアクセスするユーザ機器との間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵をアプリケーションサーバに配信する方法であって、
ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするためにユーザ機器とホームドメインとの間でＡＫＡ手順を実行し、ユーザ機器とアクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために鍵材料の少なくとも一部を使用する工程と、
鍵材料の少なくとも一部を使用してアクセスエンフォースメントポイントにおいて１つ以上のアプリケーション鍵を導出し、アプリケーション鍵をアプリケーションサーバに提供し、ユーザ機器において同一のアプリケーション鍵を導出する工程と、
を有することを特徴とする方法が提供される。
【発明を実施するための最良の形態】
【００３６】
本発明の他の面は添付の請求の範囲において特定される。
【００３７】
２Ｇ／３Ｇコアネットワークアクセス及びＩＭＳアクセスドメインの双方の場合において、ＡＫＡプロトコル及びＧＢＡプロコルを図１〜図５を参照して上述した。最初にＩＭＳの場合において、次にＳＡＥ／ＬＴＥ高性能３Ｇネットワークの場合において、ＡＫＡの再実行を必要とせずにＧＢＡを実現できる機構を以下に説明する。
【００３８】
図４を参照して既に上述したように、セキュアＩＰｓｅｃトンネルは、暗号鍵ＣＫ及び秘匿鍵ＩＫに基づいて、ユーザ機器（ＵＥ）とＰ−ＣＳＣＦとの間に確立される。Ｓ−ＣＳＣＦが更なる鍵ＣＫ’及びＩＫ’を以下のように導出する場合を以下に考察する。
【００３９】
ＣＫ’＝ＫＤＦ(ＣＫ,P_CSCF_ID)
ＩＫ'＝ＫＤＦ(ＩＫ,P_CSCF_ID)
式中、ＫＤＦは鍵導出関数（例えば、ＧＢＡに対して定義されるような関数）である。Ｓ−ＣＳＣＦは、ＣＫ及びＩＫをＰ−ＣＳＣＦに提供するのではなく、導出された鍵ＣＫ’及びＩＫ’をＩＰｓｅｃトンネルに対して使用する鍵として提供する。しかしながら、Ｓ−ＣＳＣＦによりＰ−ＣＳＣＦを介してＵＥに提供されるＲＡＮＤ値は、１次鍵ＣＫ及びＩＫを生成するのに使用されたＲＡＮＤ値のままである。従って、ＵＥは、関数ＫＤＦと導出された鍵ＣＫ’及びＩＫ’とを使用してＣＫ及びＩＫを生成できる。
【００４０】
詳細な処理のステップを図６に示す。
・ＵＥはＳＩＰ Ｒｅｇｉｓｔｅｒ（ＳＩＰレジスタ）をＳ−ＣＳＣＦへ送信する。
・Ｓ−ＣＳＣＦは、認証ベクトルＡＶ＝（ＲＡＮＤ、ＣＫ、ＩＫ、ＸＲＥＳ、ＡＵＴＮ）をＨＳＳから取り出す。
・Ｓ−ＣＳＣＦは、例えば以下のような任意のＫＤＦを使用して、２つの新規の鍵ＣＫ’及びＩＫ’をそれぞれＣＫ及びＩＫから導出する。
ＣＫ’＝ＫＤＦ(ＣＫ,P_CSCF_ID)
ＩＫ'＝ＫＤＦ(ＩＫ,P_CSCF_ID)
・Ｓ−ＣＳＣＦは、Ｐ−ＣＳＣＦに対する新規の特別なＡＶ’＝（ＲＡＮＤ、ＣＫ’、ＩＫ’、ＸＲＥＳ、ＡＵＴＮ）を作成する。
・Ｐ−ＣＳＣＦはＡＶ’を受信し、ＲＡＮＤ／ＡＵＴＮをＵＥに転送する（このステップを図６に丸１で示す）。
・ＵＥはＲＡＮＤ／ＡＵＴＮを受信し、このタプルをＩＳＩＭを介して実行する。この動作の結果、ＵＥはＩＳＩＭからＣＫ及びＩＫを取り戻す。ここで、ＵＥは、ＣＫ’及びＩＫ’を計算するために、Ｓ−ＣＳＣＦにより使用されたのと同一のＫＤＦを適用する。このステップを図中に丸２で示す。
・ＵＥ及びＰ−ＣＳＣＦは、ＣＫ’及びＩＫ’に基づいてＩＰｓｅｃトンネルを確立する。
・図中に丸３で示すステップにおいて、ＵＥは、通信を希望する特定のＮＡＦに対するサービス専用鍵Ｋｓ＿ＮＡＦを導出する。これは、先に使用されたものと潜在的に同一のＫＤＦをＣＫ、ＩＫ及びＮＡＦ＿ＩＤに適用することにより実行されてもよい。あるいは、Ｋｓ＿ＮＡＦは、例えば以下のように、ＫＤＦを鍵ＣＫ”及びＩＫ”とＮＡＦ＿ＩＤとに適用することにより導出される：
ＣＫ"＝ＫＤＦ(ＣＫ,＜some GBA ID＞,＜other param＞)
ＩＫ"＝ＫＤＦ(ＩＫ,＜some GBA ID＞,＜other param＞)
ＣＫ”及びＩＫ”を導出する理由は、ＮＡＦがＵＥとＮＡＦとの間で使用されるセキュリティプロトコルに対する別個の秘匿鍵及び暗号化鍵を有することを希望する場合があるからである。その場合、ＮＡＦはＣＫ”及びＩＫ”を直接使用できる。＜some GBA ID＞パラメータは、高性能ＧＢＡシステムを識別するＩＤであり（例えば、文字列「eGBA」又は文字列「eGBA@operator.com」）、生成された鍵をこの特定の鍵配布システムに結び付けるため及び潜在的な鍵の衝突を回避するために使用される。
・その後、ＵＥはＮＡＦに接触し、ＩＭＳ登録の結果生じたＣＫ／ＩＫを一意に識別するアイデンティティをＮＡＦに提供する。このアイデンティティは（ＧＢＡにおいては）Ｂ−ＴＩＤと呼ばれ、ＡＫＡ手順中にＢＳＦからＵＥに提供される。すなわち、このアイデンティティは、（ＡＫＡが実行される場合は）ＩＭＳ登録手順中にＳ−ＣＳＣＦにより提供される。
・ＮＡＦはＳ−ＣＳＣＦに接触し、所定のＢ−ＴＩＤに対応するＫｓ＿ＮＡＦを要求する。
・Ｓ−ＣＳＣＦは、ＵＥが行なったのと同一の方法でＣＫ及びＩＫからＫｓ＿ＮＡＦを導出する。Ｓ−ＣＳＣＦは、Ｋｓ＿ＮＡＦをＮＡＦに返送する。例えば、Ｋｓ_NAF＝ＫＤＦ(ＣＫ",ＩＫ",NAF_ID,＜other param＞)である。
・この時点で、ＵＥ及びＮＡＦは、Ｋｓ＿ＮＡＦに基づいてセキュア接続を確立できる。
【００４１】
この処理を実現するには、Ｓ−ＣＳＣＦに対する変更及び場合によってはより重大なＵＥに対する変更が必要である。この変更は、ある特定のＵＥがＧＢＡ処理により提供される追加の機能性を利用することを要求しない場合であっても必要である。これは、従来のＵＥに対する単なるソフトウェアのアップグレードを含んでもよいが、更新が面倒な場合がある。この問題は、別の処理を実現することにより回避される。これは、ＲＡＮＤ／ＡＵＴＮの第２の対（すなわち、ＲＡＮＤ’及びＡＵＴＮ’）を初期ＩＭＳ ＡＫＡ交換に含むことを伴う。このように、ＵＥ及びＳ−ＣＳＣＦは、２組の共有鍵（ＣＫ、ＩＫ及びＣＫ’、ＩＫ’）を確立できる。第１の鍵の組はＰ−ＣＳＣＦとＵＥとの間にＩＰｓｅｃトンネルを確立するのに使用され、第２の組はＩＭＳアプリケーションサーバに対する鍵を導出するのに使用される。この別の処理を図７に示す。ＵＥが高性能ＧＢＡ機能性をサポートしない従来のＵＥの場合、ＵＥはＲＡＮＤ’値及びＡＵＴＮ’値を単に参照しないか又は無視し、ＲＡＮＤ及びＡＵＴＮのみを通常通り処理する。
【００４２】
詳細な処理ステップは以下の通りである：
・ＵＥは、ＳＩＰ ＲｅｇｉｓｔｅｒをＳ−ＣＳＣＦへ送信する。
・Ｓ−ＣＳＣＦは、ＡＶ＝（ＲＡＮＤ、ＣＫ、ＩＫ、ＸＲＥＳ、ＡＵＴＮ）及びＡＶ’＝（ＲＡＮＤ’、ＣＫ’、ＩＫ’、ＸＲＥＳ’、ＡＵＴＮ’）をＨＳＳから取り出す。
・Ｓ−ＣＳＣＦは、ＡＶ及びＡＶ’をＰ−ＣＳＣＦへ送信する。
・Ｐ−ＣＳＣＦはＡＶ及びＡＶ’を受信し、ＲＡＮＤ／ＡＵＴＮ及びＲＡＮＤ’／ＡＵＴＮ’をＵＥに転送する（このステップを図７に丸１で示す）。
・ＵＥはＲＡＮＤ／ＡＵＴＮ及びＲＡＮＤ’／ＡＵＴＮ’を受信し、ＩＳＩＭを介してＲＡＮＤ／ＡＵＴＮを実行する。この動作の結果、ＵＥはＩＳＩＭからＣＫ及びＩＫを取り戻す。ＵＥは、ＣＫ及びＩＫを使用してＰ−ＣＳＣＦとのＩＰｓｅｃトンネルを確立する。ＵＥはＩＳＩＭを介してＲＡＮＤ’／ＡＵＴＮ’を実行し、その結果、ＩＳＩＭからＣＫ’及びＩＫ’を取り戻す。このステップを図中に丸２で示す。
・図中に丸３で示すステップにおいて、ＵＥは、通信を希望する特定のＮＡＦに対するサービス専用鍵Ｋｓ＿ＮＡＦを導出する。これは、ＫＤＦをＣＫ’、ＩＫ’及びＮＡＦ＿ＩＤに適用することにより実行される。
・ＵＥはＮＡＦに接触し、ＩＭＳ登録の結果生じたＣＫ’／ＩＫ’を一意に識別するアイデンティティ（例えばＢ−ＴＩＤ）をＮＡＦに提供する。
・ＮＡＦはＳ−ＣＳＣＦに接触し、所定のＢ−ＴＩＤに対応するＫｓ＿ＮＡＦを要求する。
・Ｓ−ＣＳＣＦは、ＵＥが行なったのと同一の方法でＣＫ’及びＩＫ’からＫｓ＿ＮＡＦを導出する。Ｓ−ＣＳＣＦはＫｓ＿ＮＡＦをＮＡＦに返送する。
・この時点で、ＵＥ及びＮＡＦは、Ｋｓ＿ＮＡＦに基づいてセキュア接続を確立できる。
【００４３】
この別の方法も、高性能機能性が動作するためにＳ−ＣＳＣＦに対する変更を必要とするが、ＲＡＮＤ’／ＡＵＴＮ’は、従来のＵＥがネットワーク内で依然として機能できるように、すなわち、Ｐ−ＣＳＣＦとのセキュアトンネルを確立できるように、初期ＩＭＳ ＡＫＡに含まれる。例えば、ＲＡＮＤ’／ＡＵＴＮ’は、従来のＵＥによって認識されない（従って、無視される）新規のＳＩＰヘッダ内に存在してもよい。当然、従来のＵＥは、ＲＡＮＤ’／ＡＵＴＮ’の組から導出される鍵を必要とするアプリケーションサーバに依然としてアクセスできない。
【００４４】
更に別の処理において、アプリケーションサービス鍵は、従来のＩＭＳ ＡＫＡ処理、すなわち図４に示すような処理に従い且つ結果として得られる鍵ＣＫ／ＩＫをＫＤＦを使用して後処理することにより導出される。これは、Ｓ−ＣＳＣＦ及びＵＥのみが知る更なる引数、すなわち共有秘密をＫＤＦに含むことにより達成される。この場合も、Ｐ−ＣＳＣＦはアプリケーションサービス鍵を導出できない。例えば、ＫＤＦの一部（又は全部）は、ＵＥ内のソフトＳＩＭ、あるいはＵＥによりアクセスされるスマートカード内の新規又は既存のＳＩＭアプリケーションとして実現される。ＫＤＦは、例えば、通常のＳＩＭアプリケーションをサブ機能として含むことができる。ネットワークの観点から、共有秘密は認証センタ（ＡｕＣ）に格納される。これは、認証ベクトルを導出するために使用されるものと潜在的に同一の共有秘密である。これは、特定の関数（関数はＡｕＣの一部であってもよく、又はＳ−ＣＳＣＦにより供給されてもよい）を介して所定のＲＡＮＤを実行した結果をＡｕＣに要求できることを必要とする。また、共有秘密は、Ｓ−ＣＳＣＦからの所定のＲＡＮＤに対して関数を計算するためのクエリに応答する他の任意のデータベースに格納されてもよい。
【００４５】
前の段落で説明した鍵導出ステップが通常のＩＭＳ登録の後に実行される場合、この解決策は従来のＵＥに影響を与えないが、当然、従来のＵＥはアプリケーションサービス鍵を導出できない。しかしながら、ＵＥにおいて及びＩＭＳ内で重大な変更が必要とされるため、この別の処理は必ずしも最適ではない。
【００４６】
Ｓ−ＣＳＣＦは、登録中に受信される公開ユーザアイデンティティに基づいてアプリケーションサービス鍵の使用を制限してもよい。Ｓ−ＣＳＣＦは、このために現在のＩＭＳ加入処理機構を再使用できる。ユーザがＩＭＳに登録する場合、ユーザは１つ以上の公開アイデンティティを登録してもよく、そのうちのいくつかは禁止アイデンティティ（限定的な使用の場合以外は許可されない）として分類されてもよい。更に、Ｓ−ＣＳＣＦは、アプリケーションサーバ（Ｓ−ＣＳＣＦがＡＳ鍵を要求するアプリケーションサーバ）から受信するアイデンティティと禁止アイデンティティとを比較することにより、禁止アイデンティティが高性能ＧＢＡにより使用されないことを保証できる。当然、Ｓ−ＣＳＣＦは、他のサービスに対するユーザのアクセス権とは関係なく、高性能ＧＢＡ機能性を所定のユーザ又は公開ユーザアイデンティティに対して許可するため又は許可しないためにローカルポリシーを適用してもよい。
【００４７】
上述の方法は、アプリケーションサーバ（ＮＡＦ）がＳ−ＣＳＣＦのアイデンティティを知っており且つＳ−ＣＳＣＦと通信可能であると想定する。これは、アプリケーションサーバがＳ−ＣＳＣＦと同一のネットワーク内に位置する場合に当てはまる。しかしながら、これが当てはまらないこともあり、アプリケーションサーバは、例えば、Ｐ−ＣＳＣＦと同一の訪問先ネットワーク内に位置してもよい。この場合、Ｐ−ＣＳＣＦは訪問先ネットワーク内のＡＳに対してＢＳＦ機能性を有してもよい。これを図８に示す。訪問先ネットワーク内のＡＳは、ＡＳ鍵を入手するために、Ｐ−ＣＳＣＦに接触するか又はローカルＳ−ＣＳＣＦ（非ローミングユーザの場合）に接触するかを判定できなければならない。ＡＳは、ＵＥにより与えられるＳＩＰ ＵＲＩ／ＩＭＰＵ又はＢ−ＴＩＤ（Ｂ−ＴＩＤはＵＥのホームオペレータの名称を含む）に基づいてこの判定を行うことができる。ＵＥのホームオペレータは、ＧＢＡ鍵（ＣＫ及びＩＫ）をＰ−ＣＳＣＦに配布するか否かを選択することにより、訪問先ＡＳに対してローミングを許可するかを決定できる。図９は、この場合のメッセージの流れを示す。この第１の例の場合、２次鍵（ＣＫ”、ＩＫ”）の導出はＰ−ＣＳＣＦ内でローカルに行なわれる。最初に、ＵＥとＰ−ＣＳＣＦとの間のＩＰｓｅｃトンネルをセキュリティ保護するために、ＣＫ’及びＩＫ’が導出される：
ＣＫ’＝ＫＤＦ(ＣＫ,ＵＥ＿ＩＤ)
ＩＫ'＝ＫＤＦ(ＩＫ,ＵＥ＿ＩＤ)
次に、ＣＫ”及びＩＫ”が導出される：
ＣＫ"＝ＫＤＦ(ＣＫ,ＧＢＡ−ＩＤ,＜other param＞)
ＩＫ"＝ＫＤＦ(ＩＫ,ＧＢＡ−ＩＤ,＜other param＞)
ＣＫ”及びＩＫ”は、ＡＳ鍵を（ＡＳ−ＳＥＲＶ−ＩＤを用いて）導出するために使用される。
【００４８】
別個のクインテットがアクセスセキュリティ及びＧＢＡに対して使用される場合、図１０に詳細に示す処理になる。尚、この場合、ＣＫ”及びＩＫ”はＰ−ＣＳＣＦに配布され、Ｐ−ＣＳＣＦは訪問先ネットワーク内の異なるローカルＡＳに対するアプリケーションサービス（ＡＳ）鍵を導出できる。
【００４９】
ＩＭＳにおける本発明の手順の実現は、以下に示す利点の１つ以上を提供してもよい：・サービス鍵を確立するためにＧＢＡが本質的に必要ではないことによる実現の複雑性の低減、並びにＵＥ、アプリケーションサーバ及びＨＳＳにより必要とされるインタフェースの数の減少。
・セキュアＩＭＳサービスが確立される前に必要な往復処理の数の減少。
・個別のサービスの鍵の間の厳密な鍵の分離。
・アクセス保護鍵とサービス鍵との暗号化による分離。
・ＩＭＳシステムによる他のアプリケーションサービスの厳密なポリシー制御。
・ＩＭＳアクセスとサービスアクセスとの相関性。
・アプリケーションサービスアクセスを許可するための追加のインフラストラクチャ要素又は追加のインタフェースの必要性の回避。
・アプリケーションサービスに対する透過性（Ｚｎインタフェースが影響を受けないような）。
【００５０】
本発明の手順の適用はＩＭＳに限定されない。図１１は、現在考えられているＳＥＡ／ＬＴＥ（System Architecture Evolution/Long Term Evolution）アクセスネットワークを用いて高性能化される３Ｇネットワークのシステム構成要素を概略的に示す。従来のネットワークにおけるユーザの認証は、パケット交換ドメイン内のＳＧＳＮ及び回路交換ドメイン内のＶＬＲによって処理される。移行の観点から、ＳＧＳＮ／ＶＬＲが新規の特徴を実現する必要がないことが重要である。従って、インタフェース「Ｂ」及び「Ｃ」を介するプロトコルは変更されていない。従って、Ｂインタフェースは、ＨＬＲとＳＧＳＮ／ＶＬＲとの間の現在のインタフェースと同一である。新規のアクセスネットワークにおける認証は、鍵を必要とするネットワークエンティティに鍵を同様に配布する認証管理サーバ（ＡＭＳ）により処理される。図示するアーキテクチャの例において、鍵は、ユーザプレーン（ＵＰ）のデータ保護及び２種類の制御プレーン（ＣＰ１、ＣＰ２）のデータ保護のために、新規のアクセスネットワークを使用するＵＥ毎に必要とされる。
【００５１】
ユーザ証明書マネージャサーバ（ＵＣＭＳ：User Credential Manager Server）は、ＨＬＲ／ＡｕＣとＡＭＳとの間及びＨＬＲ／ＡｕＣと従来のＳＧＳＮ／ＶＬＲとの間に位置する新規のエンティティである。ＵＣＭＳはＢＳＦに類似する機能を実行し、提案される新規の機能性が使用される場合に、基本鍵を作成し、この鍵を使用してアクセスネットワークエンティティＡＭＳ及びＶＬＲが必要とする鍵を導出する。また、ＵＣＭＳ内のＢＳＦに類似する機能は、後段でＮＡＦとＵＥとの間にサービス鍵を確立するために、ＮＡＦに対するＺｎインタフェース実現する（任意の中間エンティティがＵＣＭＳの代わりにＺｎインタフェースを提供する場合を除く）。ＵＣＭＳは、従来のＳＩＭを使用する認証と新規の高性能ＵＳＩＭ（「ＸＳＩＭ」）が使用される場合とを区別する。ＸＳＩＭが使用される場合、ＡＭＳ又はＳＧＳＮ／ＶＬＲにＡＶ’を求める要求はＢＳＦに類似する機能性をトリガする。一方、従来のＳＩＭが使用される場合、ＵＣＭＳは透過的なエンティティとして動作し、ＡＭＳＳＧＳＮ／ＶＬＲとＨＬＲ／ＡｕＣとの間の要求及び応答を単に転送する。
【００５２】
認証要求（Ａｕｔｈ Ｒｅｑ：Authentication Request）がＵＣＭＳにより受信される場合を考察する。ＵＣＭＳは、要求がＸＳＩＭに関すると判定する。ＸＳＩＭが使用されることは、例えば、ＩＭＳＩの特別な範囲が使用される場合は加入者のＩＭＳＩから認識されてもよく、又はＨＬＲ／ＡｕＣからの応答において他の任意の方法、例えばＡＶの符号化で示されてもよい。ＵＣＭＳは、ＢＳＦが通常のＧＢＡトランザクションを処理するのと同様の方法でＡＶを処理する。ＵＣＭＳは、ＡＶ内のＣＫ及びＩＫから鍵Ｋｓを形成する。すなわち、ＣＫ’＝f(ＣＫ,ＩＫ)、ＩＫ'＝ｇ(ＣＫ,ＩＫ)、及びＫｓ＝ｈ(ＣＫ,ＩＫ)である。ただし、一方向関数ｆ、ｇ及びｈにおいて、ｆ!＝ｇ!＝ｈである。ＵＣＭＳはＫｓ及び関連するＢ−ＴＩＤを格納し、その後更なる暗号化鍵ＣＫ’及び秘匿鍵ＩＫ’を導出する。ＵＣＭＳはベクトル（ＲＡＮＤ、ＡＵＴＮ、ＣＫ’、ＩＫ’、ＸＲＥＳ）をＡＭＳ又はＳＧＳＮ／ＶＬＲに転送する。ＩＭＳの場合を参照して上述したように、ＡＭＳ又はＳＧＳＮ／ＶＬＲはＲＡＮＤ及びＡＵＴＮをＵＥに転送する。
【００５３】
端末側において、ＲＡＮＤ及びＡＵＴＮはＸＳＩＭに入力され、ＸＳＩＭはＣＫ及びＩＫのＧＢＡ導出を実行し、その後ＣＫ’及びＩＫ’のＧＢＡ導出を実行し、アクセスネットワークにおける保護に使用される他の任意の必要な鍵のＧＢＡ導出を実行する。ＣＫ’及びＩＫ’（並びに、他の任意の必要な鍵）はＭＥに配信される。ＫｓはＸＳＩＭに格納され、ＵＥがＧＢＡに基づく任意のサービスの使用を希望する場合、ＩＭＳの場合を参照して上述したように、ＮＡＦ専用鍵の更なる導出の基本となる。ＵＳＩＭはＲＥＳを生成し、これをＡＭＳ／ＶＬＲに返送する。ＡＭＳ／ＶＬＲは、この値がＸＲＥＳに一致することを確認する。一致する場合、ＡＭＳ／ＶＬＲは鍵ＣＫ’及びＩＫ’をＥＰに渡す。
【００５４】
ＵＥが現在のＵＭＴＳネットワークにおける情報の種類と同一種類の情報、すなわちＲＡＮＤ、ＡＵＴＮを受信すること及びＭＥとＸＳＩＭとの間のインタフェースがＲＥＬ−６インタフェースを使用してＲＡＮＤ、ＡＵＴＮを送信し且つ結果をサブセットとして受信することが理解されるだろう。これは、この機構を使用可能なＸＳＩＭを有するＲＥＬ−６ＵＥが依然として機能することを意味する。
【００５５】
図１２の信号フローは、ＵＥが認証及び鍵の確立の実行を希望する旨をネットワークに通知した後に行われる処理を示す。ＵＥが既にネットワークにアタッチされている場合、ネットワークは、同一の信号フローに従って再認証手順を開始してもよい。
【００５６】
処理ステップをより詳細に考察する。
【００５７】
ＡＭＳ又はＳＧＳＮ／ＶＬＲは、認証処理の結果をＵＣＭＳに通知してもよい。この信号伝送は図１２には示さないが、ホームネットワークがユーザの所在の記録を保持したい場合には必要である（これを以下に更に説明する）。加入者の現在のアタッチに関する情報がＨＬＲ内に保持される場合、ＵＣＭＳはＡＭＳ又はＳＧＳＮ／ＶＬＲからこの情報を受信する際にＨＬＲを更新してもよい。
【００５８】
上述の処理は、ＡｕＣ／ＨＬＲがＣＫ’及びＩＫ’を導出できるようにすることにより変更されてもよい。このエンティティは、ＣＫ’、ＩＫ’及びＫｓを含む拡張ＡＶ（ｅＡＶ）をＵＣＭＳに送信する。ＵＣＭＳではなくＡＭＳ／ＶＬＲがＣＫ’及びＩＫ’に対する鍵導出を実行することも可能である。しかしながら、これは、ＡＭＳ／ＶＬＲがＫｓ及びそれから導出される全てのＮＡＦ専用鍵を更に導出できることを意味する。ある特定の信頼モデルの下で、これは許容可能であってもよい。
【００５９】
場合によっては、ＵＣＭＳエンティティを組み込むネットワークアーキテクチャがＵＣＭＳエンティティを組み込まないアーキテクチャと共存しなければならない場合が考えられる。そのような移行フェーズにおいて、新規の鍵導出を実行する必要があるか否かを示す通知をネットワークがＸＳＩＭに信号伝送することは有利である。このような信号伝送が行われる複数の方法がある。このような信号伝送が行われる２つの方法を以下に示す。
【００６０】
１．ＡｕＣは、ＲＡＮＤ内の特定ビットを常に０に設定する（例えばＬＳＢとする）。ＵＣＭＳ内のＢＳＦ機能性は、新規の鍵導出が使用される場合はＬＳＢを１に設定し、通常の鍵導出が実行される場合はＬＳＢを０に設定する。ＸＳＩＭが（ＲＡＮＤ、ＡＵＴＮ）を受信すると、ＸＳＩＭはどちらの鍵導出が実行されるかを確認するためにＬＳＢを調べ、必要であればＬＳＢを０にリセットして続行する。しかしながら、この方法の問題は、「ハッキングされた」電話を所有する悪意のあるユーザが、ＲＡＮＤ、ＡＵＴＮをＸＳＩＭに渡す前にＲＡＮＤのＬＳＢを０に設定できることである。ＸＳＩＭは実際のＣＫ／ＩＫをＭＳに返送する。ユーザは、ネットワークにアクセスできるだけではなく、ＣＫ’及びＩＫ’を導出することもでき、従って、任意のサービスをセキュリティ保護するために使用されるＮＡＦ鍵を導出できる。
【００６１】
２．第２の方法は、例えば、偶数のシーケンス番号に基づく全てのＡＶが新規の鍵導出手順に使用され且つ奇数のシーケンス番号に基づく全てのＡＶが従来の鍵導出手順に使用されると指定することである。この方法の利点は、シーケンス番号がＡｕＣとＸＳＩＭとの間で共有される鍵Ｋによって保護される秘匿性である。従って、攻撃者は解決策１で挙げられた攻撃と同様の攻撃を実行できない。しかしながら、欠点は、新規の鍵導出又は従来の鍵導出のみを使用するＸＳＩＭの場合、シーケンス番号の空間の半分が浪費されることである。
【００６２】
加入者の認証が常にホームネットワークによって実行される場合、訪問先ネットワーク内のＡＭＳ又はＳＧＳＮ／ＶＬＲはホームネットワーク内のＵＣＭＳとＵＥとの間の中継点として使用される。これは、ＡＭＳ又はＳＧＳＮ／ＶＬＲがオーセンティケータを介する通路の役割を想定するような、すなわち、それらが認証トラフィックのみを中継するような拡張可能認証プロトコル（ＥＡＰ）ＡＫＡに非常に類似した動作になる。ＵＥがＵＣＭＳにより認証されると、ＵＣＭＳは鍵ＣＫ’及びＩＫ’のみをＡＭＳ又はＳＧＳＮ／ＶＬＲに転送する。ＵＣＭＳが、例えば、ＣＫ’＝ＫＤＦ("visited_NW_name",ＣＫ)及びＩＫ'＝ＫＤＦ("visited_NW_name",ＩＫ)によって、訪問先ネットワーク専用の鍵を導出することも可能である。これを図１３に示す。当然、ＣＫ’及びＩＫ’は、ＲＡＮＤ値及びＡＵＴＮ値と共に事前に送信される。
【００６３】
訪問先ネットワーク内で認証が行われる場合、ＢＳＦは、通常通り（図１２を参照）訪問先ネットワーク内のＡＭＳ又はＳＧＳＮ／ＶＬＲと単純に対話する。当然、ＵＣＭＳとＡＭＳ又はＳＧＳＮ／ＶＬＲとの間の信号伝送は機密性を保護されなければならない。
【００６４】
Ｓ−ＣＳＣＦに常駐するＢＳＦに類似する機能性とＵＣＭＳとが同一であるため、上述のＩＭＳ及びアクセスモデルは組み合わされてもよい。この場合、従来のＳ−ＣＳＣＦを変更する必要はない。しかしながら、Ｓ−ＣＳＣＦは通常のインタフェースをＨＳＳに対して実行するのではなく、このインタフェースをＵＣＭＳに対して実行する。共通のＵＣＭＳ機能は、別個のエンティティとしてＨＳＳにおいて実現されてもよく、又はＢＳＦと組み合わされてもよい。
【００６５】
本発明の範囲を逸脱せずに、上述の実施形態に対して種々の変形が実施されてもよいことが当業者には理解されるだろう。例えば、新規の機能性を実現するために高性能ＵＳＩＭ（すなわち、ＸＳＩＭ）を提供するのではなく、新規の機能性は、Ｋｓ及びＢ−ＴＩＤがＭＥに格納され且つＭＥが鍵導出を実行する高性能ＭＳにおいて実現されてもよい。
【図面の簡単な説明】
【００６６】
【図１】ユーザ機器とホームドメインとの間でアクセスネットワークを介して行なわれるパケットドメインにおけるＡＫＡ手順に関連付けられる信号伝送を示す図である。
【図２】ＧＢＡアーキテクチャを概略的に示す図である。
【図３】セルラ通信ネットワーク内のＩＰマルチメディアサブシステムアーキテクチャを概略的に示す図である。
【図４】ユーザ機器に対するＩＭＳ認証手順を示す図である。
【図５】汎用ＧＢＡアーキテクチャ及びＩＭＳにマッピングされたＧＢＡアーキテクチャを概略的に示す図である。
【図６】本発明の第１の実施形態に従って、ＵＥとＩＭＳのＮＡＦとの間で共有される鍵情報を確立する処理を示す図である。
【図７】本発明の第２の実施形態に従って、ＵＥとＩＭＳのＮＡＦとの間で共有される鍵情報を確立する処理を示す図である。
【図８】ＩＭＳのＰ−ＣＳＣＦにおけるＢＳＦ機能性の実現を示すブロック図である。
【図９】本発明の更なる実施形態に従って、ＵＥとＩＭＳのＮＡＦとの間で共有される鍵情報を確立する処理を示す図である。
【図１０】本発明の更に別の実施形態に従って、ＵＥとＩＭＳのＮＡＦとの間で共有される鍵情報を確立する処理を示す図である。
【図１１】ＳＡＥ／ＬＴＥアクセスネットワークを組み込んだ３Ｇネットワークを概略的に示す図である。
【図１２】図１１のネットワークにおいて認証がホームネットワークから訪問先ネットワークに委譲される初期鍵確立処理を示す図である。
【図１３】図１１のネットワークにおいて認証がホームネットワークを使用して実行される初期鍵確立処理を示す図である。
【特許請求の範囲】
【請求項１】
アプリケーションサーバと、アクセスドメインを介して通信ネットワークにアクセスするユーザ機器と、の間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵を前記アプリケーションサーバに配信する方法であって、
前記ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするために前記ユーザ機器とホームドメインとの間でＡＫＡ（Authentication and Key Agreement）手順を実行し、前記ユーザ機器と前記アクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する工程と、
前記鍵材料の少なくとも一部を使用して前記ホームドメイン内で１つ以上のアプリケーション鍵を導出し、前記アプリケーション鍵を前記アプリケーションサーバに提供し、前記ユーザ機器において同一のアプリケーション鍵を導出する工程と、
を有し、
前記アクセスエンフォースメントポイントは、前記アプリケーション鍵を導出できないか又は前記アプリケーション鍵に対するアクセス権を有することができない
ことを特徴とする方法。
【請求項２】
前記ＡＫＡ手順の前記実行は、前記ユーザ機器を前記ホームドメインに登録又は再登録する際に行われることを特徴とする請求項１記載の方法。
【請求項３】
前記アクセスエンフォースメントポイントを介するドメインアクセスはアクセスエンフォースメントポイントコントローラにより制御され、前記ユーザ機器とホームドメインとの間でＡＫＡ手順を実行する前記工程は、
ランダム値を含む認証ベクトルと前記ランダム値から導出可能な２次暗号鍵及び２次秘匿鍵とを前記ホームドメインから前記アクセスエンフォースメントポイントコントローラへ送信し、前記ランダム値を前記ユーザ機器に転送する工程と、
前記２次暗号鍵及び前記２次秘匿鍵を前記アクセスエンフォースメントポイントコントローラから前記アクセスエンフォースメントポイントに渡す工程と、
前記ユーザ機器において、１次暗号鍵及び１次秘匿鍵を生成するために第１の鍵導出関数を前記ランダム値に適用し、前記２次暗号鍵及び前記２次秘匿鍵を生成するために第２の鍵導出関数を前記１次暗号鍵及び前記１次秘匿鍵に適用する工程と、
を有し、
それによって、前記２次暗号鍵及び前記２次秘匿鍵に基づいて前記アクセスエンフォースメントポイントと前記ユーザ機器との間にセキュアトンネルを確立することが可能である
ことを特徴とする請求項１又は２記載の方法。
【請求項４】
前記ユーザ機器及び前記ホームドメインにおいて、前記１次暗号鍵及び前記１次秘匿鍵のうちの一方又は双方を使用して前記アプリケーション鍵を導出する工程を有する
ことを特徴とする請求項３記載の方法。
【請求項５】
前記アクセスエンフォースメントポイントを介するドメインアクセスはアクセスエンフォースメントポイントコントローラにより制御され、前記鍵材料は、第１のランダム値と、第２のランダム値と、前記第１のランダム値から導出可能な１次暗号鍵及び１次秘匿鍵とを含み、
前記ランダム値を前記アクセスエンフォースメントポイントコントローラから前記ユーザ機器に転送する工程を有し、
前記ユーザ機器は１次暗号鍵及び１次秘匿鍵を生成するために第１の鍵導出関数を前記第１のランダム値に適用し、それによって、前記１次暗号鍵及び前記１次秘匿鍵に基づいて前記アクセスエンフォースメントポイントと前記ユーザ機器との間にセキュアトンネルを確立することが可能であるを特徴とする請求項１又は２記載の方法。
【請求項６】
前記ユーザ機器において及び前記ホームドメイン内で、前記第２のランダム値を使用して前記アプリケーション鍵を導出する工程を有することを特徴とする請求項５記載の方法。
【請求項７】
前記第２のランダム値から２次暗号鍵及び２次秘匿鍵を導出する工程と、その後、前記アプリケーション鍵を生成するために鍵導出関数を前記２次暗号鍵及び前記２次秘匿鍵に適用する工程とを有することを特徴とする請求項６記載の方法。
【請求項８】
前記ホームドメイン内及び前記ユーザ機器においてアプリケーション鍵を導出する前記工程は、前記アプリケーション鍵を導出するために、前記ホームドメインと前記ユーザ機器との間で共有される秘密を利用する工程を有することを特徴とする請求項５から７のいずれか１項に記載の方法。
【請求項９】
鍵導出関数を暗号鍵及び秘匿鍵とサービスノード識別子とに適用することにより前記アプリケーション鍵を導出する工程を有することを特徴とする請求項１から８のいずれか１項に記載の方法。
【請求項１０】
前記アクセスエンフォースメントポイントは、ＩＰマルチメディアサブシステムのプロキシコールセッション制御機能内にあることを特徴とする請求項１から９のいずれか１項に記載の方法。
【請求項１１】
前記アクセスエンフォースメントポイントコントローラは前記プロキシコールセッション制御機能内に提供され、サービングコールセッション制御機能は、前記ホームドメイン内において、前記ＡＫＡ手順をホーム加入者サーバと関連して処理する役割を有することを特徴とする請求項１０記載の方法。
【請求項１２】
前記アクセスエンフォースメントポイントは、ＵＭＴＳアクセスドメインのサービングＧＰＲＳサポートノード内にあることを特徴とする請求項１から９のいずれか１項に記載の方法。
【請求項１３】
前記アクセスエンフォースメントポイントコントローラは、前記サービングＧＰＲＳサポートノード内に提供されることを特徴とする請求項１２記載の方法。
【請求項１４】
前記アクセスエンフォースメントポイントは、ＵＭＴＳアクセスドメインの無線ネットワークコントローラ内にあることを特徴とする請求項１から９のいずれか１項に記載の方法。
【請求項１５】
前記アクセスエンフォースメントポイントコントローラは、ビジターロケーションレジスタ内に提供されることを特徴とする請求項１４記載の方法。
【請求項１６】
前記アクセスドメインはＬＴＥ（Long Term Evolution）アクセスドメインを含み、前記アクセスエンフォースメントポイントはＵＰＥ／ＭＭＥ／ｅＮｏｄｅＢであることを特徴とする請求項１から９のいずれか１項に記載の方法。
【請求項１７】
前記アクセスエンフォースメントポイントコントローラはＭＭＥ内に提供されることを特徴とする請求項１６記載の方法。
【請求項１８】
前記ホームドメインのホーム加入者サーバと前記アクセスエンフォースメントポイントコントローラとの間にユーザ証明書管理サーバを設けることを含み、このサーバが２次暗号鍵及び２次秘匿鍵を判定し、要求時にアプリケーション鍵をアプリケーションサーバに提供することを特徴とする請求項１６又は１７記載の方法。
【請求項１９】
アプリケーションサーバと、アクセスドメインを介して通信ネットワークにアクセスするユーザ機器と、の間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵を前記アプリケーションサーバに配信するネットワーク系装置であって、
前記ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするために前記ユーザ機器と共にＡＫＡ手順を実行し、それによって、前記ユーザ機器と前記アクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部が使用される手段と、
前記鍵材料の少なくとも一部を使用して１つ以上のアプリケーション鍵を導出し、前記アプリケーション鍵を前記アプリケーションサーバに提供し、前記鍵材料によって前記ユーザ機器は前記アプリケーション鍵を同様に導出できるが前記アクセスエンフォースメントポイントは前記鍵を導出できない手段と、
を具備することを特徴とする装置。
【請求項２０】
アクセスドメインを介して通信ネットワークにアクセスするユーザ機器であって、
前記ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするためにホームドメインと共にＡＫＡ手順を実行し、前記ユーザ機器と前記アクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する手段と、
前記鍵材料の少なくとも一部を使用して１つ以上のアプリケーション鍵を導出し、アプリケーションサーバとの通信トンネルをセキュリティ保護するために前記アプリケーション鍵を使用する手段と、
を具備することを特徴とするユーザ機器。
【請求項２１】
アプリケーションサーバと、アクセスドメインを介して通信ネットワークにアクセスするユーザ機器と、の間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵を前記アプリケーションサーバに配信する方法であって、
前記ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするために前記ユーザ機器とホームドメインとの間でＡＫＡ手順を実行し、前記ユーザ機器と前記アクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する工程と、
前記鍵材料の少なくとも一部を使用して前記アクセスエンフォースメントポイントにおいて１つ以上のアプリケーション鍵を導出し、前記アプリケーション鍵を前記アプリケーションサーバに提供し、前記ユーザ機器において同一のアプリケーション鍵を導出する工程と、
を有することを特徴とする方法。
【請求項２２】
ＩＰマルチメディアサブシステムネットワークを介するユーザ機器とアプリケーションサーバとの間の通信をセキュリティ保護する方法であって、
前記ユーザ機器及びプロキシコール状態制御機能に対して鍵材料を使用可能にするために前記ユーザ機器と前記ＩＰマルチメディアサブシステムネットワークのサービングコール状態制御機能との間でＡＫＡ手順を実行し、前記ユーザ機器と前記プロキシコール状態制御機能との間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する工程と、
前記鍵材料の少なくとも一部を使用して前記サービングコール状態制御機能において少なくとも１つのアプリケーションサービス鍵を導出し、前記アプリケーションサービス鍵を前記アプリケーションサーバに提供し、前記ユーザ機器において同一のアプリケーションサービス鍵を導出する工程と、
を有し、
前記プロキシコール状態制御機能は前記アプリケーションサービス鍵を導出できないことを特徴とする方法。
【請求項２３】
前記鍵材料はランダム値と前記ランダム値から導出可能な第２の暗号鍵及び第２の秘匿鍵とを含み、
前記方法はこれらの値を前記サービングコール状態制御機能から前記プロキシコール状態制御機能に提供する工程を有し、
前記プロキシコール状態制御機能は前記ランダム値を前記ユーザ機器に転送し、前記ユーザ機器は、第１の暗号鍵及び第１の秘匿鍵を生成するために第１の鍵導出関数を前記ランダム値に適用し、前記第２の暗号鍵及び前記第２の秘匿鍵を生成するために第２の鍵導出関数を前記第１の暗号鍵及び前記第１の秘匿鍵に適用し、それによって、前記第２の暗号鍵及び前記第２の秘匿鍵に基づいて前記プロキシコール状態制御機能と前記ユーザ機器との間にセキュアトンネルを確立することが可能であることを特徴とする請求項２２記載の方法。
【請求項２４】
前記第２の暗号鍵及び前記第２の秘匿鍵は、前記ユーザ機器と前記サービングコール状態制御機能又は前記サービングコール状態制御機能に結合するノードとの間で共有される秘密及び前記ランダム値から導出可能であることを特徴とする請求項２３記載の方法。
【請求項２５】
前記第１の暗号鍵及び前記第１の秘匿鍵のうちの一方又は双方を使用して、前記ユーザ機器及び前記サービングコール状態制御機能において前記アプリケーションサービス鍵を導出する工程を有することを特徴とする請求項２３又は２４記載の方法。
【請求項２６】
前記鍵材料は第１のランダム値及び第２のランダム値と前記第１のランダム値から導出可能な第１の暗号鍵及び第１の秘匿鍵とを含み、
前記方法は前記ランダム値を前記プロキシコール状態制御機能から前記ユーザ機器に転送することを有し、
前記ユーザ機器は第１の暗号鍵及び第１の秘匿鍵を生成するために第１の鍵導出関数を前記第１のランダム値に適用し、それによって、前記第１の暗号鍵及び前記第１の秘匿鍵に基づいて前記プロキシコール状態制御機能と前記ユーザ機器との間にセキュアトンネルを確立することが可能であることを特徴とする請求項２２記載の方法。
【請求項２７】
前記アプリケーションサービス鍵は、前記ユーザ機器及び前記サービングコール状態制御機能において前記第２のランダム値を使用して導出されることを特徴とする請求項２６記載の方法。
【請求項２８】
前記第２のランダム値から第２の暗号鍵及び第２の秘匿鍵を導出する工程と、その後、前記アプリケーションサービス鍵を生成するために鍵導出関数を前記第２の暗号鍵及び前記第２の秘匿鍵に適用する工程とを有することを特徴とする請求項２７記載の方法。
【請求項２９】
前記サービングコール状態制御機能及び前記ユーザ機器においてアプリケーションサービス鍵を導出する前記工程は、前記鍵材料の少なくとも一部から前記アプリケーションサービス鍵を導出するために、前記サービングコール状態制御機能又は前記サービングコール状態制御機能に結合されるノードと前記ユーザ機器との間で共有される秘密を利用する工程を有することを特徴とする請求項２２記載の方法。
【請求項３０】
前記アプリケーションサービス鍵は、鍵導出関数を暗号鍵及び秘匿鍵とサービスノード識別子とに適用することにより導出されることを特徴とする請求項２２から２９のいずれか１項に記載の方法。
【請求項３１】
ＩＰマルチメディアサブシステムを介してアプリケーションサーバとのセキュア通信リンクを確立するユーザ機器であって、
前記ユーザ機器及びプロキシコール状態制御機能に対して鍵材料を使用可能にするために前記ＩＰマルチメディアサブシステムネットワークのサービングコール状態制御機能と共にＡＫＡ手順を実行し、前記ユーザ機器と前記プロキシコール状態制御機能との間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する手段と、
前記鍵材料の少なくとも一部を使用して少なくとも１つのアプリケーションサービス鍵を導出し、その場合、前記プロキシコール状態制御機能は前記アプリケーションサービス鍵を導出できない手段と、
前記アプリケーションサービス鍵を使用して前記アプリケーションサーバとのセキュア通信リンクを確立する手段と、
を具備することを特徴とするユーザ機器。
【請求項３２】
ＩＰマルチメディアサブシステムネットワークを介するユーザ機器とアプリケーションサーバとの間の通信をセキュリティ保護する方法であって、
前記ユーザ機器及びプロキシコール状態制御機能に対して鍵材料を使用可能にするために前記ユーザ機器と前記ＩＰマルチメディアサブシステムネットワークのサービングコール状態制御機能との間でＡＫＡ手順を実行し、前記ユーザ機器と前記プロキシコール状態制御機能との間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する工程と、
前記プロキシコール状態制御機能において前記鍵材料の少なくとも一部を使用して少なくとも１つのアプリケーションサービス鍵を導出し、前記アプリケーションサービス鍵を前記アプリケーションサーバに提供し、前記ユーザ機器において同一のアプリケーションサービス鍵を導出し、それによって、前記ユーザ機器と前記アプリケーションサーバとの間のセキュア通信が容易になる、工程と、
を有することを特徴とする方法。
【請求項３３】
ＩＰマルチメディアサブシステムにおいて使用するためのプロキシコール状態制御機能ノードであって、
ユーザ機器及び前記プロキシコール状態制御機能に対して鍵材料を使用可能にするために前記ユーザ機器及びサービスコール状態制御機能と共にＡＫＡ手順を実行し、前記ユーザ機器と前記プロキシコール状態制御機能との間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する手段と、
前記プロキシコール状態制御機能において前記鍵材料の少なくとも一部を使用して少なくとも１つのアプリケーションサービス鍵を導出し、前記ユーザ機器と前記アプリケーションサーバとの間にセキュア通信を提供するために前記アプリケーションサービス鍵を前記アプリケーションサーバに提供する手段と、
を具備することを特徴とするノード。
【請求項３４】
ＩＰマルチメディアサブシステムネットワークを介するユーザ機器とアプリケーションサーバとの間の通信をセキュリティ保護する方法であって、
前記アプリケーションサーバが前記ユーザ機器のホームネットワーク内に位置する場合、ユーザ機器と前記アプリケーションサーバとの間の通信をセキュリティ保護するために請求項１記載の方法を採用する工程と、
前記アプリケーションサーバが訪問先ネットワーク内に位置する場合、ユーザ機器と前記アプリケーションサーバとの間の通信をセキュリティ保護するために請求項１０記載の方法を採用する工程と、
を有することを特徴とする方法。
【請求項１】
アプリケーションサーバと、アクセスドメインを介して通信ネットワークにアクセスするユーザ機器と、の間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵を前記アプリケーションサーバに配信する方法であって、
前記ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするために前記ユーザ機器とホームドメインとの間でＡＫＡ（Authentication and Key Agreement）手順を実行し、前記ユーザ機器と前記アクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する工程と、
前記鍵材料の少なくとも一部を使用して前記ホームドメイン内で１つ以上のアプリケーション鍵を導出し、前記アプリケーション鍵を前記アプリケーションサーバに提供し、前記ユーザ機器において同一のアプリケーション鍵を導出する工程と、
を有し、
前記アクセスエンフォースメントポイントは、前記アプリケーション鍵を導出できないか又は前記アプリケーション鍵に対するアクセス権を有することができない
ことを特徴とする方法。
【請求項２】
前記ＡＫＡ手順の前記実行は、前記ユーザ機器を前記ホームドメインに登録又は再登録する際に行われることを特徴とする請求項１記載の方法。
【請求項３】
前記アクセスエンフォースメントポイントを介するドメインアクセスはアクセスエンフォースメントポイントコントローラにより制御され、前記ユーザ機器とホームドメインとの間でＡＫＡ手順を実行する前記工程は、
ランダム値を含む認証ベクトルと前記ランダム値から導出可能な２次暗号鍵及び２次秘匿鍵とを前記ホームドメインから前記アクセスエンフォースメントポイントコントローラへ送信し、前記ランダム値を前記ユーザ機器に転送する工程と、
前記２次暗号鍵及び前記２次秘匿鍵を前記アクセスエンフォースメントポイントコントローラから前記アクセスエンフォースメントポイントに渡す工程と、
前記ユーザ機器において、１次暗号鍵及び１次秘匿鍵を生成するために第１の鍵導出関数を前記ランダム値に適用し、前記２次暗号鍵及び前記２次秘匿鍵を生成するために第２の鍵導出関数を前記１次暗号鍵及び前記１次秘匿鍵に適用する工程と、
を有し、
それによって、前記２次暗号鍵及び前記２次秘匿鍵に基づいて前記アクセスエンフォースメントポイントと前記ユーザ機器との間にセキュアトンネルを確立することが可能である
ことを特徴とする請求項１又は２記載の方法。
【請求項４】
前記ユーザ機器及び前記ホームドメインにおいて、前記１次暗号鍵及び前記１次秘匿鍵のうちの一方又は双方を使用して前記アプリケーション鍵を導出する工程を有する
ことを特徴とする請求項３記載の方法。
【請求項５】
前記アクセスエンフォースメントポイントを介するドメインアクセスはアクセスエンフォースメントポイントコントローラにより制御され、前記鍵材料は、第１のランダム値と、第２のランダム値と、前記第１のランダム値から導出可能な１次暗号鍵及び１次秘匿鍵とを含み、
前記ランダム値を前記アクセスエンフォースメントポイントコントローラから前記ユーザ機器に転送する工程を有し、
前記ユーザ機器は１次暗号鍵及び１次秘匿鍵を生成するために第１の鍵導出関数を前記第１のランダム値に適用し、それによって、前記１次暗号鍵及び前記１次秘匿鍵に基づいて前記アクセスエンフォースメントポイントと前記ユーザ機器との間にセキュアトンネルを確立することが可能であるを特徴とする請求項１又は２記載の方法。
【請求項６】
前記ユーザ機器において及び前記ホームドメイン内で、前記第２のランダム値を使用して前記アプリケーション鍵を導出する工程を有することを特徴とする請求項５記載の方法。
【請求項７】
前記第２のランダム値から２次暗号鍵及び２次秘匿鍵を導出する工程と、その後、前記アプリケーション鍵を生成するために鍵導出関数を前記２次暗号鍵及び前記２次秘匿鍵に適用する工程とを有することを特徴とする請求項６記載の方法。
【請求項８】
前記ホームドメイン内及び前記ユーザ機器においてアプリケーション鍵を導出する前記工程は、前記アプリケーション鍵を導出するために、前記ホームドメインと前記ユーザ機器との間で共有される秘密を利用する工程を有することを特徴とする請求項５から７のいずれか１項に記載の方法。
【請求項９】
鍵導出関数を暗号鍵及び秘匿鍵とサービスノード識別子とに適用することにより前記アプリケーション鍵を導出する工程を有することを特徴とする請求項１から８のいずれか１項に記載の方法。
【請求項１０】
前記アクセスエンフォースメントポイントは、ＩＰマルチメディアサブシステムのプロキシコールセッション制御機能内にあることを特徴とする請求項１から９のいずれか１項に記載の方法。
【請求項１１】
前記アクセスエンフォースメントポイントコントローラは前記プロキシコールセッション制御機能内に提供され、サービングコールセッション制御機能は、前記ホームドメイン内において、前記ＡＫＡ手順をホーム加入者サーバと関連して処理する役割を有することを特徴とする請求項１０記載の方法。
【請求項１２】
前記アクセスエンフォースメントポイントは、ＵＭＴＳアクセスドメインのサービングＧＰＲＳサポートノード内にあることを特徴とする請求項１から９のいずれか１項に記載の方法。
【請求項１３】
前記アクセスエンフォースメントポイントコントローラは、前記サービングＧＰＲＳサポートノード内に提供されることを特徴とする請求項１２記載の方法。
【請求項１４】
前記アクセスエンフォースメントポイントは、ＵＭＴＳアクセスドメインの無線ネットワークコントローラ内にあることを特徴とする請求項１から９のいずれか１項に記載の方法。
【請求項１５】
前記アクセスエンフォースメントポイントコントローラは、ビジターロケーションレジスタ内に提供されることを特徴とする請求項１４記載の方法。
【請求項１６】
前記アクセスドメインはＬＴＥ（Long Term Evolution）アクセスドメインを含み、前記アクセスエンフォースメントポイントはＵＰＥ／ＭＭＥ／ｅＮｏｄｅＢであることを特徴とする請求項１から９のいずれか１項に記載の方法。
【請求項１７】
前記アクセスエンフォースメントポイントコントローラはＭＭＥ内に提供されることを特徴とする請求項１６記載の方法。
【請求項１８】
前記ホームドメインのホーム加入者サーバと前記アクセスエンフォースメントポイントコントローラとの間にユーザ証明書管理サーバを設けることを含み、このサーバが２次暗号鍵及び２次秘匿鍵を判定し、要求時にアプリケーション鍵をアプリケーションサーバに提供することを特徴とする請求項１６又は１７記載の方法。
【請求項１９】
アプリケーションサーバと、アクセスドメインを介して通信ネットワークにアクセスするユーザ機器と、の間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵を前記アプリケーションサーバに配信するネットワーク系装置であって、
前記ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするために前記ユーザ機器と共にＡＫＡ手順を実行し、それによって、前記ユーザ機器と前記アクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部が使用される手段と、
前記鍵材料の少なくとも一部を使用して１つ以上のアプリケーション鍵を導出し、前記アプリケーション鍵を前記アプリケーションサーバに提供し、前記鍵材料によって前記ユーザ機器は前記アプリケーション鍵を同様に導出できるが前記アクセスエンフォースメントポイントは前記鍵を導出できない手段と、
を具備することを特徴とする装置。
【請求項２０】
アクセスドメインを介して通信ネットワークにアクセスするユーザ機器であって、
前記ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするためにホームドメインと共にＡＫＡ手順を実行し、前記ユーザ機器と前記アクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する手段と、
前記鍵材料の少なくとも一部を使用して１つ以上のアプリケーション鍵を導出し、アプリケーションサーバとの通信トンネルをセキュリティ保護するために前記アプリケーション鍵を使用する手段と、
を具備することを特徴とするユーザ機器。
【請求項２１】
アプリケーションサーバと、アクセスドメインを介して通信ネットワークにアクセスするユーザ機器と、の間で交換されるデータをセキュリティ保護する際に使用するためのアプリケーション鍵を前記アプリケーションサーバに配信する方法であって、
前記ユーザ機器及びアクセスエンフォースメントポイントに対して鍵材料を使用可能にするために前記ユーザ機器とホームドメインとの間でＡＫＡ手順を実行し、前記ユーザ機器と前記アクセスエンフォースメントポイントとの間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する工程と、
前記鍵材料の少なくとも一部を使用して前記アクセスエンフォースメントポイントにおいて１つ以上のアプリケーション鍵を導出し、前記アプリケーション鍵を前記アプリケーションサーバに提供し、前記ユーザ機器において同一のアプリケーション鍵を導出する工程と、
を有することを特徴とする方法。
【請求項２２】
ＩＰマルチメディアサブシステムネットワークを介するユーザ機器とアプリケーションサーバとの間の通信をセキュリティ保護する方法であって、
前記ユーザ機器及びプロキシコール状態制御機能に対して鍵材料を使用可能にするために前記ユーザ機器と前記ＩＰマルチメディアサブシステムネットワークのサービングコール状態制御機能との間でＡＫＡ手順を実行し、前記ユーザ機器と前記プロキシコール状態制御機能との間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する工程と、
前記鍵材料の少なくとも一部を使用して前記サービングコール状態制御機能において少なくとも１つのアプリケーションサービス鍵を導出し、前記アプリケーションサービス鍵を前記アプリケーションサーバに提供し、前記ユーザ機器において同一のアプリケーションサービス鍵を導出する工程と、
を有し、
前記プロキシコール状態制御機能は前記アプリケーションサービス鍵を導出できないことを特徴とする方法。
【請求項２３】
前記鍵材料はランダム値と前記ランダム値から導出可能な第２の暗号鍵及び第２の秘匿鍵とを含み、
前記方法はこれらの値を前記サービングコール状態制御機能から前記プロキシコール状態制御機能に提供する工程を有し、
前記プロキシコール状態制御機能は前記ランダム値を前記ユーザ機器に転送し、前記ユーザ機器は、第１の暗号鍵及び第１の秘匿鍵を生成するために第１の鍵導出関数を前記ランダム値に適用し、前記第２の暗号鍵及び前記第２の秘匿鍵を生成するために第２の鍵導出関数を前記第１の暗号鍵及び前記第１の秘匿鍵に適用し、それによって、前記第２の暗号鍵及び前記第２の秘匿鍵に基づいて前記プロキシコール状態制御機能と前記ユーザ機器との間にセキュアトンネルを確立することが可能であることを特徴とする請求項２２記載の方法。
【請求項２４】
前記第２の暗号鍵及び前記第２の秘匿鍵は、前記ユーザ機器と前記サービングコール状態制御機能又は前記サービングコール状態制御機能に結合するノードとの間で共有される秘密及び前記ランダム値から導出可能であることを特徴とする請求項２３記載の方法。
【請求項２５】
前記第１の暗号鍵及び前記第１の秘匿鍵のうちの一方又は双方を使用して、前記ユーザ機器及び前記サービングコール状態制御機能において前記アプリケーションサービス鍵を導出する工程を有することを特徴とする請求項２３又は２４記載の方法。
【請求項２６】
前記鍵材料は第１のランダム値及び第２のランダム値と前記第１のランダム値から導出可能な第１の暗号鍵及び第１の秘匿鍵とを含み、
前記方法は前記ランダム値を前記プロキシコール状態制御機能から前記ユーザ機器に転送することを有し、
前記ユーザ機器は第１の暗号鍵及び第１の秘匿鍵を生成するために第１の鍵導出関数を前記第１のランダム値に適用し、それによって、前記第１の暗号鍵及び前記第１の秘匿鍵に基づいて前記プロキシコール状態制御機能と前記ユーザ機器との間にセキュアトンネルを確立することが可能であることを特徴とする請求項２２記載の方法。
【請求項２７】
前記アプリケーションサービス鍵は、前記ユーザ機器及び前記サービングコール状態制御機能において前記第２のランダム値を使用して導出されることを特徴とする請求項２６記載の方法。
【請求項２８】
前記第２のランダム値から第２の暗号鍵及び第２の秘匿鍵を導出する工程と、その後、前記アプリケーションサービス鍵を生成するために鍵導出関数を前記第２の暗号鍵及び前記第２の秘匿鍵に適用する工程とを有することを特徴とする請求項２７記載の方法。
【請求項２９】
前記サービングコール状態制御機能及び前記ユーザ機器においてアプリケーションサービス鍵を導出する前記工程は、前記鍵材料の少なくとも一部から前記アプリケーションサービス鍵を導出するために、前記サービングコール状態制御機能又は前記サービングコール状態制御機能に結合されるノードと前記ユーザ機器との間で共有される秘密を利用する工程を有することを特徴とする請求項２２記載の方法。
【請求項３０】
前記アプリケーションサービス鍵は、鍵導出関数を暗号鍵及び秘匿鍵とサービスノード識別子とに適用することにより導出されることを特徴とする請求項２２から２９のいずれか１項に記載の方法。
【請求項３１】
ＩＰマルチメディアサブシステムを介してアプリケーションサーバとのセキュア通信リンクを確立するユーザ機器であって、
前記ユーザ機器及びプロキシコール状態制御機能に対して鍵材料を使用可能にするために前記ＩＰマルチメディアサブシステムネットワークのサービングコール状態制御機能と共にＡＫＡ手順を実行し、前記ユーザ機器と前記プロキシコール状態制御機能との間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する手段と、
前記鍵材料の少なくとも一部を使用して少なくとも１つのアプリケーションサービス鍵を導出し、その場合、前記プロキシコール状態制御機能は前記アプリケーションサービス鍵を導出できない手段と、
前記アプリケーションサービス鍵を使用して前記アプリケーションサーバとのセキュア通信リンクを確立する手段と、
を具備することを特徴とするユーザ機器。
【請求項３２】
ＩＰマルチメディアサブシステムネットワークを介するユーザ機器とアプリケーションサーバとの間の通信をセキュリティ保護する方法であって、
前記ユーザ機器及びプロキシコール状態制御機能に対して鍵材料を使用可能にするために前記ユーザ機器と前記ＩＰマルチメディアサブシステムネットワークのサービングコール状態制御機能との間でＡＫＡ手順を実行し、前記ユーザ機器と前記プロキシコール状態制御機能との間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する工程と、
前記プロキシコール状態制御機能において前記鍵材料の少なくとも一部を使用して少なくとも１つのアプリケーションサービス鍵を導出し、前記アプリケーションサービス鍵を前記アプリケーションサーバに提供し、前記ユーザ機器において同一のアプリケーションサービス鍵を導出し、それによって、前記ユーザ機器と前記アプリケーションサーバとの間のセキュア通信が容易になる、工程と、
を有することを特徴とする方法。
【請求項３３】
ＩＰマルチメディアサブシステムにおいて使用するためのプロキシコール状態制御機能ノードであって、
ユーザ機器及び前記プロキシコール状態制御機能に対して鍵材料を使用可能にするために前記ユーザ機器及びサービスコール状態制御機能と共にＡＫＡ手順を実行し、前記ユーザ機器と前記プロキシコール状態制御機能との間の通信トンネルをセキュリティ保護するために前記鍵材料の少なくとも一部を使用する手段と、
前記プロキシコール状態制御機能において前記鍵材料の少なくとも一部を使用して少なくとも１つのアプリケーションサービス鍵を導出し、前記ユーザ機器と前記アプリケーションサーバとの間にセキュア通信を提供するために前記アプリケーションサービス鍵を前記アプリケーションサーバに提供する手段と、
を具備することを特徴とするノード。
【請求項３４】
ＩＰマルチメディアサブシステムネットワークを介するユーザ機器とアプリケーションサーバとの間の通信をセキュリティ保護する方法であって、
前記アプリケーションサーバが前記ユーザ機器のホームネットワーク内に位置する場合、ユーザ機器と前記アプリケーションサーバとの間の通信をセキュリティ保護するために請求項１記載の方法を採用する工程と、
前記アプリケーションサーバが訪問先ネットワーク内に位置する場合、ユーザ機器と前記アプリケーションサーバとの間の通信をセキュリティ保護するために請求項１０記載の方法を採用する工程と、
を有することを特徴とする方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公表番号】特表２００９−５１７９３７（Ｐ２００９−５１７９３７Ａ）
【公表日】平成２１年４月３０日（２００９．４．３０）
【国際特許分類】
【出願番号】特願２００８−５４２６８４（Ｐ２００８−５４２６８４）
【出願日】平成１８年７月１１日（２００６．７．１１）
【国際出願番号】ＰＣＴ／ＥＰ２００６／０６４１０７
【国際公開番号】ＷＯ２００７／０６２８８２
【国際公開日】平成１９年６月７日（２００７．６．７）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２１年４月３０日（２００９．４．３０）
【国際特許分類】
【出願日】平成１８年７月１１日（２００６．７．１１）
【国際出願番号】ＰＣＴ／ＥＰ２００６／０６４１０７
【国際公開番号】ＷＯ２００７／０６２８８２
【国際公開日】平成１９年６月７日（２００７．６．７）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]