モバイルネットワークに基づくエンドツーエンド通信での認証の方法、システム、および認証センタ
モバイルネットワークに基づくエンドツーエンド通信において認証を行う方法を開示する。上記方法は、サービスを要求する第1サービスエンティティと、サービスを提供する第2サービスエンティティと、エンティティ認証センタEACとを具備するシステムに適用され、ネゴシエートされた認証モードに従って第1サービスエンティティとEACとの間の相互認証及び第2サービスエンティティとEACとの間の相互認証をそれぞれ実行する段階と、第1サービスエンティティが第2サービスエンティティにサービス提供を要求する場合に、EACが、ネゴシエートされた認証モードに従って第1及び第2サービスエンティティに関する認証問合せを提供し、ネゴシエートされた認証モードに従って共有派生鍵を生成する段階と、第1及び第2サービスエンティティが、共有派生鍵及びネゴシエートされた認証モードに従って互いを認証し、サービスを保護するセッション鍵を生成する段階とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク通信サービス技法に関し、具体的には、モバイルネットワークに基づくエンドツーエンド通信での認証の方法、システム、および認証センタに関する。
【背景技術】
【０００２】
現在、サービスをモバイル加入者に提供する時に、アプリケーションサーバの大多数は、まず、モバイル加入者と認証プロキシとの間、モバイル加入者と公開鍵基盤(PKI)証明機関との間、モバイル加入者とコンテンツ提供サーバとの間など、相互信頼関係をモバイル加入者と共に確立する。一般に、そのような信頼関係は、モバイル加入者とアプリケーションサーバとの間の双方向認証手順中に確立される。
【０００３】
3G無線通信標準規格では、GAA(Generic Authentication Architecture)が、加入者識別情報を検証するためにさまざまなアプリケーションサービスエンティティによって使用される一般的アーキテクチャであり、アプリケーションサービス加入者をチェックし、加入者識別情報を検証することができる。上記アプリケーションサービスは、マルチキャスト/ブロードキャストサービス、ユーザ証明書サービス、瞬時情報を提供するサービス、またはプロキシサービスとすることができる。
【０００４】
図1は、GAAのアーキテクチャを示す概略図であり、このGAAは、一般に、加入者101、加入者識別情報の初期チェックおよび検証を実行するBSF(Bootstrapping Server Function) 102、HSS(Home Subscriber Server) 103、およびNAF(Network Application Function) 104を含む。BSF 102は、加入者101との相互識別情報検証を実行し、BSF 102および加入者101の共有鍵を生成するように働く。HSS 103は、加入者情報を記述するプロファイルを格納し、認証情報を生成する機能を有する。
【０００５】
サービスを使用することを望む時に、加入者は、サービスがBSFを用いる相互認証手順を必要とする場合に、相互認証のために直接にBSFと通信する。そうでない場合には、加入者は、まずサービスに対応するNAFに連絡し、NAFがGAAを使用するがサービスを要求する加入者が相互認証手順のためにBSFと通信してはいない場合には、NAFは、サービスを要求する加入者に、BSFとの識別情報検証を実行するように通知する。
【０００６】
相互認証が成功した時に、加入者およびBSFは、互いの識別情報を認証し、共有鍵Ksを生成する。さらに、BSFは、Ksの更新を容易にするために、Ksの寿命を定義する。後に、BSFは、加入者のB-TID(Bootstrapping Transaction Identifier)を割り振り、そのB-TIDをKsの寿命と共にユーザ機器(UE)に転送し、ここで、B-TIDが、Ksに関連付けられる。共有鍵Ksは、ルート鍵として使用されるが、加入者のUEおよびBSFから出ない。加入者がNAFと通信する時には、Ksから導出された鍵Ks_NAFが、通信を保護するのに使用される。
【０００７】
GAAの不利益は、1. 1つの認証機構(すなわちAKA認証機構)だけが、加入者とBSFとの間の認証でサポートされることと、2. 認証機構が、BSFとNAFとの間の認証を提供せず、これが、NAFを偽る攻撃者による加入者の秘密情報の窃取をもたらす可能性があることである。
【０００８】
3GPP2にもGAAがあり、図2を参照されたい。図2は、既存の3GPP2でのGAAを示す図である。3GPP2のGAAは、MN(Mobile Node) 201、NAF(Network Application Function) 202、加入者識別情報の初期チェックおよび検証を実行するBSF 203、HSS 204、HLR/AC(Home Location Register/Authentication Centre)、およびAAA(Authentication Authorization Accounting)サーバがある。
【０００９】
NAFによって提供されるサービスを使用することを望む場合に、MNは、まず、BSFとの相互認証を実行しなければならない。MNおよびネットワークのサポート条件ならびにオペレータのローカルポリシに従って自由に選択できる3タイプの相互認証機構(AKA認証機構、CAVEベース認証機構、およびAAAベース認証機構を含む)がある。
【００１０】
しかし、3GPP2のGAAは、3つの認証機構だけをサポートし、これは、あるサービスエンティティとさまざまなネットワークとの間の相互認証に適用可能ではない。さらに、認証機構は、BSFとNAFとの間の認証を提供せず、これは、NAFを偽る攻撃者による加入者の秘密情報の窃取をもたらす可能性がある。
【００１１】
要約すると、既存のGAAは、それが属する標準規格の中でのみ適用可能であり、ネットワークおよびサービスエンティティによって制限され、したがって、いくつかの制限を有する。
【発明の開示】
【課題を解決するための手段】
【００１２】
本発明による実施形態は、さまざまなエンティティの間で相互信頼関係を確立するために異なるモバイルネットワーク標準規格について適用可能である包括的認証アーキテクチャを提供する。
【００１３】
本発明の実施形態による技術的解決策は、次の通りである。
【００１４】
本発明の実施形態は、サービスを要求する第1サービスエンティティと、サービスを提供する第2サービスエンティティと、エンティティ認証センタすなわちEACとを具備するシステムに適用される、モバイルネットワークに基づくエンドツーエンド通信において認証する方法であって、第1サービスエンティティとEACとの間で認証モードをネゴシエートする段階であって、ネゴシエートされた認証モードは、第1サービスエンティティとEACとの間の認証機構と、第2サービスエンティティとEACとの間の認証機構と、認証問合せの機構と、派生鍵を導出する機構と、第1サービスエンティティと第2サービスエンティティとの間の認証機構とを含む、段階と、ネゴシエートされた認証モードに含まれる第1サービスエンティティとEACとの間の認証機構に従ってEACと第1サービスエンティティとの間で相互認証を実行し、ネゴシエートされた認証モードに含まれる第2サービスエンティティとEACとの間の認証機構に従ってEACと第2サービスエンティティとの間で相互認証を実行する段階と、第1サービスエンティティが、サービスを提供するように第2サービスエンティティに要求する場合に、EACが、ネゴシエートされた認証モードに含まれる認証問合せの機構に従って第1サービスエンティティおよび第2サービスエンティティに関する認証問合せを提供し、ネゴシエートされた認証モードに含まれる派生鍵を生成する機構に従って第1サービスエンティティと第2サービスエンティティとの間の通信を保護する共有される派生鍵を生成する段階と、第1サービスエンティティおよび第2サービスエンティティが、共有される派生鍵、およびネゴシエートされた認証モードに含まれる第1サービスエンティティと第2サービスエンティティとの間の認証機構に従って互いを認証し、サービスを保護するセッション鍵を生成する段階とを有することを特徴とする方法を開示する。
【００１５】
また、本発明の実施形態は、サービスエンティティおよびEACに適用される、サービスエンティティを認証する方法であって、サービスエンティティとEACとの間で認証モードをネゴシエートする段階であって、ネゴシエートされた認証モードは、サービスエンティティとEACとの間の認証機構を含む、段階と、ネゴシエートされた認証モードに含まれる認証機構に従ってサービスエンティティとEACとの間で相互認証を実行する段階とを有することを特徴とする方法を開示する。
【００１６】
本発明の実施形態は、サービスを要求する第1サービスエンティティと、サービスを提供する第2サービスエンティティと、EACとを具備するシステムに適用される、認証問合せの方法であって、第1サービスエンティティとEACとの間の相互認証と、第2サービスエンティティとEACとの間の相互認証とが、それぞれ実行され、EACは、第1サービスエンティティおよび第2サービスエンティティの一時識別情報をそれぞれ割り振り、第1サービスエンティティおよび第2サービスエンティティとの通信を保護する共有鍵材料をそれぞれ獲得し、第1サービスエンティティは、認証問合せの機構および派生鍵を生成する機構を含む認証モードをEACとネゴシエートし、上記方法は、第1サービスエンティティが、第2サービスエンティティによって提供されるサービスを要求する場合に、ネゴシエートされた認証モードに含まれる認証問合せの機構に従って、第1サービスエンティティおよび第2サービスエンティティの一時識別情報に従って第1サービスエンティティおよび第2サービスエンティティの権限を認証する段階と、ネゴシエートされた認証モードに含まれる派生鍵を生成する機構、第1サービスエンティティおよび第2サービスエンティティの一時識別情報、ならびに第1サービスエンティティとの通信を保護する共有鍵材料に従って、第1サービスエンティティと第2サービスエンティティとの間の通信を保護する共有される派生鍵を計算する段階とを有することを特徴とする方法を開示する。
【００１７】
本発明の実施形態は、サービスを要求する第1サービスエンティティと、サービスを提供する第2サービスエンティティと、EACとを具備するモバイルネットワークに基づくエンドツーエンド通信において認証するシステムであって、第1サービスエンティティは、認証に関係する少なくとも1つの機構を含む認証モードをEACとネゴシエートし、ネゴシエートされた認証モードに従って第1サービスエンティティとEACとの間で相互認証を実行し、第2サービスエンティティにサービスを要求し、ネゴシエートされた認証モードに従って、第1サービスエンティティと第2サービスエンティティとの間の通信を保護する共有される派生鍵に従って第1サービスエンティティと第2サービスエンティティとの間で相互認証を実行するように構成され、第2サービスエンティティは、ネゴシエートされた認証モードに従ってEACを認証し、第1サービスエンティティがサービスを要求する場合にネゴシエートされた認証モードに従って第1サービスエンティティと第2サービスエンティティとの間の通信を保護する共有される派生鍵に従って第2サービスエンティティと第1サービスエンティティとの間で相互認証を実行するように構成され、EACは、ネゴシエートされた認証モードに従って、EACと第1サービスエンティティとの間の相互認証と、EACと第2サービスエンティティとの間の相互認証とをそれぞれ実行し、第1サービスエンティティがサービスを要求する時に、ネゴシエートされた認証モードに従って第1サービスエンティティおよび第2サービスエンティティに関する認証問合せを提供し、第1サービスエンティティと第2サービスエンティティとの間の通信を保護する共有される派生鍵を生成するように構成されることを特徴とするシステムを開示する。
【００１８】
また、本発明の実施形態は、サービスエンティティおよびEACを具備する、サービスエンティティを認証するシステムであって、サービスエンティティは、サービスエンティティとEACとの間の認証機構を含む認証モードをEACとネゴシエートし、ネゴシエートされた認証モードに含まれる認証機構に従ってサービスエンティティとEACとの間で相互認証を実行するように構成されることを特徴とするシステムを開示する。
【００１９】
本発明の実施形態は、サービスを要求する第1サービスエンティティ、サービスを提供する第2サービスエンティティ、およびEACを具備する、認証問合せのシステムであって、第1サービスエンティティは、認証問合せの機構および派生鍵を生成する機構を含む認証モードをEACとネゴシエートするように構成され、EACは、第1サービスエンティティがサービスを要求する時に、ネゴシエートされた認証モードに含まれる認証問合せの機構に従って、第1サービスエンティティおよび第2サービスエンティティの権限を認証し、ネゴシエートされた認証モードに含まれる派生鍵を生成する機構に従って、第1サービスエンティティと第2サービスエンティティとの間の通信を保護する共有される派生鍵を生成するように構成されることを特徴とするシステムをさらに開示する。
【００２０】
本発明の実施形態は、認証センタであって、サービスエンティティの認証モードをネゴシエートするように構成された第1モジュールであって、認証モードは、サービスエンティティと認証センタとの間の認証機構を含む、第1モジュールと、第1モジュールによってネゴシエートされた認証モードに含まれる認証機構に従ってサービスエンティティを認証するように構成された第2モジュールとを具備することを特徴とする認証センタを開示する。
【００２１】
上記認証センタでは、第1モジュールは、サービスを要求するサービスエンティティおよびサービスを提供するサービスエンティティの認証機能をそれぞれ獲得するためにサブスクリプションデータを問い合わせるように構成された第1サブモジュールと、サービスを要求するサービスエンティティおよびサービスを提供するサービスエンティティの認証機能に従って認証モードを選択するように構成された第2サブモジュールであって、認証機能は、第1モジュールによって獲得される、第2サブモジュールとを具備することを特徴とする。
【００２２】
上記認証センタでは、認証モードは、認証問合せの機構および派生鍵を生成する機構をさらに含み、認証センタは、サービスエンティティがサービスを要求する時に、サービスを要求するサービスエンティティおよびサービスを提供するサービスエンティティに関する認証問合せを提供し、第1モジュールによってネゴシエートされた認証モードに含まれる認証問合せの機構および派生鍵を生成する機構に従って、2つのサービスエンティティの間の通信を保護する共有される派生鍵を計算するように構成された第3モジュールをさらに具備することを特徴とする。
【００２３】
上記認証センタでは、第2モジュールは、2つのサービスエンティティの共有鍵材料および一時識別情報を生成するように構成され、第3モジュールは、第2モジュールによって生成された2つのサービスエンティティの共有鍵材料および一時識別情報に従って共有される派生鍵を計算するように構成されることを特徴とする。
【発明の効果】
【００２４】
本発明の実施形態による技術的解決策によってもたらされる有益な効果は、真の包括的認証アーキテクチャが提供されることであり、ここで、GAAによって提供される認証機構は、複数の認証機構および認証モジュールに関するネゴシエーションおよび選択を実行することができ、これは、認証機構の柔軟性および一般性を高める。本発明の実施形態によるフレームワークでは、サービスプロバイダを、モバイルネットワーク内のアプリケーションサーバ、オープンネットワーク内のアプリケーションサーバ、または高度な機能を有するモバイル端末とすることができ、これは、サービス加入者がより豊富なサービスリソースを使用することを可能にする。この認証解決策は、モバイル端末が、サービスプロバイダになるためにアップグレードされる状況をサポートし、これは、高度な機能を有するモバイル端末がサービスを提供することを望むという需要を満足する。
【発明を実施するための最良の形態】
【００２５】
本発明の目的、技術的解決策、および利益をより明白にするために、本発明を、添付の図面および実施形態を参照して、以下でさらに詳細に説明する。
【００２６】
図3に、本発明の実施形態によるモバイルネットワークに基づくエンドツーエンド通信認証のアーキテクチャを示す。このアーキテクチャは、異なるモバイルネットワーク標準規格に適用可能であり、異なるタイプのサービスエンティティの間で相互信頼関係を確立するように働くという点で、実際に包括的認証アーキテクチャと呼ぶことができる。2つのサービスエンティティすなわちサービス加入者(SS)301およびサービスプロバイダ(SP)302のほかに、この包括的認証アーキテクチャに用いられるネットワーク要素は、さらに、オペレータのネットワーク内のエンティティ認証センタ(EAC)303およびエンティティサブスクリプションデータベース(ESD)304を含む。このアーキテクチャでは、SSおよびSPは、互いに通信することができ、SSおよびSPは、それぞれ、それ自体の認証を実行するためにEACと通信することができ、EACは、ESDに接続することができ、そこから認証に必要な情報を獲得することができる。本発明の実施形態では、サービスエンティティは、サービス加入者(SS)またはサービスプロバイダ(SP)とすることができる。SSは、3GPP GAAの加入者または3GPP2 GAAのMNと同等とすることができ、SPは、3GPP GAAまたは3GPP2 GAAのNAFとして振る舞うことができ、EACは、3GPP GAAまたは3GPP2 GAAのBSFと同等とすることができる。
【００２７】
サービスをモバイル加入者に提供する時に、アプリケーションサーバの大多数は、まず、相互信頼関係をモバイル加入者と確立する(たとえば、モバイル加入者と認証プロキシとの間、モバイル加入者とPKI証明機関との間、モバイル加入者とコンテンツ提供サーバとの間など)。一般に、そのような信頼関係は、モバイル加入者とアプリケーションサーバとの間の双方向認証手順中に確立される。モバイルネットワークの開発と共に、サービスのタイプが、ますます多様化する。その一方で、SPは、純オペレータネットワークに制限されるのではなく、オペレータネットワーク以外のサードパーティSPまたはモバイル加入者とすることすらできる。すなわち、一部のモバイル加入者は、ネットワークによって提供されるアプリケーションサービスを使用できるだけではなく、あるサービスをネットワーク内の他の加入者に提供することもできる。本発明の実施形態には、オペレータネットワークのAS、サードパーティAS、およびモバイル加入者を含む3タイプのSPがある。また、一般的なモバイル加入者またはサードパーティASを含む2タイプのSSがある。したがって、モバイル加入者は、SSならびにSPであることができ、サードパーティASは、SPおよびSSであることができる。したがって、加入者およびSPへのサービスエンティティの分類と比較して、本発明の実施形態でのサービスエンティティは、3つのタイプすなわち、1. SSすなわちサービスを求めることだけができる単純なサービス加入者(一般に、一般のモバイル加入者)、2. SPすなわち単純なサービスプロバイダ(オペレータネットワークのASまたは外部ネットワークのSP)、3. サービス加入者であるだけではなくサービスプロバイダでもあるサービス加入者兼プロバイダ(SSPとも称する)(一般のモバイル加入者またはサードパーティASとすることができる)に分類される。
【００２８】
図3に示されたアーキテクチャでは、EACが、認証方法のネゴシエーションおよびサービスエンティティの認証と、エンドツーエンド通信エンティティの識別情報およびサービスを要求するか提供するエンティティの妥当性の検証と、派生鍵(derived key)の生成などに使用される。ESDは、エンティティによってサブスクライブされかつ/または提供されるサービスのタイプ、エンティティによってサポートされる認証機構、および認証情報などを含む、エンティティのサブスクリプション情報を格納する。エンティティのサブスクリプション情報は、そのエンティティのプライベートIDと一緒に格納される。SPが他のエンティティにサービスを提供するか、SSが他のエンティティのサービスを要求する前に、SPとネットワークとの間またはSSとネットワークとの間のサブスクリプション関係が、存在しなければならず、ESDに格納されなければならない。
【００２９】
本発明の実施形態によって提供される認証手順は、次のステージを含む。
【００３０】
第1ステージ(エンティティ認証プロセスと称する):サービスエンティティは、ネットワーク内の各SSがSPと通信する前に、まず、EACに行って、認証機構をネゴシエートし、サービスエンティティの識別情報を認証しなければならない。
【００３１】
認証機構をネゴシエートするプロセスは、サービスエンティティによって開始され、サービスエンティティの識別情報およびサービスのセキュリティ度合要件が、ネゴシエーションを開始するために要求メッセージ内で伝えられる。EACは、セキュリティ度合、ネットワークサポート条件(たとえば、ネットワークがサポートした認証モード)、およびエンティティサブスクリプション情報に従って認証機構を選択し、認証リクエスタとして振る舞うサービスエンティティに対応する情報を返す。サービスの異なるセキュリティ度合は、異なる認証モードが選択されることにつながる。認証リクエスタは、ネゴシエーション手順の終りを示すために確認メッセージを発行する。
【００３２】
サービスエンティティおよびEACは、ネゴシエートされた機構に従って、それらの間で相互認証を実行する。この認証は、双方向である。認証の後に、認証リクエスタ(すなわち、認証を要求するサービスエンティティ)およびEACは、共有鍵材料を生成し、EACは、認証リクエスタに、そのサブスクリプション情報に従って一時IDおよび対応する寿命を割り振る。認証リクエスタがSSである場合には、EACは、ISR-ID(Interim Service Request Identifier)を認証リクエスタに割り振り、認証リクエスタがSPである場合には、EACは、IAC-ID(Interim Authentication Check Identifier)を認証リクエスタに割り振る。EACは、サービスエンティティの一時IDおよび寿命を、認証を要求するサービスエンティティに転送する。この後に、認証を要求するサービスエンティティとEACとの間の通信を、そのサービスエンティティとEACとの間の認証手順で生成された共有鍵材料を使用することによって保護することができる。
【００３３】
第2ステージ(認証問合せプロセスと称する):EACとの認証を実行した後に、SSは、SPにサービスを要求することができる。
【００３４】
サービス要求を受信した時に、SPまたはSSPがEACとの認証を実行し、有効なIAC-IDを獲得済みであるならば、SPまたはSSPは、SSの認証条件についてEACに問い合わせることができる。そうでない場合には、SPまたはSSPは、まずEACと通信して認証および鍵ネゴシエーションを実行しなければならず、その後、SSのISR-IDおよびSPまたはSSPのIAC-IDを伝える問合せ要求を送信することによって、SSの認証条件についてEACに問い合わせなければならない。問合せ要求を受信した時に、EACは、まず、SSおよびSPがSSのIDおよびSPのIDに従って権限を有するかどうかを問い合わせ、次に、SSおよびSPの一時IDとSS/SPによってEACとネゴシエートされたKsとを使用することによってSSとSPとの間のサービス通信を保護する派生鍵を計算し、その派生鍵をSPに転送する。その間に、SSは、同一のパラメータおよびアルゴリズムに従って派生鍵を計算する。サービスエンティティとEACとの間で確立される信頼関係は、寿命を有する。この寿命が、満了しようとしているかまたは満了済みである場合には、サービスエンティティは、新しい信頼関係を確立するために、EACとの再認証手順を必要とする。
【００３５】
第3ステージ(サービスエンティティ間の相互認証プロセスと称する):共有される派生鍵を獲得した後に、SSおよびSPは、その派生鍵を使用して、各サービス通信の前にこの2つの当事者間で相互認証を実行し、通信のセキュリティを保護するためのセッション鍵Kr-SS-SPをさらに生成し、その後、そのセッション鍵を使用してサービス通信を保護することができる。
【００３６】
本発明の実施形態によって提供される認証手順の各ステージを、これより、添付の図面を参照して詳細に説明する。
【００３７】
図4は、本発明による実施形態での、サービスエンティティとEACとの間で認証機構をネゴシエートし、相互認証を実行するプロセスを示す流れ図である。この実施形態では、サービスエンティティとEACとの間で認証機構をネゴシエートし、相互認証を実行するプロセスは、図4に示されているようにサービスエンティティによって開始され、次のステップを含む。
【００３８】
ブロック401:サービスエンティティは、要求されたサービスまたは提供されるサービス(たとえば、ビデオ会議サービス)に対応する認証機構のセキュリティ度合要件(たとえば、高セキュリティ度合)を自動的に選択する。
【００３９】
ブロック402:サービスエンティティが、サービスエンティティのID、サービスエンティティによって選択された認証機構のセキュリティ度合などの関連情報を伝える認証要求をEACに転送する。
【００４０】
ブロック403:認証要求を受信した時に、EACは、ローカルに格納されたセキュリティ度合リストを検索して、ネットワークによって現在サポートされ、認証プロトコルおよび暗号化アルゴリズムを含むセキュリティ度合要件を満足する少なくとも1つの認証機構を見つける。たとえば、Http AKAは、ネットワークと無線ネットワーク内の端末との間の相互認証プロトコルである。このプロトコルを実行することによって、2つの通信当事者は、互いの識別情報を認証し、同一の鍵をそれぞれ生成することができる。
【００４１】
ブロック404:サービスエンティティの識別情報に従って、EACは、ESDに格納されたサブスクリプション情報を問い合わせ、サービスエンティティの認証情報、たとえば、認証プロトコル、暗号化アルゴリズム、および他の関連パラメータを含む、サービスエンティティによってサポートされる認証機構を得る。
【００４２】
ブロック405:ESDは、サービスエンティティの認証機能情報(たとえば、サポートされる認証プロトコル、暗号化アルゴリズムなど)および他の関連パラメータをEACに返す。
【００４３】
ブロック406:EACは、ローカルポリシに従って、サービスエンティティおよびネットワークによってサポートされる認証プロトコルおよび暗号化アルゴリズムを照合し、やはりセキュリティ度合要件に従って、両方の側によってサポートされる認証プロトコルおよび暗号化アルゴリズム(すなわち、認証機構)を判定する。セキュリティ度合要件にも従う、両方の側によってサポートされる認証プロトコルおよび暗号化アルゴリズムがない場合には、EACは、エラー表示をサービスエンティティに返し、現在の手順を打ち切る。
【００４４】
ブロック407:EACは、認証プロトコルおよび暗号化アルゴリズムを含む選択された認証機構をサービスエンティティに返す。
【００４５】
ブロック408:EACによって返された情報を受信した時に、サービスエンティティは、認証機構を判断し、確認応答をEACに返す。
【００４６】
ブロック409:サービスエンティティおよびEACは、選択された認証プロトコルおよび暗号化アルゴリズムを使用して、相互認証を実行する。成功の認証の後に、両方の当事者は、共有鍵材料(共有される秘密情報とも称する)を獲得する。
【００４７】
サービスエンティティがモバイル端末である場合には、共有鍵材料を、共有鍵(Ks)とすることができる。サービスエンティティがモバイルコアネットワークドメイン内のアプリケーションサーバ(AS)である場合には、サービスエンティティとEACとの間の相互認証手順でネゴシエートされる共有鍵材料を、SA(Security Association)すなわち、インターネットプロトコルセキュリティ(IPSec)に従ってネゴシエートされるセキュリティ通信の鍵および鍵アルゴリズム情報とすることができる。
【００４８】
ブロック410:EACは、認証成功応答をサービスエンティティに返し、サービスエンティティの一時IDおよび対応する寿命を割り振るが、これには、次の状況が含まれる:1) 認証要求をEACに発行するサービスエンティティがサービス加入者(SS/SSP)である場合に、EACは、SS/SSPが他のエンティティにサービスを要求する場合に使用されるISR-IDをSS/SSPに割り振り、2) 認証要求をEACに発行するサービスエンティティがサービスプロバイダ(SP/SSP)である場合に、EACは、SS/SSPがSSの認証条件についてEACに問い合わせる必要がある場合に使用されるIAC-IDをSS/SSPに割り振る。
【００４９】
ブロック411:EACおよびサービスエンティティは、それぞれ、対応するセキュリティ度合に関連する共有鍵材料を格納するが、これは、ISR-ID/IAC-ID、鍵材料、認証機構、およびセキュリティ度合を関連付け、かつ格納することを含む。
【００５０】
図5は、本発明による実施形態での、サービスエンティティとEACとの間での認証問合せ手順を示す流れ図である。この実施形態では、相互認証を実行した後に、サービスエンティティおよびEACは、認証問合せ手順を実行するが、その詳細な説明が、図5に示されている。
【００５１】
ブロック501:SS(またはSSP)が、EACとの認証でSSによって獲得されたISR-IDおよび他のサービスエンティティと連絡するためのIDであるSPのパブリック識別情報(UID)を含むサービス要求を、サービスを提供できるSP(または別のSSP)に発行する。
【００５２】
同一のサービスエンティティによって提供される異なるサービスは、異なるUIDに対応し、したがって、異なるサービスを、それら自体のUIDによって区別することができる。
【００５３】
ブロック502:サービス要求を受信した時に、SPは、SSを識別するために、ローカルに格納されたSSのISR-IDがあるかどうかを検索する。ISR-ID、それに関連する有効な派生鍵、サービスエンティティの実際の識別情報などが格納されている場合には、SSおよびSPは、その派生鍵を使用して、それらの間でサービスを保護する。派生鍵またはISR-ID情報がハイポオペレーション(hypo-operation)状態であるか、撤回されたか破壊されていることがわかった場合には、SPは、再認証要求を開始しなければならないことをSSに通知し、現在の手順は打ち切られ、再認証を開始する詳細な手順には、後続のテキストで言及する。ISR-IDが格納されていない場合には、SPは、認証問合せ要求をEACに送信し、SSのISR-IDならびにSPのIAC-IDおよびUIDをその認証問合せ要求で伝え、ブロック503を実行する。
【００５４】
ブロック503:認証問合せ要求を受信した時に、EACは、まず、その認証問合せ要求で伝えられるIAC-IDが有効であるかどうか、およびSPがサービスを提供する資格を与えられているかどうかを問い合わせ、判断し、その認証問合せ要求で伝えられるISR-IDが有効であるかどうか、およびSSがサービスを要求する資格を与えられているかどうかを問い合わせ、判断する。ISR-IDが有効であり、SSがサービスを要求する資格を与えられていることのほかに、IAC-IDが有効であり、SPがサービスを提供する資格を与えられていると判断される(すなわち、認証に合格する)場合に、EACは、SSおよびSPの派生鍵を生成する。
【００５５】
ブロック504:EACは、ブロック503で生成された派生鍵およびその鍵の寿命を伝える認証問合せ応答をSPに返す。ブロック503の認証問合せが成功である(すなわち、問合せおよび判断の結果が肯定である)場合には、SPおよびEACの共有鍵材料を暗号化することによって獲得される新しい派生鍵が、返される認証問合せ応答で伝えられる。そうでない場合には、EACは、エラーメッセージを返し、対応するサービスエンティティにEACでの再認証について通知し(この再認証の詳細は後続テキストで言及する)、現在の手順を打ち切る。
【００５６】
ブロック505:SPは、暗号化解除することによって認証問合せ応答から新たに生成された派生鍵を獲得し、派生鍵、寿命、SSのISR-ID、およびSPのUIDを関連付け、これらをローカルに格納する。
【００５７】
ブロック506:SPは、サービス要求応答をSSに返す。
【００５８】
ブロック507:SSは、同一のパラメータおよび鍵アルゴリズムを使用することによって同一の派生鍵を計算し、この鍵アルゴリズムは、DES(Data Encryption Standard)、3-DES(ternary DES)、AES(Advanced Enciphering Standard) 256、AES 1024(256と1024との両方が鍵長を表す)などを採用することができる。
【００５９】
ブロック508:SSおよびSPは、派生鍵を使用して、それらの間でサービスを保護する。
【００６０】
認証によってサービスエンティティとEACとの間で確立された信頼関係は、寿命(共有鍵材料、派生鍵、および一時IDの寿命など)を有するので、寿命が満了しようとしているか満了済みである場合には、サービスエンティティは、新しい信頼関係を確立するために、EACとの間での再認証のためにEACに接続する必要がある。
【００６１】
さらに、共有鍵材料または一時IDの異なる条件に従って、サービスエンティティは、次の状態を有する場合がある:1. ハイポオペレーション状態:共有鍵材料、派生鍵の寿命、または一時IDが、満了しようとしており、したがって、共有鍵材料を、暗号化計算に使用することはできないが、エンティティIDの暗号化解除および認証に使用することはできる。2. 撤回状態:共有鍵材料、派生鍵の寿命、または一時IDが、満了しており、共有鍵材料とエンティティの実際のIDとの間の対応する関係または一時IDとエンティティの実際のIDとの間の対応する関係が、除去されている。3. 破壊状態:共有鍵材料、派生鍵、または一時IDの関連レコードが削除されている。したがって、次の状況のうちの少なくとも1つが発生する場合に、再認証手順を開始する必要がある。
【００６２】
1. ローカルポリシに従って、サービスエンティティおよびEACの共有鍵材料またはサービスエンティティの一時IDがハイポオペレーション状態であることを見つけた場合に、EACは、再認証要求を開始しなければならないことをサービスエンティティに通知する。
【００６３】
2. ローカルポリシに従って、共有鍵または一時IDが撤回状態または破壊状態であることを見つけた場合に、EACは、再認証要求を開始しなければならないことをサービスエンティティに通知する。
【００６４】
3. EACが、一時IDに従って関連する識別情報および鍵情報を見つけることができない(すなわち、破壊状態である)場合に、EACは、再認証要求を開始しなければならないことをサービスエンティティに通知する。
【００６５】
4. ローカルポリシに従って、派生鍵がハイポオペレーション状態であることを見つけた場合に、SPは、再認証要求を開始しなければならないことをSSに通知する。
【００６６】
5. ローカルポリシに従って、派生鍵が撤回状態または破壊状態であることを見つけた場合に、SPは、再認証要求を開始しなければならないことをSSに通知する。
【００６７】
6. SPが、一時IDに従って、対応する識別情報および鍵情報を見つけることができない(すなわち、破壊状態である)場合に、SPは、再認証要求を開始しなければならないことをSSに通知する。
【００６８】
EACが、再認証要求を開始しなければならないことをサービスエンティティに通知する時に、その再認証の理由は、通知内で識別される。再認証の理由が、共有鍵材料または一時IDがハイポオペレーション状態であることである場合には、サービスエンティティは、開始される再認証要求でそれ自体を識別するのに、一時IDを使用する。その再認証要求を受信した時に、EACは、一時IDに従って、認証機構をネゴシエートする必要がないと判断し、したがって、相互認証を実行するのに、最初に使用された認証機構を採用する。再認証の理由が、共有鍵材料または一時IDが撤回状態または破壊状態であることである場合、または鍵材料を必要な時に一時IDに従って見つけることができないことである場合には、サービスエンティティは、開始される再認証要求でそれ自体を識別するのに、プライベートIDを使用する。その再認証要求を受信した時に、EACは、プライベートIDに従って、認証機構をネゴシエートする必要があると判断し、ここで、認証機構を再ネゴシエートする手順は、図4に示された最初の認証手順と同一である。
【００６９】
同様に、SPが、再認証要求を開始しなければならないことをSSに通知する時に、再認証の理由が、やはり通知内で識別されなければならない。再認証の理由が、一時IDがハイポオペレーション状態であることである場合には、SSは、開始される再認証要求でそれ自体を識別するのに、一時IDを使用する。この再認証要求を受信した時に、EACは、一時IDに従って、認証機構をネゴシエートする必要がないと判断し、したがって、相互認証を実行するのに、最初に使用された認証機構を採用する。再認証の理由が、一時IDが撤回状態または破壊状態であることである場合には、SSは、開始される再認証要求でそれ自体を識別するのに、プライベートIDを使用する。その再認証要求を受信した時に、EACは、プライベートIDに従って、認証機構をネゴシエートする必要があると判断し、ここで、認証機構を再ネゴシエートする手順は、図4に示された最初の認証手順と同一である。
【００７０】
一時ID(すなわち、ISR-ID/IAC-ID)またはそれに関連する共有鍵材料(すなわち、Ks/Kp)を使用する場合に、サービスエンティティ(SSまたはSP)またはEACは、一時IDまたは共有鍵材料がハイポオペレーション状態、撤回状態、または破壊状態であるかどうかを検証しなければならない。一時IDまたは共有鍵材料がハイポオペレーション状態、撤回状態、または破壊状態である場合には、サービスエンティティまたはEACは、対応するサービスエンティティとEACとの間で再認証手順を開始しなければならない。認証手順で、障害の理由を示すメッセージを受信する場合に、サービスエンティティまたはEACは、再認証手順を開始することもできる。さらに、SPが、SSと共有される派生鍵がハイポオペレーション状態、撤回状態、または破壊状態であることを見つけた場合に、SPは、SSに再認証要求を送信し、その要求内で再認証理由を示す。また、SSおよびSPの一時IDが正常状態である間に、共有される派生鍵だけがハイポオペレーション状態、撤回状態、または破壊状態である場合には、SSおよびSPは、EACとの最初のエンティティ認証を実行する必要はなく、SSは、EACがSP用の新しい共有される派生鍵を生成するようにするために、EACへの認証問合せ手順を開始しなければならず、SSは、同一の共有される派生鍵をそれ自体で生成する。
【００７１】
ここに、寿命およびハイポオペレーション状態の例がある。共有鍵材料の寿命を例にとり、共有鍵材料の寿命が48時間であり、44時間から48時間までの期間内に、共有鍵材料がハイポオペレーション状態であると仮定すると、共有鍵材料が45時間にわたって生存した場合に、この共有鍵材料がそのライフサイクルのハイポオペレーション状態にあると判断することができる。
【００７２】
エンティティ認証センタ(EAC)が、Kerberosサーバの機能を有する場合には、Kerberosモデルと組み合わされた認証問合せの機構を使用することができる。図6は、Kerberosモデルと組み合わされたエンドツーエンド認証モデルを示す概略図である。図6に示されているように、SSは、サービス許可チケットSGT(service granted ticket)をEACに要求し、SSのISR-IDおよびUIDをEACに供給する。EACは、ISR-IDおよびIAC-IDの妥当性をチェックし、サービス許可チケットを生成し、このサービス許可チケットをSSに返す。サービス要求をSPに発行する時に、SSは、要求内でサービス許可チケットを伝える。SPは、サービス許可チケットに従って派生鍵を生成し、その後、SSにサービス応答を返す。
【００７３】
図7は、図6に示された、Kerberosモデルと組み合わされた認証問合せのプロセスを示す概略図である。図7に示されているように、詳細なステップは、次の通りである。
【００７４】
ブロック701:あるサービスを獲得することを望む時に、SSは、まず、そのサービスに対応するサービス許可チケットがローカルに格納されているかどうかを検索する。格納されている場合には、ブロック705に進む。格納されていない場合には、SSは、SSのISR-IDおよびそのサービスを提供するSPのUIDを伝えるサービス許可チケット要求をEACに転送する。
【００７５】
ブロック702:サービス許可チケット要求を受信した時に、EACは、識別情報の妥当性および権限をチェックする。まず、EACは、要求内で伝えられたISR-IDが有効であるかどうかを問い合わせることによって、SSがそのサービスを使用する資格を与えられているかどうかを判断し、次に、要求内で伝えられたSPのUIDに従ってSPのIAC-IDを獲得し、IAC-IDが有効であるかどうかを判断することによって、SPがそのサービスを提供する資格を与えられているかどうかを判断する。
【００７６】
上記の判断が、SPがそのサービスを提供する資格を与えられている(すなわち、SPが正当である)ことを示す場合には、EACは、SSおよびSPの識別情報とSSおよびEACの共有鍵材料とに従って、SSとSPとの間のサービス通信を保護するための派生鍵K-SSP/SPを計算する。EACは、さらに、その派生鍵とSSおよびSPの識別情報とを含むサービス許可チケットを生成し、それ自体およびSPの共有鍵材料を使用して、そのSGTを暗号化する。
【００７７】
上記の判断が、SPがそのサービスを提供する資格を与えられていない(すなわち、SPが不正である)ことを示す場合には、EACは、エラーメッセージを転送し、EACでその識別情報を認証することについて、対応するエンティティに通知し、現在の手順を打ち切る。
【００７８】
ブロック703:EACは、上記で暗号化されたSGTをSSに転送する。
【００７９】
ブロック704:SGTを受信した時に、SSは、EACによって使用されたものと同一のパラメータおよびアルゴリズムを採用することによって、EACが生成したものと同一の派生鍵をローカルに生成する。
【００８０】
ブロック705:SSは、SGTを伝えるサービス要求をSPに転送する。
【００８１】
ブロック706:SPは、SGTを暗号化解除して、派生鍵を獲得する。
【００８２】
ブロック707:SPは、成功を識別するサービス要求応答をSSに返す。
【００８３】
ブロック708:SSおよびSPは、派生鍵を使用して、それらの間でサービスを保護する。
【００８４】
上記のブロック以外に、EACは、それ自体およびSSの共有鍵材料を使用して、派生鍵を暗号化し、暗号化された派生鍵をSSに転送することができる。したがって、SSは、ローカルに再計算するのではなく暗号化解除によって派生鍵を獲得することができる。
【００８５】
同様に、共有される派生鍵を獲得した後に、SSおよびSPは、その派生鍵を使用して、各サービス通信が始まる前にこの2つの当事者の間で相互認証を実行することができ、さらに、その通信のセキュリティを保護するセッション鍵Kr-SS-SPを生成し、その後、このセッション鍵を使用してサービス通信を保護することができる。
【００８６】
EACが、仲裁者として働くTTP(Trusted Third Party)の機能を有する場合には、Mediationモデルと組み合わされた認証問合せの機構を採用することもできる。図8は、Mediationモデルと組み合わされたエンドツーエンド認証モデルを示す概略図である。図8に示されているように、SSは、SPによって提供されるサービスを要求するために、サービス要求をEACに発行する。EACは、SSが正当であると判断した後に、このサービス要求をSPに転送する。SPは、それ自体のIAC-IDを伝えるサービス要求応答をEACに返す。EACは、IAC-IDに従ってSPの妥当性を判断する。SPが正当である場合には、EACは、SSとSPとの間の派生鍵を計算し、その派生鍵をSPに転送し、それと同時にサービス要求応答をSSに返す。SSは、この応答を受信した時に同一の派生鍵を計算する。
【００８７】
図9は、Mediationモデルと組み合わされた認証問合せのプロセスを示す流れ図である。図9に示されているように、詳細なブロックは、次の通りである。
【００８８】
ブロック901:SPによって提供されるサービスを使用することを望む場合に、SSは、まず、SSのISR-IDおよびSPのUIDを伝えるサービス要求をEACに発行する。
【００８９】
ブロック902:EACは、SSのISR-IDおよびSSのサブスクリプション情報の妥当性を判断して、SSがサービスを要求する資格を与えられているかどうかを判断する。
【００９０】
ブロック903:SSが正当である場合には、EACは、サービス要求をSPに転送し、ブロック904を実行する。SSが不正である場合には、EACは、エラーメッセージをSSに転送して、SSに、EACでのその識別情報の認証について通知し、現在の手順を打ち切る。
【００９１】
ブロック904:SPは、それ自体のIAC-IDを伝えるサービス要求応答を返す。
【００９２】
ブロック905:EACは、IAC-IDおよびSPのサブスクリプション情報の妥当性を検証して、SPがサービスを提供する資格を与えられているかどうかを判断する。SPが正当である場合には、EACは、SSおよびSPの識別情報ならびにSSおよびEACの共有鍵材料に従ってSSとSPとの間のサービス通信を保護する派生鍵を計算し、ブロック906を実行する。SPが不正である場合には、EACは、エラーメッセージをSPに転送して、SPに、EACでのそのIDの認証について通知し、現在の手順を打ち切る。
【００９３】
ブロック906:EACは、サービス要求成功応答をSSに転送し、EACおよびSPの共有鍵材料によって暗号化された派生鍵をSPに転送する。
【００９４】
ブロック907:EACによって転送されたサービス要求成功応答を受信した時に、SSは、EACによって使用されたものと同一のパラメータおよびアルゴリズムを採用して、派生鍵を獲得する。
【００９５】
ブロック908:SSおよびSPは、派生鍵を使用して、それらの間でサービスを保護する。
【００９６】
同様に、共有される派生鍵を獲得した後に、SSおよびSPは、各サービス通信が始まる前に、その派生鍵を使用して、この2つの当事者の間で相互認証を実行することができ、さらに、その通信のセキュリティを保護するセッション鍵Kr-SS-SPを生成し、その後、このセッション鍵を使用してサービス通信を保護することができる。
【００９７】
先の記載は、本発明の実施形態を例示するに過ぎない。サービスエンティティとして働くSSPなど、他の類似する状況で、SSPの形を変更することができる。SSPがサービスを要求する場合には、その処理の形は、上記のSSの処理の形と同一であるが、SSPがサービスを提供する場合には、その処理の形は、SPの処理の形と同一である。したがって、本発明の実施形態の範囲内で考えられ、当業者によって作られる一般的な変形形態および置換は、本発明の保護の範囲に含まれなければならない。
【００９８】
本発明による実施形態の認証方法の第1ステージおよび第2ステージの認証手順の実施形態を、以下で説明する。
【００９９】
図10は、本発明による実施形態でのサービスエンティティを認証する方法を示す流れ図である。図10を参照すると、本発明による認証方法の説明は、次の通りである。
【０１００】
ブロック1001:サービスエンティティは、そのサービスエンティティの識別情報、セキュリティ度合情報、そのサービスエンティティによよってサポートされる少なくとも1つの認証機構の情報(サービスエンティティによってサポートされる少なくとも1つの認証機構の情報が、ネットワークのサブスクリプション情報内に格納される場合には、認証機構の情報を伝えないものとすることができる)などを伝える認証要求をEACに転送する。
【０１０１】
識別情報には、プライベートID(PID)またはUIDを含めることができる。セキュリティ度合の選択に関して、次の状況を考慮することができる。1) サービスエンティティは、ローカルに格納されたサービスセキュリティ度合リストを検索することによって、所望のサービスに対応するセキュリティ度合を選択することができる。2) サービスエンティティが、セキュリティ度合リストをローカルに格納しない場合には、セキュリティ度合を、ヒューマン-コンピュータインターフェースを介して加入者が手動で選択することができる。3) サービスエンティティは、セキュリティ度合を選択せずに、対応するサービスを提供するSPのUIDだけをEACに供給することができ、ここで、そのUIDが、SPによって提供されるサービスのタイプを識別することができる。次に、EACは、サービスのタイプに従ってセキュリティ度合リストを検索し、これによって、対応するセキュリティ度合を選択することができる。
【０１０２】
ブロック1002:認証要求を受信した時に、EACは、要求内のIDに従ってESDに格納されたサブスクリプション情報を検索し、サービスエンティティおよびネットワークによってサポートされる認証機構とセキュリティ度合とを考慮して、ローカルポリシに従って認証機構を選択する。この実施形態で選択される認証機構を、認証機構bとして識別する。サポートされる認証機構には、AKA、SIM、CAVE、MN-AAA key、TLS-PSKまたはTLS-Cert、DHなどを含めることができる。
【０１０３】
ネットワークおよびサービスエンティティが、1つの認証機構だけをサポートするときには、2つの当事者は、ネゴシエーションなしで、相互認証を実行するためにその認証機構を採用することができる。セキュリティ度合を選択する時に、EACは、サービスのセキュリティ度合要件を考慮してもしなくてもよい、すなわち、条件としてのセキュリティ度合は、認証ネゴシエーション手順について任意選択である。
【０１０４】
ブロック1003:EACは、ブロック1002で選択された認証機構の識別子、セキュリティ度合(セキュリティ度合がブロック1002のネゴシエーション手順で考慮される場合には、セキュリティ度合は、サービスエンティティによって選択されたセキュリティ度合未満であってはならない)などを伝える認証初期化メッセージをサービスエンティティに転送する。
【０１０５】
フォローアップ認証対話手順がEACによって開始される場合に、認証初期化メッセージは、認証機構上で命じられる、この手順の最初の認証メッセージによって伝えられる情報を含まなければならない。第1認証メッセージの内容は、AKA認証に関して、認証ベクトルであり、TSL認証の形に関して、その内容は、Hello Requestである。
【０１０６】
ブロック1004:サービスエンティティは、認証機構を入手する。フォローアップ認証がサービスエンティティによって開始される場合には、サービスエンティティは、認証情報を計算するが、フォローアップ認証がEACによって開始される場合には、サービスエンティティは、関連する認証情報を受信した後に応答値を計算する。
【０１０７】
ブロック1005:選択された認証機構に基づく認証対話手順が、サービスエンティティとEACとの間で実行される。
【０１０８】
ブロック1006:認証の後に、サービスエンティティとEACとの両方が、共有鍵材料を入手し、EACは、サービスエンティティにISR-IDまたはIAC-IDを割り振り、このISR-IDまたはIAC-IDは、共有鍵材料に関連して格納され、共有鍵材料またはセキュリティ接続のSession IDを検索するためのインデックスとして働くことができる。
【０１０９】
図11は、本発明による実施形態で3GPP無線ネットワークのサービスエンティティを認証する方法を示す流れ図である。図11を参照すると、この実施形態では、サービスエンティティがSSである。SSが3GPPネットワーク内のモバイル端末すなわち図11のUEであり、AKA認証だけをサポートする場合に、認証手順は、次の通りである。
【０１１０】
ブロック1101:UEが、それ自体のIDを伝えるHTTPダイジェスト認証要求をEACに発行する。
【０１１１】
ブロック1102:3GPPネットワークおよびUEは、AKA機構だけをサポートするので、この2つの当事者は、認証機構をネゴシエートせずに、認証にAKA機構を直接に採用する。EACは、ESDから、UE加入者の認証ベクトル(RAND、AUTN、RES、CK、IK)を入手する。
【０１１２】
ブロック1103:EACは、認証ベクトル内でRANDおよびAUTNを伝えるHTTP 401メッセージ(ダイジェストAKAチャレンジを含む)をUEに転送する。
【０１１３】
ブロック1104:UEは、AUTNを計算し、AUTNの妥当性を検証して、ダイジェストAKAチャレンジを含むメッセージが許可されたネットワークから来たものであるかどうかを確認し、CK、IK、およびRESを計算する。
【０１１４】
ブロック1105:UEは、ダイジェストAKA応答および計算されたRESによって計算されたアブストラクト値を含むHTTP要求メッセージをEACに転送する。
【０１１５】
ブロック1106:EACは、計算されたアブストラクト値の正確さを検証して、UEの妥当性を認証する。
【０１１６】
ブロック1107:EACは、鍵材料Ks=CK‖IKおよびISR-IDを生成するが、その生成方法およびフォーマットは、3GPP包括的認証アーキテクチャのB-TIDの生成方法およびフォーマットと同一である。
【０１１７】
ブロック1108:EACは、200 OKメッセージをUEに転送して、認証の成功の終了を識別し、このメッセージは、Ksによって暗号化されるが、鍵材料の寿命およびISR-IDを含む。
【０１１８】
ブロック1109:UEも、同一の鍵材料Ks=CK‖IKを生成し、暗号化解除によってISR-IDおよび鍵材料の寿命を獲得し、ISR-IDおよび鍵材料の寿命をローカルに格納し、これらを認証機構に関連付ける。
【０１１９】
図12は、本発明による実施形態での3GPP2無線ネットワークでサービスエンティティを認証する方法を示す流れ図である。この実施形態では、サービスエンティティがSSである。SSが、UEであり、AKA認証、証明書認証などの認証方法をサポートするが、3GPP2ネットワークが、AKA認証、CAVEベースの認証機構、およびMN-AAAベースの認証機構をサポートする場合には、認証手順は、図12を参照すると、次の通りである。
【０１２０】
ブロック1201:UEは、UEの識別情報と、AKA認証および証明書認証など、UEがサポートする認証モードとを伝えるHTTP認証要求をEACに発行する。
【０１２１】
ブロック1202:EACは、ESD内で、UEの識別情報に従ってUEのサブスクリプション情報を検索し、AKA認証、CAVEベースの認証機構、MN-AAAベースの認証機構など、自己がサポートする認証機構タイプに従ってローカルポリシを採用することによって、2つの当事者が認証を実行するためにAKA機構を使用すると判断する。EACは、ESDからUE加入者の認証ベクトル(RAND、AUTN、RES、CK、IK)を獲得する。
【０１２２】
ブロック1203:EACは、RANDおよびAUTNを伝えるHTTP 401メッセージ(ダイジェストAKAチャレンジを含む)をUEに転送し、このメッセージのペイロード情報内に認証機構識別子を置く。
【０１２３】
ブロック1204:UEは、AUTNを計算し、AUTNの正確さを検証して、チャレンジを含むメッセージが許可されたネットワークから来たものであるかどうかを確認し、CK、IK、およびRESを計算する。
【０１２４】
ブロック1205:UEは、ダイジェストAKA応答およびRESによって計算されたアブストラクト値を含むHTTP要求メッセージをEACに送信する。
【０１２５】
ブロック1206:EACは、アブストラクト値の正確さを検証して、UEの妥当性を認証する。
【０１２６】
ブロック1207:EACは、鍵材料Ks=CK‖IKおよびISR-IDを生成するが、その生成方法およびフォーマットは、3GPP2包括的認証アーキテクチャのB-TIDの生成方法およびフォーマットと同一である。
【０１２７】
ブロック1208:EACは、200 OKメッセージをUEに送信して、認証の成功の終了を識別し、このメッセージは、Ksによって暗号化され、ISR-IDおよび鍵材料の寿命を含む。
【０１２８】
ブロック1209:UEも、同一のKs=CK‖IKを生成し、暗号化解除によってISR-IDおよび鍵材料の寿命を獲得し、ISR-IDおよび鍵材料の寿命を認証機構に関連付け、これらをローカルに格納する。
【０１２９】
認証要求を受信した後に、UEがCAVEベースの認証機構をもサポートする場合には、EACは、それ自体の識別情報に従ってサブスクリプション情報を検索し、最終的に、それがサポートする認証モードのタイプを考慮してローカルポリシを採用することによって、CAVEベースの認証機構を使用しなければならないと判断し、フォローアップ認証手順は、3GPP2包括的認証アーキテクチャのCAVEベースの認証手順と同一である。AAA認証機構を使用しなければならないと判断される場合には、本発明の実施形態の包括的認証アーキテクチャを、同一の原理に従って使用することもできる。
【０１３０】
図13は、本発明による実施形態において、SPが銀行である場合の、SPとエンティティ認証センタとの間で相互に認証する方法を示す流れ図である。この実施形態では、サービスエンティティは、銀行SPである。銀行SPが、UEに携帯電話銀行サービスを提供することを望むときに、銀行SPは、まず、共有鍵材料を生成し、セキュリティ接続を確立するために、EACとの相互認証を実行する必要があり、認証手順は、図13を参照すると、次の通りである。
【０１３１】
ブロック1301:SPが、それ自体のUIDを伝える認証要求をEACに転送する。
【０１３２】
ブロック1302:EACは、UIDに従ってSPのサブスクリプション情報を検索し、SPがサービスを提供する資格を与えられていると判断した後に、SPの認証能力の情報すなわち、証明書、証明書TLS認証、事前に供給される鍵ベースのTLS認証など、SPによってサポートされる認証モードを獲得する。
【０１３３】
次に、EACは、サービスセキュリティ度合リストを検索し、携帯電話銀行サービスが高セキュリティ度合サービスに属すると判断し、認証セキュリティ度合リストを検索することによって、高セキュリティ度合を有するネットワークによってサポートされる認証モードが、HTTPダイジェストAKA、証明書TLS認証などを含むことを見つける。また、EACは、最終的に、SPによってサポートされる認証機構を照合し、相互認証で使用される認証機構を決定する。この実施形態では、証明書TLSを使用すると判断される。
【０１３４】
ブロック1303:EACは、認証機構識別子(この実施形態では、証明書TLS認証の識別子である)およびセキュリティ度合識別子を伝えるHello RequestメッセージをSPに向けて開始する。
【０１３５】
ブロック1304:SPは、認証機構が証明書TLSであることを知り、ローカルにSession IDすなわちIAC-IDがあるかどうかを検索する。TLSセキュリティチャネルが、EACの証明書TLS認証を介して確立済みであり、そのチャネルがまだ有効である場合には、Session IDを、TLSセキュリティチャネルのインデックスとすることができる。
【０１３６】
ブロック1305:SPは、Client HelloメッセージをEACに転送する。SPが有効なSession IDを格納していない場合には、このメッセージのSession IDフィールドはヌルであり、SPが有効なSession IDすなわちIAC-IDを格納している場合には、このメッセージのSession IDフィールドはIAC-IDである。
【０１３７】
ブロック1306:Client Helloメッセージを受信した時に、EACは、Session IDフィールドがヌルであるかどうかを検証する。Session IDフィールドがヌルではなく、関連するセキュリティ接続情報を、Session IDフィールド内で伝えられた情報と照合できる場合には、EACは、FinishedメッセージをSPに直接に転送して、セキュリティ接続の認証結果および共有鍵材料が使用可能であるかどうかを検証する。Finishedメッセージ内のパラメータが正しいことを検証した後に、SPは、もう1つのFinishedメッセージをEACに返す。EACが、Finishedメッセージ内のパラメータが正しいことを検証する場合に、この2つの当事者は、そのセキュリティ接続を再利用する。
【０１３８】
Session IDフィールドがヌルであるか、上記のFinishedメッセージがエラーを有する場合には、EACは、ローカルポリシ構成メッセージ内のパラメータに従って、Server certificateメッセージ、ServerKeyExchangeメッセージ(任意選択)、およびCertificateRequestメッセージを返す。最終的に、EACは、ServerHelloDoneメッセージを返して、ServerHelloメッセージおよび関連メッセージが転送され終えたことを示す。
【０１３９】
ブロック1307:ServerHelloDoneメッセージを受信した時に、SPは、Certificateメッセージを返し、その後、ClientKeyExchangeメッセージを転送し、このClientKeyExchangeメッセージを介して、2つの当事者は、共有される秘密パラメータを獲得する。その後、SPは、CertifiicateVerifyメッセージをEACに転送して、SPの証明書を明瞭に検証することにおいてEACを容易にする。最後に、ChangeCipherSpecメッセージを転送した後に、SPは、即座にFinishedメッセージをEACに転送して、鍵交換および認証手順が成功であることを識別する。
【０１４０】
ブロック1308:EACは、SPのFinishedメッセージ内の情報が正しいかどうかを検証する。この情報が正しくない場合には、現在のハンドシェーク手順を打ち切り、この情報が正しい場合には、もう1つのFinishedメッセージをSPに返す。SPが、Finishedメッセージ内の情報が正しいことを検証する場合に、これは、2つの当事者間の認証および鍵交換手順が成功であることを意味する。
【０１４１】
この実施形態は、3GPP/3GPP2ネットワーク内のNAFを認証する均一な手順を提供し、この手順は、本発明による包括的認証アーキテクチャについても適用可能である。
【０１４２】
本発明の上記の実施形態に基づいて、エンティティ認証の装置も提供される。図14は、本発明の実施形態での認証の装置の実施形態を示す構造図である。図14を参照すると、エンティティ認証の装置は、認証要求を転送するモジュール、ネゴシエーションのモジュール、および認証対話のモジュールを含む。
【０１４３】
認証要求を転送するモジュールは、サービスエンティティの認証要求をEACに転送するのに使用され、この認証要求の内容は、サービスエンティティの識別情報を含む。ネゴシエーションのモジュールは、認証要求を受信した後に、EACのローカルポリシに従って認証機構を選択するように構成される。認証対話のモジュールは、サービスエンティティとEACとの間で、選択された認証機構に基づいて認証対話を実行するのに使用される。諸機能の実行に関するこれらのモジュールの原理は、上記の手順で説明済みであり、本明細書では説明しない。
【０１４４】
上記の認証解決策を基礎として、サービスエンティティとEACとの間の認証機構、認証問合せの機構および派生鍵を生成する機構、サービスエンティティの間の認証機構、ならびにセッション鍵を生成する機構などを含む、サービスエンティティ認証、認証問合せ手順、およびサービスエンティティの間の相互認証を全体として定義する認証モードをまず定義することを含む、機能強化された解決策が、本発明の実施形態によって提供される。この解決策は、短く次のように説明される。
【０１４５】
1. 認証モードの定義
主にSSおよびEACの認証機構によって決定され、時々SSおよびSPの認証機構によって決定される、E2E認証モードを定義することができる。その認証モードでは、SSおよびEACの認証機構、SPおよびEACの認証機構、SSとSPとの間の認証機構、認証問合せの機構、派生鍵を生成する機構、セッション鍵を生成する機構などを含む複数の認証関連モードが定義され、実用的な応用例では、上記の認証関連モードの一部だけを、いくつかの場合に関して認証モード内で定義することができる。たとえば、SSおよびSPが、認証機構をネゴシエートせずに直接に認証でき、セキュリティ接続を確立できる場合に、SSとEACとの間の認証およびSPとEACとの間の認証は、不要である。したがって、この場合の認証関連モードでは、SSとSPとの間の認証機構およびセッション鍵を生成する方法だけを定義すればよい。
【０１４６】
この認証モードでは、認証機構が任意選択であるか否かおよび認証方法をネゴシエートしなければならないか否かを含めて、各認証機構の選択するポリシをさらに定義することができる。
【０１４７】
次のように、本発明の実施形態によって採用できる複数のタイプのエンドツーエンド(E2E)認証モードがある。
【０１４８】
E2E_3GPP_AKA、E2E_3GPP2_AKA、E2E_3GPP2_CAVE、E2E_WLAN、E2E_3GPP2_MNAAA、E2E_3GPP_WLAN、E2E_Kerberos、E2E_Mediation、E2E_TLS(しかし、認証モードの定義は、これらのタイプに限定はされず、新しいタイプを必要に応じて定義することもできる)。これらのタイプの認証モードの実施形態は、次の通りである。
【０１４９】
1. E2E_3GPP_AKAの定義は、次の通りである。
E2E_3GPP_AKA ::= struct {
SS<->EAC認証機構 AKA
ベアラプロトコル HTTPダイジェスト
SP<->EAC認証機構 TLS機構(またはIPSecチャネル機構など)
SS<->SP認証機構 基本的な問合せ機構
ベアラプロトコル TLS(または他のプロトコル)
セッション鍵を生成する機構 自己定義(または他の任意選択の機構)
}
【０１５０】
2. E2E_3GPP2_CAVEの定義は、次の通りである。
E2E_3GPP2_CAVE ::= struct {
SS<->EAC認証機構 CAVEに基づく認証
ベアラプロトコル HTTPダイジェスト
SP<->EAC認証機構 TLS機構(またはIPSecチャネル機構など)
SS<->SP認証機構 基本的な問合せ機構
ベアラプロトコル TLS(または他のプロトコル)
セッション鍵を生成する機構 自己定義(または他の任意選択の機構)
}
【０１５１】
3. E2E_WLAN ::= struct {
SS<->EAC認証機構 AKA (またはSIM)
ベアラプロトコル EAP (Extensible Authentication Protocol)
SP<->EAC認証機構 TLS機構(またはIPSecチャネル機構など)
SS<->SP認証機構 基本的な問合せ機構
ベアラプロトコル TLS(または他のプロトコル)
セッション鍵を生成する機構 自己定義(または他の任意選択の機構)
}
【０１５２】
4. E2E_Kerberosの定義は、次の通りである。
SS<->EAC認証機構(ネゴシエーション可能、たとえば、AKA、CABEベースの認証、証明書ベースの認証)
SP<->EAC認証機構 IPSecチャネル(または他の任意選択の機構)
SS<->SP認証機構 Kerberos(強制的、Kerberos解決策および変更されたKerberos解決策のうちのどれを使用しなければならないかをネゴシエートすることができる)
ベアラプロトコル TCP (または他のプロトコル)
セッション鍵を生成する機構 TLS-Krb5 (または他の任意選択の機構)
}
【０１５３】
5. E2E_TLSの定義は、次の通りである。
E2E_TLS ::= struct {
SS<->EAC認証機構 なし
SP<->EAC認証機構 なし
SS<->SP認証機構 TLS
セッション鍵を生成する機構 TLS-PSK5 (または他の任意選択の機構)
}
【０１５４】
6. E2E_3G_GAAの定義は、次の通りである。
SSとEACとの間の認証機構は、SIM、AKA、CAVE、MN-AAA Key、TLS-PSK、TLS-Certなどのうちのいずれかとすることができる;
SPとEACとの間の認証機構は、TLS、IKEとすることができる;
認証問合せの機構および派生鍵を生成する機構は、GBAである;
SSとSPとの間の認証機構は、TLS-PSK、TLS-Certとすることができる。
【０１５５】
7. E2E_KERBEROSの定義は、次の通りである。
SSとEACとの間の認証機構は、E2E_3G_GAAで定義されたものとすることができ、EACは、認証の後にSGTを生成し、サービスエンティティに送信する;
SPとEACとの間の認証機構は、NULL、TLS、IKEとすることができる;
認証問合せの機構および派生鍵を生成する機構は、Kerberosである;
SSとSPとの間の認証機構は、NULL、TLS-KBR5とすることができる。
【０１５６】
8. E2E_Mediationの定義は、次の通りである。
SSとEACとの間の認証機構は、E2E_3G_GAAで定義されたもののほかに、IKEとすることができる;
SPとEACとの間の認証機構は、E2E_3G_GAAで定義されたものとすることができる;
認証問合せの機構および派生鍵を生成する機構は、Mediationである;
SSとSPとの間の認証機構は、TLS-PSKである。
【０１５７】
9. E2E_TLSの定義は、次の通りである。
SSとEACとの間の認証機構は、NULLである;
SPとEACとの間の認証機構は、NULLである;
認証問合せの機構および派生鍵を生成する機構は、NULLである;
SSとSPとの間の認証機構は、TLS-Cert、TLS-PSKとすることができる。
【０１５８】
上記のモードでは、新しい認証モードを、サービス要件に従って定義することができる。本発明の実施形態は、認証機構、選択ポリシ、および鍵を生成する機構など、認証モードで定義された特定の認証関連モードに限定されない。
【０１５９】
図15は、本発明の実施形態でのサービス加入者とEACとの間の認証手順を示す流れ図である。図15を参照すると、この実施形態では、3GPPネットワーク内のモバイル加入者のUEが、インターネット内のアプリケーションサーバによって提供されるサービスを使用する(このサーバは、Kerberos認証プロトコルをサポートする)。詳細な手順は、次の通りである。
【０１６０】
ブロック1501:SS(すなわち、UE)は、UEのID、認証機能識別子、サービスタイプを伝えるサービス要求をEACに転送し、このサービス要求は、EACがUIDを介してエンティティサブスクリプションデータベース(ESD)から対応するサービスタイプを検索することを可能にするために、サービスタイプではなく、SPのUIDを伝える場合がある。
【０１６１】
ブロック1502:EACは、サービス要求内のIDと、SSおよびSPの認証機能の情報とに従ってローカルポリシを採用することによって、認証モードおよび対応する認証機構を選択する。この実施形態では、選択される認証モードが、E2E_Kerberosモードであると仮定する。
【０１６２】
EACは、ローカルポリシおよび認証モード内の選択するポリシに従って各認証機構を判断することができる。ローカルポリシは、SSおよびSPが、この2つの当事者の認証機能およびサービスタイプに従って相互認証機構およびセッション鍵を生成する機構を選択することとすることができ、SPとEACとの間で相互認証を実行するかどうかは、SSおよびSPの相互認証機構によって判断することができる。相互認証を実行する必要がある場合には、認証機構は、SPおよびEACの認証機能ならびにサービスタイプなどに従って選択される。
【０１６３】
ブロック1503:E2E_Kerberosモードの定義に従って、SSおよびEACの認証機構は、ネゴシエーション可能であり、したがって、認証機構を、ローカルポリシ(すなわち、2つの当事者の認証機能、2つの当事者によって使用されるサービスのタイプなど)に従って選択することができる。この実施形態では、SSおよびEACの認証機構は、AKA認証機構と仮定される。SSおよびEACの認証機構は、IPSecチャネルまたは他の機構とすることができ、任意選択である。この実施形態では、SSおよびEACの認証機構が、ヌルとして構成される、すなわち、SPとEACとの間の認証が実行されないと仮定する。SSおよびSPの認証機構は、Kerberosとしてセットされ、したがって、SSおよびSPの認証機構は、Kerberosまたは変更されたKerberos解決策のどちらを使用するかを判断することによってネゴシエートすることができ、ベアラプロトコルは、ネゴシエーションによってTCPまたは他のプロトコルとすることができる。この実施形態では、2つの当事者の認証機能、サービスタイプなどに従って、ネゴシエーションを介して、Kerberosが、SSおよびSPの認証機構として選択され、TLS-Krb5が、ベアラプロトコルとして選択される。セッション鍵を生成する機構は、TLS-Krb5または他の機構としてセットされ、任意選択であり、この実施形態では、TLS-Krb5が、セッション鍵を生成する機構として選択される。
【０１６４】
上記で選択されたさまざまな認証モードに従って、SSとEACとの間の認証を開始することができる。SSおよびEACが、AKA相互認証を実行済みであり、生成された共有鍵およびISR-IDが、まだ寿命のうちである場合には、AKA相互認証を実行する必要はなく、ブロック1509を直接に実行して、SGTを生成することになる。
【０１６５】
ブロック1504:EACは、加入者の認証ベクトル(RAND、AUTN、RES、CK、IK)をESDから獲得する。
【０１６６】
ブロック1505:EACは、RANDおよびAUTNを伝えるHTTP 401メッセージ(ダイジェストAKAチャレンジを含む)をUEに転送し、メッセージのペイロード情報内で認証機構識別子aを伝える。
【０１６７】
ブロック1506:UEは、AUTNを計算し、受信したAUTNの妥当性を検証して、チャレンジが許可されたネットワークから来たかどうかを確認し、CK、IK、およびRESを計算する。
【０１６８】
ブロック1507:UEは、ダイジェストAKA応答およびRESを使用することによって計算されたアブストラクト値を含むHTTPメッセージをEACに転送する。
【０１６９】
ブロック1508:EACは、計算されたアブストラクト値の正確さを検証して、UEの妥当性を認証する。
【０１７０】
ブロック1509:EACは、共有鍵Ks=CK‖IKおよびISR-IDを生成し、次に、共有鍵Ks、SSのID、およびSPのUIDを使用して派生鍵Kspを生成し、生成された派生鍵をSGT内で伝え、このSGTの内容は、Ksp、SSのISR-ID、SPのUID、寿命、反射攻撃を防ぐためのパラメータなどを含み、SGTは、EACおよびSPの共有鍵によって暗号化される。
【０１７１】
ブロック1510:EACは、共有鍵の寿命、ISR-ID、およびKsを使用することによって暗号化されたSGTを含む200 OKメッセージをUEに転送して、認証の成功の終了を識別する。
【０１７２】
ブロック1511:UEは、共有鍵Ks=CK‖IKおよび派生鍵Kspをも生成し、その後、暗号化解除によって200 OKメッセージ内のISR-IDを獲得し、暗号化解除によって獲得した上記情報を認証モード情報に関連付け、関連付けられた情報をローカルに格納する。
【０１７３】
図16は、本発明による実施形態での、SSとSPとの間の相互認証のプロセスを示す流れ図である。図16を参照すると、SSとSPとの間の相互認証の詳細な手順は、次の通りである。
【０１７４】
ブロック1601:SSは、SPのUID、SSによってサポートされるTLS-KRB5暗号化スイート、およびE2E_Kerberosの認証モードの関連情報を伝えるClientHelloメッセージをSPに転送する。
【０１７５】
E2E_Kerberosの認証モードの関連情報は、SSとSPとの間の認証機構およびセッション鍵を生成する機構を含む、定義されたモードを指す。
【０１７６】
ブロック1602:Client Helloメッセージを受信した時に、SPは、Session IDフィールドがヌルであることを見つけ、その後、2つの当事者によってサポートされるTLS-KRB5暗号化スイートを選択し、ServerRequestメッセージ、ServerHello、およびServerHelloDoneメッセージをSSに転送する。
【０１７７】
ブロック1603:ServiceHelloDoneメッセージを受信した時に、SSは、ClientKeyExchangeメッセージをSPに転送し、これによって、この2つの当事者は、事前に共有された秘密パラメータ(PreMasterSecret)を獲得する。SSは、PreMasterSecretおよび乱数を使用して、セッション鍵(MasterSecret)を生成する。その後、SSは、ChangeCipherSpecメッセージをSPに転送し、その後、正式の鍵交換および妥当性検査のためにFinishedメッセージをSPに転送する。
【０１７８】
ブロック1604:SPは、SGTを暗号化解除し、SGTの妥当性をチェックし、共有される派生鍵Kspを獲得し、共有される派生鍵Kspを使用してPreMasterSecretを暗号化解除し、PreMasterSecretおよび乱数に従ってSSおよびSPのセッション鍵MasterSecretを生成する。その後、SPは、SSからのFinishedメッセージ内の情報が正しいかどうかを検証する。この情報が正しくない場合には、SPは、現在の手順を打ち切り、そうでない場合には、ブロック1605を実行する。
【０１７９】
ブロック1605:SPは、ChangeCipherSpecメッセージをSSに転送し、その後、FinishedメッセージをSSに転送する。
【０１８０】
ブロック1606:SSは、SPからのFinishedメッセージ内の情報が正しいかどうかを検証する。SSが、SPからのFinishedメッセージ内の情報が正しいと判断する場合には、これは、この2つの当事者の間の認証および鍵交換手順が成功して終了したことを意味する。
【０１８１】
ブロック1607:SSおよびSPは、サービス通信データの転送を始める。
【０１８２】
上記の手順で確立されたセッションが期限を過ぎてはいないときに、SSがもう一度サービス要求をSPに転送する場合に、最後のセッションで生成されたPreMasterSecretを再利用して、このサービス通信のための新しいセッション鍵(MasterSecret)を生成することができる。
【０１８３】
図17は、本発明による実施形態での、セッション鍵を生成するためにSSおよびSPが認証結果を再利用するプロセスを示す流れ図である。図17を参照すると、詳細な手順は、次の通りである。
【０１８４】
ブロック1701:SSは、最後に発生した最後のセッションのSession IDを伝えるClient HelloメッセージをSPに転送する。
【０１８５】
ブロック1702:Client Helloメッセージを受信した時に、SPは、メッセージ内のSession IDがヌルとしてセットされてはいないことを見つけ、そのSession IDに関連するセキュリティ接続情報を照合することができ、したがって、そのSession IDは、このセッションを識別するために再利用される。さらに、SPは、Session IDを伝えるServerHelloメッセージをSSに転送し、その後、ServerHelloDoneメッセージをSSに転送する。
【０１８６】
ブロック1703:SSは、SPと共有されたPreMasterSecretを使用してセッション鍵(MasterSecret)を生成する。
【０１８７】
ブロック1704:SSは、ChangeCipherSpecメッセージをSPに転送し、その後、FinishedメッセージをSPに転送する。
【０１８８】
ブロック1705:受信したFinishedメッセージが正しいと判断した後に、SPは、同一のPreMasterSecretを使用して、セッション鍵(MasterSecret)を生成する。
【０１８９】
ブロック1706:SPは、ChangeCipherSpecメッセージをSSに転送し、その後、FinishedメッセージをSSに転送する。
【０１９０】
ブロック1707:SSによって受信されたFinishedメッセージが正しいと判断される場合に、この2つの当事者の間の相互認証が打ち切られ、サービス通信データが転送され始める。
【０１９１】
認証モードに基づく機能強化されたエンティティ認証解決策に従って、エンティティ認証のもう1つの装置が、本発明による実施形態によって提供される。この装置は、図14に示された装置に類似する。図18は、本発明によるエンドツーエンド通信認証装置の実施形態を示す概略図である。図18を参照すると、エンティティ認証の装置は、認証要求をEACに転送するように構成された転送するモジュール(図14に示された認証要求を転送するモジュールに類似する)と、転送するモジュールによって転送された認証要求に従って認証モードを選択し、サービスエンティティに知らせるように構成された選択するモジュール(図14のネゴシエーションのモジュールに類似する)と、選択するモジュールによって選択された認証機構に従って、サービスエンティティとEACとの間またはサービスエンティティの間で認証を実行するように構成された認証のモジュールとを含む。これらのモジュールの特定の機能を実施するための原理は、上記の手順で説明済みであり、したがって、さらなる説明は、本明細書では提供しない。
【０１９２】
もちろん、上記の2つの装置の機能を実現できる、エンティティ認証の別の装置を、本発明による実施形態によって提供することができる。この装置は、上記の転送するモジュールおよび認証要求を転送するモジュールの機能を実行するのに使用される第1モジュールと、選択するモジュールおよびネゴシエーションのモジュールの機能を実行するのに使用される第2モジュールと、認証のモジュールおよび認証対話のモジュールの機能を実行するのに使用される第3モジュールとを含むことができる。この装置に関するさらなる説明は、本明細書では提供しない。
【０１９３】
以上の記載は、本発明の実施形態に過ぎず、本発明の保護の範囲を限定するのに使用するためのものではない。本発明の趣旨および原理の範囲内のすべての変更、同等の置換、または改善は、添付の特許請求の範囲の保護範囲に含まれなければならない。
【図面の簡単な説明】
【０１９４】
【図１】GAA(Generic Authentication Architecture)のアーキテクチャを示す概略図である。
【図２】従来技術の3GPP2でのGAAのアーキテクチャを示す図である。
【図３】本発明の実施形態によるモバイルネットワークに基づくエンドツーエンド通信認証のアーキテクチャを示す概略図である。
【図４】本発明による実施形態での、サービスエンティティとエンティティ認証センタとの間で認証機構をネゴシエートし、相互認証を実行するプロセスを示す流れ図である。
【図５】本発明による実施形態での、サービスエンティティとエンティティ認証センタとの間での認証問合せのプロセスを示す流れ図である。
【図６】Kerberosモデルと組み合わされたエンドツーエンド認証モデルを示す概略図である。
【図７】Kerberosモデルと組み合わされた認証問合せのプロセスを示すブロック図である。
【図８】Mediationモデルと組み合わされたエンドツーエンド認証モデルを示す概略図である。
【図９】Mediationモデルと組み合わされた認証問合せのプロセスを示すブロック図である。
【図１０】本発明による実施形態でのサービスエンティティを認証する方法を示す流れ図である。
【図１１】本発明による実施形態による3GPP無線ネットワークでサービスエンティティを認証する方法を示す流れ図である。
【図１２】本発明による実施形態での3GPP2無線ネットワークでサービスエンティティを認証する方法を示す流れ図である。
【図１３】本発明による実施形態での、SPが銀行である場合の、SPとエンティティ認証センタとの間で相互に認証する方法を示す流れ図である。
【図１４】本発明の実施形態による、認証装置の実施形態の構造を示す概略図である。
【図１５】本発明による実施形態での、サービス加入者とエンティティ認証センタとの間の認証のプロセスを示す流れ図である。
【図１６】本発明による実施形態での、サービス加入者とサービスプロバイダとの間の相互認証のプロセスを示す流れ図である。
【図１７】本発明による実施形態での、セッション鍵を生成するためにサービス加入者およびサービスプロバイダが認証結果を再利用するプロセスを示す流れ図である。
【図１８】本発明によるエンドツーエンド通信認証装置の実施形態の構造を示す概略図である。
【符号の説明】
【０１９５】
101 加入者
102 BSF(Bootstrapping Server Function)
103 HSS(Home Subscriber Server)
104 NAF(Network Application Function)
201 MN(Mobile Node)
202 NAF(Network Application Function)
203 BSF
204 HSS
301 サービス加入者(SS)
302 サービスプロバイダ(SP)
303 エンティティ認証センタ(EAC)
304 エンティティサブスクリプションデータベース(ESD)
【技術分野】
【０００１】
本発明は、ネットワーク通信サービス技法に関し、具体的には、モバイルネットワークに基づくエンドツーエンド通信での認証の方法、システム、および認証センタに関する。
【背景技術】
【０００２】
現在、サービスをモバイル加入者に提供する時に、アプリケーションサーバの大多数は、まず、モバイル加入者と認証プロキシとの間、モバイル加入者と公開鍵基盤(PKI)証明機関との間、モバイル加入者とコンテンツ提供サーバとの間など、相互信頼関係をモバイル加入者と共に確立する。一般に、そのような信頼関係は、モバイル加入者とアプリケーションサーバとの間の双方向認証手順中に確立される。
【０００３】
3G無線通信標準規格では、GAA(Generic Authentication Architecture)が、加入者識別情報を検証するためにさまざまなアプリケーションサービスエンティティによって使用される一般的アーキテクチャであり、アプリケーションサービス加入者をチェックし、加入者識別情報を検証することができる。上記アプリケーションサービスは、マルチキャスト/ブロードキャストサービス、ユーザ証明書サービス、瞬時情報を提供するサービス、またはプロキシサービスとすることができる。
【０００４】
図1は、GAAのアーキテクチャを示す概略図であり、このGAAは、一般に、加入者101、加入者識別情報の初期チェックおよび検証を実行するBSF(Bootstrapping Server Function) 102、HSS(Home Subscriber Server) 103、およびNAF(Network Application Function) 104を含む。BSF 102は、加入者101との相互識別情報検証を実行し、BSF 102および加入者101の共有鍵を生成するように働く。HSS 103は、加入者情報を記述するプロファイルを格納し、認証情報を生成する機能を有する。
【０００５】
サービスを使用することを望む時に、加入者は、サービスがBSFを用いる相互認証手順を必要とする場合に、相互認証のために直接にBSFと通信する。そうでない場合には、加入者は、まずサービスに対応するNAFに連絡し、NAFがGAAを使用するがサービスを要求する加入者が相互認証手順のためにBSFと通信してはいない場合には、NAFは、サービスを要求する加入者に、BSFとの識別情報検証を実行するように通知する。
【０００６】
相互認証が成功した時に、加入者およびBSFは、互いの識別情報を認証し、共有鍵Ksを生成する。さらに、BSFは、Ksの更新を容易にするために、Ksの寿命を定義する。後に、BSFは、加入者のB-TID(Bootstrapping Transaction Identifier)を割り振り、そのB-TIDをKsの寿命と共にユーザ機器(UE)に転送し、ここで、B-TIDが、Ksに関連付けられる。共有鍵Ksは、ルート鍵として使用されるが、加入者のUEおよびBSFから出ない。加入者がNAFと通信する時には、Ksから導出された鍵Ks_NAFが、通信を保護するのに使用される。
【０００７】
GAAの不利益は、1. 1つの認証機構(すなわちAKA認証機構)だけが、加入者とBSFとの間の認証でサポートされることと、2. 認証機構が、BSFとNAFとの間の認証を提供せず、これが、NAFを偽る攻撃者による加入者の秘密情報の窃取をもたらす可能性があることである。
【０００８】
3GPP2にもGAAがあり、図2を参照されたい。図2は、既存の3GPP2でのGAAを示す図である。3GPP2のGAAは、MN(Mobile Node) 201、NAF(Network Application Function) 202、加入者識別情報の初期チェックおよび検証を実行するBSF 203、HSS 204、HLR/AC(Home Location Register/Authentication Centre)、およびAAA(Authentication Authorization Accounting)サーバがある。
【０００９】
NAFによって提供されるサービスを使用することを望む場合に、MNは、まず、BSFとの相互認証を実行しなければならない。MNおよびネットワークのサポート条件ならびにオペレータのローカルポリシに従って自由に選択できる3タイプの相互認証機構(AKA認証機構、CAVEベース認証機構、およびAAAベース認証機構を含む)がある。
【００１０】
しかし、3GPP2のGAAは、3つの認証機構だけをサポートし、これは、あるサービスエンティティとさまざまなネットワークとの間の相互認証に適用可能ではない。さらに、認証機構は、BSFとNAFとの間の認証を提供せず、これは、NAFを偽る攻撃者による加入者の秘密情報の窃取をもたらす可能性がある。
【００１１】
要約すると、既存のGAAは、それが属する標準規格の中でのみ適用可能であり、ネットワークおよびサービスエンティティによって制限され、したがって、いくつかの制限を有する。
【発明の開示】
【課題を解決するための手段】
【００１２】
本発明による実施形態は、さまざまなエンティティの間で相互信頼関係を確立するために異なるモバイルネットワーク標準規格について適用可能である包括的認証アーキテクチャを提供する。
【００１３】
本発明の実施形態による技術的解決策は、次の通りである。
【００１４】
本発明の実施形態は、サービスを要求する第1サービスエンティティと、サービスを提供する第2サービスエンティティと、エンティティ認証センタすなわちEACとを具備するシステムに適用される、モバイルネットワークに基づくエンドツーエンド通信において認証する方法であって、第1サービスエンティティとEACとの間で認証モードをネゴシエートする段階であって、ネゴシエートされた認証モードは、第1サービスエンティティとEACとの間の認証機構と、第2サービスエンティティとEACとの間の認証機構と、認証問合せの機構と、派生鍵を導出する機構と、第1サービスエンティティと第2サービスエンティティとの間の認証機構とを含む、段階と、ネゴシエートされた認証モードに含まれる第1サービスエンティティとEACとの間の認証機構に従ってEACと第1サービスエンティティとの間で相互認証を実行し、ネゴシエートされた認証モードに含まれる第2サービスエンティティとEACとの間の認証機構に従ってEACと第2サービスエンティティとの間で相互認証を実行する段階と、第1サービスエンティティが、サービスを提供するように第2サービスエンティティに要求する場合に、EACが、ネゴシエートされた認証モードに含まれる認証問合せの機構に従って第1サービスエンティティおよび第2サービスエンティティに関する認証問合せを提供し、ネゴシエートされた認証モードに含まれる派生鍵を生成する機構に従って第1サービスエンティティと第2サービスエンティティとの間の通信を保護する共有される派生鍵を生成する段階と、第1サービスエンティティおよび第2サービスエンティティが、共有される派生鍵、およびネゴシエートされた認証モードに含まれる第1サービスエンティティと第2サービスエンティティとの間の認証機構に従って互いを認証し、サービスを保護するセッション鍵を生成する段階とを有することを特徴とする方法を開示する。
【００１５】
また、本発明の実施形態は、サービスエンティティおよびEACに適用される、サービスエンティティを認証する方法であって、サービスエンティティとEACとの間で認証モードをネゴシエートする段階であって、ネゴシエートされた認証モードは、サービスエンティティとEACとの間の認証機構を含む、段階と、ネゴシエートされた認証モードに含まれる認証機構に従ってサービスエンティティとEACとの間で相互認証を実行する段階とを有することを特徴とする方法を開示する。
【００１６】
本発明の実施形態は、サービスを要求する第1サービスエンティティと、サービスを提供する第2サービスエンティティと、EACとを具備するシステムに適用される、認証問合せの方法であって、第1サービスエンティティとEACとの間の相互認証と、第2サービスエンティティとEACとの間の相互認証とが、それぞれ実行され、EACは、第1サービスエンティティおよび第2サービスエンティティの一時識別情報をそれぞれ割り振り、第1サービスエンティティおよび第2サービスエンティティとの通信を保護する共有鍵材料をそれぞれ獲得し、第1サービスエンティティは、認証問合せの機構および派生鍵を生成する機構を含む認証モードをEACとネゴシエートし、上記方法は、第1サービスエンティティが、第2サービスエンティティによって提供されるサービスを要求する場合に、ネゴシエートされた認証モードに含まれる認証問合せの機構に従って、第1サービスエンティティおよび第2サービスエンティティの一時識別情報に従って第1サービスエンティティおよび第2サービスエンティティの権限を認証する段階と、ネゴシエートされた認証モードに含まれる派生鍵を生成する機構、第1サービスエンティティおよび第2サービスエンティティの一時識別情報、ならびに第1サービスエンティティとの通信を保護する共有鍵材料に従って、第1サービスエンティティと第2サービスエンティティとの間の通信を保護する共有される派生鍵を計算する段階とを有することを特徴とする方法を開示する。
【００１７】
本発明の実施形態は、サービスを要求する第1サービスエンティティと、サービスを提供する第2サービスエンティティと、EACとを具備するモバイルネットワークに基づくエンドツーエンド通信において認証するシステムであって、第1サービスエンティティは、認証に関係する少なくとも1つの機構を含む認証モードをEACとネゴシエートし、ネゴシエートされた認証モードに従って第1サービスエンティティとEACとの間で相互認証を実行し、第2サービスエンティティにサービスを要求し、ネゴシエートされた認証モードに従って、第1サービスエンティティと第2サービスエンティティとの間の通信を保護する共有される派生鍵に従って第1サービスエンティティと第2サービスエンティティとの間で相互認証を実行するように構成され、第2サービスエンティティは、ネゴシエートされた認証モードに従ってEACを認証し、第1サービスエンティティがサービスを要求する場合にネゴシエートされた認証モードに従って第1サービスエンティティと第2サービスエンティティとの間の通信を保護する共有される派生鍵に従って第2サービスエンティティと第1サービスエンティティとの間で相互認証を実行するように構成され、EACは、ネゴシエートされた認証モードに従って、EACと第1サービスエンティティとの間の相互認証と、EACと第2サービスエンティティとの間の相互認証とをそれぞれ実行し、第1サービスエンティティがサービスを要求する時に、ネゴシエートされた認証モードに従って第1サービスエンティティおよび第2サービスエンティティに関する認証問合せを提供し、第1サービスエンティティと第2サービスエンティティとの間の通信を保護する共有される派生鍵を生成するように構成されることを特徴とするシステムを開示する。
【００１８】
また、本発明の実施形態は、サービスエンティティおよびEACを具備する、サービスエンティティを認証するシステムであって、サービスエンティティは、サービスエンティティとEACとの間の認証機構を含む認証モードをEACとネゴシエートし、ネゴシエートされた認証モードに含まれる認証機構に従ってサービスエンティティとEACとの間で相互認証を実行するように構成されることを特徴とするシステムを開示する。
【００１９】
本発明の実施形態は、サービスを要求する第1サービスエンティティ、サービスを提供する第2サービスエンティティ、およびEACを具備する、認証問合せのシステムであって、第1サービスエンティティは、認証問合せの機構および派生鍵を生成する機構を含む認証モードをEACとネゴシエートするように構成され、EACは、第1サービスエンティティがサービスを要求する時に、ネゴシエートされた認証モードに含まれる認証問合せの機構に従って、第1サービスエンティティおよび第2サービスエンティティの権限を認証し、ネゴシエートされた認証モードに含まれる派生鍵を生成する機構に従って、第1サービスエンティティと第2サービスエンティティとの間の通信を保護する共有される派生鍵を生成するように構成されることを特徴とするシステムをさらに開示する。
【００２０】
本発明の実施形態は、認証センタであって、サービスエンティティの認証モードをネゴシエートするように構成された第1モジュールであって、認証モードは、サービスエンティティと認証センタとの間の認証機構を含む、第1モジュールと、第1モジュールによってネゴシエートされた認証モードに含まれる認証機構に従ってサービスエンティティを認証するように構成された第2モジュールとを具備することを特徴とする認証センタを開示する。
【００２１】
上記認証センタでは、第1モジュールは、サービスを要求するサービスエンティティおよびサービスを提供するサービスエンティティの認証機能をそれぞれ獲得するためにサブスクリプションデータを問い合わせるように構成された第1サブモジュールと、サービスを要求するサービスエンティティおよびサービスを提供するサービスエンティティの認証機能に従って認証モードを選択するように構成された第2サブモジュールであって、認証機能は、第1モジュールによって獲得される、第2サブモジュールとを具備することを特徴とする。
【００２２】
上記認証センタでは、認証モードは、認証問合せの機構および派生鍵を生成する機構をさらに含み、認証センタは、サービスエンティティがサービスを要求する時に、サービスを要求するサービスエンティティおよびサービスを提供するサービスエンティティに関する認証問合せを提供し、第1モジュールによってネゴシエートされた認証モードに含まれる認証問合せの機構および派生鍵を生成する機構に従って、2つのサービスエンティティの間の通信を保護する共有される派生鍵を計算するように構成された第3モジュールをさらに具備することを特徴とする。
【００２３】
上記認証センタでは、第2モジュールは、2つのサービスエンティティの共有鍵材料および一時識別情報を生成するように構成され、第3モジュールは、第2モジュールによって生成された2つのサービスエンティティの共有鍵材料および一時識別情報に従って共有される派生鍵を計算するように構成されることを特徴とする。
【発明の効果】
【００２４】
本発明の実施形態による技術的解決策によってもたらされる有益な効果は、真の包括的認証アーキテクチャが提供されることであり、ここで、GAAによって提供される認証機構は、複数の認証機構および認証モジュールに関するネゴシエーションおよび選択を実行することができ、これは、認証機構の柔軟性および一般性を高める。本発明の実施形態によるフレームワークでは、サービスプロバイダを、モバイルネットワーク内のアプリケーションサーバ、オープンネットワーク内のアプリケーションサーバ、または高度な機能を有するモバイル端末とすることができ、これは、サービス加入者がより豊富なサービスリソースを使用することを可能にする。この認証解決策は、モバイル端末が、サービスプロバイダになるためにアップグレードされる状況をサポートし、これは、高度な機能を有するモバイル端末がサービスを提供することを望むという需要を満足する。
【発明を実施するための最良の形態】
【００２５】
本発明の目的、技術的解決策、および利益をより明白にするために、本発明を、添付の図面および実施形態を参照して、以下でさらに詳細に説明する。
【００２６】
図3に、本発明の実施形態によるモバイルネットワークに基づくエンドツーエンド通信認証のアーキテクチャを示す。このアーキテクチャは、異なるモバイルネットワーク標準規格に適用可能であり、異なるタイプのサービスエンティティの間で相互信頼関係を確立するように働くという点で、実際に包括的認証アーキテクチャと呼ぶことができる。2つのサービスエンティティすなわちサービス加入者(SS)301およびサービスプロバイダ(SP)302のほかに、この包括的認証アーキテクチャに用いられるネットワーク要素は、さらに、オペレータのネットワーク内のエンティティ認証センタ(EAC)303およびエンティティサブスクリプションデータベース(ESD)304を含む。このアーキテクチャでは、SSおよびSPは、互いに通信することができ、SSおよびSPは、それぞれ、それ自体の認証を実行するためにEACと通信することができ、EACは、ESDに接続することができ、そこから認証に必要な情報を獲得することができる。本発明の実施形態では、サービスエンティティは、サービス加入者(SS)またはサービスプロバイダ(SP)とすることができる。SSは、3GPP GAAの加入者または3GPP2 GAAのMNと同等とすることができ、SPは、3GPP GAAまたは3GPP2 GAAのNAFとして振る舞うことができ、EACは、3GPP GAAまたは3GPP2 GAAのBSFと同等とすることができる。
【００２７】
サービスをモバイル加入者に提供する時に、アプリケーションサーバの大多数は、まず、相互信頼関係をモバイル加入者と確立する(たとえば、モバイル加入者と認証プロキシとの間、モバイル加入者とPKI証明機関との間、モバイル加入者とコンテンツ提供サーバとの間など)。一般に、そのような信頼関係は、モバイル加入者とアプリケーションサーバとの間の双方向認証手順中に確立される。モバイルネットワークの開発と共に、サービスのタイプが、ますます多様化する。その一方で、SPは、純オペレータネットワークに制限されるのではなく、オペレータネットワーク以外のサードパーティSPまたはモバイル加入者とすることすらできる。すなわち、一部のモバイル加入者は、ネットワークによって提供されるアプリケーションサービスを使用できるだけではなく、あるサービスをネットワーク内の他の加入者に提供することもできる。本発明の実施形態には、オペレータネットワークのAS、サードパーティAS、およびモバイル加入者を含む3タイプのSPがある。また、一般的なモバイル加入者またはサードパーティASを含む2タイプのSSがある。したがって、モバイル加入者は、SSならびにSPであることができ、サードパーティASは、SPおよびSSであることができる。したがって、加入者およびSPへのサービスエンティティの分類と比較して、本発明の実施形態でのサービスエンティティは、3つのタイプすなわち、1. SSすなわちサービスを求めることだけができる単純なサービス加入者(一般に、一般のモバイル加入者)、2. SPすなわち単純なサービスプロバイダ(オペレータネットワークのASまたは外部ネットワークのSP)、3. サービス加入者であるだけではなくサービスプロバイダでもあるサービス加入者兼プロバイダ(SSPとも称する)(一般のモバイル加入者またはサードパーティASとすることができる)に分類される。
【００２８】
図3に示されたアーキテクチャでは、EACが、認証方法のネゴシエーションおよびサービスエンティティの認証と、エンドツーエンド通信エンティティの識別情報およびサービスを要求するか提供するエンティティの妥当性の検証と、派生鍵(derived key)の生成などに使用される。ESDは、エンティティによってサブスクライブされかつ/または提供されるサービスのタイプ、エンティティによってサポートされる認証機構、および認証情報などを含む、エンティティのサブスクリプション情報を格納する。エンティティのサブスクリプション情報は、そのエンティティのプライベートIDと一緒に格納される。SPが他のエンティティにサービスを提供するか、SSが他のエンティティのサービスを要求する前に、SPとネットワークとの間またはSSとネットワークとの間のサブスクリプション関係が、存在しなければならず、ESDに格納されなければならない。
【００２９】
本発明の実施形態によって提供される認証手順は、次のステージを含む。
【００３０】
第1ステージ(エンティティ認証プロセスと称する):サービスエンティティは、ネットワーク内の各SSがSPと通信する前に、まず、EACに行って、認証機構をネゴシエートし、サービスエンティティの識別情報を認証しなければならない。
【００３１】
認証機構をネゴシエートするプロセスは、サービスエンティティによって開始され、サービスエンティティの識別情報およびサービスのセキュリティ度合要件が、ネゴシエーションを開始するために要求メッセージ内で伝えられる。EACは、セキュリティ度合、ネットワークサポート条件(たとえば、ネットワークがサポートした認証モード)、およびエンティティサブスクリプション情報に従って認証機構を選択し、認証リクエスタとして振る舞うサービスエンティティに対応する情報を返す。サービスの異なるセキュリティ度合は、異なる認証モードが選択されることにつながる。認証リクエスタは、ネゴシエーション手順の終りを示すために確認メッセージを発行する。
【００３２】
サービスエンティティおよびEACは、ネゴシエートされた機構に従って、それらの間で相互認証を実行する。この認証は、双方向である。認証の後に、認証リクエスタ(すなわち、認証を要求するサービスエンティティ)およびEACは、共有鍵材料を生成し、EACは、認証リクエスタに、そのサブスクリプション情報に従って一時IDおよび対応する寿命を割り振る。認証リクエスタがSSである場合には、EACは、ISR-ID(Interim Service Request Identifier)を認証リクエスタに割り振り、認証リクエスタがSPである場合には、EACは、IAC-ID(Interim Authentication Check Identifier)を認証リクエスタに割り振る。EACは、サービスエンティティの一時IDおよび寿命を、認証を要求するサービスエンティティに転送する。この後に、認証を要求するサービスエンティティとEACとの間の通信を、そのサービスエンティティとEACとの間の認証手順で生成された共有鍵材料を使用することによって保護することができる。
【００３３】
第2ステージ(認証問合せプロセスと称する):EACとの認証を実行した後に、SSは、SPにサービスを要求することができる。
【００３４】
サービス要求を受信した時に、SPまたはSSPがEACとの認証を実行し、有効なIAC-IDを獲得済みであるならば、SPまたはSSPは、SSの認証条件についてEACに問い合わせることができる。そうでない場合には、SPまたはSSPは、まずEACと通信して認証および鍵ネゴシエーションを実行しなければならず、その後、SSのISR-IDおよびSPまたはSSPのIAC-IDを伝える問合せ要求を送信することによって、SSの認証条件についてEACに問い合わせなければならない。問合せ要求を受信した時に、EACは、まず、SSおよびSPがSSのIDおよびSPのIDに従って権限を有するかどうかを問い合わせ、次に、SSおよびSPの一時IDとSS/SPによってEACとネゴシエートされたKsとを使用することによってSSとSPとの間のサービス通信を保護する派生鍵を計算し、その派生鍵をSPに転送する。その間に、SSは、同一のパラメータおよびアルゴリズムに従って派生鍵を計算する。サービスエンティティとEACとの間で確立される信頼関係は、寿命を有する。この寿命が、満了しようとしているかまたは満了済みである場合には、サービスエンティティは、新しい信頼関係を確立するために、EACとの再認証手順を必要とする。
【００３５】
第3ステージ(サービスエンティティ間の相互認証プロセスと称する):共有される派生鍵を獲得した後に、SSおよびSPは、その派生鍵を使用して、各サービス通信の前にこの2つの当事者間で相互認証を実行し、通信のセキュリティを保護するためのセッション鍵Kr-SS-SPをさらに生成し、その後、そのセッション鍵を使用してサービス通信を保護することができる。
【００３６】
本発明の実施形態によって提供される認証手順の各ステージを、これより、添付の図面を参照して詳細に説明する。
【００３７】
図4は、本発明による実施形態での、サービスエンティティとEACとの間で認証機構をネゴシエートし、相互認証を実行するプロセスを示す流れ図である。この実施形態では、サービスエンティティとEACとの間で認証機構をネゴシエートし、相互認証を実行するプロセスは、図4に示されているようにサービスエンティティによって開始され、次のステップを含む。
【００３８】
ブロック401:サービスエンティティは、要求されたサービスまたは提供されるサービス(たとえば、ビデオ会議サービス)に対応する認証機構のセキュリティ度合要件(たとえば、高セキュリティ度合)を自動的に選択する。
【００３９】
ブロック402:サービスエンティティが、サービスエンティティのID、サービスエンティティによって選択された認証機構のセキュリティ度合などの関連情報を伝える認証要求をEACに転送する。
【００４０】
ブロック403:認証要求を受信した時に、EACは、ローカルに格納されたセキュリティ度合リストを検索して、ネットワークによって現在サポートされ、認証プロトコルおよび暗号化アルゴリズムを含むセキュリティ度合要件を満足する少なくとも1つの認証機構を見つける。たとえば、Http AKAは、ネットワークと無線ネットワーク内の端末との間の相互認証プロトコルである。このプロトコルを実行することによって、2つの通信当事者は、互いの識別情報を認証し、同一の鍵をそれぞれ生成することができる。
【００４１】
ブロック404:サービスエンティティの識別情報に従って、EACは、ESDに格納されたサブスクリプション情報を問い合わせ、サービスエンティティの認証情報、たとえば、認証プロトコル、暗号化アルゴリズム、および他の関連パラメータを含む、サービスエンティティによってサポートされる認証機構を得る。
【００４２】
ブロック405:ESDは、サービスエンティティの認証機能情報(たとえば、サポートされる認証プロトコル、暗号化アルゴリズムなど)および他の関連パラメータをEACに返す。
【００４３】
ブロック406:EACは、ローカルポリシに従って、サービスエンティティおよびネットワークによってサポートされる認証プロトコルおよび暗号化アルゴリズムを照合し、やはりセキュリティ度合要件に従って、両方の側によってサポートされる認証プロトコルおよび暗号化アルゴリズム(すなわち、認証機構)を判定する。セキュリティ度合要件にも従う、両方の側によってサポートされる認証プロトコルおよび暗号化アルゴリズムがない場合には、EACは、エラー表示をサービスエンティティに返し、現在の手順を打ち切る。
【００４４】
ブロック407:EACは、認証プロトコルおよび暗号化アルゴリズムを含む選択された認証機構をサービスエンティティに返す。
【００４５】
ブロック408:EACによって返された情報を受信した時に、サービスエンティティは、認証機構を判断し、確認応答をEACに返す。
【００４６】
ブロック409:サービスエンティティおよびEACは、選択された認証プロトコルおよび暗号化アルゴリズムを使用して、相互認証を実行する。成功の認証の後に、両方の当事者は、共有鍵材料(共有される秘密情報とも称する)を獲得する。
【００４７】
サービスエンティティがモバイル端末である場合には、共有鍵材料を、共有鍵(Ks)とすることができる。サービスエンティティがモバイルコアネットワークドメイン内のアプリケーションサーバ(AS)である場合には、サービスエンティティとEACとの間の相互認証手順でネゴシエートされる共有鍵材料を、SA(Security Association)すなわち、インターネットプロトコルセキュリティ(IPSec)に従ってネゴシエートされるセキュリティ通信の鍵および鍵アルゴリズム情報とすることができる。
【００４８】
ブロック410:EACは、認証成功応答をサービスエンティティに返し、サービスエンティティの一時IDおよび対応する寿命を割り振るが、これには、次の状況が含まれる:1) 認証要求をEACに発行するサービスエンティティがサービス加入者(SS/SSP)である場合に、EACは、SS/SSPが他のエンティティにサービスを要求する場合に使用されるISR-IDをSS/SSPに割り振り、2) 認証要求をEACに発行するサービスエンティティがサービスプロバイダ(SP/SSP)である場合に、EACは、SS/SSPがSSの認証条件についてEACに問い合わせる必要がある場合に使用されるIAC-IDをSS/SSPに割り振る。
【００４９】
ブロック411:EACおよびサービスエンティティは、それぞれ、対応するセキュリティ度合に関連する共有鍵材料を格納するが、これは、ISR-ID/IAC-ID、鍵材料、認証機構、およびセキュリティ度合を関連付け、かつ格納することを含む。
【００５０】
図5は、本発明による実施形態での、サービスエンティティとEACとの間での認証問合せ手順を示す流れ図である。この実施形態では、相互認証を実行した後に、サービスエンティティおよびEACは、認証問合せ手順を実行するが、その詳細な説明が、図5に示されている。
【００５１】
ブロック501:SS(またはSSP)が、EACとの認証でSSによって獲得されたISR-IDおよび他のサービスエンティティと連絡するためのIDであるSPのパブリック識別情報(UID)を含むサービス要求を、サービスを提供できるSP(または別のSSP)に発行する。
【００５２】
同一のサービスエンティティによって提供される異なるサービスは、異なるUIDに対応し、したがって、異なるサービスを、それら自体のUIDによって区別することができる。
【００５３】
ブロック502:サービス要求を受信した時に、SPは、SSを識別するために、ローカルに格納されたSSのISR-IDがあるかどうかを検索する。ISR-ID、それに関連する有効な派生鍵、サービスエンティティの実際の識別情報などが格納されている場合には、SSおよびSPは、その派生鍵を使用して、それらの間でサービスを保護する。派生鍵またはISR-ID情報がハイポオペレーション(hypo-operation)状態であるか、撤回されたか破壊されていることがわかった場合には、SPは、再認証要求を開始しなければならないことをSSに通知し、現在の手順は打ち切られ、再認証を開始する詳細な手順には、後続のテキストで言及する。ISR-IDが格納されていない場合には、SPは、認証問合せ要求をEACに送信し、SSのISR-IDならびにSPのIAC-IDおよびUIDをその認証問合せ要求で伝え、ブロック503を実行する。
【００５４】
ブロック503:認証問合せ要求を受信した時に、EACは、まず、その認証問合せ要求で伝えられるIAC-IDが有効であるかどうか、およびSPがサービスを提供する資格を与えられているかどうかを問い合わせ、判断し、その認証問合せ要求で伝えられるISR-IDが有効であるかどうか、およびSSがサービスを要求する資格を与えられているかどうかを問い合わせ、判断する。ISR-IDが有効であり、SSがサービスを要求する資格を与えられていることのほかに、IAC-IDが有効であり、SPがサービスを提供する資格を与えられていると判断される(すなわち、認証に合格する)場合に、EACは、SSおよびSPの派生鍵を生成する。
【００５５】
ブロック504:EACは、ブロック503で生成された派生鍵およびその鍵の寿命を伝える認証問合せ応答をSPに返す。ブロック503の認証問合せが成功である(すなわち、問合せおよび判断の結果が肯定である)場合には、SPおよびEACの共有鍵材料を暗号化することによって獲得される新しい派生鍵が、返される認証問合せ応答で伝えられる。そうでない場合には、EACは、エラーメッセージを返し、対応するサービスエンティティにEACでの再認証について通知し(この再認証の詳細は後続テキストで言及する)、現在の手順を打ち切る。
【００５６】
ブロック505:SPは、暗号化解除することによって認証問合せ応答から新たに生成された派生鍵を獲得し、派生鍵、寿命、SSのISR-ID、およびSPのUIDを関連付け、これらをローカルに格納する。
【００５７】
ブロック506:SPは、サービス要求応答をSSに返す。
【００５８】
ブロック507:SSは、同一のパラメータおよび鍵アルゴリズムを使用することによって同一の派生鍵を計算し、この鍵アルゴリズムは、DES(Data Encryption Standard)、3-DES(ternary DES)、AES(Advanced Enciphering Standard) 256、AES 1024(256と1024との両方が鍵長を表す)などを採用することができる。
【００５９】
ブロック508:SSおよびSPは、派生鍵を使用して、それらの間でサービスを保護する。
【００６０】
認証によってサービスエンティティとEACとの間で確立された信頼関係は、寿命(共有鍵材料、派生鍵、および一時IDの寿命など)を有するので、寿命が満了しようとしているか満了済みである場合には、サービスエンティティは、新しい信頼関係を確立するために、EACとの間での再認証のためにEACに接続する必要がある。
【００６１】
さらに、共有鍵材料または一時IDの異なる条件に従って、サービスエンティティは、次の状態を有する場合がある:1. ハイポオペレーション状態:共有鍵材料、派生鍵の寿命、または一時IDが、満了しようとしており、したがって、共有鍵材料を、暗号化計算に使用することはできないが、エンティティIDの暗号化解除および認証に使用することはできる。2. 撤回状態:共有鍵材料、派生鍵の寿命、または一時IDが、満了しており、共有鍵材料とエンティティの実際のIDとの間の対応する関係または一時IDとエンティティの実際のIDとの間の対応する関係が、除去されている。3. 破壊状態:共有鍵材料、派生鍵、または一時IDの関連レコードが削除されている。したがって、次の状況のうちの少なくとも1つが発生する場合に、再認証手順を開始する必要がある。
【００６２】
1. ローカルポリシに従って、サービスエンティティおよびEACの共有鍵材料またはサービスエンティティの一時IDがハイポオペレーション状態であることを見つけた場合に、EACは、再認証要求を開始しなければならないことをサービスエンティティに通知する。
【００６３】
2. ローカルポリシに従って、共有鍵または一時IDが撤回状態または破壊状態であることを見つけた場合に、EACは、再認証要求を開始しなければならないことをサービスエンティティに通知する。
【００６４】
3. EACが、一時IDに従って関連する識別情報および鍵情報を見つけることができない(すなわち、破壊状態である)場合に、EACは、再認証要求を開始しなければならないことをサービスエンティティに通知する。
【００６５】
4. ローカルポリシに従って、派生鍵がハイポオペレーション状態であることを見つけた場合に、SPは、再認証要求を開始しなければならないことをSSに通知する。
【００６６】
5. ローカルポリシに従って、派生鍵が撤回状態または破壊状態であることを見つけた場合に、SPは、再認証要求を開始しなければならないことをSSに通知する。
【００６７】
6. SPが、一時IDに従って、対応する識別情報および鍵情報を見つけることができない(すなわち、破壊状態である)場合に、SPは、再認証要求を開始しなければならないことをSSに通知する。
【００６８】
EACが、再認証要求を開始しなければならないことをサービスエンティティに通知する時に、その再認証の理由は、通知内で識別される。再認証の理由が、共有鍵材料または一時IDがハイポオペレーション状態であることである場合には、サービスエンティティは、開始される再認証要求でそれ自体を識別するのに、一時IDを使用する。その再認証要求を受信した時に、EACは、一時IDに従って、認証機構をネゴシエートする必要がないと判断し、したがって、相互認証を実行するのに、最初に使用された認証機構を採用する。再認証の理由が、共有鍵材料または一時IDが撤回状態または破壊状態であることである場合、または鍵材料を必要な時に一時IDに従って見つけることができないことである場合には、サービスエンティティは、開始される再認証要求でそれ自体を識別するのに、プライベートIDを使用する。その再認証要求を受信した時に、EACは、プライベートIDに従って、認証機構をネゴシエートする必要があると判断し、ここで、認証機構を再ネゴシエートする手順は、図4に示された最初の認証手順と同一である。
【００６９】
同様に、SPが、再認証要求を開始しなければならないことをSSに通知する時に、再認証の理由が、やはり通知内で識別されなければならない。再認証の理由が、一時IDがハイポオペレーション状態であることである場合には、SSは、開始される再認証要求でそれ自体を識別するのに、一時IDを使用する。この再認証要求を受信した時に、EACは、一時IDに従って、認証機構をネゴシエートする必要がないと判断し、したがって、相互認証を実行するのに、最初に使用された認証機構を採用する。再認証の理由が、一時IDが撤回状態または破壊状態であることである場合には、SSは、開始される再認証要求でそれ自体を識別するのに、プライベートIDを使用する。その再認証要求を受信した時に、EACは、プライベートIDに従って、認証機構をネゴシエートする必要があると判断し、ここで、認証機構を再ネゴシエートする手順は、図4に示された最初の認証手順と同一である。
【００７０】
一時ID(すなわち、ISR-ID/IAC-ID)またはそれに関連する共有鍵材料(すなわち、Ks/Kp)を使用する場合に、サービスエンティティ(SSまたはSP)またはEACは、一時IDまたは共有鍵材料がハイポオペレーション状態、撤回状態、または破壊状態であるかどうかを検証しなければならない。一時IDまたは共有鍵材料がハイポオペレーション状態、撤回状態、または破壊状態である場合には、サービスエンティティまたはEACは、対応するサービスエンティティとEACとの間で再認証手順を開始しなければならない。認証手順で、障害の理由を示すメッセージを受信する場合に、サービスエンティティまたはEACは、再認証手順を開始することもできる。さらに、SPが、SSと共有される派生鍵がハイポオペレーション状態、撤回状態、または破壊状態であることを見つけた場合に、SPは、SSに再認証要求を送信し、その要求内で再認証理由を示す。また、SSおよびSPの一時IDが正常状態である間に、共有される派生鍵だけがハイポオペレーション状態、撤回状態、または破壊状態である場合には、SSおよびSPは、EACとの最初のエンティティ認証を実行する必要はなく、SSは、EACがSP用の新しい共有される派生鍵を生成するようにするために、EACへの認証問合せ手順を開始しなければならず、SSは、同一の共有される派生鍵をそれ自体で生成する。
【００７１】
ここに、寿命およびハイポオペレーション状態の例がある。共有鍵材料の寿命を例にとり、共有鍵材料の寿命が48時間であり、44時間から48時間までの期間内に、共有鍵材料がハイポオペレーション状態であると仮定すると、共有鍵材料が45時間にわたって生存した場合に、この共有鍵材料がそのライフサイクルのハイポオペレーション状態にあると判断することができる。
【００７２】
エンティティ認証センタ(EAC)が、Kerberosサーバの機能を有する場合には、Kerberosモデルと組み合わされた認証問合せの機構を使用することができる。図6は、Kerberosモデルと組み合わされたエンドツーエンド認証モデルを示す概略図である。図6に示されているように、SSは、サービス許可チケットSGT(service granted ticket)をEACに要求し、SSのISR-IDおよびUIDをEACに供給する。EACは、ISR-IDおよびIAC-IDの妥当性をチェックし、サービス許可チケットを生成し、このサービス許可チケットをSSに返す。サービス要求をSPに発行する時に、SSは、要求内でサービス許可チケットを伝える。SPは、サービス許可チケットに従って派生鍵を生成し、その後、SSにサービス応答を返す。
【００７３】
図7は、図6に示された、Kerberosモデルと組み合わされた認証問合せのプロセスを示す概略図である。図7に示されているように、詳細なステップは、次の通りである。
【００７４】
ブロック701:あるサービスを獲得することを望む時に、SSは、まず、そのサービスに対応するサービス許可チケットがローカルに格納されているかどうかを検索する。格納されている場合には、ブロック705に進む。格納されていない場合には、SSは、SSのISR-IDおよびそのサービスを提供するSPのUIDを伝えるサービス許可チケット要求をEACに転送する。
【００７５】
ブロック702:サービス許可チケット要求を受信した時に、EACは、識別情報の妥当性および権限をチェックする。まず、EACは、要求内で伝えられたISR-IDが有効であるかどうかを問い合わせることによって、SSがそのサービスを使用する資格を与えられているかどうかを判断し、次に、要求内で伝えられたSPのUIDに従ってSPのIAC-IDを獲得し、IAC-IDが有効であるかどうかを判断することによって、SPがそのサービスを提供する資格を与えられているかどうかを判断する。
【００７６】
上記の判断が、SPがそのサービスを提供する資格を与えられている(すなわち、SPが正当である)ことを示す場合には、EACは、SSおよびSPの識別情報とSSおよびEACの共有鍵材料とに従って、SSとSPとの間のサービス通信を保護するための派生鍵K-SSP/SPを計算する。EACは、さらに、その派生鍵とSSおよびSPの識別情報とを含むサービス許可チケットを生成し、それ自体およびSPの共有鍵材料を使用して、そのSGTを暗号化する。
【００７７】
上記の判断が、SPがそのサービスを提供する資格を与えられていない(すなわち、SPが不正である)ことを示す場合には、EACは、エラーメッセージを転送し、EACでその識別情報を認証することについて、対応するエンティティに通知し、現在の手順を打ち切る。
【００７８】
ブロック703:EACは、上記で暗号化されたSGTをSSに転送する。
【００７９】
ブロック704:SGTを受信した時に、SSは、EACによって使用されたものと同一のパラメータおよびアルゴリズムを採用することによって、EACが生成したものと同一の派生鍵をローカルに生成する。
【００８０】
ブロック705:SSは、SGTを伝えるサービス要求をSPに転送する。
【００８１】
ブロック706:SPは、SGTを暗号化解除して、派生鍵を獲得する。
【００８２】
ブロック707:SPは、成功を識別するサービス要求応答をSSに返す。
【００８３】
ブロック708:SSおよびSPは、派生鍵を使用して、それらの間でサービスを保護する。
【００８４】
上記のブロック以外に、EACは、それ自体およびSSの共有鍵材料を使用して、派生鍵を暗号化し、暗号化された派生鍵をSSに転送することができる。したがって、SSは、ローカルに再計算するのではなく暗号化解除によって派生鍵を獲得することができる。
【００８５】
同様に、共有される派生鍵を獲得した後に、SSおよびSPは、その派生鍵を使用して、各サービス通信が始まる前にこの2つの当事者の間で相互認証を実行することができ、さらに、その通信のセキュリティを保護するセッション鍵Kr-SS-SPを生成し、その後、このセッション鍵を使用してサービス通信を保護することができる。
【００８６】
EACが、仲裁者として働くTTP(Trusted Third Party)の機能を有する場合には、Mediationモデルと組み合わされた認証問合せの機構を採用することもできる。図8は、Mediationモデルと組み合わされたエンドツーエンド認証モデルを示す概略図である。図8に示されているように、SSは、SPによって提供されるサービスを要求するために、サービス要求をEACに発行する。EACは、SSが正当であると判断した後に、このサービス要求をSPに転送する。SPは、それ自体のIAC-IDを伝えるサービス要求応答をEACに返す。EACは、IAC-IDに従ってSPの妥当性を判断する。SPが正当である場合には、EACは、SSとSPとの間の派生鍵を計算し、その派生鍵をSPに転送し、それと同時にサービス要求応答をSSに返す。SSは、この応答を受信した時に同一の派生鍵を計算する。
【００８７】
図9は、Mediationモデルと組み合わされた認証問合せのプロセスを示す流れ図である。図9に示されているように、詳細なブロックは、次の通りである。
【００８８】
ブロック901:SPによって提供されるサービスを使用することを望む場合に、SSは、まず、SSのISR-IDおよびSPのUIDを伝えるサービス要求をEACに発行する。
【００８９】
ブロック902:EACは、SSのISR-IDおよびSSのサブスクリプション情報の妥当性を判断して、SSがサービスを要求する資格を与えられているかどうかを判断する。
【００９０】
ブロック903:SSが正当である場合には、EACは、サービス要求をSPに転送し、ブロック904を実行する。SSが不正である場合には、EACは、エラーメッセージをSSに転送して、SSに、EACでのその識別情報の認証について通知し、現在の手順を打ち切る。
【００９１】
ブロック904:SPは、それ自体のIAC-IDを伝えるサービス要求応答を返す。
【００９２】
ブロック905:EACは、IAC-IDおよびSPのサブスクリプション情報の妥当性を検証して、SPがサービスを提供する資格を与えられているかどうかを判断する。SPが正当である場合には、EACは、SSおよびSPの識別情報ならびにSSおよびEACの共有鍵材料に従ってSSとSPとの間のサービス通信を保護する派生鍵を計算し、ブロック906を実行する。SPが不正である場合には、EACは、エラーメッセージをSPに転送して、SPに、EACでのそのIDの認証について通知し、現在の手順を打ち切る。
【００９３】
ブロック906:EACは、サービス要求成功応答をSSに転送し、EACおよびSPの共有鍵材料によって暗号化された派生鍵をSPに転送する。
【００９４】
ブロック907:EACによって転送されたサービス要求成功応答を受信した時に、SSは、EACによって使用されたものと同一のパラメータおよびアルゴリズムを採用して、派生鍵を獲得する。
【００９５】
ブロック908:SSおよびSPは、派生鍵を使用して、それらの間でサービスを保護する。
【００９６】
同様に、共有される派生鍵を獲得した後に、SSおよびSPは、各サービス通信が始まる前に、その派生鍵を使用して、この2つの当事者の間で相互認証を実行することができ、さらに、その通信のセキュリティを保護するセッション鍵Kr-SS-SPを生成し、その後、このセッション鍵を使用してサービス通信を保護することができる。
【００９７】
先の記載は、本発明の実施形態を例示するに過ぎない。サービスエンティティとして働くSSPなど、他の類似する状況で、SSPの形を変更することができる。SSPがサービスを要求する場合には、その処理の形は、上記のSSの処理の形と同一であるが、SSPがサービスを提供する場合には、その処理の形は、SPの処理の形と同一である。したがって、本発明の実施形態の範囲内で考えられ、当業者によって作られる一般的な変形形態および置換は、本発明の保護の範囲に含まれなければならない。
【００９８】
本発明による実施形態の認証方法の第1ステージおよび第2ステージの認証手順の実施形態を、以下で説明する。
【００９９】
図10は、本発明による実施形態でのサービスエンティティを認証する方法を示す流れ図である。図10を参照すると、本発明による認証方法の説明は、次の通りである。
【０１００】
ブロック1001:サービスエンティティは、そのサービスエンティティの識別情報、セキュリティ度合情報、そのサービスエンティティによよってサポートされる少なくとも1つの認証機構の情報(サービスエンティティによってサポートされる少なくとも1つの認証機構の情報が、ネットワークのサブスクリプション情報内に格納される場合には、認証機構の情報を伝えないものとすることができる)などを伝える認証要求をEACに転送する。
【０１０１】
識別情報には、プライベートID(PID)またはUIDを含めることができる。セキュリティ度合の選択に関して、次の状況を考慮することができる。1) サービスエンティティは、ローカルに格納されたサービスセキュリティ度合リストを検索することによって、所望のサービスに対応するセキュリティ度合を選択することができる。2) サービスエンティティが、セキュリティ度合リストをローカルに格納しない場合には、セキュリティ度合を、ヒューマン-コンピュータインターフェースを介して加入者が手動で選択することができる。3) サービスエンティティは、セキュリティ度合を選択せずに、対応するサービスを提供するSPのUIDだけをEACに供給することができ、ここで、そのUIDが、SPによって提供されるサービスのタイプを識別することができる。次に、EACは、サービスのタイプに従ってセキュリティ度合リストを検索し、これによって、対応するセキュリティ度合を選択することができる。
【０１０２】
ブロック1002:認証要求を受信した時に、EACは、要求内のIDに従ってESDに格納されたサブスクリプション情報を検索し、サービスエンティティおよびネットワークによってサポートされる認証機構とセキュリティ度合とを考慮して、ローカルポリシに従って認証機構を選択する。この実施形態で選択される認証機構を、認証機構bとして識別する。サポートされる認証機構には、AKA、SIM、CAVE、MN-AAA key、TLS-PSKまたはTLS-Cert、DHなどを含めることができる。
【０１０３】
ネットワークおよびサービスエンティティが、1つの認証機構だけをサポートするときには、2つの当事者は、ネゴシエーションなしで、相互認証を実行するためにその認証機構を採用することができる。セキュリティ度合を選択する時に、EACは、サービスのセキュリティ度合要件を考慮してもしなくてもよい、すなわち、条件としてのセキュリティ度合は、認証ネゴシエーション手順について任意選択である。
【０１０４】
ブロック1003:EACは、ブロック1002で選択された認証機構の識別子、セキュリティ度合(セキュリティ度合がブロック1002のネゴシエーション手順で考慮される場合には、セキュリティ度合は、サービスエンティティによって選択されたセキュリティ度合未満であってはならない)などを伝える認証初期化メッセージをサービスエンティティに転送する。
【０１０５】
フォローアップ認証対話手順がEACによって開始される場合に、認証初期化メッセージは、認証機構上で命じられる、この手順の最初の認証メッセージによって伝えられる情報を含まなければならない。第1認証メッセージの内容は、AKA認証に関して、認証ベクトルであり、TSL認証の形に関して、その内容は、Hello Requestである。
【０１０６】
ブロック1004:サービスエンティティは、認証機構を入手する。フォローアップ認証がサービスエンティティによって開始される場合には、サービスエンティティは、認証情報を計算するが、フォローアップ認証がEACによって開始される場合には、サービスエンティティは、関連する認証情報を受信した後に応答値を計算する。
【０１０７】
ブロック1005:選択された認証機構に基づく認証対話手順が、サービスエンティティとEACとの間で実行される。
【０１０８】
ブロック1006:認証の後に、サービスエンティティとEACとの両方が、共有鍵材料を入手し、EACは、サービスエンティティにISR-IDまたはIAC-IDを割り振り、このISR-IDまたはIAC-IDは、共有鍵材料に関連して格納され、共有鍵材料またはセキュリティ接続のSession IDを検索するためのインデックスとして働くことができる。
【０１０９】
図11は、本発明による実施形態で3GPP無線ネットワークのサービスエンティティを認証する方法を示す流れ図である。図11を参照すると、この実施形態では、サービスエンティティがSSである。SSが3GPPネットワーク内のモバイル端末すなわち図11のUEであり、AKA認証だけをサポートする場合に、認証手順は、次の通りである。
【０１１０】
ブロック1101:UEが、それ自体のIDを伝えるHTTPダイジェスト認証要求をEACに発行する。
【０１１１】
ブロック1102:3GPPネットワークおよびUEは、AKA機構だけをサポートするので、この2つの当事者は、認証機構をネゴシエートせずに、認証にAKA機構を直接に採用する。EACは、ESDから、UE加入者の認証ベクトル(RAND、AUTN、RES、CK、IK)を入手する。
【０１１２】
ブロック1103:EACは、認証ベクトル内でRANDおよびAUTNを伝えるHTTP 401メッセージ(ダイジェストAKAチャレンジを含む)をUEに転送する。
【０１１３】
ブロック1104:UEは、AUTNを計算し、AUTNの妥当性を検証して、ダイジェストAKAチャレンジを含むメッセージが許可されたネットワークから来たものであるかどうかを確認し、CK、IK、およびRESを計算する。
【０１１４】
ブロック1105:UEは、ダイジェストAKA応答および計算されたRESによって計算されたアブストラクト値を含むHTTP要求メッセージをEACに転送する。
【０１１５】
ブロック1106:EACは、計算されたアブストラクト値の正確さを検証して、UEの妥当性を認証する。
【０１１６】
ブロック1107:EACは、鍵材料Ks=CK‖IKおよびISR-IDを生成するが、その生成方法およびフォーマットは、3GPP包括的認証アーキテクチャのB-TIDの生成方法およびフォーマットと同一である。
【０１１７】
ブロック1108:EACは、200 OKメッセージをUEに転送して、認証の成功の終了を識別し、このメッセージは、Ksによって暗号化されるが、鍵材料の寿命およびISR-IDを含む。
【０１１８】
ブロック1109:UEも、同一の鍵材料Ks=CK‖IKを生成し、暗号化解除によってISR-IDおよび鍵材料の寿命を獲得し、ISR-IDおよび鍵材料の寿命をローカルに格納し、これらを認証機構に関連付ける。
【０１１９】
図12は、本発明による実施形態での3GPP2無線ネットワークでサービスエンティティを認証する方法を示す流れ図である。この実施形態では、サービスエンティティがSSである。SSが、UEであり、AKA認証、証明書認証などの認証方法をサポートするが、3GPP2ネットワークが、AKA認証、CAVEベースの認証機構、およびMN-AAAベースの認証機構をサポートする場合には、認証手順は、図12を参照すると、次の通りである。
【０１２０】
ブロック1201:UEは、UEの識別情報と、AKA認証および証明書認証など、UEがサポートする認証モードとを伝えるHTTP認証要求をEACに発行する。
【０１２１】
ブロック1202:EACは、ESD内で、UEの識別情報に従ってUEのサブスクリプション情報を検索し、AKA認証、CAVEベースの認証機構、MN-AAAベースの認証機構など、自己がサポートする認証機構タイプに従ってローカルポリシを採用することによって、2つの当事者が認証を実行するためにAKA機構を使用すると判断する。EACは、ESDからUE加入者の認証ベクトル(RAND、AUTN、RES、CK、IK)を獲得する。
【０１２２】
ブロック1203:EACは、RANDおよびAUTNを伝えるHTTP 401メッセージ(ダイジェストAKAチャレンジを含む)をUEに転送し、このメッセージのペイロード情報内に認証機構識別子を置く。
【０１２３】
ブロック1204:UEは、AUTNを計算し、AUTNの正確さを検証して、チャレンジを含むメッセージが許可されたネットワークから来たものであるかどうかを確認し、CK、IK、およびRESを計算する。
【０１２４】
ブロック1205:UEは、ダイジェストAKA応答およびRESによって計算されたアブストラクト値を含むHTTP要求メッセージをEACに送信する。
【０１２５】
ブロック1206:EACは、アブストラクト値の正確さを検証して、UEの妥当性を認証する。
【０１２６】
ブロック1207:EACは、鍵材料Ks=CK‖IKおよびISR-IDを生成するが、その生成方法およびフォーマットは、3GPP2包括的認証アーキテクチャのB-TIDの生成方法およびフォーマットと同一である。
【０１２７】
ブロック1208:EACは、200 OKメッセージをUEに送信して、認証の成功の終了を識別し、このメッセージは、Ksによって暗号化され、ISR-IDおよび鍵材料の寿命を含む。
【０１２８】
ブロック1209:UEも、同一のKs=CK‖IKを生成し、暗号化解除によってISR-IDおよび鍵材料の寿命を獲得し、ISR-IDおよび鍵材料の寿命を認証機構に関連付け、これらをローカルに格納する。
【０１２９】
認証要求を受信した後に、UEがCAVEベースの認証機構をもサポートする場合には、EACは、それ自体の識別情報に従ってサブスクリプション情報を検索し、最終的に、それがサポートする認証モードのタイプを考慮してローカルポリシを採用することによって、CAVEベースの認証機構を使用しなければならないと判断し、フォローアップ認証手順は、3GPP2包括的認証アーキテクチャのCAVEベースの認証手順と同一である。AAA認証機構を使用しなければならないと判断される場合には、本発明の実施形態の包括的認証アーキテクチャを、同一の原理に従って使用することもできる。
【０１３０】
図13は、本発明による実施形態において、SPが銀行である場合の、SPとエンティティ認証センタとの間で相互に認証する方法を示す流れ図である。この実施形態では、サービスエンティティは、銀行SPである。銀行SPが、UEに携帯電話銀行サービスを提供することを望むときに、銀行SPは、まず、共有鍵材料を生成し、セキュリティ接続を確立するために、EACとの相互認証を実行する必要があり、認証手順は、図13を参照すると、次の通りである。
【０１３１】
ブロック1301:SPが、それ自体のUIDを伝える認証要求をEACに転送する。
【０１３２】
ブロック1302:EACは、UIDに従ってSPのサブスクリプション情報を検索し、SPがサービスを提供する資格を与えられていると判断した後に、SPの認証能力の情報すなわち、証明書、証明書TLS認証、事前に供給される鍵ベースのTLS認証など、SPによってサポートされる認証モードを獲得する。
【０１３３】
次に、EACは、サービスセキュリティ度合リストを検索し、携帯電話銀行サービスが高セキュリティ度合サービスに属すると判断し、認証セキュリティ度合リストを検索することによって、高セキュリティ度合を有するネットワークによってサポートされる認証モードが、HTTPダイジェストAKA、証明書TLS認証などを含むことを見つける。また、EACは、最終的に、SPによってサポートされる認証機構を照合し、相互認証で使用される認証機構を決定する。この実施形態では、証明書TLSを使用すると判断される。
【０１３４】
ブロック1303:EACは、認証機構識別子(この実施形態では、証明書TLS認証の識別子である)およびセキュリティ度合識別子を伝えるHello RequestメッセージをSPに向けて開始する。
【０１３５】
ブロック1304:SPは、認証機構が証明書TLSであることを知り、ローカルにSession IDすなわちIAC-IDがあるかどうかを検索する。TLSセキュリティチャネルが、EACの証明書TLS認証を介して確立済みであり、そのチャネルがまだ有効である場合には、Session IDを、TLSセキュリティチャネルのインデックスとすることができる。
【０１３６】
ブロック1305:SPは、Client HelloメッセージをEACに転送する。SPが有効なSession IDを格納していない場合には、このメッセージのSession IDフィールドはヌルであり、SPが有効なSession IDすなわちIAC-IDを格納している場合には、このメッセージのSession IDフィールドはIAC-IDである。
【０１３７】
ブロック1306:Client Helloメッセージを受信した時に、EACは、Session IDフィールドがヌルであるかどうかを検証する。Session IDフィールドがヌルではなく、関連するセキュリティ接続情報を、Session IDフィールド内で伝えられた情報と照合できる場合には、EACは、FinishedメッセージをSPに直接に転送して、セキュリティ接続の認証結果および共有鍵材料が使用可能であるかどうかを検証する。Finishedメッセージ内のパラメータが正しいことを検証した後に、SPは、もう1つのFinishedメッセージをEACに返す。EACが、Finishedメッセージ内のパラメータが正しいことを検証する場合に、この2つの当事者は、そのセキュリティ接続を再利用する。
【０１３８】
Session IDフィールドがヌルであるか、上記のFinishedメッセージがエラーを有する場合には、EACは、ローカルポリシ構成メッセージ内のパラメータに従って、Server certificateメッセージ、ServerKeyExchangeメッセージ(任意選択)、およびCertificateRequestメッセージを返す。最終的に、EACは、ServerHelloDoneメッセージを返して、ServerHelloメッセージおよび関連メッセージが転送され終えたことを示す。
【０１３９】
ブロック1307:ServerHelloDoneメッセージを受信した時に、SPは、Certificateメッセージを返し、その後、ClientKeyExchangeメッセージを転送し、このClientKeyExchangeメッセージを介して、2つの当事者は、共有される秘密パラメータを獲得する。その後、SPは、CertifiicateVerifyメッセージをEACに転送して、SPの証明書を明瞭に検証することにおいてEACを容易にする。最後に、ChangeCipherSpecメッセージを転送した後に、SPは、即座にFinishedメッセージをEACに転送して、鍵交換および認証手順が成功であることを識別する。
【０１４０】
ブロック1308:EACは、SPのFinishedメッセージ内の情報が正しいかどうかを検証する。この情報が正しくない場合には、現在のハンドシェーク手順を打ち切り、この情報が正しい場合には、もう1つのFinishedメッセージをSPに返す。SPが、Finishedメッセージ内の情報が正しいことを検証する場合に、これは、2つの当事者間の認証および鍵交換手順が成功であることを意味する。
【０１４１】
この実施形態は、3GPP/3GPP2ネットワーク内のNAFを認証する均一な手順を提供し、この手順は、本発明による包括的認証アーキテクチャについても適用可能である。
【０１４２】
本発明の上記の実施形態に基づいて、エンティティ認証の装置も提供される。図14は、本発明の実施形態での認証の装置の実施形態を示す構造図である。図14を参照すると、エンティティ認証の装置は、認証要求を転送するモジュール、ネゴシエーションのモジュール、および認証対話のモジュールを含む。
【０１４３】
認証要求を転送するモジュールは、サービスエンティティの認証要求をEACに転送するのに使用され、この認証要求の内容は、サービスエンティティの識別情報を含む。ネゴシエーションのモジュールは、認証要求を受信した後に、EACのローカルポリシに従って認証機構を選択するように構成される。認証対話のモジュールは、サービスエンティティとEACとの間で、選択された認証機構に基づいて認証対話を実行するのに使用される。諸機能の実行に関するこれらのモジュールの原理は、上記の手順で説明済みであり、本明細書では説明しない。
【０１４４】
上記の認証解決策を基礎として、サービスエンティティとEACとの間の認証機構、認証問合せの機構および派生鍵を生成する機構、サービスエンティティの間の認証機構、ならびにセッション鍵を生成する機構などを含む、サービスエンティティ認証、認証問合せ手順、およびサービスエンティティの間の相互認証を全体として定義する認証モードをまず定義することを含む、機能強化された解決策が、本発明の実施形態によって提供される。この解決策は、短く次のように説明される。
【０１４５】
1. 認証モードの定義
主にSSおよびEACの認証機構によって決定され、時々SSおよびSPの認証機構によって決定される、E2E認証モードを定義することができる。その認証モードでは、SSおよびEACの認証機構、SPおよびEACの認証機構、SSとSPとの間の認証機構、認証問合せの機構、派生鍵を生成する機構、セッション鍵を生成する機構などを含む複数の認証関連モードが定義され、実用的な応用例では、上記の認証関連モードの一部だけを、いくつかの場合に関して認証モード内で定義することができる。たとえば、SSおよびSPが、認証機構をネゴシエートせずに直接に認証でき、セキュリティ接続を確立できる場合に、SSとEACとの間の認証およびSPとEACとの間の認証は、不要である。したがって、この場合の認証関連モードでは、SSとSPとの間の認証機構およびセッション鍵を生成する方法だけを定義すればよい。
【０１４６】
この認証モードでは、認証機構が任意選択であるか否かおよび認証方法をネゴシエートしなければならないか否かを含めて、各認証機構の選択するポリシをさらに定義することができる。
【０１４７】
次のように、本発明の実施形態によって採用できる複数のタイプのエンドツーエンド(E2E)認証モードがある。
【０１４８】
E2E_3GPP_AKA、E2E_3GPP2_AKA、E2E_3GPP2_CAVE、E2E_WLAN、E2E_3GPP2_MNAAA、E2E_3GPP_WLAN、E2E_Kerberos、E2E_Mediation、E2E_TLS(しかし、認証モードの定義は、これらのタイプに限定はされず、新しいタイプを必要に応じて定義することもできる)。これらのタイプの認証モードの実施形態は、次の通りである。
【０１４９】
1. E2E_3GPP_AKAの定義は、次の通りである。
E2E_3GPP_AKA ::= struct {
SS<->EAC認証機構 AKA
ベアラプロトコル HTTPダイジェスト
SP<->EAC認証機構 TLS機構(またはIPSecチャネル機構など)
SS<->SP認証機構 基本的な問合せ機構
ベアラプロトコル TLS(または他のプロトコル)
セッション鍵を生成する機構 自己定義(または他の任意選択の機構)
}
【０１５０】
2. E2E_3GPP2_CAVEの定義は、次の通りである。
E2E_3GPP2_CAVE ::= struct {
SS<->EAC認証機構 CAVEに基づく認証
ベアラプロトコル HTTPダイジェスト
SP<->EAC認証機構 TLS機構(またはIPSecチャネル機構など)
SS<->SP認証機構 基本的な問合せ機構
ベアラプロトコル TLS(または他のプロトコル)
セッション鍵を生成する機構 自己定義(または他の任意選択の機構)
}
【０１５１】
3. E2E_WLAN ::= struct {
SS<->EAC認証機構 AKA (またはSIM)
ベアラプロトコル EAP (Extensible Authentication Protocol)
SP<->EAC認証機構 TLS機構(またはIPSecチャネル機構など)
SS<->SP認証機構 基本的な問合せ機構
ベアラプロトコル TLS(または他のプロトコル)
セッション鍵を生成する機構 自己定義(または他の任意選択の機構)
}
【０１５２】
4. E2E_Kerberosの定義は、次の通りである。
SS<->EAC認証機構(ネゴシエーション可能、たとえば、AKA、CABEベースの認証、証明書ベースの認証)
SP<->EAC認証機構 IPSecチャネル(または他の任意選択の機構)
SS<->SP認証機構 Kerberos(強制的、Kerberos解決策および変更されたKerberos解決策のうちのどれを使用しなければならないかをネゴシエートすることができる)
ベアラプロトコル TCP (または他のプロトコル)
セッション鍵を生成する機構 TLS-Krb5 (または他の任意選択の機構)
}
【０１５３】
5. E2E_TLSの定義は、次の通りである。
E2E_TLS ::= struct {
SS<->EAC認証機構 なし
SP<->EAC認証機構 なし
SS<->SP認証機構 TLS
セッション鍵を生成する機構 TLS-PSK5 (または他の任意選択の機構)
}
【０１５４】
6. E2E_3G_GAAの定義は、次の通りである。
SSとEACとの間の認証機構は、SIM、AKA、CAVE、MN-AAA Key、TLS-PSK、TLS-Certなどのうちのいずれかとすることができる;
SPとEACとの間の認証機構は、TLS、IKEとすることができる;
認証問合せの機構および派生鍵を生成する機構は、GBAである;
SSとSPとの間の認証機構は、TLS-PSK、TLS-Certとすることができる。
【０１５５】
7. E2E_KERBEROSの定義は、次の通りである。
SSとEACとの間の認証機構は、E2E_3G_GAAで定義されたものとすることができ、EACは、認証の後にSGTを生成し、サービスエンティティに送信する;
SPとEACとの間の認証機構は、NULL、TLS、IKEとすることができる;
認証問合せの機構および派生鍵を生成する機構は、Kerberosである;
SSとSPとの間の認証機構は、NULL、TLS-KBR5とすることができる。
【０１５６】
8. E2E_Mediationの定義は、次の通りである。
SSとEACとの間の認証機構は、E2E_3G_GAAで定義されたもののほかに、IKEとすることができる;
SPとEACとの間の認証機構は、E2E_3G_GAAで定義されたものとすることができる;
認証問合せの機構および派生鍵を生成する機構は、Mediationである;
SSとSPとの間の認証機構は、TLS-PSKである。
【０１５７】
9. E2E_TLSの定義は、次の通りである。
SSとEACとの間の認証機構は、NULLである;
SPとEACとの間の認証機構は、NULLである;
認証問合せの機構および派生鍵を生成する機構は、NULLである;
SSとSPとの間の認証機構は、TLS-Cert、TLS-PSKとすることができる。
【０１５８】
上記のモードでは、新しい認証モードを、サービス要件に従って定義することができる。本発明の実施形態は、認証機構、選択ポリシ、および鍵を生成する機構など、認証モードで定義された特定の認証関連モードに限定されない。
【０１５９】
図15は、本発明の実施形態でのサービス加入者とEACとの間の認証手順を示す流れ図である。図15を参照すると、この実施形態では、3GPPネットワーク内のモバイル加入者のUEが、インターネット内のアプリケーションサーバによって提供されるサービスを使用する(このサーバは、Kerberos認証プロトコルをサポートする)。詳細な手順は、次の通りである。
【０１６０】
ブロック1501:SS(すなわち、UE)は、UEのID、認証機能識別子、サービスタイプを伝えるサービス要求をEACに転送し、このサービス要求は、EACがUIDを介してエンティティサブスクリプションデータベース(ESD)から対応するサービスタイプを検索することを可能にするために、サービスタイプではなく、SPのUIDを伝える場合がある。
【０１６１】
ブロック1502:EACは、サービス要求内のIDと、SSおよびSPの認証機能の情報とに従ってローカルポリシを採用することによって、認証モードおよび対応する認証機構を選択する。この実施形態では、選択される認証モードが、E2E_Kerberosモードであると仮定する。
【０１６２】
EACは、ローカルポリシおよび認証モード内の選択するポリシに従って各認証機構を判断することができる。ローカルポリシは、SSおよびSPが、この2つの当事者の認証機能およびサービスタイプに従って相互認証機構およびセッション鍵を生成する機構を選択することとすることができ、SPとEACとの間で相互認証を実行するかどうかは、SSおよびSPの相互認証機構によって判断することができる。相互認証を実行する必要がある場合には、認証機構は、SPおよびEACの認証機能ならびにサービスタイプなどに従って選択される。
【０１６３】
ブロック1503:E2E_Kerberosモードの定義に従って、SSおよびEACの認証機構は、ネゴシエーション可能であり、したがって、認証機構を、ローカルポリシ(すなわち、2つの当事者の認証機能、2つの当事者によって使用されるサービスのタイプなど)に従って選択することができる。この実施形態では、SSおよびEACの認証機構は、AKA認証機構と仮定される。SSおよびEACの認証機構は、IPSecチャネルまたは他の機構とすることができ、任意選択である。この実施形態では、SSおよびEACの認証機構が、ヌルとして構成される、すなわち、SPとEACとの間の認証が実行されないと仮定する。SSおよびSPの認証機構は、Kerberosとしてセットされ、したがって、SSおよびSPの認証機構は、Kerberosまたは変更されたKerberos解決策のどちらを使用するかを判断することによってネゴシエートすることができ、ベアラプロトコルは、ネゴシエーションによってTCPまたは他のプロトコルとすることができる。この実施形態では、2つの当事者の認証機能、サービスタイプなどに従って、ネゴシエーションを介して、Kerberosが、SSおよびSPの認証機構として選択され、TLS-Krb5が、ベアラプロトコルとして選択される。セッション鍵を生成する機構は、TLS-Krb5または他の機構としてセットされ、任意選択であり、この実施形態では、TLS-Krb5が、セッション鍵を生成する機構として選択される。
【０１６４】
上記で選択されたさまざまな認証モードに従って、SSとEACとの間の認証を開始することができる。SSおよびEACが、AKA相互認証を実行済みであり、生成された共有鍵およびISR-IDが、まだ寿命のうちである場合には、AKA相互認証を実行する必要はなく、ブロック1509を直接に実行して、SGTを生成することになる。
【０１６５】
ブロック1504:EACは、加入者の認証ベクトル(RAND、AUTN、RES、CK、IK)をESDから獲得する。
【０１６６】
ブロック1505:EACは、RANDおよびAUTNを伝えるHTTP 401メッセージ(ダイジェストAKAチャレンジを含む)をUEに転送し、メッセージのペイロード情報内で認証機構識別子aを伝える。
【０１６７】
ブロック1506:UEは、AUTNを計算し、受信したAUTNの妥当性を検証して、チャレンジが許可されたネットワークから来たかどうかを確認し、CK、IK、およびRESを計算する。
【０１６８】
ブロック1507:UEは、ダイジェストAKA応答およびRESを使用することによって計算されたアブストラクト値を含むHTTPメッセージをEACに転送する。
【０１６９】
ブロック1508:EACは、計算されたアブストラクト値の正確さを検証して、UEの妥当性を認証する。
【０１７０】
ブロック1509:EACは、共有鍵Ks=CK‖IKおよびISR-IDを生成し、次に、共有鍵Ks、SSのID、およびSPのUIDを使用して派生鍵Kspを生成し、生成された派生鍵をSGT内で伝え、このSGTの内容は、Ksp、SSのISR-ID、SPのUID、寿命、反射攻撃を防ぐためのパラメータなどを含み、SGTは、EACおよびSPの共有鍵によって暗号化される。
【０１７１】
ブロック1510:EACは、共有鍵の寿命、ISR-ID、およびKsを使用することによって暗号化されたSGTを含む200 OKメッセージをUEに転送して、認証の成功の終了を識別する。
【０１７２】
ブロック1511:UEは、共有鍵Ks=CK‖IKおよび派生鍵Kspをも生成し、その後、暗号化解除によって200 OKメッセージ内のISR-IDを獲得し、暗号化解除によって獲得した上記情報を認証モード情報に関連付け、関連付けられた情報をローカルに格納する。
【０１７３】
図16は、本発明による実施形態での、SSとSPとの間の相互認証のプロセスを示す流れ図である。図16を参照すると、SSとSPとの間の相互認証の詳細な手順は、次の通りである。
【０１７４】
ブロック1601:SSは、SPのUID、SSによってサポートされるTLS-KRB5暗号化スイート、およびE2E_Kerberosの認証モードの関連情報を伝えるClientHelloメッセージをSPに転送する。
【０１７５】
E2E_Kerberosの認証モードの関連情報は、SSとSPとの間の認証機構およびセッション鍵を生成する機構を含む、定義されたモードを指す。
【０１７６】
ブロック1602:Client Helloメッセージを受信した時に、SPは、Session IDフィールドがヌルであることを見つけ、その後、2つの当事者によってサポートされるTLS-KRB5暗号化スイートを選択し、ServerRequestメッセージ、ServerHello、およびServerHelloDoneメッセージをSSに転送する。
【０１７７】
ブロック1603:ServiceHelloDoneメッセージを受信した時に、SSは、ClientKeyExchangeメッセージをSPに転送し、これによって、この2つの当事者は、事前に共有された秘密パラメータ(PreMasterSecret)を獲得する。SSは、PreMasterSecretおよび乱数を使用して、セッション鍵(MasterSecret)を生成する。その後、SSは、ChangeCipherSpecメッセージをSPに転送し、その後、正式の鍵交換および妥当性検査のためにFinishedメッセージをSPに転送する。
【０１７８】
ブロック1604:SPは、SGTを暗号化解除し、SGTの妥当性をチェックし、共有される派生鍵Kspを獲得し、共有される派生鍵Kspを使用してPreMasterSecretを暗号化解除し、PreMasterSecretおよび乱数に従ってSSおよびSPのセッション鍵MasterSecretを生成する。その後、SPは、SSからのFinishedメッセージ内の情報が正しいかどうかを検証する。この情報が正しくない場合には、SPは、現在の手順を打ち切り、そうでない場合には、ブロック1605を実行する。
【０１７９】
ブロック1605:SPは、ChangeCipherSpecメッセージをSSに転送し、その後、FinishedメッセージをSSに転送する。
【０１８０】
ブロック1606:SSは、SPからのFinishedメッセージ内の情報が正しいかどうかを検証する。SSが、SPからのFinishedメッセージ内の情報が正しいと判断する場合には、これは、この2つの当事者の間の認証および鍵交換手順が成功して終了したことを意味する。
【０１８１】
ブロック1607:SSおよびSPは、サービス通信データの転送を始める。
【０１８２】
上記の手順で確立されたセッションが期限を過ぎてはいないときに、SSがもう一度サービス要求をSPに転送する場合に、最後のセッションで生成されたPreMasterSecretを再利用して、このサービス通信のための新しいセッション鍵(MasterSecret)を生成することができる。
【０１８３】
図17は、本発明による実施形態での、セッション鍵を生成するためにSSおよびSPが認証結果を再利用するプロセスを示す流れ図である。図17を参照すると、詳細な手順は、次の通りである。
【０１８４】
ブロック1701:SSは、最後に発生した最後のセッションのSession IDを伝えるClient HelloメッセージをSPに転送する。
【０１８５】
ブロック1702:Client Helloメッセージを受信した時に、SPは、メッセージ内のSession IDがヌルとしてセットされてはいないことを見つけ、そのSession IDに関連するセキュリティ接続情報を照合することができ、したがって、そのSession IDは、このセッションを識別するために再利用される。さらに、SPは、Session IDを伝えるServerHelloメッセージをSSに転送し、その後、ServerHelloDoneメッセージをSSに転送する。
【０１８６】
ブロック1703:SSは、SPと共有されたPreMasterSecretを使用してセッション鍵(MasterSecret)を生成する。
【０１８７】
ブロック1704:SSは、ChangeCipherSpecメッセージをSPに転送し、その後、FinishedメッセージをSPに転送する。
【０１８８】
ブロック1705:受信したFinishedメッセージが正しいと判断した後に、SPは、同一のPreMasterSecretを使用して、セッション鍵(MasterSecret)を生成する。
【０１８９】
ブロック1706:SPは、ChangeCipherSpecメッセージをSSに転送し、その後、FinishedメッセージをSSに転送する。
【０１９０】
ブロック1707:SSによって受信されたFinishedメッセージが正しいと判断される場合に、この2つの当事者の間の相互認証が打ち切られ、サービス通信データが転送され始める。
【０１９１】
認証モードに基づく機能強化されたエンティティ認証解決策に従って、エンティティ認証のもう1つの装置が、本発明による実施形態によって提供される。この装置は、図14に示された装置に類似する。図18は、本発明によるエンドツーエンド通信認証装置の実施形態を示す概略図である。図18を参照すると、エンティティ認証の装置は、認証要求をEACに転送するように構成された転送するモジュール(図14に示された認証要求を転送するモジュールに類似する)と、転送するモジュールによって転送された認証要求に従って認証モードを選択し、サービスエンティティに知らせるように構成された選択するモジュール(図14のネゴシエーションのモジュールに類似する)と、選択するモジュールによって選択された認証機構に従って、サービスエンティティとEACとの間またはサービスエンティティの間で認証を実行するように構成された認証のモジュールとを含む。これらのモジュールの特定の機能を実施するための原理は、上記の手順で説明済みであり、したがって、さらなる説明は、本明細書では提供しない。
【０１９２】
もちろん、上記の2つの装置の機能を実現できる、エンティティ認証の別の装置を、本発明による実施形態によって提供することができる。この装置は、上記の転送するモジュールおよび認証要求を転送するモジュールの機能を実行するのに使用される第1モジュールと、選択するモジュールおよびネゴシエーションのモジュールの機能を実行するのに使用される第2モジュールと、認証のモジュールおよび認証対話のモジュールの機能を実行するのに使用される第3モジュールとを含むことができる。この装置に関するさらなる説明は、本明細書では提供しない。
【０１９３】
以上の記載は、本発明の実施形態に過ぎず、本発明の保護の範囲を限定するのに使用するためのものではない。本発明の趣旨および原理の範囲内のすべての変更、同等の置換、または改善は、添付の特許請求の範囲の保護範囲に含まれなければならない。
【図面の簡単な説明】
【０１９４】
【図１】GAA(Generic Authentication Architecture)のアーキテクチャを示す概略図である。
【図２】従来技術の3GPP2でのGAAのアーキテクチャを示す図である。
【図３】本発明の実施形態によるモバイルネットワークに基づくエンドツーエンド通信認証のアーキテクチャを示す概略図である。
【図４】本発明による実施形態での、サービスエンティティとエンティティ認証センタとの間で認証機構をネゴシエートし、相互認証を実行するプロセスを示す流れ図である。
【図５】本発明による実施形態での、サービスエンティティとエンティティ認証センタとの間での認証問合せのプロセスを示す流れ図である。
【図６】Kerberosモデルと組み合わされたエンドツーエンド認証モデルを示す概略図である。
【図７】Kerberosモデルと組み合わされた認証問合せのプロセスを示すブロック図である。
【図８】Mediationモデルと組み合わされたエンドツーエンド認証モデルを示す概略図である。
【図９】Mediationモデルと組み合わされた認証問合せのプロセスを示すブロック図である。
【図１０】本発明による実施形態でのサービスエンティティを認証する方法を示す流れ図である。
【図１１】本発明による実施形態による3GPP無線ネットワークでサービスエンティティを認証する方法を示す流れ図である。
【図１２】本発明による実施形態での3GPP2無線ネットワークでサービスエンティティを認証する方法を示す流れ図である。
【図１３】本発明による実施形態での、SPが銀行である場合の、SPとエンティティ認証センタとの間で相互に認証する方法を示す流れ図である。
【図１４】本発明の実施形態による、認証装置の実施形態の構造を示す概略図である。
【図１５】本発明による実施形態での、サービス加入者とエンティティ認証センタとの間の認証のプロセスを示す流れ図である。
【図１６】本発明による実施形態での、サービス加入者とサービスプロバイダとの間の相互認証のプロセスを示す流れ図である。
【図１７】本発明による実施形態での、セッション鍵を生成するためにサービス加入者およびサービスプロバイダが認証結果を再利用するプロセスを示す流れ図である。
【図１８】本発明によるエンドツーエンド通信認証装置の実施形態の構造を示す概略図である。
【符号の説明】
【０１９５】
101 加入者
102 BSF(Bootstrapping Server Function)
103 HSS(Home Subscriber Server)
104 NAF(Network Application Function)
201 MN(Mobile Node)
202 NAF(Network Application Function)
203 BSF
204 HSS
301 サービス加入者(SS)
302 サービスプロバイダ(SP)
303 エンティティ認証センタ(EAC)
304 エンティティサブスクリプションデータベース(ESD)
【特許請求の範囲】
【請求項１】
サービスを要求する第1サービスエンティティと、前記サービスを提供する第2サービスエンティティと、エンティティ認証センタすなわちEACとを具備するシステムに適用される、モバイルネットワークに基づくエンドツーエンド通信において認証を行う方法であって、
前記第1サービスエンティティと前記EACとの間で認証モードをネゴシエートする段階であって、前記ネゴシエートされた認証モードは、前記第1サービスエンティティと前記EACとの間の認証機構と、前記第2サービスエンティティと前記EACとの間の認証機構と、認証問合せの機構と、派生鍵を生成する機構と、前記第1サービスエンティティと前記第2サービスエンティティとの間の認証機構とを含む、段階と、
前記ネゴシエートされた認証モードに含まれる前記第1サービスエンティティと前記EACとの間の前記認証機構に従って前記EACと前記第1サービスエンティティとの間で相互認証を実行し、前記ネゴシエートされた認証モードに含まれる前記第2サービスエンティティと前記EACとの間の前記認証機構に従って前記EACと前記第2サービスエンティティとの間で相互認証を実行する段階と、
前記第1サービスエンティティが、前記サービスを提供するように前記第2サービスエンティティに要求する場合に、前記EACが、前記ネゴシエートされた認証モードに含まれる認証問合せの前記機構に従って前記第1サービスエンティティおよび前記第2サービスエンティティに関する認証問合せを提供し、前記ネゴシエートされた認証モードに含まれる派生鍵を生成する前記機構に従って前記第1サービスエンティティと前記第2サービスエンティティとの間の通信を保護する共有される派生鍵を生成する段階と、
前記第1サービスエンティティおよび前記第2サービスエンティティが、前記共有される派生鍵、および前記ネゴシエートされた認証モードに含まれる前記第1サービスエンティティと前記第2サービスエンティティとの間の前記認証機構に従って互いを認証し、前記サービスを保護するセッション鍵を生成する段階と
を有することを特徴とする方法。
【請求項２】
前記第1サービスエンティティによって、前記EACと認証モードをネゴシエートする段階は、
前記第1サービスエンティティによって、認証要求を前記EACに送信する段階であって、前記認証要求は、前記第1サービスエンティティの識別情報および現在要求されているサービスのタイプを伝える、段階と、
前記EACが、現在要求されている前記サービスの前記タイプに従って前記サービスを提供する前記第2サービスエンティティを判定し、前記第1サービスエンティティおよび前記第2サービスエンティティの認証機能を獲得し、前記第1サービスエンティティおよび前記第2サービスエンティティの前記認証機能に従って前記認証モードを選択する段階と
を有することを特徴とする請求項1に記載の方法。
【請求項３】
前記認証モードは、前記第1サービスエンティティと前記第2サービスエンティティとの間のセッション鍵を生成する機構をさらに含み、
前記サービスを保護する前記セッション鍵を生成する段階は、前記ネゴシエートされた認証モードに含まれる前記第1サービスエンティティと前記第2サービスエンティティとの間の前記セッション鍵を生成する前記機構に従って前記セッション鍵を生成する段階を有することを特徴とする請求項1に記載の方法。
【請求項４】
前記EACと前記第1サービスエンティティとの間で前記相互認証を実行する段階は、
前記EACおよび前記第1サービスエンティティによって互いを認証する段階と、
前記EACによって前記第1サービスエンティティの一時識別情報を割り振る段階と、
前記EACおよび前記第1サービスエンティティが、それぞれ、それらの間での通信を保護する共有鍵材料を獲得し、前記獲得された共有鍵材料と共に前記割り振られた一時識別情報を格納する段階と
を有し、
前記EACと前記第2サービスエンティティとの間で前記相互認証を実行する段階は、
前記EACおよび前記第2サービスエンティティによって互いを認証する段階と、
前記EACによって前記第2サービスエンティティの一時識別情報を割り振る段階と、
前記EACおよび前記第2サービスエンティティが、それぞれ、それらの間での通信を保護する共有鍵材料を獲得し、前記獲得された共有鍵材料と共に前記割り振られた一時識別情報を格納する段階と
を有し、
前記EACが、前記第1サービスエンティティおよび前記第2サービスエンティティに関する認証問合せを提供し、前記第1サービスエンティティと前記第2サービスエンティティとの間の通信を保護する共有される派生鍵を生成する段階は、
前記EACが、前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って前記第1サービスエンティティおよび前記第2サービスエンティティの権限を認証する段階と、
前記EACが、前記EACと前記第1サービスエンティティとの間の前記通信を保護する前記共有鍵材料、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記第1サービスエンティティと前記第2サービスエンティティとの間の前記通信を保護する前記共有される派生鍵を計算する段階と、
前記EACが、前記共有される派生鍵を前記第2サービスエンティティに転送する段階と、
前記第2サービスエンティティが、前記第1サービスエンティティの前記一時識別情報、前記共有される派生鍵、および現在要求されている前記サービスの前記タイプを関連付ける段階と、
前記第2サービスエンティティが、前記関連付けられた前記第1サービスエンティティの前記一時識別情報、前記共有される派生鍵、および現在要求されている前記サービスの前記タイプを格納する段階と、
前記第1サービスエンティティが、前記EACとの前記通信を保護する前記共有鍵材料、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算する段階と
を有することを特徴とする請求項1に記載の方法。
【請求項５】
前記共有される派生鍵、前記共有鍵材料、および前記一時識別情報のそれぞれは、寿命を有し、
前記方法は、
前記EACによって、その前記寿命が満了しようとしているかまたは満了した前記共有鍵材料または前記一時識別情報に対応する前記第1サービスエンティティおよび/または前記第2サービスエンティティに、再認証手順を開始しなければならないことを通知する段階、
その前記寿命が満了しようとしているかまたは満了した前記共有鍵材料または前記一時識別情報に対応する前記第1サービスエンティティおよび/または前記第2サービスエンティティによって、前記EACに対する前記再認証手順を開始する段階、
前記EACによって、その前記寿命が満了しようとしているかまたは満了した前記共有される派生鍵に対応する前記第1サービスエンティティに、前記再認証手順を開始しなければならないことを通知する段階、
および/または、
前記第2サービスエンティティによって、前記第1サービスエンティティと前記第2サービスエンティティとの間の前記通信を保護する前記共有される派生鍵の前記寿命または前記第1サービスエンティティの前記一時識別情報の前記寿命が満了しようとしているかまたは満了した場合に、前記再認証手順を開始しなければならないことを前記第1サービスエンティティに通知する段階
をさらに有することを特徴とする請求項4に記載の方法。
【請求項６】
サービスエンティティおよびEACに適用される、サービスエンティティを認証する方法であって、
前記サービスエンティティと前記EACとの間で認証モードをネゴシエートする段階であって、前記ネゴシエートされた認証モードは、前記サービスエンティティと前記EACとの間の認証機構を含む、段階と、
前記ネゴシエートされた認証モードに含まれる前記認証機構に従って前記サービスエンティティと前記EACとの間で相互認証を実行する段階と
を有することを特徴とする方法。
【請求項７】
前記サービスエンティティによって前記EACと認証モードをネゴシエートする前記段階は、
前記サービスエンティティによって、前記EACに認証要求を送信する段階であって、前記認証要求は、前記サービスエンティティの識別情報および現在要求されているサービスのタイプを伝える、段階と、
前記EACが、現在要求されている前記サービスの前記タイプに従って前記サービスを提供するサービスエンティティを判定し、前記認証要求を送信する前記サービスエンティティおよび前記サービスを提供する前記サービスエンティティの認証機能を獲得し、前記2つのサービスエンティティの前記認証機能に従って前記認証モードを選択する段階と
を有することを特徴とする請求項6に記載の方法。
【請求項８】
前記認証要求を送信する前記サービスエンティティおよび前記サービスを提供する前記サービスエンティティの認証機能を獲得する前記段階は、
前記EACが、前記認証要求から前記認証要求を送信する前記サービスエンティティの前記認証機能を獲得し、前記サービスを提供する前記サービスエンティティを判定した後に、前記サービスを提供する前記サービスエンティティのサブスクリプションデータを問い合わせることによって、前記サービスを提供する前記サービスエンティティの前記識別情報に従って前記サービスを提供する前記サービスエンティティの前記認証機能を獲得する段階、
または、
前記EACが、前記サービスを提供する前記サービスエンティティの前記サブスクリプションデータを問い合わせることによって、前記認証要求を送信する前記サービスエンティティの前記識別情報に従って前記認証要求を送信する前記サービスエンティティの前記認証機能を獲得し、前記サービスを提供する前記サービスエンティティを判定した後に、前記サービスを提供する前記サービスエンティティの前記サブスクリプションデータを問い合わせることによって前記サービスを提供する前記サービスエンティティの前記認証機能を獲得する段階
を有することを特徴とする請求項7に記載の方法。
【請求項９】
前記サービスエンティティと前記EACとの間で相互認証を実行する段階は
前記サービスエンティティおよび前記EACが、互いを認証し、それぞれ、前記サービスエンティティと前記EACとの間の前記通信を保護する共有鍵材料を獲得する段階と、
前記EACによって、前記サービスエンティティの一時識別情報を割り振る段階と、
前記EACおよび前記サービスエンティティが、それぞれ、前記獲得された共有鍵材料と共に前記割り振られた一時識別情報を格納する段階と
を有することを特徴とする請求項6に記載の方法。
【請求項１０】
前記共有鍵材料および前記一時識別情報のそれぞれは、寿命を有し、
前記方法は、
前記EACによって、前記共有鍵材料または前記一時識別情報の前記寿命が満了しようとしているかまたは満了した場合に再認証手順を開始しなければならないことを前記サービスエンティティに通知する段階、
および/または、
前記サービスエンティティによって、前記共有鍵材料または前記一時識別情報の前記寿命が満了しようとしているかまたは満了した場合に、前記EACに対する前記再認証手順を開始する段階と
をさらに有することを特徴とする請求項9に記載の方法。
【請求項１１】
サービスを要求する第1サービスエンティティと、前記サービスを提供する第2サービスエンティティと、EACとを具備するシステムに適用される、認証問合せの方法であって、
前記第1サービスエンティティと前記EACとの間の相互認証と、前記第2サービスエンティティと前記EACとの間の相互認証とが、それぞれ実行され、
前記EACは、前記第1サービスエンティティおよび前記第2サービスエンティティの一時識別情報をそれぞれ割り振り、前記第1サービスエンティティおよび前記第2サービスエンティティとの通信を保護する共有鍵材料をそれぞれ獲得し、
前記第1サービスエンティティは、認証問合せの機構および派生鍵を生成する機構を含む認証モードを前記EACとネゴシエートし、
前記方法は、
前記第1サービスエンティティが、前記第2サービスエンティティによって提供される前記サービスを要求する場合に、前記ネゴシエートされた認証モードに含まれる認証問合せの前記機構に従って、前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って前記第1サービスエンティティおよび前記第2サービスエンティティの権限を認証する段階と、
前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報、ならびに前記第1サービスエンティティとの通信を保護する前記共有鍵材料に従って、前記第1サービスエンティティと前記第2サービスエンティティとの間の通信を保護する共有される派生鍵を計算する段階と
を有することを特徴とする方法。
【請求項１２】
前記EACが、前記ネゴシエートされた認証モードに含まれる認証問合せの前記機構に従って、それぞれ前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って前記第1サービスエンティティおよび前記第2サービスエンティティの前記権限をそれぞれ認証し、前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記第1サービスエンティティとの前記通信を保護する前記共有鍵材料、ならびに前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算し、前記計算された共有される派生鍵を前記第2サービスエンティティに転送する段階と、
前記第2サービスエンティティが、前記共有される派生鍵および現在要求されている前記サービスの前記タイプと共に、前記第1サービスエンティティの前記一時識別情報を格納する段階と、
前記第1サービスエンティティによって、前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記EACとの前記通信を保護する前記共有鍵材料、ならびに前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算する段階と
を有することを特徴とする請求項11に記載の方法。
【請求項１３】
前記第2サービスエンティティに前記サービスを要求する場合に前記第1サービスエンティティの前記一時識別情報を前記第1サービスエンティティによって前記第2サービスエンティティに提供する段階と、
前記第2サービスエンティティの前記一時識別情報および前記第1サービスエンティティの前記一時識別情報を前記第2サービスエンティティによって前記EACに提供する段階と、
前記EACが、前記ネゴシエートされた認証モードに含まれる認証問合せの前記機構に従って、それぞれ前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って前記第1サービスエンティティおよび前記第2サービスエンティティの前記権限をそれぞれ認証し、前記第1サービスエンティティとの前記通信を保護する前記共有鍵材料、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算し、前記計算された共有される派生鍵を前記第2サービスエンティティに転送する段階と、
前記第2サービスエンティティによって、前記共有される派生鍵および現在要求されている前記サービスの前記タイプと共に前記第1サービスエンティティの前記一時識別情報を格納する段階と、
前記第1サービスエンティティによって、前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記EACとの前記通信を保護する前記共有鍵材料、ならびに前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算する段階と
を有することを特徴とする請求項11に記載の方法。
【請求項１４】
サービス許可チケットすなわちSGTを前記EACに要求する場合に、前記第1サービスエンティティの前記一時識別情報および現在要求されている前記サービスのタイプを前記第1サービスエンティティによって前記EACに提供する段階と、
前記EACが、前記第1サービスエンティティの前記一時識別情報に従って前記第1サービスエンティティの前記権限を認証し、前記サービスの前記タイプに従って前記第2サービスエンティティの前記一時識別情報を獲得し、前記第2サービスエンティティの前記一時識別情報に従って前記第2サービスエンティティの前記権限を認証し、前記第1サービスエンティティとの前記通信を保護する前記共有鍵材料、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算し、前記計算された共有される派生鍵、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報を含む前記SGTを生成し、前記生成されたSGTを前記第1サービスエンティティに送信する段階と、
前記第1サービスエンティティが、前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記EACとの前記通信を保護する前記共有鍵材料、ならびに前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算し、前記第2サービスエンティティに前記サービスを要求する場合に前記EACから送信された前記SGTを前記第2サービスエンティティに提供する段階と、
前記第2サービスエンティティが、前記第1サービスエンティティによって提供された前記SGTから前記共有される派生鍵を獲得し、前記共有される派生鍵および現在要求されている前記サービスの前記タイプと共に前記第1サービスエンティティの前記一時識別情報を格納する段階と
を有することを特徴とする請求項11に記載の方法。
【請求項１５】
前記EACにサービス要求を送信する場合に、前記第1サービスエンティティの前記一時識別情報および現在要求されている前記サービスのタイプを前記第1サービスエンティティによって前記EACに提供する段階と、
前記EACが、前記第1サービスエンティティの前記一時識別情報に従って前記第1サービスエンティティの前記権限を認証し、現在要求されている前記サービスの前記タイプに従って前記第2サービスエンティティに前記サービス要求を転送する段階と、
前記第2サービスエンティティの前記一時識別情報を前記第2サービスエンティティによって前記EACに返す段階と、
前記EACが、前記第2サービスエンティティの前記一時識別情報に従って前記第2サービスエンティティの前記権限を認証し、前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記第1サービスエンティティとの前記通信を保護する前記共有鍵材料、ならびに前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算し、前記計算された共有される派生鍵を前記第2サービスエンティティに送信する段階と、
前記共有される派生鍵および現在要求されている前記サービスの前記タイプと共に前記第1サービスエンティティの前記一時識別情報を前記第2サービスエンティティによって格納する段階と、
前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記EACとの前記通信を保護する前記共有鍵材料、ならびに前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を前記第1サービスエンティティによって計算する段階と
を有することを特徴とする請求項11に記載の方法。
【請求項１６】
前記EACが前記共有される派生鍵を前記第2サービスエンティティに転送する時に、前記方法は、前記第2サービスエンティティとの前記通信を保護するために、前記通信を保護する前記共有鍵材料を前記EACによって使用する段階をさらに有することを特徴とする請求項11から15のいずれか一項に記載の方法。
【請求項１７】
サービスを要求する第1サービスエンティティと、サービスを提供する第2サービスエンティティと、EACとを具備するモバイルネットワークに基づくエンドツーエンド通信において認証を行うシステムであって、
前記第1サービスエンティティは、認証に関係する少なくとも1つの機構を含む認証モードを前記EACとネゴシエートし、前記ネゴシエートされた認証モードに従って前記第1サービスエンティティと前記EACとの間で相互認証を実行し、前記第2サービスエンティティにサービスを要求し、前記ネゴシエートされた認証モードに従って、前記第1サービスエンティティと前記第2サービスエンティティとの間の通信を保護する共有される派生鍵に従って前記第1サービスエンティティと前記第2サービスエンティティとの間で相互認証を実行するように構成され、
前記第2サービスエンティティは、前記ネゴシエートされた認証モードに従って前記EACを認証し、前記第1サービスエンティティが前記サービスを要求する場合に前記ネゴシエートされた認証モードに従って前記第1サービスエンティティと前記第2サービスエンティティとの間の前記通信を保護する前記共有される派生鍵に従って前記第1サービスエンティティと前記第2サービスエンティティとの間で前記相互認証を実行するように構成され、
前記EACは、前記ネゴシエートされた認証モードに従って、前記EACと前記第1サービスエンティティとの間の前記相互認証と、前記EACと前記第2サービスエンティティとの間の相互認証とをそれぞれ実行し、前記第1サービスエンティティが前記サービスを要求する時に、前記ネゴシエートされた認証モードに従って前記第1サービスエンティティおよび前記第2サービスエンティティに関する認証問合せを提供し、前記第1サービスエンティティと前記第2サービスエンティティとの間の前記通信を保護する前記共有される派生鍵を生成するように構成されることを特徴とするシステム。
【請求項１８】
サービスエンティティのサブスクリプションデータを格納するデータベースをさらに具備し、
前記EACは、前記認証モードをネゴシエートする場合に、前記第1サービスエンティティおよび前記第2サービスエンティティの認証機能を獲得するために前記第1サービスエンティティおよび前記第2サービスエンティティの識別情報に従って前記データベースに問い合わせ、前記第1サービスエンティティおよび前記第2サービスエンティティの前記獲得された認証機能に従って前記認証モードを選択するようにさらに構成されることを特徴とする請求項17に記載のシステム。
【請求項１９】
前記EACは、前記EACと前記第1サービスエンティティとの間の前記相互認証と、前記EACと前記第2サービスエンティティとの間の前記相互認証とをそれぞれ実行する時に、それぞれ、前記第1サービスエンティティおよび前記第2サービスエンティティの一時識別情報を割り振り、前記第1サービスエンティティおよび前記第2サービスエンティティとの通信を保護する共有鍵材料を獲得し、前記第1サービスエンティティおよび前記第2サービスエンティティに関する前記認証問合せを提供する時に、前記ネゴシエートされた認証モードに従って、前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報、および前記第1サービスエンティティとの前記通信を保護する前記共有鍵材料に従って、前記第1サービスエンティティと前記第2サービスエンティティとの間の前記通信を保護する前記共有される派生鍵を計算し、前記共有される派生鍵を前記第2サービスエンティティに転送するように構成され、
前記第1サービスエンティティは、前記サービスを要求する時に、前記ネゴシエートされた認証モードに従って、前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報、および前記EACとの前記通信を保護する前記共有鍵材料に従って、前記共有される派生鍵を計算するように構成され、
前記第2サービスエンティティは、前記EACによって返された前記共有される派生鍵および前記第1サービスエンティティによって要求された前記サービスの前記タイプと共に前記第1サービスエンティティの前記一時識別情報を格納するようにさらに構成されることを特徴とする請求項17に記載のシステム。
【請求項２０】
サービスエンティティおよびEACを具備する、サービスエンティティを認証するシステムであって、
前記サービスエンティティは、前記サービスエンティティと前記EACとの間の認証機構を含む認証モードを前記EACとネゴシエートし、前記ネゴシエートされた認証モードに含まれる前記認証機構に従って前記サービスエンティティと前記EACとの間で相互認証を実行するように構成されることを特徴とするシステム。
【請求項２１】
サービスエンティティのサブスクリプションデータを格納するデータベースをさらに具備し、
前記EACは、前記認証モードをネゴシエートする時に、サービスを要求するサービスエンティティおよび前記サービスを提供するサービスエンティティの識別情報に従って前記データベースに問い合わせ、前記2つのサービスエンティティの認証機能を獲得し、前記2つのサービスエンティティの前記認証機能に従って前記認証モードを選択するようにさらに構成されることを特徴とする請求項20に記載のシステム。
【請求項２２】
サービスを要求する第1サービスエンティティ、前記サービスを提供する第2サービスエンティティ、およびEACを具備する、認証問合せのシステムであって、
前記第1サービスエンティティは、認証問合せの機構および派生鍵を生成する機構を含む認証モードを前記EACとネゴシエートするように構成され、
前記EACは、前記第1サービスエンティティが前記サービスを要求する時に、前記ネゴシエートされた認証モードに含まれる認証問合せの前記機構に従って、前記第1サービスエンティティおよび前記第2サービスエンティティの権限を認証し、前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構に従って、前記第1サービスエンティティと前記第2サービスエンティティとの間の通信を保護する共有される派生鍵を生成するように構成されることを特徴とするシステム。
【請求項２３】
前記EACは、前記第1サービスエンティティおよび前記第2サービスエンティティの一時識別情報に従って前記第1サービスエンティティおよび前記第2サービスエンティティの前記権限を認証し、前記第1サービスエンティティとの通信を保護する共有鍵材料、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算し、前記計算された共有される派生鍵を前記第2サービスエンティティに転送するように構成され、
前記第1サービスエンティティは、前記EACとの前記通信を保護する前記共有鍵材料、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算するように構成され、
前記第2サービスエンティティは、前記EACによって返された前記共有される派生鍵および要求された前記サービスのタイプと共に前記第1サービスエンティティの前記一時識別情報を格納するように構成されることを特徴とする請求項22に記載のシステム。
【請求項２４】
認証センタであって、
サービスエンティティの認証モードをネゴシエートするように構成された第1モジュールであって、前記認証モードは、前記サービスエンティティと前記認証センタとの間の認証機構を含む、第1モジュールと、
前記第1モジュールによってネゴシエートされた前記認証モードに含まれる前記認証機構に従って前記サービスエンティティを認証するように構成された第2モジュールと
を具備することを特徴とする認証センタ。
【請求項２５】
前記第1モジュールは、
サービスを要求するサービスエンティティおよび前記サービスを提供するサービスエンティティの認証機能をそれぞれ獲得するためにサブスクリプションデータを問い合わせるように構成された第1サブモジュールと、
前記サービスを要求する前記サービスエンティティおよび前記サービスを提供する前記サービスエンティティの前記認証機能に従って認証モードを選択するように構成された第2サブモジュールであって、前記認証機能は、前記第1モジュールによって獲得される、第2サブモジュールと
を具備することを特徴とする請求項24に記載の認証センタ。
【請求項２６】
前記認証モードは、認証問合せの機構および派生鍵を生成する機構をさらに含み、
前記認証センタは、
前記サービスエンティティが前記サービスを要求する時に、前記サービスを要求する前記サービスエンティティおよび前記サービスを提供する前記サービスエンティティに関する認証問合せを提供し、前記第1モジュールによってネゴシエートされた前記認証モードに含まれる認証問合せの前記機構および前記派生鍵を生成する前記機構に従って、前記2つのサービスエンティティの間の通信を保護する前記共有される派生鍵を計算するように構成された第3モジュールをさらに具備することを特徴とする請求項24または25に記載の認証センタ。
【請求項２７】
前記第2モジュールは、前記2つのサービスエンティティの共有鍵材料および一時識別情報を生成するように構成され、
前記第3モジュールは、前記第2モジュールによって生成された前記2つのサービスエンティティの前記共有鍵材料および前記一時識別情報に従って前記共有される派生鍵を計算するように構成されることを特徴とする請求項26に記載の認証センタ。
【請求項１】
サービスを要求する第1サービスエンティティと、前記サービスを提供する第2サービスエンティティと、エンティティ認証センタすなわちEACとを具備するシステムに適用される、モバイルネットワークに基づくエンドツーエンド通信において認証を行う方法であって、
前記第1サービスエンティティと前記EACとの間で認証モードをネゴシエートする段階であって、前記ネゴシエートされた認証モードは、前記第1サービスエンティティと前記EACとの間の認証機構と、前記第2サービスエンティティと前記EACとの間の認証機構と、認証問合せの機構と、派生鍵を生成する機構と、前記第1サービスエンティティと前記第2サービスエンティティとの間の認証機構とを含む、段階と、
前記ネゴシエートされた認証モードに含まれる前記第1サービスエンティティと前記EACとの間の前記認証機構に従って前記EACと前記第1サービスエンティティとの間で相互認証を実行し、前記ネゴシエートされた認証モードに含まれる前記第2サービスエンティティと前記EACとの間の前記認証機構に従って前記EACと前記第2サービスエンティティとの間で相互認証を実行する段階と、
前記第1サービスエンティティが、前記サービスを提供するように前記第2サービスエンティティに要求する場合に、前記EACが、前記ネゴシエートされた認証モードに含まれる認証問合せの前記機構に従って前記第1サービスエンティティおよび前記第2サービスエンティティに関する認証問合せを提供し、前記ネゴシエートされた認証モードに含まれる派生鍵を生成する前記機構に従って前記第1サービスエンティティと前記第2サービスエンティティとの間の通信を保護する共有される派生鍵を生成する段階と、
前記第1サービスエンティティおよび前記第2サービスエンティティが、前記共有される派生鍵、および前記ネゴシエートされた認証モードに含まれる前記第1サービスエンティティと前記第2サービスエンティティとの間の前記認証機構に従って互いを認証し、前記サービスを保護するセッション鍵を生成する段階と
を有することを特徴とする方法。
【請求項２】
前記第1サービスエンティティによって、前記EACと認証モードをネゴシエートする段階は、
前記第1サービスエンティティによって、認証要求を前記EACに送信する段階であって、前記認証要求は、前記第1サービスエンティティの識別情報および現在要求されているサービスのタイプを伝える、段階と、
前記EACが、現在要求されている前記サービスの前記タイプに従って前記サービスを提供する前記第2サービスエンティティを判定し、前記第1サービスエンティティおよび前記第2サービスエンティティの認証機能を獲得し、前記第1サービスエンティティおよび前記第2サービスエンティティの前記認証機能に従って前記認証モードを選択する段階と
を有することを特徴とする請求項1に記載の方法。
【請求項３】
前記認証モードは、前記第1サービスエンティティと前記第2サービスエンティティとの間のセッション鍵を生成する機構をさらに含み、
前記サービスを保護する前記セッション鍵を生成する段階は、前記ネゴシエートされた認証モードに含まれる前記第1サービスエンティティと前記第2サービスエンティティとの間の前記セッション鍵を生成する前記機構に従って前記セッション鍵を生成する段階を有することを特徴とする請求項1に記載の方法。
【請求項４】
前記EACと前記第1サービスエンティティとの間で前記相互認証を実行する段階は、
前記EACおよび前記第1サービスエンティティによって互いを認証する段階と、
前記EACによって前記第1サービスエンティティの一時識別情報を割り振る段階と、
前記EACおよび前記第1サービスエンティティが、それぞれ、それらの間での通信を保護する共有鍵材料を獲得し、前記獲得された共有鍵材料と共に前記割り振られた一時識別情報を格納する段階と
を有し、
前記EACと前記第2サービスエンティティとの間で前記相互認証を実行する段階は、
前記EACおよび前記第2サービスエンティティによって互いを認証する段階と、
前記EACによって前記第2サービスエンティティの一時識別情報を割り振る段階と、
前記EACおよび前記第2サービスエンティティが、それぞれ、それらの間での通信を保護する共有鍵材料を獲得し、前記獲得された共有鍵材料と共に前記割り振られた一時識別情報を格納する段階と
を有し、
前記EACが、前記第1サービスエンティティおよび前記第2サービスエンティティに関する認証問合せを提供し、前記第1サービスエンティティと前記第2サービスエンティティとの間の通信を保護する共有される派生鍵を生成する段階は、
前記EACが、前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って前記第1サービスエンティティおよび前記第2サービスエンティティの権限を認証する段階と、
前記EACが、前記EACと前記第1サービスエンティティとの間の前記通信を保護する前記共有鍵材料、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記第1サービスエンティティと前記第2サービスエンティティとの間の前記通信を保護する前記共有される派生鍵を計算する段階と、
前記EACが、前記共有される派生鍵を前記第2サービスエンティティに転送する段階と、
前記第2サービスエンティティが、前記第1サービスエンティティの前記一時識別情報、前記共有される派生鍵、および現在要求されている前記サービスの前記タイプを関連付ける段階と、
前記第2サービスエンティティが、前記関連付けられた前記第1サービスエンティティの前記一時識別情報、前記共有される派生鍵、および現在要求されている前記サービスの前記タイプを格納する段階と、
前記第1サービスエンティティが、前記EACとの前記通信を保護する前記共有鍵材料、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算する段階と
を有することを特徴とする請求項1に記載の方法。
【請求項５】
前記共有される派生鍵、前記共有鍵材料、および前記一時識別情報のそれぞれは、寿命を有し、
前記方法は、
前記EACによって、その前記寿命が満了しようとしているかまたは満了した前記共有鍵材料または前記一時識別情報に対応する前記第1サービスエンティティおよび/または前記第2サービスエンティティに、再認証手順を開始しなければならないことを通知する段階、
その前記寿命が満了しようとしているかまたは満了した前記共有鍵材料または前記一時識別情報に対応する前記第1サービスエンティティおよび/または前記第2サービスエンティティによって、前記EACに対する前記再認証手順を開始する段階、
前記EACによって、その前記寿命が満了しようとしているかまたは満了した前記共有される派生鍵に対応する前記第1サービスエンティティに、前記再認証手順を開始しなければならないことを通知する段階、
および/または、
前記第2サービスエンティティによって、前記第1サービスエンティティと前記第2サービスエンティティとの間の前記通信を保護する前記共有される派生鍵の前記寿命または前記第1サービスエンティティの前記一時識別情報の前記寿命が満了しようとしているかまたは満了した場合に、前記再認証手順を開始しなければならないことを前記第1サービスエンティティに通知する段階
をさらに有することを特徴とする請求項4に記載の方法。
【請求項６】
サービスエンティティおよびEACに適用される、サービスエンティティを認証する方法であって、
前記サービスエンティティと前記EACとの間で認証モードをネゴシエートする段階であって、前記ネゴシエートされた認証モードは、前記サービスエンティティと前記EACとの間の認証機構を含む、段階と、
前記ネゴシエートされた認証モードに含まれる前記認証機構に従って前記サービスエンティティと前記EACとの間で相互認証を実行する段階と
を有することを特徴とする方法。
【請求項７】
前記サービスエンティティによって前記EACと認証モードをネゴシエートする前記段階は、
前記サービスエンティティによって、前記EACに認証要求を送信する段階であって、前記認証要求は、前記サービスエンティティの識別情報および現在要求されているサービスのタイプを伝える、段階と、
前記EACが、現在要求されている前記サービスの前記タイプに従って前記サービスを提供するサービスエンティティを判定し、前記認証要求を送信する前記サービスエンティティおよび前記サービスを提供する前記サービスエンティティの認証機能を獲得し、前記2つのサービスエンティティの前記認証機能に従って前記認証モードを選択する段階と
を有することを特徴とする請求項6に記載の方法。
【請求項８】
前記認証要求を送信する前記サービスエンティティおよび前記サービスを提供する前記サービスエンティティの認証機能を獲得する前記段階は、
前記EACが、前記認証要求から前記認証要求を送信する前記サービスエンティティの前記認証機能を獲得し、前記サービスを提供する前記サービスエンティティを判定した後に、前記サービスを提供する前記サービスエンティティのサブスクリプションデータを問い合わせることによって、前記サービスを提供する前記サービスエンティティの前記識別情報に従って前記サービスを提供する前記サービスエンティティの前記認証機能を獲得する段階、
または、
前記EACが、前記サービスを提供する前記サービスエンティティの前記サブスクリプションデータを問い合わせることによって、前記認証要求を送信する前記サービスエンティティの前記識別情報に従って前記認証要求を送信する前記サービスエンティティの前記認証機能を獲得し、前記サービスを提供する前記サービスエンティティを判定した後に、前記サービスを提供する前記サービスエンティティの前記サブスクリプションデータを問い合わせることによって前記サービスを提供する前記サービスエンティティの前記認証機能を獲得する段階
を有することを特徴とする請求項7に記載の方法。
【請求項９】
前記サービスエンティティと前記EACとの間で相互認証を実行する段階は
前記サービスエンティティおよび前記EACが、互いを認証し、それぞれ、前記サービスエンティティと前記EACとの間の前記通信を保護する共有鍵材料を獲得する段階と、
前記EACによって、前記サービスエンティティの一時識別情報を割り振る段階と、
前記EACおよび前記サービスエンティティが、それぞれ、前記獲得された共有鍵材料と共に前記割り振られた一時識別情報を格納する段階と
を有することを特徴とする請求項6に記載の方法。
【請求項１０】
前記共有鍵材料および前記一時識別情報のそれぞれは、寿命を有し、
前記方法は、
前記EACによって、前記共有鍵材料または前記一時識別情報の前記寿命が満了しようとしているかまたは満了した場合に再認証手順を開始しなければならないことを前記サービスエンティティに通知する段階、
および/または、
前記サービスエンティティによって、前記共有鍵材料または前記一時識別情報の前記寿命が満了しようとしているかまたは満了した場合に、前記EACに対する前記再認証手順を開始する段階と
をさらに有することを特徴とする請求項9に記載の方法。
【請求項１１】
サービスを要求する第1サービスエンティティと、前記サービスを提供する第2サービスエンティティと、EACとを具備するシステムに適用される、認証問合せの方法であって、
前記第1サービスエンティティと前記EACとの間の相互認証と、前記第2サービスエンティティと前記EACとの間の相互認証とが、それぞれ実行され、
前記EACは、前記第1サービスエンティティおよび前記第2サービスエンティティの一時識別情報をそれぞれ割り振り、前記第1サービスエンティティおよび前記第2サービスエンティティとの通信を保護する共有鍵材料をそれぞれ獲得し、
前記第1サービスエンティティは、認証問合せの機構および派生鍵を生成する機構を含む認証モードを前記EACとネゴシエートし、
前記方法は、
前記第1サービスエンティティが、前記第2サービスエンティティによって提供される前記サービスを要求する場合に、前記ネゴシエートされた認証モードに含まれる認証問合せの前記機構に従って、前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って前記第1サービスエンティティおよび前記第2サービスエンティティの権限を認証する段階と、
前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報、ならびに前記第1サービスエンティティとの通信を保護する前記共有鍵材料に従って、前記第1サービスエンティティと前記第2サービスエンティティとの間の通信を保護する共有される派生鍵を計算する段階と
を有することを特徴とする方法。
【請求項１２】
前記EACが、前記ネゴシエートされた認証モードに含まれる認証問合せの前記機構に従って、それぞれ前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って前記第1サービスエンティティおよび前記第2サービスエンティティの前記権限をそれぞれ認証し、前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記第1サービスエンティティとの前記通信を保護する前記共有鍵材料、ならびに前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算し、前記計算された共有される派生鍵を前記第2サービスエンティティに転送する段階と、
前記第2サービスエンティティが、前記共有される派生鍵および現在要求されている前記サービスの前記タイプと共に、前記第1サービスエンティティの前記一時識別情報を格納する段階と、
前記第1サービスエンティティによって、前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記EACとの前記通信を保護する前記共有鍵材料、ならびに前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算する段階と
を有することを特徴とする請求項11に記載の方法。
【請求項１３】
前記第2サービスエンティティに前記サービスを要求する場合に前記第1サービスエンティティの前記一時識別情報を前記第1サービスエンティティによって前記第2サービスエンティティに提供する段階と、
前記第2サービスエンティティの前記一時識別情報および前記第1サービスエンティティの前記一時識別情報を前記第2サービスエンティティによって前記EACに提供する段階と、
前記EACが、前記ネゴシエートされた認証モードに含まれる認証問合せの前記機構に従って、それぞれ前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って前記第1サービスエンティティおよび前記第2サービスエンティティの前記権限をそれぞれ認証し、前記第1サービスエンティティとの前記通信を保護する前記共有鍵材料、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算し、前記計算された共有される派生鍵を前記第2サービスエンティティに転送する段階と、
前記第2サービスエンティティによって、前記共有される派生鍵および現在要求されている前記サービスの前記タイプと共に前記第1サービスエンティティの前記一時識別情報を格納する段階と、
前記第1サービスエンティティによって、前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記EACとの前記通信を保護する前記共有鍵材料、ならびに前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算する段階と
を有することを特徴とする請求項11に記載の方法。
【請求項１４】
サービス許可チケットすなわちSGTを前記EACに要求する場合に、前記第1サービスエンティティの前記一時識別情報および現在要求されている前記サービスのタイプを前記第1サービスエンティティによって前記EACに提供する段階と、
前記EACが、前記第1サービスエンティティの前記一時識別情報に従って前記第1サービスエンティティの前記権限を認証し、前記サービスの前記タイプに従って前記第2サービスエンティティの前記一時識別情報を獲得し、前記第2サービスエンティティの前記一時識別情報に従って前記第2サービスエンティティの前記権限を認証し、前記第1サービスエンティティとの前記通信を保護する前記共有鍵材料、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算し、前記計算された共有される派生鍵、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報を含む前記SGTを生成し、前記生成されたSGTを前記第1サービスエンティティに送信する段階と、
前記第1サービスエンティティが、前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記EACとの前記通信を保護する前記共有鍵材料、ならびに前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算し、前記第2サービスエンティティに前記サービスを要求する場合に前記EACから送信された前記SGTを前記第2サービスエンティティに提供する段階と、
前記第2サービスエンティティが、前記第1サービスエンティティによって提供された前記SGTから前記共有される派生鍵を獲得し、前記共有される派生鍵および現在要求されている前記サービスの前記タイプと共に前記第1サービスエンティティの前記一時識別情報を格納する段階と
を有することを特徴とする請求項11に記載の方法。
【請求項１５】
前記EACにサービス要求を送信する場合に、前記第1サービスエンティティの前記一時識別情報および現在要求されている前記サービスのタイプを前記第1サービスエンティティによって前記EACに提供する段階と、
前記EACが、前記第1サービスエンティティの前記一時識別情報に従って前記第1サービスエンティティの前記権限を認証し、現在要求されている前記サービスの前記タイプに従って前記第2サービスエンティティに前記サービス要求を転送する段階と、
前記第2サービスエンティティの前記一時識別情報を前記第2サービスエンティティによって前記EACに返す段階と、
前記EACが、前記第2サービスエンティティの前記一時識別情報に従って前記第2サービスエンティティの前記権限を認証し、前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記第1サービスエンティティとの前記通信を保護する前記共有鍵材料、ならびに前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算し、前記計算された共有される派生鍵を前記第2サービスエンティティに送信する段階と、
前記共有される派生鍵および現在要求されている前記サービスの前記タイプと共に前記第1サービスエンティティの前記一時識別情報を前記第2サービスエンティティによって格納する段階と、
前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構、前記EACとの前記通信を保護する前記共有鍵材料、ならびに前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を前記第1サービスエンティティによって計算する段階と
を有することを特徴とする請求項11に記載の方法。
【請求項１６】
前記EACが前記共有される派生鍵を前記第2サービスエンティティに転送する時に、前記方法は、前記第2サービスエンティティとの前記通信を保護するために、前記通信を保護する前記共有鍵材料を前記EACによって使用する段階をさらに有することを特徴とする請求項11から15のいずれか一項に記載の方法。
【請求項１７】
サービスを要求する第1サービスエンティティと、サービスを提供する第2サービスエンティティと、EACとを具備するモバイルネットワークに基づくエンドツーエンド通信において認証を行うシステムであって、
前記第1サービスエンティティは、認証に関係する少なくとも1つの機構を含む認証モードを前記EACとネゴシエートし、前記ネゴシエートされた認証モードに従って前記第1サービスエンティティと前記EACとの間で相互認証を実行し、前記第2サービスエンティティにサービスを要求し、前記ネゴシエートされた認証モードに従って、前記第1サービスエンティティと前記第2サービスエンティティとの間の通信を保護する共有される派生鍵に従って前記第1サービスエンティティと前記第2サービスエンティティとの間で相互認証を実行するように構成され、
前記第2サービスエンティティは、前記ネゴシエートされた認証モードに従って前記EACを認証し、前記第1サービスエンティティが前記サービスを要求する場合に前記ネゴシエートされた認証モードに従って前記第1サービスエンティティと前記第2サービスエンティティとの間の前記通信を保護する前記共有される派生鍵に従って前記第1サービスエンティティと前記第2サービスエンティティとの間で前記相互認証を実行するように構成され、
前記EACは、前記ネゴシエートされた認証モードに従って、前記EACと前記第1サービスエンティティとの間の前記相互認証と、前記EACと前記第2サービスエンティティとの間の相互認証とをそれぞれ実行し、前記第1サービスエンティティが前記サービスを要求する時に、前記ネゴシエートされた認証モードに従って前記第1サービスエンティティおよび前記第2サービスエンティティに関する認証問合せを提供し、前記第1サービスエンティティと前記第2サービスエンティティとの間の前記通信を保護する前記共有される派生鍵を生成するように構成されることを特徴とするシステム。
【請求項１８】
サービスエンティティのサブスクリプションデータを格納するデータベースをさらに具備し、
前記EACは、前記認証モードをネゴシエートする場合に、前記第1サービスエンティティおよび前記第2サービスエンティティの認証機能を獲得するために前記第1サービスエンティティおよび前記第2サービスエンティティの識別情報に従って前記データベースに問い合わせ、前記第1サービスエンティティおよび前記第2サービスエンティティの前記獲得された認証機能に従って前記認証モードを選択するようにさらに構成されることを特徴とする請求項17に記載のシステム。
【請求項１９】
前記EACは、前記EACと前記第1サービスエンティティとの間の前記相互認証と、前記EACと前記第2サービスエンティティとの間の前記相互認証とをそれぞれ実行する時に、それぞれ、前記第1サービスエンティティおよび前記第2サービスエンティティの一時識別情報を割り振り、前記第1サービスエンティティおよび前記第2サービスエンティティとの通信を保護する共有鍵材料を獲得し、前記第1サービスエンティティおよび前記第2サービスエンティティに関する前記認証問合せを提供する時に、前記ネゴシエートされた認証モードに従って、前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報、および前記第1サービスエンティティとの前記通信を保護する前記共有鍵材料に従って、前記第1サービスエンティティと前記第2サービスエンティティとの間の前記通信を保護する前記共有される派生鍵を計算し、前記共有される派生鍵を前記第2サービスエンティティに転送するように構成され、
前記第1サービスエンティティは、前記サービスを要求する時に、前記ネゴシエートされた認証モードに従って、前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報、および前記EACとの前記通信を保護する前記共有鍵材料に従って、前記共有される派生鍵を計算するように構成され、
前記第2サービスエンティティは、前記EACによって返された前記共有される派生鍵および前記第1サービスエンティティによって要求された前記サービスの前記タイプと共に前記第1サービスエンティティの前記一時識別情報を格納するようにさらに構成されることを特徴とする請求項17に記載のシステム。
【請求項２０】
サービスエンティティおよびEACを具備する、サービスエンティティを認証するシステムであって、
前記サービスエンティティは、前記サービスエンティティと前記EACとの間の認証機構を含む認証モードを前記EACとネゴシエートし、前記ネゴシエートされた認証モードに含まれる前記認証機構に従って前記サービスエンティティと前記EACとの間で相互認証を実行するように構成されることを特徴とするシステム。
【請求項２１】
サービスエンティティのサブスクリプションデータを格納するデータベースをさらに具備し、
前記EACは、前記認証モードをネゴシエートする時に、サービスを要求するサービスエンティティおよび前記サービスを提供するサービスエンティティの識別情報に従って前記データベースに問い合わせ、前記2つのサービスエンティティの認証機能を獲得し、前記2つのサービスエンティティの前記認証機能に従って前記認証モードを選択するようにさらに構成されることを特徴とする請求項20に記載のシステム。
【請求項２２】
サービスを要求する第1サービスエンティティ、前記サービスを提供する第2サービスエンティティ、およびEACを具備する、認証問合せのシステムであって、
前記第1サービスエンティティは、認証問合せの機構および派生鍵を生成する機構を含む認証モードを前記EACとネゴシエートするように構成され、
前記EACは、前記第1サービスエンティティが前記サービスを要求する時に、前記ネゴシエートされた認証モードに含まれる認証問合せの前記機構に従って、前記第1サービスエンティティおよび前記第2サービスエンティティの権限を認証し、前記ネゴシエートされた認証モードに含まれる前記派生鍵を生成する前記機構に従って、前記第1サービスエンティティと前記第2サービスエンティティとの間の通信を保護する共有される派生鍵を生成するように構成されることを特徴とするシステム。
【請求項２３】
前記EACは、前記第1サービスエンティティおよび前記第2サービスエンティティの一時識別情報に従って前記第1サービスエンティティおよび前記第2サービスエンティティの前記権限を認証し、前記第1サービスエンティティとの通信を保護する共有鍵材料、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算し、前記計算された共有される派生鍵を前記第2サービスエンティティに転送するように構成され、
前記第1サービスエンティティは、前記EACとの前記通信を保護する前記共有鍵材料、および前記第1サービスエンティティおよび前記第2サービスエンティティの前記一時識別情報に従って、前記共有される派生鍵を計算するように構成され、
前記第2サービスエンティティは、前記EACによって返された前記共有される派生鍵および要求された前記サービスのタイプと共に前記第1サービスエンティティの前記一時識別情報を格納するように構成されることを特徴とする請求項22に記載のシステム。
【請求項２４】
認証センタであって、
サービスエンティティの認証モードをネゴシエートするように構成された第1モジュールであって、前記認証モードは、前記サービスエンティティと前記認証センタとの間の認証機構を含む、第1モジュールと、
前記第1モジュールによってネゴシエートされた前記認証モードに含まれる前記認証機構に従って前記サービスエンティティを認証するように構成された第2モジュールと
を具備することを特徴とする認証センタ。
【請求項２５】
前記第1モジュールは、
サービスを要求するサービスエンティティおよび前記サービスを提供するサービスエンティティの認証機能をそれぞれ獲得するためにサブスクリプションデータを問い合わせるように構成された第1サブモジュールと、
前記サービスを要求する前記サービスエンティティおよび前記サービスを提供する前記サービスエンティティの前記認証機能に従って認証モードを選択するように構成された第2サブモジュールであって、前記認証機能は、前記第1モジュールによって獲得される、第2サブモジュールと
を具備することを特徴とする請求項24に記載の認証センタ。
【請求項２６】
前記認証モードは、認証問合せの機構および派生鍵を生成する機構をさらに含み、
前記認証センタは、
前記サービスエンティティが前記サービスを要求する時に、前記サービスを要求する前記サービスエンティティおよび前記サービスを提供する前記サービスエンティティに関する認証問合せを提供し、前記第1モジュールによってネゴシエートされた前記認証モードに含まれる認証問合せの前記機構および前記派生鍵を生成する前記機構に従って、前記2つのサービスエンティティの間の通信を保護する前記共有される派生鍵を計算するように構成された第3モジュールをさらに具備することを特徴とする請求項24または25に記載の認証センタ。
【請求項２７】
前記第2モジュールは、前記2つのサービスエンティティの共有鍵材料および一時識別情報を生成するように構成され、
前記第3モジュールは、前記第2モジュールによって生成された前記2つのサービスエンティティの前記共有鍵材料および前記一時識別情報に従って前記共有される派生鍵を計算するように構成されることを特徴とする請求項26に記載の認証センタ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公表番号】特表２００９−５２４３６９（Ｐ２００９−５２４３６９Ａ）
【公表日】平成２１年６月２５日（２００９．６．２５）
【国際特許分類】
【出願番号】特願２００８−５５１６２９（Ｐ２００８−５５１６２９）
【出願日】平成１８年１２月２６日（２００６．１２．２６）
【国際出願番号】ＰＣＴ／ＣＮ２００６／００３６０１
【国際公開番号】ＷＯ２００７／０８５１７５
【国際公開日】平成１９年８月２日（２００７．８．２）
【出願人】（５０４２７７３８８）▲ホア▼▲ウェイ▼技術有限公司 (220)
【Ｆターム（参考）】
【公表日】平成２１年６月２５日（２００９．６．２５）
【国際特許分類】
【出願日】平成１８年１２月２６日（２００６．１２．２６）
【国際出願番号】ＰＣＴ／ＣＮ２００６／００３６０１
【国際公開番号】ＷＯ２００７／０８５１７５
【国際公開日】平成１９年８月２日（２００７．８．２）
【出願人】（５０４２７７３８８）▲ホア▼▲ウェイ▼技術有限公司 (220)
【Ｆターム（参考）】
[ Back to top ]