JP2008546333A - 通信コネクションを保護するために少なくとも１つの第１の通信加入者と少なくとも１つの第２の通信加入者との間で秘密鍵を一致させるための方法 - Google Patents

Abstract

本発明は、通信コネクションを保護するために少なくとも１つの第１の通信加入者と少なくとも１つの第２の通信加入者との間で秘密鍵を一致させるための方法に関する。本発明の課題は、適切な措置により通信コネクションを保護するために少なくとも１つの第１の通信加入者と少なくとも１つの第２の通信加入者との間で秘密鍵を一致させる方法を通信に関するセキュリティレベルが高められるように改善し、その改善された方法が既存の方法をカバーするようにすることである。この課題は、認証および鍵導出プロトコルから少なくとも１つの第１のパラメータが求められ、さらに付加的なパラメータが第２の通信加入者から第１の通信加入者に機密的に伝送され、最終的に第１のパラメータおよび付加的なパラメータから秘密鍵が求められることにより解決される。

Description

本発明は、通信コネクションを保護するために少なくとも１つの第１の通信加入者と少なくとも１つの第２の通信加入者との間で秘密鍵を一致させるための方法とコンピュータプログラムに関する。

第３世代の移動無線システムに関しては３ＧＰＰの仕様書から、ユーザとネットワークオペレータとの間の長期間のセキュリティ関係からユーザと通信ネットワーク装置との間の短期間のセキュリティ関係が導出される方法が公知である。長期間のセキュリティ関係は長期間の秘密暗号鍵を基礎としており、この秘密暗号鍵はユーザのセキュリティモジュール、いわゆるＵＭＴＳ−ＳＩＭカード（技術的に正確には：ＵＩＣＣカードにおけるＵＳＩＭアプリケーション）およびネットワークオペレータの認証中央局に記憶されている。この長期間の鍵からいわゆるＧＢＡ方法（GBA = Generic Bootstrapping Architecture、汎用ブートストラッピング方法）により短期間の鍵Ｋｓが導出される。この導出はユーザ装置（UE = User Equipment）、通信ネットワークにおける計算ユニット（BSF = Bootstrapping Server Function）ならびに通信ネットワーク加入者システム（HSS = Home Subscriber Server）の間でメッセージが交換されることにより行われる。この短期間の鍵はユーザの移動通信端末機器と別の通信ネットワーク装置（NAF = Network Application Function）との間の通信を保護するために別の鍵導出関数を用いてＫｓ＿ＮＡＦとして使用される。３Ｇ ＴＳ ３３．１０２において規定されているＧＢＡ法はＵＭＴＳ ＡＫＡプロトコル（AKA = Authentication and Key Agreement、認証／暗号鍵配送方式）を基礎とする。このプロトコルは３Ｇ ＴＳ ３３．１０２において規定されており、ＵＳＩＭアプリケーションがユーザのもとに必ず存在していることを前提としている。ＵＭＴＳ ＡＫＡプロトコルは安全なやり方でそれぞれが１２８ビットのセッションキーＣＫおよびＩＫを生成する。ＴＳ ３３．２２０に記載されているように、ユーザの移動通信端末装置と通信ネットワーク装置との間の通信を保護するために、セッションキーＣＫおよびＩＫから短期間の鍵Ｋｓ＿ＮＡＦが導出される。

もっともＵＭＴＳ標準に準拠する移動通信端末装置はＧＳＭ標準に準拠する移動通信端末装置ほどまだ広く普及していない。したがって、あらゆるＧＳＭ移動無線電話において使用されているようなＳＩＭカードも、依然として希少なＵＭＴＳ−ＳＩＭカードよりも実質的に広く普及している。しかしながらＧＳＭネットワークオペレータにとっても、移動通信端末装置と通信ネットワーク装置との間の安全なコネクションをＧＳＭユーザに対して提供することは大きな関心事である。したがって２Ｇ ＧＢＡの名称での最新の標準化プロジェクトの目標は、ＵＭＴＳ−ＳＩＭカードおよびＵＭＴＳ ＡＫＡプロトコルの代わりにＳＩＭカードまたはＵＩＣＣカードにおけるＳＩＭアプリケーションおよびＧＳＭ ＡＫＡプロトコルを使用する、ＧＢＡに対応する通信保護方法を定義することである。

