セキュリティ・アソシエーションを確立するための方法および装置
【課題】サービス・ノードからクライアントに情報をプッシュ配信するためセキュリティ・アソシエーションをクライアントとサービス・ノードとの間に確立するための方法を提供する。
【解決手段】クライアントと鍵サーバは基本秘密を共有し、サービス鍵の生成および提供に対する要求をサービス・ノードから鍵サーバに送信する。当該要求はクライアントおよびサービス・ノードを識別する、ステップと、クライアントおよびサービス・ノードの識別情報、基本秘密、付加情報を使用してサービス鍵を鍵サーバで生成し付加情報と一緒にサービス鍵をサービス・ノードに送信するステップと、付加情報をサービス・ノードからクライアントに転送するステップと、受信した付加情報および基本鍵を使用してクライアントでサービス鍵を生成するステップとで構成する。同様な手法はｐ２ｐ鍵管理にも適用出来る。
【解決手段】クライアントと鍵サーバは基本秘密を共有し、サービス鍵の生成および提供に対する要求をサービス・ノードから鍵サーバに送信する。当該要求はクライアントおよびサービス・ノードを識別する、ステップと、クライアントおよびサービス・ノードの識別情報、基本秘密、付加情報を使用してサービス鍵を鍵サーバで生成し付加情報と一緒にサービス鍵をサービス・ノードに送信するステップと、付加情報をサービス・ノードからクライアントに転送するステップと、受信した付加情報および基本鍵を使用してクライアントでサービス鍵を生成するステップとで構成する。同様な手法はｐ２ｐ鍵管理にも適用出来る。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はプッシュ型サービスを配信するためにクライアント端末とサービス・ノードとの間にセキュリティ・アソシエーションを確立するための方法および装置に関するものであり、必ずしもそうではないが、特に、汎用ブートストラッピング・アーキテクチャを採用する方法および装置に関するものである。
【背景技術】
【０００２】
ユーザ端末へのサービスの提供を容易にするために、３Ｇネットワークのようなモバイル・ネットワークは大抵、クライアント端末（すなわち移動端末）とサービスを提供するネットワーク基盤サービス・ノードとの間に安全な通信チャネル、すなわち“セキュリティ・アソシエーション”の確立を必要とする。汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）は３ＧＰＰ技術仕様書ＴＳ３３．２２０で論じられており、そしてクライアント端末（ＵＥ）がネットワーク認証機能（サービス・ノード）により認証されるメカニズム、および、クライアント端末とネットワーク認証機能との間での使用のために得られる安全なセッション鍵を提供する。このアーキテクチャに対する簡単なネットワーク・モデルが図１に描かれている。このメカニズムは、クライアント端末がクライアントのホーム・ネットワークのブートストラッピング・サーバ機能（ＢＳＦ）に、クライアント端末のＵＳＩＭと加入者のホーム・ネットワークのホーム加入者システム（ＨＳＳ）との間で共有される秘密Ｋに基づいて、認証されるようにできる周知の認証／暗号鍵配送方式（ＡＫＡ）手順［３ＧＰＰ ＴＳ３３．１０２］でブートする。ＡＫＡ手順はさらに、セッション鍵を確立し、この鍵は後でクライアント端末とネットワーク・アプリケーション機能（ＮＡＦ）との間で適用される。クライアント端末およびＮＡＦがＢＳＦからセッション鍵を得ようとする場合、ＮＡＦはトランザクション識別子をＢＳＦに送り、トランザクション識別子にはＢＳＦがクライアント端末を識別するために使用するインデックスおよびＮＡＦに転送する適切な鍵を含んでいる。
【０００３】
ＧＢＡメカニズムに従って、ＵＥは鍵の生成処理を、ユーザ識別情報を含む要求をＢＳＦに送ることにより開始する。要求はまたＮＡＦの識別情報を含む。ＢＳＦは認証ベクトルをホーム加入者システム（ＨＳＳ）から読み出し、各々の認証ベクトルは乱数ＲＡＮＤ、想定される認証応答ＸＲＥＳ、暗号鍵ＣＫ、インテグリティ鍵ＩＫおよび認証トークンＡＵＴＮで構成されている。ＢＳＦは、認証ベクトルに含まれるＣＫおよびＩＫを連結することにより鍵素材ＫＳを生成する。ＢＳＦは鍵識別子Ｂ−ＴＩＤを、ＲＡＮＤ値をｂａｓｅ６４符号化し、そして符号化された値をＢＳＦのサーバ名と組み合わせることにより、すなわち
ｂａｓｅ６４ｅｎｃｏｄｅ（ＲＡＮＤ）＠ＢＳＦ＿ｓｅｒｖｅｒｓ＿ｄｏｍａｉｎ＿ｎａｍｅ
としてＮＡＩフォーマットで生成する。
【０００４】
ＢＳＦは鍵ＫＳをトランザクション識別子Ｂ−ＴＩＤおよびＮＡＦ識別情報と併せて保持する。Ｂ−ＴＩＤおよびＡＵＴＮはＢＳＦによりＵＥに送られ、クライアント端末のＵＳＩＭは、値ＡＵＴＮを共有秘密Ｋを使用して確認し、そして想定される認証応答ＸＲＥＳの要約をＢＳＦに戻す。ＵＳＩＭはまた、鍵素材ＫＳを秘密Ｋおよび（Ｂ−ＴＩＤから元に戻された）値ＲＡＮＤを使用して生成する。
【０００５】
この手順の完了に続き、ＵＥはＮＡＦに、受信したＢ−ＴＩＤを伝える。ＮＡＦおよびＢＳＦは相互に認証され、そしてＮＡＦはＢＳＦに受信したＢ−ＴＩＤをそれ自身の識別情報と一緒に送る。ＢＳＦはＢ−ＴＩＤおよびＮＡＦの識別情報を使用して正しい鍵ＫＳを検索し、そしてＫＳを使用してＮＡＦ鍵を生成する。ＮＡＦ識別情報のような他の情報はまた、ＮＡＦ鍵の生成の際に使用される。生成されたＮＡＦ鍵はＮＡＦに戻される。ＵＥは、同様にＮＡＦ鍵を、既に生成されている鍵ＫＳを使用して生成することができる。
【０００６】
ＧＢＡメカニズムが初めて実行されてから、ＵＥと同じまたは異なるＮＡＦとの間にセキュリティ・アソシエーションを確立する後続の要求は、鍵が失効していなければ、既に確立された鍵素材ＫＳを使用することができる。しかしながら、これはなお、Ｂ−ＴＩＤをＮＡＦに送ることによりＵＥがセキュリティ・アソシエーションの確立要求を開始することを要求するであろう。
【発明の概要】
【０００７】
ＮＡＦがＵＥとのセキュリティ・アソシエーションの確立を開始するようにできることが望ましい場合がある。たとえば、プッシュ型のサービスが考えられ、それは予めサービスに対して登録を済ませているユーザに、ニュース、スポーツおよび金融等の情報を配信する。これを達成する標準的な操作手順は、サービス提供業者がＳＭＳメッセージを、ユーザに安全なコネクションをオープンするように要求するＵＥに送ることであろう。しかしながら、ＳＭＳが巧妙に操作され、無認可パーティにより送られ、リプレイされる恐れのあるこのモデルに関連する多くの脅威がある。セキュリティ・アソシエーションが存在していたか、またはサービス・ノードが実際のサービス・データが送られるまでにセキュリティ・アソシエーションを開始できていれば、セキュリティ手順はこれに基づくことができ、そして大抵の問題は軽減されることができよう。
【０００８】
本発明の第１の態様では、第１のノードから第２のノードに情報をプッシュ配信するために前記第１のノードと前記第２のノードとの間にセキュリティ・アソシエーションを確立する方法が提供され、前記第２のノードおよび鍵生成機能は基本秘密を共有しており、該方法は、
サービス鍵の生成および提供の要求を前記第１のノードから前記鍵生成機能に送信するステップであって、前記要求は前記第１および第２のノードの識別情報を含む、ステップと、
前記第１のノードの前記識別情報と前記基本秘密と付加情報とを使用して前記鍵生成機能でサービス鍵を生成し、該サービス鍵を前記付加情報と共に前記第１のノードに送信するステップと、
前記付加情報と前記第１のノードの前記識別情報とを前記第１のノードから前記第２のノードに転送するステップと、
受信した前記付加情報と前記第１のユーザの識別情報と前記基本秘密とを使用して前記第２のノードで前記サービス鍵を生成するステップと、
を備える。
【０００９】
当然のことながら、鍵生成機能はスタンドアロン・ノードであってもよく、また、分散サーバであってもよい。汎用ブートストラッピング・アーキテクチャを採用する３Ｇネットワークの場合、ブートストラッピング・サーバ機能およびホーム加入者サーバはともに、鍵生成機能を提供することができ、ブートストラッピング・サーバ機能はサービス・ノードとおよびホーム加入者サーバと通信する。２Ｇネットワークの場合、鍵生成機能はブートストラッピング・サーバ機能とＡｕＣサーバとの組み合わせであることができる。
【００１０】
汎用ブートストラッピング・アーキテクチャを採用する３Ｇネットワークの場合、サービス・ノードはネットワーク・アプリケーション機能を備える。サービス鍵を鍵生成機能で生成するステップは：
前記基本秘密を使用して鍵素材ＫＳを生成するステップと、
前記鍵素材ＫＳと前記サービス・ノードの前記識別情報と前記付加情報とを使用して前記サービス鍵を生成するステップと、
を備える。
【００１１】
クライアントでサービス鍵を生成するステップはまた、これらの２つのステップを備える。
【００１２】
鍵サーバでサービス鍵を生成する前記ステップは、サービス・ノードからクライアントに送信されたもの以外の他の値を利用する場合がある。クライアントは鍵サーバからそれらの他の値のうちのいくつかを得ることができる。
【００１３】
前記付加情報は、１以上の、
ランダム値；
タイムスタンプ；
シーケンス番号；
他の識別子
を含む。汎用ブートストラッピング・アーキテクチャの場合、前記ランダム値はＲＡＮＤパラメータであり、そしてＢ−ＴＩＤにより運ばれる。
【００１４】
前記付加情報はＮＡＩフォーマットのトランザクション識別子を含むことができ、そして符号化ランダム値を含む。
【００１５】
前記付加情報はサービス・ノードからクライアントにサービス・データをまた含むメッセージで転送されることができ、サービス・データはサービス鍵で暗号化されており、クライアントは一旦サービス鍵を生成していると暗号化されたデータを復号することができる。
【００１６】
本発明の１つの実施形態では、鍵生成機能はサービス・ノードにネットワーク認証値を送る。サービス・ノードはこの値をクライアントに前記付加情報と一緒に転送する。クライアントは基本秘密および認証値を使用して鍵生成機能を認証する。鍵生成機能が認証されている場合に限り、クライアントはサービス鍵を生成し使用する。
【００１７】
本発明の別の実施形態では、クライアントは認証値を鍵生成機能に、前記付加情報をサービス・ノードから受信し終わってから要求する。クライアントが鍵生成機能を認証している場合のみ、サービス鍵が生成され使用される。
【００１８】
端末はサービス・ノードからメッセージ認証コードを受信するための手段を備えることができ、端末は１以上の認証鍵を少なくとも一部の鍵生成情報から生成し、１以上の認証鍵を使用してメッセージ認証コードを認証するための手段を備える。生成手段はＵＳＩＭ／ＩＳＩＭである場合がある。
【００１９】
前記サービス鍵は第２のノードに対するＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵であることができ、方法はさらに第１のノードに第１のノードに対するＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵を提供し、および第１のノードに対するＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵を第２のノードに送るステップを備え、前記セキュリティ・アソシエーションが２つのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵に基づいて確立される。
【００２０】
本発明の第２の態様では、安全な通信リンクを経由してプッシュ型サービスをクライアントに配信するためのサービス・ノードが提供され、サービス・ノードは、
サービス鍵の生成および提供の要求を鍵生成機能に送信する手段であって、前記要求は前記クライアントおよび前記サービス・ノードを識別する、手段と、
前記鍵生成機能からサービス鍵を付加情報と共に受信する手段と、
前記付加情報を前記クライアントに転送する手段と、
前記サービス鍵を使用してサービス情報の暗号化および／または完全性保護を行い、該暗号化および／または完全性保護された情報を前記クライアントに送信する手段と、
を備える。
【００２１】
汎用ブートストラッピング・アーキテクチャの場合、前記付加情報はＲＡＮＤ値を含むＢ−ＴＩＤを備える。転送するための前記手段はまた、クライアントにサービス・ノードの識別情報を転送するように構成される。
【００２２】
本発明の第３の態様では、サービス・ノードにより配信されるプッシュ型サービスを受信するためのクライアント端末が提供され、クライアント端末は、
鍵生成機能との共有秘密を格納する記憶手段と、
前記サービス・ノードから鍵生成情報を受信する手段と、
前記共有秘密と前記鍵生成情報とを使用してサービス鍵を生成する手段と、
前記サービス・ノードとの通信の復号および／または完全性検証のために前記サービス鍵を使用する手段と、
を備える。
【００２３】
本発明の第４の態様では、サービス・ノードからクライアントに情報をプッシュ配信するために前記クライアントと前記サービス・ノードとの間にセキュリティ・アソシエーションを確立する際に使用する鍵生成機能が提供され、鍵サーバは、
前記クライアントと共有される秘密を格納する記憶手段と、
サービス鍵の生成および提供の要求を前記サービス・ノードから受信する手段であって、前記要求は前記クライアントおよび前記サービス・ノードを識別する、手段と、
前記サービス・ノードの前記クライアントの前記識別情報と前記基本秘密と付加情報とを使用してサービス鍵を生成し、該サービス鍵を前記付加情報と共に前記サービス・ノードに送信する手段と、
を備える。
【００２４】
本発明の第５の態様では、第１のクライアントから第２のクライアントに情報をプッシュ配信するために前記第１および第２のクライアントの間でセキュリティ・アソシエーションを確立する方法が提供され、前記第１および第２のクライアントはそれぞれ第１および第２の鍵サーバとの信頼関係を有しそれぞれの鍵サーバと秘密を共有しており、該方法は、
サービス鍵の生成および提供の要求を前記第１の鍵サーバを経由して前記第１のクライアントから前記第２の鍵サーバに送信するステップであって、前記要求は前記第１および第２のノードを識別する、ステップと、
前記第１のノードの前記識別情報と前記基本秘密と付加情報とを使用して前記第２の鍵サーバでサービス鍵を生成し、該サービス鍵を前記付加情報と共に前記第１のノードに送信するステップと、
前記付加情報を前記第１のノードから前記第２のノードに転送するステップと、
前記第２のノードで、受信した前記付加情報と前記基本秘密とを使用して前記サービス鍵を生成するステップと、
を備える。
【００２５】
本発明の第６の態様では、リプレイ攻撃に対してノードを保護する方法が提供され、該方法は、
ブートストラッピング・サーバ機能でサービス鍵を生成するステップと、
前記サービス鍵を該サービス鍵の生成に必要な情報と共に第１のノードに提供するステップと、
前記第１のノードから前記第２のノードに鍵生成メッセージを送信するステップであって、前記メッセージは前記情報とリプレイ防止値と該リプレイ防止値を含む前記メッセージ本体にわたって計算されるメッセージ認証コードとを含み、前記リプレイ防止値は前記手順の実行のたびにインクリメントまたはデクリメントされる、ステップと、
前記第２のノードで前記鍵生成メッセージを受信し、該鍵生成メッセージに含まれる前記リプレイ防止値を格納するステップと、
前記第２のノードで、鍵生成メッセージが受信されるたびに、前記メッセージ認証コードを検証し、前記メッセージに含まれる前記リプレイ防止値が前記第２のノードに既に格納されているか否かを決定し、格納されている場合前記メッセージを拒絶する、ステップと、
を備える。
【００２６】
本発明のこの態様の実施形態は、有効なＧＢＡ手順に関して第２のノードに予め送られるメッセージに基づいて第２のノードがリプレイ攻撃を拒絶できるようにする。攻撃者がリプレイ防止値を以前未使用の値に単にインクリメントするだけであれば、第２のノードはこの変化を不正なＭＡＣ値に基づいて検出し、それ故攻撃を検出するであろう。また、第１のノードはＮＡＦサーバで、第２のノードがクライアントである場合があり、または第１および第２のノードが共にクライアントである場合もある。当然のことながら、本発明の第１から第５までの態様の特徴は第６の態様のそれらと組み合わされ得、また逆も同様である。
【図面の簡単な説明】
【００２７】
【図１】汎用ブートストラッピング・アーキテクチャに対する簡単なネットワーク・モデルを説明する図である。
【図２】セキュリティ・アソシエーションをクライアント（ＵＥ）とＮＡＦとの間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【図３】セキュリティ・アソシエーションをクライアント（ＵＥ）とＮＡＦとの間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【図４】セキュリティ・アソシエーションをクライアント（ＵＥ）とＮＡＦとの間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【図５】セキュリティ・アソシエーションをクライアント（ＵＥ）とＮＡＦとの間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【図６】セキュリティ・アソシエーションをクライアント（ＵＥ）とＮＡＦとの間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【図７】セキュリティ・アソシエーションを一対のクライアント（ＵＥＡおよびＵＥＢ）間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【図８】セキュリティ・アソシエーションを一対のクライアント（ＵＥＡおよびＵＥＢ）間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【発明を実施するための形態】
【００２８】
３Ｇネットワークに対する一般的な汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）を図１を参照して説明しており、種々のエンティティ間のインタフェース（Ｕａ、Ｕｂ、Ｚｎ、およびＺｈ）を説明している。本明細書は比較的高レベルにあり、そして実際の実装は異なって“見える”場合があるが、全く同じ一般的な機能性を採用しているということに留意しておくべきである。たとえば、（以下に説明されるであろうように）ＢＳＦがサービス鍵要求をＮＡＦから受信する場合、受信側のＢＳＦはアドレス解決ステップを実行してＮＡＦまたはクライアント（ＵＥ）に対して“在圏”ＢＳＦを識別しなければならず、そして受信側のＢＳＦが在圏ＢＳＦでないと、要求は在圏ＢＳＦに転送されるという可能性がある。
【００２９】
この議論はクライアントへのプッシュ型サービスの提供に関係している。通常、クライアントはサービス提供業者に事前登録しているであろうが、しかし特定の情報をプッシュ配信する主導権はサービス提供業者にある。そのような状況では、（セキュリティ・アソシエーションは通常存続期間が短いため）サービス提供業者およびクライアントは互いに確立されたセキュリティ・アソシエーションをまた持たないため、セキュリティ・アソシエーションを確立しなければならない。
【００３０】
本明細書で提案される第１の解決策は、ＮＡＦがＢＳＦにＮＡＦ（またはサービス）鍵を求めるという手法を取る。ＢＳＦはＮＡＦに、ＮＡＦ鍵をクライアントのトランザクション識別子（Ｂ−ＴＩＤ）および対応するネットワーク認証値（ＡＵＴＮ）と一緒に返信する。上述したように、Ｂ−ＴＩＤは符号化されたＲＡＮＤ値（ＮＡＩプレフィックスとして）を含み、それはクライアントにより基本鍵（ＫＳ）を得るために使用されることができる。ＮＡＦはこれからＢ−ＴＩＤ、ＡＵＴＮ、およびクライアントがＮＡＦ鍵を得るために必要とするＮＡＦ識別情報を含む更なるデータを含むメッセージを作成し、そしてこのメッセージをクライアントに送ることができる。このメッセージはＳＡの設定（すなわちサービス鍵の共有）をトリガするだけのメッセージであってもよく、またはサービス鍵で暗号化されたサービス・データ（すなわちペイロード・データ）を含むことができよう。どちらの場合も、値Ｂ−ＴＩＤ、ＡＵＴＮ、およびクライアントによりＫＳを生成するように要求される他のデータが平文で送られるが、メッセージ認証コードで“署名されて”いる。ＳＡ内の１以上の鍵はＨＳＳとＵＥとで共有される鍵を使用して得られること、およびＡＵＴＮはメッセージ内に含まれていることに留意されたい。したがって、たとえメッセージを完全性保護するために使用される鍵が確立されようとしているＳＡから得られるとしても、メッセージを“偽造する”ことはできない。
【００３１】
クライアントがメッセージを受信する場合、（符号化の逆をして）Ｂ−ＴＩＤのＲＡＮＤ部およびＡＵＴＮを検索し、それらをＵＳＩＭ／ＩＳＩＭに適用して基本鍵ＫＳを得る。それから更なるデータを使用してＮＡＦ鍵を得て、受信メッセージをＭＡＣを使用して検証する。
【００３２】
この手順に関連したシグナリング交換が図２に説明されている。
【００３３】
（クライアントにより要求される）更なるデータのＮＡＦによる操作を防止するために、ＢＳＦはデータにＫＳから派生したものを使用して署名することができる。これは、たとえばＮＡＦが鍵の存続期間を延長することを防止するために重要でありえよう。
【００３４】
上で提示した解決策はＮＡＦがクライアントに、セキュリティ・アソシエーションを２つのパーティの間に確立するために必要な情報をプッシュ配信できるようにする。このように、クライアントはこれらのタスクを行うためにＢＳＦとのコネクションを設定しなくてもよい。このことは極めて時間効率の良い解決策を表わしている。しかしながら、ＮＡＦが全ての鍵関連情報（鍵の存続期間、付加情報等）をＢＳＦからＵＥに保護された形式で中継することが必要である。Ｂ−ＴＩＤおよびその他のデータはその場合相当大きなデータ構造を備える可能性がある。このことは、メッセージ構造に組み込まれることができる大量のデータがクライアントとＮＡＦとの間で使用される場合、たとえばこの構造がＳＭＳである場合には解決が難しくなるであろう。
【００３５】
ＮＡＦとクライアントとの間でセキュリティ・アソシエーションを確立するために交換される要求データ量を減らすために、上記の解決策はＢＳＦによりＮＡＦに送られるデータからＡＵＴＮ値を除外することにより変更され得る。ＮＡＦは今度は、Ｂ−ＴＩＤおよび端末がＮＡＦ鍵を得るために必要とする他の必要なデータ（ＮＡＦ識別情報を含む）を含むメッセージを作成し、そしてそれをクライアントに送信する。再び、このメッセージは、セキュリティ・アソシエーションの設定をトリガするだけのメッセージであり得、または暗号化されたペイロード・データを含むことができる。
【００３６】
クライアントがＮＡＦからメッセージを受信する場合、Ｂ−ＴＩＤをそれに送信するＢＳＦに接続し、それ自身を認証して、Ｂ−ＴＩＤに関連する鍵素材、すなわち、たとえばＡＵＴＮを得るのに必要な残りの情報を要求する。この情報を受信し終わってから、サービス（ＮＡＦ）鍵を得て、そしてメッセージの完全性を検証する。クライアントはＢＳＦに接続しなければならないので、同時に鍵素材に関連する全ての情報、すなわち付加情報、鍵存続期間等を得ることができ、このようにして、ＮＡＦからクライアントに送信されなければならない“管理”情報の総量を削減する。
【００３７】
この手順に関連したシグナリング交換が、ＫＳ生成シナリオ（すなわち図２に類似）を想定して、図３に示されている。
【００３８】
状況次第では値ＲＡＮＤをＮＡＦに明らかにすることは望ましくない場合がある。これは、Ｂ−ＴＩＤを、実際のＲＡＮＤ値（または実効ＲＡＮＤ（ＲＡＮＤｅ））に対する参照を使用して形成することにより避けることができ、ＮＡＦは参照値のみを見るようになる。実効ＲＡＮＤ（ＲＡＮＤｅ）はその場合ＡＵＴＮと一緒にＢＳＦからクライアントに信号で伝えられなければならないであろう。この修正された手順が図４に説明されている。
【００３９】
図３および図４を参照して説明されている解決策の主たる利点は、ＢＳＦがクライアントにおける鍵生成を制御する更なる機会を有するであろうということである。クライアントは鍵を得るためにＡＵＴＮを必要とする。一方、クライアントはＢＳＦに接続し、Ｕｂインタフェース上でＧＢＡプロトコルの新しい変形を要するＢＳＦに向かって自身を認証しなければならないであろう。
【００４０】
図３および図４の解決策に対する１つの脅威は、攻撃者が一群の（有効なＢ−ＴＩＤを含むと主張する）メッセージを生成し、それらを異なるクライアントに送りサービス不能（ＤｏＳ）攻撃を開始する可能性があるということである。クライアントはメッセージを認証する手段（すなわちＡＵＴＮ）を有しないので、受信したメッセージを認証しようとしてＢＳＦに接続するであろう。そのような攻撃に対して反撃しない場合、ＢＳＦ側でかなりの資源を消耗するであろう。そのようなＤｏＳ攻撃をさらに困難にするには、クライアントがＮＡＦによりプッシュ配信されたメッセージのＭＡＣを直ちに確認し、ＢＳＦに接続しなくてもメッセージの正当性を立証することができるようにすることが望ましいであろう。これを達成するために、クライアントはメッセージのＭＡＣ化のために使用される鍵を得ることができなければならない。ＡＵＴＮはプッシュ配信されるメッセージのなかではクライアントに送られないので、この導出はＢ−ＴＩＤ内のＲＡＮＤ（または派生値、図４）のみに基づかなければならない。
【００４１】
１つの解決策はＢ−ＴＩＤ内のＲＡＮＤ（または派生値）を使用して２つの鍵Ｃｋ’およびＩｋ’をＢＳＦで得ることである。それからＢＳＦはこれらの鍵を使用してＭＡＣ鍵を得て、ＭＡＣ鍵をＮＡＦに送る。このインテグリティ鍵はまた、好適にはＮＡＦの識別情報に依存するべきである。ＮＡＦ鍵をインテグリティ鍵の導出の際に得るために必要とされるその他の必要情報の“フィンガープリント”を使用することは、全ての情報をＵＥに送らなくてもこれを達成する１つの方法となるであろう。ＮＡＦは第２の（短い）ＭＡＣをクライアントに送られるべき少なくとも一部のデータにわたって計算し、クライアントに送られるメッセージにＭＡＣを含める。クライアントで、ＵＳＩＭ／ＩＳＩＭはＡＫＡアルゴリズムを使用してＣｋ’およびＩｋ’およびそれ故第２のＭＡＣ鍵を生成し、それからクライアントはメッセージを検証することができる。あるいは、ＢＳＦは鍵Ｃｋ’およびＩｋ’をＮＡＦに提供することができ、ＮＡＦが第２のＭＡＣ鍵それ自身を生成できるようにする。これは（タイムスタンプを使用して扱われ得るが）古いメッセージのリプレイを阻止しない、しかし攻撃者がランダムなメッセージを生成するのを阻止する。
【００４２】
別の解決策は、図５のシグナリング図で説明され、ＢＳＦはＮＡＦ鍵それ自身を、所与のユーザに対するＰＵＳＨ鍵に対するＮＡＦ要求に応えて生成し、ＮＡＦに送るようなことはしない。その代わりに、ＢＳＦはＮＡＦ＿Ｋｅｙ（または関連する共有秘密Ｋｓに基づいた何らかの他の値）に基づいたＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開値ｇＮＡＦ Ｋｅｙおよび、関係するパーティの識別情報および鍵の使用目的に関連したデータ送る。ＮＡＦは、今度はそれ自身の秘密値ＲＡＮＤを選択し、そして秘密値に対応する公開Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ値ｇＲＡＮＤをＵＥに送信される情報に追加することができる。そして両方のパーティは共通の共有鍵、Ｓ＿Ｋｅｙ＝ｇＲＡＮＤ＊ＮＡＦ Ｋｅｙを得ることができる。Ｓ＿ＫｅｙはＭＡＣに鍵を掛けるのに使用される。Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ方式は異なる種別のグループにわたって実装され得ることが知られている。ここで、標準的な表記法を使用しており、グループはＺｐ、使用される生成ｇ要素はｇと表わされる。
【００４３】
さらなる別の解決策は、図６のシグナリング図に説明され、ＮＡＦが所与のユーザに対するＰＵＳＨ鍵を要求する場合、ＢＳＦは標準的なＮＡＦ鍵を含まず、その代わりにＵＥ識別情報とＮＡＦ識別情報と（そして任意のさらなるデータ）の両方に依存する鍵を導出する。そのような鍵は、図では“ＮＡＦ＿ＵＥ＿Ｋｅｙ”と表示されている。ＢＳＦからＮＡＦへの鍵の配信を保護にするために、ＢＳＦはＢＳＦへのメッセージにＮＡＦ＿ＵＥ＿Ｋｅｙを使用して計算されたＭＡＣを含める。
【００４４】
上述の議論は、ユーザおよびサービス・ノードへのサービス関連の鍵の提供に対する本発明の適用を考察してきた。本発明の別の適用は、１つのクライアント端末がピア・クライアント端末にメッセージを安全な方法でプッシュ配信できるようにクライアント端末への鍵の提供に関連する、すなわちピア・ツー・ピア（ｐ２ｐ）鍵管理に関連する。
【００４５】
１つの解決策に従って、開始側のＵＥ、すなわちＵＥＡは図７で一般的に説明される方法を採用する。この手法はＢＳＦＡとＢＳＦＢとの間の明確な信頼関係に依存している。開始側のパーティはまずホーム・ネットワークのＢＳＦＡを用いる標準的なＧＢＡ手順を行い、基本鍵ＫＳＡを得る。それからＵＥＡは、基本鍵を使用してＵＥＡがメッセージをプッシュ配信しようと望むもう一方のパーティＵＥＢに関係するＲＡＮＤを導出する。このことはＮＡＦ鍵が導出されるのと同様になされることができる。ＵＥＡにより行われる第２の動作はＵＥＢに対する鍵情報を要求することである。この要求は、両方のクライアントの識別情報を含み、ＢＳＦＡに送信され、要求をＵＥＢのホーム・ネットワーク内のＢＳＦ、すなわちＢＳＦＢに転送する。
【００４６】
ＢＳＦＢはＵＥＡに、ＢＳＦＡを経由して、ＵＥＢに対するＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開値、すなわちｇＮＡＦ Ｋｅｙを返信する。それはまた、Ｂ−ＴＩＤ（ＮＡＦ＿Ｋｅｙを生成するのに使用されるＲＡＮＤ値を含む）、ＡＵＴＮおよび所要のさらなるデータを返信する。それから開始側のパーティＵＥＡは、自身の公開Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ値、ｇＲＡＮＤと、ＫＳＢ、関連ＮＡＦ＿Ｋｅｙ、そしてセッション鍵ｇＲＡＮＤ＊ＮＡＦ Ｋｅｙを導出するために受信者により必要とされる情報と、を含むメッセージを形成する。ＵＥＡは勿論同一のセッション鍵を得ることができる。
【００４７】
別のｐ２ｐ鍵管理の解決策は図８に説明されており、そしてＢＳＦＢがピアにより共有されるべき鍵を生成することを要求する。起動側のパーティＵＥＡによる第１の動作は一方のパーティＵＥＢに対する鍵を要求することである。この要求は起動側パーティのＢＳＦＡに送られ、要求を受信側パーティのＢＳＦＢに転送する。起動側のパーティは識別情報のほかに要求内の受信側パーティのＢＳＦＢの識別情報をも含み、そしてＢＳＦＢは共有されるべき鍵、すなわちＮＡＦ＿ＵＥ＿Ｋｅｙを得る。得られた鍵はＢ−ＴＩＤ、ＡＵＴＮ等と一緒にそれからＵＥＡに配信される。
【００４８】
この方式を用いて、受信側のパーティは、送信側の主張した識別情報の間接的な検証を受信し、この識別情報はＮＡＦ＿ＵＥ＿Ｋｅｙの導出に使用される。受信側のパーティはまた、ＢＳＦＢが全データをカバーする“ＮＡＦ＿Ｋｅｙ”に基づくＭＡＣを含む場合、上述のように明確な認証を得ることができよう。
【００４９】
当業者には当然のことなから、本発明の要旨を逸脱しない範囲で様々な変更が上述した実施形態になされ得る。たとえば、上記で提示された解決策はＧＢＡに関係しているが、本発明は、情報がサービス提供業者からプッシュ配信されることになっているような、そしてサービス提供業者およびクライアントが共通秘密を共有しないようなアーキテクチャへの一般的な適用性を有する。別の変更では、複数の解決策が並行して実装され、ＢＳＦに送られる認証要求がいずれの解決策をＮＡＦ／ＵＥが採用することになるかを示す選択肢を含む。
【技術分野】
【０００１】
本発明はプッシュ型サービスを配信するためにクライアント端末とサービス・ノードとの間にセキュリティ・アソシエーションを確立するための方法および装置に関するものであり、必ずしもそうではないが、特に、汎用ブートストラッピング・アーキテクチャを採用する方法および装置に関するものである。
【背景技術】
【０００２】
ユーザ端末へのサービスの提供を容易にするために、３Ｇネットワークのようなモバイル・ネットワークは大抵、クライアント端末（すなわち移動端末）とサービスを提供するネットワーク基盤サービス・ノードとの間に安全な通信チャネル、すなわち“セキュリティ・アソシエーション”の確立を必要とする。汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）は３ＧＰＰ技術仕様書ＴＳ３３．２２０で論じられており、そしてクライアント端末（ＵＥ）がネットワーク認証機能（サービス・ノード）により認証されるメカニズム、および、クライアント端末とネットワーク認証機能との間での使用のために得られる安全なセッション鍵を提供する。このアーキテクチャに対する簡単なネットワーク・モデルが図１に描かれている。このメカニズムは、クライアント端末がクライアントのホーム・ネットワークのブートストラッピング・サーバ機能（ＢＳＦ）に、クライアント端末のＵＳＩＭと加入者のホーム・ネットワークのホーム加入者システム（ＨＳＳ）との間で共有される秘密Ｋに基づいて、認証されるようにできる周知の認証／暗号鍵配送方式（ＡＫＡ）手順［３ＧＰＰ ＴＳ３３．１０２］でブートする。ＡＫＡ手順はさらに、セッション鍵を確立し、この鍵は後でクライアント端末とネットワーク・アプリケーション機能（ＮＡＦ）との間で適用される。クライアント端末およびＮＡＦがＢＳＦからセッション鍵を得ようとする場合、ＮＡＦはトランザクション識別子をＢＳＦに送り、トランザクション識別子にはＢＳＦがクライアント端末を識別するために使用するインデックスおよびＮＡＦに転送する適切な鍵を含んでいる。
【０００３】
ＧＢＡメカニズムに従って、ＵＥは鍵の生成処理を、ユーザ識別情報を含む要求をＢＳＦに送ることにより開始する。要求はまたＮＡＦの識別情報を含む。ＢＳＦは認証ベクトルをホーム加入者システム（ＨＳＳ）から読み出し、各々の認証ベクトルは乱数ＲＡＮＤ、想定される認証応答ＸＲＥＳ、暗号鍵ＣＫ、インテグリティ鍵ＩＫおよび認証トークンＡＵＴＮで構成されている。ＢＳＦは、認証ベクトルに含まれるＣＫおよびＩＫを連結することにより鍵素材ＫＳを生成する。ＢＳＦは鍵識別子Ｂ−ＴＩＤを、ＲＡＮＤ値をｂａｓｅ６４符号化し、そして符号化された値をＢＳＦのサーバ名と組み合わせることにより、すなわち
ｂａｓｅ６４ｅｎｃｏｄｅ（ＲＡＮＤ）＠ＢＳＦ＿ｓｅｒｖｅｒｓ＿ｄｏｍａｉｎ＿ｎａｍｅ
としてＮＡＩフォーマットで生成する。
【０００４】
ＢＳＦは鍵ＫＳをトランザクション識別子Ｂ−ＴＩＤおよびＮＡＦ識別情報と併せて保持する。Ｂ−ＴＩＤおよびＡＵＴＮはＢＳＦによりＵＥに送られ、クライアント端末のＵＳＩＭは、値ＡＵＴＮを共有秘密Ｋを使用して確認し、そして想定される認証応答ＸＲＥＳの要約をＢＳＦに戻す。ＵＳＩＭはまた、鍵素材ＫＳを秘密Ｋおよび（Ｂ−ＴＩＤから元に戻された）値ＲＡＮＤを使用して生成する。
【０００５】
この手順の完了に続き、ＵＥはＮＡＦに、受信したＢ−ＴＩＤを伝える。ＮＡＦおよびＢＳＦは相互に認証され、そしてＮＡＦはＢＳＦに受信したＢ−ＴＩＤをそれ自身の識別情報と一緒に送る。ＢＳＦはＢ−ＴＩＤおよびＮＡＦの識別情報を使用して正しい鍵ＫＳを検索し、そしてＫＳを使用してＮＡＦ鍵を生成する。ＮＡＦ識別情報のような他の情報はまた、ＮＡＦ鍵の生成の際に使用される。生成されたＮＡＦ鍵はＮＡＦに戻される。ＵＥは、同様にＮＡＦ鍵を、既に生成されている鍵ＫＳを使用して生成することができる。
【０００６】
ＧＢＡメカニズムが初めて実行されてから、ＵＥと同じまたは異なるＮＡＦとの間にセキュリティ・アソシエーションを確立する後続の要求は、鍵が失効していなければ、既に確立された鍵素材ＫＳを使用することができる。しかしながら、これはなお、Ｂ−ＴＩＤをＮＡＦに送ることによりＵＥがセキュリティ・アソシエーションの確立要求を開始することを要求するであろう。
【発明の概要】
【０００７】
ＮＡＦがＵＥとのセキュリティ・アソシエーションの確立を開始するようにできることが望ましい場合がある。たとえば、プッシュ型のサービスが考えられ、それは予めサービスに対して登録を済ませているユーザに、ニュース、スポーツおよび金融等の情報を配信する。これを達成する標準的な操作手順は、サービス提供業者がＳＭＳメッセージを、ユーザに安全なコネクションをオープンするように要求するＵＥに送ることであろう。しかしながら、ＳＭＳが巧妙に操作され、無認可パーティにより送られ、リプレイされる恐れのあるこのモデルに関連する多くの脅威がある。セキュリティ・アソシエーションが存在していたか、またはサービス・ノードが実際のサービス・データが送られるまでにセキュリティ・アソシエーションを開始できていれば、セキュリティ手順はこれに基づくことができ、そして大抵の問題は軽減されることができよう。
【０００８】
本発明の第１の態様では、第１のノードから第２のノードに情報をプッシュ配信するために前記第１のノードと前記第２のノードとの間にセキュリティ・アソシエーションを確立する方法が提供され、前記第２のノードおよび鍵生成機能は基本秘密を共有しており、該方法は、
サービス鍵の生成および提供の要求を前記第１のノードから前記鍵生成機能に送信するステップであって、前記要求は前記第１および第２のノードの識別情報を含む、ステップと、
前記第１のノードの前記識別情報と前記基本秘密と付加情報とを使用して前記鍵生成機能でサービス鍵を生成し、該サービス鍵を前記付加情報と共に前記第１のノードに送信するステップと、
前記付加情報と前記第１のノードの前記識別情報とを前記第１のノードから前記第２のノードに転送するステップと、
受信した前記付加情報と前記第１のユーザの識別情報と前記基本秘密とを使用して前記第２のノードで前記サービス鍵を生成するステップと、
を備える。
【０００９】
当然のことながら、鍵生成機能はスタンドアロン・ノードであってもよく、また、分散サーバであってもよい。汎用ブートストラッピング・アーキテクチャを採用する３Ｇネットワークの場合、ブートストラッピング・サーバ機能およびホーム加入者サーバはともに、鍵生成機能を提供することができ、ブートストラッピング・サーバ機能はサービス・ノードとおよびホーム加入者サーバと通信する。２Ｇネットワークの場合、鍵生成機能はブートストラッピング・サーバ機能とＡｕＣサーバとの組み合わせであることができる。
【００１０】
汎用ブートストラッピング・アーキテクチャを採用する３Ｇネットワークの場合、サービス・ノードはネットワーク・アプリケーション機能を備える。サービス鍵を鍵生成機能で生成するステップは：
前記基本秘密を使用して鍵素材ＫＳを生成するステップと、
前記鍵素材ＫＳと前記サービス・ノードの前記識別情報と前記付加情報とを使用して前記サービス鍵を生成するステップと、
を備える。
【００１１】
クライアントでサービス鍵を生成するステップはまた、これらの２つのステップを備える。
【００１２】
鍵サーバでサービス鍵を生成する前記ステップは、サービス・ノードからクライアントに送信されたもの以外の他の値を利用する場合がある。クライアントは鍵サーバからそれらの他の値のうちのいくつかを得ることができる。
【００１３】
前記付加情報は、１以上の、
ランダム値；
タイムスタンプ；
シーケンス番号；
他の識別子
を含む。汎用ブートストラッピング・アーキテクチャの場合、前記ランダム値はＲＡＮＤパラメータであり、そしてＢ−ＴＩＤにより運ばれる。
【００１４】
前記付加情報はＮＡＩフォーマットのトランザクション識別子を含むことができ、そして符号化ランダム値を含む。
【００１５】
前記付加情報はサービス・ノードからクライアントにサービス・データをまた含むメッセージで転送されることができ、サービス・データはサービス鍵で暗号化されており、クライアントは一旦サービス鍵を生成していると暗号化されたデータを復号することができる。
【００１６】
本発明の１つの実施形態では、鍵生成機能はサービス・ノードにネットワーク認証値を送る。サービス・ノードはこの値をクライアントに前記付加情報と一緒に転送する。クライアントは基本秘密および認証値を使用して鍵生成機能を認証する。鍵生成機能が認証されている場合に限り、クライアントはサービス鍵を生成し使用する。
【００１７】
本発明の別の実施形態では、クライアントは認証値を鍵生成機能に、前記付加情報をサービス・ノードから受信し終わってから要求する。クライアントが鍵生成機能を認証している場合のみ、サービス鍵が生成され使用される。
【００１８】
端末はサービス・ノードからメッセージ認証コードを受信するための手段を備えることができ、端末は１以上の認証鍵を少なくとも一部の鍵生成情報から生成し、１以上の認証鍵を使用してメッセージ認証コードを認証するための手段を備える。生成手段はＵＳＩＭ／ＩＳＩＭである場合がある。
【００１９】
前記サービス鍵は第２のノードに対するＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵であることができ、方法はさらに第１のノードに第１のノードに対するＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵を提供し、および第１のノードに対するＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵を第２のノードに送るステップを備え、前記セキュリティ・アソシエーションが２つのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵に基づいて確立される。
【００２０】
本発明の第２の態様では、安全な通信リンクを経由してプッシュ型サービスをクライアントに配信するためのサービス・ノードが提供され、サービス・ノードは、
サービス鍵の生成および提供の要求を鍵生成機能に送信する手段であって、前記要求は前記クライアントおよび前記サービス・ノードを識別する、手段と、
前記鍵生成機能からサービス鍵を付加情報と共に受信する手段と、
前記付加情報を前記クライアントに転送する手段と、
前記サービス鍵を使用してサービス情報の暗号化および／または完全性保護を行い、該暗号化および／または完全性保護された情報を前記クライアントに送信する手段と、
を備える。
【００２１】
汎用ブートストラッピング・アーキテクチャの場合、前記付加情報はＲＡＮＤ値を含むＢ−ＴＩＤを備える。転送するための前記手段はまた、クライアントにサービス・ノードの識別情報を転送するように構成される。
【００２２】
本発明の第３の態様では、サービス・ノードにより配信されるプッシュ型サービスを受信するためのクライアント端末が提供され、クライアント端末は、
鍵生成機能との共有秘密を格納する記憶手段と、
前記サービス・ノードから鍵生成情報を受信する手段と、
前記共有秘密と前記鍵生成情報とを使用してサービス鍵を生成する手段と、
前記サービス・ノードとの通信の復号および／または完全性検証のために前記サービス鍵を使用する手段と、
を備える。
【００２３】
本発明の第４の態様では、サービス・ノードからクライアントに情報をプッシュ配信するために前記クライアントと前記サービス・ノードとの間にセキュリティ・アソシエーションを確立する際に使用する鍵生成機能が提供され、鍵サーバは、
前記クライアントと共有される秘密を格納する記憶手段と、
サービス鍵の生成および提供の要求を前記サービス・ノードから受信する手段であって、前記要求は前記クライアントおよび前記サービス・ノードを識別する、手段と、
前記サービス・ノードの前記クライアントの前記識別情報と前記基本秘密と付加情報とを使用してサービス鍵を生成し、該サービス鍵を前記付加情報と共に前記サービス・ノードに送信する手段と、
を備える。
【００２４】
本発明の第５の態様では、第１のクライアントから第２のクライアントに情報をプッシュ配信するために前記第１および第２のクライアントの間でセキュリティ・アソシエーションを確立する方法が提供され、前記第１および第２のクライアントはそれぞれ第１および第２の鍵サーバとの信頼関係を有しそれぞれの鍵サーバと秘密を共有しており、該方法は、
サービス鍵の生成および提供の要求を前記第１の鍵サーバを経由して前記第１のクライアントから前記第２の鍵サーバに送信するステップであって、前記要求は前記第１および第２のノードを識別する、ステップと、
前記第１のノードの前記識別情報と前記基本秘密と付加情報とを使用して前記第２の鍵サーバでサービス鍵を生成し、該サービス鍵を前記付加情報と共に前記第１のノードに送信するステップと、
前記付加情報を前記第１のノードから前記第２のノードに転送するステップと、
前記第２のノードで、受信した前記付加情報と前記基本秘密とを使用して前記サービス鍵を生成するステップと、
を備える。
【００２５】
本発明の第６の態様では、リプレイ攻撃に対してノードを保護する方法が提供され、該方法は、
ブートストラッピング・サーバ機能でサービス鍵を生成するステップと、
前記サービス鍵を該サービス鍵の生成に必要な情報と共に第１のノードに提供するステップと、
前記第１のノードから前記第２のノードに鍵生成メッセージを送信するステップであって、前記メッセージは前記情報とリプレイ防止値と該リプレイ防止値を含む前記メッセージ本体にわたって計算されるメッセージ認証コードとを含み、前記リプレイ防止値は前記手順の実行のたびにインクリメントまたはデクリメントされる、ステップと、
前記第２のノードで前記鍵生成メッセージを受信し、該鍵生成メッセージに含まれる前記リプレイ防止値を格納するステップと、
前記第２のノードで、鍵生成メッセージが受信されるたびに、前記メッセージ認証コードを検証し、前記メッセージに含まれる前記リプレイ防止値が前記第２のノードに既に格納されているか否かを決定し、格納されている場合前記メッセージを拒絶する、ステップと、
を備える。
【００２６】
本発明のこの態様の実施形態は、有効なＧＢＡ手順に関して第２のノードに予め送られるメッセージに基づいて第２のノードがリプレイ攻撃を拒絶できるようにする。攻撃者がリプレイ防止値を以前未使用の値に単にインクリメントするだけであれば、第２のノードはこの変化を不正なＭＡＣ値に基づいて検出し、それ故攻撃を検出するであろう。また、第１のノードはＮＡＦサーバで、第２のノードがクライアントである場合があり、または第１および第２のノードが共にクライアントである場合もある。当然のことながら、本発明の第１から第５までの態様の特徴は第６の態様のそれらと組み合わされ得、また逆も同様である。
【図面の簡単な説明】
【００２７】
【図１】汎用ブートストラッピング・アーキテクチャに対する簡単なネットワーク・モデルを説明する図である。
【図２】セキュリティ・アソシエーションをクライアント（ＵＥ）とＮＡＦとの間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【図３】セキュリティ・アソシエーションをクライアント（ＵＥ）とＮＡＦとの間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【図４】セキュリティ・アソシエーションをクライアント（ＵＥ）とＮＡＦとの間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【図５】セキュリティ・アソシエーションをクライアント（ＵＥ）とＮＡＦとの間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【図６】セキュリティ・アソシエーションをクライアント（ＵＥ）とＮＡＦとの間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【図７】セキュリティ・アソシエーションを一対のクライアント（ＵＥＡおよびＵＥＢ）間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【図８】セキュリティ・アソシエーションを一対のクライアント（ＵＥＡおよびＵＥＢ）間に確立するためのそれぞれの手順に関連するシグナリングフローを説明する図である。
【発明を実施するための形態】
【００２８】
３Ｇネットワークに対する一般的な汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）を図１を参照して説明しており、種々のエンティティ間のインタフェース（Ｕａ、Ｕｂ、Ｚｎ、およびＺｈ）を説明している。本明細書は比較的高レベルにあり、そして実際の実装は異なって“見える”場合があるが、全く同じ一般的な機能性を採用しているということに留意しておくべきである。たとえば、（以下に説明されるであろうように）ＢＳＦがサービス鍵要求をＮＡＦから受信する場合、受信側のＢＳＦはアドレス解決ステップを実行してＮＡＦまたはクライアント（ＵＥ）に対して“在圏”ＢＳＦを識別しなければならず、そして受信側のＢＳＦが在圏ＢＳＦでないと、要求は在圏ＢＳＦに転送されるという可能性がある。
【００２９】
この議論はクライアントへのプッシュ型サービスの提供に関係している。通常、クライアントはサービス提供業者に事前登録しているであろうが、しかし特定の情報をプッシュ配信する主導権はサービス提供業者にある。そのような状況では、（セキュリティ・アソシエーションは通常存続期間が短いため）サービス提供業者およびクライアントは互いに確立されたセキュリティ・アソシエーションをまた持たないため、セキュリティ・アソシエーションを確立しなければならない。
【００３０】
本明細書で提案される第１の解決策は、ＮＡＦがＢＳＦにＮＡＦ（またはサービス）鍵を求めるという手法を取る。ＢＳＦはＮＡＦに、ＮＡＦ鍵をクライアントのトランザクション識別子（Ｂ−ＴＩＤ）および対応するネットワーク認証値（ＡＵＴＮ）と一緒に返信する。上述したように、Ｂ−ＴＩＤは符号化されたＲＡＮＤ値（ＮＡＩプレフィックスとして）を含み、それはクライアントにより基本鍵（ＫＳ）を得るために使用されることができる。ＮＡＦはこれからＢ−ＴＩＤ、ＡＵＴＮ、およびクライアントがＮＡＦ鍵を得るために必要とするＮＡＦ識別情報を含む更なるデータを含むメッセージを作成し、そしてこのメッセージをクライアントに送ることができる。このメッセージはＳＡの設定（すなわちサービス鍵の共有）をトリガするだけのメッセージであってもよく、またはサービス鍵で暗号化されたサービス・データ（すなわちペイロード・データ）を含むことができよう。どちらの場合も、値Ｂ−ＴＩＤ、ＡＵＴＮ、およびクライアントによりＫＳを生成するように要求される他のデータが平文で送られるが、メッセージ認証コードで“署名されて”いる。ＳＡ内の１以上の鍵はＨＳＳとＵＥとで共有される鍵を使用して得られること、およびＡＵＴＮはメッセージ内に含まれていることに留意されたい。したがって、たとえメッセージを完全性保護するために使用される鍵が確立されようとしているＳＡから得られるとしても、メッセージを“偽造する”ことはできない。
【００３１】
クライアントがメッセージを受信する場合、（符号化の逆をして）Ｂ−ＴＩＤのＲＡＮＤ部およびＡＵＴＮを検索し、それらをＵＳＩＭ／ＩＳＩＭに適用して基本鍵ＫＳを得る。それから更なるデータを使用してＮＡＦ鍵を得て、受信メッセージをＭＡＣを使用して検証する。
【００３２】
この手順に関連したシグナリング交換が図２に説明されている。
【００３３】
（クライアントにより要求される）更なるデータのＮＡＦによる操作を防止するために、ＢＳＦはデータにＫＳから派生したものを使用して署名することができる。これは、たとえばＮＡＦが鍵の存続期間を延長することを防止するために重要でありえよう。
【００３４】
上で提示した解決策はＮＡＦがクライアントに、セキュリティ・アソシエーションを２つのパーティの間に確立するために必要な情報をプッシュ配信できるようにする。このように、クライアントはこれらのタスクを行うためにＢＳＦとのコネクションを設定しなくてもよい。このことは極めて時間効率の良い解決策を表わしている。しかしながら、ＮＡＦが全ての鍵関連情報（鍵の存続期間、付加情報等）をＢＳＦからＵＥに保護された形式で中継することが必要である。Ｂ−ＴＩＤおよびその他のデータはその場合相当大きなデータ構造を備える可能性がある。このことは、メッセージ構造に組み込まれることができる大量のデータがクライアントとＮＡＦとの間で使用される場合、たとえばこの構造がＳＭＳである場合には解決が難しくなるであろう。
【００３５】
ＮＡＦとクライアントとの間でセキュリティ・アソシエーションを確立するために交換される要求データ量を減らすために、上記の解決策はＢＳＦによりＮＡＦに送られるデータからＡＵＴＮ値を除外することにより変更され得る。ＮＡＦは今度は、Ｂ−ＴＩＤおよび端末がＮＡＦ鍵を得るために必要とする他の必要なデータ（ＮＡＦ識別情報を含む）を含むメッセージを作成し、そしてそれをクライアントに送信する。再び、このメッセージは、セキュリティ・アソシエーションの設定をトリガするだけのメッセージであり得、または暗号化されたペイロード・データを含むことができる。
【００３６】
クライアントがＮＡＦからメッセージを受信する場合、Ｂ−ＴＩＤをそれに送信するＢＳＦに接続し、それ自身を認証して、Ｂ−ＴＩＤに関連する鍵素材、すなわち、たとえばＡＵＴＮを得るのに必要な残りの情報を要求する。この情報を受信し終わってから、サービス（ＮＡＦ）鍵を得て、そしてメッセージの完全性を検証する。クライアントはＢＳＦに接続しなければならないので、同時に鍵素材に関連する全ての情報、すなわち付加情報、鍵存続期間等を得ることができ、このようにして、ＮＡＦからクライアントに送信されなければならない“管理”情報の総量を削減する。
【００３７】
この手順に関連したシグナリング交換が、ＫＳ生成シナリオ（すなわち図２に類似）を想定して、図３に示されている。
【００３８】
状況次第では値ＲＡＮＤをＮＡＦに明らかにすることは望ましくない場合がある。これは、Ｂ−ＴＩＤを、実際のＲＡＮＤ値（または実効ＲＡＮＤ（ＲＡＮＤｅ））に対する参照を使用して形成することにより避けることができ、ＮＡＦは参照値のみを見るようになる。実効ＲＡＮＤ（ＲＡＮＤｅ）はその場合ＡＵＴＮと一緒にＢＳＦからクライアントに信号で伝えられなければならないであろう。この修正された手順が図４に説明されている。
【００３９】
図３および図４を参照して説明されている解決策の主たる利点は、ＢＳＦがクライアントにおける鍵生成を制御する更なる機会を有するであろうということである。クライアントは鍵を得るためにＡＵＴＮを必要とする。一方、クライアントはＢＳＦに接続し、Ｕｂインタフェース上でＧＢＡプロトコルの新しい変形を要するＢＳＦに向かって自身を認証しなければならないであろう。
【００４０】
図３および図４の解決策に対する１つの脅威は、攻撃者が一群の（有効なＢ−ＴＩＤを含むと主張する）メッセージを生成し、それらを異なるクライアントに送りサービス不能（ＤｏＳ）攻撃を開始する可能性があるということである。クライアントはメッセージを認証する手段（すなわちＡＵＴＮ）を有しないので、受信したメッセージを認証しようとしてＢＳＦに接続するであろう。そのような攻撃に対して反撃しない場合、ＢＳＦ側でかなりの資源を消耗するであろう。そのようなＤｏＳ攻撃をさらに困難にするには、クライアントがＮＡＦによりプッシュ配信されたメッセージのＭＡＣを直ちに確認し、ＢＳＦに接続しなくてもメッセージの正当性を立証することができるようにすることが望ましいであろう。これを達成するために、クライアントはメッセージのＭＡＣ化のために使用される鍵を得ることができなければならない。ＡＵＴＮはプッシュ配信されるメッセージのなかではクライアントに送られないので、この導出はＢ−ＴＩＤ内のＲＡＮＤ（または派生値、図４）のみに基づかなければならない。
【００４１】
１つの解決策はＢ−ＴＩＤ内のＲＡＮＤ（または派生値）を使用して２つの鍵Ｃｋ’およびＩｋ’をＢＳＦで得ることである。それからＢＳＦはこれらの鍵を使用してＭＡＣ鍵を得て、ＭＡＣ鍵をＮＡＦに送る。このインテグリティ鍵はまた、好適にはＮＡＦの識別情報に依存するべきである。ＮＡＦ鍵をインテグリティ鍵の導出の際に得るために必要とされるその他の必要情報の“フィンガープリント”を使用することは、全ての情報をＵＥに送らなくてもこれを達成する１つの方法となるであろう。ＮＡＦは第２の（短い）ＭＡＣをクライアントに送られるべき少なくとも一部のデータにわたって計算し、クライアントに送られるメッセージにＭＡＣを含める。クライアントで、ＵＳＩＭ／ＩＳＩＭはＡＫＡアルゴリズムを使用してＣｋ’およびＩｋ’およびそれ故第２のＭＡＣ鍵を生成し、それからクライアントはメッセージを検証することができる。あるいは、ＢＳＦは鍵Ｃｋ’およびＩｋ’をＮＡＦに提供することができ、ＮＡＦが第２のＭＡＣ鍵それ自身を生成できるようにする。これは（タイムスタンプを使用して扱われ得るが）古いメッセージのリプレイを阻止しない、しかし攻撃者がランダムなメッセージを生成するのを阻止する。
【００４２】
別の解決策は、図５のシグナリング図で説明され、ＢＳＦはＮＡＦ鍵それ自身を、所与のユーザに対するＰＵＳＨ鍵に対するＮＡＦ要求に応えて生成し、ＮＡＦに送るようなことはしない。その代わりに、ＢＳＦはＮＡＦ＿Ｋｅｙ（または関連する共有秘密Ｋｓに基づいた何らかの他の値）に基づいたＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開値ｇＮＡＦ Ｋｅｙおよび、関係するパーティの識別情報および鍵の使用目的に関連したデータ送る。ＮＡＦは、今度はそれ自身の秘密値ＲＡＮＤを選択し、そして秘密値に対応する公開Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ値ｇＲＡＮＤをＵＥに送信される情報に追加することができる。そして両方のパーティは共通の共有鍵、Ｓ＿Ｋｅｙ＝ｇＲＡＮＤ＊ＮＡＦ Ｋｅｙを得ることができる。Ｓ＿ＫｅｙはＭＡＣに鍵を掛けるのに使用される。Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ方式は異なる種別のグループにわたって実装され得ることが知られている。ここで、標準的な表記法を使用しており、グループはＺｐ、使用される生成ｇ要素はｇと表わされる。
【００４３】
さらなる別の解決策は、図６のシグナリング図に説明され、ＮＡＦが所与のユーザに対するＰＵＳＨ鍵を要求する場合、ＢＳＦは標準的なＮＡＦ鍵を含まず、その代わりにＵＥ識別情報とＮＡＦ識別情報と（そして任意のさらなるデータ）の両方に依存する鍵を導出する。そのような鍵は、図では“ＮＡＦ＿ＵＥ＿Ｋｅｙ”と表示されている。ＢＳＦからＮＡＦへの鍵の配信を保護にするために、ＢＳＦはＢＳＦへのメッセージにＮＡＦ＿ＵＥ＿Ｋｅｙを使用して計算されたＭＡＣを含める。
【００４４】
上述の議論は、ユーザおよびサービス・ノードへのサービス関連の鍵の提供に対する本発明の適用を考察してきた。本発明の別の適用は、１つのクライアント端末がピア・クライアント端末にメッセージを安全な方法でプッシュ配信できるようにクライアント端末への鍵の提供に関連する、すなわちピア・ツー・ピア（ｐ２ｐ）鍵管理に関連する。
【００４５】
１つの解決策に従って、開始側のＵＥ、すなわちＵＥＡは図７で一般的に説明される方法を採用する。この手法はＢＳＦＡとＢＳＦＢとの間の明確な信頼関係に依存している。開始側のパーティはまずホーム・ネットワークのＢＳＦＡを用いる標準的なＧＢＡ手順を行い、基本鍵ＫＳＡを得る。それからＵＥＡは、基本鍵を使用してＵＥＡがメッセージをプッシュ配信しようと望むもう一方のパーティＵＥＢに関係するＲＡＮＤを導出する。このことはＮＡＦ鍵が導出されるのと同様になされることができる。ＵＥＡにより行われる第２の動作はＵＥＢに対する鍵情報を要求することである。この要求は、両方のクライアントの識別情報を含み、ＢＳＦＡに送信され、要求をＵＥＢのホーム・ネットワーク内のＢＳＦ、すなわちＢＳＦＢに転送する。
【００４６】
ＢＳＦＢはＵＥＡに、ＢＳＦＡを経由して、ＵＥＢに対するＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開値、すなわちｇＮＡＦ Ｋｅｙを返信する。それはまた、Ｂ−ＴＩＤ（ＮＡＦ＿Ｋｅｙを生成するのに使用されるＲＡＮＤ値を含む）、ＡＵＴＮおよび所要のさらなるデータを返信する。それから開始側のパーティＵＥＡは、自身の公開Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ値、ｇＲＡＮＤと、ＫＳＢ、関連ＮＡＦ＿Ｋｅｙ、そしてセッション鍵ｇＲＡＮＤ＊ＮＡＦ Ｋｅｙを導出するために受信者により必要とされる情報と、を含むメッセージを形成する。ＵＥＡは勿論同一のセッション鍵を得ることができる。
【００４７】
別のｐ２ｐ鍵管理の解決策は図８に説明されており、そしてＢＳＦＢがピアにより共有されるべき鍵を生成することを要求する。起動側のパーティＵＥＡによる第１の動作は一方のパーティＵＥＢに対する鍵を要求することである。この要求は起動側パーティのＢＳＦＡに送られ、要求を受信側パーティのＢＳＦＢに転送する。起動側のパーティは識別情報のほかに要求内の受信側パーティのＢＳＦＢの識別情報をも含み、そしてＢＳＦＢは共有されるべき鍵、すなわちＮＡＦ＿ＵＥ＿Ｋｅｙを得る。得られた鍵はＢ−ＴＩＤ、ＡＵＴＮ等と一緒にそれからＵＥＡに配信される。
【００４８】
この方式を用いて、受信側のパーティは、送信側の主張した識別情報の間接的な検証を受信し、この識別情報はＮＡＦ＿ＵＥ＿Ｋｅｙの導出に使用される。受信側のパーティはまた、ＢＳＦＢが全データをカバーする“ＮＡＦ＿Ｋｅｙ”に基づくＭＡＣを含む場合、上述のように明確な認証を得ることができよう。
【００４９】
当業者には当然のことなから、本発明の要旨を逸脱しない範囲で様々な変更が上述した実施形態になされ得る。たとえば、上記で提示された解決策はＧＢＡに関係しているが、本発明は、情報がサービス提供業者からプッシュ配信されることになっているような、そしてサービス提供業者およびクライアントが共通秘密を共有しないようなアーキテクチャへの一般的な適用性を有する。別の変更では、複数の解決策が並行して実装され、ＢＳＦに送られる認証要求がいずれの解決策をＮＡＦ／ＵＥが採用することになるかを示す選択肢を含む。
【特許請求の範囲】
【請求項１】
第１のノードから第２のノードに情報をプッシュ配信するために前記第１のノードと前記第２のノードとの間にセキュリティ・アソシエーションを確立する方法であって、前記第２のノードおよび鍵生成機能は基本秘密を共有しており、該方法は、
サービス鍵の生成および提供の要求を前記第１のノードから前記鍵生成機能に送信するステップであって、前記要求は前記第１および第２のノードの識別情報を含む、ステップと、
前記第１のノードの前記識別情報と前記基本秘密と付加情報とを使用して前記鍵生成機能でサービス鍵を生成し、該サービス鍵を前記付加情報と共に前記第１のノードに送信するステップと、
前記付加情報と前記第１のノードの前記識別情報とを前記第１のノードから前記第２のノードに転送するステップと、
受信した前記付加情報と前記第１のユーザの識別情報と前記基本秘密とを使用して前記第２のノードで前記サービス鍵を生成するステップと、
を備えることを特徴とする方法。
【請求項２】
前記第１のノードはサービス・ノードであり、前記第２のノードはクライアントであることを特徴とする請求項１に記載の方法。
【請求項３】
前記クライアントは汎用ブートストラッピング・アーキテクチャを採用する３Ｇネットワークのクライアント端末であり、前記サービス・ノードはネットワーク・アプリケーション機能を備え、前記鍵生成機能はブートストラッピング・サーバ機能を備えることを特徴とする請求項２に記載の方法。
【請求項４】
前記鍵生成機能は、ホーム加入者システムまたはホーム・ロケーション・レジスタ／認証センタをさらに備え、前記基本秘密は前記ホーム加入者システムまたはＨＥ？／認証センタにより既知であるかまたはアクセス可能であることを特徴とする請求項３に記載の方法。
【請求項５】
前記鍵生成機能でサービス鍵を生成する前記ステップは、
前記基本秘密を使用して鍵素材ＫＳを生成するステップと、
前記鍵素材ＫＳと前記サービス・ノードの前記識別情報と前記付加情報とを使用して前記サービス鍵を生成するステップと、
を備えることを特徴とする請求項３または４に記載の方法。
【請求項６】
前記クライアントで前記サービス鍵を生成する前記ステップは、
前記基本秘密を使用して鍵素材ＫＳを生成するステップと、
前記鍵素材ＫＳと前記付加情報とを使用して前記サービス鍵を生成するステップと、
を備えることを特徴とする請求項３に記載の方法。
【請求項７】
前記基本秘密は前記クライアントのＩＳＩＭ／ＵＳＩＭに格納されており、前記鍵素材ＫＳを生成する前記ステップは前記ＩＳＩＭ／ＵＳＩＭ内で実行されることを特徴とする請求項６に記載の方法。
【請求項８】
前記鍵生成機能でサービス鍵を生成する前記ステップは、前記サービス・ノードから前記クライアントに送信されたもの以外の他の値を利用することを特徴とする請求項１乃至７の何れか一項に記載の方法。
【請求項９】
前記他の値の少なくともいくつかは前記クライアントにより前記鍵生成機能から取得されることを特徴とする請求項８に記載の方法。
【請求項１０】
前記付加情報は、１以上の
トランザクション識別子、
ネットワーク認証値、
を含むことを特徴とする請求項１乃至９の何れか一項に記載の方法。
【請求項１１】
前記付加情報はＮＡＩフォーマットのトランザクション識別子を含み、前記トランザクション識別子は前記鍵生成機能により生成される符号化ランダム値を含み、前記符号化ランダム値は前記サービス鍵を生成するために使用される、ことを特徴とする請求項１乃至９の何れか一項に記載の方法。
【請求項１２】
前記付加情報はＮＡＩフォーマットのトランザクション識別子を含み、前記トランザクション識別子は前記鍵生成機能により生成され格納されるランダム値へのポインタを含み、前記ランダム値は前記サービス鍵を生成するために使用され、
前記方法は、
前記ポインタを含む要求を前記クライアントから前記鍵生成機能に送信するステップと、
前記クライアントが前記サービス鍵を生成可能となるように前記ランダム値を前記クライアントに返送するステップと、
を備えることを特徴とする請求項２に記載の方法。
【請求項１３】
前記鍵生成機能は前記サービス・ノードにネットワーク認証値を送信し、前記サービス・ノードは当該値を前記付加情報と共に前記クライアントに転送し、前記クライアントは前記鍵生成機能を認証するために前記基本秘密および前記認証値を使用する、ことを特徴とする請求項２に記載の方法。
【請求項１４】
前記クライアントが前記付加情報を前記サービス・ノードから受信した後に前記クライアントから前記鍵生成機能に認証値の要求を送信するステップと、
前記認証値を前記クライアントで受信するステップと、
当該値に基づいて前記サービス・ノードから受信した前記セキュリティ・アソシエーション要求を認証するステップと、
を備えることを特徴とする請求項２に記載の方法。
【請求項１５】
前記付加情報はサービス・データを併せて含むメッセージで前記サービス・ノードから前記クライアントに転送され、前記サービス・データは前記サービス鍵により暗号化および／または完全性保護がなされ、前記クライアントは一旦前記サービス鍵が生成されると前記暗号化データを復号可能となる、ことを特徴とする請求項２に記載の方法。
【請求項１６】
サービス鍵を前記鍵生成機能で生成する前記ステップは前記第２のノードの前記識別情報を使用するステップを備えることを特徴とする請求項１乃至１５の何れか一項に記載の方法。
【請求項１７】
前記サービス鍵は前記第２のノードのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵であり、
前記方法は、
前記第１のノードのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵を前記第１のノードに提供するステップと、
前記第１のノードの前記Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵を前記第２のノードに送信するステップと、
をさらに備え、前記セキュリティ・アソシエーションは２つの前記Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵に基づいて確立される、ことを特徴とする請求項１乃至１６の何れか一項に記載の方法。
【請求項１８】
前記第１および第２のノードはそれぞれ第１および第２のクライアントであることを特徴とする請求項１に記載の方法。
【請求項１９】
前記鍵生成機能は前記第２のクライアントと信頼関係を有する鍵サーバを含み、サービス鍵の生成および提供の前記要求は前記第１のクライアントと信頼関係を有する第２の鍵サーバを経由して前記鍵サーバに送信されることを特徴とする請求項１８に記載の方法。
【請求項２０】
前記第１のノードから前記第２のノードに前記第１のノードにより得られたサービス鍵を送信するステップと、
前記第１および第２のノードで、前記サービス鍵の両方を使用してセッション鍵を導出するステップと、
を備えることを特徴とする請求項１９に記載の方法。
【請求項２１】
前記付加情報を前記第１のノードから前記第２のノードに転送するステップと、受信した前記付加情報と前記基本秘密とを使用して前記第２のノードで前記サービス鍵を生成する前記ステップと、はＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ交換手順の一部を形成することを特徴とする請求項１８に記載の方法。
【請求項２２】
安全な通信リンクを経由してプッシュ型サービスをクライアントに配信するためのサービス・ノードであって、
サービス鍵の生成および提供の要求を鍵生成機能に送信する手段であって、前記要求は前記クライアントおよび前記サービス・ノードを識別する、手段と、
前記鍵生成機能からサービス鍵を付加情報と共に受信する手段と、
前記付加情報を前記クライアントに転送する手段と、
前記サービス鍵を使用してサービス情報の暗号化および／または完全性保護を行い、該暗号化および／または完全性保護された情報を前記クライアントに送信する手段と、
を備えることを特徴とするサービス・ノード。
【請求項２３】
サービス・ノードにより配信されるプッシュ型サービスを受信するためのクライアント端末であって、
鍵生成機能との共有秘密を格納する記憶手段と、
前記サービス・ノードから鍵生成情報を受信する手段と、
前記共有秘密と前記鍵生成情報とを使用してサービス鍵を生成する手段と、
前記サービス・ノードとの通信の復号および／または完全性検証のために前記サービス鍵を使用する手段と、
を備えることを特徴とするクライアント端末。
【請求項２４】
前記サービス・ノードからメッセージ認証コードを受信する手段と、
前記鍵生成情報の少なくとも一部から１以上の認証鍵を生成し、該１以上の認証鍵を使用して前記メッセージ認証コードを認証する手段と、
を備えることを特徴とする請求項２３に記載の端末。
【請求項２５】
１以上の認証鍵を生成する前記手段はＵＳＩＭ／ＩＳＩＭを含むことを特徴とする請求項２３に記載の端末。
【請求項２６】
サービス・ノードからクライアントに情報をプッシュ配信するために前記クライアントと前記サービス・ノードとの間にセキュリティ・アソシエーションを確立する際に使用する鍵生成機能であって、
鍵サーバは、
前記クライアントと共有される秘密を格納する記憶手段と、
サービス鍵の生成および提供の要求を前記サービス・ノードから受信する手段であって、前記要求は前記クライアントおよび前記サービス・ノードを識別する、手段と、
前記サービス・ノードの前記識別情報と前記基本秘密と付加情報とを使用してサービス鍵を生成し、該サービス鍵を前記付加情報と共に前記サービス・ノードに送信する手段と、
を備えることを特徴とする鍵生成機能。
【請求項２７】
第１のクライアントから第２のクライアントに情報をプッシュ配信するために前記第１および第２のクライアントの間でセキュリティ・アソシエーションを確立する方法であって、前記第１および第２のクライアントはそれぞれ第１および第２の鍵サーバとの信頼関係を有しそれぞれの鍵サーバと秘密を共有しており、該方法は、
サービス鍵の生成および提供の要求を前記第１の鍵サーバを経由して前記第１のクライアントから前記第２の鍵サーバに送信するステップであって、前記要求は前記第１および第２のノードを識別する、ステップと、
前記第１のノードの前記識別情報と前記基本秘密と付加情報とを使用して前記第２の鍵サーバでサービス鍵を生成し、該サービス鍵を前記付加情報と共に前記第１のノードに送信するステップと、
前記付加情報を前記第１のノードから前記第２のノードに転送するステップと、
前記第２のノードで、受信した前記付加情報と前記基本秘密とを使用して前記サービス鍵を生成するステップと、
を備えることを特徴とする方法。
【請求項２８】
リプレイ攻撃に対してノードを保護する方法であって、該方法は、
ブートストラッピング・サーバ機能でサービス鍵を生成するステップと、
前記サービス鍵を該サービス鍵の生成に必要な情報と共に第１のノードに提供するステップと、
前記第１のノードから前記第２のノードに鍵生成メッセージを送信するステップであって、前記メッセージは前記情報とリプレイ防止値と該リプレイ防止値を含む前記メッセージ本体にわたって計算されるメッセージ認証コードとを含み、前記リプレイ防止値は前記手順の実行のたびにインクリメントまたはデクリメントされる、ステップと、
前記第２のノードで前記鍵生成メッセージを受信し、該鍵生成メッセージに含まれる前記リプレイ防止値を格納するステップと、
前記第２のノードで、鍵生成メッセージが受信されるたびに、前記メッセージ認証コードを検証し、前記メッセージに含まれる前記リプレイ防止値が前記第２のノードに既に格納されているか否かを決定し、格納されている場合前記メッセージを拒絶する、ステップと、
を備えることを特徴とする方法。
【請求項１】
第１のノードから第２のノードに情報をプッシュ配信するために前記第１のノードと前記第２のノードとの間にセキュリティ・アソシエーションを確立する方法であって、前記第２のノードおよび鍵生成機能は基本秘密を共有しており、該方法は、
サービス鍵の生成および提供の要求を前記第１のノードから前記鍵生成機能に送信するステップであって、前記要求は前記第１および第２のノードの識別情報を含む、ステップと、
前記第１のノードの前記識別情報と前記基本秘密と付加情報とを使用して前記鍵生成機能でサービス鍵を生成し、該サービス鍵を前記付加情報と共に前記第１のノードに送信するステップと、
前記付加情報と前記第１のノードの前記識別情報とを前記第１のノードから前記第２のノードに転送するステップと、
受信した前記付加情報と前記第１のユーザの識別情報と前記基本秘密とを使用して前記第２のノードで前記サービス鍵を生成するステップと、
を備えることを特徴とする方法。
【請求項２】
前記第１のノードはサービス・ノードであり、前記第２のノードはクライアントであることを特徴とする請求項１に記載の方法。
【請求項３】
前記クライアントは汎用ブートストラッピング・アーキテクチャを採用する３Ｇネットワークのクライアント端末であり、前記サービス・ノードはネットワーク・アプリケーション機能を備え、前記鍵生成機能はブートストラッピング・サーバ機能を備えることを特徴とする請求項２に記載の方法。
【請求項４】
前記鍵生成機能は、ホーム加入者システムまたはホーム・ロケーション・レジスタ／認証センタをさらに備え、前記基本秘密は前記ホーム加入者システムまたはＨＥ？／認証センタにより既知であるかまたはアクセス可能であることを特徴とする請求項３に記載の方法。
【請求項５】
前記鍵生成機能でサービス鍵を生成する前記ステップは、
前記基本秘密を使用して鍵素材ＫＳを生成するステップと、
前記鍵素材ＫＳと前記サービス・ノードの前記識別情報と前記付加情報とを使用して前記サービス鍵を生成するステップと、
を備えることを特徴とする請求項３または４に記載の方法。
【請求項６】
前記クライアントで前記サービス鍵を生成する前記ステップは、
前記基本秘密を使用して鍵素材ＫＳを生成するステップと、
前記鍵素材ＫＳと前記付加情報とを使用して前記サービス鍵を生成するステップと、
を備えることを特徴とする請求項３に記載の方法。
【請求項７】
前記基本秘密は前記クライアントのＩＳＩＭ／ＵＳＩＭに格納されており、前記鍵素材ＫＳを生成する前記ステップは前記ＩＳＩＭ／ＵＳＩＭ内で実行されることを特徴とする請求項６に記載の方法。
【請求項８】
前記鍵生成機能でサービス鍵を生成する前記ステップは、前記サービス・ノードから前記クライアントに送信されたもの以外の他の値を利用することを特徴とする請求項１乃至７の何れか一項に記載の方法。
【請求項９】
前記他の値の少なくともいくつかは前記クライアントにより前記鍵生成機能から取得されることを特徴とする請求項８に記載の方法。
【請求項１０】
前記付加情報は、１以上の
トランザクション識別子、
ネットワーク認証値、
を含むことを特徴とする請求項１乃至９の何れか一項に記載の方法。
【請求項１１】
前記付加情報はＮＡＩフォーマットのトランザクション識別子を含み、前記トランザクション識別子は前記鍵生成機能により生成される符号化ランダム値を含み、前記符号化ランダム値は前記サービス鍵を生成するために使用される、ことを特徴とする請求項１乃至９の何れか一項に記載の方法。
【請求項１２】
前記付加情報はＮＡＩフォーマットのトランザクション識別子を含み、前記トランザクション識別子は前記鍵生成機能により生成され格納されるランダム値へのポインタを含み、前記ランダム値は前記サービス鍵を生成するために使用され、
前記方法は、
前記ポインタを含む要求を前記クライアントから前記鍵生成機能に送信するステップと、
前記クライアントが前記サービス鍵を生成可能となるように前記ランダム値を前記クライアントに返送するステップと、
を備えることを特徴とする請求項２に記載の方法。
【請求項１３】
前記鍵生成機能は前記サービス・ノードにネットワーク認証値を送信し、前記サービス・ノードは当該値を前記付加情報と共に前記クライアントに転送し、前記クライアントは前記鍵生成機能を認証するために前記基本秘密および前記認証値を使用する、ことを特徴とする請求項２に記載の方法。
【請求項１４】
前記クライアントが前記付加情報を前記サービス・ノードから受信した後に前記クライアントから前記鍵生成機能に認証値の要求を送信するステップと、
前記認証値を前記クライアントで受信するステップと、
当該値に基づいて前記サービス・ノードから受信した前記セキュリティ・アソシエーション要求を認証するステップと、
を備えることを特徴とする請求項２に記載の方法。
【請求項１５】
前記付加情報はサービス・データを併せて含むメッセージで前記サービス・ノードから前記クライアントに転送され、前記サービス・データは前記サービス鍵により暗号化および／または完全性保護がなされ、前記クライアントは一旦前記サービス鍵が生成されると前記暗号化データを復号可能となる、ことを特徴とする請求項２に記載の方法。
【請求項１６】
サービス鍵を前記鍵生成機能で生成する前記ステップは前記第２のノードの前記識別情報を使用するステップを備えることを特徴とする請求項１乃至１５の何れか一項に記載の方法。
【請求項１７】
前記サービス鍵は前記第２のノードのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵であり、
前記方法は、
前記第１のノードのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵を前記第１のノードに提供するステップと、
前記第１のノードの前記Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵を前記第２のノードに送信するステップと、
をさらに備え、前記セキュリティ・アソシエーションは２つの前記Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵に基づいて確立される、ことを特徴とする請求項１乃至１６の何れか一項に記載の方法。
【請求項１８】
前記第１および第２のノードはそれぞれ第１および第２のクライアントであることを特徴とする請求項１に記載の方法。
【請求項１９】
前記鍵生成機能は前記第２のクライアントと信頼関係を有する鍵サーバを含み、サービス鍵の生成および提供の前記要求は前記第１のクライアントと信頼関係を有する第２の鍵サーバを経由して前記鍵サーバに送信されることを特徴とする請求項１８に記載の方法。
【請求項２０】
前記第１のノードから前記第２のノードに前記第１のノードにより得られたサービス鍵を送信するステップと、
前記第１および第２のノードで、前記サービス鍵の両方を使用してセッション鍵を導出するステップと、
を備えることを特徴とする請求項１９に記載の方法。
【請求項２１】
前記付加情報を前記第１のノードから前記第２のノードに転送するステップと、受信した前記付加情報と前記基本秘密とを使用して前記第２のノードで前記サービス鍵を生成する前記ステップと、はＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ交換手順の一部を形成することを特徴とする請求項１８に記載の方法。
【請求項２２】
安全な通信リンクを経由してプッシュ型サービスをクライアントに配信するためのサービス・ノードであって、
サービス鍵の生成および提供の要求を鍵生成機能に送信する手段であって、前記要求は前記クライアントおよび前記サービス・ノードを識別する、手段と、
前記鍵生成機能からサービス鍵を付加情報と共に受信する手段と、
前記付加情報を前記クライアントに転送する手段と、
前記サービス鍵を使用してサービス情報の暗号化および／または完全性保護を行い、該暗号化および／または完全性保護された情報を前記クライアントに送信する手段と、
を備えることを特徴とするサービス・ノード。
【請求項２３】
サービス・ノードにより配信されるプッシュ型サービスを受信するためのクライアント端末であって、
鍵生成機能との共有秘密を格納する記憶手段と、
前記サービス・ノードから鍵生成情報を受信する手段と、
前記共有秘密と前記鍵生成情報とを使用してサービス鍵を生成する手段と、
前記サービス・ノードとの通信の復号および／または完全性検証のために前記サービス鍵を使用する手段と、
を備えることを特徴とするクライアント端末。
【請求項２４】
前記サービス・ノードからメッセージ認証コードを受信する手段と、
前記鍵生成情報の少なくとも一部から１以上の認証鍵を生成し、該１以上の認証鍵を使用して前記メッセージ認証コードを認証する手段と、
を備えることを特徴とする請求項２３に記載の端末。
【請求項２５】
１以上の認証鍵を生成する前記手段はＵＳＩＭ／ＩＳＩＭを含むことを特徴とする請求項２３に記載の端末。
【請求項２６】
サービス・ノードからクライアントに情報をプッシュ配信するために前記クライアントと前記サービス・ノードとの間にセキュリティ・アソシエーションを確立する際に使用する鍵生成機能であって、
鍵サーバは、
前記クライアントと共有される秘密を格納する記憶手段と、
サービス鍵の生成および提供の要求を前記サービス・ノードから受信する手段であって、前記要求は前記クライアントおよび前記サービス・ノードを識別する、手段と、
前記サービス・ノードの前記識別情報と前記基本秘密と付加情報とを使用してサービス鍵を生成し、該サービス鍵を前記付加情報と共に前記サービス・ノードに送信する手段と、
を備えることを特徴とする鍵生成機能。
【請求項２７】
第１のクライアントから第２のクライアントに情報をプッシュ配信するために前記第１および第２のクライアントの間でセキュリティ・アソシエーションを確立する方法であって、前記第１および第２のクライアントはそれぞれ第１および第２の鍵サーバとの信頼関係を有しそれぞれの鍵サーバと秘密を共有しており、該方法は、
サービス鍵の生成および提供の要求を前記第１の鍵サーバを経由して前記第１のクライアントから前記第２の鍵サーバに送信するステップであって、前記要求は前記第１および第２のノードを識別する、ステップと、
前記第１のノードの前記識別情報と前記基本秘密と付加情報とを使用して前記第２の鍵サーバでサービス鍵を生成し、該サービス鍵を前記付加情報と共に前記第１のノードに送信するステップと、
前記付加情報を前記第１のノードから前記第２のノードに転送するステップと、
前記第２のノードで、受信した前記付加情報と前記基本秘密とを使用して前記サービス鍵を生成するステップと、
を備えることを特徴とする方法。
【請求項２８】
リプレイ攻撃に対してノードを保護する方法であって、該方法は、
ブートストラッピング・サーバ機能でサービス鍵を生成するステップと、
前記サービス鍵を該サービス鍵の生成に必要な情報と共に第１のノードに提供するステップと、
前記第１のノードから前記第２のノードに鍵生成メッセージを送信するステップであって、前記メッセージは前記情報とリプレイ防止値と該リプレイ防止値を含む前記メッセージ本体にわたって計算されるメッセージ認証コードとを含み、前記リプレイ防止値は前記手順の実行のたびにインクリメントまたはデクリメントされる、ステップと、
前記第２のノードで前記鍵生成メッセージを受信し、該鍵生成メッセージに含まれる前記リプレイ防止値を格納するステップと、
前記第２のノードで、鍵生成メッセージが受信されるたびに、前記メッセージ認証コードを検証し、前記メッセージに含まれる前記リプレイ防止値が前記第２のノードに既に格納されているか否かを決定し、格納されている場合前記メッセージを拒絶する、ステップと、
を備えることを特徴とする方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１３−３４２２０（Ｐ２０１３−３４２２０Ａ）
【公開日】平成２５年２月１４日（２０１３．２．１４）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−２０８８５４（Ｐ２０１２−２０８８５４）
【出願日】平成２４年９月２１日（２０１２．９．２１）
【分割の表示】特願２００８−５３５０１２（Ｐ２００８−５３５０１２）の分割
【原出願日】平成１８年１０月１０日（２００６．１０．１０）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公開日】平成２５年２月１４日（２０１３．２．１４）
【国際特許分類】
【出願番号】特願２０１２−２０８８５４（Ｐ２０１２−２０８８５４）
【出願日】平成２４年９月２１日（２０１２．９．２１）
【分割の表示】特願２００８−５３５０１２（Ｐ２００８−５３５０１２）の分割
【原出願日】平成１８年１０月１０日（２００６．１０．１０）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]