ＵＩＣＣと端末との間のセキュア通信方法
本発明は、ワイヤレス通信システムに関する。３Ｇ ＵＭＴＳ携帯電話システムは、３Ｇモバイル端末とＵＭＴＳワイヤレスネットワーク（またはＵＴＲＡＮ）との間の通信経路をセキュアにするさまざまなセキュリティ手段の基礎またはルートとしてＵＳＩＭ（ＵＭＴＳ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）アプリケーションを提供するＵＭＴＳ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ（ＵＩＣＣ）と呼ばれるセキュアにされたスマートカードに依存する。例えば、内部鍵センター（ＩＫＣ １２５０）およびＢｏｏｔｓｔｒａｐｐｉｎｇ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ（ＢＳＦ １２７０）は、アプリケーションおよびＮＡＦ（ｎｅｔｗｏｒｋ ａｐｐｌｉｃａｔｉｏｎ ｆｕｎｃｔｉｏｎ）に固有の複数のローカル鍵（Ｋｓ＿ｌｏｃａｌ）が認証のために、そしてメッセージの暗号化および暗号化解除に使用される手順を可能にするなど、ＵＩＣＣによる端末と情報を交換する方法を開示する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワイヤレス通信に関し、より詳細には、ＵＩＣＣと端末との間のセキュア通信方法に関する。
【背景技術】
【０００２】
ＵＭＴＳセルラーワイヤレス通信システムのＲｅｌｅａｓｅ ７において、標準化制定団体３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）は、既存のＡＫＡ（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ ｋｅｙ ａｇｒｅｅｍｅｎｔ）処理を強化する技術仕様ＴＳ ３３．２２０−７８０を起草した。ＴＳ ３３．２２０に記載された、より新しいＡＫＡ処理は、ＵＩＣＣ（ＵＭＴＳ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）およびＨＬＲ／ＨＳＳ（Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ／Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｙｓｔｅｍ）を組み入れるＷＴＲＵ（ｗｉｒｅｌｅｓｓ ｔｒａｎｓｍｉｔ／ｒｅｃｅｉｖｅ ｕｎｉｔ）を伴う処理を指定する。
【０００３】
図１は、ＡＫＡ処理に対して想像されたネットワーク要素およびそれぞれのインターフェースを示す。ＢＳＦ（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ）は、ＭＮＯ（ｍｏｂｉｌｅ ｎｅｔｗｏｒｋ ｏｐｅｒａｔｏｒ）の制御の下にあり、ＷＴＲＵおよびＨＳＳといっしょにＧＢＡ＿Ｕ（ＵＩＣＣベースの強化を伴うＧＢＡ（ｇｅｎｅｒｉｃ ｂｏｏｔｓｔｒａｐｐｉｎｇ ａｒｃｈｉｔｅｃｔｕｒｅ））に加わって、ネットワークとＷＴＲＵとの間の共有秘密を確立するネットワーク要素の一部である。ＮＡＦ（ｎｅｔｗｏｒｋ ａｐｐｌｉｃａｔｉｏｎ ｆｕｎｃｔｉｏｎ）は、ネットワーク要素の一部としてホスティングされて、ＷＴＲＵとＮＡＦとの間の通信経路をセキュアにする鍵を導出するために、ＧＢＡによって確立された共有秘密を使用する。ＳＬＦ（ｓｕｂｓｃｒｉｂｅｒ ｌｏｃａｔｉｏｎ ｆｕｎｃｔｉｏｎ）は、ＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｙｓｔｅｍ）の詳細を獲得するためにＢＳＦ（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ）によって使用され、このＨＳＳの詳細は、ＢＳＦが事前定義のＨＳＳによって構成または管理されないときに、必要な加入者固有データを含む。ＨＳＳは、すべてのＵＳＳ（ｕｓｅｒ ｓｅｃｕｒｉｔｙ ｓｅｔｔｉｎｇ）を格納して、加入者は、ＵＩＣＣ上に複数のＩＳＩＭ（ＩＰ ｍｕｌｔｉｍｅｄｉａ ｓｅｒｖｉｃｅｓ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）アプリケーションかＵＳＩＭ（ｕｓｅｒ ｓｅｒｖｉｃｅｓ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）アプリケーションかのどちらかを有する。ＨＳＳは、１つまたは複数のプライベートアイデンティティにマッピングできる１つまたは複数のＧＵＳＳ（ＧＢＡ ｕｓｅｒ ｓｅｃｕｒｉｔｙ ｓｅｔｔｉｎｇ）を含むことができる。Ｕｂは、ＷＴＲＵとＢＳＦとの間の参照点を指す。ＷＴＲＵとＢＳＦとの間の相互認証手順は、この参照点で行われて、セッション鍵は、３ＧＰＰ ＡＫＡインフラストラクチャに基づいてブートストラップされる。Ｕａは、ＷＴＲＵと、アプリケーションプロトコルを保持するＮＡＦとの間の参照点であり、参照点Ｕｂを通じたＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡの結果としてＷＴＲＵとＢＳＦとの間で一致の鍵材料に基づいて鍵を導出することによってセキュアにされる。Ｚｎは、ＮＡＦとＢＳＦとの間の参照点であり、（以前のＵｂを通じたＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡプロトコル中に一致の）鍵材料およびアプリケーション固有のＵＳＳをＢＳＦから獲得するのにＮＡＦによって使用される。Ｚｈは、ＢＳＦとＨＳＳとの間の参照点であり、認証情報およびＧＵＳＳをＨＳＳから検索するのにＢＳＦによって使用される。Ｄｚは、ＢＳＦとＳＬＦとの間の参照点であり、加入者固有情報を含むＨＳＳの名前を検索するのにＢＳＦによって使用される。
【０００４】
２つの手順を、ＴＳ ３３．２２０において検討する。１つ目は、ＧＢＡ＿Ｕ（ＵＩＣＣによって強化されたＧＢＡ）処理であり、２つ目は、セキュリティアソシエーション（ＳＡ）処理である。
【０００５】
ＧＢＡ＿Ｕ処理において、ＵＩＣＣおよびＢＳＦは、互いを相互に認証して、ＵＩＣＣとＨＬＲ／ＨＳＳとの間において共有される加入者認証鍵Ｋから導出することによって、ＧＢＡ＿Ｕ鍵と呼ばれる鍵Ｋｓを確立する。
【０００６】
図２を参照しながら、ＧＢＡ＿Ｕ処理のステップを示して、さらに、次のように説明する。ＭＥは、ステップＳ１において、ＧＢＡ＿Ｕ処理を開始するためにＨＴＴＰ要求をＢＳＦに送信する。ＭＥは、ＨＴＴＰ要求のｕｓｅｒｎａｍｅパラメーターフィールドにユーザーアイデンティティ（ＴＭＰＩ（ｔｅｍｐｏｒａｒｙ ＩＰ ｍｕｌｔｉｍｅｄｉａ ｐｒｉｖａｔｅ ｉｄｅｎｔｉｔｙ）またはＩＭＰＩ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｐｒｉｖａｔｅ Ｉｄｅｎｔｉｔｙ））を挿入する。ＢＳＦは、ステップＳ２において、認証ベクトル（ＡＶ＝ＲＡＮＤ‖ＡＵＴＮ‖ＸＲＥＳ‖ＣＫ‖ＩＫ）およびＧＵＳＳ（ＧＢＡ ｕｓｅｒ ｓｅｃｕｒｉｔｙ ｓｅｔｔｉｎｇ）をＨＬＲ／ＨＳＳから（参照点Ｚｈを通じて）とってくる。ただし、
【０００７】
【数１】
【０００８】
である。次に、ＢＳＦは、ＭＡＣ*
【０００９】
【数２】
【００１０】
を計算する。ＭＡＣは、ＲＡＮＤおよびＡＵＴＮの保全性をセキュアにするのに使用される。ＢＳＦは、ステップＳ３において、ＨＴＴＰ ４０１ Ｕｎａｕｔｈｏｒｉｚｅｄ ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ： Ｄｉｇｅｓｔメッセージにて、ＲＡＮＤおよびＡＵＴＮ*（＝ＳＱＮ ｘｏｒ ＡＫ‖ＡＭＦ‖ＭＡＣ*）をＭＥに転送し、ＸＲＥＳ、ＣＫ、およびＩＫを格納する。ＭＥは、ステップＳ４において、受信したＲＡＮＤおよびＡＵＴＮ*を、ＨＴＴＰ ４０１ Ｕｎａｕｔｈｏｒｉｚｅｄ ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ： ＤｉｇｅｓｔメッセージにてＵＩＣＣへ転送する。ＵＩＣＣは、ステップＳ５において、ＡＫＡアルゴリズムを実行する、すなわち、ＩＫおよびＸＭＡＣを計算し、次に、ＵＩＣＣは、ＡＵＴＮ（すなわち、
【００１１】
【数３】
【００１２】
）を検査して、チャレンジが認証されたネットワークからであることを検証する。すなわち、ＵＩＣＣは、ＣＫおよびＲＥＳをさらに計算する。これは、セッション鍵ＣＫおよびＩＫの作成に帰着する。ただし、ＢＳＦとＵＩＣＣとの両方においてＫｓ＝ＣＫ‖ＩＫである。ＵＩＣＣは、ステップＳ６において、ＲＥＳをＭＥへ転送する。ＭＥは、ステップＳ７において、別のＨＴＴＰ要求をＢＳＦへ送信し、このＨＴＴＰ要求は、ＲＥＳを使用して計算されたＤｉｇｅｓｔ ＡＫＡレスポンスを含む。ＢＳＦは、ステップＳ８において、受信したＲＥＳをＸＲＥＳと比較することによって、ＵＥの信頼性を検証して、ステップＳ９において、Ｋｓ＝ＣＫ‖ＩＫおよびブートストラッピングトランザクション識別子（Ｂ−ＴＩＤ）を作成する。ＢＳＦは、ステップＳ１０において、認証の成功を示すために、Ｂ−ＴＩＤおよびＫｅｙ Ｌｉｆｅｔｉｍｅを含む２００ ＯＫメッセージを送り返す。ＭＥは、ステップＳ１１において、Ｂ−ＴＩＤおよびＫｅｙ ＬｉｆｅｔｉｍｅをＵＩＣＣへ送信する。ＵＩＣＣは、ステップＳ１２において、Ｋｓ＝ＣＫ‖ＩＫ、Ｂ−ＴＩＤおよびＫｅｙ Ｌｉｆｅｔｉｍｅを格納する。
【００１３】
図２に示されたＧＢＡ＿Ｕ処理の終わりに、ＵＩＣＣとＢＳＦとの両方が、例えばセキュリティ・アソシエーション・ステージなどのより後のステージに必要な場合に、それぞれ、ＮＡＦ（Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｆｕｎｃｔｉｏｎ）固有鍵Ｋｓ＿ｅｘｔ＿ＮＡＦおよびＫｓ＿ｉｎｔ＿ＮＡＦを導出するのに、それらの両方が有しているＫｓを使用できる状態にある。これらの導出された鍵Ｋｓ＿ｅｘｔ＿ＮＡＦおよびＫｓ＿ｉｎｔ＿ＮＡＦは、後に、参照点Ｕａをセキュアにするのに使用される。Ｋｓ＿ｅｘｔ＿ＮＡＦは、ＵＩＣＣにおいて、Ｋｓ＿ｅｘｔ＿ＮＡＦ＝ＫＤＦ（Ｋｓ，“ｇｂａ−ｍｅ”，ＲＡＮＤ，ＩＭＰＩ，ＮＡＦ＿Ｉｄ）として計算され、Ｋｓ＿ｉｎｔ＿ＮＡＦは、ＵＩＣＣにおいて、Ｋｓ＿ｉｎｔ＿ＮＡＦ＝ＫＤＦ（Ｋｓ，“ｇｂａ−ｕ，ＲＡＮＤ，ＩＭＰＩ，ＮＡＦ＿Ｉｄ）として計算される。すなわち、ＮＡＦ＿Ｉｄ＝ＮＡＦのＦＱＤＮ‖Ｕａセキュリティプロトコル識別子である。ＫＤＦは、ＴＳ ３３．２２０−７８０ Ａｎｎｅｘ Ｂに指定された鍵導出関数である。
【００１４】
ＫｓがＧＢＡ＿Ｕ処理において確立された後に、セキュリティアソシエーション処理が、ＮＡＦとＷＴＲＵとの間で行われる。セキュリティアソシエーション処理の目的は、ＷＴＲＵおよびＮＡＦが、ＧＢＡ鍵（Ｋｓ＿ｉｎｔ＿ＮＡＦおよび／またはＫｓ＿ｅｘｔ＿ＮＡＦ）を使用するかどうかを決定することである。デフォルトにより、Ｋｓ＿ｅｘｔ＿ＮＡＦは、ＷＴＲＵとＮＡＦとの間においてパケットを暗号化するのに使用される鍵ストリームを後に導出するのに使用される。しかし、Ｋｓ＿ｉｎｔ＿ＮＡＦまたはＫｓ ｉｎｔ＿ＮＡＦとＫｓ＿ｅｘｔ＿ＮＡＦとの両方が使用される場合には、これを、セキュリティアソシエーション処理において一致しなければならない。上記の一致が、デフォルト選択を覆すものであることを補足する。さらに、鍵選択指示を、アプリケーション固有ＵＳＳにおいて指定できる。
【００１５】
図３を参照するとセキュリティ・アソシエーション・ステップが示され、ＷＴＲＵ（ＭＥ）は、通信を開始する前に、（ＧＢＡ＿Ｕによって作成された）Ｋｓが現存して最新であることを検査し、そうでない場合には、ＧＢＡ＿Ｕを初期化して、Ｋｓを作成する。Ｋｓが有効であって最新である場合には、ＭＥは、ステップＳ１において、ＵＩＣＣからＢ−ＴＩＤを取り出し、ＵＩＣＣは、Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦ鍵を導出する。ＭＥは、ステップＳ２において、アプリケーション要求の一部としてＢ−ＴＩＤをＮＡＦに送信する。ＮＡＦは、ステップＳ３において、認証要求（Ｂ−ＴＩＤおよびＮＡＦ−ＩＤを含む）をＢＳＦに送信して、Ｚｎ参照点を介してＢ−ＴＩＤに対応する鍵を送信する。ＢＳＦは、ステップＳ４において、Ｋｓ＿ｉｎｔ＿ＮＡＦおよびＫｓ＿ｅｘｔ＿ＮＡＦを導出する。ＮＡＦは、ＧＢＡ＿Ｕ対応である場合に、ステップＳ４において両方の鍵を送付し、そうでない場合には、例えばブートストラップ時刻、鍵の有効期間等のある他の情報と一緒にＫｓ＿ｅｘｔ＿ＮＡＦだけを供給する。次に、ＮＡＦは、ＵＳＳがＢＳＦから返される場合にはＵＳＳを調べて、鍵選択指示が存在するかどうかを検査し（存在する場合には、ＵＳＳ内で指示された鍵（１つまたは複数）が使用される）、これらの鍵（１つまたは複数）を格納する。ＮＡＦは、ステップＳ７において、ＮＡＦ鍵Ｋｓ＿ｅｘｔ／ｉｎｔ＿ＮＡＦを現在有していることを示すアプリケーション回答（Ａｐｐｌｉｃａｔｉｏｎ Ａｎｓｗｅｒ）をＷＴＲＵに送信する。
【００１６】
最近、３ＧＰＰ ＴＳ ３３．１１０−７００により、ＵＩＣＣと端末との間のプラットフォームおよびアプリケーション固有鍵Ｋｓ＿ｌｏｃａｌの確立を提案された。上記の鍵は、ＵＩＣＣと端末との間のチャネルをセキュアにするのに、ＵＩＣＣおよび端末によって使用されることを意図される。
【００１７】
図４において、端末がＵＩＣＣ保持デバイスの一部である場合の参照点のアーキテクチャを示す。図４のネットワーク要素は、ＵＩＣＣホスティングデバイスの提供を除いて、図１に示されたものと同一である。ＵＩＣＣと端末との間でＫｓ＿ｌｏｃａｌを確立するプロトコルフローを、図５に示す。端末は、ステップＳ１において、Ｂ−ＴＩＤおよび対応する有効期間をＵＩＣＣから取ってくることによって、有効なＫｓ鍵がＵＩＣＣ内に存在するかどうかを検査する。有効な鍵ｋｓがＵＩＣＣ内で使用可能ではない場合には、端末は、ＢＳＦとＵＩＣＣとの間でＫｓ鍵を確立するためにＧＢＡブートストラッピング手順を要求する。次に、端末は、有効なＫｓ＿ｉｎｔ＿ＮＡＦが存在するかどうかを検査し、そうである場合には、ＮＡＦ鍵センターに対応するＮＡＦ＿ＩＤのＢ−ＴＩＤ値を取り出すようにＵＩＣＣに要求する。端末は、ＮＡＦ＿ＩＤを有しない場合には、ステップＳ２においてその値を取り出すようにＵＩＣＣに要求する。ＵＩＣＣは、ステップＳ３において、ＮＡＦ鍵センターに対応するＮＡＦ＿ＩＤおよびＢ−ＴＩＤを戻す。端末およびＮＡＦ鍵センターは、ステップＳ４において、端末とＮＡＦ鍵センターとの間の証明書ベースの相互認証を用いて、ＨＴＴＰＳタイプのトンネルを確立する。端末は、ステップＳ５において、トンネルを介して「サービス要求」メッセージを送信し、このメッセージのペイロードは、Ｂ−ＴＩＤ、端末識別子（Ｔｅｒｍｉｎａｌ＿ＩＤ）、スマートカード識別子（ＩＣＣＩＤ）、鍵Ｋｓ＿ｌｏｃａｌの確立を必要とするＵＩＣＣアプリケーションのアプリケーション識別子（ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ）および端末アプリケーションのアプリケーション識別子（Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ）、ならびに変数値ＲＡＮＤｘを含む。アプリケーション固有鍵ではなくプラットフォーム固有鍵が望まれる場合には、パラメーターＵＩＣＣ＿ａｐｐｌｉ＿ＩＤおよびＴｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤは、静的ＡＳＣＩＩ符号化ストリング“ｐｌａｔｆｏｒｍ”と等しくなる。ＮＡＦ鍵センターは、ステップＳ６において、端末ＩＤ／ＩＣＣＩＤがブラックリストに載せられていないかどうか、または鍵確立手順がターゲットにされたアプリケーションについて許可されるかどうかを判定する。これらの条件が満足されない場合には、ＮＡＦ鍵センターは、適当なエラーコードを応答し、端末とのＴＬＳ接続を終了する。ＮＡＦ鍵センターは、ステップＳ６において、ＢＳＦに連絡し、Ｂ−ＴＩＤおよびそれ自体のＮＡＦ＿ＩＤを信用証明書要求内で送信する（この要求の目的は、関連する鍵Ｋｓ＿ｉｎｔ＿ＮＡＦおよびＫｓ＿ｅｘｔ＿ＮＡＦを返すようにＢＳＦに要求することである。Ｋｓ＿ｌｏｃａｌが、Ｋｓ＿ｉｎｔ＿ＮＡＦだけから生成されることに留意されたい）。ＢＳＦは、Ｋｓ＿ｉｎｔ＿ＮＡＦおよびＫｓ＿ｅｘｔ＿ＮＡＦを導出し、ステップＳ７において、これらの鍵および例えばブートストラップ時刻、鍵の有効期間等の関連情報をＮＡＦ鍵センターに戻す。ＮＡＦ鍵センターは、ステップＳ８において、ＵＩＣＣで使用される適切な１６オクテットのｃｏｕｎｔｅｒ ｌｉｍｉｔを生成して、端末において使用される導出された鍵Ｋｓ＿ｌｏｃａｌに鍵の有効期間を関連付ける。次に、ＮＡＦ鍵センターは、次のように鍵導出関数（ＫＤＦ）を使用して、Ｋｓ＿ｉｎｔ＿ＮＡＦからＫｓ＿ｌｏｃａｌを導出する。
Ｋｓ＿ｌｏｃａｌ＝ＫＤＦ（Ｋｓ＿ｉｎｔ＿ＮＡＦ，Ｂ−ＴＩＤ，Ｔｅｒｍｉｎａｌ＿ＩＤ，ＩＣＣＩＤ，Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ，ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ，ＲＡＮＤｘ，ｃｏｕｎｔｅｒ ｌｉｍｉｔ）
【００１８】
ステップＳ９において、ＮＡＦ鍵センターは、ステップＳ４において確立されたＨＴＴＰＳトンネルを介して、端末にＢ−ＴＩＤ、鍵の有効期間、およびｃｏｕｎｔｅｒ ｌｉｍｉｔと一緒にＫｓ＿ｌｏｃａｌを送付する。ステップＳ１０において、端末は、それ自体のストレージに、Ｋｓ＿ｌｏｃａｌならびに鍵の有効期間、ＩＣＣＩＤ、Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ、およびＵＩＣＣ＿ａｐｐｌｉ＿ＩＤなどの関連するパラメーターを格納する。ステップＳ１１において、端末は、Ｋｓ＿ｌｏｃａｌを生成するようにＵＩＣＣに要求し、ＵＩＣＣに鍵材料（ＮＡＦ＿ＩＤ、Ｔｅｒｍｉｎａｌ ＩＤ、Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ、ＲＡＮＤｘ、およびｃｏｕｎｔｅｒ ｌｉｍｉｔ値）をＭＡＣ（＝ＨＭＡＣ−ＳＨＡ−２５６［Ｋｓ＿ｌｏｃａｌ，ＮＡＦ＿ＩＤ‖Ｔｅｒｍｉｎａｌ＿ＩＤ‖ＩＣＣＩＤ‖Ｔｅｒｍ＿ａｐｐｌｉ＿ＩＤ‖ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ‖ＲＡＮＤＸ‖Ｃｏｕｎｔｅｒ Ｌｉｍｉｔ］）と一緒に送信し、このＭＡＣは、１６オクテット＝１２８ビットに切り詰められる。ＵＩＣＣは、ステップＳ１２において、Ｋｓ＿ｉｎｔ＿ＮＡＦおよびＢ−ＴＩＤを取り出し、Ｋｓ＿ｌｏｃａｌ＝ＫＤＦ（Ｋｓ＿ｉｎｔ＿ＮＡＦ，Ｂ−ＴＩＤ，Ｔｅｒｍｉｎａｌ＿ＩＤ，ＩＣＣＩＤ，Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ，ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ，ＲＡＮＤｘ，Ｃｏｕｎｔｅｒ Ｌｉｍｉｔ）を生成する。ＵＩＣＣは、ＭＡＣ’＝（ＨＭＡＣ−ＳＨＡ−２５６［Ｋｓ＿ｌｏｃａｌ，ＮＡＦ＿ＩＤ‖Ｔｅｒｍｉｎａｌ＿ＩＤ‖ＩＣＣＩＤ‖Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ‖ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ‖ＲＡＮＤＸ‖Ｃｏｕｎｔｅｒ Ｌｉｍｉｔ］）を計算し、このＭＡＣ’は、１６オクテット＝１２８ビットに切り詰められる。計算されたＭＡＣ’は、受信されたＭＡＣと比較される。ＭＡＣ’およびＭＡＣが一致しない場合には、ステップＳ１３において、失敗メッセージが端末に送り返される。ＭＡＣとＭＡＣ’との間に一致がある場合には、Ｋｓ＿ｌｏｃａｌならびにＴｅｒｍｉｎａｌ＿ＩＤ、Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ、およびｃｏｕｎｔｅｒ ｌｉｍｉｔなどの関連するパラメーターが、ＵＩＣＣ内に格納される。ステップＳ１３において、ＵＩＣＣは、Ｋｓ＿ｌｏｃａｌおよびＭＡＣアルゴリズムＨＭＡＣ−ＳＨＡ−２５６を使用して作成された、１６オクテットに切り詰められた「検証成功メッセージ」を端末に返す。
【００１９】
図５は、ＵＩＣＣと端末との間の鍵の確立を示す。ＴＳ３３．１１０ ｖ７．２．０からのローカル鍵確立処理は、ＨＴＴＰＳトンネルの確立に依存する（図５のステップＳ４を参照されたい）。ＴＳ３３．１１０ ｖ７．２．０において、ＨＴＴＰＳトンネルが、後にそのトンネルを設定する際に使用される公開鍵を証明する加入者証明書を使用して確立されることが指定されている。最近の３ＧＰＰ仕様ＴＳ３３．２２１ ｖ７．０．０は、そのような加入者証明書が図６に示されたステップを使用して確立されるステップを指定する。
【００２０】
図６のシーケンス図は、ＨＴＴＰダイジェスト認証と共にＰＫＣＳ（Ｐｕｂｌｉｃ Ｋｅｙ Ｃｒｙｐｔｏｇｒａｐｈｙ Ｓｔａｎｄａｒｄ）＃１０を使用する時の証明書要求を説明するものである。ステップＳ１において、ＷＴＲＵは、公開鍵基盤（ＰＫＩ）ポータルに空のＨＴＴＰ要求を送信する。ＰＫＩポータルは、ステップＳ２において、ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダーを含むＨＴＴＰ応答コード４０１“Ｕｎａｕｔｈｏｒｉｚｅｄ”を使用して、認証チャレンジレスポンスを送信する。このヘッダーは、ＨＴＴＰダイジェスト認証を使用するようにＷＴＲＵに指示する。ＷＴＲＵは、ｕｓｅｒｎａｍｅとしてＢＳＦから受信したブートストラッピングトランザクション識別子（Ｂ−ＴＩＤ）およびＮＡＦ固有セッション鍵Ｋｓ＿ＮＡＦを使用してＡｕｔｈｏｒｉｚａｔｉｏｎヘッダー値を計算することによって、ＨＴＴＰ要求を生成する。証明書要求が、鍵の発信証明についてＷＩＭ（ｗｉｒｅｌｅｓｓ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）アプリケーションによる余分な保証を必要とする場合には、ＷＴＲＵは、鍵の発信証明生成に必要なパラメーターを含むＷＩＭチャレンジ要求を生成する。ＷＴＲＵは、ステップＳ４において、ＰＫＩポータルにＨＴＴＰ要求を送信し、この要求にそのＷＩＭチャレンジ要求を含める。ステップＳ５において、ＰＫＩポータルは、ＮＡＦとして働いて、要求を受信し、Ｂ−ＴＩＤを使用してＢＳＦからＮＡＦ固有セッション鍵Ｋｓ＿ＮＡＦを取ってくることと、Ｋｓ＿ＮＡＦを使用して対応するダイジェスト値を計算することと、計算された値を認証ヘッダー内で受信された値と比較することとによって、認証ヘッダーを検証する。検証が成功であり、ＷＩＭアプリケーションの余分な保証が必要である場合には、ＰＫＩポータルは、ＰＫＩポータル固有ユーザー・セキュリティ・セッティングを使用して、ＷＩＭチャレンジレスポンスを計算することができる。ＰＫＩポータルは、ステップＳ６において、後続のＰＫＣＳ＃１０要求生成に必要な追加パラメーターを含んでいるＷＩＭチャレンジレスポンスを送り返す。ＰＫＩポータルは、セッション鍵Ｋｓ＿ＮＡＦを使用して、このレスポンスを保全性保護し、認証することができる。ＷＴＲＵは、ステップＳ７においてＰＫＣＳ＃１０要求を生成し、ステップＳ８において、これを、ＨＴＴＰダイジェスト要求を使用してＰＫＩポータルに送信する。秘密鍵がＷＩＭアプリケーション内に格納される場合に、ＭＥは、ＷＩＭアプリケーションにＡｓｓｕｒａｎｃｅＩｎｆｏを要求し、供給される場合にこれをＰＫＣＳ＃１０要求に含める。エンロールメント要求は、ＰＫＣＳ ＃１０証明書エンロールメントフォーマットに従う。この要求にＡｓｓｕｒａｎｃｅＩｎｆｏを追加することは、ＯＭＡのＥＣＭＡ Ｓｃｒｉｐｔ仕様で定義されている。ＡｓｓｕｒａｎｃｅＩｎｆｏは、鍵処理に関するｐｒｏｏｆ ｏｆ ｏｒｉｇｉｎを提供する（たとえば、ＷＩＭアプリケーションを識別し、鍵がその中に格納されていることの証明を提供する）。ＷＴＲＵは、証明レスポンスの所望のフォーマットすなわち、証明書、証明書へのポインタ（たとえば、ＵＲＬ）、または完全な証明書チェーン（すなわち、発行された証明書から対応するルート証明書まで）を指示することができる。ＷＴＲＵは、証明書エンロールメントに関するＨＴＴＰ要求をＰＫＩポータルに送信する。このエンロールメント要求は、次のようにならなければならない。
【００２１】
【表１】
【００２２】
ただし、＜ｂａｓｅ ＵＲＬ＞は、サーバ／プログラムを識別する。ラベル＜ｉｎｄｉｃａｔｉｏｎ＞は、ＷＴＲＵに関する所望のレスポンスタイプをＰＫＩポータルに指示するのに使用される。可能な値は、加入者証明書のみの“ｓｉｎｇｌｅ”、加入者証明書へのポインタの“ｐｏｉｎｔｅｒ”、または完全な証明書チェーンの“ｃｈａｉｎ”である。さらに、ｏｔｈｅｒ ＵＲＬ ｐａｒａｍｅｔｅｒｓは、追加のオプションのＵＲＬパラメーターである。
【００２３】
ＰＫＣＳ＃１０要求は、ステップＳ９において、ＰＫＩポータルによって処理される。ＰＫＩポータルが、認証局（ＣＡ）である場合には、証明書は、ＰＫＩポータルで生成される。ＰＫＩポータルが、ＣＡではなく登録機関（ＲＡ）でしかない場合には、ＰＫＣＳ＃１０要求は、ＩＥＴＦのＲＦＣ ２７９７で指定されたＣＭＣまたはＩＥＴＦのＲＦＣ ２５１０およびＩＥＴＦのＲＦＣ ２５１１で指定されたＣＭＰなどの使用可能な任意のプロトコルを使用してＣＡに転送される。この場合に、ＰＫＣＳ＃１０要求が処理され、証明書が作成された後に、新しい証明書が、ＰＫＩポータルに返される。どちらの場合でも、ＰＫＩポータルは、ステップＳ１０において、証明書、ＯＭＡのＷｉｒｅｌｅｓｓ ＰＫＩ仕様（ＷＰＫＩ）のｃｌａｕｓｅ ７．４で定義された証明書へのポインタ、または発行された証明書からルート証明書までの完全な証明書チェーンを含むＨＴＴＰ応答を生成する。このＨＴＴＰ応答が、加入者証明書自体を含む場合には、このＨＴＴＰ応答は、ｂａｓｅ６４符号化されなければならず、次のように境界を定めることができる。
【００２４】
【表２】
【００２５】
このＨＴＴＰ応答が、証明書へのポインタを含む場合には、ＯＭＡのＷＰＫＩのｓｕｂｃｌａｕｓｅ ７．３．５で定義されたＣｅｒｔＲｅｓｐｏｎｓｅ構造体を使用しなければならず、このＨＴＴＰ応答は、次のように境界を定めることができる。
【００２６】
【表３】
【００２７】
このＨＴＴＰ応答が、で定義されたＰｋｉＰａｔｈ構造体内に完全な証明書チェーンを含み、ｂａｓｅ６４符号化されなければならない場合には、
【００２８】
【表４】
【００２９】
証明書チェーンのｃｏｎｔｅｎｔ−ｔｙｐｅヘッダー値は、“ａｐｐｌｉｃａｔｉｏｎ／ｐｋｉｘ−ｐｋｉｐａｔｈ”である。ＰＫＩポータルは、証明書または証明書へのポインタがＷＴＲＵに送信される場合に、セッション鍵Ｋｓ＿ＮＡＦを使用して、応答を保全性保護し、認証することができる。ＰＫＩポータルは、完全な証明書チェーンがＷＴＲＵに送信される場合に、保全性保護を使用し、応答を認証しなければならない。ＷＴＲＵが加入者証明書または加入者証明書へのＵＲＬを受信する時に、それが、ステップＳ１１において、ローカル証明書管理システムに格納される。
【００３０】
（従来技術の問題）
ＧＢＡ＿Ｕ処理とセキュリティアソシエーション処理との両方が、プライバシ問題を有する。なぜならば、両方の処理で、ＵＩＣＣおよび端末が、それらの間ならびに端末とネットワーク（ＢＳＦ、ＮＡＦ）との間で、ＵＩＣＣと端末との間のセキュアローカルチャネルまたは端末とＢＳＦ（またはＮＡＦ）との間のセキュアチャネルが形成される前に、オープンチャネルを介して多数のパラメーターを交換するからである。たとえば、ＢＳＦからＵＩＣＣへのＡＵＴＮおよびＲＡＮＤなどのパラメーターの転送は、オープンチャネル上において平文の状態ある。ＵＩＣＣとＢＳＦとの間の保全性保護が、認証情報（ＡＵＴＮ）および乱数（ＲＡＮＤ）について提供され、このＲＡＮＤは、ナンス（すなわち、それぞれ、メッセージ認証コード（ＭＡＣ）（および想定ＭＡＣ）（ＸＭＡＣ）ならびにユーザー応答（ＲＥＳ）および想定ＲＥＳ（ＸＲＥＳ）の使用によってセキュリティエンジニアリングにおいて１回だけ使用される数またはビットストリームとして）を作動する。しかし、チャネルがオープンなので、スヌーピングの危険、プライバシに対する懸念の発生、暗号解析に起因する最終的なＫの露出の危険がある。
【００３１】
従来技術は、セッション鍵のオープンチャネル転送に起因する問題をさらに含む。ＵＩＣＣの内部で導出される（導出にＫｓまたはＫｓ＿ＮＡＦを使用して）セッション鍵は、後にセッションの暗号化または暗号化解除に端末によって使用するために、ＵＩＣＣから端末に転送され、セキュアにされないチャネル上で実行される。その結果、盗聴する能力のある者は、セッション鍵を傍受し、端末とネットワークとの間で交換されるメッセージを暗号化し、または暗号化解除することができる。この場合に、ＮＡＦ鍵センターがローカル鍵（Ｋｓ＿ｌｏｃａｌ）を導出し、その後、移送する（ＮＡＦ鍵センターから）ために端末とＮＡＦ鍵センターとの間でＨＴＴＰＳトンネルを確立するのに必要な、加入者証明書確立などの後続手順の多くが、漏洩の危険がある。ローカル鍵自体がＨＴＴＰＳトンネルを介して移送されるので、セッション鍵の漏洩は、ローカル鍵の漏洩につながる。その後、ローカル鍵がリセットまたは電話ブートの後に消えずに残り、ＵＩＣＣと端末との間の情報の暗号化された転送に使用される場合に、その時に、すべてのそのような通信が、危険にさらされている。
【００３２】
（ローカル鍵確立における問題）
ＴＳ ３３．１１０−７２０に見られるＫｓ＿ｌｏｃａｌを確立する手順は、次の問題を有する。
１）複数のＯＴＡ接続に起因する非効率性 − 端末は、Ｋｓ鍵を確立するためにワイヤレスＧＢＡ＿Ｕ処理を完了しなければならない。それ自体はＵＩＣＣとＨＳＳとの間で共有される加入者秘密（Ｋ）に基づくＫｓから導出されるＫｓ＿ｌｏｃａｌを確立しようとして、ＴＳ ３３．１１０は、ＵＩＣＣと端末との間のＫｓ＿ｌｏｃａｌが、もう一度、そのチャネルに使用されるアプリケーションを指定する各ＮＡＦについて、ワイヤレスプロトコルに従うための鍵確立手順を提案する。この規格は、それぞれが異なるＮＡＦに固有の複数の異なるローカル鍵をこの形で生成することを可能にするので、複数のそのような鍵を確立したい場合には、多数のＯＴＡ手順を完了しなければならない。
２）情報プライバシの問題 − ＮＡＦ＿ＩＤ、ｔｅｒｍｉｎａｌ ＩＤ、Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ、ＲＡＮＤｘ、およびＣｏｕｎｔｅｒ Ｌｉｍｉｔ値などの多数のパラメーターの値が、ＵＩＣＣと端末との間でオープンチャネルを介して転送される。これらのパラメーターの一部は、露出された場合に、プライバシの危険を提示する可能性がある。
３）ＮＡＦ鍵センターと端末との間のＨＴＴＰＳトンネルにおいて − ３ＧＰＰ ＴＳ ３３．１１０ Ｖ７．２．０（図５のステップＳ４およびＳ５を参照されたい）において、このトンネルは、証明書ベースの相互認証を使用して作成され、ＮＡＦ鍵センターから端末へのＫｓ＿ｌｏｃａｌおよび鍵材料の転送に使用されると想定される。加入者証明書を、端末またはＵＩＣＣで動作するアプリケーションのいずれかに発行することができる。加入者証明書を確立するために必要な秘密鍵および公開鍵は、ＵＩＣＣの内部または端末上のいずれかに存在することができる。多くのこれらの場合において、秘密鍵もしくは公開鍵、加入者証明書、またはＫｓ＿ｅｘｔ＿ＮＡＦ鍵などの機密情報を、ＵＩＣＣと端末との間のセキュアにされないチャネルを介して転送する必要に起因するセキュリティ脆弱性がある。いくつかのシナリオおよびこれらのシナリオに関連する脆弱性を、下に示す。
【００３３】
図７〜図９に、加入者証明書確立処理の３つの異なるシナリオを示す。
【００３４】
図７に示されたシナリオＡ１において、秘密／公開鍵対が、端末にある。ＵＩＣＣは、ＨＴＴＰセッションを介するＰＫＩ（＝ＮＡＦ）を用いる加入者証明書確立の責任を負う。ＧＢＡ／ＧＢＡ＿Ｕ手順が既に行われたと仮定すると、Ｋｓ＿ＮＡＦ／Ｋｓ＿ｅｘｔ＿ＮＡＦ鍵は、ＵＩＣＣ上に存在する。シナリオＡ１の現在の解決策には、弱点がある。最も著しくは、ステップＳ５において、端末が、証明のための公開鍵をオープンチャネル上でＵＩＣＣに送信しなければならない。さらに、ＵＩＣＣは、ステップＳ１１において、オープンチャネルを通じて加入者証明書（ＨＴＴＰＳセッションに使用される）を端末へ送信する。
【００３５】
図８に示されたシナリオＡ２において、秘密／公開鍵対が、端末にある。端末は、ＨＴＴＰセッションを介するＰＫＩ（＝ＮＡＦ）を用いる加入者証明書確立の責任を負う。ＧＢＡ／ＧＢＡ＿Ｕ手順が既に行われたと仮定すると、Ｋｓ＿ＮＡＦ／Ｋｓ＿ｅｘｔ＿ＮＡＦ鍵は、ステップＳ１に示されているように、ＵＩＣＣ上に存在する。シナリオＡ２の＿現在の解決策に関連する弱点がある。最も著しくは、ＵＩＣＣが、ステップＳ１において、オープンチャネルを通じてＫｓ＿ｅｘｔ＿ＮＡＦ（端末は加入者証明書セッション中にＨＴＴＰダイジェストを妥当性検査するためにこれを必要とする）を端末に送信する。
【００３６】
図９に示されたシナリオＡ３において、秘密／公開鍵対が、端末にある。端末は、ＨＴＴＰセッションを介し、ステップＳ１からステップＳ１１を介するＰＫＩ（＝ＮＡＦ）を用いる加入者証明書確立の責任を負う。ＧＢＡ／ＧＢＡ＿Ｕ手順が既に行われたと仮定すると、Ｋｓ＿ＮＡＦ／Ｋｓ＿ｅｘｔ＿ＮＡＦ鍵は、ＵＩＣＣ上に存在する。端末は、ステップＳ１において、ＰＫＩ（＝ＮＡＦ）を用いてセッション鍵ＫｓｓによってセキュアにされたセキュアＯＴＡチャネルを介してＫｓ＿ｅｘｔ＿ＮＡＦを受信する。これが、Ｋｓ＿ｅｘｔ＿ＮＡＦがＰＫＩ（ＮＡＦ）から端末に送信される場合に、規格の変更を仮定することを補足する。しかし、シナリオＡ３の現在の解決策に関連する弱点がある。現在、すべてのセッション鍵は、端末によって使用され、その結果、Ｋｓは、Ｓ０に示されているように、現在の電話のアーキテクチャの下において、オープンチャネルを介してＵＩＣＣによって端末に送信されなければならない。これは、盗聴者が、セッション鍵を傍受し、任意のメッセージ（加入者証明書処理メッセージを含む）を暗号化解除できることを意味する。この弱点（セッション鍵のあらわな転送）は、第１のＡＫＡ処理にすら影響する可能性がある一般的な問題である。ローカル鍵確立処理の２つの異なるシナリオを、図１０〜図１１に示す。
【００３７】
図１０に示されたシナリオＢ１において、秘密／公開鍵対が、端末にある。端末は、ステップＳ４において、処理Ａ（ＴＳ ３３．１１０）で確立された加入者証明書を使用するＨＴＴＰＳトンネル確立の責任を負う。シナリオＢ１の現在の解決策の弱点がある。最も著しくは、端末は、ステップＳ１０において、オープンチャネルを通じて証明書の公開鍵をＵＩＣＣに送信する。さらに、ＵＩＣＣは、ステップＳ１２において、オープンチャネルを介して加入者証明書（ＨＴＴＰＳセッションに使用される）を端末に送信する。
【００３８】
図１１に示されたシナリオＢ２において、秘密／公開鍵対が、ＵＩＣＣにある。端末は、ステップＳ５に示されているように、処理Ａ（３３．１１０）で確立された加入者証明書を使用するＨＴＴＰＳトンネル確立の責任を負う。しかし、シナリオＢ１の現在の解決策に関連する弱点がある。最も著しくは、ＵＩＣＣと端末との間にセキュアチャネルがない。さらに、攻撃者は、加入者証明書および秘密鍵を傍受することができ（秘密鍵を、ステップＳ４に示されているように、ＵＩＣＣによってオープンチャネルを介して端末に送信しなければならないので）、これは、ＨＴＴＰＳトンネルを危険にさらす。加えて、ステップＳ１３を参照すると、Ｋｓ＿ｌｏｃａｌが攻撃者に暴露される。
【発明の概要】
【００３９】
３Ｇ ＵＭＴＳ携帯電話システムは、３Ｇモバイル端末とＵＭＴＳワイヤレスネットワーク（またはＵＴＲＡＮ）との間の通信経路をセキュアにするさまざまなセキュリティ手段の基礎またはルートとしてＵＳＩＭ（ＵＭＴＳ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）アプリケーションを提供するＵＭＴＳ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ（ＵＩＣＣ）と呼ばれるセキュアにされたスマートカードに依存する。
【００４０】
ＵＩＣＣは、端末（ＭＥ）およびＢＳＦ（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ）と情報を交換し、ここで、それ自体はＮＡＦ固有鍵（Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦ）の複数のインスタンス化によって導出される、アプリケーションおよびＮＡＦ（ｎｅｔｗｏｒｋ ａｐｐｌｉｃａｔｉｏｎ ｆｕｎｃｔｉｏｎ）に固有の複数のローカル鍵（Ｋｓ＿ｌｏｃａｌ）が、ＵＩＣＣと端末（ＭＥ）との間のローカルチャネルを暗号化するのに使用される鍵を導出するのに使用され、ＮＡＦのそれぞれの鍵を導出するための複数のワイヤレス（ＯＴＡ）手順が除去される。本明細書で提案される方法は、「バルク」手順でローカル鍵導出および複数のＮＡＦとのセキュリティアソシエーションを可能にし、過度なＯＴＡ接続の必要を軽減する。
【００４１】
本明細書において提案されるもう１つの概念が、内部鍵センター（Ｉｎｔｅｒｎａｌ Ｋｅｙ Ｃｅｎｔｅｒ、ＩＫＣ）の使用である。ＩＫＣは、仮の鍵材料ならびに最終的なＫｓ＿ｌｏｃａｌを導出する機能に限れば、外部ＮＡＦの機能の一部に似た機能を有する、ＷＴＲＵ（ワイヤレス送受信器ユニット）内の信頼されるエンティティである。
【００４２】
複数の実施形態オプションが、ＩＫＣについて提案される。一実施形態において、ＩＫＣが信頼され、ＮＡＦ鍵センター機能の「複製」が可能であるという意味で端末として働くと同時に、Ｋｓ＿ｌｏｃａｌの生成に必要な機能（ＯＴＡ通信機能など）およびデータを提供する。もう１つの実施形態において、ＩＫＣは、ＭＥ内の信頼されるエンティティとして働くが、端末とは別々であり、ＮＡＦ鍵センターの代理として作動することができる。
【００４３】
一緒にＩＫＣの保全性および使用をセキュアにし、ＩＫＣがＮＡＦなどの外部ネットワークエンティティの代理または置換としてセキュアに働くことを可能にする、信頼されるコンピューティングに基づく方法も提案される。
【００４４】
本発明のより詳細な理解は、例として与えられ、添付図面に関連して理解されるべき、実施形態の次の説明から得ることができる。
【図面の簡単な説明】
【００４５】
【図１】ＢＳＳを用いるブートストラップの参照モデルを示す図である。
【図２】ＵＩＣＣベースの強化を使用するＧＢＡ＿Ｕブートストラップ手順を示すフローチャートである。
【図３】ＧＢＡ＿Ｕの実施の後のセキュリティアソシエーションの処理を示す図である。
【図４】端末がＵＩＣＣ保持デバイスの一部である参照モデルを示す図である。
【図５】ＵＩＣＣと端末との間での鍵の確立を示す図である。
【図６】ＨＴＴＰダイジェスト認証と共にＰＫＣＳ＃１０を使用する証明書要求を示す図である。
【図７】シナリオＡ１の加入者証明書処理を示す図である。
【図８】シナリオＡ２の加入者証明書処理を示す図である。
【図９】シナリオＡ３の加入者証明書処理を示す図である。
【図１０】シナリオＢ１のローカル鍵確立処理を示す図である。
【図１１】シナリオＢ２のローカル鍵確立処理を示す図である。
【図１２ａ】セキュアワイヤレス通信システムを示す例のブロック図である。
【図１２ｂ】ＵＩＣＣおよびＨＬＲ／ＨＳＳがＫUHを共有する場合を示す図である。
【図１３】ＵＩＣＣおよびＩＫＣが対称秘密鍵Ｋsym_UIを共有する時の実施形態を示す図である。
【図１４】ＩＫＣによって実行される正しいＫIHの識別および後続のＴＬＳ−ＰＳＫトンネル確立の処理を示す図である。
【図１５】ＢＳＦによって実行される正しいＫIHの識別および後続のＴＬＳ−ＰＳＫトンネル確立の処理を示す図である。
【図１６】本開示で説明されるＮＡＦとＷＴＲＵとの間のセキュリティアソシエーションを示す図である。
【図１７】ＵＩＣＣと端末との間のＫｓ＿ｌｏｃａｌ確立の処理を示す図である）。
【図１８】ＩＫＣならびにＩＫＣが処理する鍵およびデータの保全性をセキュアにするＭＴＭの方法を示す図である。
【図１９】ＭＴＭが端末とＩＫＣとの間に結合されるシステムを示す図である。
【発明を実施するための形態】
【００４６】
（本明細書で使用される頭字語）
３ＧＰＰ ３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ
ＡＫ 匿名鍵（Ａｎｏｎｙｍｉｔｙ Ｋｅｙ）、ＡＫ＝ｆ５K（ＲＡＮＤ）として計算される
ＡＫＡ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ
ＡＵＴＮ 認証トークン（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｔｏｋｅｎ）
ＡＶ 認証ベクトル（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｖｅｃｔｏｒ）
Ｂ−ＴＩＤ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ｔｒａｎｓａｃｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ
ＢＳＦ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ
ＣＡ 認証局（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）
ＣＫ 暗号鍵（Ｃｉｐｈｅｒ Ｋｅｙ）
ＦＱＤＮ 完全修飾ドメイン名（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）
ＧＡＡ Ｇｅｎｅｒｉｃ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ
ＧＢＡ Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ
ＧＢＡ＿ＭＥ ＭＥベースのＧＢＡ
ＧＢＡ＿Ｕ ＵＩＣＣベースの強化を伴うＧＢＡ
ＧＵＳＳ ＧＢＡ Ｕｓｅｒ Ｓｅｃｕｒｉｔｙ Ｓｅｔｔｉｎｇｓ
ＨＬＲ Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ
ＨＳＳ Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｙｓｔｅｍ
ＨＴＴＰ ハイパーテキスト転送プロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）
ＩＣＣＩＤ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ
ＩＫ Ｉｎｔｅｇｒｉｔｙ Ｋｅｙ
ＩＫＣ 内部鍵センター（Ｉｎｔｅｒｎａｌ Ｋｅｙ Ｃｅｎｔｅｒ）
ＩＭＰＩ ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｐｒｉｖａｔｅ Ｉｄｅｎｔｉｔｙ
ＫＤＦ 鍵導出関数（Ｋｅｙ Ｄｅｒｉｖａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）
Ｋ 加入者認証鍵（Ｓｕｂｓｃｒｉｂｅｒ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｋｅｙ）（ＴＳ３３．１０５ ｓｅｃ ５．１．７．１）
Ｋｓ＿ＩＫＣ＿ＮＡＦ ＩＫＣと端末との間のセキュアローカルチャネルのためにＵＩＣＣとＩＫＣとの両方でローカル鍵を導出するための鍵材料として使用される、ＢＳＦで計算される提案される鍵
Ｋｓ＿ｅｘｔ＿ＮＡＦ ＧＢＡ＿Ｕで導出される鍵
ＫIH 本発明でのＩＫＣとＨＬＲ／ＨＳＳとの間の事前共有鍵
Ｋsym_UI ＵＩＣＣとＩＫＣとの間の事前共有対称鍵
ＫUH 本発明でのＵＩＣＣとＨＬＲ／ＨＳＳとの間の事前共有鍵
Ｋｓ＿ＩＫＣ＿ＮＡＦ ＮＡＦ固有Ｋｓ＿ｌｏｃａｌの導出に使用するためにＵＩＣＣおよびＢＳＦで導出される
Ｋｓ＿ｉｎｔ＿ＮＡＦ ＵＩＣＣに残る、ＧＢＡ＿Ｕで導出される鍵
Ｋｓ＿ｌｏｃａｌ 端末とＵＩＣＣとの間で共有される、導出される鍵
ＭＡＣ メッセージ認証コード（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）
ＭＡＣNAF 本新発明でＮＡＦによって生成される（パート２中に）ＭＡＣ
ＭＡＣIKC 本新発明でＩＫＣによって生成される（パート３中に）ＭＡＣ
ＭＡＣUICC 本新発明でＵＩＣＣによって生成される（パート３中にＭＡＣ
ＭＡＣUICC_SA 本新発明でＵＩＣＣによって生成される（パート２中に）ＭＡＣ
ＭＮＯ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｏｒ
ＭＴＭ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ
ＮＡＦ Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ
ＮＡＩ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｆｉｅｒ
ＯＴＡ ワイヤレス（Ｏｖｅｒ ｔｈｅ Ａｉｒ）
ＰＫＩ 公開鍵基盤（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）
ＲＡＮＤ ランダムチャレンジ（Ｒａｎｄｏｍ ｃｈａｌｌｅｎｇｅ）
ＲＡＮＤｘ Ｋｓ＿ｌｏｃａｌ導出のためにＩＫＣによって生成されるランダムチャレンジ
ＲＡＮＤｙ Ｋｓ＿ＩＫＣ＿ＮＡＦ導出のためにＩＫＣによって生成されるランダムチャレンジ
ＲＥＳ ユーザー応答
ＳＬＦ Ｓｕｂｓｃｒｉｂｅｒ Ｌｏｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ
ＳＱＮ シーケンス番号（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）
ＴIB ＩＫＣとＢＳＦとの間のＴＬＳタイプトンネル
ＴUI ＵＩＣＣとＩＫＣとの間のＴＬＳタイプトンネル
ＴＣＧ Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ
ＴＬＳ トランスポート層セキュリティ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）
ＴＭＰＩ Ｔｅｍｐｏｒａｒｙ ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｐｒｉｖａｔｅ Ｉｄｅｎｔｉｔｙ
ＵＳＳ Ｕｓｅｒ Ｓｅｃｕｒｉｔｙ Ｓｅｔｔｉｎｇ
ＵＥ ユーザー機器（Ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）
ＵＳＩＭ Ｕｓｅｒ Ｓｅｒｖｉｃｅｓ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ
ＸＭＡＣ 認証および鍵一致に使用されるＥｘｐｅｃｔｅｄ（期待される）ＭＡＣ
ＸＲＥＳ Ｅｘｐｅｃｔｅｄ（期待される）ユーザー応答
【００４７】
本明細書において以下に引用する場合、用語の「ＷＴＲＵ（ワイヤレス送受信ユニット）」は、ユーザー機器（ＵＥ）、移動局、固定のまたは移動の加入者ユニット、ポケットベル、携帯電話機、携帯情報端末（ＰＤＡ）、コンピューター、またはワイヤレス環境で動作できるあらゆる他のタイプのユーザーデバイスを含むが、これらに限定はされない。本明細書において以下に引用する場合、用語の「基地局」は、Ｎｏｄｅ−Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、またはワイヤレス環境で動作できる任意の他のタイプのインターフェースするデバイスを含むが、これらに限定はされない。下で示す詳細な説明において、用語ＭＥは、端末と同義であり、これらの用語は、交換可能である。ＵＥは、ＵＩＣＣおよび端末（またはＭＥ）を集合的に組み込む識別するのに使用される。信頼される携帯電話機（Ｔｒｕｓｔｅｄ Ｍｏｂｉｌｅ Ｐｈｏｎｅ）は、端末と同義であるが、ＴＧＣの意味で信頼される。電話機は、端末と同義である。リモートデバイスは、ＵＥを識別し、ここで、そのＵＩＣＣおよびＵＩＣＣのリーダーは、ＵＥを含む同一の物理パッケージングに存在するのではなく、たとえばＵＳＢケーブル、ワイヤレス接続性、および類似物などのリモート接続を介してＵＥに接続される。
【００４８】
前の問題を解決し、ＧＢＡ＿Ｕ、セキュリティアソシエーション、およびＮＡＦの固有のローカル鍵Ｋｓ＿ｌｏｃａｌの確立などの既存処理のセキュリティと効率との両方を強化する、新しい方法を説明する。この方法は、仮定または要件の次のセットに基づく。
【００４９】
仮定は、次のとおりである。
１．ＷＴＲＵの内部のエンティティとして提供される内部鍵センター（ＩＫＣ）は、外部ＮＡＦ鍵センターの機能性に類似する機能性を有する。
ａ．後で検討される一実施形態において、ＩＫＣは、ＭＥの通信機能（ネットワークおよびＵＩＣＣへの）の責任をも負う。これに関して、ＩＫＣを、外部ＮＡＦ鍵センターの追加機能性を有する端末と考えることができる。
ｂ．ＩＫＣの仮定される機能性の詳細は、下で説明する。
２．ＩＫＣおよびＨＬＲ／ＨＳＳは、おそらくはその製造または販売の時に事前にプロビジョニングされる、事前共有秘密ＫIHを有する。
ａ．ＢＳＦ（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ）は、ＨＬＲ／ＨＳＳからＫIHをセキュアに取り出すことができると仮定される。
ｂ．ＫIHは、以下においてトンネルＴIBと称する、ＩＫＣとＢＳＦとの間のＴｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ−Ｐｒｅ−Ｓｈａｒｅｄ Ｋｅｙ（ＴＬＳ−ＰＳＫ）トンネルを確立するのに使用される。
３−Ａ．ＵＩＣＣおよびＨＬＲ／ＨＳＳは、ＵＩＣＣおよびＨＬＲ／ＨＳＳが既存ＧＢＡ＿Ｕ処理のためにそれらの間で既に共有する加入者秘密Ｋとは異なる秘密ＫUHを共有する。
ａ．ＢＳＦは、ＨＬＲ／ＨＳＳからＫUHをセキュアに取り出すことができると仮定される。
ｂ．ＢＳＦは、ＴＬＳ−ＰＳＫトンネルＴIBを使用して、この鍵ＫUHをＩＫＣにセキュアに暗号化して転送することができるとも仮定される。
ｃ．ＫUHは、ＢＳＦからＩＫＣに送付された後に、以下においてトンネルＴUIと称する、ＵＩＣＣとＩＫＣとの間のＴＬＳ−ＰＳＫトンネルを確立するのに使用され得る。トンネルＴUIは、短いセキュリティ有効期間を有する場合があり、その結果、これを限られた時間の間に限って使用できるようになる。
３−Ｂ．ＵＩＣＣおよびＨＬＲ／ＨＳＳが秘密鍵ＫUHを共有する仮定３Ａの代替として、ＵＩＣＣおよびＩＫＣが、事前共有対称鍵Ｋsym_UIを事前にプロビジョニングされると仮定することができ、そのようなプロビジョニングは、製造または販売の時に提供される。
４−Ａ．ＵＩＣＣは、共有秘密鍵ＫUHを使用してメッセージを暗号化し、暗号化解除することができる。
４−Ｂ．３−Ｂ仮定を使用して、ＵＩＣＣは、事前共有対称鍵Ｋsym_UIを使用してメッセージを暗号化し、暗号化解除することができる。
５−Ａ．ＩＫＣは、共有秘密鍵ＫUHを使用してメッセージを暗号化し、暗号化解除することができる。
５−Ｂ．３−Ｂ仮定を使用して、ＩＫＣは、事前共有対称鍵Ｋsym_UIを使用してメッセージを暗号化し、暗号化解除することができる。
６．ＵＩＣＣおよびＢＳＦは、両方とも、１つまたは複数の鍵Ｋｓ＿ＩＫＣ＿ＮＡＦを導出することができ、この鍵は、それぞれがＮＡＦのそれぞれに固有であり、ＮＡＦ固有Ｋｓ＿ｌｏｃａｌの生成で使用される。
７．ＩＫＣおよびＢＳＦは、１つのＯＴＡアプリケーション応答交換で複数のＮＡＦの鍵材料を交換することができる。
８．ＢＳＦは、ＩＫＣの識別情報（以下においてＩＫＣ＿ＩＤ）の受信時に、以前に認証されたかこれから認証されると期待されるのいずれかであるＵＩＣＣ＿ＩＤを識別し、これらのおそらくは複数のＵＩＣＣ＿ＩＤを使用して、これらの認証されたまたは認証されると期待されるＵＩＣＣ＿ＩＤに対応するおそらくは複数の正しい鍵｛ＫUH｝を識別することができる。ＢＳＦは、集合｛ＫUH}の鍵のうちの１つ、複数、またはすべてを、並列にまたは順番にのいずれかでＩＫＣに送信し、ＩＫＣが、これらの鍵のうちのどれをホスティングされるＵＩＣＣと共に使用すべきかをホスティングされるＵＩＣＣと共にテストすることを可能にすることもできる。
９．ＴＣＧのＭｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ ｖ１．０の仕様を満足するＭＴＭ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅ）およびそれに関連するソフトウェアスタックは、ＷＴＲＵ内に存在し、ＵＥは、ＴＣＧのＴｒｕｓｔｅｄ Ｍｏｂｉｌｅ Ｐｈｏｎｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｓｐｅｃｉｆｉｃａｔｉｏｎの仕様を満足する信頼される携帯電話機である。ＭＴＭは、ＩＫＣおよびＵＩＣＣの状態の作成、検査、および検証の責任を負い、ＧＢＡ＿Ｕ手順、セキュリティアソシエーション手順、およびセキュアローカル鍵確立手順のためにＩＫＣが処理する鍵およびデータのセキュアストレージの責任をも負う。
【００５０】
（内部鍵センター（ＩＫＣ））
一実施例において、ＩＫＣは、端末の一部であり、３Ｇエアインターフェースを使用してワイヤレスで通信でき、最終的にＢＳＦと通信することができる。代替の実施例において、ＩＫＣを、端末とは完全に別々とすることができる。ＩＫＣは、信頼されるコンポーネントであり、その保全性および信頼性は、ＷＴＲＵ内のＭＴＭによって検証可能である。ＭＴＭは、一実施例で、端末（またはＷＴＲＵ）の一部である。端末（またはＷＴＲＵ）の一部としてＭＴＭとＩＫＣとの両方を有する実施例において、ワイヤレス接続性を、有線接続性によって置換することができる。ＩＫＣは、それ自体とＵＩＣＣとの間でならびにＢＳＦと共にＴＬＳタイプのトンネルを確立するために暗号機能を有する。これらのトンネルは、ＧＢＡ＿Ｕ手順およびセキュリティアソシエーションで、およびＵＩＣＣと端末との間のセキュアチャネルの確立中にも、交換される情報の保全性および機密性をセキュアにするのに使用される。ＩＫＣは、ＢＳＦと共にＴＬＳ−ＰＳＫトンネルを確立することができる。ＢＳＦは、ＩＫＣと共にそのようなトンネルをサポートすることができると仮定される。本明細書で提案されるバージョンのパート１およびパート２のフェーズ中に、ＩＫＣは、従来技術のＧＢＡ＿Ｕ手順およびセキュリティアソシエーション手順の実行のために端末に要求される機能、ならびに一方はＩＫＣとＵＩＣＣとの間、他方はＩＫＣとＢＳＦとの間の２つのＴＬＳトンネルの作成および使用に必要な機能を実行する。本技法のパート３中に、ＩＫＣは、外部ＮＡＦ鍵センターによって実行される機能に類似する機能を実行する。この機能は、１）ｃｏｕｎｔｅｒ ｌｉｍｉｔの生成、２）それぞれがＮＡＦに固有であり、ＮＡＦ固有Ｋｓ＿ｌｏｃａｌを導出するのに使用される、乱数ＲＡＮＤｘ（１つまたは複数）およびＲＡＮＤｙ（１つまたは複数）の１つまたは複数の対の生成、３）ＫＤＦを使用するＫｓ＿ｌｏｃａｌの導出、ならびに４）ＩＫＣが端末とは完全に別々である場合の、端末へのＫｓ＿ｌｏｃａｌの転送を含む。
【００５１】
図１２ａに、上で述べた仮定に従って構成されたセキュアワイヤレス通信システムの例のブロック図を示す。このワイヤレス通信システムは、ＷＴＲＵ １２００を含む。ＷＴＲＵ １２００は、端末１２１０、モデム１２２０、およびラジオ（ＲＦ）ユニット１２３０を含む。端末１２１０は、ＭＴＭ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅ）１２４０および内部鍵センター（ＩＫＣ）１２５０を含む。ＩＫＣユニット１２５０は、外部ＵＩＣＣ １２６０と通信するように構成される。ＲＦユニット１２３０は、エアインターフェース１２７５を介してｂｏｏｔｓｔｒａｐ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ（ＢＳＦ）１２７０と通信するように構成される。ＢＳＦ １２７０は、ＨＬＲ／ＨＳＳ １２８０と通信し、オプションで、他のＮＡＦ（ｎｅｔｗｏｒｋ ａｐｐｌｉｃａｔｉｏｎ ｆｕｎｃｔｉｏｎ）（図示せず）と通信する。
【００５２】
ＩＫＣ手順を使用する改善された鍵導出およびセキュリティアソシエーション（ＳＡ）は、下で示すように、３つの部分に分割される。
【００５３】
この手順の第１部分（パート１）は、図１２に示された第１実施形態による改善されたＧＢＡ＿Ｕ処理を使用する。従来の方法を超える１つの改善は、この処理が、今や、ＷＴＲＵ １２００内の新たに提案されるエンティティ、ＩＫＣ １２５０の制御の下で２つのＴＬＳタイプチャネルを介して実行されることである。図１２を参照すると、ステップＳ１において、ＩＫＣ １２５０は、ＩＫＣ １２５０とＢＳＦ １２７０との間のＴＬＳ−ＰＳＫトンネルの確立の要求を送信する。この要求メッセージは、ペイロードとしてＩＫＣ １２５０＿ＩＤを含む。次に、ＢＳＦ １２７０は、ステップＳ２において、ＨＳＳ／ＨＬＲから事前共有鍵（ＫIHおよびＫUH）を取り出す。ＫIHは、ＩＫＣ １２５０とＢＳＦ １２７０との間でＴＬＳ−ＰＳＫトンネルを確立するのに使用され、ＫUHは、ＵＩＣＣ １２６０とＩＫＣ １２５０との間でトンネルを確立するのに使用される。ＩＫＣ １２５０とＢＳＦ １２７０との間のＴＬＳ−ＰＳＫトンネル（ＴIB）は、ステップＳ３において確立され、ここで、相互認証に基づく事前共有秘密（ＫIH）が使用される。ＢＳＦ １２７０は、ステップＳ４において、トンネルＴIBを介してＫUHをＩＫＣ １２５０に送信する。ＵＩＣＣ １２６０およびＩＫＣ １２５０は、ステップＳ５において、相互認証に基づく事前共有秘密（ＫUH）を使用して、ＴＬＳ−ＰＳＫトンネル（ＴUI）を確立する。ＧＢＡ＿Ｕが行われ、これは、ＵＩＣＣ １２６０とＢＳＦ １２７０との両方でのＫｓの確立につながる。最後に、ＧＢＡ＿Ｕ手順の終りに、Ｋｓ＝ＣＫ‖ＩＫが、ＢＳＦ １２７０（ステップＳ７ａを参照されたい）およびＵＩＣＣ １２６０（ステップＳ７ｂを参照されたい）で確立される。ＮＡＦ＿ＩＤも、ＵＩＣＣ １２６０で、ＮＡＦ＿Ｉｄ＝ＮＡＦのＦＱＤＮ‖Ｕａセキュリティプロトコル識別子として構成される。この手順において、ＵＩＣＣ １２６０は、秘密鍵ＫUHをＨＬＲ／ＨＳＳ １２８０と共有すると仮定される。
【００５４】
代替として、図１３に、ＵＩＣＣ １２６０が事前にプロビジョニングされる対称秘密鍵Ｋsym_UIをＩＫＣ １２５０と直接に共有する（ステップＳ４を参照されたい）、変更されたＢＧＡ＿Ｕのステップを示す。図１２と異なるステップだけを、これから説明する。ステップＳ２において、共有鍵ＫIHだけが、ＢＳＦ １２７０に供給される。図１３のステップＳ４において、Ｋsym_UIを使用してＴＬＳ−ＰＳＫトンネルを確立する。図１３のステップＳ５は、図１２のステップＳ６と同一である。図１３のステップＳ６ａおよびＳ６ｂは、図１２のステップＳ７ａおよびステップＳ７ｂと同一である。図１３の代替手順は、ＵＩＣＣ １２６０およびＩＫＣ １２５０が事前にプロビジョニングされる秘密鍵Ｋsym_UIを直接共有するという要件が、特定のＵＩＣＣ １２６０と特定のＩＫＣ １２５０との間に強い「バインディング」を不必要に作成する場合があり、上で説明した異なるタイプのデバイスでホスティングされるためのＵＩＣＣ １２６０のポータビリティが、実施または管理がよりむずかしくなる可能性があるという点で、欠点を有する。
【００５５】
図１２に示された手順において、ＢＳＦ １２７０は、必要な場合に、所与のＩＫＣ １２５０に関連付けられているまたは関連付けられると期待されるのいずれかとしてＨＬＲ／ＨＳＳ １２８０が知識を有することのできるＵＩＣＣ １２６０に対応する複数の鍵｛ＫUH｝を収集するように構成される。ＢＳＦ １２７０は、これらの複数の鍵を送信することができ、その後、ＩＫＣ １２５０は、正しい鍵ＫUHが識別されるまで、ＵＩＣＣ １２６０と共にチャレンジレスポンスタイプの鍵検証手順を実行することができる。この手順の実施形態を、図１４に示す。図１３と異なるステップだけが説明され、ステップＳ２において、両方ＫIH複数鍵｛ＫUH｝をＢＳＦ １２７０に供給する。ＩＫＣ １２５０は、ＵＩＣＣ １２６０にナンス‖ｈａｓｈ（
【００５６】
【数４】
【００５７】
）を要求し（ステップＳ５）、その後、これを受信する（ステップＳ６）。各ＫUHを計算して（ステップＳ７）、ＵＩＣＣ １２６０とのＴＬＳ−ＰＳＫトンネルＴUIを確立するための正しいＫUHを見つける。
【００５８】
図１４において説明した処理に対する代替として、我々は、ＩＫＣ １２５０がＢＳＦ １２７０から可能な鍵ＫUHのすべてを受信するの「ではない」鍵検証方法を提案する。ＩＫＣ １２５０は、ＵＩＣＣ １２６０から証拠鍵ＫUHを受信し（図１５、ステップＳ４およびＳ５を参照されたい）、これをＢＳＦ １２７０に渡し（ステップＳ６）、その後、ＢＳＦ １２７０は、図１５のステップＳ６に示された、鍵の可能な集合｛ＫUH｝から正しい鍵を識別する手順を実行する。正しいＫUHは、ＵＩＣＣ １２６０とのＴＬＳ−ＰＳＫトンネルの確立で使用するためにＩＫＣ １２５０に渡される（ステップＳ７）。この方法は、ＢＳＦ １２７０が、複数の候補鍵のＯＴＡ開示の危険を冒さないという点で、図１４に示された方法を超える利益を有する。
【００５９】
図１２ｂに示されたＴＬＳ−ＰＳＫトンネル確立手順において、ＩＫＣ １２５０からＢＳＦ １２７０へのＩＫＣ １２５０＿ＩＤの初期情報転送は、現在、物理層保護の上でのみ（すなわち、ＵＩＡセッション鍵およびＵＥＡセッション鍵によってセキュアにされて）実行される。前に説明したように、そのようなセッション鍵が盗聴に脆弱である場合には、ＩＫＣ １２５０−ＩＤも盗聴に脆弱になり、プライバシ開示をもたらす。
【００６０】
ＩＫＣ １２５０のアイデンティティをセキュアにするために、図１４においてオプションのステップを使用することができ、ここで、ＩＫＣ １２５０およびＢＳＦ １２７０は、ＩＫＣ １２５０＿ＩＤならびにＴＬＳ−ＰＳＫトンネル確立処理中に交換される他の情報の公開鍵ベースの暗号化および暗号化解除を使用する。面倒またはセキュリティリスクに脆弱である場合がある証明書ベースの手法の代わりに、ＩＫＣ １２５０およびＢＳＦ １２７０が、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ（ＤＨ）鍵交換手順を使用してそれぞれの公開鍵を確立することを提案する。実際に、ＩＫＣ １２５０は、ネットワークからブロードキャストされる、かなり多い個数ｎ個の異なる公開鍵を入手し、そこから１つを選択することができる。ＤＨ鍵交換プロトコルを、この目的に使用することができる。
【００６１】
伝達者は、このプロトコルを適用して、公開鍵集合への、ａなどの共通インデックスを計算する。これを達成するために、まず、ネットワークおよびＩＫＣ １２５０は、公知の２つの値すなわち、非常に大きい素数ｐおよび体Ｆpの乗法群Ｆ*pの生成元ｇについて一致する。次に、ネットワークは、乱数ＲＡＮＤiを選択し、
【００６２】
【数５】
【００６３】
を計算し、
【００６４】
【数６】
【００６５】
をＩＫＣ １２５０に送信する（１≦ＲＡＮＤi≦ｐ−２）。次に、ＩＫＣ １２５０は、乱数ＦＲＥＳＨを計算し、ｇFRESH≡ｇFRESH ｍｏｄ ｐを計算し、ｇFRESHをネットワークに送信する（１≦ＦＲＥＳＨ≦ｐ−２）。次に、ネットワークは、
【００６６】
【数７】
【００６７】
を計算する。最後に、ＩＫＣ １２５０は、
【００６８】
【数８】
【００６９】
を計算する。
【００７０】
ｋ≡ｋ’ ｍｏｄ ｐであることは、簡単に示される。ＩＫＣ １２５０およびネットワークは、両方ともｋ（０≦ｋ＜ｐ）を計算済みであるが、単純にｋ ｍｏｄｕｌｏ ｎを換算することによって、公開鍵の秘密インデックスａを計算することができる。すなわち、ａ≡ｋ ｍｏｄ ｎである。公開鍵ｋaすなわちインデックスａに対応する公開鍵を使用して、ＩＫＣ １２５０は、ＩＫＣ １２５０＿ＩＤを含むメッセージを暗号化し、ネットワークは、ｋaに対応する秘密鍵を使用して、そのメッセージを暗号化解除することができる。
【００７１】
ＩＫＣ １２５０＿ＩＤの機密性が達成されるのは、ネットワークがＲＡＮＤiの唯一のプロセッサであり、ＩＫＣ １２５０がＦＲＥＳＨの唯一のプロセッサであり、この２つの通信参加者だけがｋを計算できるからである。攻撃者は、離散対数問題の計算的実行不可能性によってセキュアにされる、これらの乱数値の両方を欠いている。
【００７２】
メッセージ機構が、公開鍵集合の散布に関して暗示される。これを、簡単にセルブロードキャストメッセージング構造の一部にすることができる。しかし、ネットワークからＩＫＣ １２５０への
【００７３】
【数９】
【００７４】
の送信およびＩＫＣ １２５０からネットワークへの値ｇFRESHの送信のために、追加のメッセージ機構が必要である。これらの機構は、好ましくは、上で定義した公開値ｐおよびｇに関するネットワーク／ＩＫＣ １２５０一致処理を含む。
【００７５】
ＫUHと表される複数の鍵をＩＫＣ １２５０に転送するネットワークに関して、成功のＫUHが達成されるまで、鍵ごとに１回の反復的な相互（チャレンジ−レスポンス）認証処理を使用することができる。ＵＩＣＣ １２６０は、この認証がすべての鍵について失敗する場合に拒否される。
【００７６】
上に説明した公開鍵のＤＨ交換を、ＴＬＳ−ＰＳＫトンネリング確立処理自体の一部として実行することもできる。この場合に、ＩＫＣ １２５０＿ＩＤは、ＴＬＳ−ＰＳＫハンドシェーク処理でのＩＫＣ １２５０からＢＳＦ １２７０への初期交換メッセージに含まれる。ＴＬＳ−ＰＳＫ拡張に関するＲＦＣ ４２７９が、ＤＨ対応ＴＬＳ−ＰＳＫ手順について、次の４つの異なる暗号スイート（ｃｉｐｈｅｒｓｕｉｔｅ）を許容することに留意されたい。
１．ＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
２．ＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿３ＤＥＳ＿ＥＤＥ＿ＣＢＣ＿ＳＨＡ
３．ＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
４．ＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
ＲＣ４アルゴリズムの既知の暗号強度問題に起因して、それぞれ３ＤＥＳ、ＡＥＳ１２８、またはＡＥＳ２５６を用いる後の３つの暗号スイートだけを使用しなければならない。
【００７７】
（パート２：ＮＡＦとＵＥとの間のセキュリティアソシエーション）
パート２は、ＵＩＣＣ １２６０とＩＫＣ １２５０との間およびＩＫＣ １２５０とＢＳＦ １２７０との間の情報の交換をセキュアにするための２つのＴＬＳ−ＰＳＫトンネルの使用を介する従来技術の同一の名前の処理より優れたセキュリティアソシエーション処理である。追加の改善は、ＵＩＣＣ １２６０が、ＩＫＣ １２５０およびＢＳＦ １２７０の助けを得て、バルク鍵確立機構で複数のＮＡＦと共に鍵を確立できることである。
【００７８】
図１６を参照すると、パート２の詳細なステップが示されている。ＩＫＣ １２５０は、ステップＳ１において、ＵＩＣＣ １２６０に最新の有効なＫｓが存在するかどうかを検査し、そうである場合には、ＩＫＣ １２５０は、既に確立されたトンネル（ＴUI）を介してＵＩＣＣ １２６０からＢ−ＴＩＤおよびＮＡＦ＿ＩＤ（または、ＵＩＣＣ １２６０がそれとのセキュリティアソシエーションを確立することを望むＮＡＦのある他のアイデンティティ）を取り出す。ＵＩＣＣ １２６０は、ステップＳ１の間にＫｓ ｉｎｔ／ｅｘｔ＿ＮＡＦ鍵をも導出する。Ｋｓが最新でないか有効でない場合には、ＧＢＡ＿Ｕが、Ｋｓの確立のために開始される。ＩＫＣ １２５０は、ステップＳ２において、トンネルＴIBを介してＢＳＦ １２７０にＮＡＦ＿ＩＤおよびＢ−ＴＩＤを転送する。ＢＳＦ １２７０は、ステップＳ３において、所望のＮＡＦ（図を単純にするために図１６には１つのＮＡＦだけが示されている）に認証要求を送信する。ＢＳＦ １２７０は、ステップＳ４において、ＮＡＦから認証レスポンスを受信する。ＮＡＦが認証される場合には、ＢＳＦ １２７０は、ステップＳ５において、ＮＡＦ固有鍵（Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦ）を導出する。ＢＳＦ １２７０は、ステップＳ６において、ブートストラップ時刻および鍵の有効期間と一緒に、Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦをすべてのＮＡＦに転送する。ステップＳ７において、ＮＡＦのそれぞれは、Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦ、鍵の有効期間、およびブートストラップ時刻の受信を示す肯定応答メッセージをＢＳＦ １２７０に送信する。ＢＳＦ １２７０は、これらのメッセージを集約し、ステップＳ８において、ＴＬＳ−ＰＳＫトンネルＴIBを介してＩＫＣ １２５０にバルク・セキュリティ・アソシエーション・メッセージを送信し、このバルク・セキュリティ・アソシエーション・メッセージは、それに関してステップＳ５〜Ｓ７においてＫｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦが確立された特定のＮＡＦにそれぞれが対応する複数のＭＡＣNAFを含む。ＭＡＣNAFメッセージのそれぞれについて、ＭＡＣNAF＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｓ＿ｅｘｔ＿ＮＡＦ‖Ｋｓ＿ｉｎｔ＿ＮＡＦ‖ＮＡＦ＿ＩＤ‖ＧＵＳＳ）が、ＮＡＦごとに１６オクテットに切り詰められる。ＩＫＣ １２５０は、ステップＳ９において、ステップＳ８の間にＢＳＦ １２７０から受信したバルク・セキュリティ・アソシエーション・メッセージを、ＴＬＳ−ＰＳＫチャネルＴUIを介してＵＩＣＣ １２６０に転送する。ＵＩＣＣ １２６０は、ステップＳ１０において、ＮＡＦごとに、そのＮＡＦに固有のＭＡＣUICC_SAを、１６オクテットに切り詰められたＭＡＣUICC_SA＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｓ＿ｅｘｔ＿ＮＡＦ‖Ｋｓ＿ｉｎｔ＿ＮＡＦ‖ＮＡＦ＿ＩＤ‖ＧＵＳＳ）になるように計算する。ステップＳ１１において、バルク・セキュリティ・アソシエーション応答メッセージがＵＩＣＣ １２６０によって生成され、このメッセージは、ＵＩＣＣ １２６０とすべてのＮＡＦとの間のセキュリティアソシエーションのすべての成功および／または失敗を含む。失敗は、ＮＡＦのいずれかについて、ＭＡＣIKCがそれに対応するＭＡＣUICC_SAと一致しない時に検出される。この失敗は、たとえば、“ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ ｆａｉｌｕｒｅ”‖ＮＡＦ＿ＩＤなどのストリングによって示される。成功は、ＭＡＣIKCがそれに対応するＭＡＣUICC_SAと一致する時に検出される。成功応答は、Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦ鍵およびＭＡＣアルゴリズムＨＭＡＣ−ＳＨＡ−２５６を使用するＡＳＣＩＩ符号化されたストリング“ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ Ｓｕｃｃｅｓｓｆｕｌ”のメッセージ認証コード（ＭＡＣ）を１６オクテットに切り詰めたものを含む。ステップＳ１１において、バルク・セキュリティ・アソシエーション応答メッセージが、ＩＫＣ １２５０を介し、ＴUIトンネルおよびＴIBトンネルを介してＢＳＦ １２７０まで送信される。ＢＳＦ １２７０は、ステップＳ１２において、ＮＡＦのそれぞれに、そのＮＡＦに固有のセキュリティアソシエーションの試みの失敗または成功の状況を送信する。成功の状況を受信したすべてのＮＡＦは、ステップＳ１３において、鍵（Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦ）、ブートストラップ時刻、および関連する鍵の有効期間を格納する。
【００７９】
（パート３：端末とＵＩＣＣ １２６０との間での鍵確立（Ｋｓ＿ｌｏｃａｌ））
パート３は、ＵＩＣＣ １２６０と端末との間のローカル鍵確立の処理である。従来技術と比較したこのパートの利益は、次のとおりである。ＵＩＣＣ １２６０とＩＫＣ １２５０との間およびＩＫＣ １２５０とＢＳＦ １２７０との間の情報の交換をセキュアにする２つのＴＬＳ−ＰＳＫトンネルの使用。第２に、ＵＩＣＣ １２６０および端末が、ＩＫＣ １２５０およびＢＳＦ １２７０の助けを得て、従来技術で要求されるように端末が異なる外部ＮＡＦ鍵センターとの複数のＯＴＡ接続を確立する必要なしに、それぞれが異なるＮＡＦに固有の複数のローカル鍵を確立する。
【００８０】
図１７に、パート３の詳細なステップを示す。ＩＫＣ １２５０は、ステップＳ１において、最新の有効なＫｓがＵＩＣＣ １２６０に存在するかどうかを検査する。そうである場合には、ＩＫＣ １２５０は、Ｂ−ＴＩＤおよび１つまたは複数のＮＡＦ＿ＩＤをＵＩＣＣ １２６０から取り出す。最新のＫｓまたは有効なＫｓがないときには、新しいＧＢＡ＿Ｕ処理を開始してＫｓを確立し、その後、Ｂ−ＴＩＤおよび１つまたは複数のＮＡＦ＿ＩＤが、ＩＫＣ １２５０によってＵＩＣＣ １２６０から取り出される。上の手順のために必要なＵＩＣＣ １２６０とＩＫＣ １２５０との間の情報交換のすべてが、ＴＬＳ−ＰＳＫトンネルＴUIを介してもたらされる。ＩＫＣ １２５０は、ステップＳ２において、それぞれが要求されるＮＡＦのＮＡＦ＿ＩＤに対応する１つまたは複数の鍵Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦのアプリケーション要求をＢＳＦ １２７０に送信する。ＩＫＣ １２５０は、Ｂ−ＴＩＤと、対応するＲＡＮＤｙナンスと一緒に１つまたは複数のＮＡＦ＿ＩＤとをも、ＴＬＳ−ＰＳＫトンネルＴIBを介して送信する。ＢＳＦ １２７０は、それぞれが要求されるＮＡＦのそれぞれに固有の１つまたは複数のＩＫＣ １２５０鍵Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦを計算し、ここで、Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦ＝ＫＤＦ（Ｋｓ＿ｉｎｔ＿ＮＡＦ，ＲＡＮＤｙ）である。その後、ＢＳＦ １２７０は、ステップＳ３において、Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦ鍵およびそのそれぞれの（ＮＡＦ固有）鍵の有効期間のすべてを含むアプリケーション応答をＩＫＣ １２５０に送信する。ＩＫＣ １２５０は、ステップＳ４において、ｃｏｕｎｔｅｒ ｌｉｍｉｔ値（それぞれが要求されるＮＡＦの関連する１つに固有）を生成し、１つまたは複数のローカル鍵Ｋｓ＿ｌｏｃａｌを導出し、ここで、Ｋｓ＿ｌｏｃａｌ＝ＫＤＦ（Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦ，Ｂ−ＴＩＤ，Ｔｅｒｍｉｎａｌ＿ＩＤ，ＩＣＣＩＤ，Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ，ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ，ＲＡＮＤｘ，ＣｏｕｎｔｅｒＬｉｍｉｔ）である。ローカル鍵がプラットフォーム固有鍵である場合に、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤオクテットストリングおよびＴｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤオクテットストリングが、静的なＡＳＣＩＩ符号化されたストリング“ｐｌａｔｆｏｒｍ”と等しくなるようにセットされることに留意されたい。ＩＫＣ１２５０は、ステップＳ５において、ＮＡＦ＿ＩＤに固有のＫｓ＿ｌｏｃａｌを作成するようにＵＩＣＣ １２６０に要求するアプリケーション要求メッセージを、トンネルＴUIを介してＵＩＣＣ １２６０に送信する。この要求のペイロードは、ＮＡＦ＿ＩＤ、Ｔｅｒｍｉｎａｌ＿ＩＤ、Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ、ＲＡＮＤｘ、ＲＡＮＤｙ、およびＣｏｕｎｔｅｒ Ｌｉｍｉｔ値を含む。端末は、ＭＡＣIKCをも含め、このＭＡＣIKCは、１６オクテットに切り詰められるＭＡＣIKC＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｓ＿ｌｏｃａｌ，ＮＡＦ＿ＩＤ‖Ｔｅｒｍｉｎａｌ＿ＩＤ‖ＩＣＣＩＤ‖Ｔｅｒｍ＿ａｐｐｌｉ＿ＩＤ‖ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ‖ＲＡＮＤｘ‖ＲＡＮＤｙ‖ＣｏｕｎｔｅｒＬｉｍｉｔ）として計算される。これがプラットフォーム固有鍵である場合に、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤオクテットストリングおよびＴｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤオクテットストリングが、静的なＡＳＣＩＩ符号化されたストリング“ｐｌａｔｆｏｒｍ”と等しくなるようにセットされることに留意されたい。ＵＩＣＣ １２６０は、受信されたＮＡＦ＿ＩＤに関連するＫｓ＿ｉｎｔ＿ＮＡＦおよびＢ−ＴＩＤを取り出し、当初に、Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦ＝ＫＤＦ（Ｋｓ＿ｉｎｔ＿ＮＡＦ，ＲＡＮＤｙ）に従ってＫｓ＿ＩＫＣ １２５０＿ＮＡＦを導出し、その後、Ｋｓ＿ｌｏｃａｌを導出し、ここで、Ｋｓ＿ｌｏｃａｌ＝ＫＤＦ（Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦ，Ｂ−ＴＩＤ，Ｔｅｒｍｉｎａｌ＿ＩＤ，ＩＣＣＩＤ，Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ，ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ，ＲＡＮＤｘ，Ｃｏｕｎｔｅｒ Ｌｉｍｉｔ）である。ＵＩＣＣ １２６０は、ステップＳ６において、１６オクテットに切り詰められるＭＡＣUICC＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｓ＿ｌｏｃａｌ，ＮＡＦ＿ＩＤ‖Ｔｅｒｍｉｎａｌ＿ＩＤ‖ＩＣＣＩＤ‖Ｔｅｒｍ＿ａｐｐｌｉ＿ＩＤ‖ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ‖ＲＡＮＤｘ‖ＲＡＮＤｙ‖Ｃｏｕｎｔｅｒ Ｌｉｍｉｔ）を計算し、これをＭＡＣIKCと比較することによって、端末から受信したＭＡＣIKC 1250値を検証する。ＭＡＣUICCがＭＡＣIKCと等しくない場合には、ＵＩＣＣ １２６０は、鍵一致手順を終了し、Ｋｓ＿ｌｏｃａｌ導出要求に応答するＭＡＣ検証失敗メッセージを返す。ＭＡＣUICC＝ＭＡＣIKCの場合には、ＵＩＣＣ １２６０は、Ｋｓ＿ｌｏｃａｌおよび関連するパラメーター（Ｔｅｒｍｉｎａｌ＿ＩＤ、Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ、およびＫｓ＿ｌｏｃａｌ Ｃｏｕｎｔｅｒ Ｌｉｍｉｔ）を格納する。ステップＳ７において、ＵＩＣＣ １２６０は、鍵Ｋｓ＿ｌｏｃａｌおよびＭＡＣアルゴリズムＨＭＡＣ−ＳＨＡ−２５６を使用して、１６オクテットに切り詰められる、ＡＳＣＩＩ符号化されたストリング“ｖｅｒｉｆｉｃａｔｉｏｎ ｓｕｃｃｅｓｓｆｕｌ”のＭＡＣを含むＫｓ＿ｌｏｃａｌ導出応答を送信する。ＩＫＣ １２５０は、ステップＳ８において、Ｋｓ＿ｌｏｃａｌおよび鍵の有効期間を格納する。ローカル鍵Ｋｓ＿ｌｏｃａｌが要求されるＮＡＦのそれぞれについて、ステップＳ４〜Ｓ８が繰り返される。
【００８１】
上に説明した方法において、代替の実施形態に、事前共有鍵であるＫUHおよびＫIHは、直接に使用されるのではなく、事前共有秘密として使用され、実際の共有鍵は、これらの事前共有秘密から導出される。導出される共有鍵を更新することができる、すなわち、これらは、セッション鍵になる。この形で、ＫUHまたはＫIHのいずれかから導出されたセッション鍵が暴露される場合であっても、秘密自体を、まだセキュアにすることができる。
【００８２】
上に述べたＴＬＳ−ＰＳＫトンネルに引用すると、事前共有秘密を使用する認証される暗号化の他の方法を、代替として使用することができる。１つの代替の実施形態は、ＲＡＤＩＵＳ（Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ−Ｉｎ Ｕｓｅｒ Ｓｅｒｖｉｃｅ）上でのＥＡＰ（拡張認証プロトコル）の使用を組み合わせる。そのような代替方法を、下にさらに説明され新たに提案されるプロトコルの３つすべてのパートに適用することができる。
【００８３】
加えて、上に説明した手順において、ＴＬＳをトンネリングなしで使用することができる、すなわち、ＴＬＳは、暗号化および認証だけに使用され、認証には使用されない。
【００８４】
上に説明した方法に行き渡る要件、すなわち事前に共有される秘密鍵、または事前に共有される秘密鍵から導出されるセッション鍵が、ＧＢＡ＿Ｕ処理、セキュリティアソシエーション処理、およびローカル鍵生成処理をセキュアにするのに使用されることは、ローカル鍵Ｋｓ＿ｌｏｃａｌを初めて生成しなければならない場合にのみ要求される。本明細書で提案される機構の保護の下で、ローカル鍵Ｋｓ＿ｌｏｃａｌが、生成され、ＵＩＣＣ １２６０と端末との両方でセキュアに存在するようにされ（電話機のパワーオフまたはＵＩＣＣの除去の後であっても）、Ｋｓ＿ｌｏｃａｌが、ＮＡＦ鍵センターで（管理のために）維持される場合には、後に、３つの処理のいずれかすなわち、ＧＢＡ＿Ｕ、セキュリティアソシエーション、またはローカル鍵導出処理がもう一度行われる必要がある時に、提案される手順を繰り返す必要はない。これは、そのような場合に、既に生成されセキュアに格納されたローカル鍵Ｋｓ＿ｌｏｃａｌを、本開示で提案される事前共有秘密（または鍵）の代わりに、オリジナルの変更されない処理（ＧＢＡ＿Ｕ、セキュリティアソシエーション、おおびローカル鍵導出）インストならびにＮＡＦ鍵センターでの情報フローの保全性および機密性をセキュアにするのに使用できるからである。
【００８５】
上に提案された新しい方法は、わずかな変更を伴って、ＵＩＣＣ １２６０ホスティングデバイスとリモートデバイスとの間のチャネルを証券化する既存プロトコルにも適用可能である。
【００８６】
（ＩＫＣ １２５０をセキュアにするためのＭＴＭの使用）
ＵＩＣＣ １２６０と端末との間のセキュアチャネルに関する強化されたＧＢＡ＿Ｕ、セキュリティアソシエーション、およびローカル鍵確立の提案される方法（上で説明したパート１、パート２、およびパート３を参照されたい）を実行するために、ＭＴＭ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅ）を携帯電話機（ＵＥ）上で使用して、内部鍵センター（ＩＫＣ １２５０）およびそれが扱い、処理するデータの保全性をセキュアにすることができる。
【００８７】
図１８に、ＭＴＭ １２４０をセクション４．３に説明した変更されたＧＢＡ＿Ｕ処理（パート１）にどのように使用できるかを示す。ＭＴＭ １２４０は、主に、ＩＫＣ １２５０がＧＢＡ＿Ｕ処理を続行する前にＩＫＣ １２５０の保全性を検証するのに使用される。ＭＴＭ １２４０は、それ自体の中で（セキュアな不揮発性ＮＶＲＡＭの下で）またはＩＫＣ １２５０とＢＳＦ １２７０との間ならびにＩＫＣ １２５０とＵＩＣＣ １２６０との間のトンネリングに必要な鍵の暗号化に使用される暗号化鍵をセキュアにすることによってのいずれかで、セキュアに格納するのにも使用される。ＭＴＭ １２４０は、ＴＬＳ−ＰＳＫトンネルでナンスとして使用される乱数を生成するのにも使用される。
【００８８】
同様に、パート１（ＧＢＡ＿Ｕ）処理について上で説明したように、上で提案されたパート２（セキュリティアソシエーション）ステップおよびパート３（ローカル鍵生成）ステップを、類似する形でＭＴＭ １２４０を使用することによって強化することもできる。ＭＴＭ １２４０は、処理のそれぞれの前にＩＫＣ １２５０の保全性を検証し、鍵と、ＩＫＣ １２５０が生成またはＵＩＣＣ １２６０およびＢＳＦ １２７０などの他のエンティティからの受信のいずれかを行う他の機密材料とをセキュアにし、格納し、ＩＫＣ １２５０が取り出すことを可能にし、処理のそれぞれのナンスに使用される乱数を生成するのに使用される。
【００８９】
図１９に、端末およびＩＫＣ １２５０を伴うＭＴＭ １２４０の使用を示す。ＭＴＭ １２４０を、ＩＫＣ １２５０が端末とは別々である時に端末の保全性を検証するのに使用することもでき、この端末は、ＩＫＣ １２５０より信頼できず、セキュアでもないと考えられる。これは、端末が、ＵＩＣＣ １２６０とＩＫＣ １２５０との間でＵＩＣＣ １２６０および端末によって導出されたローカル鍵Ｋｓ＿ｌｏｃａｌをセキュアに取り出し、後に使用することを可能にする。図１９を参照すると、ＵＩＣＣ １２６０とＩＫＣ １２５０との間で導出された鍵Ｋｓ＿ｌｏｃａｌを使用して（パート３の終りを参照されたい）、ＩＫＣ １２５０は、ＭＴＭ １２４０内またはＭＴＭ １２４０による暗号保護の下のいずれかでＫｓ＿ｌｏｃａｌをセキュアに格納する。Ｋｓ＿ｌｏｃａｌから導出される任意のプラットフォーム固有鍵またはアプリケーション固有鍵も、ＭＴＭ １２４０によって同一の形でセキュアに格納される。端末（ＩＫＣ １２５０とは別々）が、Ｋｓ＿ｌｏｃａｌまたはそれから導出される鍵のいずれかを使用できる前に、端末は、ステップＳ１において、ローカル鍵の使用についてＩＫＣ １２５０に要求する。ＩＫＣ １２５０は、ステップＳ２において、端末の保全性を検証するようにＭＴＭ １２４０に要求する。ＭＴＭ １２４０は、ステップＳ３において、端末の保全性を検証する。端末の保全性が、ステップＳ３およびＳ４において、ＭＴＭ １２４０によって端末およびＩＫＣ １２５０に対して検証された後に限って、ＩＫＣ １２５０は、ステップＳ５において、ＭＴＭ １２４０が端末とＵＩＣＣ １２６０との間の通信に使用するために端末によって要求された鍵を公開することを認証する。ステップＳ６において、ローカル鍵（１つまたは複数）が、ＭＴＭ １２４０によって端末に公開される。端末は、ステップＳ７において、ＵＩＣＣ １２６０とのセキュアチャネル（１つまたは複数）を確立するのにそのローカル鍵を使用する。
【００９０】
提案される解決策の利益のいくつかを、下で示す。図１９のステップＳ２、Ｓ３、およびＳ４において、ＩＫＣ １２５０とＢＳＦ １２７０との間での鍵および鍵材料の「バルク」転送および処理を可能にし、ここで、１つまたは複数のＮＡＦ用の材料を、そのＮＡＦに固有のＫｓ＿ｌｏｃａｌ鍵を導出するために交換し、処理することができ、これによって、複数のＮＡＦのＫｓ＿ｌｏｃａｌの導出が従来技術に従って実行される場合に必要になるＯＴＡ手順の数が減る。第２に、ＵＩＣＣ １２６０とＩＫＣ １２５０との間およびＩＫＣ １２５０とＢＳＦ １２７０との間で交換される情報は、今や、２つのＴＬＳ−ＰＳＫトンネルの使用に起因して、保全性と機密性との両方についてセキュアにされる。これは、上で説明した問題に起因する従来技術のプライバシリスクおよび潜在的なセキュリティリスクを軽減する。この利益は、ローカル鍵確立の処理だけではなく、ＧＢＡ＿Ｕ処理およびセキュリティアソシエーション処理にも適用可能である。第３に、どちらもが既存の加入者秘密Ｋまでトレース可能ではない別々の共有秘密ＫUIおよびＫIHの使用は、ＵＩＣＣ １２６０およびＨＬＲ／ＨＳＳ １２８０によって共有される加入者秘密へのトンネリングの処理を分離し、これは、ＫUI鍵およびＫIH鍵の潜在的漏洩が加入者秘密を暴露しないので、セキュリティリスクを減らす。第４に、ＩＫＣ １２５０の使用は、ＩＫＣ １２５０が、その信頼性がＷＴＲＵ １２００上のＭＴＭ １２４０によってセキュアにされる（検証可能かつ証明可能な）信頼されるエンティティなので、セキュリティの利益を加える。ローカル鍵（Ｋｓ＿ｌｏｃａｌ）および鍵材料が、信頼されるＩＫＣ １２５０によって処理されるので、また、ＩＫＣ １２５０が、この情報を保持するＭＴＭ １２４０のセキュアストレージ機能ならびにＲＡＮＤｘおよびＲＡＮＤｙの作成用の乱数ジェネレータなどのＭＴＭ １２４０のセキュアにされた機能を使用できるので、総合的な処理セキュリティが強化される。最後に、ＩＫＣ １２５０の（ならびに、ＩＫＣ １２５０および端末が別々のエンティティである時には端末の）保全性を検証し、鍵および鍵材料をセキュアに格納し、ナンスとして使用される乱数をセキュアに生成するためのＭＴＭ １２４０の使用は、ローカル鍵を確立する処理（パート１からパート３）のセキュリティおよび信頼性を増し、端末が、ＩＫＣ １２５０およびＵＩＣＣ １２６０によって生成されたローカル鍵を、そのローカル鍵の保全性がＭＴＭ １２４０によって検証された後に限って使用することをも可能にする。
【００９１】
本発明の特徴および要素は、望ましい実施形態において特定の組合せにより説明されるが、各特徴または要素を、望ましい実施形態の他の特徴および要素を伴わずに単独において、または本発明の他の特徴および要素を伴ってもしくは伴わずにさまざまな組合せにおいて使用することができる。本発明において提供される方法またはフローチャートは、汎用コンピューターまたはプロセッサによる実行のためにコンピューター読み取り可能な記憶媒体において明白に実装される、コンピュータープログラム、ソフトウェア、またはファームウェアに実装することができる。コンピューター読み取り可能な記憶媒体の例は、読み取り専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、レジスター、キャッシュメモリ、半導体メモリデバイス、例えば内蔵ハードディスク、取外し可能なディスクなどの磁気媒体、光磁気媒体、および例えばＣＤ−ＲＯＭディスク、デジタル多用途ディスク（ＤＶＤ）などの光媒体を含む。
【００９２】
適切なプロセッサは、たとえば、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つまたは複数のマイクロプロセッサ、コントローラー、マイクロコントローラー、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）回路、他のすべての型の集積回路（ＩＣ）、および／または状態機械を含む。
【００９３】
ソフトウェアに関連するプロセッサを使用して、ＷＴＲＵ（ワイヤレス送受信ユニット）、ユーザー機器（ＵＥ）、端末、ＭＥ、基地局、ワイヤレスネットワークコントローラ（ＲＮＣ）、またはすべてのホストコンピューターにおいて使用されるラジオ周波数トランシーバーを実装することができる。ＷＴＲＵは、例えば、カメラ、ビデオ・カメラ・モジュール、ビデオ電話機、スピーカホン、振動デバイス、スピーカー、マイクロホン、テレビジョントランシーバー、ハンズ・フリー・ヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、液晶ディスプレイ（ＬＣＤ）ディスプレイユニット、有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット、デジタル音楽プレイヤー、メディアプレイヤー、ビデオ・ゲーム・プレイヤー・モジュール、インターネットブラウザー、および／またはすべてのワイヤレス・ローカル・エリア・ネットワーク（ＷＬＡＮ）モジュールなどのハードウェアおよび／またはソフトウェアで実装されるモジュールに関連して使用される。
【００９４】
（実施形態）
１．セキュア通信を確立する方法であって、
ａ）内部鍵センター（ＩＫＣ）とＢＳＦ（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ）との間のＴＬＳ−ＰＳＫトンネルの確立を要求することと、
ｂ）ＨＳＳ／ＨＬＲ（ｈｏｍｅ ｓｕｂｓｃｒｉｂｅｒ ｓｙｓｔｅｍ／ｈｏｍｅ ｌｏｃａｔｉｏｎ ｒｅｇｉｓｔｅｒ）から複数の事前共有鍵を取り出すことと、
ｃ）ＩＫＣとＢＳＦとの間のＴＬＳ−ＰＳＫトンネルを確立することと、
ｄ）ＢＳＦから、トンネルを通じて複数の事前共有鍵のうち少なくとも１つをＩＫＣに送信することと、
ｅ）ＵＩＣＣとＩＫＣとの間のＴＬＳ−ＰＳＫトンネルを確立することと、
ｆ）ＵＩＣＣとＢＳＦとの間の少なくとも１つの加入者認証鍵を確立することと
を備えた方法。
２．事前にプロビジョニングされる対称鍵をＩＫＣにより直接に共有することをさらに備えた上記実施形態のいずれかにおける方法。
３．複数の鍵をＩＫＣに送信することと、
正しい鍵が識別されるまでＵＩＣＣを用いて妥当性検査することと
をさらに備えた上記実施形態のいずれかにおける方法。
４．妥当性検査することは、チャレンジ−レスポンスタイプの鍵検証を含む上記実施形態のいずれかにおける方法。
５．事前共有鍵の証拠をＵＩＣＣから受信することと、
証拠をＢＳＦに送信することと、
複数の事前共有鍵から正しい鍵を識別することと
をさらに含む上記実施形態のいずれかにおける方法。
６．要求メッセージを受信することであって、要求メッセージはペイロードとしてＩＫＣ識別子を含む、受信することをさらに含む上記実施形態のいずれかにおける方法。
７．事前共有鍵は、ＩＫＣとＢＳＦとの間のＴＬＳ−ＰＳＫトンネルを確立するのに使用される上記実施形態のいずれかにおける方法。
８．事前共有鍵は、ＵＩＣＣとＩＫＣとの間のトンネルを確立するのに使用される上記実施形態のいずれかにおける方法。
９．ＵＩＣＣによってＮＡＦ識別子を構成することをさらに含む上記実施形態のいずれかにおける方法。
１０．ＩＫＣおよびＢＳＦは、ＩＫＣ識別子について公開鍵ベースの暗号化および公開鍵ベースの暗号化解除を使用する上記実施形態のいずれかにおける方法。
１１．複数の異なる公開鍵から選択することであって、公開鍵は、ネットワークからブロードキャストされる、選択することをさらに含む上記実施形態のいずれかにおける方法。
１２．Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換プロトコルが使用される上記実施形態のいずれかにおける方法。
１３．公開鍵への共通インデックスを計算する方法であって、
ネットワークおよびＩＫＣによって２つの値について一致することであって、２つの値は、素数ｐおよび生成元ｇを含む、一致することと、
ネットワークが乱数（ＲＡＮＤi）を選択することと、
【００９５】
【数１０】
を計算することと、
ネットワークが
【００９６】
【数１１】
【００９７】
をＩＫＣに送信することと（１≦ＲＡＮＤi≦ｐ−２）、
ＩＫＣが乱数（ＦＲＥＳＨ）を計算することであって、ｇFRESH≡ｇFRESH ｍｏｄ ｐである、計算することと、
ｇFRESHをネットワークに送信することと（１≦ＦＲＥＳＨ≦ｐ−２）、
ネットワークが
【００９８】
【数１２】
【００９９】
を計算することと、
ＩＫＣが
【０１００】
【数１３】
【０１０１】
を計算することと
を備えた方法。
１４．ＩＫＣ識別子を含んでいるメッセージを暗号化することをさらに備えた上記実施形態のいずれかにおける方法。
１５．ＴＬＳ−ＰＳＫトンネリング確立処理中に公開鍵を交換することをさらに備えた上記実施形態のいずれかにおける方法。
１６．ＤＨ対応ＴＬＳ−ＰＳＫ用のＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿３ＤＥＳ＿ＥＤＥ＿ＣＢＣ＿ＳＨＡ暗号スイートをさらに備えた上記実施形態のいずれかにおける方法。
１７．ＤＨ対応ＴＬＳ−ＰＳＫ用のＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡをさらに備えた上記実施形態のいずれかにおける方法。
１８．ＤＨ対応ＴＬＳ−ＰＳＫ用のＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡをさらに備えた上記実施形態のいずれかにおける方法。
１９．セキュリティアソシエーションの方法であって、
ＵＩＣＣとＩＫＣとの間およびＩＫＣとＢＳＦとの間の情報を交換することであって、ＵＩＣＣ、ＩＫＣ、およびＢＳＦは交換をセキュアにするのにＴＳＬ−ＰＳＫトンネルを使用する、交換すること
を備えた方法。
２０．ＵＩＣＣ上の有効な加入者認証鍵について検査することをさらに備えた上記実施形態のいずれかにおける方法。
２１．ＵＩＣＣがそれとのセキュリティアソシエーションを確立することを望むＮＡＦのアイデンティティデータを、確立されたトンネル（ＴＵＩ）を介してＵＩＣＣから取り出すことをさらに備えた上記実施形態のいずれかにおける方法。
２２．ＵＩＣＣが複数のＮＡＦ固有鍵を導出することをさらに備えた上記実施形態のいずれかにおける方法。
２３．加入者認証鍵の確立のためにＵＩＣＣベースの強化を有するｇｅｎｅｒａｌ ｂｏｏｔｓｔｒａｐｐｉｎｇ ａｒｃｈｉｔｅｃｔｕｒｅ（ＧＢＡ＿Ｕ）を開始することをさらに備えた上記実施形態のいずれかにおける方法。
２４．複数のトンネルのうちの１つを介してＩＫＣからＢＳＦにアイデンティティデータを送信することをさらに備えた上記実施形態のいずれかにおける方法。
２５．少なくとも１つのＮＡＦに認証要求を送信することをさらに備えた上記実施形態のいずれかにおける方法。
２６．ＢＳＦにおいてＮＡＦから少なくとも１つの認証応答を受信することをさらに備えた上記実施形態のいずれかにおける方法。
２７．ＢＳＦが複数のＮＡＦ固有鍵を導出することをさらに備えた上記実施形態のいずれかにおける方法。
２８．複数のＮＡＦ固有鍵、ブートストラップ時刻、および鍵の有効期間をＢＳＦから複数のＮＡＦに転送することをさらに備えた上記実施形態のいずれかにおける方法。
２９．ＮＡＦからＢＳＦへ、ＮＡＦ固有鍵、鍵の有効期間、およびブートストラップ時刻の受信を示す肯定応答メッセージを送信することをさらに備えた上記実施形態のいずれかにおける方法。
３０．バルク・セキュリティ・アソシエーション・メッセージをＢＳＦからＩＫＣに送信することであって、バルク・セキュリティ・アソシエーション・メッセージはそれぞれが特定のＮＡＦに対応する複数のＮＡＦメッセージ認証コード（ＭＡＣNAF）を含む、送信することをさらに備えた上記実施形態のいずれかにおける方法。
３１．ＩＫＣがＢＳＦから受信したバルク・セキュリティ・アソシエーション・メッセージをＵＩＣＣに転送することをさらに備えた上記実施形態のいずれかにおける方法。
３２．ＮＡＦに固有のＭＡＣUICC_SA atをＵＩＣＣで計算することをさらに備えた上記実施形態のいずれかにおける方法。
３３．ＵＩＣＣによってバルク・セキュリティ・アソシエーション応答メッセージを生成すること をさらに備えた上記実施形態のいずれかにおける方法。
３４．ＮＡＦの対応するＭＡＣUICC_SAに対するＭＡＣIKCは一致しない場合に、セッションの失敗を検出することをさらに備えた上記実施形態のいずれかにおける方法。
３５．ＭＡＣIKCがそれに対応するＭＡＣUICC_SAと一致した場合に、成功を検出することをさらに備えた上記実施形態のいずれかにおける方法。
３６．ＮＡＦ固有鍵およびＭＡＣアルゴリズムを使用して成功応答を送信することをさらに備えた上記実施形態のいずれかにおける方法。
３７．ＩＫＣを介し、複数のトンネルを介してバルク・セキュリティ・アソシエーション応答メッセージをＢＳＦに送信することをさらに備えた上記実施形態のいずれかにおける方法。
３８．ＢＳＦによって、セキュリティアソシエーションの試みの失敗または成功の状況をＮＡＦに示すことをさらに備えた上記実施形態のいずれかにおける方法。
３９．ＮＡＦで成功状況を受信することと、
ＮＡＦ固有鍵、ブートストラップ時刻、および関連する鍵の有効期間を格納することと
をさらに備えた上記実施形態のいずれかにおける方法。
４０．端末とＵＭＴＳ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ（ＵＩＣＣ）との間の鍵を確立する方法であって、
２つのＴＬＳ−ＰＳＫトンネルを使用してセキュアな形で情報を交換すること
を含むことを特徴とする方法。
４１．内部鍵センター（ＩＫＣ）によって、ＵＩＣＣ上の少なくとも１つの有効な加入者認証鍵の存在を識別することと、
ブートストラッピングトランザクション識別子および少なくとも１つのＮＡＦ（ｎｅｔｗｏｒｋ ａｐｐｌｉｃａｔｉｏｎ ｆｕｎｃｔｉｏｎ）識別子をＵＩＣＣから取り出すことと
をさらに備えた上記実施形態のいずれかにおける方法。
４２．少なくとも１つの加入者認証鍵を確立するためにＵＩＣＣベースの強化を有するｇｅｎｅｒａｌ ｂｏｏｔｓｔｒａｐｐｉｎｇ ａｒｃｈｉｔｅｃｔｕｒｅ（ＧＢＡ＿Ｕ）処理を開始することと、
ブートストラッピングトランザクション識別子および少なくとも１つのＮＡＦ識別子をＵＩＣＣから取り出すことと
をさらに備えた上記実施形態のいずれかにおける方法。
４３．ＵＩＣＣとＩＫＣとの間のＴＬＳ−ＰＳＫトンネルを介して情報交換を送信することをさらに備えた上記実施形態のいずれかにおける方法。
４４．それぞれが要求されるＮＡＦのＮＡＦ識別子に対応する少なくとも１つのＩＫＣ鍵に関するアプリケーション要求をＩＫＣからＢＳＦ（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ）に送信することと、
ＩＫＣはブートストラッピングトランザクション識別子および少なくとも１つのＮＡＦ識別子をＫｓ＿ＩＫＣ＿ＮＡＦ（ＲＡＮＤｙ）ナンスについてＩＣＫによって生成された複数の対応するランダムチャレンジと一緒に送信することと
をさらに備えた上記実施形態のいずれかにおける方法。
４５．それぞれが要求されるＮＡＦのそれぞれに固有の少なくとも１つのＩＫＣ鍵を計算することをさらに備えた上記実施形態のいずれかにおける方法。
４６．少なくとも１つのＩＫＣ鍵および鍵の有効期間を含んでいるアプリケーション応答をＩＫＣに送信することをさらに備えた上記実施形態のいずれかにおける方法。
４７．ＩＫＣが、少なくとも１つのｃｏｕｎｔｅｒ ｌｉｍｉｔ値を生成することと、
少なくとも１つのローカル鍵を導出することと
をさらに備えた上記実施形態のいずれかにおける方法。
４８．ＩＫＣが、トンネルＴＵＩを介してアプリケーション要求メッセージをＵＩＣＣに送信することと、
ＮＡＦ識別子に固有のローカル鍵を作成するようにＵＩＣＣに要求することであって、要求は、ＮＡＦ識別子、端末識別子、端末アプリケーション識別子、ＵＩＣＣアプリケーション識別子、およびｃｏｕｎｔｅｒ ｌｉｍｉｔ値を含む、要求することと
をさらに備えた上記実施形態のいずれかにおける方法。
４９．端末がＭＡＣIKCを計算することをさらに備えた上記実施形態のいずれかにおける方法。
５０．ＵＩＣＣが、受信されたＮＡＦ識別子に関連するＫｓ＿ｉｎｔ＿ＮＡＦおよびブートストラッピングトランザクション識別子を取り出すことをさらに備えた上記実施形態のいずれかにおける方法。
５１．ｉｎｔ＿ＮＡＦ鍵およびＲＡＮＤｙに基づいてＩＫＣ−ＮＡＦ鍵を導出することをさらに備えた上記実施形態のいずれかにおける方法。
５２．ＵＩＣＣがローカル鍵を導出することであって、ローカル鍵は、ＩＫＣ−ＮＡＦ鍵、ブートストラッピングトランザクション識別子、端末識別子、ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（ＩＣＣＩＤ）、端末アプリケーション識別子、ＵＩＣＣアプリケーション識別子、ＲＡＮＤｘ、およびＣｏｕｎｔｅｒ Ｌｉｍｉｔの関数として決定される、導出すること
をさらに備えた上記実施形態のいずれかにおける方法。
５３．ＵＩＣＣが端末から受信されたＭＡＣIKC値を検証することをさらに備えた上記実施形態のいずれかにおける方法。
５４．ＵＩＣＣが、鍵一致手順を終了することと、
ローカル鍵導出要求に応答してＭＡＣ検証失敗メッセージを返すことと
をさらに備えた上記実施形態のいずれかにおける方法。
５５．ＵＩＣＣがローカル鍵および関連するパラメーターを格納することと、
ＵＩＣＣが鍵ローカル鍵およびＭＡＣアルゴリズムを使用してＡＳＣＩＩ符号化されたストリングのＭＡＣを含んでいるローカル鍵導出応答を送信することと
をさらに備えた上記実施形態のいずれかにおける方法。
５６．ＩＫＣがローカル鍵および鍵の有効期間を格納することをさらに備えた上記実施形態のいずれかにおける方法。
５７．ローカル鍵から実際の共有鍵を導出することと、
導出された共有鍵を更新することと
をさらに備えた上記実施形態のいずれかにおける方法。
５８．認証することおよび暗号化することが、ｒｅｍｏｔｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｄｉａｌ−ｉｎ ｕｓｅｒ ｓｅｒｖｉｃｅを通じて拡張認証プロトコルを組み合わせることをさらに備えた上記実施形態のいずれかにおける方法。
５９．内部鍵センターを使用してセキュアに通信する方法であって、携帯電話機（ＵＥ）のＭＴＭ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅ）を使用して鍵をセキュアにすることを備えた方法。
６０．ＩＫＣがＭＴＭ内にローカル鍵を格納することをさらに備えた上記実施形態のいずれかにおける方法。
６１．ローカル鍵から導出されたすべてのプラットフォーム固有鍵またはアプリケーション固有鍵をＭＴＭによって格納することをさらに備えた上記実施形態のいずれかにおける方法。
６２．端末が、ローカル鍵を使用する前に、ローカル鍵を使用するようにＩＫＣに要求することをさらに備えた上記実施形態のいずれかにおける方法。
６３．ＩＫＣは、ＭＴＭが端末の保全性を検証するように要求することをさらに備えた上記実施形態のいずれかにおける方法。
６４．ＭＴＭが端末の保全性を検証することをさらに備えた上記実施形態のいずれかにおける方法。
６５．ＩＫＣは、ＭＴＭが、それ自体とＵＩＣＣとの間の通信に使用される、端末によって要求される複数の鍵を公開すること認証することをさらに備えた上記実施形態のいずれかにおける方法。
６６．少なくとも１つのローカル鍵をＭＴＭから端末に公開することをさらに備えた上記実施形態のいずれかにおける方法。
６７．端末が、ＵＩＣＣとの少なくとも１つのセキュアチャネルを確立するためにローカル鍵を送信することをさらに備えた上記実施形態のいずれかにおける方法。
６８．ＵＩＣＣによって実行される上記実施形態のいずれかにおける方法。
６９．ＢＳＦによって実行される上記実施形態のいずれかにおける方法。
７０．ＷＴＲＵ（ワイヤレス送受信ユニット）によって実行される上記実施形態のいずれかにおける方法。
７１．基地局によって実行される上記実施形態のいずれかにおける方法。
７２．ＩＫＣによって実行される上記実施形態のいずれかにおける方法。
【技術分野】
【０００１】
本発明は、ワイヤレス通信に関し、より詳細には、ＵＩＣＣと端末との間のセキュア通信方法に関する。
【背景技術】
【０００２】
ＵＭＴＳセルラーワイヤレス通信システムのＲｅｌｅａｓｅ ７において、標準化制定団体３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）は、既存のＡＫＡ（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ ｋｅｙ ａｇｒｅｅｍｅｎｔ）処理を強化する技術仕様ＴＳ ３３．２２０−７８０を起草した。ＴＳ ３３．２２０に記載された、より新しいＡＫＡ処理は、ＵＩＣＣ（ＵＭＴＳ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）およびＨＬＲ／ＨＳＳ（Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ／Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｙｓｔｅｍ）を組み入れるＷＴＲＵ（ｗｉｒｅｌｅｓｓ ｔｒａｎｓｍｉｔ／ｒｅｃｅｉｖｅ ｕｎｉｔ）を伴う処理を指定する。
【０００３】
図１は、ＡＫＡ処理に対して想像されたネットワーク要素およびそれぞれのインターフェースを示す。ＢＳＦ（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ）は、ＭＮＯ（ｍｏｂｉｌｅ ｎｅｔｗｏｒｋ ｏｐｅｒａｔｏｒ）の制御の下にあり、ＷＴＲＵおよびＨＳＳといっしょにＧＢＡ＿Ｕ（ＵＩＣＣベースの強化を伴うＧＢＡ（ｇｅｎｅｒｉｃ ｂｏｏｔｓｔｒａｐｐｉｎｇ ａｒｃｈｉｔｅｃｔｕｒｅ））に加わって、ネットワークとＷＴＲＵとの間の共有秘密を確立するネットワーク要素の一部である。ＮＡＦ（ｎｅｔｗｏｒｋ ａｐｐｌｉｃａｔｉｏｎ ｆｕｎｃｔｉｏｎ）は、ネットワーク要素の一部としてホスティングされて、ＷＴＲＵとＮＡＦとの間の通信経路をセキュアにする鍵を導出するために、ＧＢＡによって確立された共有秘密を使用する。ＳＬＦ（ｓｕｂｓｃｒｉｂｅｒ ｌｏｃａｔｉｏｎ ｆｕｎｃｔｉｏｎ）は、ＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｙｓｔｅｍ）の詳細を獲得するためにＢＳＦ（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ）によって使用され、このＨＳＳの詳細は、ＢＳＦが事前定義のＨＳＳによって構成または管理されないときに、必要な加入者固有データを含む。ＨＳＳは、すべてのＵＳＳ（ｕｓｅｒ ｓｅｃｕｒｉｔｙ ｓｅｔｔｉｎｇ）を格納して、加入者は、ＵＩＣＣ上に複数のＩＳＩＭ（ＩＰ ｍｕｌｔｉｍｅｄｉａ ｓｅｒｖｉｃｅｓ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）アプリケーションかＵＳＩＭ（ｕｓｅｒ ｓｅｒｖｉｃｅｓ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）アプリケーションかのどちらかを有する。ＨＳＳは、１つまたは複数のプライベートアイデンティティにマッピングできる１つまたは複数のＧＵＳＳ（ＧＢＡ ｕｓｅｒ ｓｅｃｕｒｉｔｙ ｓｅｔｔｉｎｇ）を含むことができる。Ｕｂは、ＷＴＲＵとＢＳＦとの間の参照点を指す。ＷＴＲＵとＢＳＦとの間の相互認証手順は、この参照点で行われて、セッション鍵は、３ＧＰＰ ＡＫＡインフラストラクチャに基づいてブートストラップされる。Ｕａは、ＷＴＲＵと、アプリケーションプロトコルを保持するＮＡＦとの間の参照点であり、参照点Ｕｂを通じたＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡの結果としてＷＴＲＵとＢＳＦとの間で一致の鍵材料に基づいて鍵を導出することによってセキュアにされる。Ｚｎは、ＮＡＦとＢＳＦとの間の参照点であり、（以前のＵｂを通じたＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡプロトコル中に一致の）鍵材料およびアプリケーション固有のＵＳＳをＢＳＦから獲得するのにＮＡＦによって使用される。Ｚｈは、ＢＳＦとＨＳＳとの間の参照点であり、認証情報およびＧＵＳＳをＨＳＳから検索するのにＢＳＦによって使用される。Ｄｚは、ＢＳＦとＳＬＦとの間の参照点であり、加入者固有情報を含むＨＳＳの名前を検索するのにＢＳＦによって使用される。
【０００４】
２つの手順を、ＴＳ ３３．２２０において検討する。１つ目は、ＧＢＡ＿Ｕ（ＵＩＣＣによって強化されたＧＢＡ）処理であり、２つ目は、セキュリティアソシエーション（ＳＡ）処理である。
【０００５】
ＧＢＡ＿Ｕ処理において、ＵＩＣＣおよびＢＳＦは、互いを相互に認証して、ＵＩＣＣとＨＬＲ／ＨＳＳとの間において共有される加入者認証鍵Ｋから導出することによって、ＧＢＡ＿Ｕ鍵と呼ばれる鍵Ｋｓを確立する。
【０００６】
図２を参照しながら、ＧＢＡ＿Ｕ処理のステップを示して、さらに、次のように説明する。ＭＥは、ステップＳ１において、ＧＢＡ＿Ｕ処理を開始するためにＨＴＴＰ要求をＢＳＦに送信する。ＭＥは、ＨＴＴＰ要求のｕｓｅｒｎａｍｅパラメーターフィールドにユーザーアイデンティティ（ＴＭＰＩ（ｔｅｍｐｏｒａｒｙ ＩＰ ｍｕｌｔｉｍｅｄｉａ ｐｒｉｖａｔｅ ｉｄｅｎｔｉｔｙ）またはＩＭＰＩ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｐｒｉｖａｔｅ Ｉｄｅｎｔｉｔｙ））を挿入する。ＢＳＦは、ステップＳ２において、認証ベクトル（ＡＶ＝ＲＡＮＤ‖ＡＵＴＮ‖ＸＲＥＳ‖ＣＫ‖ＩＫ）およびＧＵＳＳ（ＧＢＡ ｕｓｅｒ ｓｅｃｕｒｉｔｙ ｓｅｔｔｉｎｇ）をＨＬＲ／ＨＳＳから（参照点Ｚｈを通じて）とってくる。ただし、
【０００７】
【数１】
【０００８】
である。次に、ＢＳＦは、ＭＡＣ*
【０００９】
【数２】
【００１０】
を計算する。ＭＡＣは、ＲＡＮＤおよびＡＵＴＮの保全性をセキュアにするのに使用される。ＢＳＦは、ステップＳ３において、ＨＴＴＰ ４０１ Ｕｎａｕｔｈｏｒｉｚｅｄ ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ： Ｄｉｇｅｓｔメッセージにて、ＲＡＮＤおよびＡＵＴＮ*（＝ＳＱＮ ｘｏｒ ＡＫ‖ＡＭＦ‖ＭＡＣ*）をＭＥに転送し、ＸＲＥＳ、ＣＫ、およびＩＫを格納する。ＭＥは、ステップＳ４において、受信したＲＡＮＤおよびＡＵＴＮ*を、ＨＴＴＰ ４０１ Ｕｎａｕｔｈｏｒｉｚｅｄ ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅ： ＤｉｇｅｓｔメッセージにてＵＩＣＣへ転送する。ＵＩＣＣは、ステップＳ５において、ＡＫＡアルゴリズムを実行する、すなわち、ＩＫおよびＸＭＡＣを計算し、次に、ＵＩＣＣは、ＡＵＴＮ（すなわち、
【００１１】
【数３】
【００１２】
）を検査して、チャレンジが認証されたネットワークからであることを検証する。すなわち、ＵＩＣＣは、ＣＫおよびＲＥＳをさらに計算する。これは、セッション鍵ＣＫおよびＩＫの作成に帰着する。ただし、ＢＳＦとＵＩＣＣとの両方においてＫｓ＝ＣＫ‖ＩＫである。ＵＩＣＣは、ステップＳ６において、ＲＥＳをＭＥへ転送する。ＭＥは、ステップＳ７において、別のＨＴＴＰ要求をＢＳＦへ送信し、このＨＴＴＰ要求は、ＲＥＳを使用して計算されたＤｉｇｅｓｔ ＡＫＡレスポンスを含む。ＢＳＦは、ステップＳ８において、受信したＲＥＳをＸＲＥＳと比較することによって、ＵＥの信頼性を検証して、ステップＳ９において、Ｋｓ＝ＣＫ‖ＩＫおよびブートストラッピングトランザクション識別子（Ｂ−ＴＩＤ）を作成する。ＢＳＦは、ステップＳ１０において、認証の成功を示すために、Ｂ−ＴＩＤおよびＫｅｙ Ｌｉｆｅｔｉｍｅを含む２００ ＯＫメッセージを送り返す。ＭＥは、ステップＳ１１において、Ｂ−ＴＩＤおよびＫｅｙ ＬｉｆｅｔｉｍｅをＵＩＣＣへ送信する。ＵＩＣＣは、ステップＳ１２において、Ｋｓ＝ＣＫ‖ＩＫ、Ｂ−ＴＩＤおよびＫｅｙ Ｌｉｆｅｔｉｍｅを格納する。
【００１３】
図２に示されたＧＢＡ＿Ｕ処理の終わりに、ＵＩＣＣとＢＳＦとの両方が、例えばセキュリティ・アソシエーション・ステージなどのより後のステージに必要な場合に、それぞれ、ＮＡＦ（Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｆｕｎｃｔｉｏｎ）固有鍵Ｋｓ＿ｅｘｔ＿ＮＡＦおよびＫｓ＿ｉｎｔ＿ＮＡＦを導出するのに、それらの両方が有しているＫｓを使用できる状態にある。これらの導出された鍵Ｋｓ＿ｅｘｔ＿ＮＡＦおよびＫｓ＿ｉｎｔ＿ＮＡＦは、後に、参照点Ｕａをセキュアにするのに使用される。Ｋｓ＿ｅｘｔ＿ＮＡＦは、ＵＩＣＣにおいて、Ｋｓ＿ｅｘｔ＿ＮＡＦ＝ＫＤＦ（Ｋｓ，“ｇｂａ−ｍｅ”，ＲＡＮＤ，ＩＭＰＩ，ＮＡＦ＿Ｉｄ）として計算され、Ｋｓ＿ｉｎｔ＿ＮＡＦは、ＵＩＣＣにおいて、Ｋｓ＿ｉｎｔ＿ＮＡＦ＝ＫＤＦ（Ｋｓ，“ｇｂａ−ｕ，ＲＡＮＤ，ＩＭＰＩ，ＮＡＦ＿Ｉｄ）として計算される。すなわち、ＮＡＦ＿Ｉｄ＝ＮＡＦのＦＱＤＮ‖Ｕａセキュリティプロトコル識別子である。ＫＤＦは、ＴＳ ３３．２２０−７８０ Ａｎｎｅｘ Ｂに指定された鍵導出関数である。
【００１４】
ＫｓがＧＢＡ＿Ｕ処理において確立された後に、セキュリティアソシエーション処理が、ＮＡＦとＷＴＲＵとの間で行われる。セキュリティアソシエーション処理の目的は、ＷＴＲＵおよびＮＡＦが、ＧＢＡ鍵（Ｋｓ＿ｉｎｔ＿ＮＡＦおよび／またはＫｓ＿ｅｘｔ＿ＮＡＦ）を使用するかどうかを決定することである。デフォルトにより、Ｋｓ＿ｅｘｔ＿ＮＡＦは、ＷＴＲＵとＮＡＦとの間においてパケットを暗号化するのに使用される鍵ストリームを後に導出するのに使用される。しかし、Ｋｓ＿ｉｎｔ＿ＮＡＦまたはＫｓ ｉｎｔ＿ＮＡＦとＫｓ＿ｅｘｔ＿ＮＡＦとの両方が使用される場合には、これを、セキュリティアソシエーション処理において一致しなければならない。上記の一致が、デフォルト選択を覆すものであることを補足する。さらに、鍵選択指示を、アプリケーション固有ＵＳＳにおいて指定できる。
【００１５】
図３を参照するとセキュリティ・アソシエーション・ステップが示され、ＷＴＲＵ（ＭＥ）は、通信を開始する前に、（ＧＢＡ＿Ｕによって作成された）Ｋｓが現存して最新であることを検査し、そうでない場合には、ＧＢＡ＿Ｕを初期化して、Ｋｓを作成する。Ｋｓが有効であって最新である場合には、ＭＥは、ステップＳ１において、ＵＩＣＣからＢ−ＴＩＤを取り出し、ＵＩＣＣは、Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦ鍵を導出する。ＭＥは、ステップＳ２において、アプリケーション要求の一部としてＢ−ＴＩＤをＮＡＦに送信する。ＮＡＦは、ステップＳ３において、認証要求（Ｂ−ＴＩＤおよびＮＡＦ−ＩＤを含む）をＢＳＦに送信して、Ｚｎ参照点を介してＢ−ＴＩＤに対応する鍵を送信する。ＢＳＦは、ステップＳ４において、Ｋｓ＿ｉｎｔ＿ＮＡＦおよびＫｓ＿ｅｘｔ＿ＮＡＦを導出する。ＮＡＦは、ＧＢＡ＿Ｕ対応である場合に、ステップＳ４において両方の鍵を送付し、そうでない場合には、例えばブートストラップ時刻、鍵の有効期間等のある他の情報と一緒にＫｓ＿ｅｘｔ＿ＮＡＦだけを供給する。次に、ＮＡＦは、ＵＳＳがＢＳＦから返される場合にはＵＳＳを調べて、鍵選択指示が存在するかどうかを検査し（存在する場合には、ＵＳＳ内で指示された鍵（１つまたは複数）が使用される）、これらの鍵（１つまたは複数）を格納する。ＮＡＦは、ステップＳ７において、ＮＡＦ鍵Ｋｓ＿ｅｘｔ／ｉｎｔ＿ＮＡＦを現在有していることを示すアプリケーション回答（Ａｐｐｌｉｃａｔｉｏｎ Ａｎｓｗｅｒ）をＷＴＲＵに送信する。
【００１６】
最近、３ＧＰＰ ＴＳ ３３．１１０−７００により、ＵＩＣＣと端末との間のプラットフォームおよびアプリケーション固有鍵Ｋｓ＿ｌｏｃａｌの確立を提案された。上記の鍵は、ＵＩＣＣと端末との間のチャネルをセキュアにするのに、ＵＩＣＣおよび端末によって使用されることを意図される。
【００１７】
図４において、端末がＵＩＣＣ保持デバイスの一部である場合の参照点のアーキテクチャを示す。図４のネットワーク要素は、ＵＩＣＣホスティングデバイスの提供を除いて、図１に示されたものと同一である。ＵＩＣＣと端末との間でＫｓ＿ｌｏｃａｌを確立するプロトコルフローを、図５に示す。端末は、ステップＳ１において、Ｂ−ＴＩＤおよび対応する有効期間をＵＩＣＣから取ってくることによって、有効なＫｓ鍵がＵＩＣＣ内に存在するかどうかを検査する。有効な鍵ｋｓがＵＩＣＣ内で使用可能ではない場合には、端末は、ＢＳＦとＵＩＣＣとの間でＫｓ鍵を確立するためにＧＢＡブートストラッピング手順を要求する。次に、端末は、有効なＫｓ＿ｉｎｔ＿ＮＡＦが存在するかどうかを検査し、そうである場合には、ＮＡＦ鍵センターに対応するＮＡＦ＿ＩＤのＢ−ＴＩＤ値を取り出すようにＵＩＣＣに要求する。端末は、ＮＡＦ＿ＩＤを有しない場合には、ステップＳ２においてその値を取り出すようにＵＩＣＣに要求する。ＵＩＣＣは、ステップＳ３において、ＮＡＦ鍵センターに対応するＮＡＦ＿ＩＤおよびＢ−ＴＩＤを戻す。端末およびＮＡＦ鍵センターは、ステップＳ４において、端末とＮＡＦ鍵センターとの間の証明書ベースの相互認証を用いて、ＨＴＴＰＳタイプのトンネルを確立する。端末は、ステップＳ５において、トンネルを介して「サービス要求」メッセージを送信し、このメッセージのペイロードは、Ｂ−ＴＩＤ、端末識別子（Ｔｅｒｍｉｎａｌ＿ＩＤ）、スマートカード識別子（ＩＣＣＩＤ）、鍵Ｋｓ＿ｌｏｃａｌの確立を必要とするＵＩＣＣアプリケーションのアプリケーション識別子（ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ）および端末アプリケーションのアプリケーション識別子（Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ）、ならびに変数値ＲＡＮＤｘを含む。アプリケーション固有鍵ではなくプラットフォーム固有鍵が望まれる場合には、パラメーターＵＩＣＣ＿ａｐｐｌｉ＿ＩＤおよびＴｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤは、静的ＡＳＣＩＩ符号化ストリング“ｐｌａｔｆｏｒｍ”と等しくなる。ＮＡＦ鍵センターは、ステップＳ６において、端末ＩＤ／ＩＣＣＩＤがブラックリストに載せられていないかどうか、または鍵確立手順がターゲットにされたアプリケーションについて許可されるかどうかを判定する。これらの条件が満足されない場合には、ＮＡＦ鍵センターは、適当なエラーコードを応答し、端末とのＴＬＳ接続を終了する。ＮＡＦ鍵センターは、ステップＳ６において、ＢＳＦに連絡し、Ｂ−ＴＩＤおよびそれ自体のＮＡＦ＿ＩＤを信用証明書要求内で送信する（この要求の目的は、関連する鍵Ｋｓ＿ｉｎｔ＿ＮＡＦおよびＫｓ＿ｅｘｔ＿ＮＡＦを返すようにＢＳＦに要求することである。Ｋｓ＿ｌｏｃａｌが、Ｋｓ＿ｉｎｔ＿ＮＡＦだけから生成されることに留意されたい）。ＢＳＦは、Ｋｓ＿ｉｎｔ＿ＮＡＦおよびＫｓ＿ｅｘｔ＿ＮＡＦを導出し、ステップＳ７において、これらの鍵および例えばブートストラップ時刻、鍵の有効期間等の関連情報をＮＡＦ鍵センターに戻す。ＮＡＦ鍵センターは、ステップＳ８において、ＵＩＣＣで使用される適切な１６オクテットのｃｏｕｎｔｅｒ ｌｉｍｉｔを生成して、端末において使用される導出された鍵Ｋｓ＿ｌｏｃａｌに鍵の有効期間を関連付ける。次に、ＮＡＦ鍵センターは、次のように鍵導出関数（ＫＤＦ）を使用して、Ｋｓ＿ｉｎｔ＿ＮＡＦからＫｓ＿ｌｏｃａｌを導出する。
Ｋｓ＿ｌｏｃａｌ＝ＫＤＦ（Ｋｓ＿ｉｎｔ＿ＮＡＦ，Ｂ−ＴＩＤ，Ｔｅｒｍｉｎａｌ＿ＩＤ，ＩＣＣＩＤ，Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ，ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ，ＲＡＮＤｘ，ｃｏｕｎｔｅｒ ｌｉｍｉｔ）
【００１８】
ステップＳ９において、ＮＡＦ鍵センターは、ステップＳ４において確立されたＨＴＴＰＳトンネルを介して、端末にＢ−ＴＩＤ、鍵の有効期間、およびｃｏｕｎｔｅｒ ｌｉｍｉｔと一緒にＫｓ＿ｌｏｃａｌを送付する。ステップＳ１０において、端末は、それ自体のストレージに、Ｋｓ＿ｌｏｃａｌならびに鍵の有効期間、ＩＣＣＩＤ、Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ、およびＵＩＣＣ＿ａｐｐｌｉ＿ＩＤなどの関連するパラメーターを格納する。ステップＳ１１において、端末は、Ｋｓ＿ｌｏｃａｌを生成するようにＵＩＣＣに要求し、ＵＩＣＣに鍵材料（ＮＡＦ＿ＩＤ、Ｔｅｒｍｉｎａｌ ＩＤ、Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ、ＲＡＮＤｘ、およびｃｏｕｎｔｅｒ ｌｉｍｉｔ値）をＭＡＣ（＝ＨＭＡＣ−ＳＨＡ−２５６［Ｋｓ＿ｌｏｃａｌ，ＮＡＦ＿ＩＤ‖Ｔｅｒｍｉｎａｌ＿ＩＤ‖ＩＣＣＩＤ‖Ｔｅｒｍ＿ａｐｐｌｉ＿ＩＤ‖ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ‖ＲＡＮＤＸ‖Ｃｏｕｎｔｅｒ Ｌｉｍｉｔ］）と一緒に送信し、このＭＡＣは、１６オクテット＝１２８ビットに切り詰められる。ＵＩＣＣは、ステップＳ１２において、Ｋｓ＿ｉｎｔ＿ＮＡＦおよびＢ−ＴＩＤを取り出し、Ｋｓ＿ｌｏｃａｌ＝ＫＤＦ（Ｋｓ＿ｉｎｔ＿ＮＡＦ，Ｂ−ＴＩＤ，Ｔｅｒｍｉｎａｌ＿ＩＤ，ＩＣＣＩＤ，Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ，ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ，ＲＡＮＤｘ，Ｃｏｕｎｔｅｒ Ｌｉｍｉｔ）を生成する。ＵＩＣＣは、ＭＡＣ’＝（ＨＭＡＣ−ＳＨＡ−２５６［Ｋｓ＿ｌｏｃａｌ，ＮＡＦ＿ＩＤ‖Ｔｅｒｍｉｎａｌ＿ＩＤ‖ＩＣＣＩＤ‖Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ‖ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ‖ＲＡＮＤＸ‖Ｃｏｕｎｔｅｒ Ｌｉｍｉｔ］）を計算し、このＭＡＣ’は、１６オクテット＝１２８ビットに切り詰められる。計算されたＭＡＣ’は、受信されたＭＡＣと比較される。ＭＡＣ’およびＭＡＣが一致しない場合には、ステップＳ１３において、失敗メッセージが端末に送り返される。ＭＡＣとＭＡＣ’との間に一致がある場合には、Ｋｓ＿ｌｏｃａｌならびにＴｅｒｍｉｎａｌ＿ＩＤ、Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ、およびｃｏｕｎｔｅｒ ｌｉｍｉｔなどの関連するパラメーターが、ＵＩＣＣ内に格納される。ステップＳ１３において、ＵＩＣＣは、Ｋｓ＿ｌｏｃａｌおよびＭＡＣアルゴリズムＨＭＡＣ−ＳＨＡ−２５６を使用して作成された、１６オクテットに切り詰められた「検証成功メッセージ」を端末に返す。
【００１９】
図５は、ＵＩＣＣと端末との間の鍵の確立を示す。ＴＳ３３．１１０ ｖ７．２．０からのローカル鍵確立処理は、ＨＴＴＰＳトンネルの確立に依存する（図５のステップＳ４を参照されたい）。ＴＳ３３．１１０ ｖ７．２．０において、ＨＴＴＰＳトンネルが、後にそのトンネルを設定する際に使用される公開鍵を証明する加入者証明書を使用して確立されることが指定されている。最近の３ＧＰＰ仕様ＴＳ３３．２２１ ｖ７．０．０は、そのような加入者証明書が図６に示されたステップを使用して確立されるステップを指定する。
【００２０】
図６のシーケンス図は、ＨＴＴＰダイジェスト認証と共にＰＫＣＳ（Ｐｕｂｌｉｃ Ｋｅｙ Ｃｒｙｐｔｏｇｒａｐｈｙ Ｓｔａｎｄａｒｄ）＃１０を使用する時の証明書要求を説明するものである。ステップＳ１において、ＷＴＲＵは、公開鍵基盤（ＰＫＩ）ポータルに空のＨＴＴＰ要求を送信する。ＰＫＩポータルは、ステップＳ２において、ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダーを含むＨＴＴＰ応答コード４０１“Ｕｎａｕｔｈｏｒｉｚｅｄ”を使用して、認証チャレンジレスポンスを送信する。このヘッダーは、ＨＴＴＰダイジェスト認証を使用するようにＷＴＲＵに指示する。ＷＴＲＵは、ｕｓｅｒｎａｍｅとしてＢＳＦから受信したブートストラッピングトランザクション識別子（Ｂ−ＴＩＤ）およびＮＡＦ固有セッション鍵Ｋｓ＿ＮＡＦを使用してＡｕｔｈｏｒｉｚａｔｉｏｎヘッダー値を計算することによって、ＨＴＴＰ要求を生成する。証明書要求が、鍵の発信証明についてＷＩＭ（ｗｉｒｅｌｅｓｓ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）アプリケーションによる余分な保証を必要とする場合には、ＷＴＲＵは、鍵の発信証明生成に必要なパラメーターを含むＷＩＭチャレンジ要求を生成する。ＷＴＲＵは、ステップＳ４において、ＰＫＩポータルにＨＴＴＰ要求を送信し、この要求にそのＷＩＭチャレンジ要求を含める。ステップＳ５において、ＰＫＩポータルは、ＮＡＦとして働いて、要求を受信し、Ｂ−ＴＩＤを使用してＢＳＦからＮＡＦ固有セッション鍵Ｋｓ＿ＮＡＦを取ってくることと、Ｋｓ＿ＮＡＦを使用して対応するダイジェスト値を計算することと、計算された値を認証ヘッダー内で受信された値と比較することとによって、認証ヘッダーを検証する。検証が成功であり、ＷＩＭアプリケーションの余分な保証が必要である場合には、ＰＫＩポータルは、ＰＫＩポータル固有ユーザー・セキュリティ・セッティングを使用して、ＷＩＭチャレンジレスポンスを計算することができる。ＰＫＩポータルは、ステップＳ６において、後続のＰＫＣＳ＃１０要求生成に必要な追加パラメーターを含んでいるＷＩＭチャレンジレスポンスを送り返す。ＰＫＩポータルは、セッション鍵Ｋｓ＿ＮＡＦを使用して、このレスポンスを保全性保護し、認証することができる。ＷＴＲＵは、ステップＳ７においてＰＫＣＳ＃１０要求を生成し、ステップＳ８において、これを、ＨＴＴＰダイジェスト要求を使用してＰＫＩポータルに送信する。秘密鍵がＷＩＭアプリケーション内に格納される場合に、ＭＥは、ＷＩＭアプリケーションにＡｓｓｕｒａｎｃｅＩｎｆｏを要求し、供給される場合にこれをＰＫＣＳ＃１０要求に含める。エンロールメント要求は、ＰＫＣＳ ＃１０証明書エンロールメントフォーマットに従う。この要求にＡｓｓｕｒａｎｃｅＩｎｆｏを追加することは、ＯＭＡのＥＣＭＡ Ｓｃｒｉｐｔ仕様で定義されている。ＡｓｓｕｒａｎｃｅＩｎｆｏは、鍵処理に関するｐｒｏｏｆ ｏｆ ｏｒｉｇｉｎを提供する（たとえば、ＷＩＭアプリケーションを識別し、鍵がその中に格納されていることの証明を提供する）。ＷＴＲＵは、証明レスポンスの所望のフォーマットすなわち、証明書、証明書へのポインタ（たとえば、ＵＲＬ）、または完全な証明書チェーン（すなわち、発行された証明書から対応するルート証明書まで）を指示することができる。ＷＴＲＵは、証明書エンロールメントに関するＨＴＴＰ要求をＰＫＩポータルに送信する。このエンロールメント要求は、次のようにならなければならない。
【００２１】
【表１】
【００２２】
ただし、＜ｂａｓｅ ＵＲＬ＞は、サーバ／プログラムを識別する。ラベル＜ｉｎｄｉｃａｔｉｏｎ＞は、ＷＴＲＵに関する所望のレスポンスタイプをＰＫＩポータルに指示するのに使用される。可能な値は、加入者証明書のみの“ｓｉｎｇｌｅ”、加入者証明書へのポインタの“ｐｏｉｎｔｅｒ”、または完全な証明書チェーンの“ｃｈａｉｎ”である。さらに、ｏｔｈｅｒ ＵＲＬ ｐａｒａｍｅｔｅｒｓは、追加のオプションのＵＲＬパラメーターである。
【００２３】
ＰＫＣＳ＃１０要求は、ステップＳ９において、ＰＫＩポータルによって処理される。ＰＫＩポータルが、認証局（ＣＡ）である場合には、証明書は、ＰＫＩポータルで生成される。ＰＫＩポータルが、ＣＡではなく登録機関（ＲＡ）でしかない場合には、ＰＫＣＳ＃１０要求は、ＩＥＴＦのＲＦＣ ２７９７で指定されたＣＭＣまたはＩＥＴＦのＲＦＣ ２５１０およびＩＥＴＦのＲＦＣ ２５１１で指定されたＣＭＰなどの使用可能な任意のプロトコルを使用してＣＡに転送される。この場合に、ＰＫＣＳ＃１０要求が処理され、証明書が作成された後に、新しい証明書が、ＰＫＩポータルに返される。どちらの場合でも、ＰＫＩポータルは、ステップＳ１０において、証明書、ＯＭＡのＷｉｒｅｌｅｓｓ ＰＫＩ仕様（ＷＰＫＩ）のｃｌａｕｓｅ ７．４で定義された証明書へのポインタ、または発行された証明書からルート証明書までの完全な証明書チェーンを含むＨＴＴＰ応答を生成する。このＨＴＴＰ応答が、加入者証明書自体を含む場合には、このＨＴＴＰ応答は、ｂａｓｅ６４符号化されなければならず、次のように境界を定めることができる。
【００２４】
【表２】
【００２５】
このＨＴＴＰ応答が、証明書へのポインタを含む場合には、ＯＭＡのＷＰＫＩのｓｕｂｃｌａｕｓｅ ７．３．５で定義されたＣｅｒｔＲｅｓｐｏｎｓｅ構造体を使用しなければならず、このＨＴＴＰ応答は、次のように境界を定めることができる。
【００２６】
【表３】
【００２７】
このＨＴＴＰ応答が、で定義されたＰｋｉＰａｔｈ構造体内に完全な証明書チェーンを含み、ｂａｓｅ６４符号化されなければならない場合には、
【００２８】
【表４】
【００２９】
証明書チェーンのｃｏｎｔｅｎｔ−ｔｙｐｅヘッダー値は、“ａｐｐｌｉｃａｔｉｏｎ／ｐｋｉｘ−ｐｋｉｐａｔｈ”である。ＰＫＩポータルは、証明書または証明書へのポインタがＷＴＲＵに送信される場合に、セッション鍵Ｋｓ＿ＮＡＦを使用して、応答を保全性保護し、認証することができる。ＰＫＩポータルは、完全な証明書チェーンがＷＴＲＵに送信される場合に、保全性保護を使用し、応答を認証しなければならない。ＷＴＲＵが加入者証明書または加入者証明書へのＵＲＬを受信する時に、それが、ステップＳ１１において、ローカル証明書管理システムに格納される。
【００３０】
（従来技術の問題）
ＧＢＡ＿Ｕ処理とセキュリティアソシエーション処理との両方が、プライバシ問題を有する。なぜならば、両方の処理で、ＵＩＣＣおよび端末が、それらの間ならびに端末とネットワーク（ＢＳＦ、ＮＡＦ）との間で、ＵＩＣＣと端末との間のセキュアローカルチャネルまたは端末とＢＳＦ（またはＮＡＦ）との間のセキュアチャネルが形成される前に、オープンチャネルを介して多数のパラメーターを交換するからである。たとえば、ＢＳＦからＵＩＣＣへのＡＵＴＮおよびＲＡＮＤなどのパラメーターの転送は、オープンチャネル上において平文の状態ある。ＵＩＣＣとＢＳＦとの間の保全性保護が、認証情報（ＡＵＴＮ）および乱数（ＲＡＮＤ）について提供され、このＲＡＮＤは、ナンス（すなわち、それぞれ、メッセージ認証コード（ＭＡＣ）（および想定ＭＡＣ）（ＸＭＡＣ）ならびにユーザー応答（ＲＥＳ）および想定ＲＥＳ（ＸＲＥＳ）の使用によってセキュリティエンジニアリングにおいて１回だけ使用される数またはビットストリームとして）を作動する。しかし、チャネルがオープンなので、スヌーピングの危険、プライバシに対する懸念の発生、暗号解析に起因する最終的なＫの露出の危険がある。
【００３１】
従来技術は、セッション鍵のオープンチャネル転送に起因する問題をさらに含む。ＵＩＣＣの内部で導出される（導出にＫｓまたはＫｓ＿ＮＡＦを使用して）セッション鍵は、後にセッションの暗号化または暗号化解除に端末によって使用するために、ＵＩＣＣから端末に転送され、セキュアにされないチャネル上で実行される。その結果、盗聴する能力のある者は、セッション鍵を傍受し、端末とネットワークとの間で交換されるメッセージを暗号化し、または暗号化解除することができる。この場合に、ＮＡＦ鍵センターがローカル鍵（Ｋｓ＿ｌｏｃａｌ）を導出し、その後、移送する（ＮＡＦ鍵センターから）ために端末とＮＡＦ鍵センターとの間でＨＴＴＰＳトンネルを確立するのに必要な、加入者証明書確立などの後続手順の多くが、漏洩の危険がある。ローカル鍵自体がＨＴＴＰＳトンネルを介して移送されるので、セッション鍵の漏洩は、ローカル鍵の漏洩につながる。その後、ローカル鍵がリセットまたは電話ブートの後に消えずに残り、ＵＩＣＣと端末との間の情報の暗号化された転送に使用される場合に、その時に、すべてのそのような通信が、危険にさらされている。
【００３２】
（ローカル鍵確立における問題）
ＴＳ ３３．１１０−７２０に見られるＫｓ＿ｌｏｃａｌを確立する手順は、次の問題を有する。
１）複数のＯＴＡ接続に起因する非効率性 − 端末は、Ｋｓ鍵を確立するためにワイヤレスＧＢＡ＿Ｕ処理を完了しなければならない。それ自体はＵＩＣＣとＨＳＳとの間で共有される加入者秘密（Ｋ）に基づくＫｓから導出されるＫｓ＿ｌｏｃａｌを確立しようとして、ＴＳ ３３．１１０は、ＵＩＣＣと端末との間のＫｓ＿ｌｏｃａｌが、もう一度、そのチャネルに使用されるアプリケーションを指定する各ＮＡＦについて、ワイヤレスプロトコルに従うための鍵確立手順を提案する。この規格は、それぞれが異なるＮＡＦに固有の複数の異なるローカル鍵をこの形で生成することを可能にするので、複数のそのような鍵を確立したい場合には、多数のＯＴＡ手順を完了しなければならない。
２）情報プライバシの問題 − ＮＡＦ＿ＩＤ、ｔｅｒｍｉｎａｌ ＩＤ、Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ、ＲＡＮＤｘ、およびＣｏｕｎｔｅｒ Ｌｉｍｉｔ値などの多数のパラメーターの値が、ＵＩＣＣと端末との間でオープンチャネルを介して転送される。これらのパラメーターの一部は、露出された場合に、プライバシの危険を提示する可能性がある。
３）ＮＡＦ鍵センターと端末との間のＨＴＴＰＳトンネルにおいて − ３ＧＰＰ ＴＳ ３３．１１０ Ｖ７．２．０（図５のステップＳ４およびＳ５を参照されたい）において、このトンネルは、証明書ベースの相互認証を使用して作成され、ＮＡＦ鍵センターから端末へのＫｓ＿ｌｏｃａｌおよび鍵材料の転送に使用されると想定される。加入者証明書を、端末またはＵＩＣＣで動作するアプリケーションのいずれかに発行することができる。加入者証明書を確立するために必要な秘密鍵および公開鍵は、ＵＩＣＣの内部または端末上のいずれかに存在することができる。多くのこれらの場合において、秘密鍵もしくは公開鍵、加入者証明書、またはＫｓ＿ｅｘｔ＿ＮＡＦ鍵などの機密情報を、ＵＩＣＣと端末との間のセキュアにされないチャネルを介して転送する必要に起因するセキュリティ脆弱性がある。いくつかのシナリオおよびこれらのシナリオに関連する脆弱性を、下に示す。
【００３３】
図７〜図９に、加入者証明書確立処理の３つの異なるシナリオを示す。
【００３４】
図７に示されたシナリオＡ１において、秘密／公開鍵対が、端末にある。ＵＩＣＣは、ＨＴＴＰセッションを介するＰＫＩ（＝ＮＡＦ）を用いる加入者証明書確立の責任を負う。ＧＢＡ／ＧＢＡ＿Ｕ手順が既に行われたと仮定すると、Ｋｓ＿ＮＡＦ／Ｋｓ＿ｅｘｔ＿ＮＡＦ鍵は、ＵＩＣＣ上に存在する。シナリオＡ１の現在の解決策には、弱点がある。最も著しくは、ステップＳ５において、端末が、証明のための公開鍵をオープンチャネル上でＵＩＣＣに送信しなければならない。さらに、ＵＩＣＣは、ステップＳ１１において、オープンチャネルを通じて加入者証明書（ＨＴＴＰＳセッションに使用される）を端末へ送信する。
【００３５】
図８に示されたシナリオＡ２において、秘密／公開鍵対が、端末にある。端末は、ＨＴＴＰセッションを介するＰＫＩ（＝ＮＡＦ）を用いる加入者証明書確立の責任を負う。ＧＢＡ／ＧＢＡ＿Ｕ手順が既に行われたと仮定すると、Ｋｓ＿ＮＡＦ／Ｋｓ＿ｅｘｔ＿ＮＡＦ鍵は、ステップＳ１に示されているように、ＵＩＣＣ上に存在する。シナリオＡ２の＿現在の解決策に関連する弱点がある。最も著しくは、ＵＩＣＣが、ステップＳ１において、オープンチャネルを通じてＫｓ＿ｅｘｔ＿ＮＡＦ（端末は加入者証明書セッション中にＨＴＴＰダイジェストを妥当性検査するためにこれを必要とする）を端末に送信する。
【００３６】
図９に示されたシナリオＡ３において、秘密／公開鍵対が、端末にある。端末は、ＨＴＴＰセッションを介し、ステップＳ１からステップＳ１１を介するＰＫＩ（＝ＮＡＦ）を用いる加入者証明書確立の責任を負う。ＧＢＡ／ＧＢＡ＿Ｕ手順が既に行われたと仮定すると、Ｋｓ＿ＮＡＦ／Ｋｓ＿ｅｘｔ＿ＮＡＦ鍵は、ＵＩＣＣ上に存在する。端末は、ステップＳ１において、ＰＫＩ（＝ＮＡＦ）を用いてセッション鍵ＫｓｓによってセキュアにされたセキュアＯＴＡチャネルを介してＫｓ＿ｅｘｔ＿ＮＡＦを受信する。これが、Ｋｓ＿ｅｘｔ＿ＮＡＦがＰＫＩ（ＮＡＦ）から端末に送信される場合に、規格の変更を仮定することを補足する。しかし、シナリオＡ３の現在の解決策に関連する弱点がある。現在、すべてのセッション鍵は、端末によって使用され、その結果、Ｋｓは、Ｓ０に示されているように、現在の電話のアーキテクチャの下において、オープンチャネルを介してＵＩＣＣによって端末に送信されなければならない。これは、盗聴者が、セッション鍵を傍受し、任意のメッセージ（加入者証明書処理メッセージを含む）を暗号化解除できることを意味する。この弱点（セッション鍵のあらわな転送）は、第１のＡＫＡ処理にすら影響する可能性がある一般的な問題である。ローカル鍵確立処理の２つの異なるシナリオを、図１０〜図１１に示す。
【００３７】
図１０に示されたシナリオＢ１において、秘密／公開鍵対が、端末にある。端末は、ステップＳ４において、処理Ａ（ＴＳ ３３．１１０）で確立された加入者証明書を使用するＨＴＴＰＳトンネル確立の責任を負う。シナリオＢ１の現在の解決策の弱点がある。最も著しくは、端末は、ステップＳ１０において、オープンチャネルを通じて証明書の公開鍵をＵＩＣＣに送信する。さらに、ＵＩＣＣは、ステップＳ１２において、オープンチャネルを介して加入者証明書（ＨＴＴＰＳセッションに使用される）を端末に送信する。
【００３８】
図１１に示されたシナリオＢ２において、秘密／公開鍵対が、ＵＩＣＣにある。端末は、ステップＳ５に示されているように、処理Ａ（３３．１１０）で確立された加入者証明書を使用するＨＴＴＰＳトンネル確立の責任を負う。しかし、シナリオＢ１の現在の解決策に関連する弱点がある。最も著しくは、ＵＩＣＣと端末との間にセキュアチャネルがない。さらに、攻撃者は、加入者証明書および秘密鍵を傍受することができ（秘密鍵を、ステップＳ４に示されているように、ＵＩＣＣによってオープンチャネルを介して端末に送信しなければならないので）、これは、ＨＴＴＰＳトンネルを危険にさらす。加えて、ステップＳ１３を参照すると、Ｋｓ＿ｌｏｃａｌが攻撃者に暴露される。
【発明の概要】
【００３９】
３Ｇ ＵＭＴＳ携帯電話システムは、３Ｇモバイル端末とＵＭＴＳワイヤレスネットワーク（またはＵＴＲＡＮ）との間の通信経路をセキュアにするさまざまなセキュリティ手段の基礎またはルートとしてＵＳＩＭ（ＵＭＴＳ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）アプリケーションを提供するＵＭＴＳ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ（ＵＩＣＣ）と呼ばれるセキュアにされたスマートカードに依存する。
【００４０】
ＵＩＣＣは、端末（ＭＥ）およびＢＳＦ（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ）と情報を交換し、ここで、それ自体はＮＡＦ固有鍵（Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦ）の複数のインスタンス化によって導出される、アプリケーションおよびＮＡＦ（ｎｅｔｗｏｒｋ ａｐｐｌｉｃａｔｉｏｎ ｆｕｎｃｔｉｏｎ）に固有の複数のローカル鍵（Ｋｓ＿ｌｏｃａｌ）が、ＵＩＣＣと端末（ＭＥ）との間のローカルチャネルを暗号化するのに使用される鍵を導出するのに使用され、ＮＡＦのそれぞれの鍵を導出するための複数のワイヤレス（ＯＴＡ）手順が除去される。本明細書で提案される方法は、「バルク」手順でローカル鍵導出および複数のＮＡＦとのセキュリティアソシエーションを可能にし、過度なＯＴＡ接続の必要を軽減する。
【００４１】
本明細書において提案されるもう１つの概念が、内部鍵センター（Ｉｎｔｅｒｎａｌ Ｋｅｙ Ｃｅｎｔｅｒ、ＩＫＣ）の使用である。ＩＫＣは、仮の鍵材料ならびに最終的なＫｓ＿ｌｏｃａｌを導出する機能に限れば、外部ＮＡＦの機能の一部に似た機能を有する、ＷＴＲＵ（ワイヤレス送受信器ユニット）内の信頼されるエンティティである。
【００４２】
複数の実施形態オプションが、ＩＫＣについて提案される。一実施形態において、ＩＫＣが信頼され、ＮＡＦ鍵センター機能の「複製」が可能であるという意味で端末として働くと同時に、Ｋｓ＿ｌｏｃａｌの生成に必要な機能（ＯＴＡ通信機能など）およびデータを提供する。もう１つの実施形態において、ＩＫＣは、ＭＥ内の信頼されるエンティティとして働くが、端末とは別々であり、ＮＡＦ鍵センターの代理として作動することができる。
【００４３】
一緒にＩＫＣの保全性および使用をセキュアにし、ＩＫＣがＮＡＦなどの外部ネットワークエンティティの代理または置換としてセキュアに働くことを可能にする、信頼されるコンピューティングに基づく方法も提案される。
【００４４】
本発明のより詳細な理解は、例として与えられ、添付図面に関連して理解されるべき、実施形態の次の説明から得ることができる。
【図面の簡単な説明】
【００４５】
【図１】ＢＳＳを用いるブートストラップの参照モデルを示す図である。
【図２】ＵＩＣＣベースの強化を使用するＧＢＡ＿Ｕブートストラップ手順を示すフローチャートである。
【図３】ＧＢＡ＿Ｕの実施の後のセキュリティアソシエーションの処理を示す図である。
【図４】端末がＵＩＣＣ保持デバイスの一部である参照モデルを示す図である。
【図５】ＵＩＣＣと端末との間での鍵の確立を示す図である。
【図６】ＨＴＴＰダイジェスト認証と共にＰＫＣＳ＃１０を使用する証明書要求を示す図である。
【図７】シナリオＡ１の加入者証明書処理を示す図である。
【図８】シナリオＡ２の加入者証明書処理を示す図である。
【図９】シナリオＡ３の加入者証明書処理を示す図である。
【図１０】シナリオＢ１のローカル鍵確立処理を示す図である。
【図１１】シナリオＢ２のローカル鍵確立処理を示す図である。
【図１２ａ】セキュアワイヤレス通信システムを示す例のブロック図である。
【図１２ｂ】ＵＩＣＣおよびＨＬＲ／ＨＳＳがＫUHを共有する場合を示す図である。
【図１３】ＵＩＣＣおよびＩＫＣが対称秘密鍵Ｋsym_UIを共有する時の実施形態を示す図である。
【図１４】ＩＫＣによって実行される正しいＫIHの識別および後続のＴＬＳ−ＰＳＫトンネル確立の処理を示す図である。
【図１５】ＢＳＦによって実行される正しいＫIHの識別および後続のＴＬＳ−ＰＳＫトンネル確立の処理を示す図である。
【図１６】本開示で説明されるＮＡＦとＷＴＲＵとの間のセキュリティアソシエーションを示す図である。
【図１７】ＵＩＣＣと端末との間のＫｓ＿ｌｏｃａｌ確立の処理を示す図である）。
【図１８】ＩＫＣならびにＩＫＣが処理する鍵およびデータの保全性をセキュアにするＭＴＭの方法を示す図である。
【図１９】ＭＴＭが端末とＩＫＣとの間に結合されるシステムを示す図である。
【発明を実施するための形態】
【００４６】
（本明細書で使用される頭字語）
３ＧＰＰ ３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ
ＡＫ 匿名鍵（Ａｎｏｎｙｍｉｔｙ Ｋｅｙ）、ＡＫ＝ｆ５K（ＲＡＮＤ）として計算される
ＡＫＡ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ａｇｒｅｅｍｅｎｔ
ＡＵＴＮ 認証トークン（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｔｏｋｅｎ）
ＡＶ 認証ベクトル（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｖｅｃｔｏｒ）
Ｂ−ＴＩＤ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ｔｒａｎｓａｃｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ
ＢＳＦ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ
ＣＡ 認証局（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ）
ＣＫ 暗号鍵（Ｃｉｐｈｅｒ Ｋｅｙ）
ＦＱＤＮ 完全修飾ドメイン名（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）
ＧＡＡ Ｇｅｎｅｒｉｃ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ
ＧＢＡ Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ
ＧＢＡ＿ＭＥ ＭＥベースのＧＢＡ
ＧＢＡ＿Ｕ ＵＩＣＣベースの強化を伴うＧＢＡ
ＧＵＳＳ ＧＢＡ Ｕｓｅｒ Ｓｅｃｕｒｉｔｙ Ｓｅｔｔｉｎｇｓ
ＨＬＲ Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ
ＨＳＳ Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｙｓｔｅｍ
ＨＴＴＰ ハイパーテキスト転送プロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）
ＩＣＣＩＤ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ
ＩＫ Ｉｎｔｅｇｒｉｔｙ Ｋｅｙ
ＩＫＣ 内部鍵センター（Ｉｎｔｅｒｎａｌ Ｋｅｙ Ｃｅｎｔｅｒ）
ＩＭＰＩ ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｐｒｉｖａｔｅ Ｉｄｅｎｔｉｔｙ
ＫＤＦ 鍵導出関数（Ｋｅｙ Ｄｅｒｉｖａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）
Ｋ 加入者認証鍵（Ｓｕｂｓｃｒｉｂｅｒ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｋｅｙ）（ＴＳ３３．１０５ ｓｅｃ ５．１．７．１）
Ｋｓ＿ＩＫＣ＿ＮＡＦ ＩＫＣと端末との間のセキュアローカルチャネルのためにＵＩＣＣとＩＫＣとの両方でローカル鍵を導出するための鍵材料として使用される、ＢＳＦで計算される提案される鍵
Ｋｓ＿ｅｘｔ＿ＮＡＦ ＧＢＡ＿Ｕで導出される鍵
ＫIH 本発明でのＩＫＣとＨＬＲ／ＨＳＳとの間の事前共有鍵
Ｋsym_UI ＵＩＣＣとＩＫＣとの間の事前共有対称鍵
ＫUH 本発明でのＵＩＣＣとＨＬＲ／ＨＳＳとの間の事前共有鍵
Ｋｓ＿ＩＫＣ＿ＮＡＦ ＮＡＦ固有Ｋｓ＿ｌｏｃａｌの導出に使用するためにＵＩＣＣおよびＢＳＦで導出される
Ｋｓ＿ｉｎｔ＿ＮＡＦ ＵＩＣＣに残る、ＧＢＡ＿Ｕで導出される鍵
Ｋｓ＿ｌｏｃａｌ 端末とＵＩＣＣとの間で共有される、導出される鍵
ＭＡＣ メッセージ認証コード（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）
ＭＡＣNAF 本新発明でＮＡＦによって生成される（パート２中に）ＭＡＣ
ＭＡＣIKC 本新発明でＩＫＣによって生成される（パート３中に）ＭＡＣ
ＭＡＣUICC 本新発明でＵＩＣＣによって生成される（パート３中にＭＡＣ
ＭＡＣUICC_SA 本新発明でＵＩＣＣによって生成される（パート２中に）ＭＡＣ
ＭＮＯ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｏｒ
ＭＴＭ Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ
ＮＡＦ Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ
ＮＡＩ Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｆｉｅｒ
ＯＴＡ ワイヤレス（Ｏｖｅｒ ｔｈｅ Ａｉｒ）
ＰＫＩ 公開鍵基盤（Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）
ＲＡＮＤ ランダムチャレンジ（Ｒａｎｄｏｍ ｃｈａｌｌｅｎｇｅ）
ＲＡＮＤｘ Ｋｓ＿ｌｏｃａｌ導出のためにＩＫＣによって生成されるランダムチャレンジ
ＲＡＮＤｙ Ｋｓ＿ＩＫＣ＿ＮＡＦ導出のためにＩＫＣによって生成されるランダムチャレンジ
ＲＥＳ ユーザー応答
ＳＬＦ Ｓｕｂｓｃｒｉｂｅｒ Ｌｏｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ
ＳＱＮ シーケンス番号（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）
ＴIB ＩＫＣとＢＳＦとの間のＴＬＳタイプトンネル
ＴUI ＵＩＣＣとＩＫＣとの間のＴＬＳタイプトンネル
ＴＣＧ Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ
ＴＬＳ トランスポート層セキュリティ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）
ＴＭＰＩ Ｔｅｍｐｏｒａｒｙ ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｐｒｉｖａｔｅ Ｉｄｅｎｔｉｔｙ
ＵＳＳ Ｕｓｅｒ Ｓｅｃｕｒｉｔｙ Ｓｅｔｔｉｎｇ
ＵＥ ユーザー機器（Ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）
ＵＳＩＭ Ｕｓｅｒ Ｓｅｒｖｉｃｅｓ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ
ＸＭＡＣ 認証および鍵一致に使用されるＥｘｐｅｃｔｅｄ（期待される）ＭＡＣ
ＸＲＥＳ Ｅｘｐｅｃｔｅｄ（期待される）ユーザー応答
【００４７】
本明細書において以下に引用する場合、用語の「ＷＴＲＵ（ワイヤレス送受信ユニット）」は、ユーザー機器（ＵＥ）、移動局、固定のまたは移動の加入者ユニット、ポケットベル、携帯電話機、携帯情報端末（ＰＤＡ）、コンピューター、またはワイヤレス環境で動作できるあらゆる他のタイプのユーザーデバイスを含むが、これらに限定はされない。本明細書において以下に引用する場合、用語の「基地局」は、Ｎｏｄｅ−Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、またはワイヤレス環境で動作できる任意の他のタイプのインターフェースするデバイスを含むが、これらに限定はされない。下で示す詳細な説明において、用語ＭＥは、端末と同義であり、これらの用語は、交換可能である。ＵＥは、ＵＩＣＣおよび端末（またはＭＥ）を集合的に組み込む識別するのに使用される。信頼される携帯電話機（Ｔｒｕｓｔｅｄ Ｍｏｂｉｌｅ Ｐｈｏｎｅ）は、端末と同義であるが、ＴＧＣの意味で信頼される。電話機は、端末と同義である。リモートデバイスは、ＵＥを識別し、ここで、そのＵＩＣＣおよびＵＩＣＣのリーダーは、ＵＥを含む同一の物理パッケージングに存在するのではなく、たとえばＵＳＢケーブル、ワイヤレス接続性、および類似物などのリモート接続を介してＵＥに接続される。
【００４８】
前の問題を解決し、ＧＢＡ＿Ｕ、セキュリティアソシエーション、およびＮＡＦの固有のローカル鍵Ｋｓ＿ｌｏｃａｌの確立などの既存処理のセキュリティと効率との両方を強化する、新しい方法を説明する。この方法は、仮定または要件の次のセットに基づく。
【００４９】
仮定は、次のとおりである。
１．ＷＴＲＵの内部のエンティティとして提供される内部鍵センター（ＩＫＣ）は、外部ＮＡＦ鍵センターの機能性に類似する機能性を有する。
ａ．後で検討される一実施形態において、ＩＫＣは、ＭＥの通信機能（ネットワークおよびＵＩＣＣへの）の責任をも負う。これに関して、ＩＫＣを、外部ＮＡＦ鍵センターの追加機能性を有する端末と考えることができる。
ｂ．ＩＫＣの仮定される機能性の詳細は、下で説明する。
２．ＩＫＣおよびＨＬＲ／ＨＳＳは、おそらくはその製造または販売の時に事前にプロビジョニングされる、事前共有秘密ＫIHを有する。
ａ．ＢＳＦ（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ）は、ＨＬＲ／ＨＳＳからＫIHをセキュアに取り出すことができると仮定される。
ｂ．ＫIHは、以下においてトンネルＴIBと称する、ＩＫＣとＢＳＦとの間のＴｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ−Ｐｒｅ−Ｓｈａｒｅｄ Ｋｅｙ（ＴＬＳ−ＰＳＫ）トンネルを確立するのに使用される。
３−Ａ．ＵＩＣＣおよびＨＬＲ／ＨＳＳは、ＵＩＣＣおよびＨＬＲ／ＨＳＳが既存ＧＢＡ＿Ｕ処理のためにそれらの間で既に共有する加入者秘密Ｋとは異なる秘密ＫUHを共有する。
ａ．ＢＳＦは、ＨＬＲ／ＨＳＳからＫUHをセキュアに取り出すことができると仮定される。
ｂ．ＢＳＦは、ＴＬＳ−ＰＳＫトンネルＴIBを使用して、この鍵ＫUHをＩＫＣにセキュアに暗号化して転送することができるとも仮定される。
ｃ．ＫUHは、ＢＳＦからＩＫＣに送付された後に、以下においてトンネルＴUIと称する、ＵＩＣＣとＩＫＣとの間のＴＬＳ−ＰＳＫトンネルを確立するのに使用され得る。トンネルＴUIは、短いセキュリティ有効期間を有する場合があり、その結果、これを限られた時間の間に限って使用できるようになる。
３−Ｂ．ＵＩＣＣおよびＨＬＲ／ＨＳＳが秘密鍵ＫUHを共有する仮定３Ａの代替として、ＵＩＣＣおよびＩＫＣが、事前共有対称鍵Ｋsym_UIを事前にプロビジョニングされると仮定することができ、そのようなプロビジョニングは、製造または販売の時に提供される。
４−Ａ．ＵＩＣＣは、共有秘密鍵ＫUHを使用してメッセージを暗号化し、暗号化解除することができる。
４−Ｂ．３−Ｂ仮定を使用して、ＵＩＣＣは、事前共有対称鍵Ｋsym_UIを使用してメッセージを暗号化し、暗号化解除することができる。
５−Ａ．ＩＫＣは、共有秘密鍵ＫUHを使用してメッセージを暗号化し、暗号化解除することができる。
５−Ｂ．３−Ｂ仮定を使用して、ＩＫＣは、事前共有対称鍵Ｋsym_UIを使用してメッセージを暗号化し、暗号化解除することができる。
６．ＵＩＣＣおよびＢＳＦは、両方とも、１つまたは複数の鍵Ｋｓ＿ＩＫＣ＿ＮＡＦを導出することができ、この鍵は、それぞれがＮＡＦのそれぞれに固有であり、ＮＡＦ固有Ｋｓ＿ｌｏｃａｌの生成で使用される。
７．ＩＫＣおよびＢＳＦは、１つのＯＴＡアプリケーション応答交換で複数のＮＡＦの鍵材料を交換することができる。
８．ＢＳＦは、ＩＫＣの識別情報（以下においてＩＫＣ＿ＩＤ）の受信時に、以前に認証されたかこれから認証されると期待されるのいずれかであるＵＩＣＣ＿ＩＤを識別し、これらのおそらくは複数のＵＩＣＣ＿ＩＤを使用して、これらの認証されたまたは認証されると期待されるＵＩＣＣ＿ＩＤに対応するおそらくは複数の正しい鍵｛ＫUH｝を識別することができる。ＢＳＦは、集合｛ＫUH}の鍵のうちの１つ、複数、またはすべてを、並列にまたは順番にのいずれかでＩＫＣに送信し、ＩＫＣが、これらの鍵のうちのどれをホスティングされるＵＩＣＣと共に使用すべきかをホスティングされるＵＩＣＣと共にテストすることを可能にすることもできる。
９．ＴＣＧのＭｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｍｏｄｕｌｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ ｖ１．０の仕様を満足するＭＴＭ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅ）およびそれに関連するソフトウェアスタックは、ＷＴＲＵ内に存在し、ＵＥは、ＴＣＧのＴｒｕｓｔｅｄ Ｍｏｂｉｌｅ Ｐｈｏｎｅ Ｒｅｆｅｒｅｎｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ ｓｐｅｃｉｆｉｃａｔｉｏｎの仕様を満足する信頼される携帯電話機である。ＭＴＭは、ＩＫＣおよびＵＩＣＣの状態の作成、検査、および検証の責任を負い、ＧＢＡ＿Ｕ手順、セキュリティアソシエーション手順、およびセキュアローカル鍵確立手順のためにＩＫＣが処理する鍵およびデータのセキュアストレージの責任をも負う。
【００５０】
（内部鍵センター（ＩＫＣ））
一実施例において、ＩＫＣは、端末の一部であり、３Ｇエアインターフェースを使用してワイヤレスで通信でき、最終的にＢＳＦと通信することができる。代替の実施例において、ＩＫＣを、端末とは完全に別々とすることができる。ＩＫＣは、信頼されるコンポーネントであり、その保全性および信頼性は、ＷＴＲＵ内のＭＴＭによって検証可能である。ＭＴＭは、一実施例で、端末（またはＷＴＲＵ）の一部である。端末（またはＷＴＲＵ）の一部としてＭＴＭとＩＫＣとの両方を有する実施例において、ワイヤレス接続性を、有線接続性によって置換することができる。ＩＫＣは、それ自体とＵＩＣＣとの間でならびにＢＳＦと共にＴＬＳタイプのトンネルを確立するために暗号機能を有する。これらのトンネルは、ＧＢＡ＿Ｕ手順およびセキュリティアソシエーションで、およびＵＩＣＣと端末との間のセキュアチャネルの確立中にも、交換される情報の保全性および機密性をセキュアにするのに使用される。ＩＫＣは、ＢＳＦと共にＴＬＳ−ＰＳＫトンネルを確立することができる。ＢＳＦは、ＩＫＣと共にそのようなトンネルをサポートすることができると仮定される。本明細書で提案されるバージョンのパート１およびパート２のフェーズ中に、ＩＫＣは、従来技術のＧＢＡ＿Ｕ手順およびセキュリティアソシエーション手順の実行のために端末に要求される機能、ならびに一方はＩＫＣとＵＩＣＣとの間、他方はＩＫＣとＢＳＦとの間の２つのＴＬＳトンネルの作成および使用に必要な機能を実行する。本技法のパート３中に、ＩＫＣは、外部ＮＡＦ鍵センターによって実行される機能に類似する機能を実行する。この機能は、１）ｃｏｕｎｔｅｒ ｌｉｍｉｔの生成、２）それぞれがＮＡＦに固有であり、ＮＡＦ固有Ｋｓ＿ｌｏｃａｌを導出するのに使用される、乱数ＲＡＮＤｘ（１つまたは複数）およびＲＡＮＤｙ（１つまたは複数）の１つまたは複数の対の生成、３）ＫＤＦを使用するＫｓ＿ｌｏｃａｌの導出、ならびに４）ＩＫＣが端末とは完全に別々である場合の、端末へのＫｓ＿ｌｏｃａｌの転送を含む。
【００５１】
図１２ａに、上で述べた仮定に従って構成されたセキュアワイヤレス通信システムの例のブロック図を示す。このワイヤレス通信システムは、ＷＴＲＵ １２００を含む。ＷＴＲＵ １２００は、端末１２１０、モデム１２２０、およびラジオ（ＲＦ）ユニット１２３０を含む。端末１２１０は、ＭＴＭ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅ）１２４０および内部鍵センター（ＩＫＣ）１２５０を含む。ＩＫＣユニット１２５０は、外部ＵＩＣＣ １２６０と通信するように構成される。ＲＦユニット１２３０は、エアインターフェース１２７５を介してｂｏｏｔｓｔｒａｐ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ（ＢＳＦ）１２７０と通信するように構成される。ＢＳＦ １２７０は、ＨＬＲ／ＨＳＳ １２８０と通信し、オプションで、他のＮＡＦ（ｎｅｔｗｏｒｋ ａｐｐｌｉｃａｔｉｏｎ ｆｕｎｃｔｉｏｎ）（図示せず）と通信する。
【００５２】
ＩＫＣ手順を使用する改善された鍵導出およびセキュリティアソシエーション（ＳＡ）は、下で示すように、３つの部分に分割される。
【００５３】
この手順の第１部分（パート１）は、図１２に示された第１実施形態による改善されたＧＢＡ＿Ｕ処理を使用する。従来の方法を超える１つの改善は、この処理が、今や、ＷＴＲＵ １２００内の新たに提案されるエンティティ、ＩＫＣ １２５０の制御の下で２つのＴＬＳタイプチャネルを介して実行されることである。図１２を参照すると、ステップＳ１において、ＩＫＣ １２５０は、ＩＫＣ １２５０とＢＳＦ １２７０との間のＴＬＳ−ＰＳＫトンネルの確立の要求を送信する。この要求メッセージは、ペイロードとしてＩＫＣ １２５０＿ＩＤを含む。次に、ＢＳＦ １２７０は、ステップＳ２において、ＨＳＳ／ＨＬＲから事前共有鍵（ＫIHおよびＫUH）を取り出す。ＫIHは、ＩＫＣ １２５０とＢＳＦ １２７０との間でＴＬＳ−ＰＳＫトンネルを確立するのに使用され、ＫUHは、ＵＩＣＣ １２６０とＩＫＣ １２５０との間でトンネルを確立するのに使用される。ＩＫＣ １２５０とＢＳＦ １２７０との間のＴＬＳ−ＰＳＫトンネル（ＴIB）は、ステップＳ３において確立され、ここで、相互認証に基づく事前共有秘密（ＫIH）が使用される。ＢＳＦ １２７０は、ステップＳ４において、トンネルＴIBを介してＫUHをＩＫＣ １２５０に送信する。ＵＩＣＣ １２６０およびＩＫＣ １２５０は、ステップＳ５において、相互認証に基づく事前共有秘密（ＫUH）を使用して、ＴＬＳ−ＰＳＫトンネル（ＴUI）を確立する。ＧＢＡ＿Ｕが行われ、これは、ＵＩＣＣ １２６０とＢＳＦ １２７０との両方でのＫｓの確立につながる。最後に、ＧＢＡ＿Ｕ手順の終りに、Ｋｓ＝ＣＫ‖ＩＫが、ＢＳＦ １２７０（ステップＳ７ａを参照されたい）およびＵＩＣＣ １２６０（ステップＳ７ｂを参照されたい）で確立される。ＮＡＦ＿ＩＤも、ＵＩＣＣ １２６０で、ＮＡＦ＿Ｉｄ＝ＮＡＦのＦＱＤＮ‖Ｕａセキュリティプロトコル識別子として構成される。この手順において、ＵＩＣＣ １２６０は、秘密鍵ＫUHをＨＬＲ／ＨＳＳ １２８０と共有すると仮定される。
【００５４】
代替として、図１３に、ＵＩＣＣ １２６０が事前にプロビジョニングされる対称秘密鍵Ｋsym_UIをＩＫＣ １２５０と直接に共有する（ステップＳ４を参照されたい）、変更されたＢＧＡ＿Ｕのステップを示す。図１２と異なるステップだけを、これから説明する。ステップＳ２において、共有鍵ＫIHだけが、ＢＳＦ １２７０に供給される。図１３のステップＳ４において、Ｋsym_UIを使用してＴＬＳ−ＰＳＫトンネルを確立する。図１３のステップＳ５は、図１２のステップＳ６と同一である。図１３のステップＳ６ａおよびＳ６ｂは、図１２のステップＳ７ａおよびステップＳ７ｂと同一である。図１３の代替手順は、ＵＩＣＣ １２６０およびＩＫＣ １２５０が事前にプロビジョニングされる秘密鍵Ｋsym_UIを直接共有するという要件が、特定のＵＩＣＣ １２６０と特定のＩＫＣ １２５０との間に強い「バインディング」を不必要に作成する場合があり、上で説明した異なるタイプのデバイスでホスティングされるためのＵＩＣＣ １２６０のポータビリティが、実施または管理がよりむずかしくなる可能性があるという点で、欠点を有する。
【００５５】
図１２に示された手順において、ＢＳＦ １２７０は、必要な場合に、所与のＩＫＣ １２５０に関連付けられているまたは関連付けられると期待されるのいずれかとしてＨＬＲ／ＨＳＳ １２８０が知識を有することのできるＵＩＣＣ １２６０に対応する複数の鍵｛ＫUH｝を収集するように構成される。ＢＳＦ １２７０は、これらの複数の鍵を送信することができ、その後、ＩＫＣ １２５０は、正しい鍵ＫUHが識別されるまで、ＵＩＣＣ １２６０と共にチャレンジレスポンスタイプの鍵検証手順を実行することができる。この手順の実施形態を、図１４に示す。図１３と異なるステップだけが説明され、ステップＳ２において、両方ＫIH複数鍵｛ＫUH｝をＢＳＦ １２７０に供給する。ＩＫＣ １２５０は、ＵＩＣＣ １２６０にナンス‖ｈａｓｈ（
【００５６】
【数４】
【００５７】
）を要求し（ステップＳ５）、その後、これを受信する（ステップＳ６）。各ＫUHを計算して（ステップＳ７）、ＵＩＣＣ １２６０とのＴＬＳ−ＰＳＫトンネルＴUIを確立するための正しいＫUHを見つける。
【００５８】
図１４において説明した処理に対する代替として、我々は、ＩＫＣ １２５０がＢＳＦ １２７０から可能な鍵ＫUHのすべてを受信するの「ではない」鍵検証方法を提案する。ＩＫＣ １２５０は、ＵＩＣＣ １２６０から証拠鍵ＫUHを受信し（図１５、ステップＳ４およびＳ５を参照されたい）、これをＢＳＦ １２７０に渡し（ステップＳ６）、その後、ＢＳＦ １２７０は、図１５のステップＳ６に示された、鍵の可能な集合｛ＫUH｝から正しい鍵を識別する手順を実行する。正しいＫUHは、ＵＩＣＣ １２６０とのＴＬＳ−ＰＳＫトンネルの確立で使用するためにＩＫＣ １２５０に渡される（ステップＳ７）。この方法は、ＢＳＦ １２７０が、複数の候補鍵のＯＴＡ開示の危険を冒さないという点で、図１４に示された方法を超える利益を有する。
【００５９】
図１２ｂに示されたＴＬＳ−ＰＳＫトンネル確立手順において、ＩＫＣ １２５０からＢＳＦ １２７０へのＩＫＣ １２５０＿ＩＤの初期情報転送は、現在、物理層保護の上でのみ（すなわち、ＵＩＡセッション鍵およびＵＥＡセッション鍵によってセキュアにされて）実行される。前に説明したように、そのようなセッション鍵が盗聴に脆弱である場合には、ＩＫＣ １２５０−ＩＤも盗聴に脆弱になり、プライバシ開示をもたらす。
【００６０】
ＩＫＣ １２５０のアイデンティティをセキュアにするために、図１４においてオプションのステップを使用することができ、ここで、ＩＫＣ １２５０およびＢＳＦ １２７０は、ＩＫＣ １２５０＿ＩＤならびにＴＬＳ−ＰＳＫトンネル確立処理中に交換される他の情報の公開鍵ベースの暗号化および暗号化解除を使用する。面倒またはセキュリティリスクに脆弱である場合がある証明書ベースの手法の代わりに、ＩＫＣ １２５０およびＢＳＦ １２７０が、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ（ＤＨ）鍵交換手順を使用してそれぞれの公開鍵を確立することを提案する。実際に、ＩＫＣ １２５０は、ネットワークからブロードキャストされる、かなり多い個数ｎ個の異なる公開鍵を入手し、そこから１つを選択することができる。ＤＨ鍵交換プロトコルを、この目的に使用することができる。
【００６１】
伝達者は、このプロトコルを適用して、公開鍵集合への、ａなどの共通インデックスを計算する。これを達成するために、まず、ネットワークおよびＩＫＣ １２５０は、公知の２つの値すなわち、非常に大きい素数ｐおよび体Ｆpの乗法群Ｆ*pの生成元ｇについて一致する。次に、ネットワークは、乱数ＲＡＮＤiを選択し、
【００６２】
【数５】
【００６３】
を計算し、
【００６４】
【数６】
【００６５】
をＩＫＣ １２５０に送信する（１≦ＲＡＮＤi≦ｐ−２）。次に、ＩＫＣ １２５０は、乱数ＦＲＥＳＨを計算し、ｇFRESH≡ｇFRESH ｍｏｄ ｐを計算し、ｇFRESHをネットワークに送信する（１≦ＦＲＥＳＨ≦ｐ−２）。次に、ネットワークは、
【００６６】
【数７】
【００６７】
を計算する。最後に、ＩＫＣ １２５０は、
【００６８】
【数８】
【００６９】
を計算する。
【００７０】
ｋ≡ｋ’ ｍｏｄ ｐであることは、簡単に示される。ＩＫＣ １２５０およびネットワークは、両方ともｋ（０≦ｋ＜ｐ）を計算済みであるが、単純にｋ ｍｏｄｕｌｏ ｎを換算することによって、公開鍵の秘密インデックスａを計算することができる。すなわち、ａ≡ｋ ｍｏｄ ｎである。公開鍵ｋaすなわちインデックスａに対応する公開鍵を使用して、ＩＫＣ １２５０は、ＩＫＣ １２５０＿ＩＤを含むメッセージを暗号化し、ネットワークは、ｋaに対応する秘密鍵を使用して、そのメッセージを暗号化解除することができる。
【００７１】
ＩＫＣ １２５０＿ＩＤの機密性が達成されるのは、ネットワークがＲＡＮＤiの唯一のプロセッサであり、ＩＫＣ １２５０がＦＲＥＳＨの唯一のプロセッサであり、この２つの通信参加者だけがｋを計算できるからである。攻撃者は、離散対数問題の計算的実行不可能性によってセキュアにされる、これらの乱数値の両方を欠いている。
【００７２】
メッセージ機構が、公開鍵集合の散布に関して暗示される。これを、簡単にセルブロードキャストメッセージング構造の一部にすることができる。しかし、ネットワークからＩＫＣ １２５０への
【００７３】
【数９】
【００７４】
の送信およびＩＫＣ １２５０からネットワークへの値ｇFRESHの送信のために、追加のメッセージ機構が必要である。これらの機構は、好ましくは、上で定義した公開値ｐおよびｇに関するネットワーク／ＩＫＣ １２５０一致処理を含む。
【００７５】
ＫUHと表される複数の鍵をＩＫＣ １２５０に転送するネットワークに関して、成功のＫUHが達成されるまで、鍵ごとに１回の反復的な相互（チャレンジ−レスポンス）認証処理を使用することができる。ＵＩＣＣ １２６０は、この認証がすべての鍵について失敗する場合に拒否される。
【００７６】
上に説明した公開鍵のＤＨ交換を、ＴＬＳ−ＰＳＫトンネリング確立処理自体の一部として実行することもできる。この場合に、ＩＫＣ １２５０＿ＩＤは、ＴＬＳ−ＰＳＫハンドシェーク処理でのＩＫＣ １２５０からＢＳＦ １２７０への初期交換メッセージに含まれる。ＴＬＳ−ＰＳＫ拡張に関するＲＦＣ ４２７９が、ＤＨ対応ＴＬＳ−ＰＳＫ手順について、次の４つの異なる暗号スイート（ｃｉｐｈｅｒｓｕｉｔｅ）を許容することに留意されたい。
１．ＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿ＲＣ４＿１２８＿ＳＨＡ
２．ＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿３ＤＥＳ＿ＥＤＥ＿ＣＢＣ＿ＳＨＡ
３．ＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡ
４．ＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡ
ＲＣ４アルゴリズムの既知の暗号強度問題に起因して、それぞれ３ＤＥＳ、ＡＥＳ１２８、またはＡＥＳ２５６を用いる後の３つの暗号スイートだけを使用しなければならない。
【００７７】
（パート２：ＮＡＦとＵＥとの間のセキュリティアソシエーション）
パート２は、ＵＩＣＣ １２６０とＩＫＣ １２５０との間およびＩＫＣ １２５０とＢＳＦ １２７０との間の情報の交換をセキュアにするための２つのＴＬＳ−ＰＳＫトンネルの使用を介する従来技術の同一の名前の処理より優れたセキュリティアソシエーション処理である。追加の改善は、ＵＩＣＣ １２６０が、ＩＫＣ １２５０およびＢＳＦ １２７０の助けを得て、バルク鍵確立機構で複数のＮＡＦと共に鍵を確立できることである。
【００７８】
図１６を参照すると、パート２の詳細なステップが示されている。ＩＫＣ １２５０は、ステップＳ１において、ＵＩＣＣ １２６０に最新の有効なＫｓが存在するかどうかを検査し、そうである場合には、ＩＫＣ １２５０は、既に確立されたトンネル（ＴUI）を介してＵＩＣＣ １２６０からＢ−ＴＩＤおよびＮＡＦ＿ＩＤ（または、ＵＩＣＣ １２６０がそれとのセキュリティアソシエーションを確立することを望むＮＡＦのある他のアイデンティティ）を取り出す。ＵＩＣＣ １２６０は、ステップＳ１の間にＫｓ ｉｎｔ／ｅｘｔ＿ＮＡＦ鍵をも導出する。Ｋｓが最新でないか有効でない場合には、ＧＢＡ＿Ｕが、Ｋｓの確立のために開始される。ＩＫＣ １２５０は、ステップＳ２において、トンネルＴIBを介してＢＳＦ １２７０にＮＡＦ＿ＩＤおよびＢ−ＴＩＤを転送する。ＢＳＦ １２７０は、ステップＳ３において、所望のＮＡＦ（図を単純にするために図１６には１つのＮＡＦだけが示されている）に認証要求を送信する。ＢＳＦ １２７０は、ステップＳ４において、ＮＡＦから認証レスポンスを受信する。ＮＡＦが認証される場合には、ＢＳＦ １２７０は、ステップＳ５において、ＮＡＦ固有鍵（Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦ）を導出する。ＢＳＦ １２７０は、ステップＳ６において、ブートストラップ時刻および鍵の有効期間と一緒に、Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦをすべてのＮＡＦに転送する。ステップＳ７において、ＮＡＦのそれぞれは、Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦ、鍵の有効期間、およびブートストラップ時刻の受信を示す肯定応答メッセージをＢＳＦ １２７０に送信する。ＢＳＦ １２７０は、これらのメッセージを集約し、ステップＳ８において、ＴＬＳ−ＰＳＫトンネルＴIBを介してＩＫＣ １２５０にバルク・セキュリティ・アソシエーション・メッセージを送信し、このバルク・セキュリティ・アソシエーション・メッセージは、それに関してステップＳ５〜Ｓ７においてＫｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦが確立された特定のＮＡＦにそれぞれが対応する複数のＭＡＣNAFを含む。ＭＡＣNAFメッセージのそれぞれについて、ＭＡＣNAF＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｓ＿ｅｘｔ＿ＮＡＦ‖Ｋｓ＿ｉｎｔ＿ＮＡＦ‖ＮＡＦ＿ＩＤ‖ＧＵＳＳ）が、ＮＡＦごとに１６オクテットに切り詰められる。ＩＫＣ １２５０は、ステップＳ９において、ステップＳ８の間にＢＳＦ １２７０から受信したバルク・セキュリティ・アソシエーション・メッセージを、ＴＬＳ−ＰＳＫチャネルＴUIを介してＵＩＣＣ １２６０に転送する。ＵＩＣＣ １２６０は、ステップＳ１０において、ＮＡＦごとに、そのＮＡＦに固有のＭＡＣUICC_SAを、１６オクテットに切り詰められたＭＡＣUICC_SA＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｓ＿ｅｘｔ＿ＮＡＦ‖Ｋｓ＿ｉｎｔ＿ＮＡＦ‖ＮＡＦ＿ＩＤ‖ＧＵＳＳ）になるように計算する。ステップＳ１１において、バルク・セキュリティ・アソシエーション応答メッセージがＵＩＣＣ １２６０によって生成され、このメッセージは、ＵＩＣＣ １２６０とすべてのＮＡＦとの間のセキュリティアソシエーションのすべての成功および／または失敗を含む。失敗は、ＮＡＦのいずれかについて、ＭＡＣIKCがそれに対応するＭＡＣUICC_SAと一致しない時に検出される。この失敗は、たとえば、“ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ ｆａｉｌｕｒｅ”‖ＮＡＦ＿ＩＤなどのストリングによって示される。成功は、ＭＡＣIKCがそれに対応するＭＡＣUICC_SAと一致する時に検出される。成功応答は、Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦ鍵およびＭＡＣアルゴリズムＨＭＡＣ−ＳＨＡ−２５６を使用するＡＳＣＩＩ符号化されたストリング“ｓｅｃｕｒｉｔｙ ａｓｓｏｃｉａｔｉｏｎ Ｓｕｃｃｅｓｓｆｕｌ”のメッセージ認証コード（ＭＡＣ）を１６オクテットに切り詰めたものを含む。ステップＳ１１において、バルク・セキュリティ・アソシエーション応答メッセージが、ＩＫＣ １２５０を介し、ＴUIトンネルおよびＴIBトンネルを介してＢＳＦ １２７０まで送信される。ＢＳＦ １２７０は、ステップＳ１２において、ＮＡＦのそれぞれに、そのＮＡＦに固有のセキュリティアソシエーションの試みの失敗または成功の状況を送信する。成功の状況を受信したすべてのＮＡＦは、ステップＳ１３において、鍵（Ｋｓ＿ｉｎｔ／ｅｘｔ＿ＮＡＦ）、ブートストラップ時刻、および関連する鍵の有効期間を格納する。
【００７９】
（パート３：端末とＵＩＣＣ １２６０との間での鍵確立（Ｋｓ＿ｌｏｃａｌ））
パート３は、ＵＩＣＣ １２６０と端末との間のローカル鍵確立の処理である。従来技術と比較したこのパートの利益は、次のとおりである。ＵＩＣＣ １２６０とＩＫＣ １２５０との間およびＩＫＣ １２５０とＢＳＦ １２７０との間の情報の交換をセキュアにする２つのＴＬＳ−ＰＳＫトンネルの使用。第２に、ＵＩＣＣ １２６０および端末が、ＩＫＣ １２５０およびＢＳＦ １２７０の助けを得て、従来技術で要求されるように端末が異なる外部ＮＡＦ鍵センターとの複数のＯＴＡ接続を確立する必要なしに、それぞれが異なるＮＡＦに固有の複数のローカル鍵を確立する。
【００８０】
図１７に、パート３の詳細なステップを示す。ＩＫＣ １２５０は、ステップＳ１において、最新の有効なＫｓがＵＩＣＣ １２６０に存在するかどうかを検査する。そうである場合には、ＩＫＣ １２５０は、Ｂ−ＴＩＤおよび１つまたは複数のＮＡＦ＿ＩＤをＵＩＣＣ １２６０から取り出す。最新のＫｓまたは有効なＫｓがないときには、新しいＧＢＡ＿Ｕ処理を開始してＫｓを確立し、その後、Ｂ−ＴＩＤおよび１つまたは複数のＮＡＦ＿ＩＤが、ＩＫＣ １２５０によってＵＩＣＣ １２６０から取り出される。上の手順のために必要なＵＩＣＣ １２６０とＩＫＣ １２５０との間の情報交換のすべてが、ＴＬＳ−ＰＳＫトンネルＴUIを介してもたらされる。ＩＫＣ １２５０は、ステップＳ２において、それぞれが要求されるＮＡＦのＮＡＦ＿ＩＤに対応する１つまたは複数の鍵Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦのアプリケーション要求をＢＳＦ １２７０に送信する。ＩＫＣ １２５０は、Ｂ−ＴＩＤと、対応するＲＡＮＤｙナンスと一緒に１つまたは複数のＮＡＦ＿ＩＤとをも、ＴＬＳ−ＰＳＫトンネルＴIBを介して送信する。ＢＳＦ １２７０は、それぞれが要求されるＮＡＦのそれぞれに固有の１つまたは複数のＩＫＣ １２５０鍵Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦを計算し、ここで、Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦ＝ＫＤＦ（Ｋｓ＿ｉｎｔ＿ＮＡＦ，ＲＡＮＤｙ）である。その後、ＢＳＦ １２７０は、ステップＳ３において、Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦ鍵およびそのそれぞれの（ＮＡＦ固有）鍵の有効期間のすべてを含むアプリケーション応答をＩＫＣ １２５０に送信する。ＩＫＣ １２５０は、ステップＳ４において、ｃｏｕｎｔｅｒ ｌｉｍｉｔ値（それぞれが要求されるＮＡＦの関連する１つに固有）を生成し、１つまたは複数のローカル鍵Ｋｓ＿ｌｏｃａｌを導出し、ここで、Ｋｓ＿ｌｏｃａｌ＝ＫＤＦ（Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦ，Ｂ−ＴＩＤ，Ｔｅｒｍｉｎａｌ＿ＩＤ，ＩＣＣＩＤ，Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ，ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ，ＲＡＮＤｘ，ＣｏｕｎｔｅｒＬｉｍｉｔ）である。ローカル鍵がプラットフォーム固有鍵である場合に、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤオクテットストリングおよびＴｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤオクテットストリングが、静的なＡＳＣＩＩ符号化されたストリング“ｐｌａｔｆｏｒｍ”と等しくなるようにセットされることに留意されたい。ＩＫＣ１２５０は、ステップＳ５において、ＮＡＦ＿ＩＤに固有のＫｓ＿ｌｏｃａｌを作成するようにＵＩＣＣ １２６０に要求するアプリケーション要求メッセージを、トンネルＴUIを介してＵＩＣＣ １２６０に送信する。この要求のペイロードは、ＮＡＦ＿ＩＤ、Ｔｅｒｍｉｎａｌ＿ＩＤ、Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ、ＲＡＮＤｘ、ＲＡＮＤｙ、およびＣｏｕｎｔｅｒ Ｌｉｍｉｔ値を含む。端末は、ＭＡＣIKCをも含め、このＭＡＣIKCは、１６オクテットに切り詰められるＭＡＣIKC＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｓ＿ｌｏｃａｌ，ＮＡＦ＿ＩＤ‖Ｔｅｒｍｉｎａｌ＿ＩＤ‖ＩＣＣＩＤ‖Ｔｅｒｍ＿ａｐｐｌｉ＿ＩＤ‖ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ‖ＲＡＮＤｘ‖ＲＡＮＤｙ‖ＣｏｕｎｔｅｒＬｉｍｉｔ）として計算される。これがプラットフォーム固有鍵である場合に、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤオクテットストリングおよびＴｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤオクテットストリングが、静的なＡＳＣＩＩ符号化されたストリング“ｐｌａｔｆｏｒｍ”と等しくなるようにセットされることに留意されたい。ＵＩＣＣ １２６０は、受信されたＮＡＦ＿ＩＤに関連するＫｓ＿ｉｎｔ＿ＮＡＦおよびＢ−ＴＩＤを取り出し、当初に、Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦ＝ＫＤＦ（Ｋｓ＿ｉｎｔ＿ＮＡＦ，ＲＡＮＤｙ）に従ってＫｓ＿ＩＫＣ １２５０＿ＮＡＦを導出し、その後、Ｋｓ＿ｌｏｃａｌを導出し、ここで、Ｋｓ＿ｌｏｃａｌ＝ＫＤＦ（Ｋｓ＿ＩＫＣ １２５０＿ＮＡＦ，Ｂ−ＴＩＤ，Ｔｅｒｍｉｎａｌ＿ＩＤ，ＩＣＣＩＤ，Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ，ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ，ＲＡＮＤｘ，Ｃｏｕｎｔｅｒ Ｌｉｍｉｔ）である。ＵＩＣＣ １２６０は、ステップＳ６において、１６オクテットに切り詰められるＭＡＣUICC＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｓ＿ｌｏｃａｌ，ＮＡＦ＿ＩＤ‖Ｔｅｒｍｉｎａｌ＿ＩＤ‖ＩＣＣＩＤ‖Ｔｅｒｍ＿ａｐｐｌｉ＿ＩＤ‖ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ‖ＲＡＮＤｘ‖ＲＡＮＤｙ‖Ｃｏｕｎｔｅｒ Ｌｉｍｉｔ）を計算し、これをＭＡＣIKCと比較することによって、端末から受信したＭＡＣIKC 1250値を検証する。ＭＡＣUICCがＭＡＣIKCと等しくない場合には、ＵＩＣＣ １２６０は、鍵一致手順を終了し、Ｋｓ＿ｌｏｃａｌ導出要求に応答するＭＡＣ検証失敗メッセージを返す。ＭＡＣUICC＝ＭＡＣIKCの場合には、ＵＩＣＣ １２６０は、Ｋｓ＿ｌｏｃａｌおよび関連するパラメーター（Ｔｅｒｍｉｎａｌ＿ＩＤ、Ｔｅｒｍｉｎａｌ＿ａｐｐｌｉ＿ＩＤ、ＵＩＣＣ＿ａｐｐｌｉ＿ＩＤ、およびＫｓ＿ｌｏｃａｌ Ｃｏｕｎｔｅｒ Ｌｉｍｉｔ）を格納する。ステップＳ７において、ＵＩＣＣ １２６０は、鍵Ｋｓ＿ｌｏｃａｌおよびＭＡＣアルゴリズムＨＭＡＣ−ＳＨＡ−２５６を使用して、１６オクテットに切り詰められる、ＡＳＣＩＩ符号化されたストリング“ｖｅｒｉｆｉｃａｔｉｏｎ ｓｕｃｃｅｓｓｆｕｌ”のＭＡＣを含むＫｓ＿ｌｏｃａｌ導出応答を送信する。ＩＫＣ １２５０は、ステップＳ８において、Ｋｓ＿ｌｏｃａｌおよび鍵の有効期間を格納する。ローカル鍵Ｋｓ＿ｌｏｃａｌが要求されるＮＡＦのそれぞれについて、ステップＳ４〜Ｓ８が繰り返される。
【００８１】
上に説明した方法において、代替の実施形態に、事前共有鍵であるＫUHおよびＫIHは、直接に使用されるのではなく、事前共有秘密として使用され、実際の共有鍵は、これらの事前共有秘密から導出される。導出される共有鍵を更新することができる、すなわち、これらは、セッション鍵になる。この形で、ＫUHまたはＫIHのいずれかから導出されたセッション鍵が暴露される場合であっても、秘密自体を、まだセキュアにすることができる。
【００８２】
上に述べたＴＬＳ−ＰＳＫトンネルに引用すると、事前共有秘密を使用する認証される暗号化の他の方法を、代替として使用することができる。１つの代替の実施形態は、ＲＡＤＩＵＳ（Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ−Ｉｎ Ｕｓｅｒ Ｓｅｒｖｉｃｅ）上でのＥＡＰ（拡張認証プロトコル）の使用を組み合わせる。そのような代替方法を、下にさらに説明され新たに提案されるプロトコルの３つすべてのパートに適用することができる。
【００８３】
加えて、上に説明した手順において、ＴＬＳをトンネリングなしで使用することができる、すなわち、ＴＬＳは、暗号化および認証だけに使用され、認証には使用されない。
【００８４】
上に説明した方法に行き渡る要件、すなわち事前に共有される秘密鍵、または事前に共有される秘密鍵から導出されるセッション鍵が、ＧＢＡ＿Ｕ処理、セキュリティアソシエーション処理、およびローカル鍵生成処理をセキュアにするのに使用されることは、ローカル鍵Ｋｓ＿ｌｏｃａｌを初めて生成しなければならない場合にのみ要求される。本明細書で提案される機構の保護の下で、ローカル鍵Ｋｓ＿ｌｏｃａｌが、生成され、ＵＩＣＣ １２６０と端末との両方でセキュアに存在するようにされ（電話機のパワーオフまたはＵＩＣＣの除去の後であっても）、Ｋｓ＿ｌｏｃａｌが、ＮＡＦ鍵センターで（管理のために）維持される場合には、後に、３つの処理のいずれかすなわち、ＧＢＡ＿Ｕ、セキュリティアソシエーション、またはローカル鍵導出処理がもう一度行われる必要がある時に、提案される手順を繰り返す必要はない。これは、そのような場合に、既に生成されセキュアに格納されたローカル鍵Ｋｓ＿ｌｏｃａｌを、本開示で提案される事前共有秘密（または鍵）の代わりに、オリジナルの変更されない処理（ＧＢＡ＿Ｕ、セキュリティアソシエーション、おおびローカル鍵導出）インストならびにＮＡＦ鍵センターでの情報フローの保全性および機密性をセキュアにするのに使用できるからである。
【００８５】
上に提案された新しい方法は、わずかな変更を伴って、ＵＩＣＣ １２６０ホスティングデバイスとリモートデバイスとの間のチャネルを証券化する既存プロトコルにも適用可能である。
【００８６】
（ＩＫＣ １２５０をセキュアにするためのＭＴＭの使用）
ＵＩＣＣ １２６０と端末との間のセキュアチャネルに関する強化されたＧＢＡ＿Ｕ、セキュリティアソシエーション、およびローカル鍵確立の提案される方法（上で説明したパート１、パート２、およびパート３を参照されたい）を実行するために、ＭＴＭ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅ）を携帯電話機（ＵＥ）上で使用して、内部鍵センター（ＩＫＣ １２５０）およびそれが扱い、処理するデータの保全性をセキュアにすることができる。
【００８７】
図１８に、ＭＴＭ １２４０をセクション４．３に説明した変更されたＧＢＡ＿Ｕ処理（パート１）にどのように使用できるかを示す。ＭＴＭ １２４０は、主に、ＩＫＣ １２５０がＧＢＡ＿Ｕ処理を続行する前にＩＫＣ １２５０の保全性を検証するのに使用される。ＭＴＭ １２４０は、それ自体の中で（セキュアな不揮発性ＮＶＲＡＭの下で）またはＩＫＣ １２５０とＢＳＦ １２７０との間ならびにＩＫＣ １２５０とＵＩＣＣ １２６０との間のトンネリングに必要な鍵の暗号化に使用される暗号化鍵をセキュアにすることによってのいずれかで、セキュアに格納するのにも使用される。ＭＴＭ １２４０は、ＴＬＳ−ＰＳＫトンネルでナンスとして使用される乱数を生成するのにも使用される。
【００８８】
同様に、パート１（ＧＢＡ＿Ｕ）処理について上で説明したように、上で提案されたパート２（セキュリティアソシエーション）ステップおよびパート３（ローカル鍵生成）ステップを、類似する形でＭＴＭ １２４０を使用することによって強化することもできる。ＭＴＭ １２４０は、処理のそれぞれの前にＩＫＣ １２５０の保全性を検証し、鍵と、ＩＫＣ １２５０が生成またはＵＩＣＣ １２６０およびＢＳＦ １２７０などの他のエンティティからの受信のいずれかを行う他の機密材料とをセキュアにし、格納し、ＩＫＣ １２５０が取り出すことを可能にし、処理のそれぞれのナンスに使用される乱数を生成するのに使用される。
【００８９】
図１９に、端末およびＩＫＣ １２５０を伴うＭＴＭ １２４０の使用を示す。ＭＴＭ １２４０を、ＩＫＣ １２５０が端末とは別々である時に端末の保全性を検証するのに使用することもでき、この端末は、ＩＫＣ １２５０より信頼できず、セキュアでもないと考えられる。これは、端末が、ＵＩＣＣ １２６０とＩＫＣ １２５０との間でＵＩＣＣ １２６０および端末によって導出されたローカル鍵Ｋｓ＿ｌｏｃａｌをセキュアに取り出し、後に使用することを可能にする。図１９を参照すると、ＵＩＣＣ １２６０とＩＫＣ １２５０との間で導出された鍵Ｋｓ＿ｌｏｃａｌを使用して（パート３の終りを参照されたい）、ＩＫＣ １２５０は、ＭＴＭ １２４０内またはＭＴＭ １２４０による暗号保護の下のいずれかでＫｓ＿ｌｏｃａｌをセキュアに格納する。Ｋｓ＿ｌｏｃａｌから導出される任意のプラットフォーム固有鍵またはアプリケーション固有鍵も、ＭＴＭ １２４０によって同一の形でセキュアに格納される。端末（ＩＫＣ １２５０とは別々）が、Ｋｓ＿ｌｏｃａｌまたはそれから導出される鍵のいずれかを使用できる前に、端末は、ステップＳ１において、ローカル鍵の使用についてＩＫＣ １２５０に要求する。ＩＫＣ １２５０は、ステップＳ２において、端末の保全性を検証するようにＭＴＭ １２４０に要求する。ＭＴＭ １２４０は、ステップＳ３において、端末の保全性を検証する。端末の保全性が、ステップＳ３およびＳ４において、ＭＴＭ １２４０によって端末およびＩＫＣ １２５０に対して検証された後に限って、ＩＫＣ １２５０は、ステップＳ５において、ＭＴＭ １２４０が端末とＵＩＣＣ １２６０との間の通信に使用するために端末によって要求された鍵を公開することを認証する。ステップＳ６において、ローカル鍵（１つまたは複数）が、ＭＴＭ １２４０によって端末に公開される。端末は、ステップＳ７において、ＵＩＣＣ １２６０とのセキュアチャネル（１つまたは複数）を確立するのにそのローカル鍵を使用する。
【００９０】
提案される解決策の利益のいくつかを、下で示す。図１９のステップＳ２、Ｓ３、およびＳ４において、ＩＫＣ １２５０とＢＳＦ １２７０との間での鍵および鍵材料の「バルク」転送および処理を可能にし、ここで、１つまたは複数のＮＡＦ用の材料を、そのＮＡＦに固有のＫｓ＿ｌｏｃａｌ鍵を導出するために交換し、処理することができ、これによって、複数のＮＡＦのＫｓ＿ｌｏｃａｌの導出が従来技術に従って実行される場合に必要になるＯＴＡ手順の数が減る。第２に、ＵＩＣＣ １２６０とＩＫＣ １２５０との間およびＩＫＣ １２５０とＢＳＦ １２７０との間で交換される情報は、今や、２つのＴＬＳ−ＰＳＫトンネルの使用に起因して、保全性と機密性との両方についてセキュアにされる。これは、上で説明した問題に起因する従来技術のプライバシリスクおよび潜在的なセキュリティリスクを軽減する。この利益は、ローカル鍵確立の処理だけではなく、ＧＢＡ＿Ｕ処理およびセキュリティアソシエーション処理にも適用可能である。第３に、どちらもが既存の加入者秘密Ｋまでトレース可能ではない別々の共有秘密ＫUIおよびＫIHの使用は、ＵＩＣＣ １２６０およびＨＬＲ／ＨＳＳ １２８０によって共有される加入者秘密へのトンネリングの処理を分離し、これは、ＫUI鍵およびＫIH鍵の潜在的漏洩が加入者秘密を暴露しないので、セキュリティリスクを減らす。第４に、ＩＫＣ １２５０の使用は、ＩＫＣ １２５０が、その信頼性がＷＴＲＵ １２００上のＭＴＭ １２４０によってセキュアにされる（検証可能かつ証明可能な）信頼されるエンティティなので、セキュリティの利益を加える。ローカル鍵（Ｋｓ＿ｌｏｃａｌ）および鍵材料が、信頼されるＩＫＣ １２５０によって処理されるので、また、ＩＫＣ １２５０が、この情報を保持するＭＴＭ １２４０のセキュアストレージ機能ならびにＲＡＮＤｘおよびＲＡＮＤｙの作成用の乱数ジェネレータなどのＭＴＭ １２４０のセキュアにされた機能を使用できるので、総合的な処理セキュリティが強化される。最後に、ＩＫＣ １２５０の（ならびに、ＩＫＣ １２５０および端末が別々のエンティティである時には端末の）保全性を検証し、鍵および鍵材料をセキュアに格納し、ナンスとして使用される乱数をセキュアに生成するためのＭＴＭ １２４０の使用は、ローカル鍵を確立する処理（パート１からパート３）のセキュリティおよび信頼性を増し、端末が、ＩＫＣ １２５０およびＵＩＣＣ １２６０によって生成されたローカル鍵を、そのローカル鍵の保全性がＭＴＭ １２４０によって検証された後に限って使用することをも可能にする。
【００９１】
本発明の特徴および要素は、望ましい実施形態において特定の組合せにより説明されるが、各特徴または要素を、望ましい実施形態の他の特徴および要素を伴わずに単独において、または本発明の他の特徴および要素を伴ってもしくは伴わずにさまざまな組合せにおいて使用することができる。本発明において提供される方法またはフローチャートは、汎用コンピューターまたはプロセッサによる実行のためにコンピューター読み取り可能な記憶媒体において明白に実装される、コンピュータープログラム、ソフトウェア、またはファームウェアに実装することができる。コンピューター読み取り可能な記憶媒体の例は、読み取り専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、レジスター、キャッシュメモリ、半導体メモリデバイス、例えば内蔵ハードディスク、取外し可能なディスクなどの磁気媒体、光磁気媒体、および例えばＣＤ−ＲＯＭディスク、デジタル多用途ディスク（ＤＶＤ）などの光媒体を含む。
【００９２】
適切なプロセッサは、たとえば、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つまたは複数のマイクロプロセッサ、コントローラー、マイクロコントローラー、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）回路、他のすべての型の集積回路（ＩＣ）、および／または状態機械を含む。
【００９３】
ソフトウェアに関連するプロセッサを使用して、ＷＴＲＵ（ワイヤレス送受信ユニット）、ユーザー機器（ＵＥ）、端末、ＭＥ、基地局、ワイヤレスネットワークコントローラ（ＲＮＣ）、またはすべてのホストコンピューターにおいて使用されるラジオ周波数トランシーバーを実装することができる。ＷＴＲＵは、例えば、カメラ、ビデオ・カメラ・モジュール、ビデオ電話機、スピーカホン、振動デバイス、スピーカー、マイクロホン、テレビジョントランシーバー、ハンズ・フリー・ヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、液晶ディスプレイ（ＬＣＤ）ディスプレイユニット、有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット、デジタル音楽プレイヤー、メディアプレイヤー、ビデオ・ゲーム・プレイヤー・モジュール、インターネットブラウザー、および／またはすべてのワイヤレス・ローカル・エリア・ネットワーク（ＷＬＡＮ）モジュールなどのハードウェアおよび／またはソフトウェアで実装されるモジュールに関連して使用される。
【００９４】
（実施形態）
１．セキュア通信を確立する方法であって、
ａ）内部鍵センター（ＩＫＣ）とＢＳＦ（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ）との間のＴＬＳ−ＰＳＫトンネルの確立を要求することと、
ｂ）ＨＳＳ／ＨＬＲ（ｈｏｍｅ ｓｕｂｓｃｒｉｂｅｒ ｓｙｓｔｅｍ／ｈｏｍｅ ｌｏｃａｔｉｏｎ ｒｅｇｉｓｔｅｒ）から複数の事前共有鍵を取り出すことと、
ｃ）ＩＫＣとＢＳＦとの間のＴＬＳ−ＰＳＫトンネルを確立することと、
ｄ）ＢＳＦから、トンネルを通じて複数の事前共有鍵のうち少なくとも１つをＩＫＣに送信することと、
ｅ）ＵＩＣＣとＩＫＣとの間のＴＬＳ−ＰＳＫトンネルを確立することと、
ｆ）ＵＩＣＣとＢＳＦとの間の少なくとも１つの加入者認証鍵を確立することと
を備えた方法。
２．事前にプロビジョニングされる対称鍵をＩＫＣにより直接に共有することをさらに備えた上記実施形態のいずれかにおける方法。
３．複数の鍵をＩＫＣに送信することと、
正しい鍵が識別されるまでＵＩＣＣを用いて妥当性検査することと
をさらに備えた上記実施形態のいずれかにおける方法。
４．妥当性検査することは、チャレンジ−レスポンスタイプの鍵検証を含む上記実施形態のいずれかにおける方法。
５．事前共有鍵の証拠をＵＩＣＣから受信することと、
証拠をＢＳＦに送信することと、
複数の事前共有鍵から正しい鍵を識別することと
をさらに含む上記実施形態のいずれかにおける方法。
６．要求メッセージを受信することであって、要求メッセージはペイロードとしてＩＫＣ識別子を含む、受信することをさらに含む上記実施形態のいずれかにおける方法。
７．事前共有鍵は、ＩＫＣとＢＳＦとの間のＴＬＳ−ＰＳＫトンネルを確立するのに使用される上記実施形態のいずれかにおける方法。
８．事前共有鍵は、ＵＩＣＣとＩＫＣとの間のトンネルを確立するのに使用される上記実施形態のいずれかにおける方法。
９．ＵＩＣＣによってＮＡＦ識別子を構成することをさらに含む上記実施形態のいずれかにおける方法。
１０．ＩＫＣおよびＢＳＦは、ＩＫＣ識別子について公開鍵ベースの暗号化および公開鍵ベースの暗号化解除を使用する上記実施形態のいずれかにおける方法。
１１．複数の異なる公開鍵から選択することであって、公開鍵は、ネットワークからブロードキャストされる、選択することをさらに含む上記実施形態のいずれかにおける方法。
１２．Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵交換プロトコルが使用される上記実施形態のいずれかにおける方法。
１３．公開鍵への共通インデックスを計算する方法であって、
ネットワークおよびＩＫＣによって２つの値について一致することであって、２つの値は、素数ｐおよび生成元ｇを含む、一致することと、
ネットワークが乱数（ＲＡＮＤi）を選択することと、
【００９５】
【数１０】
を計算することと、
ネットワークが
【００９６】
【数１１】
【００９７】
をＩＫＣに送信することと（１≦ＲＡＮＤi≦ｐ−２）、
ＩＫＣが乱数（ＦＲＥＳＨ）を計算することであって、ｇFRESH≡ｇFRESH ｍｏｄ ｐである、計算することと、
ｇFRESHをネットワークに送信することと（１≦ＦＲＥＳＨ≦ｐ−２）、
ネットワークが
【００９８】
【数１２】
【００９９】
を計算することと、
ＩＫＣが
【０１００】
【数１３】
【０１０１】
を計算することと
を備えた方法。
１４．ＩＫＣ識別子を含んでいるメッセージを暗号化することをさらに備えた上記実施形態のいずれかにおける方法。
１５．ＴＬＳ−ＰＳＫトンネリング確立処理中に公開鍵を交換することをさらに備えた上記実施形態のいずれかにおける方法。
１６．ＤＨ対応ＴＬＳ−ＰＳＫ用のＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿３ＤＥＳ＿ＥＤＥ＿ＣＢＣ＿ＳＨＡ暗号スイートをさらに備えた上記実施形態のいずれかにおける方法。
１７．ＤＨ対応ＴＬＳ−ＰＳＫ用のＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡをさらに備えた上記実施形態のいずれかにおける方法。
１８．ＤＨ対応ＴＬＳ−ＰＳＫ用のＴＬＳ＿ＤＨＥ＿ＰＳＫ＿ＷＩＴＨ＿ＡＥＳ＿２５６＿ＣＢＣ＿ＳＨＡをさらに備えた上記実施形態のいずれかにおける方法。
１９．セキュリティアソシエーションの方法であって、
ＵＩＣＣとＩＫＣとの間およびＩＫＣとＢＳＦとの間の情報を交換することであって、ＵＩＣＣ、ＩＫＣ、およびＢＳＦは交換をセキュアにするのにＴＳＬ−ＰＳＫトンネルを使用する、交換すること
を備えた方法。
２０．ＵＩＣＣ上の有効な加入者認証鍵について検査することをさらに備えた上記実施形態のいずれかにおける方法。
２１．ＵＩＣＣがそれとのセキュリティアソシエーションを確立することを望むＮＡＦのアイデンティティデータを、確立されたトンネル（ＴＵＩ）を介してＵＩＣＣから取り出すことをさらに備えた上記実施形態のいずれかにおける方法。
２２．ＵＩＣＣが複数のＮＡＦ固有鍵を導出することをさらに備えた上記実施形態のいずれかにおける方法。
２３．加入者認証鍵の確立のためにＵＩＣＣベースの強化を有するｇｅｎｅｒａｌ ｂｏｏｔｓｔｒａｐｐｉｎｇ ａｒｃｈｉｔｅｃｔｕｒｅ（ＧＢＡ＿Ｕ）を開始することをさらに備えた上記実施形態のいずれかにおける方法。
２４．複数のトンネルのうちの１つを介してＩＫＣからＢＳＦにアイデンティティデータを送信することをさらに備えた上記実施形態のいずれかにおける方法。
２５．少なくとも１つのＮＡＦに認証要求を送信することをさらに備えた上記実施形態のいずれかにおける方法。
２６．ＢＳＦにおいてＮＡＦから少なくとも１つの認証応答を受信することをさらに備えた上記実施形態のいずれかにおける方法。
２７．ＢＳＦが複数のＮＡＦ固有鍵を導出することをさらに備えた上記実施形態のいずれかにおける方法。
２８．複数のＮＡＦ固有鍵、ブートストラップ時刻、および鍵の有効期間をＢＳＦから複数のＮＡＦに転送することをさらに備えた上記実施形態のいずれかにおける方法。
２９．ＮＡＦからＢＳＦへ、ＮＡＦ固有鍵、鍵の有効期間、およびブートストラップ時刻の受信を示す肯定応答メッセージを送信することをさらに備えた上記実施形態のいずれかにおける方法。
３０．バルク・セキュリティ・アソシエーション・メッセージをＢＳＦからＩＫＣに送信することであって、バルク・セキュリティ・アソシエーション・メッセージはそれぞれが特定のＮＡＦに対応する複数のＮＡＦメッセージ認証コード（ＭＡＣNAF）を含む、送信することをさらに備えた上記実施形態のいずれかにおける方法。
３１．ＩＫＣがＢＳＦから受信したバルク・セキュリティ・アソシエーション・メッセージをＵＩＣＣに転送することをさらに備えた上記実施形態のいずれかにおける方法。
３２．ＮＡＦに固有のＭＡＣUICC_SA atをＵＩＣＣで計算することをさらに備えた上記実施形態のいずれかにおける方法。
３３．ＵＩＣＣによってバルク・セキュリティ・アソシエーション応答メッセージを生成すること をさらに備えた上記実施形態のいずれかにおける方法。
３４．ＮＡＦの対応するＭＡＣUICC_SAに対するＭＡＣIKCは一致しない場合に、セッションの失敗を検出することをさらに備えた上記実施形態のいずれかにおける方法。
３５．ＭＡＣIKCがそれに対応するＭＡＣUICC_SAと一致した場合に、成功を検出することをさらに備えた上記実施形態のいずれかにおける方法。
３６．ＮＡＦ固有鍵およびＭＡＣアルゴリズムを使用して成功応答を送信することをさらに備えた上記実施形態のいずれかにおける方法。
３７．ＩＫＣを介し、複数のトンネルを介してバルク・セキュリティ・アソシエーション応答メッセージをＢＳＦに送信することをさらに備えた上記実施形態のいずれかにおける方法。
３８．ＢＳＦによって、セキュリティアソシエーションの試みの失敗または成功の状況をＮＡＦに示すことをさらに備えた上記実施形態のいずれかにおける方法。
３９．ＮＡＦで成功状況を受信することと、
ＮＡＦ固有鍵、ブートストラップ時刻、および関連する鍵の有効期間を格納することと
をさらに備えた上記実施形態のいずれかにおける方法。
４０．端末とＵＭＴＳ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ（ＵＩＣＣ）との間の鍵を確立する方法であって、
２つのＴＬＳ−ＰＳＫトンネルを使用してセキュアな形で情報を交換すること
を含むことを特徴とする方法。
４１．内部鍵センター（ＩＫＣ）によって、ＵＩＣＣ上の少なくとも１つの有効な加入者認証鍵の存在を識別することと、
ブートストラッピングトランザクション識別子および少なくとも１つのＮＡＦ（ｎｅｔｗｏｒｋ ａｐｐｌｉｃａｔｉｏｎ ｆｕｎｃｔｉｏｎ）識別子をＵＩＣＣから取り出すことと
をさらに備えた上記実施形態のいずれかにおける方法。
４２．少なくとも１つの加入者認証鍵を確立するためにＵＩＣＣベースの強化を有するｇｅｎｅｒａｌ ｂｏｏｔｓｔｒａｐｐｉｎｇ ａｒｃｈｉｔｅｃｔｕｒｅ（ＧＢＡ＿Ｕ）処理を開始することと、
ブートストラッピングトランザクション識別子および少なくとも１つのＮＡＦ識別子をＵＩＣＣから取り出すことと
をさらに備えた上記実施形態のいずれかにおける方法。
４３．ＵＩＣＣとＩＫＣとの間のＴＬＳ−ＰＳＫトンネルを介して情報交換を送信することをさらに備えた上記実施形態のいずれかにおける方法。
４４．それぞれが要求されるＮＡＦのＮＡＦ識別子に対応する少なくとも１つのＩＫＣ鍵に関するアプリケーション要求をＩＫＣからＢＳＦ（ｂｏｏｔｓｔｒａｐｐｉｎｇ ｓｅｒｖｅｒ ｆｕｎｃｔｉｏｎ）に送信することと、
ＩＫＣはブートストラッピングトランザクション識別子および少なくとも１つのＮＡＦ識別子をＫｓ＿ＩＫＣ＿ＮＡＦ（ＲＡＮＤｙ）ナンスについてＩＣＫによって生成された複数の対応するランダムチャレンジと一緒に送信することと
をさらに備えた上記実施形態のいずれかにおける方法。
４５．それぞれが要求されるＮＡＦのそれぞれに固有の少なくとも１つのＩＫＣ鍵を計算することをさらに備えた上記実施形態のいずれかにおける方法。
４６．少なくとも１つのＩＫＣ鍵および鍵の有効期間を含んでいるアプリケーション応答をＩＫＣに送信することをさらに備えた上記実施形態のいずれかにおける方法。
４７．ＩＫＣが、少なくとも１つのｃｏｕｎｔｅｒ ｌｉｍｉｔ値を生成することと、
少なくとも１つのローカル鍵を導出することと
をさらに備えた上記実施形態のいずれかにおける方法。
４８．ＩＫＣが、トンネルＴＵＩを介してアプリケーション要求メッセージをＵＩＣＣに送信することと、
ＮＡＦ識別子に固有のローカル鍵を作成するようにＵＩＣＣに要求することであって、要求は、ＮＡＦ識別子、端末識別子、端末アプリケーション識別子、ＵＩＣＣアプリケーション識別子、およびｃｏｕｎｔｅｒ ｌｉｍｉｔ値を含む、要求することと
をさらに備えた上記実施形態のいずれかにおける方法。
４９．端末がＭＡＣIKCを計算することをさらに備えた上記実施形態のいずれかにおける方法。
５０．ＵＩＣＣが、受信されたＮＡＦ識別子に関連するＫｓ＿ｉｎｔ＿ＮＡＦおよびブートストラッピングトランザクション識別子を取り出すことをさらに備えた上記実施形態のいずれかにおける方法。
５１．ｉｎｔ＿ＮＡＦ鍵およびＲＡＮＤｙに基づいてＩＫＣ−ＮＡＦ鍵を導出することをさらに備えた上記実施形態のいずれかにおける方法。
５２．ＵＩＣＣがローカル鍵を導出することであって、ローカル鍵は、ＩＫＣ−ＮＡＦ鍵、ブートストラッピングトランザクション識別子、端末識別子、ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ ｃａｒｄ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（ＩＣＣＩＤ）、端末アプリケーション識別子、ＵＩＣＣアプリケーション識別子、ＲＡＮＤｘ、およびＣｏｕｎｔｅｒ Ｌｉｍｉｔの関数として決定される、導出すること
をさらに備えた上記実施形態のいずれかにおける方法。
５３．ＵＩＣＣが端末から受信されたＭＡＣIKC値を検証することをさらに備えた上記実施形態のいずれかにおける方法。
５４．ＵＩＣＣが、鍵一致手順を終了することと、
ローカル鍵導出要求に応答してＭＡＣ検証失敗メッセージを返すことと
をさらに備えた上記実施形態のいずれかにおける方法。
５５．ＵＩＣＣがローカル鍵および関連するパラメーターを格納することと、
ＵＩＣＣが鍵ローカル鍵およびＭＡＣアルゴリズムを使用してＡＳＣＩＩ符号化されたストリングのＭＡＣを含んでいるローカル鍵導出応答を送信することと
をさらに備えた上記実施形態のいずれかにおける方法。
５６．ＩＫＣがローカル鍵および鍵の有効期間を格納することをさらに備えた上記実施形態のいずれかにおける方法。
５７．ローカル鍵から実際の共有鍵を導出することと、
導出された共有鍵を更新することと
をさらに備えた上記実施形態のいずれかにおける方法。
５８．認証することおよび暗号化することが、ｒｅｍｏｔｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｄｉａｌ−ｉｎ ｕｓｅｒ ｓｅｒｖｉｃｅを通じて拡張認証プロトコルを組み合わせることをさらに備えた上記実施形態のいずれかにおける方法。
５９．内部鍵センターを使用してセキュアに通信する方法であって、携帯電話機（ＵＥ）のＭＴＭ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅ）を使用して鍵をセキュアにすることを備えた方法。
６０．ＩＫＣがＭＴＭ内にローカル鍵を格納することをさらに備えた上記実施形態のいずれかにおける方法。
６１．ローカル鍵から導出されたすべてのプラットフォーム固有鍵またはアプリケーション固有鍵をＭＴＭによって格納することをさらに備えた上記実施形態のいずれかにおける方法。
６２．端末が、ローカル鍵を使用する前に、ローカル鍵を使用するようにＩＫＣに要求することをさらに備えた上記実施形態のいずれかにおける方法。
６３．ＩＫＣは、ＭＴＭが端末の保全性を検証するように要求することをさらに備えた上記実施形態のいずれかにおける方法。
６４．ＭＴＭが端末の保全性を検証することをさらに備えた上記実施形態のいずれかにおける方法。
６５．ＩＫＣは、ＭＴＭが、それ自体とＵＩＣＣとの間の通信に使用される、端末によって要求される複数の鍵を公開すること認証することをさらに備えた上記実施形態のいずれかにおける方法。
６６．少なくとも１つのローカル鍵をＭＴＭから端末に公開することをさらに備えた上記実施形態のいずれかにおける方法。
６７．端末が、ＵＩＣＣとの少なくとも１つのセキュアチャネルを確立するためにローカル鍵を送信することをさらに備えた上記実施形態のいずれかにおける方法。
６８．ＵＩＣＣによって実行される上記実施形態のいずれかにおける方法。
６９．ＢＳＦによって実行される上記実施形態のいずれかにおける方法。
７０．ＷＴＲＵ（ワイヤレス送受信ユニット）によって実行される上記実施形態のいずれかにおける方法。
７１．基地局によって実行される上記実施形態のいずれかにおける方法。
７２．ＩＫＣによって実行される上記実施形態のいずれかにおける方法。
【特許請求の範囲】
【請求項１】
ＷＴＲＵによって使用され、セキュア通信を確立する方法であって、
前記ＷＴＲＵ内のＩＫＣとＵＩＣＣとの間の一時的なセキュアチャネルを確立するステップと、
前記確立された一時的なセキュアチャネルによりＧＢＡ＿Ｕ処理およびローカル鍵設定処理を実行することによって前記ＵＩＣＣとＩＫＣとの間のセキュアチャネルを確立するステップと
を備えたことを特徴とする方法。
【請求項２】
前記一時的なセキュアチャネルを確立するステップは、
前記ＩＫＣとＢＳＦとの間のセキュアトンネルを確立するステップと、
前記確立されたセキュアトンネルにより第１の鍵を受信するステップであって、前記一時的なセキュアチャネルは前記第１の鍵を使用して確立される、受信するステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記セキュアトンネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項１に記載の方法。
【請求項４】
前記一時的なセキュアチャネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項１に記載の方法。
【請求項５】
前記一時的なセキュアチャネルは、共有秘密を使用して確立されることを特徴とする請求項１に記載の方法。
【請求項６】
前記共有秘密は、前記ＩＫＣおよび前記ＵＩＣＣにおいてあらかじめプロビジョニングされることを特徴とする請求項５に記載の方法。
【請求項７】
セキュア通信を確立するよう構成されたＷＴＲＵであって、
一時的なセキュアチャネル、ＵＩＣＣを確立して、
前記確立された一時的なセキュアチャネルによりＧＢＡ＿Ｕ処理およびローカル鍵設定処理を実行することによって前記ＵＩＣＣとＢＳＦとの間のセキュアチャネルを確立する
よう構成されたＩＫＣ
を備えたことを特徴とするＷＴＲＵ。
【請求項８】
前記ＩＣＫは、
前記ＩＫＣと前記ＢＳＦとの間のセキュアトンネルを確立して、
前記セキュアにされたトンネルにより第１の鍵を受信する
ようさらに構成され、前記一時的なセキュアチャネルは前記第１の鍵を使用して確立されることを特徴とする請求項７に記載のＷＴＲＵ。
【請求項９】
前記セキュアトンネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項８に記載の方法。
【請求項１０】
前記一時的なセキュアチャネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項７に記載の方法。
【請求項１１】
前記一時的なセキュアチャネルは、共有秘密を使用して確立されることを特徴とする請求項７に記載の方法。
【請求項１２】
前記共有秘密は、前記ＩＫＣおよび前記ＵＩＣＣにおいてあらかじめプロビジョニングされることを特徴とする請求項１１に記載の方法。
【請求項１３】
ＩＫＣによって使用されるセキュア通信の方法であって、
ＵＩＣＣにより第１のセキュアにされたトンネルを確立するステップと、
ＢＳＦにより第２のセキュアにされたトンネルを確立するステップと、
前記第１のトンネルおよび前記第２のトンネルを使用して、前記ＵＩＣＣに少なくも２つのネットワークアプリケーション機能のセキュリティアソシエーション情報を提供するステップと
を備えたことを特徴とする方法。
【請求項１４】
前記第１のトンネルおよび前記第２のトンネルを使用して、セキュリティアソシエーション応答を前記ＵＩＣＣから前記ＢＳＦへ転送するステップをさらに備えたことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記第１のトンネルおよび前記第２のトンネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項１３に記載の方法。
【請求項１６】
ＩＫＣを含むＷＴＲＵによって使用されるセキュアローカル鍵を確立する方法であって、
有効な鍵がＵＩＣＣに存在するかどうかを判定するステップと、
Ｂ−ＴＩＤおよび少なくとも１つのＮＡＦ−ＩＤを前記ＵＩＣＣから取り出すステップと、
鍵に関するアプリケーション要求をＢＳＦへ送信するステップと、
少なくとも１つの鍵を含んでいるアプリケーション応答を受信するステップと、
ｃｏｕｎｔｅｒ ｌｉｍｉｔを生成して、少なくとも１つのＮＡＦに関連するパラメーターからローカル鍵を導出するステップと、
鍵確立に関するアプリケーション要求を前記ＵＩＣＣへ送信するステップと、
前記ローカル鍵の成功した検証を示すローカル導出応答を受信するステップと、
前記ローカル鍵および前記関連するパラメーターのすべてを前記ＩＫＣに格納するステップと
を備えたことを特徴とする方法。
【請求項１７】
前記Ｂ−ＴＩＤおよび少なくとも１つのＮＡＦ−ＩＤを前記ＵＩＣＣから取り出すステップが、第１のセキュアトンネルを通じて行われることを特徴とする請求項１６に記載の方法。
【請求項１８】
前記鍵に関するアプリケーション要求をＢＳＦへ送信するステップが、第２のセキュアトンネルを通じて行われることを特徴とする請求項１６に記載の方法。
【請求項１９】
前記少なくとも１つの鍵を含んでいるアプリケーション応答を受信するステップが、前記第２のセキュアチャネルを通じて行われることを特徴とする請求項１８に記載の方法。
【請求項２０】
前記第１のトンネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項１９に記載の方法。
【請求項２１】
前記第２のトンネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項１９に記載の方法。
【請求項１】
ＷＴＲＵによって使用され、セキュア通信を確立する方法であって、
前記ＷＴＲＵ内のＩＫＣとＵＩＣＣとの間の一時的なセキュアチャネルを確立するステップと、
前記確立された一時的なセキュアチャネルによりＧＢＡ＿Ｕ処理およびローカル鍵設定処理を実行することによって前記ＵＩＣＣとＩＫＣとの間のセキュアチャネルを確立するステップと
を備えたことを特徴とする方法。
【請求項２】
前記一時的なセキュアチャネルを確立するステップは、
前記ＩＫＣとＢＳＦとの間のセキュアトンネルを確立するステップと、
前記確立されたセキュアトンネルにより第１の鍵を受信するステップであって、前記一時的なセキュアチャネルは前記第１の鍵を使用して確立される、受信するステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記セキュアトンネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項１に記載の方法。
【請求項４】
前記一時的なセキュアチャネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項１に記載の方法。
【請求項５】
前記一時的なセキュアチャネルは、共有秘密を使用して確立されることを特徴とする請求項１に記載の方法。
【請求項６】
前記共有秘密は、前記ＩＫＣおよび前記ＵＩＣＣにおいてあらかじめプロビジョニングされることを特徴とする請求項５に記載の方法。
【請求項７】
セキュア通信を確立するよう構成されたＷＴＲＵであって、
一時的なセキュアチャネル、ＵＩＣＣを確立して、
前記確立された一時的なセキュアチャネルによりＧＢＡ＿Ｕ処理およびローカル鍵設定処理を実行することによって前記ＵＩＣＣとＢＳＦとの間のセキュアチャネルを確立する
よう構成されたＩＫＣ
を備えたことを特徴とするＷＴＲＵ。
【請求項８】
前記ＩＣＫは、
前記ＩＫＣと前記ＢＳＦとの間のセキュアトンネルを確立して、
前記セキュアにされたトンネルにより第１の鍵を受信する
ようさらに構成され、前記一時的なセキュアチャネルは前記第１の鍵を使用して確立されることを特徴とする請求項７に記載のＷＴＲＵ。
【請求項９】
前記セキュアトンネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項８に記載の方法。
【請求項１０】
前記一時的なセキュアチャネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項７に記載の方法。
【請求項１１】
前記一時的なセキュアチャネルは、共有秘密を使用して確立されることを特徴とする請求項７に記載の方法。
【請求項１２】
前記共有秘密は、前記ＩＫＣおよび前記ＵＩＣＣにおいてあらかじめプロビジョニングされることを特徴とする請求項１１に記載の方法。
【請求項１３】
ＩＫＣによって使用されるセキュア通信の方法であって、
ＵＩＣＣにより第１のセキュアにされたトンネルを確立するステップと、
ＢＳＦにより第２のセキュアにされたトンネルを確立するステップと、
前記第１のトンネルおよび前記第２のトンネルを使用して、前記ＵＩＣＣに少なくも２つのネットワークアプリケーション機能のセキュリティアソシエーション情報を提供するステップと
を備えたことを特徴とする方法。
【請求項１４】
前記第１のトンネルおよび前記第２のトンネルを使用して、セキュリティアソシエーション応答を前記ＵＩＣＣから前記ＢＳＦへ転送するステップをさらに備えたことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記第１のトンネルおよび前記第２のトンネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項１３に記載の方法。
【請求項１６】
ＩＫＣを含むＷＴＲＵによって使用されるセキュアローカル鍵を確立する方法であって、
有効な鍵がＵＩＣＣに存在するかどうかを判定するステップと、
Ｂ−ＴＩＤおよび少なくとも１つのＮＡＦ−ＩＤを前記ＵＩＣＣから取り出すステップと、
鍵に関するアプリケーション要求をＢＳＦへ送信するステップと、
少なくとも１つの鍵を含んでいるアプリケーション応答を受信するステップと、
ｃｏｕｎｔｅｒ ｌｉｍｉｔを生成して、少なくとも１つのＮＡＦに関連するパラメーターからローカル鍵を導出するステップと、
鍵確立に関するアプリケーション要求を前記ＵＩＣＣへ送信するステップと、
前記ローカル鍵の成功した検証を示すローカル導出応答を受信するステップと、
前記ローカル鍵および前記関連するパラメーターのすべてを前記ＩＫＣに格納するステップと
を備えたことを特徴とする方法。
【請求項１７】
前記Ｂ−ＴＩＤおよび少なくとも１つのＮＡＦ−ＩＤを前記ＵＩＣＣから取り出すステップが、第１のセキュアトンネルを通じて行われることを特徴とする請求項１６に記載の方法。
【請求項１８】
前記鍵に関するアプリケーション要求をＢＳＦへ送信するステップが、第２のセキュアトンネルを通じて行われることを特徴とする請求項１６に記載の方法。
【請求項１９】
前記少なくとも１つの鍵を含んでいるアプリケーション応答を受信するステップが、前記第２のセキュアチャネルを通じて行われることを特徴とする請求項１８に記載の方法。
【請求項２０】
前記第１のトンネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項１９に記載の方法。
【請求項２１】
前記第２のトンネルは、ＴＬＳ−ＰＳＫトンネルであることを特徴とする請求項１９に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２ａ】
【図１２ｂ】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２ａ】
【図１２ｂ】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公表番号】特表２０１１−５０１９０８（Ｐ２０１１−５０１９０８Ａ）
【公表日】平成２３年１月１３日（２０１１．１．１３）
【国際特許分類】
【出願番号】特願２０１０−５２８２０１（Ｐ２０１０−５２８２０１）
【出願日】平成２０年１０月６日（２００８．１０．６）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０７８８９３
【国際公開番号】ＷＯ２００９／０４６４００
【国際公開日】平成２１年４月９日（２００９．４．９）
【出願人】（５９６００８６２２）インターデイジタル テクノロジー コーポレーション (871)
【Ｆターム（参考）】
【公表日】平成２３年１月１３日（２０１１．１．１３）
【国際特許分類】
【出願日】平成２０年１０月６日（２００８．１０．６）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０７８８９３
【国際公開番号】ＷＯ２００９／０４６４００
【国際公開日】平成２１年４月９日（２００９．４．９）
【出願人】（５９６００８６２２）インターデイジタル テクノロジー コーポレーション (871)
【Ｆターム（参考）】
[ Back to top ]