このプロジェクトに従事する理由の１つは、移動通信端末装置と通信ネットワーク装置との安全な通信を目的としてユーザとの新規で長期のセキュリティ関係を築く必要がないようにすることが将来の２Ｇ ＧＢＡ方法において期待されるからである。したがって新たなＵＭＴＳ−ＳＩＭカードがユーザに配布されることは回避されるべきである。このような配布は常にネットワークオペレータにとって多額の負担となる。すなわち、ユーザのもとにあるＳＩＭカードまたはＳＩＭアプリケーションがＵＩＣＣカードにおいてさらに使用されるべきであり、これによってユーザとネットワークオペレータとの間の既存の関係を利用することができる。

この際ＧＳＭ ＡＫＡプロトコルのセキュリティがＵＭＴＳ ＡＫＡプロトコルのセキュリティよりも著しく低いことは問題である。さらには、ＧＳＭ ＡＫＡプロトコルによって生成されるセッションキーは多くの目的のために非常に短いものである（最大で６４ビット）。またセッションキーは信頼性の低いアルゴリズム、例えばＧＳＭの暗号化アルゴリズムＡ５／１およびＡ５／２によって使用される。したがって、セッションキーが攻撃者によって突き止められ、これにより２Ｇ ＧＢＡ方法のセキュリティが完全に失われる危険が存在する。

したがって本発明の課題は、第３世代の移動無線システムから公知であるＧＢＡ方法を、ＧＢＡ ＡＫＡプロトコルおよびＳＩＭの使用しながらも可能な限り僅かな変更で、移動通信端末装置と通信ネットワーク装置の通信におけるセキュリティレベルをＧＳＭ ＡＫＡプロトコルに比べてさらに高められるように拡張することである。

本発明の別の課題は、適切な措置により通信コネクションを保護するために少なくとも１つの第１の通信加入者と少なくとも１つの第２の通信加入者との間で秘密鍵を一致させる方法を通信に関するセキュリティレベルが高められるように改善し、その改善された方法が既存の方法をカバーするようにすることである。

本発明によればこの課題は、請求項１に記載されている特徴を有する方法および請求項２０に記載されている特徴を有するコンピュータプログラムによって解決される。本発明の有利な実施形態は従属請求項に記載されている。

本発明によれば、通信コネクションを保護するために少なくとも１つの第１の通信加入者と少なくとも１つの第２の通信加入者との間において秘密鍵を一致させる方法において、認証および鍵導出プロトコルから少なくとも１つの第１のパラメータが求められる。さらに、第２の通信加入者は付加的なパラメータを機密的なやり方で、伝送の機密性が認証および鍵導出プロトコルに依存せずに保証されるように第１の通信加入者に伝送する。最終的に第１のパラメータおよび付加的なパラメータから秘密鍵が求められる。

本発明の実施形態によれば、付加的なパラメータは乱数または別のデータを有する乱数のチェーンである。

本発明の別の実施形態によれば、付加的なパラメータに包含されている乱数は認証および鍵導出プロトコルの構成要素であり、このプロトコルから第１のパラメータが求められる。

本発明の別の実施形態によれば、第１の通信加入者は移動通信端末装置として実施されており、第２の通信加入者は通信ネットワーク装置として実施されている。

本発明の有利な実施形態によれば、第２の通信加入者は第１の通信加入者に対して公開鍵を有する証明書を介して認証される。

本発明の別の有利な実施形態によれば、第１の通信加入者は第２の通信加入者に対して認証および鍵導出プロトコルを介して認証され、このプロトコルから第１のパラメータが求められる。

本発明の別の有利な実施形態によれば、第１の通信加入者は第２の通信加入者に対して、通信ネットワークのユーザの管理を専門とする第３の通信加入者により認証される。

本発明の有利な実施形態のヴァリエーションによれば、第１の通信加入者は３ＧＰＰに準拠する移動無線規格によるユーザ装置として実施されており、第２の通信加入者は移動無線規格３Ｇ ＴＳ ３３．２２０に準拠するブートストラッピングサーバ機能として実施されており、第３の通信加入者は移動無線規格３Ｇ ＴＳ ３３．２２０に準拠するホーム加入者システムとして実施されている。

本発明の別の有利な実施形態のヴァリエーションによれば、付加的なパラメータを機密に伝送するために、保護プロトコルとして規格ＲＦＣ２２４６に準拠するトランスポート層セキュリティプロトコルを使用するか、規格ＲＦＣ３５４６に準拠する拡張形態を使用する。

本発明の別の有利な実施形態のヴァリエーションによれば、第１のパラメータを求めるための認証および鍵導出プロトコルが移動無線規格３Ｇ ＴＳ ４３．０２０に準拠して実施される。

本発明の別の実施形態によれば、認証および鍵導出プロトコルのパラメータは、ＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡ（認証および鍵共有）のための規格ＲＦＣ３３１０に準拠して定義されているフィールドにおいて適切な形で第１のパラメータを求めるために伝送される。本発明の別の実施形態によれば、パラメータの伝送が規格ＴＳ ３３．２２０に準拠して行われる。

本発明の別の実施形態によれば、付加的なパラメータは、ＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡ（認証および鍵共有）のための規格ＲＦＣ３３１０に準拠して定義されているフィールドにおいて適切な形で伝送される。

本発明の別の実施形態によれば、フィールドは「ＲＡＮＤ」および「サーバ固有データ」を包含する。

通信コネクションを保護するために少なくとも１つの第１の通信加入者と少なくとも１つの第２の通信加入者との間において秘密鍵を一致させるための本発明によるコンピュータプログラム製品の実施形態においては、認証および鍵導出プロトコルから少なくとも１つの第１のパラメータが求められる。さらに、第２の通信加入者は付加的なパラメータを機密的なやり方で、伝送の機密性が認証および鍵導出プロトコルに依存せずに保証されるように第１の通信加入者に伝送する。制御プログラムがプログラム実行装置において実行される場合には、第１のパラメータおよび付加的なパラメータから秘密鍵が求められる。

以下では本発明を図面に示した実施例に基づき詳細に説明する。ここで、
図１は、ブートストラッピング方法に含まれているエンティティの概略的なネットワークモデルおよびエンティティ間で使用される基準点を示し、
図２は２Ｇ認証ベクトルを用いるブートストラッピング方法を概略的に示す。

ユーザ装置（以下ではＵＥと記す）１０１とネットワークアプリケーション機能（以下ではＮＡＦと記す）１０３との間の通信を開始できるようになる前に、ＵＥとＮＡＦは先ず、汎用ブートストラッピングアーキテクチャ（以下ではＧＢＡと記す）プロシージャに従い動作したいか否かについて合意しなければならない。第１のステップにおいてＵＥ１０１はＧＢＡに関連する何らかのパラメータを用いずに基準点Ｕａ１０２を介してＮＡＦ１０３と通信を開始する。ＮＡＦがＧＢＡ方法によって得られる鍵の使用を要求するが、ＵＥによる問い合わせがＧＢＡに関連するパラメータを包含していない場合には、ＮＡＦはブーストストラッピング開始メッセージでもって応答する。

ＵＥ１０１がＮＡＦ１０３と対話しようとし、且つブーストストラッピングプロシージャに従い動作すべきことを知ると、ＵＥは先ずブーストストラッピング認証を実施する。そうでない場合には、ＵＥが要求されるブーストストラッピング開始に関するメッセージまたはブーストストラッピングの新たな交渉についての要求をＮＡＦから受信した場合、またはＵＥにおける鍵Ｋｓの有効期間が過ぎている場合にのみＵＥはブーストストラッピング認証を行うべきである。

このためにＵＥ２０１は基準点Ｕｂ１０５（図１を参照されたい）を介してＨＴＴＰＳ要求２０４をブーストストラッピングサーバ機能（ＢＳＦ）２０２に送信する。この開始ＨＴＴＰＳ要求およびＵＥとＢＳＦとの間のその他の全ての通信は保護されたトランスポート層セキュリティ（以下ではＴＬＳと記す）チャネルを介して送信される。このＴＬＳチャネルを確立する際にＵＥはＢＳＦによって既に発行されている証明書を介してこのＢＳＦを認証する。ＵＥは「ＲＥＡＬＭ」属性がＢＳＦによって既に発行された証明書に包含されているものと同じＢＳＦの完全修飾ドメイン名（以下ではＦＱＤＮ（Fully Qualified Domain Name）と記す）を包含するか否かを検査する。

ＢＳＦ２０２は認証ベクトルおよびＧＢＡユーザセキュリティセッティング（以下ではＧＵＳＳ（GBA User Security Settings）と記す）２０５をホーム加入者システム（以下ではＨＳＳ（Home Subscriber System）と記す）２０３から基準点Ｚｈ（図１を参照されたい、１０４）を介して要求する。ＨＳＳはＧＢＡユーザセキュリティセッティング（ＧＵＳＳ）の完全なセットおよび２Ｇ認証ベクトル（ＡＶ＝ＲＡＮＤ，ＳＲＥＳ，Ｋｃ）２０５を基準点Ｚｈを介して返送する。ＡＶのタイプによってＢＳＦはＵＥに２Ｇ ＳＩＭが設けられているかを知る。ＢＳＦは２Ｇ認証ベクトル（ＲＡＮＤ，Ｋｃ，ＳＲＥＳ）を擬似３Ｇ認証ベクトルのパラメータＲＡＮＤ_ＵＭＴＳ，ＲＥＳ_ＵＭＴＳおよびＡＵＴＮ_ＵＭＴＳに変換する。３Ｇ認証ベクトルのセッションキーＣＫおよびＩＫへの変換は必要ない：
−ＲＡＮＤ_ＵＭＴＳ＝ＲＡＮＤ
−ＲＥＳ_ＵＭＴＳ＝ＫＤＦ（Ｋｅｙ、"３ＧＰＰ−ＧＢＡ−ＲＥＳ" || ＳＲＥＳ）、１２８ビットに短縮
−ＡＵＴＮ_ＵＭＴＳ＝ＫＤＦ（Ｋｅｙ、"３ＧＰＰ−ＧＢＡ−ＡＵＴＮ" || ＲＡＮＤ）、１２８ビットに短縮、ここでＫｅｙ＝Ｋｃ || Ｋｃ || ＲＡＮＤであり、ＫＤＦはＴＳ ３３．２２０における補遺Ｂにおいて規定されている鍵導出関数である。ここで「１２８ビットに短縮」とは、ＫＤＦの２５６の出力ビットから０〜１２７の番号を有する１２８ビットが選択されることを意味している。

ＢＳＦは乱数「Ｋｓ−ｉｎｐｕｔ」を選択し、ＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡのフィールド「ａｋａ−ｎｏｎｃｅ」にサーバ固有データ（Server Specific Data）＝Ｋｓ−Ｉｎｐｕｔをセットしなければならない。

ＵＥが自身の認証を要求するために、ＢＳＦはサーバ固有データ（すなわちＫｓ−Ｉｎｐｕｔ）、ＲＡＮＤ_UMTSおよびＡＵＴＮ_UMTSを「４０１」メッセージ２０６においてＵＥに転送する。

ＵＥはメッセージからＲＡＮＤを抽出し、対応するＫｃおよびＳＲＥＳ値を算出する（ステップ２０７）。続いてＵＥはこれらの値から擬似３Ｇ認証ベクトルパラメータＲＡＮＤ_UMTS，ＲＥＳ_UMTSおよびＡＵＴＮ_UMTSを計算する。ＵＥは計算されたＡＵＴＮ_UMTSを、ＢＳＦから得ている対応する値と比較する。値が一致しない場合、ＵＥはプロシージャを中断する。

ＵＥは別のＨＴＴＰ要求をＤｉｇｅｓｔ ＡＫＡ応答でもってＢＳＦに送信し（ステップ２０８）、ＲＥＳ_ＵＭＴＳはパスワードとして使用される。

ＢＳＦはＵＥをＤｉｇｅｓｔ ＡＫＡ応答の検査により認証する（ステップ２０９）。認証されない場合、ＢＳＦはこの認証ベクトルを後続の通信において再び使用すべきではない。

ＢＳＦは、Ｋｓ＝ＫＤＦ（Ｋｅｙ || Ｋｓ−Ｉｎｐｕｔ，"３ＧＰＰ−ＧＢＡ−Ｋｓ" || ＳＲＥＳ）を計算することにより鍵マテリアルを生成する（ステップ２１０）。ブートストラッピングトランザクション識別子（Ｂ−ＴＩＤ）値はＮＡＩフォーマットで、Ｂａｓｅ ６４で復号化されたＲＡＮＤ_UMTS値およびＢＳＦサーバ名、例えばBase64encode (RAND_UMTS)@BSF_Servers_Domain_Nameを使用することにより生成されるべきである。

ＢＳＦは認証の成功を確認するために２００ＯＫメッセージをＢ−ＴＩＤと共にＵＥに送信する（ステップ２１１）。付加的にＢＳＦは２００ＯＫメッセージにおいて鍵Ｋｓの有効期間を伝送する。

ＵＥはＢＳＦと同じやり方で鍵マテリアルＫｓを生成する（ステップ２１２）。

ＵＥおよびＢＳＦはいずれも基準点Ｕａを保護するために鍵マテリアルＫｓ＿ＮＡＦの導出に鍵マテリアルＫｓを使用する。Ｋｓ＿ＮＡＦはＫｓ＿ＮＡＦ＝ＫＤＦ（Ｋｓ、鍵導出パラメータ）により計算され、ＫＤＦは補遺Ｂにおいて規定された鍵導出関数であり、また鍵導出パラメータはユーザＩＭＰＩ、ＮＡＦ＿ＩＤおよびＲＡＮＤ＿ＵＭＴＳから構成されている。ＮＡＦ＿ＩＤはＮＡＦの完全なＤＮＳ名から構成されている。ＵＥおよびＢＳＦにおけるＮＡＦ名を基礎とする矛盾のない鍵導出を保証するためには、以下の３つの前提のうちの少なくとも１つが充足されている。
１．ＮＡＦはＤＮＳにおいて１つのドメイン名（ＦＱＤＮ）のもとでのみ既知である。すなわち例えば２つの異なるドメイン名がＮＡＦのＩＰアドレスを示唆することはない。このことは管理措置によって達成される。
２．ＮＡＦの各ＤＮＳエントリは異なるＩＰアドレスを示唆する。ＮＡＦはこれら全てのＩＰアドレスに応答する。各ＩＰアドレスはＮＡＦコンフィギュレーションによって対応するＦＱＤＮに結びつけられる。ＮＡＦはＩＰアドレスに基づき、どのＦＱＤＮが鍵導出のために使用されるべきかを識別することができる。
３．基準点ＵａはＮＡＦについてのホスト名を一緒に伝送するプロトコルを使用する。これは、適切であれば、ホスト名をＵＥとの全ての通信において使用するために、またこのホスト名をＢＳＦに伝送して鍵マテリアルＫｓ＿ＮＡＦの適切な導出を保証するためにホスト名の有効性を検査することをＮＡＦに強制する。

ＵＥおよびＢＳＦは、鍵Ｋｓの有効期間が経過するまで、または鍵Ｋｓが更新されるまで、鍵Ｋｓをこの鍵に所属するＢ−ＴＩＤと一緒に記憶すべきである。

鍵Ｋｓ＿ＮＡＦが対応する鍵導出パラメータＮＡＦ＿ＩＤのために存在する場合には、ＵＥおよびＮＡＦは基準点Ｕａを介する安全な通信を開始することができる。

これまでその種の２Ｇ ＧＢＡ方法に関しては２つの解決手段が公知であり、それらはＮｏｋｉａの寄稿論文Ｓ３−０５００５３およびＱｕａｌｃｏｍｍの寄稿論文Ｓ３−０５００９７において関連する標準化グループ３ＧＰＰ ＳＡ３に紹介されている。

Ｎｏｋｉａの寄稿論文Ｓ３−０５００５３は短いＧＳＭセッションキーＫｃの問題を、このセッションキーＫｃが２Ｇ ＧＢＡ方法のインスタンスに関してＧＳＭ ＡＫＡプロトコルの複数のインスタンス、いわゆるＧＳＭトリプレットを使用することにより解決する。これによって複数のセッションキーＫｃが得られ、これらのセッションキーＫｃは十分な長さの１つの短期間の鍵に結合される。ここでＧＳＭ ＡＫＡプロトコルはネットワークに対するユーザの認証、ユーザに対するネットワークの認証およびセッションキーの一致に対して使用される。ＧＳＭ ＡＫＡプロトコルのためのキャリアプロトコルとして、仕様書ＲＦＣ ３３１０によるプロトコルＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡが使用され、ＧＳＭ ＡＫＡプロトコルのパラメータは変換機能によって適切に適合される。

Ｑｕａｌｃｏｍｍの寄稿論文Ｓ３−０５００９７はセッションキーの一致に関してＤｉｆｆｉｅ Ｈｅｌｌｍａｎ方法を使用する。ユーザに対するネットワークの認証はＤｉｆｆｉｅ Ｈｅｌｌｍａｎ方法のパラメータを用いた証明書の使用およびディジタル署名の使用を基礎とする。ＧＳＭ ＡＫＡプロトコルはネットワークに対するユーザの認証のためにのみ使用され、ＧＳＭ鍵ＫｃはＤｉｆｆｉｅ Ｈｅｌｌｍａｎ方法のパラメータを用いてメッセージ認証コード（ＭＡＣ）を生成するために使用される。

これに対して本発明の実施例によれば上述の問題を以下のように解決する。

本発明による方法はＧＳＭ ＡＫＡプロトコルのためのキャリアプロトコルとして、仕様書ＲＦＣ ３３１０に準拠するＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡプロトコルを使用し、ＧＳＭ ＡＫＡプロトコルのパラメータは適切な変換機能によって適合される。ここでは２Ｇ ＧＢＡインスタンス毎にＧＳＭ ＡＫＡプロトコルのインスタンスは１つしか使用されない。付加的に、移動通信端末装置とＢＳＦとの間で仕様書ＲＦＣ ２２４６に準拠するトランスポート層セキュリティコネクション（ＴＬＳ）が確立される。このＴＬＳコネクションにおいては強い暗号がアクティブにされる。移動通信端末装置に対するＢＳＦの認証はこのＴＬＳコネクションの確立時に証明書に基づき行われる。しかしながら移動通信端末装置はＴＬＳコネクションの確立時には認証されない。ＢＳＦに対する移動通信端末装置の認証はＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡプロトコルに埋込まれているＧＳＭ ＡＫＡの使用によって行われる。

これによって、本発明による方法の短期間の鍵のセキュリティがＧＳＭのセキュリティもＴＬＳのセキュリティも基礎としているという有利な作用が得られる。２つの方法、ＧＳＭおよびＴＬＳが具体的な使用環境において妥協する場合、またはＧＳＭへの重大な攻撃によりＧＳＭ方法がここで説明するブートストラッピング方法の実施中に妥協することができる場合にのみ妥協することができる。

鍵導出関数による短期間の鍵の計算にはＧＳＭプロトコルから得られるパラメータＫｃおよびＳＲＥＳ（Signed Response）および乱数が使用され、これらはＴＬＳ暗号化によってＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡプロトコルの一部として保護されており、ＢＳＦから移動通信端末装置に安全に伝送される。これらの乱数を例えば仕様書ＲＦＣ ３３１０に準拠するフィールド「ＡＫＡ−ＮＯＮＣＥ」において、Ｃｈａｌｌｅｎｇｅ ＲＡＮＤとしても「サーバ固有データ」の一部としても伝送することができる。

本発明の方法により提案される措置によって殊に以下の利点が得られる。

−導出された短期間の鍵を発見するために、攻撃者はＧＳＭパラメータＫｃならびにＳＲＥＳも、ＴＬＳを介して安全に伝送される乱数も発見しなければならない。すなわち、攻撃者はＧＳＭ方法にもＴＬＳ方法の使用にも攻撃を仕掛けなければならない。これによって攻撃に対するセキュリティは著しく高まる。

−導出された短期間の鍵の効果的な長さは付加的なパラメータの一部として乱数Ｋｓインプットを使用することにより、Ｓ３−０５００５３における提案と比べて著しく高められる。パラメータはＧＳＭ ＡＫＡの構成部分ではない。これによって攻撃に対するセキュリティはさらに高まる。

−２Ｇ ＧＢＡインスタンス毎にＧＳＭ ＡＫＡの単一のインスタンスの使用しか必要とされない。これによりＳ３−０５００５３における提案に比べてＧＳＭ認証局における負荷が著しく低減される。

−Ｓ３−０５００５３における提案のセキュリティに関しては一般的に、２Ｇ ＧＢＡにおいて使用されたＧＳＭトリプレットを攻撃者が他のコンテキストにおいていつか再び使用することを確実に阻止することが必要とされる。これによってパラメータＫｃおよびＳＲＥＳが例えば暗号化アルゴリズムＡ５／１またはＡ５／２への攻撃によって突き止められる可能性があり、したがって２Ｇ ＧＢＡの短期間の鍵も突き止められる可能性がある。しかしながら実際にこれを実現することは容易ではない。これに対して本願発明による方法への攻撃は、攻撃者がＧＳＭパラメータＫｃおよびＳＲＥＳを２Ｇ ＧＢＡのプロトコル実行中に突き止めることができた場合にのみ可能であろう。しかしながら今日の見解によれば、数秒の周期についてアルゴリズムＡ５／２に関してのみ考えられるが、これは２Ｇ ＧＢＡを支援する端末機器においてはもはや許容されていない。したがって提案される方法はＳ３−０５００５３における提案よりも実質的に有効であるだけでなく、安全性もさらに高まっている。

−Ｓ３−０５００９７における提案と比較した場合のさらなる利点は、本発明の安全性が複数の独立した要素を基礎としていることである。殊にＵＥは計算され受信したＡＵＴＮ_UMTSの比較によってもＢＳＦを認証することができる。これに対してＱｕａｌｃｏｍｍによる提案の安全性は単に証明書を用いたＢＳＦの安全な認証を基礎としているに過ぎない。

参考文献
３Ｇ Ｓ３−０５００５３
ftp://ftp.3gpp.org/TSG_SA/WG3_Security/TSGS3_37_Sophia/Docs/ を参照されたい。
３Ｇ Ｓ３−０５００９７
ftp://ftp.3gpp.org/TSG_SA/WG3_Security/TSGS3_37_Sophia/Docs/ を参照されたい。
３Ｇ ＴＳ ３３．２２０ ｖ６．４．０
ftp://ftp.3gpp.org/Specs/ を参照されたい。
３Ｇ ＴＳ ３３．２２０ ｖ６．３．０
ftp://ftp.3gpp.org/Specs/ を参照されたい。
３Ｇ ＴＳ ３３．２２０ ｖ６．１．０
ftp://ftp.3gpp.org/Specs/ を参照されたい。
ＲＦＣ ３３１０ http://www.ietf.org/rfc.html を参照されたい。
ＲＦＣ ２２４６ http://www.ietf.org/rfc.html を参照されたい。

ブートストラッピング方法に含まれているエンティティの概略的なネットワークモデルおよびエンティティ間で使用される基準点を示す。 認証ベクトルを用いるブートストラッピング方法を概略的に示す。

Claims (20)

1. 通信コネクションを保護するために少なくとも１つの第１の通信加入者と少なくとも１つの第２の通信加入者との間で秘密鍵を一致させるための方法において、
   −認証および鍵導出プロトコルから少なくとも１つの第１のパラメータを求め、
   −前記第２の通信加入者は付加的なパラメータを機密的なやり方で、伝送の機密性が前記認証および鍵導出プロトコルに依存せずに保証されるように前記第１の通信加入者に伝送し、
   −前記第１のパラメータおよび前記付加的なパラメータから秘密鍵を求めることを特徴とする、秘密鍵を一致させるための方法。
2. 前記付加的なパラメータを少なくとも１つの第１の部分および少なくとも１つの第２の部分に分割する、請求項１記載の方法。
3. 前記付加的なパラメータは乱数であるか、別のデータを有する乱数のチェーンである、請求項１または２記載の方法。
4. 前記乱数の一部は前記認証および鍵導出プロトコルの構成要素であり、該プロトコルから前記第１のパラメータを求める、請求項１から３までのいずれか１項記載の方法。
5. 前記第１の通信加入者を移動通信端末装置として実施し、前記第２の通信加入者を通信ネットワーク装置として実施する、請求項１から４までのいずれか１項記載の方法。
6. 公開鍵を有する証明書を介して前記第１の通信加入者に対して前記第２の通信加入者を認証させる、請求項１から５までのいずれか１項記載の方法。
7. 前記第１のパラメータが導出される認証および鍵導出プロトコルを介して前記第２の通信加入者に対して前記第１の通信加入者を認証させる、請求項１から６までのいずれか１項記載の方法。
8. 通信ネットワークのユーザの管理を専門とする第３の通信加入者により、前記第２の通信加入者に対して前記第１の通信加入者を認証させる、請求項１から７までのいずれか１項記載の方法。
9. 前記第１の通信加入者を３ＧＰＰの移動無線規格に準拠するユーザ装置（ＵＥ）として実施し、前記第２の通信加入者を移動無線規格３Ｇ ＴＳ ３３．２２０に準拠するブートストラッピングサーバ機能（ＢＳＦ）として実施し、前記第３の通信加入者を移動無線規格３Ｇ ＴＳ ３３．２２０に準拠するホーム加入者サーバ（ＨＳＳ）として実施する、請求項１から８までのいずれか１項記載の方法。
10. 前記付加的なパラメータを機密に伝送するために、保護プロトコルとして規格ＲＦＣ２２４６に準拠するトランスポート層セキュリティ（ＴＬＳ）プロトコルを使用するか、規格ＲＦＣ３５４６に準拠する拡張形態を使用する、請求項１から９までのいずれか１項記載の方法。
11. 前記第１のパラメータを求めるための前記認証および鍵導出プロトコルを移動無線規格３Ｇ ＴＳ ４３．０２０に準拠して実施する、請求項１から１０までのいずれか１項記載の方法。
12. 前記認証および鍵導出プロトコルのパラメータを、ＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡ（認証および鍵共有）のための規格ＲＦＣ３３１０に準拠して定義されているフィールドにおいて適切な形で第１のパラメータを求めるために伝送する、請求項１から１１までのいずれか１項記載の方法。
13. 前記パラメータの伝送を規格ＴＳ３３．２２０に準拠して実施する、請求項１１記載の方法。
14. 前記付加的なパラメータを、ＨＴＴＰ Ｄｉｇｅｓｔ ＡＫＡ（認証および鍵共有）のための規格ＲＦＣ３３１０に準拠して定義されているフィールドにおいて適切な形で伝送する、請求項１から１３までのいずれか１項記載の方法。
15. 前記付加的なパラメータの少なくとも２つの部分を異なるフィールドにおいて伝送する、請求項１３記載の方法。
16. 前記フィールドは「ＲＡＮＤ」および「サーバ固有データ」を包含する、請求項１から１５までのいずれか１項記載の方法。
17. 鍵導出関数を、入力パラメータハッシュキーおよびハッシュデータを用いる鍵導出関数として構成する、請求項１から１６までのいずれか１項記載の方法。
18. 前記付加的なパラメータの第１の部分をハッシュキーに包含させ、前記付加的なパラメータの第２の部分を前記ハッシュデータに包含させる、請求項１６記載の方法。
19. 前記付加的なパラメータの第１の部分をハッシュキーおよびハッシュデータに包含させ、前記付加的なパラメータの第２の部分を前記ハッシュキーに包含させる、請求項１６記載の方法。
20. 通信コネクションを保護するために少なくとも１つの第１の通信加入者と少なくとも１つの第２の通信加入者との間で秘密鍵を一致させる、プログラム実行制御装置の動作メモリにおいて読み出し可能であり、且つ少なくとも１つのコードセクションを有するコンピュータプログラム製品において、
    制御プログラムが前記プログラム実行制御装置において実行される場合に、
    −認証および鍵導出プロトコルから少なくとも１つの第１のパラメータが求められ、
    −前記第２の通信加入者は付加的なパラメータを機密的なやり方で、伝送の機密性が前記認証および鍵導出プロトコルに依存せずに保証されるように前記第１の通信加入者に伝送し、
    −前記第１のパラメータおよび前記付加的なパラメータから秘密鍵を求めることを特徴とする、コンピュータプログラム製品。

Images