特許 6979420 通信デバイスとネットワークデバイスとの間の通信におけるセキュリティ構成

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6979420

(24)【登録日】2021年11月17日

(45)【発行日】2021年12月15日

(54)【発明の名称】通信デバイスとネットワークデバイスとの間の通信におけるセキュリティ構成

(51)【国際特許分類】

   H04L 9/32 20060101AFI20211202BHJP

   H04W 12/06 20210101ALI20211202BHJP

   H04L 9/08 20060101ALI20211202BHJP

   G09C 1/00 20060101ALI20211202BHJP

【ＦＩ】

   H04L9/00 675A

   H04W12/06

   H04L9/00 601C

   H04L9/00 601E

   G09C1/00 640E

【請求項の数】14

【外国語出願】

【全頁数】34

(21)【出願番号】特願2019-90941(P2019-90941)

(22)【出願日】2019年5月13日

(62)【分割の表示】特願2017-545344(P2017-545344)の分割

【原出願日】2015年7月13日

(65)【公開番号】特開2019-169963(P2019-169963A)

(43)【公開日】2019年10月3日

【審査請求日】2019年5月30日

(31)【優先権主張番号】62/121,689

(32)【優先日】2015年2月27日

(33)【優先権主張国】US

【前置審査】

(73)【特許権者】

【識別番号】598036300

【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）

(74)【代理人】

【識別番号】110003281

【氏名又は名称】特許業務法人大塚国際特許事務所

(72)【発明者】

【氏名】ネズルンド、マッツ

(72)【発明者】

【氏名】サーリン、ベンクト

(72)【発明者】

【氏名】ノールマン、カール

(72)【発明者】

【氏名】アルッコ、ヤリ

【審査官】 中里 裕正

(56)【参考文献】

【文献】 特表２００８−５３０８６１（ＪＰ，Ａ）

【文献】 特表２００３−５２４３５３（ＪＰ，Ａ）

【文献】 特表２００９−５１２２９６（ＪＰ，Ａ）

【文献】 LAI, C. et al.，SE-AKA: A secure and efficient group authentication and key agreement protocol for LTE networks，Computer Networks，No.57，2013年，pp.3492-3510

【文献】 3GPP，3G Security; Generic Authentication Architecture (GAA); System description (Release 12)，TR 33.919，V12.0.0，[online]，2014年09月，https://www.3gpp.org/ftp/Specs/archive/33_series/33.919/33919-c00.zip，[2020年4月15日検索]

【文献】 3GPP，Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) (Release 12)，TS 33.220，V12.3.0，[online]，2014年06月，https://www.3gpp.org/ftp/Specs/archive/33_series/33.220/33220-c30.zip，[2020年4月15日検索]

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ９／３２

Ｈ０４Ｗ １２／０６

Ｈ０４Ｌ ９／０８

Ｇ０９Ｃ １／００

(57)【特許請求の範囲】

【請求項1】

通信ネットワーク（３６）のネットワークデバイス（４４）と通信するための通信デバイス（４０）であって、
チャレンジ（ＲＡＮＤ）と、第１のＰＦＳパラメータ（ＰＦＳ１）と、前記第１のＰＦＳパラメータ（ＰＦＳ１）についての第１の検証コード（ＶＣ１Ａ；ＶＣ１Ｂ）であって、少なくとも前記第１のＰＦＳパラメータに基づくメッセージ認証コードを含む第１の検証コード（ＶＣ１Ａ；ＶＣ１Ｂ）と、チャレンジ検証コード（ＡＵＴＮ）とを前記ネットワークデバイス（４４）から認証要求メッセージ（２０）内で受信し、
前記チャレンジをアイデンティティモジュール（４８）へ転送し、
暗号化鍵（ＣＫ）と、完全性保護鍵（ＩＫ）と、応答パラメータ（ＲＥＳ）とを、前記アイデンティティモジュール（４８）からの応答として受信し、
前記暗号化鍵、完全性保護鍵及び応答パラメータに基づいて、前記第１のＰＦＳパラメータ（ＰＦＳ１）が真正であるかを判定し、
前記判定において前記第１のＰＦＳパラメータ（ＰＦＳ１）が真正である場合に、
第２のＰＦＳパラメータ（ＰＦＳ２）を生成し、
前記暗号化鍵（ＣＫ）、完全性保護鍵（ＩＫ）及び応答パラメータ（ＲＥＳ）のうちの少なくとも１つに基づいて第２の検証コード（ＶＣ２；ＶＣ２Ａ；ＶＣ２Ｂ）を生成し、
前記第２のＰＦＳパラメータ（ＰＦＳ２）と、前記第２の検証コード（ＶＣ２；ＶＣ２Ａ；ＶＣ２Ｂ）と、前記応答パラメータ（ＲＥＳ）とを認証応答メッセージ（２４）内で前記ネットワークデバイスへ送信し、前記第２の検証コード（ＶＣ２Ａ）は、前記応答パラメータ（ＲＥＳ）に割り当てられた情報エレメント内で送信される、
ように動作可能な通信デバイス（４０）。

【請求項2】

前記通信デバイス（４０）と前記ネットワークデバイス（４４）との間の通信のためのセッション鍵（Ｋ´）を生成する、ようにさらに動作可能であり、前記セッション鍵は、前記第１及び第２のＰＦＳパラメータ（ＰＦＳ１，ＰＦＳ２）を生成するために使用される値（ｘ，ｙ）に少なくとも基づく、請求項１に記載の通信デバイス（４０）。

【請求項3】

前記セッション鍵は、前記第１のＰＦＳパラメータ（ＰＦＳ１）と前記第２のＰＦＳパラメータ（ＰＦＳ２）の指数（ｙ）とに基づく、請求項２に記載の通信デバイス。

【請求項4】

前記通信デバイスは、前記チャレンジ（ＲＡＮＤ）を受信し、前記転送を実行し、前記暗号化鍵、完全性保護鍵及び応答パラメータを受信し、前記第１のＰＦＳパラメータ（ＰＦＳ１）が真正であるかを判定し、並びに第２のＰＦＳパラメータ（ＰＦＳ２）を生成し及び送信するように動作可能なモバイル機器（４６）、を含む、請求項１乃至３のいずれか１項に記載の通信デバイス（４０）。

【請求項5】

前記通信デバイスは、前記アイデンティティモジュール（４８）を含み、前記アイデンティティモジュールは、鍵及び暗号処理手段を含む、請求項１乃至４のいずれか１項に記載の通信デバイス（４０）。

【請求項6】

前記第１及び第２のＰＦＳパラメータはディフィーヘルマンパラメータである、請求項１乃至５のいずれか１項に記載の通信デバイス。

【請求項7】

前記認証要求メッセージ（２０）は、前記認証要求メッセージの対応する別個の情報エレメント内に前記第１の検証コード（ＶＣ１Ｂ）を含み、前記通信デバイスは、前記第１のＰＦＳパラメータ（ＰＦＳ１）の真正性を判定するよう動作可能であるとき、前記第１の検証コード（ＶＣ１Ｂ）を使用するように動作可能である、請求項１乃至６のいずれか１項に記載の通信デバイス（４０）。

【請求項8】

前記第１の検証コード（ＶＣ１Ａ）は、前記チャレンジ検証コード（ＡＵＴＮ）の少なくとも一部として提供され、前記通信デバイスは、前記第１のＰＦＳパラメータ（ＰＦＳ１）の真正性を判定するように動作可能であるとき、前記アイデンティティモジュール（４８）が前記暗号化鍵（ＣＫ）、完全性保護鍵（ＩＫ）及び応答パラメータ（ＲＥＳ）を提供することに基づいて真正性を判定するように動作可能である、請求項１乃至６のいずれか１項に記載の通信デバイス（４０）。

【請求項9】

前記第２の検証コード（ＶＣ２Ａ）は、少なくとも前記第２のＰＦＳパラメータ（ＰＦＳ２）に基づくメッセージ認証コードとして生成される、請求項１乃至８のいずれか１項に記載の通信デバイス。

【請求項10】

通信ネットワーク（３６）のネットワークデバイス（４４）と通信関係にある通信デバイス（４０）のための方法であって、前記方法は、前記通信デバイスによって実行され、
チャレンジ（ＲＡＮＤ）と、第１のＰＦＳパラメータ（ＰＦＳ１）と、前記第１のＰＦＳパラメータ（ＰＦＳ１）についての第１の検証コード（ＶＣ１Ａ；ＶＣ１Ｂ）であって、少なくとも前記第１のＰＦＳパラメータに基づくメッセージ認証コードを含む第１の検証コード（ＶＣ１Ａ；ＶＣ１Ｂ）、チャレンジ検証コード（ＡＵＴＮ）とを前記ネットワークデバイス（４４）から認証要求メッセージ（２０）内で受信すること（６４）と、
前記チャレンジをアイデンティティモジュール（４８）へ転送すること（６５）と、
暗号化鍵（ＣＫ）と、完全性保護鍵（ＩＫ）と、応答パラメータ（ＲＥＳ）とを、前記アイデンティティモジュール（４８）からの応答として受信すること（６６）と、
前記暗号化鍵（ＣＫ）、完全性保護鍵（ＩＫ）及び応答パラメータ（ＲＥＳ）に基づいて、前記第１のＰＦＳパラメータ（ＰＦＳ１）が真正であるかを判定すること（６８）と、
前記判定において前記第１のＰＦＳパラメータ（ＰＦＳ１）が真正である場合に、
第２のＰＦＳパラメータ（ＰＦＳ２）を生成すること（７０）と、
前記暗号化鍵（ＣＫ）、完全性保護鍵（ＩＫ）及び応答パラメータ（ＲＥＳ）のうちの少なくとも１つに基づいて第２の検証コード（ＶＣ２；ＶＣ２Ａ；ＶＣ２Ｂ）を生成すること（７０）と、
前記第２のＰＦＳパラメータ（ＰＦＳ２）と、前記第２の検証コード（ＶＣ２；ＶＣ２Ａ；ＶＣ２Ｂ）と、前記応答パラメータ（ＲＥＳ）とを認証応答メッセージ（２４）内で前記ネットワークデバイスへ送信すること（７２）であって、前記第２の検証コード（ＶＣ２Ａ）は、前記応答パラメータ（ＲＥＳ）に割り当てられた情報エレメント内で送信される、ことと、
を含む方法。

【請求項11】

第１の通信ネットワーク（３６）の第１のネットワークデバイス（４４）であって、前記第１のネットワークデバイス（４４）は、
チャレンジ（ＲＡＮＤ）及びチャレンジ検証コード（ＡＵＴＮ）を取得し、
第１のＰＦＳパラメータ（ＰＦＳ１）を取得し、
前記第１のＰＦＳパラメータ（ＰＦＳ１）についての第１の検証コード（ＶＣ１Ａ；ＶＣ１Ｂ）であって、少なくとも前記第１のＰＦＳパラメータに基づくメッセージ認証コードを含む第１の検証コード（ＶＣ１Ａ；ＶＣ１Ｂ）を取得し、
前記チャレンジ（ＲＡＮＤ）、前記第１のＰＦＳパラメータ（ＰＦＳ１）、前記第１の検証コード（ＶＣ１Ａ；ＶＣ１Ｂ）及び前記チャレンジ検証コード（ＡＵＴＮ）を通信デバイス（４０）へ認証要求メッセージ（２０）内で送信し、
前記通信デバイス（４０）から認証応答メッセージ（２４）内で第２のＰＦＳパラメータ（ＰＦＳ２）、第２の検証コード（ＶＣ２；ＶＣ２Ａ；ＶＣ２Ｂ）及び応答パラメータ（ＲＥＳ）を受信し、前記第２の検証コード（ＶＣ２Ａ）は前記応答パラメータ（ＲＥＳ）に割り当てられた情報エレメント内で受信され、
前記応答パラメータの真正性を判定し、
前記第２の検証コード（ＶＣ２；ＶＣ２Ａ；ＶＣ２Ｂ）に基づいて前記第２のＰＦＳパラメータ（ＰＦＳ２）を検証する
ように動作可能である、第１のネットワークデバイス（４４）。

【請求項12】

前記通信デバイス（４０）と前記第１のネットワークデバイス（４４）との間の通信のためのセッション鍵（Ｋ´）を計算する、ようにさらに動作可能であり、前記セッション鍵は、前記第１及び第２のＰＦＳパラメータ（ＰＦＳ１，ＰＦＳ２）を生成するために使用される値（ｘ，ｙ）に少なくとも基づく、請求項１１に記載の第１のネットワークデバイス（４４）。

【請求項13】

前記セッション鍵は、前記第２のＰＦＳパラメータ（ＰＦＳ２）と前記第１のＰＦＳパラメータ（ＰＦＳ１）の指数（ｘ）とに基づく、請求項１２に記載の第１のネットワークデバイス（４４）。

【請求項14】

第１の通信ネットワーク（３６）の第１のネットワークデバイス（４４）のための方法であって、前記方法は、前記第１のネットワークデバイス（４４）によって実行され、
チャレンジ（ＲＡＮＤ）及びチャレンジ検証コード（ＡＵＴＮ）を取得するステップ（７４）と、
第１のＰＦＳパラメータ（ＰＦＳ１）を取得するステップ（７６）と、
前記第１のＰＦＳパラメータについての第１の検証コード（ＶＣ１Ａ；ＶＣ１Ｂ）であって、少なくとも前記第１のＰＦＳパラメータに基づくメッセージ認証コードを含む第１の検証コード（ＶＣ１Ａ；ＶＣ１Ｂ）を取得するステップ（７８）と、
前記チャレンジ（ＲＡＮＤ）、前記第１のＰＦＳパラメータ（ＰＦＳ１）、前記第１の検証コード（ＶＣ１；ＶＣ１Ａ；ＶＣ１Ｂ）及び前記チャレンジ検証コード（ＡＵＴＮ）を通信デバイス（４０）へ認証要求メッセージ（２０）内で通信デバイス（４０）へ送信するステップ（８０）と、
前記通信デバイス（４０）から認証応答メッセージ（２４）内で第２のＰＦＳパラメータ（ＰＦＳ２）、第２の検証コード（ＶＣ２；ＶＣ２Ａ；ＶＣ２Ｂ）及び応答パラメータ（ＲＥＳ）を受信するステップ（８２）であって、前記第２の検証コード（ＶＣ２Ａ）は前記応答パラメータ（ＲＥＳ）に割り当てられた情報エレメント内で受信される、ステップと、
前記応答パラメータの真正性を判定するステップ（８４）と、
前記第２の検証コード（ＶＣ２；ＶＣ２Ａ；ＶＣ２Ｂ）に基づいて前記第２のＰＦＳパラメータ（ＰＦＳ２）を検証するステップ（８６）と
を含む方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワークデバイスと通信するための通信デバイス、通信ネットワークのネットワークデバイスと通信関係にある通信デバイスのための方法、コンピュータプログラム及びコンピュータプログラムプロダクト、第１の通信ネットワークの第１のネットワークデバイス、第１の通信ネットワークの第１のネットワークノードのための方法、コンピュータプログラム及びコンピュータプログラムプロダクト、並びに、第１の通信システム内の第１のネットワークデバイスと第２の通信システム内の第２のネットワークデバイスとを含むシステムに関する。本発明は、第２のネットワークデバイスにも関する。

【背景技術】

【0002】

通信ネットワーク上を移送されるデータは、次第にセンシティブになりつつある。モバイル、ワイヤレス及び固定の通信ネットワークといった通信ネットワークは、今日では、例えば多様な経済的及び商業関連のトランザクション、サイバー−物理システムの制御などのために、ますます頻繁に使用されている。従って、より強いセキュリティ施策を求めるニーズが存在する。

【0003】

例えばモバイル通信では、通信ネットワークとユーザ機器（ＵＥ）とが互いに相互認証を行って、交換されるトラフィックデータを暗号化できることが重要であり、それらセキュリティサービスは、鍵合意（key agreement）又は鍵確立（key establishment）を含むセキュアな鍵管理に決定的に依存する。

【0004】

この点において、第２世代（２Ｇ）以降のモバイルネットワークは、強力な（Ｕ）ＳＩＭ（(Universal) Subscriber Identity Module）カードベースの認証及び暗号鍵合意を活用してきた。第３世代（３Ｇ）以降のネットワークより、認証は相互的となっており：ネットワーク及びユーザ機器の双方が互いを認証する。ＵＳＩＭベースの３Ｇ／４Ｇ認証は、例えば３ＧＰＰ ＴＳ３３．１０２ Ｖ１２．２．０及び３３．４０１ Ｖ１２．１３．０において説明されている。そのプロトコルは、どちらのアクセスネットワークタイプが使用されるかに依存してＵＭＴＳ ＡＫＡ又はＬＴＥ ＡＫＡとして知られており、ＵＭＴＳ ＡＫＡはUniversal Mobile Telecommunication System Authentication and Key Agreementについての頭字語、ＬＴＥ ＡＫＡはLong Term Evolution Authentication and Key Agreementについての頭字語である。留意事項として、３ＧＰＰ標準は鍵合意との用語を使用する一方、実際に使用されるプロトコルは、どちらかというと鍵確立の性質を有する。但し、その違いは本議論にとって重要ではない。このＡＫＡプロトコルの異種が、ＩＰマルチメディアサブシステム（ＩＭＳ）、ＩＭＳ ＡＫＡ、非３ＧＰＰアクセス技術（ＥＡＰ−ＡＫＡ、ＩＥＴＦ ＲＦＣ４１８７）のために、及び一般的なサービスレイヤ認証（汎用ブートストラッピングアーキテクチャ、ＧＢＡ、３ＧＰＰ ＴＳ３３．２２０ Ｖ１２．３．０）のために開発されてきている。

【0005】

図１は、ＴＳ ３３．１０２ Ｖ１２．２．０による３Ｇネットワークのための高レベルでのＡＫＡの機能を示しており、ユーザ機器に対応する一種の通信デバイスである移動局ＭＳは、ＨＥ（Home Environment）／ＨＬＲ（Home Location Register）と通信するサービングネットワーク（ＳＮ）のＶＬＲ（Visiting Location Register）／ＳＧＳＮ（Serving Gateway Support Node）と通信する。４Ｇ／ＬＴＥでは、モバイル管理エンティティ（ＭＭＥ）がＶＬＲ／ＳＧＳＮに取って代わり、ＨＥ／ＨＬＲはホーム加入者サーバ（ＨＳＳ）に対応する。

【0006】

図１では、ＶＬＲ／ＳＧＳＮは、１０で、訪問中の移動局ＭＳに関して、ＨＥ／ＨＬＲへ認証データ要求を送信するものとして示されている。ＨＥ／ＨＬＲは、１２で、１組の認証ベクトル（ＡＶ（ｉ．．ｎ））を生成し、１４で、認証データ応答メッセージにおいてベクトル（ＡＶｉ．．ｎ）をＶＬＲ／ＳＧＳＮへ送信し、ＶＬＲ／ＳＧＳＮは、次いで、１６で、その認証ベクトルを記憶する。これらのステップは、ここでは一緒に、ＨＥからの配信及び認証ベクトルの段階１７を形成する。

【0007】

その後、認証及び鍵確立（又は鍵合意）の段階３１が行われる。この段階３１で認証が行われる際、ＶＬＲ／ＳＧＳＮは、１８で、利用可能な（未使用の）認証ベクトルを選択し、このベクトルの内容に基づいて、２０で、ランダム値Ｒａｎｄ（ｉ）及び認証トークンＡＵＴＮ（ｉ）を使用してチャレンジを含むユーザ認証要求メッセージＡＲＱを送信し、ここでＡＵＴＮ（ｉ）はチャレンジ検証コードを含み、インデックスｉはその値がＡＶ_ｉに関連付けられていることを示す。ＡＵＴＮ（ｉ）がＭＳにおいて検証され、検証が成功すると、検証ステップ２２において結果ＲＥＳ（ｉ）が計算される。正確に言えば、これらの動作は、ＭＳにおいてＵＳＩＭによって実行される。次いで、ＭＳは、２０で、結果ＲＥＳ（ｉ）を含むユーザ認証応答メッセージ（ＡＲＥ）を送信する。認証ベクトルは、期待される結果ＸＲＥＳ（ｉ）を含み、ＶＬＲ／ＳＧＳＮは、次いで、２６で、受信された結果ＲＥＳ（ｉ）を期待される結果ＸＲＥＳ（ｉ）と比較し、比較が成功した（すなわち、２つの値が等しい）場合、ＶＬＲ／ＳＧＳＮは、３０で、対応する暗号化鍵（ciphering key）ＣＫ（ｉ）及び完全性保護鍵ＩＫ（ｉ）を選択する。同時に、ＭＳ（この場合も、正確に言えば、ＵＳＩＭ）は、２８で、同じ鍵ＣＫ（ｉ）及びＩＫ（ｉ）を計算する。ＬＴＥの場合、たとえば、いわゆるＫａｓｍｅ鍵（図示せず）など、さらなる鍵がＣＫ（ｉ）及びＩＫ（ｉ）から導出され、この導出は、ＵＳＩＭの外側にあるＭＳの部分で行われる。ＵＳＩＭの外側のこの部分は、モバイル機器（ＭＥ）と呼ばれる。

【0008】

図１に示し、上記で説明したタイプの認証及び鍵合意では、有利には予め共有された秘密鍵Ｋが使用され、ユーザ機器（具体的にはＵＳＩＭ）とホームネットワークの双方に記憶される。次いで、ＣＫ（ｉ）及びＩＫ（ｉ）を導出するために、共有鍵Ｋが使用される。

【0009】

従って、ＡＫＡのセキュリティは、鍵Ｋが秘密に保たれることに依存する。近日、ＵＳＩＭカードの製造業者のセキュリティが破られ、Ｋ鍵のセットが「漏洩」し（又は悪意のある者へ渡り）、従って、これらの鍵に関連付けられた加入者が、偽装、接続ハイジャック、及び盗聴などの危険にさらされる（なぜなら、ＣＫ（ｉ）及び／又はＩＫ（ｉ）から導出される暗号化鍵もまたそのようにして潜在的に危険にさらされる）ことがメディアで報告された。２０１５年７月６日に得られたhttps://firstlook.org/interceptcepts/2015/02/19/great-sim-heist/の記事に、前述のセキュリティへの影響をもたらすＡＫＡプロトコルの潜在的な問題は、ＡＫＡがいわゆるＰＦＳ（Perfect forward Secrecy）を欠いていることにあることが述べられている。

【0010】

上述したことに鑑みて、セキュリティが通信ネットワークノードと共有される秘密／鍵を使用するＵＳＩＭなどのアイデンティティモジュールに基づく場合の通信デバイスと通信ネットワークとの間の通信のセキュリティレベルを上げることが重要である。

【発明の概要】

【発明が解決しようとする課題】

【0011】

従って、通信デバイスと通信ネットワークとの間の通信セキュリティを強化することを求めるニーズが存在する。

【課題を解決するための手段】

【0012】

発明の１つの目的は、長期（long-term）共有鍵の使用に関して通信デバイスの通信セキュリティを強化することである。

【0013】

上記目的は、第１の態様によれば、通信ネットワークのネットワークデバイスと通信関係にある通信デバイスによって達成される。上記通信デバイスは、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードをネットワークデバイスから受信し、チャレンジ又はその派生をアイデンティティモジュールへ転送し、少なくとも１つの結果パラメータを、アイデンティティモジュールからの応答として受信し、上記結果パラメータに基づいて、第１のＰＦＳパラメータが真正であるかを判定し、第２のＰＦＳパラメータを生成し、上記判定において第１のＰＦＳパラメータが真正である場合に、第２のＰＦＳパラメータをネットワークデバイスへ送信するように構成される。

【0014】

上記目的は、第２の態様によれば、通信ネットワークのネットワークデバイスと通信関係にある通信デバイスによって実行される方法によって達成される。上記方法は、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードをネットワークデバイスから受信することと、チャレンジ又はその派生をアイデンティティモジュールへ転送することと、少なくとも１つの結果パラメータを、アイデンティティモジュールからの応答として受信することと、上記結果パラメータに基づいて、第１のＰＦＳパラメータが真正であるかを判定することと、第２のＰＦＳパラメータを生成することと、上記判定において第１のＰＦＳパラメータが真正である場合に、第２のＰＦＳパラメータをネットワークデバイスへ送信することとを含む。

【0015】

上記目的は、第３の態様によれば、通信ネットワークのネットワークデバイスと通信関係にある通信デバイスのためのコンピュータプログラムによって達成される。上記コンピュータプログラムは、通信デバイスにおいて実行されると、通信デバイスに、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードをネットワークデバイスから受信させ、チャレンジ又はその派生をアイデンティティモジュールへ転送させ、少なくとも１つの結果パラメータを、アイデンティティモジュールからの応答として受信させ、上記結果パラメータに基づいて、第１のＰＦＳパラメータが真正であるかを判定させ、第２のＰＦＳパラメータを生成させ、上記判定が肯定的である、すなわち、第１のＰＦＳパラメータが真正である場合に、第２のＰＦＳパラメータをネットワークデバイスへ送信させる、コンピュータプログラムコードを含む。

【0016】

上記目的は、第４の態様によれば、通信ネットワークのネットワークノードと通信関係にある通信デバイスのためのコンピュータプログラムプロダクトによって達成される。上記コンピュータプログラムプロダクトは、第３の態様に係るコンピュータプログラムコードを有するデータ記憶媒体を含む。

【0017】

第１、第２及び第４の態様に係る本発明は、いくつかの利点を有する。強化されたセキュリティは、長期共有鍵を破ることのできる攻撃者に対する障壁をセットアップし、破られた鍵を悪用するためにいわゆる中間者（man-in-the-middle）攻撃を始めることを攻撃者に強いる。

【0018】

派生は、チャレンジと同一であってもよい。また、派生は、チャレンジのハッシュであってもよい。

【0019】

チャレンジのハッシュである派生が使用される場合、チャレンジのサイズは縮小され、標準化されたチャレンジサイズにも適応可能である。アイデンティティモジュールへの純粋なチャレンジの提供は、通信デバイスにおける処理を低減するという利点を有する。

【0020】

第１の態様の第１の変形例では、通信デバイスは、通信デバイスとネットワークデバイスとの間の通信のためのセッション鍵を生成するように構成され、セッション鍵は、第１及び第２のＰＦＳパラメータを生成するために使用される値に少なくとも基づく。

【0021】

第２の態様の対応する変形例では、上記方法は、通信デバイスとネットワークデバイスとの間の通信のためのセッション鍵を生成することを含み、セッション鍵は、第１及び第２のＰＦＳパラメータを生成するために使用される値に少なくとも基づく。

【0022】

この変形例は、潜在的な将来の共有鍵の侵害に対して強化された通信セキュリティを有するセッションを提供するという利点を有する。

【0023】

第１及び第２の態様のより具体的な実施形態では、セッション鍵は、第１のＰＦＳパラメータと、第２のＰＦＳパラメータの指数とに基づく。

【0024】

第１の検証コードは、少なくとも第１のＰＦＳパラメータに基づくメッセージ認証コードを含み得る。少なくとも第２のＰＦＳパラメータに基づくことは、一実施形態では、それが少なくとも第１のＰＦＳパラメータのハッシュに基づいてもよく、ハッシュが暗号ハッシュであってもよいことを意味する。さらに、チャレンジは、第１のＰＦＳパラメータに基づいてもよい。それは、例えば、第１のＰＦＳパラメータ又は第１のＰＦＳパラメータのハッシュであってもよい。このハッシュもまた暗号ハッシュであることが可能である。チャレンジが第１のＰＦＳパラメータに基づくことを通じて、暗号化及び帯域幅使用の経済性が提供される。この経済性は、ハッシュの提供によってさらに強化され、それにより第１のＰＦＳパラメータのサイズを様々な標準化されたフォーマットに適合させることが可能とされる。

【0025】

第１及び第２のＰＦＳパラメータは、より具体的には、ディフィーヘルマンパラメータであってもよい。

【0026】

第１の態様の第３の変形例では、通信デバイスは、ネットワークデバイスから、認証要求メッセージ内で、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードを受信するように構成され、このケースにおいて、認証要求メッセージは、チャレンジ検証コードをも含む。さらに、通信デバイスは、少なくとも１つの結果パラメータを受信する際に、チャレンジに対する応答として応答パラメータを受信するように構成される。最後に、通信デバイスは、第２のＰＦＳパラメータを生成し及び送信するように構成されているとき、第２のＰＦＳパラメータを第２の検証コードと共に生成し、これらを応答パラメータをも含む認証応答メッセージ内で送信するように構成される。

【0027】

第２の態様の対応する変形例では、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードが認証要求メッセージ内で受信され、認証要求メッセージはチャレンジ検証コードをも含む。少なくとも１つの結果パラメータは、チャレンジに対する応答として受信される応答パラメータをも含む。さらに、第２のＰＦＳパラメータを生成し及び送信することは、第２のＰＦＳパラメータを第２の検証コードと共に生成し、これらを応答パラメータをも含む認証応答メッセージ内で送信することを含む。

【0028】

この変形例は、第１及び第２のＰＦＳパラメータ並びに第１及び第２の検証コードを既に存在するメッセージ内で移送できるという利点を有する。それにより、追加的なメッセージが回避される。これは、限定されたリソースであり得る通信デバイス内のエネルギーを節約し得る。

【0029】

第２の検証コードは、少なくとも第２のＰＦＳパラメータに基づくメッセージ認証コードとして生成されてもよい。少なくとも第２のＰＦＳパラメータに基づくことは、一実施形態では、それが少なくとも第２のＰＦＳパラメータのハッシュに基づいてもよく、ハッシュが暗号ハッシュであってもよいことを意味する。

【0030】

ハッシュ／メッセージ認証コードはさらに、ＨＭＡＣ／ＳＨＡ−２５６に基づいてもよい。

【0031】

第１及び第２の態様の第４の変形例では、認証要求メッセージは、認証要求メッセージの対応する別個の情報エレメント内に第１の検証コードを含む。

【0032】

このケースにおいて、通信デバイスは、第１のＰＦＳパラメータの真正性を判定するときに、第１の検証コードを使用するように構成される。

【0033】

このケースにおいて、この方法で行われた第１のＰＦＳパラメータの真正性の判定は、第１の検証コードを使用して行われる。

【0034】

第１及び第２の態様の第５の変形例では、第１の検証コードがチャレンジ検証コードの少なくとも一部として提供される。

【0035】

このケースにおいて、通信デバイスは、アイデンティティモジュールが少なくとも１つの結果パラメータを提供することに基づいて、第１のＰＦＳパラメータの真正性を判定するように構成される。

【0036】

このケースにおいて、上記方法でなされる第１のＰＦＳパラメータの真正性の判定は、アイデンティティモジュールが少なくとも１つの結果パラメータを提供することに基づいて行われる。

【0037】

この変形例は、認証要求メッセージにおいて使用される暗号化におけるさらなる経済性を提供する。

【0038】

第１の態様の第６の変形例では、通信デバイスは、少なくとも１つの結果パラメータのうちの少なくとも１つに基づいて第２の検証コードを生成し、認証応答メッセージの応答パラメータに割り当てられた情報エレメント内で第２の検証コードを送信するように構成される。

【0039】

第２の態様の対応する変形例では、上記方法は、第２の検証コードを応答パラメータに基づかせることを含む。このケースにおいて、認証応答を送信することは、応答パラメータに割り当てられた認証応答メッセージの情報エレメント内で第２の検証コードを送信することをも含む。

【0040】

この変形例は、認証応答メッセージ及びその処理に使用される帯域幅及び暗号化におけるさらなる経済性を提供する。

【0041】

通信デバイスは、ユーザ機器であってもよく、また、プロセッサが動作するコンピュータ命令が記憶されるモバイル機器を含んでもよい。さらに、通信デバイスは、アイデンティティモジュールを含むことが可能であり、アイデンティティモジュールは、鍵及び暗号処理手段を含む。

【0042】

別の目的は、長期共有鍵の使用に関して通信ネットワーク内の第１のネットワークデバイスの強化された通信セキュリティを提供することである。

【0043】

上記目的は、第５の態様によれば、第１の通信ネットワークの第１のネットワークデバイスによって達成される。上記第１のネットワークデバイスは、チャレンジを取得し、第１のＰＦＳパラメータを取得し、第１のＰＦＳパラメータについての第１の検証コードを取得し、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードを通信デバイスへ送信し、通信デバイスから第２のＰＦＳパラメータ、第２の検証コード及び応答パラメータを受信し、応答パラメータの真正性を判定し、第２の検証コードに基づいて第２のＰＦＳパラメータを検証するように構成される。

【0044】

上記目的は、第６の態様によれば、通信ネットワークの第１のネットワークデバイスのための方法によって達成される。上記方法は、第１のネットワークデバイスによって実行され、チャレンジを取得することと、第１のＰＦＳパラメータを取得することと、第１のＰＦＳパラメータについての第１の検証コードを取得することと、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードを通信デバイスへ送信することと、通信デバイスから第２のＰＦＳパラメータ、第２の検証コード及び応答パラメータを受信することと、応答パラメータの真正性を判定することと、第２の検証コードに基づいて第２のＰＦＳパラメータを検証することとを含む。

【0045】

上記目的は、第７の態様によれば、通信ネットワークの第１のネットワークデバイスのためのコンピュータプログラムによって達成される。上記コンピュータプログラムは、第１のネットワークデバイスにおいて実行されると、第１のネットワークデバイスに、チャレンジを取得させ、第１のＰＦＳパラメータを取得させ、第１のＰＦＳパラメータについての第１の検証コードを取得させ、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードを通信デバイスへ送信させ、通信デバイスから第２のＰＦＳパラメータ、第２の検証コード及び応答パラメータを受信させ、応答パラメータの真正性を判定させ、第２の検証コードに基づいて第２のＰＦＳパラメータを検証させるコンピュータプログラムコードを含む。

【0046】

上記目的は、第８の態様によれば、通信ネットワークの第１のネットワークデバイスのためのコンピュータプログラムプロダクトによって達成される。上記コンピュータプログラムプロダクトは、第７の態様に係るコンピュータプログラムコードを有するデータ記憶媒体を含む。

【0047】

第５、第６、第７及び第８の態様に係る本発明は、第１のネットワークデバイスと通信デバイスとの間の通信のセキュリティを強化する。強化されたセキュリティは、いわゆる中間者攻撃に対する障壁をセットアップする。

【0048】

第５の態様の第１の変形例では、第１のネットワークデバイスは、さらに、通信デバイスと第１のネットワークデバイスとの間の通信のためのセッション鍵を計算するように構成される。セッション鍵は、少なくとも第１及び第２のＰＦＳパラメータを生成するために使用される値に基づく。

【0049】

第６の態様の対応する変形例では、上記方法は、さらに、通信デバイスユーザ機器と第１のネットワークデバイスとの間の通信のためのセッション鍵を計算することを含み、セッション鍵は、第１及び第２のＰＦＳパラメータを生成するために使用される値に少なくとも基づく。

【0050】

第５及び第６の態様のより具体的な実施形態では、セッション鍵は、第２のＰＦＳパラメータと第１のＰＦＳパラメータの指数とに基づく。

【0051】

第５の態様の第２の変形例では、第１のネットワークデバイスは、チャレンジを取得するときにチャレンジ検証コードを取得し、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードをチャレンジ検証コードと共に認証要求メッセージ内で送信し、認証応答メッセージ内で第２のＰＦＳパラメータ、第２の検証コード及び応答パラメータを受信するように構成される。

【0052】

第６の態様の対応する変形例では、チャレンジを取得することは、チャレンジ検証コードを取得することを含み、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードを送信することは、これらをチャレンジ検証コードと共に認証要求メッセージ内で送信することを含み、第２のＰＦＳパラメータ、第２の検証コード及び応答パラメータを受信することは、これらを認証応答メッセージ内で受信することを含む。

【0053】

これには、既存のメッセージを再利用する利点がある。これは、新しいメッセージを追加することなく、既存の認証及び鍵合意プロトコルの既存のメッセージ構造が使用され得ることを意味する。これにより、一般的な環境レベルでエネルギーを節約することができる。なぜなら、追加的なメッセージを送信することは、無線ネットワーク内の限られたリソースであり得るエネルギーを使用するからである。さらに、ネットワーク通信は典型的には標準化をもされており、既に存在するメッセージに新しい情報エレメントを追加することに比して、新しいメッセージの導入に関し合意をなすことはしばしばはるかに困難である。

【0054】

第５の態様の第３の変形例では、第２のネットワークデバイスは、第１の検証コードを取得するとき、第１のＰＦＳパラメータを使用して第１の検証コードを生成するように構成され、認証要求メッセージを送信するとき、認証要求メッセージの対応する別個の情報エレメント内で第１の認証コードを送信するように構成される。

【0055】

第６の態様の対応する変形例では、第１の検証コードを取得することは、第１のＰＦＳパラメータを使用して第１の検証コードを生成することを含み、認証要求メッセージを送信することは、対応する別個の情報エレメント内で第１の検証コードを送信することを含む。

【0056】

第５の態様の第４の変形例では、第１のネットワークデバイスは、第１のＰＦＳパラメータを取得するとき、さらに、第１のＰＦＳパラメータを生成するために使用される値を受信し、チャレンジ検証コードの少なくとも一部として第１の検証コードを取得し、認証要求メッセージ内でチャレンジ検証コードの少なくとも一部として第１の検証コードを送信するように構成される。

【0057】

第６の態様の対応する変形例では、上記方法は、さらに、第１のＰＦＳパラメータを生成するための値を受信することと、チャレンジ検証コードの少なくとも一部として第１の検証コードを取得することと、認証要求メッセージ内でチャレンジ検証コードの少なくとも一部として第１の検証コードを送信することとを含む。

【0058】

第５の態様の第５の変形例では、第１のネットワークデバイスは、期待されるチャレンジ結果をも取得し、期待されるチャレンジ結果との比較を通じて応答パラメータの真正性を判定するように構成される。

【0059】

第６の態様の対応する変形例では、上記方法は、さらに、チャレンジと共に期待されるチャレンジ結果を取得することと、期待されるチャレンジ結果との比較を通じて応答パラメータの真正性を判定することとを含む。

【0060】

第５及び第６の態様の第６の変形例では、応答パラメータは、第２の認証コードが応答パラメータに基づくことを通じて認証応答メッセージに含められる。

【0061】

このケースにおいて、第１のネットワークデバイスは、応答パラメータに割り当てられた認証応答メッセージの情報エレメント内で第２の検証コードを受信し、第２の検証コードを使用して、同時に、応答パラメータの真正性を判定し及び第２のＰＦＳパラメータを検証するように構成される。

【0062】

このケースにおいて、上記方法で実行される認証応答メッセージの受信は、応答パラメータに割り当てられた認証応答メッセージの情報エレメント内で第２の検証コードを受信することを含み、応答パラメータの真正性を判定すること、及び第２のＰＦＳパラメータを検証することは、第２の検証コードを使用して同時に実行される。

【0063】

さらに別の目的は、長期共有鍵の使用に関してネットワークデバイスの通信セキュリティを強化するためのシステムを提供することである。

【0064】

上記目的は、第９の態様によれば、第１の通信ネットワーク内の第１のネットワークデバイスと、第２の通信ネットワーク内の第２のネットワークデバイスとを含むシステムによって達成される。第２のネットワークデバイスは、第１のネットワークデバイスへチャレンジを送信するように構成される。

【0065】

一方、第１のネットワークデバイスは、チャレンジを受信し、第１のＰＦＳパラメータを生成し、第１のＰＦＳパラメータについての第１の検証コードを取得し、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードを通信デバイスへ送信し、通信デバイスから第２のＰＦＳパラメータ、第２の検証コード及び応答パラメータを受信し、応答パラメータの真正性を判定し、第２の検証コードに基づいて第２のＰＦＳパラメータを検証するように構成される。

【0066】

第９の態様の第１の変形例では、第２のネットワークデバイスは、第１のＰＦＳパラメータを取得するための値を、少なくとも値ｘに基づいてそれを生成することを通じて提供し、並びに、第１のＰＦＳパラメータを使用してチャレンジ検証コードを生成し、及びベース値を第１のネットワークデバイスへ送信する、ように構成される。第１のネットワークデバイスは、転じて、第１の検証コードをチャレンジ検証コードとして通信デバイスへ送信するように構成される。

【0067】

第９の態様に係る本発明は、第１のネットワークデバイスと通信デバイスとの間の通信のセキュリティを強化する利点も有する。強化されたセキュリティは、長期共有鍵を破ることのできる攻撃者に対する障壁をセットアップし、破られた鍵を悪用するためにいわゆる中間者（man-in-the-middle）攻撃を始めることを攻撃者に強いる。

【0068】

さらに、本発明の第１０の態様は、第２の通信ネットワークのための第２のネットワークデバイスに関し、第２のネットワークデバイスは、第１の通信ネットワークの第１のネットワークデバイスから、通信デバイスのアイデンティティモジュールに関係する認証データの要求を受信し、第１のＰＦＳパラメータを生成し、少なくとも第１のＰＦＳパラメータと、第２のネットワークデバイスとアイデンティティモジュールとの間で共有される鍵とに基づいて第１の検証コードを生成し、上記要求への応答として、少なくとも第１の検証コードと、第１のＰＦＳパラメータの導出元となり得る値とを第１のネットワークデバイスへ送信するように動作可能である。

【0069】

第１のＰＦＳパラメータの導出元となり得る値は、第２のネットワークデバイスの一実施形態では、第１のＰＦＳパラメータを含んでもよい。

【0070】

第２のネットワークデバイスの一実施形態では、第１のＰＦＳパラメータは、ディフィーヘルマンパラメータを含み、第１のＰＦＳパラメータの導出元となり得る値は、ディフィーヘルマンパラメータの指数を含む。

【0071】

強調すべきこととして、「含む／含んでいる（comprises/comprising）」という用語は、本明細書で使用される際、述べられた特徴、整数、ステップ、又は構成要素の存在を特定するが、１つ以上の他の特徴、整数、ステップ、構成要素又はその集合の存在又は追加を排除するものではない。「パラメータ」という語は、パラメータの値を包含するものとして、たとえば、パラメータの計算は、そのパラメータの値の計算を含み、１つ以上のパラメータに基づく結果又は応答の計算又は導出は、１つ以上のパラメータの１つ以上の値に基づく結果又は応答の計算を含むものちして解釈されるべきである。同様に、パラメータを受信すること及びパラメータを送信／転送することは、そのパラメータの値を受信すること及び送信することを含む。

【図面の簡単な説明】

【0072】

これ以降、次の添付図面に関連して本発明をより詳細に説明する。

【0073】

【図1】通信デバイスと通信ネットワークとの間で実行される既知の認証方式を概略的に示す図である。

【図2】第１及び第２の通信ネットワーク並びに第１の通信ネットワークと通信する通信デバイスを概略的に示す図である。

【図3】通信デバイスと第１の通信ネットワークとの間のディフィーヘルマンプロトコルの使用を概略的に示す図である。

【図4】アイデンティティモジュール及びモバイル機器を含むユーザ機器のブロック概略図である。

【図5】モバイル機器のブロック概略図である。

【図6】第１及び第２の通信ネットワークの双方におけるノードとして機能するデバイスに適用可能な、ネットワークデバイスの概略を示すブロック概略図である。

【図7】第１の実施形態に係る、通信デバイスの通信セキュリティを強化する方法であって、通信デバイスで実行される当該方法におけるいくつかの方法ステップのフローチャートである。

【図8】第１の実施形態に係る、第１の通信ネットワーク内の第１のネットワークデバイスのための方法であって、第１のネットワークデバイスで実行される当該方法におけるいくつかの方法ステップのフローチャートである。

【図9】第２の実施形態に係る、第２の通信ネットワーク内の通信デバイス、第１のネットワークデバイス、及び第２のネットワークデバイス間で交換される信号を伴うシグナリングチャートである。

【図10】チャレンジ検証コードをより詳細に示す図である。

【図11】第３の実施形態に係る、通信デバイス、第１のネットワークデバイス、及び第２のネットワークデバイスの間で交換される信号を伴うシグナリングチャートである。

【図12】通信デバイスの機能性を実装するためのコンピュータプログラムコードを有するデータ記憶媒体を含むコンピュータプログラムプロダクトを示す図である。

【図13】ネットワークデバイスの機能性を実装するためのコンピュータプログラムコードを有するデータ記憶媒体を含むコンピュータプログラムプロダクトを示す図である。

【図14】通信デバイスを実現する別の方法を示す図である。

【図15】第１のネットワークデバイスを実現する別の方法を示す図である。

【図16】第２のネットワークデバイスを実現するさらなる方法を示す図である。

【発明を実施するための形態】

【0074】

以下の説明では、本発明の完全な理解を提供する目的で、限定ではなく説明のために、特定のアーキテクチャ、インターフェース及び技術などの具体的な詳細を説明する。しかし、これらの具体的な詳細から逸脱する他の実施形態で本発明が実践されてもよいことは、当業者には明らかであろう。他の例では、不必要な詳細で本発明の説明を不明瞭にしないように、周知のデバイス、回路、及び方法の詳細な説明は省略されている。

【0075】

本発明は、予め共有される鍵を通信セキュリティの基礎として使用する通信ネットワークにおける通信セキュリティの改善に関する。通信ネットワークは、ここでは、ＧＳＭ（Global System for Mobile communication）のような第２世代（２Ｇ）モバイル通信ネットワーク、ＵＭＴＳ（Universal Mobile Telecommunications System）のような第３世代（３Ｇ）ネットワーク、ＬＴＥ（Long-Term Evolution）のような第４世代（４Ｇ）ネットワーク、又は現在開発中の３ＧＰＰの第５世代（５Ｇ）など任意の将来の進化したシステムなどのモバイル通信ネットワークであってよい。これらは、本発明を実装することができるネットワークのほんの一例に過ぎない。使用され得る他のタイプのネットワークは、例えばワイヤレスローカルエリアネットワーク（ＷＬＡＮ）である。セルラーフォンと呼ばれることもある、ユーザ機器（ＵＥ）、移動局（ＭＳ）などの通信デバイスは、これらの通信ネットワークを使用して通信し得る。さらに、ここでの通信デバイスは、アイデンティティモジュールに接続されており、アイデンティティモジュールは、加入者アイデンティティモジュール（ＳＩＭ）及び／若しくはユニバーサル加入者アイデンティティモジュール（ＵＳＩＭ）、ＩＰマルチメディアサブシステムＳＩＭ（ＩＳＩＭ）、組み込みＳＩＭ（ｅＳＩＭ）モジュール、ソフトウェアモジュール、又はグローバルプラットフォームトラステッドエグゼキューションモジュールなどを保持する、ユニバーサル集積回路カード（ＵＩＣＣ）などのスマートカードであってもよい。従って、アイデンティティモジュールを、信頼できる実行環境で動作するソフトウェア、又は汎用プロセッサ上で動作するソフトウェアで実装してもよく、但し後者は好適ではない。後に、ＵＳＩＭとの用語が説明の一例として使用されるが、当業者は、いかなるタイプのアイデンティティモジュールも同じ目的に供されることを認識するであろう。理解すべきこととして、アイデンティティモジュールは、通信デバイスの一部であってもよい。また、通信デバイスが使用される場合に、アイデンティティモジュールは、通信デバイスへ接続される別個のエンティティであってもよい。

【0076】

通信セキュリティのためのベースとして、例えば、認証及び鍵合意のために、鍵が使用される。鍵は、有利には、上述のように、予め共有され、アイデンティティモジュールに記憶され得る。

【0077】

以下では、ＵＥの形式の通信デバイスの例についてのみ説明する。しかし、通信デバイスはＵＥであることに限定されないことを理解されたい。通信デバイスは、データ及び／又は信号をネットワークノードとの間でワイヤレスに送受信することができる、任意のタイプのワイヤレスエンドポイント、移動局、携帯電話、ワイヤレスローカルループ電話、スマートフォン、ユーザ機器、デスクトップコンピュータ、ＰＤＡ、セルフォン、タブレット、ラップトップ、ＶｏＩＰフォン又はハンドセットとすることができる。通信デバイスは、例えば、何らかの形式の電子機器（例えば、センサ又はデジタルカメラ）、車両、家庭用ゲートウェイ、家庭／住宅用ＷｉＦｉ／４Ｇアクセスポイント、冷蔵庫のような家電機器、サーモスタット、盗難警報機、掃除機、芝刈り機ロボットなどのための３Ｇ又は４Ｇ接続を提供する通信モデムであってもよい。固定的な通信ネットワークに接続された据え置き型の端末であってもよい。

【0078】

前述のように、及び図１に示すように、認証及び鍵合意（ＡＫＡ）は、いくつかの通信ネットワークで使用される既知の鍵合意の体系である。

【0079】

図１において見られるように、ＶＬＲ／ＳＧＳＮ（Visitor Location Register/Serving Gateway Support Node）は、訪問中のユーザ機器（ＵＥ）に関して、ＨＥ／ＨＬＲ（Home Environment/Home Location Register）へ１０で認証データ要求を送信するものとして示されている。ＨＥ／ＨＬＲは、１２で、１組の認証ベクトル（ＡＶ（ｉ．．ｎ））を生成し、１４で、ベクトル（ＡＶｉ．．ｎ）を認証データ応答メッセージ内でＶＬＲ／ＳＧＳＮへ送信し、ＶＬＲ／ＳＧＳＮは、転じて、１６で、それら認証ベクトルを記憶する。

【0080】

ＶＬＲ／ＳＧＳＮは、１８で、認証ベクトルを選択し、このベクトルの内容に基づいて、２０で、ランダム値ＲＡＮＤ（ｉ）及び認証トークンＡＵＴＮ（ｉ）が割り当てられたパラメータＲＡＮＤを使用してチャレンジを含むユーザ認証要求メッセージＡＲＱを送信し、ＡＵＴＮ（ｉ）は、以下に詳細に説明するチャレンジ検証コードをも含み、ｉは、その値がＡＶｉに関連付けられていることを示す。ＵＥでは、次いで検証ステップ２２においてＡＵＮＴ（ｉ）が検証され、結果ＲＥＳ（ｉ）が計算される。次いで、ＵＥは、２０で、結果ＲＥＳ（ｉ）を含むユーザ認証応答メッセージ（ＡＲＥ）を送信する。認証ベクトルは、期待される結果ＸＲＥＳ（ｉ）を含み、ＶＬＲ／ＳＧＳＮは、次いで、２６で、受信された結果ＲＥＳ（ｉ）を期待される結果ＸＲＥＳ（ｉ）と比較し、比較が成功した場合、すなわち、それらが等しいと判明した場合、ＶＬＲ／ＳＧＳＮは、３０で、暗号化鍵ＣＫ（ｉ）及び完全性保護鍵ＩＫ（ｉ）を選択する。また、ＵＥは、２８で、同じ鍵ＣＫ（ｉ）及びＩＫ（ｉ）を計算する。これらは次いで、セッション鍵を取得するために使用される。いくつかのシステム（例えば、ＬＴＥ）では、鍵ＣＫ（ｉ）及びＩＫ（ｉ）がセッション鍵Ｋａｓｍｅを取得するために使用される。

【0081】

図１に示し、上記で説明したタイプの認証では、有利に予め共有された秘密鍵Ｋがユーザ機器とネットワークの双方で使用される。

【0082】

ＵＭＴＳ／ＬＴＥ ＡＫＡは、セキュリティ及びロバスト性の実証済みの実績により、将来の世代のモバイルネットワーク（例えば、５Ｇ）の基礎としても使用されることが予測される。後で、特に明記しない限り、「ＡＫＡ」は、ＵＭＴＳ ＡＫＡ、ＬＴＥ ＡＫＡ、又はこれらに基づくプロトコル、例えば「５Ｇ」ネットワークの将来の拡張などを示すために使用される。

【0083】

上記でも述べたように、図１に示すＡＫＡプロトコルは、ＵＥ、ＶＬＲ／ＳＧＳＮ（Visitor Location Register/Serving Gateway Support Node）、ＨＥ／ＨＬＲ（Home Environment/Home Location Register）の間で通信が行われる３ＧＰＰ ＴＳ３３．１０２に整合する。４Ｇ／ＬＴＥでは、モビリティ管理エンティティ（ＭＭＥ）がＶＬＲ／ＳＧＳＮに取って代わり、ＨＥ／ＨＬＲはホーム加入者サーバ（ＨＳＳ）に対応する。なお、この図では、端末／ＵＥ／通信デバイスをＭＳと呼ぶ。本開示では、ＭＳ及びＵＥは同じエンティティである。

【0084】

ＡＵＴＮ（ｉ）（認証トークン）は、様々なフィールドからなるパラメータである：ＡＭＦ（認証管理フィールド）、ＭＡＣ及びシーケンス番号標識（ＳＱＮ、恐らくは匿名鍵ＡＫによって暗号化／修正される）。ＭＡＣ（ｉ）は、ＵＳＩＭにより実装された暗号機能を通じて第三者によって偽造されることからチャレンジＲＡＮＤ（ｉ）（ランダム数）、並びにＳＱＮ及びＡＭＦを保護するメッセージ認証コードである。鍵ＣＫ（ｉ）及びＩＫ（ｉ）は、３Ｇでは暗号化／完全性保護のために直接的に使用され、４Ｇ／ＬＴＥでは、それら目的のために、ＣＫ（ｉ）及びＩＫ（ｉ）から（具体的には、ＣＫ（ｉ）及びＩＫ（ｉ）によって形成される鍵Ｋａｓｍｅから）暗号化／完全性鍵を導出することによって間接的に使用される。

【0085】

ＵＥ及びＨＥの双方で提供されるこれらの暗号機能では、共有鍵Ｋがこのように使用される。

【0086】

Ｋは、ＵＳＩＭ及びＨＳＳ／ＡｕＣによってこのように共有される鍵（通常１２８ビット）であり、ＡｕＣは、認証センターの略である。その共有鍵は、他方の当事者には秘密にしておかなければならない。

【0087】

暗号化の及び他の形式の計算の説明の残りの部分で使用される簡略化した表記法として、明示的に言及されたもの以外のパラメータが、鍵導出関数（ＫＤＦ）、メッセージ認証コード（ＭＡＣ）及びここで説明されるすべての例における他のすべての関数などといった関数へ入力されてもよい。それらパラメータは、明示的に記載されたものとは異なる順序で配置されてもよい。それらパラメータは、関数への入力の前に変換されてもよい。例えば、いくつかの非負の整数ｎについて、パラメータのセットＰ１，Ｐ２，…，Ｐｎを第２の関数ｆをまず実行することによって変換することができ、その結果、すなわちｆ（Ｐ１，Ｐ２，…，Ｐｎ）が関数に入力される。

【0088】

パラメータＰ_１が「ｏｕｔｐｕｔ＿ｋｅｙ」と呼ばれる鍵を計算するためにＫＤＦへ入力される前にまず変換される場合の鍵導出の一例は、ｏｕｔｐｕｔ＿ｋｅｙ＝ＫＤＦ（ｆ（Ｐ_１），他の何らかのパラメータ）という形式の導出であり得る。ここで、ｆは、何らかの任意の関数又は一連の関数である。入力「何らかの他のパラメータ」は、例えばあるコンテキストに鍵をバインドするために使用される、０個、１個又はそれ以上の他のパラメータであり得る。時として、“…”という表記が「何らかの他のパラメータ」の同義語として使用され得る。パラメータは、別々のパラメータとして入力されてもよく、又は一緒に連結され、次いでＫＤＦへの単一の入力として入力されてもよい。従って、当業者であれば、追加のパラメータを使用してもよいこと、パラメータを変換し又は再編成するなどしてもよいこと、及び、それらの変形が存在するとしても本アイデアの要部は同じままであることを理解するであろう。

【0089】

上で言及したように、ＡＫＡのセキュリティは、鍵Ｋが秘匿されていることに依存する。近日、ＵＳＩＭカードの製造業者のセキュリティが破られ、１組のＫ鍵が「漏洩し」（又は悪意のある者へ渡り）、従って、これらの鍵に関連付けられた加入者が、偽装、接続ハイジャック、及び盗聴などの危険にさらされる（なぜなら、ＣＫ（ｉ）及び／又はＩＫ（ｉ）から導出される暗号化鍵もまたそのようにして潜在的に危険にさらされる）ことがメディアで報告された。https://firstlook.org/theintercept/2015/02/19/great-sim-heist/の記事に、前述のセキュリティへの影響をもたらすＡＫＡプロトコルの潜在的な問題は、ＡＫＡがいわゆるＰＦＳ（Perfect forward Secrecy）を欠いていることにあることが述べられている。ＰＦＳは、セッション鍵を確立するために使用される長期鍵が露見していても、過去のセッション鍵もまた露見していることは依然として示唆されないことを意味する。すなわち、長期鍵が破られている状況で、セッション鍵は将来において安全である。ＡＫＡは、実際には、有利ではあるがより脆弱な特性を有し、それはしばしば鍵分離（key separation）として言及される：セッション鍵（ＣＫ（ｉ）、ＩＫ（ｉ）など）が露見するとしても、過去／将来のＣＫ（ｊ）、ＩＫ（ｊ）（及びさらに導出される鍵）は露見しない。しかしながら、長期鍵Ｋが露見している場合、そのようなすべてのセキュリティ上の特性にはあまり価値が無い。

【0090】

本発明の複数の態様は、ＰＦＳを追加することを通じて上述の認証機能について改善をなすことに関係する。従って、ユーザ機器とネットワークの双方の通信セキュリティを強化することに関係する。

【0091】

但し、これがどのようになされるかを詳細に説明する前に、以下に環境のいくつかのさらなる詳細が与えられるであろう。

【0092】

図２は、通信デバイス４０の１つの例示的な通信環境を概略的に示しており、図２の通信デバイス４０は、通信セキュリティが強化される対象のユーザ機器（ＵＥ）の一形式である。この例では、第１及び第２の通信ネットワークが存在し、このケースでは共にＬＴＥネットワークのようなモバイル通信ネットワークである。ユーザ機器ＵＥは、このケースでは、第１の通信ネットワーク３６の基地局ＢＳ４２と無線インターフェースを介して無線で接続されており、その通信ネットワークは第１のワイヤレスネットワークＷＮ_１である。そして、基地局４２は、第１のワイヤレスネットワークＷＮ_１の第１のネットワークデバイス４４へ接続され、第１のネットワークデバイス４４は、ネットワークノードであると見なすこともできる。この例では、第１のネットワークデバイスは、ＭＭＥである。そして、ＭＭＥ４４は、第２の通信ネットワーク３８内の第２のネットワークデバイス４６へ接続され、第２の通信ネットワーク４６は、第２のワイヤレスネットワークＷＮ_２である。第２のネットワークデバイス４６は、このケースでは、ＨＳＳであり、ネットワークノードであると見なすことができる。第１のワイヤレスネットワークＷＮ_１は、訪問先ネットワーク、すなわちＵＥが訪問するネットワークであってもよく、第２のワイヤレスネットワークＷＮ_２は、ＵＥのホームネットワーク、すなわちＵＥに関連するサブスクリプションをホスティングするネットワークであってもよい。多くのネットワークにおいて、ノードＢ又はｅＮｏｄｅＢと示され得る基地局４２は、第１のワイヤレスネットワークＷＮ_１のアクセスネットワークＡＮと呼ばれる部分で提供され、コアネットワークＣＮと呼ばれる部分にＭＭＥ４４が設けられる。

【0093】

従って、第１の通信ネットワーク３６は、この例では、ＵＥによって訪問されるネットワークであり、第２の通信ネットワーク３８は、ＵＥのホームネットワークである。

【0094】

異なる実施形態において、各ワイヤレスネットワークは、任意の数の有線又はワイヤレスネットワーク、ネットワークノード、基地局、コントローラ、ワイヤレスデバイス、中継局、並びに／又は、有線接続若しくはワイヤレス接続を介してデータ及び／若しくは信号の通信を促進し若しくは当該通信に参加し得る任意の他のコンポーネントを含んでよい。

【0095】

各ワイヤレスネットワークは、１つ以上のＩＰネットワーク、公衆交換電話網（ＰＳＴＮ）、パケットデータネットワーク、光ネットワーク、広域ネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、有線ネットワーク、ワイヤレスネットワーク、メトロポリタンエリアネットワーク、及びデバイス間の通信を可能にする他のネットワークを含んでもよい。

【0096】

図１において見られるように、ＵＥと第１のネットワークデバイスとの間で通信が行われる。しかしながら、同じく見てわかるように、認証情報（ＡＶ）は、本質的に、ＵＥのホームネットワーク内の第２のネットワークデバイスによって提供されていた。

【0097】

前述のように、本発明は、図２のシステムのようなシステムにＰＦＳを導入することを対象としている。

【0098】

基礎として使用する１つの適切な方式は、ディフィーヘルマンプロトコルで定義された方式である。ＵＥと第１のワイヤレスネットワークＷＮ_１との間に実装されるこの方式は、図３に概略的に示されている。

【0099】

図３において見られるように、第１のワイヤレスネットワークＷＮ_１（及び通常は第１のネットワークデバイス）は、ベース値ｇのｘ（ランダム数）乗として生成されたパラメータを送信し、ＵＥは、同じベース値ｇのｙ（別のランダム数）乗として生成されたパラメータで応答する（「ランダム」という用語は、統計的にランダムであること及び擬似ランダムであることの双方を含むものと理解されるべきである）。それらパラメータは、例えば共有鍵（図示せず）を使用して認証されるものとする。一度認証されると、ＵＥ及び第１のネットワークデバイスは、共通のセッション鍵を使用することができ、そのセッション鍵はまたそのように共有される。セッション鍵の基底を、Ｋ´＝ｇ＾（ｘｙ）又はＫ´＝ｇ＾（ｙｘ）（これらは同じ値Ｋ´を導くことになる）として取得することができる。上記鍵は、より具体的には、ｇのｘ乗のｙ乗、又はｇのｙ乗のｘ乗として取得されてよく、すなわち（ｇ＾ｘ）＾ｙ 又は （ｇ＾ｙ）＾ｘである。

【0100】

理解され得るように、セキュアなセッション鍵である上記セッション鍵Ｋ´は、値ｘ及びｙに基づいて生成され得る。当業者であれば、楕円曲線、及び離散対数問題が困難である他の巡回群もまた使用されてよいことを認識するであろう。但し、楕円曲線のケースでは加法表記ｘ＊ｇがより適切であるものの、簡明さのために、乗法表記ｇ＾ｘを使用している。さらなる詳細については、MenezesらによるHandbook of Applied Cryptography（fifth printing (August 2001), CRC Press）を参照されたい。

【0101】

図４は、ＵＥの１つの実現例を示している。ＵＥは、ユニバーサル加入者アイデンティティモジュール（ＵＳＩＭ）４８を含んでよく、ＵＳＩＭ４８は、例えばＰＦＳ−ＡＫＡ（perfect forward security Authentication and Key Agreement）モジュール５２へ接続されるスマートカードの形式であり、ＰＦＳ−ＡＫＡモジュール５２は、転じて、ワイヤレス通信モジュールであり得る通信モジュール５０へ接続される。ここでは、通信モジュール５０及びＰＦＳ−ＡＫＡモジュール５２は共にモバイル機器４６を形成し、一方でＵＳＩＭはアイデンティティモジュール４８である。よって、併せて、ＵＳＩＭ、ＰＦＳ−ＡＫＡモジュール、及び通信モジュールがユーザ機器を形成する。

【0102】

ＭＥ４６を実現する１つの手法が図５に概略的に示されている。ＭＥ４６は、プロセッサ５４、記憶装置５６、インターフェース５０Ｂ及びアンテナ５０Ａを含む。これらの構成要素は、ワイヤレスネットワークにおいてワイヤレス接続を提供するなど、ＭＥ機能を提供するために共に作動し得る。ＭＥ４６の構成要素は、単一の大きいボックス内に配置された単一のボックスとして示されているが、実際には、ＭＥは、単一の図示された構成要素を構成する複数の異なる物理的な構成要素を含んでもよい（例えば、記憶装置５６は、複数の個別のマイクロチップを含んでもよく、各マイクロチップは、合計記憶容量の一部を表す）。

【0103】

プロセッサ５４は、マイクロプロセッサ、コントローラ、マイクロコントローラ、中央処理装置、デジタル信号プロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、又は任意の他の適切なコンピューティングデバイス、リソース、あるいはハードウェア、ソフトウェア及び／又は単独で、もしくは記憶装置５６、ＭＥ機能など他のＭＥ構成要素との組み合わせで提供するように動作可能なコード化されたロジックの組み合わせ、のうちの１つ以上の組み合わせであり得る。そうした機能性は、ここに開示される特徴又は利点のいずれかを含む、ここで議論される多様なワイヤレス機能を提供することを含み得る。

【0104】

記憶装置５６は、限定ではないものの、永続的な記憶装置、固体メモリ、遠隔的にマウントされるメモリ、磁気メディア、光メディア、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、リムーバブルメディア、又は任意の他の適切なローカル又はリモートのメモリ構成要素を含む、任意の形式の揮発性又は不揮発性のコンピュータ読取可能なメモリであってよい。記憶装置５６は、ＭＥ４６によって利用されるソフトウェア及びコード化されたロジックを含む、任意の適切なデータ、命令、又は情報を記憶し得る。記憶装置５６は、プロセッサ５４によって行われる任意の計算及び／又はインターフェース５０Ｂを介して受信される任意のデータを記憶するために使用され得る。

【0105】

インターフェース５０Ｂは、ＵＥと、基地局４２などのネットワークデバイスとの間のシグナリング及び／又はデータのワイヤレス通信に使用され得る。例えば、インターフェース５０Ｂは、ＵＥがワイヤレス接続を介して基地局４２との間でデータを送受信することを可能にするために必要とされ得る任意のフォーマット、符号化、又は変換を実行し得る。インターフェース５０Ｂは、アンテナ５０ａへ連結され又はアンテナ５０ａの一部であり得る無線送信機及び／又は受信機を含んでもよい。無線機は、ワイヤレス接続を介して基地局４２へ送出されるデジタルデータを受信し得る。無線機は、デジタルデータを、適切なチャネル及び帯域幅パラメータを有する無線信号へ変換し得る。次いで、無線信号は、アンテナ５０ａを介して基地局４２へ送信され得る。

【0106】

アンテナ５０ａは、データ及び／又は信号をワイヤレスに送受信可能な任意のタイプのアンテナであってよい。

【0107】

また、記憶装置５６は、ＭＥの第１のワイヤレスネットワークへの通信に関してＰＦＳをハンドリングするための命令を含んでもよい。

【0108】

記憶装置５６は、より具体的には、プロセッサ５４にＰＦＳ−ＡＫＡモジュール５２を実装させるコンピュータ命令を含み得る。通信モジュール５０は、本質的に、インターフェース５０Ｂとアンテナ５０Ａとの組み合わせを通じて実装され得る。

【0109】

図６は、汎用的なネットワークデバイス５７を示しており、その構造は、第１及び第２のネットワークデバイス４４及び４６の双方に適用可能である。ネットワークデバイス４７は、プロセッサ６０、記憶装置６２及びインターフェース５８を含む。これらの構成要素は、単一の大きいボックス内に配置された単一のボックスとして示されている。しかしながら、実際には、ネットワークデバイスは、単一の図示された構成要素を構成する複数の異なる物理的な構成要素を含んでもよい（例えば、インターフェース５８は、有線接続のための配線を連結するための端子を含んでもよい）。同様に、ネットワークデバイス５７は、各々がそれ自体のそれぞれのプロセッサ、記憶装置、及びインターフェース構成要素を有し得る複数の物理的に別個の構成要素から構成されてもよい。ネットワークデバイス５７が複数の別個の構成要素を含むいくつかのシナリオでは、１つ以上の別個の構成要素を複数のネットワークデバイス間で共有することができる。

【0110】

プロセッサ６０は、マイクロプロセッサ、コントローラ、マイクロコントローラ、中央処理装置、デジタル信号プロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、又は任意の他の適切なコンピューティングデバイス、リソース、あるいはハードウェア、ソフトウェア及び／又は単独で、もしくは記憶装置６２、ネットワークデバイス機能など他のネットワークデバイス構成要素との組み合わせで提供するように動作可能なコード化されたロジックの組み合わせ、のうちの１つ以上の組み合わせであり得る。例えば、プロセッサ６０は、記憶装置６２に記憶された命令を実行し得る。

【0111】

記憶装置６２は、限定ではないものの、永続的な記憶装置、固体メモリ、遠隔的にマウントされるメモリ、磁気メディア、光メディア、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、リムーバブルメディア、又は任意の他の適切なローカル又はリモートのメモリ構成要素を含む、任意の形式の揮発性又は不揮発性のコンピュータ読取可能なメモリを含んでよい。記憶装置６２は、ネットワークデバイス５７によって利用されるソフトウェア及びコード化されたロジックを含む、任意の適切な命令、データ、又は情報を記憶し得る。記憶装置６２は、プロセッサ６０によって行われる任意の計算及び／又はインターフェース５８を介して受信される任意のデータを記憶するために使用され得る。

【0112】

ネットワークデバイス５７は、ネットワークデバイス５７、ネットワークＷＮ_１もしくはＷＮ_２、及び／又はＵＥの間のシグナリング及び／又はデータの有線での通信に使用され得るインターフェース５８をも含む。例えば、インターフェース５８は、ネットワークデバイス５７が有線接続を介してネットワークＷＮ_１もしくはＷＮ_２との間でデータを送受信することを可能にするために必要とされ得る任意のフォーマット、符号化、又は変換を実行し得る。

【0113】

本発明の複数の態様は、ＡＫＡにＰＦＳを追加することに関する。

【0114】

以下の実施形態は、簡略化のために４Ｇ／ＬＴＥの文脈で説明されるが、ＩＭＳ ＡＫＡ（ＩＰマルチメディアサブシステムＡＫＡ）及びＥＡＰ−ＡＫＡ（拡張可能認証プロトコル−ＡＫＡ）にも適用可能であり、実施形態は、現在議論されている５Ｇシステム、又はＡＫＡに基づく任意の他の将来のシステム、又は予め共有される鍵を有するアイデンティティモジュールが使用される他の設定に適用可能であるものとして、現在のところ理解される。

【0115】

上述したように、本発明の態様は、有利にはディフィーヘルマン（ＤＨ）プロトコルに基づいて、通信デバイスと第１のネットワークデバイスとの間の通信においてＰＦＳを提供することに関する。

【0116】

但し、このプロトコルは、必要なパラメータを搬送するために計算の労力と追加の帯域幅とを要する：交換されるＤＨパラメータは、現在のところ標準化されているＡＫＡプロトコルのパラメータ（ＲＡＮＤ、ＲＥＳなど）よりもはるかに大きい。無線インターフェースを介してシグナリングされるビット数を増やすことが可能であったとしても、ＵＥ内の標準化されたＵＳＩＭ−ＭＥインターフェースを維持することが望ましいはずであり、これは、ＤＨが強力なセキュリティを提供する中で、プロトコルパラメータのサイズが上記レベルを下回ることについてのボトルネックを示唆している（ＲＡＮＤは現在のところ１２８ビットであり、ＡＫＡの１２８ビット強度と一致するセキュリティに到達するために、ＤＨの楕円曲線の派生には少なくとも２５６ビットのＤＨパラメータが、素数ｐを法とする標準的な離散対数ＤＨでは約３０００ビットのＤＨパラメータが必要とされる）。そのうえ、ＤＨは、中間者（ＭＩＴＭ）攻撃の影響を受け易く、これは、ＤＨパラメータを認証するための何らかの機構を追加する必要性を示唆する。これを行うための自然なアプローチは、ＡＫＡに別のデータフィールドを追加することであり、さらに多くのシグナリングオーバーヘッドがもたらされるはずである。

【0117】

従って、１つの目的は、長期共有鍵の使用に関して通信デバイスと通信ネットワークとの間の通信のセキュリティレベルを上げることである。追加的なメッセージを送信することを回避することも重要であり得る。従って、新しいメッセージを追加することなく、既存のメッセージ構造が使用されることが望ましい。これは、追加的なメッセージを送信することが、特に通信デバイス内の限られたリソースであり得るエネルギーを使用することから、通信デバイス及び一般的な環境レベルの双方に関する省エネルギーの観点から重要であり得る。さらに、ネットワーク通信は典型的には標準化されており、ＰＦＳを追加するための簡易なアプローチを用いる場合、認証及びＭＩＴＭ保護を提供するために必要となるはずの新たなエレメントを既に存在するメッセージ内に追加することに比して、新しいメッセージの導入に関し同意をなすことはしばしばはるかに困難である。

【0118】

先に進む前に、ＤＨプロトコルによって例示される、ＰＦＳを提供するプロトコルにおける認証についてのいくつかの考察が有益である。ＡＫＡの特定の文脈では、当業者は、この目的のために、ＵＳＩＭにおける計算によって生成される１つ以上のＡＫＡ結果パラメータ、すなわちＲＥＳ、ＣＫ及び／又はＩＫを使用したいという思いに駆られるかもしれない。これは、概してセキュリティにとって危険である。例えば、何らかの関数Ｆ´についてｘ＝Ｆ´（ＣＫ，ＩＫ）及び／又はｙ＝Ｆ´（ＣＫ，ＩＫ）を介したＤＨパラメータｇ＾ｘ及び／又はｇ＾ｙの計算は、ＰＦＳをもたらさない。なぜなら、長期鍵Ｋの知識からこれらのパラメータを計算することができるからである。従って、ＡＫＡパラメータ及びプロトコルデータフィールドの再利用は有益であるが、慎重に用いる必要がある。従って、ｘ及びｙは、ＡＫＡパラメータには非依存であるべきである。

【0119】

一方、ＭＩＴＭに対する保護のために、１つ以上のＡＫＡパラメータを使用し、標準的なＭＡＣを追加することができる。例えば、ＵＥからのＡＫＡ応答は、
ＲＥＳ，ｇ＾ｙ，ＭＡＣ（ＣＫ｜｜ＩＫ｜｜…，ｇ＾ｙ｜｜…）を含むことができるはずである（従って、これはおそらく、ＡＫＡプロトコルの前述のＭＡＣパラメータと混同されるべきではない別のＭＡＣ関数である。また、固定的なＡＫＡパラメータのセットを検討していることから、インデックスｉを表記せず、上記のようにＣＫ（ｉ）の代わりに、例えばＣＫを書いていることにも留意されたい）。なお、概して、ＭＡＣ内でどの鍵を使用すべきか、すなわちＭＡＣ（…，…）への入力における第１のパラメータとして、複数のオプションが存在する。詳細化し過ぎて説明を不明瞭にしないように、従って、例えば、上記のように、ＭＡＣ（ＣＫ｜｜ＩＫ｜｜…，ｇ＾ｙ｜｜…）の代わりにＭＡＣ（ｇ＾ｙ）と書くなど、鍵（及びあまり重要ではない他のパラメータ）はしばしば表記されない。…は、他の変数／パラメータがあり得ることを示し、｜｜は入力をＭＡＣ関数に結合する手法、例えば連結（concatenation）を示す。但し、より一層経済的な方法は、ＵＥからＭＭＥへ送信される際にＲＥＳを搬送する既存の情報エレメント内に上記のＭＡＣを取り入れることであり、たとえば、ＲＥＳ（及びオプションでＣＫ、ＩＫ）を鍵として使用してＲＥＳ´＝ＭＡＣ（ＲＥＳ，ｇ＾ｙ，…）を計算し、そのようにしてＵＥはＲＥＳ´，ｇ＾ｙのみで応答する。ＭＡＣ関数は、ＨＭＡＣに基づいてもよく、ＨＭＡＣは、たとえばＡＥＳに基づく、（３ＧＰＰ ＴＳ ３３．１０２に定義されているような）ネイティブＡＫＡ ｆ−関数又は他の適した関数のうちの１つである。ＲＥＳは、ｇ＾ｙ及び鍵値（ＣＫ／ＩＫ又はＲＥＳ）に基づくＭＡＣとして計算されるので、実際にはｇ＾ｙの真正性についての検証コードであることが明らかである。さらに、ＭＡＣは、鍵としてのＲＥＳにも基づく場合、同時にＲＥＳを検証するために使用することができる。また、ここで理解されるべきこととして、ＭＡＣは、ＲＥＳ´を計算するために使用できる１つの関数の候補に過ぎない。別の例は、一般的な鍵導出関数又は擬似ランダム関数である。

【0120】

通信オーバーヘッドを節約しながらそれでもＰＦＳを提供する目的で、ネットワークからＭＥへ送信されるＤＨ値ｇ＾ｘにも同様の考察が当てはまる。

【0121】

具体的には、ＡｕＣ／ＨＳＳは、いくつかの実施形態では、それに応じてサービングネットワークへ送信される認証ベクトルを生成し、すなわち、ＲＡＮＤ＝ｇ＾ｘなどのパラメータを計算し、ＲＡＮＤに、ｆ−関数などへの入力の前にハッシュを適用する。従って、ｇ＾ｘは、新しい情報エレメントを追加することなく、ＲＡＮＤ ＡＫＡプロトコルフィールドで実質的に搬送される。いくつかの実施形態において、ＨＳＳは、認証ベクトル（ＡＶ）の一部としてＭＭＥへＣＫ、ＩＫ（又はＫａｓｍｅなどそこから導出される鍵）を送信する必要がない。なぜなら、結果として得られる共有鍵は、いずれにしろＡＶ生成時にＨＳＳにとって既知でないｇ＾（ｘｙ）に基づくことになるからである。他の実施形態において、ＡｕＣ／ＨＳＳは、鍵生成に含められるべきＣＫ、ＩＫを含んでもよい。例えば、ＬＴＥでは、鍵は、ＣＫ、ＩＫからのＫａｓｍｅ鍵の導出におけるＰＬＭＮ（Public Land Mobile Network）識別子の包含を通じて、アクセスネットワークに「バインド」される。注記したように、ＨＳＳにとってＡＶが生成される時点でｇ＾（ｘｙ）は既知ではないことから、ＰＬＭＮ ＩＤへのバインディングは、ＣＫ、ＩＫからのいくつかのさらなる鍵の導出にＰＬＭＮ ＩＤを含め、ＡＶにその導出された鍵を含めることによって達成されることができる。ＭＭＥが採用されてもよく、すなわち、ＨＳＳからＡＶ内でＸＲＥＳが与えられる場合、ＭＭＥは、上記の実施形態では、加入者の真正性を検証する前にＸＲＥＳ´＝ＭＡＣ（ＸＲＥＳ，ｇ＾ｙ）を計算することになり、何らかの適切な関数ＦなどについてＫａｓｍｅをＦ（ｇ＾（ｘｙ）｜｜…）として導出し得る。ＭＥが同様にＫａｓｍｅを計算してもよい。

【0122】

次に、第１の実施形態について、図７及び８も参照して説明し、図７は、通信ネットワークのネットワークデバイスと通信関係にあるユーザ機器の通信セキュリティを強化する方法のフローチャートを示し、図８は、通信ネットワークの第１のネットワークデバイスの通信セキュリティを強化する方法の方法ステップのフローチャートを示す。

【0123】

ここで与えられる例では、通信ネットワーク３６は、第１のワイヤレスネットワークＷＮ_１であり、第１のネットワークデバイス４４は、第１のワイヤレスネットワークのＭＭＥである。

【0124】

動作は、ＵＥが第１の通信ネットワーク３６に接続することから開始し得る。この一部として、たとえば国際モバイル加入者識別情報ＩＭＳＩなどの識別子が、ＵＥから又はむしろＵＥのＵＳＩＭ４８から第１のネットワークデバイス４４へ提供されてもよく、第１のネットワークデバイス４４は、転じて、認証ベクトルＡＶを求める要求を第２の通信ネットワーク３８内の第２のネットワークデバイス４６へ送信する。第２のネットワークデバイス４６は、認証トークンＡＵＴＮ、ランダム値ＲＡＮＤ、検証計算の期待される結果ＸＲＥＳ、並びに初期セッション鍵Ｋａｓｍｅを含み得る認証ベクトルを生成する。これはまた、鍵ＣＫ／ＩＫなど他の鍵を含んでもよい。従って、これまで、第２のネットワークノード４６は、既存の（３ＧＰＰ）ＡＫＡ仕様に従って動作し得る。このようにして、第１のネットワークデバイス４４は、ステップ７４で、少なくともランダム値ＲＡＮＤ及び期待される検証結果ＸＲＥＳを含み得る認証ベクトルを取得する。ここでは、ＵＥに対するチャレンジとしての使用のためにＲＡＮＤが提供され、ＡＵＴＮがこのチャレンジについてのチャレンジ検証コードを含むことに言及することができる。

【0125】

認証ベクトルを取得した後、第１のネットワークデバイスは、次いで、ステップ７６で、第１のＰＦＳパラメータＰＦＳ_１を取得し、第１のＰＦＳパラメータＰＦＳ_１は、ベース値ｇのｘ（ランダム値）乗として、すなわちｇ＾ｘとしての生成を通じて取得されてよく、ランダム値ｘは、第１のネットワークデバイス４４によって生成されてもよい。代替的に、ランダム値ｘ及び／又は第１のＰＦＳパラメータＰＦＳ_１は、第２のネットワークデバイス４６から取得され、このケースにおいて、第２のノード４６は、ＡＫＡによって現在仕様化されているもの以外の追加の動作を実行する。その後、第１のネットワークデバイス４４は、ステップ７８で、第１のＰＦＳパラメータＰＦＳ_１についての第１の検証コードＶＣ_１を取得する。１つの変形例では、第１のネットワークデバイス４４は、検証コード自体を生成することによってＶＣ_１を取得し、別の変形例では、第２のネットワークデバイスが第１の検証コードを生成する。従って、第２の変形例では、第２のノード４６が、ＡＫＡによって現在仕様化されているもの以外に追加の動作を実行する場合もある。第１の検証コードＶＣ_１は、鍵として、ＸＲＥＳ又は初期セッション鍵Ｋａｓｍｅなどの認証ベクトルの既知の鍵を使用して、第１のＰＦＳパラメータＰＦＳ_１上でメッセージ認証コード（ＭＡＣ）として生成され得る。第２のネットワークデバイス４６が第１の検証コードを生成する場合、ＲＡＮＤ値は第１のＰＦＳパラメータＰＦＳ_１に基づく。このケースにおいて、ＲＡＮＤ値は、第１のＰＦＳパラメータＰＦＳ_１として、又は暗号ハッシュなど、第１のＰＦＳパラメータＰＦＳ_１のハッシュとして、第２のネットワークデバイス４６によって生成され得る。それにより、例えば、ＵＥによって、チャレンジ検証コードＡＵＴＮを第１のＰＦＳパラメータＰＦＳ_１についての第１の検証コードＶＣ_１としても使用することができる。ここで言及し得ることとして、これら双方の例におおいて、ＲＡＮＤは、事実上、ＵＥのＵＳＩＭ４８に対するチャレンジである。

【0126】

次いで、第１のネットワークデバイス４４は、恐らくは共にＲＡＮＤ情報エレメントにより符号化されるチャレンジＲＡＮＤ及び第１のＰＦＳパラメータＰＦＳ_１、並びに第１の検証コードＶＣ_１をＵＥへ送信し、これらは、有利には、ステップ８０で、認証要求メッセージＡＲＱ内で送信され得る。第１の検証コードＶＣ_１が別個の（すなわち、ＡＵＴＮとは異なる）コード、例えば第１のネットワークデバイス４４によって生成される専用のＭＡＣである場合、認証トークンＡＵＴＮもまた上記メッセージ内に別に提供されてよい。

【0127】

次いで、ステップ６４において、チャレンジＲＡＮＤ、第１のＰＦＳパラメータＰＦＳ_１（ＲＡＮＤ内で又は追加のパラメータ内で符号化される）、及び第１の検証コードＶＣ_１（ＡＵＴＮ又は別個のコード内で符号化される）がＵＥにおいて受信される。それらは、より具体的には、ＭＥ４６の通信モジュール５０によって受信される認証要求メッセージＡＲＱを通じて受信され、そこからＰＦＳ−ＡＫＡモジュール５２へ転送されてよい。

【0128】

ＰＦＳ ＡＫＡモジュール５２では、ステップ６５で、チャレンジ又はその派生がＵＳＩＭ４８へ転送される。これは、純粋なチャレンジをＵＳＩＭ４８へ転送する目的で行われる。純粋なチャレンジは、上述した代替手段に依存して、２つの方法のうちの１つで取得されてよい。ＲＡＮＤ情報エレメントが第１のＰＦＳパラメータＰＦＳ_１を符号化する場合、それは、ＲＡＮＤ情報エレメントのハッシュ、すなわちｇ＾ｘのハッシュをＰＦＳ
ＡＫＡモジュールが計算することを通じて派生として取得され得る。これは、ＲＡＮＤが未だ第１のＰＦＳパラメータｇ＾ｘのハッシュでない場合、この段階で１つが計算され得ることを意味する。ＲＡＮＤ情報エレメントが第１のＰＦＳパラメータＰＦＳ_１を符号化しない場合、ＲＡＮＤ情報エレメントの値がＵＳＩＭへ直接的に入力され得る。また、ＰＦＳ ＡＫＡモジュールによって受信されるチャレンジが暗号ハッシュなど第１のＰＦＳパラメータのハッシュである場合、ＵＳＩＭへそれが直接的に転送されてもよい。上記転送は、ＵＥ内の標準化されたＵＳＩＭ−ＭＥインターフェースを介して実行される。

【0129】

上述したように、ＵＳＩＭ４８は、鍵Ｋを含み、有利には、鍵Ｋは第２のネットワークデバイス４６と予め共有されている。また、ＵＳＩＭ４８は、暗号処理手段をも含む。その場合、このモジュール４８は、チャレンジ（ＲＡＮＤ及びＡＵＴＮ）に対する応答として、少なくとも１つの結果パラメータ（ＣＫ／ＩＫ）を提供し得る。１つの結果パラメータが、初期セッション鍵Ｋａｓｍｅを取得するためにＰＦＳ ＡＫＡモジュール５２によって使用され得る、暗号化鍵ＣＫ及び完全性保護鍵ＩＫなどの１つ以上の暗号鍵であってもよい。別の結果パラメータは、チャレンジに対する応答パラメータＲＥＳであってもよく、応答パラメータは、応答値を有する。従って、このような応答パラメータは、予め共有される鍵及び上記暗号処理手段に基づいて計算される暗号値を有する。

【0130】

このようにして、モバイル機器４６、及びより具体的にはＰＦＳ ＡＫＡモジュール５２は、ステップ６６で、１つ以上の結果パラメータを取得し又はむしろ受信し、続いて、ステップ６８で、第１のＰＦＳパラメータＰＦＳ_１の真正性、すなわちｇ＾ｘの真正性を判定する。従って、ＰＦＳ ＡＫＡモジュール５２は、ＶＣ_１及び１つ以上の結果パラメータに基づいて、ＰＦＳパラメータＰＦＳ_１が真正であるかを判定する。これは、第１の検証コードのための鍵が１つ以上の結果パラメータに基づいていること、及び、ＶＣ_１内で搬送されるＭＡＣを上記鍵を用いて検証することを通じて行われ得る。第１の検証コードがチャレンジの一部であるか、又はむしろチャレンジ検証コードＡＵＴＮ、すなわちＡＵＴＮのＭＡＣサブフィールド内で搬送される場合、真正性を判定するために結果パラメータが取得されれば十分である。すなわち、ＵＳＩＭ４９は、ＡＵＴＮの検証がＵＳＩＭの内部で失敗した場合には、いかなる結果パラメータも提供さえせず、エラーテータスコードを返却する。従って、第１の検証コードは、チャレンジ検証コードの少なくとも一部として提供されてもよい。このようにして、真正性は、ＵＳＩＭ４８が少なくとも１つの結果パラメータを提供することに基づいて判定される。

【0131】

少なくとも１つの結果パラメータは、予め共有される鍵Ｋ及び暗号処理手段を使用して上記チャレンジ又はチャレンジの派生を検証することの、アイデンティティモジュールによる失敗を示すエラー標識を含んでもよい。これは、ＲＡＮＤ＝ｇ＾ｘ ａｂｄ−ＡＵＴＮ検証がＵＳＩＭの内部で失敗した場合に当てはまり得る。そのようなエラー信号がＰＦＳ ＡＫＡモジュール５２によって受信された場合、ＰＦＳ ＡＫＡモジュール５２は、第１のＰＦＳパラメータが真正でないと直接的に判定し得る。

【0132】

その後、ＭＥ４６又はむしろＭＥ４６のＰＦＳ ＡＫＡモジュール５２は、ステップ７０で、第２のＰＦＳパラメータＰＦＳ_２及び第２の検証コードＶＣ_２を生成し、第２のＰＦＳパラメータＰＦＳ_２は、ベース値ｇのｙ（別のランダム値）乗、すなわちｇ＾ｙとして生成され得る。一方、検証コードＶＣ_２は、第２のＰＦＳパラメータＰＦＳ_２及び鍵（例えば、結果パラメータのうちの１つ）又は結果パラメータの派生Ｋｄ（例えば、Ｋａｓｍｅ）のメッセージ認証コード（ＭＡＣ）として生成され得る。このように、第２の検証コードは、第２のＰＦＳパラメータと、結果パラメータ又は結果パラメータの派生を使用して計算され得る。この第２の検証コードＶＣ_２が応答パラメータＲＥＳに基づいて生成される場合、ＶＣ_２は通常ＲＥＳを搬送する情報エレメント内に符号化され得る。それは、次いで、例えばＲＥＳ及びｇ＾ｙのＭＡＣなど、ＲＥＳ及びｇ＾ｙの関数として生成されてよく、この場合、ＲＥＳが鍵として機能する。従って、ＰＦＳモジュールは、ＭＡＣ（Ｋｄ，ｇ＾ｙ，…）として、ＭＡＣ（Ｋａｓｍｅ，ｇ＾ｙ，…）として、又はＭＡＣ（ＲＥＳ，ｇ＾ｙ，…．）としてのいずれかで、ＶＣ_２を計算する。次いで、第２のＰＦＳパラメータＰＦＳ_２及び第２の検証コードＶＣ_２は、ステップ７２で、別個の応答パラメータＲＥＳと共に（Ｋｄが鍵として使用された場合）、又は通常はＲＥＳ情報エレメントであるはずのものにＶＣ_２を符号化することによって（ＲＥＳが鍵として使用された場合）、のいずれかで第１のネットワークデバイスへ送信され、より具体的には、認証要求応答メッセージＡＲＥ内で送信され得る。

【0133】

また、ＰＦＳ ＡＫＡモジュール５２は、第１及び第２の検証コードが特定の関係を満たすかどうかをも検証してよい。これあ当てはまるのは、第１のＰＦＳパラメータ、すなわちｇ＾ｘがチャレンジＲＡＮＤ内で符号化されておらず、第１の検証コードＶＣ_１がたとえば明示的なＭＡＣなどの別個のコードである場合であってよく、それはＵＳＩＭの外部で検証される。このケースにおいて、上記特定の関係は、等価性である。

【0134】

従って、第２のＰＦＳパラメータＰＦＳ_２及び第２の検証コードＶＣ_２、並びに、場合によっては別個の応答パラメータが、ステップ８２で、例えば認証要求応答メッセージＡＲＥ内で第１のネットワークデバイス４４によって受信される。次いで、第１のネットワークデバイス４４は、ステップ８４で、応答パラメータＲＥＳの真正性を判定し、これはチャレンジ結果又は応答パラメータ値ＲＥＳを期待されるチャレンジ結果ＸＲＥＳと比較することを通じて行われ得る。最後に、ステップ８６で、第２の検証コードＶＣ_２に基づいて、第２のＰＦＳパラメータＰＦＳ_２が検証される。第２の検証コードＶＣ_２が応答ＲＥＳとは別に提供される場合、ステップ８６における検証は、第２の検証コードＶＣ_２を検証するために、初期セッション鍵Ｋａｓｍｅ又はその派生Ｋｄを鍵として使用して、第２のＰＦＳパラメータのＭＡＣに基づいてなされもよい。第２の検証コードＶＣ_２が、鍵としての応答パラメータ値に基づいて関数として提供され、ＶＣ_２がＲＥＳパラメータ内に符号化された場合、第１のネットワークデバイスはステップ８４と８６とを同時に実行してもよく、なぜなら、第２の検証コードの正しい値は、ＵＥが正しいＲＥＳ、すなわちＸＲＥＳにより示されるものと同じ値を使用したことを示唆するからである。

【0135】

これにより、通信セキュリティを強化する方式が実装されている。これは、より具体的には、ＰＦＳを提供することから、秘密である予め共有される鍵が破られている場合のセキュリティを強化する。

【0136】

その後のセッション、たとえば、ＵＥとネットワークとの間の、より具体的にはＵＥと第１のネットワークデバイス４４との間のデータ又はシグナリング交換では、この場合、セッション鍵を通信を保護するために使用すること、及びそのセッション鍵が第１及び第２のＰＦＳパラメータに基づくことが可能である。セッション鍵は、より具体的には、ｇ＾（ｘｙ）に従って、ベースｇの値ｘ乗の値ｙ乗に基づいてよい。代替的に、Ｋａｓｍｅとｇ＾（ｘｙ）との結合という派生が使用されてもよい。それにより、理解し得ることとして、少なくとも第１及び第２のＰＦＳパラメータを生成するために使用される値ｘ及びｙに基づくセキュアなセッション鍵が取得される。従って、これは、ＰＦＳパラメータのうちの１つと、他のＰＦＳパラメータの指数とに基づいて生成される。これは、より具体的には、ＰＦＳ ＡＫＡモジュール５２が第１のＰＦＳパラメータＰＦＳ_１と第２のＰＦＳパラメータＰＦＳ_２の指数ｙとに基づいてセッション鍵を生成し得る一方で、第１のネットワークデバイス４４が第２のＰＦＳパラメータＰＦＳ_２と第１のＰＦＳパラメータＰＦＳ_１の指数ｘとに基づいてセッション鍵を生成し得ることを意味し得る。

【0137】

次に、第２の実施形態について、図９を参照しながら説明する。図９は、ＨＳＳの形式の第２のネットワークデバイス、ＭＭＥの形式の第１のネットワークデバイス、及びＭＥとＵＳＩＭとに分けられるユーザ機器が関与するシグナリングチャートを示している。この実施形態において、第２のノード（ＨＳＳ）は、現在のＡＫＡ仕様の一部ではないステップ群を実行し、図１０については、チャレンジ検証コードをより詳細に示している。

【0138】

図１０において見られるように、及び前に説明したように、ＡＵＴＮパラメータによって提供されるチャレンジ検証コードは、フィールド：ＡＭＦ（認証管理フィールド）、ＭＡＣ（メッセージ認証コード）、及び、このケースでは匿名鍵ＡＫ）によって暗号化されるシーケンス番号標識ＳＱＮを含む。ＭＡＣフィールドが第１の検証コードＶＣ_１Ａとして使用されていることも理解され得る。ここで言及し得ることとして、第１の検証コードについてＳＱＮフィールドを使用することも可能である。

【0139】

第２の実施形態は、ネットワーク／ネットワークデバイスからＵＥ／通信デバイスへの送信の際にＰＦＳパラメータとしてＤＨ値を搬送するためにＲＡＮＤパラメータを使用することに基づく：：ＲＡＮＤ＝ｇ＾ｘ、又は、ｇ＾ｘの派生。

【0140】

なお、ＤＨのいくつかのバリエーションに従って計算されるＰＦＳパラメータは、ＲＡＮＤの現在のところ標準化されているサイズである１２８ビットよりも実質的に大きいかもしれない。従って、これはＵＳＩＭ−ＭＥインターフェースに問題を生じさせかねない。これに対処するために、ＵＳＩＭ（及びＨＳＳ、ホーム加入者サーバ）のｆ−アルゴリズムにＲＡＮＤを入力する前に、例えば、暗号化ハッシングによって、提供されたＲＡＮＤ値が圧縮され得る。すなわち、ＲＡＮＤ´＝Ｈ（ＲＡＮＤ）＝Ｈ（ｇ＾ｘ）であり、ここでは、Ｈは、適切な数のビットを生成する適切な関数であり、例えば、Ｈは、ＳＨＡ２（ＳＨＡはSecure Hash Algorithmを表す）、ＡＥＳ（Advanced Encryption Standard）、ＨＭＡＣ（key-Hashed Message Authentication Code）などに基づいてよい。原理上、Ｈは、ＲＡＮＤから１２８ビットのセット、例えば、下位１２８ビットを選択する関数とすることもできる。ＵＥ側では、ＵＳＩＭにＲＡＮＤ´を入力する前に、ＨをＭＥ（例えば、ＰＦＳモジュール）に同様に適用することができる。ＲＡＮＤはＵＳＩＭを対象とするチャレンジであるので、理解し得ることとして、ＭＥがそのようにしてチャレンジの派生を生成し及びそれをＵＳＩＭへ転送してもよい。結果として、（ＡＵＴＮ内に含まれる）ＡＫＡ ＭＡＣフィールドがＲＡＮＤ´に依存して計算されることになり、但し、Ｈの使用を通じて、実質的には依然としてＲＡＮＤ、すなわちｇ＾ｘに依存して計算されるであろう。従って、このＤＨ値のＡｕＣ（認証センター）／ＨＳＳからＵＳＩＭへの認証が、特にサービングネットワークとＵＥとの間のＭＩＴＭ攻撃を防止しながら獲得される。なぜなら、移送中のｇ＾ｘの何らかの成りすまし又は修正は、ＵＥ内のＵＳＩＭにおいてＡＵＴＮ検証によって検出されるはずだからである。

【0141】

図４及び図７を参照すると、これは、第１のＰＦＳパラメータＰＳＦ_１の修正又は捏造が、高い確率で、ＡＵＴＮ（より正確にはＭＡＣサブフィールド）の不正となることを示唆するであろう。その場合、ＡＵＴＮの検証はＵＳＩＭ４８の内部で失敗し、ＵＳＩＭは、結果パラメータのいずれも、提供さえしないであろう。第１のＰＦＳパラメータの真正性は、このようにして、ＵＳＩＭ４８が少なくとも１つの結果パラメータを提供することに基づいて判定される。

【0142】

より大きいＲＡＮＤ値は、ＡｕＣ／ＨＳＳによって計算され、修正された形式の認証ベクトル（ＡＶ）内でＭＭＥ（Mobile Management Entity）へ送信され得る。別の可能性は、ＭＭＥがＡＶ内で通常通りのサイズで形成されたＲＡＮＤを受信し、それをＵＥへ送信する前に、ＲＡＮＤにビットの集合を後方又は前方へ付加することによってＲＡＮＤを拡張することである。この後者の場合、関数Ｈの選択は、受信されたＲＡＮＤをＭＭＥがどのように拡張したかに適合しなければならず、さもなければＵＳＩＭはＲＡＮＤ／ＡＵＴＮのペアを拒否することになる。

【0143】

この第２の実施形態の残りは、ＡＵＴＮが第１の検証コードＶＣ_１を提供するために使用され（以下、ＶＣ_１Ａに対応する）、又は等価的に、第１のＰＦＳパラメータＰＦＳ_１がＲＡＮＤ情報エレメント内に符号化されるという特別なケースにおける第１の実施形態と同一である。第２の実施形態の動作は、より具体的には、次のようになり、及び図９に示されている通りであり得る。・例えば、ネットワークアタッチ８８の一部として、例えばＩＭＳＩ（International Mobile Subscriber Identity）などの識別子がＵＥ（ＵＳＩＭ）から提供される。これは、１０で、ＨＳＳへ転送される。・ＨＳＳは、８９で、認証ベクトル（ＡＶ）を生成する。この実施形態によって追加されるいくつかの新たな構成要素に焦点を当てる（他の部分は概して影響を受けない）。具体的には、議論したようにＲＡＮＤはｇ＾ｘとして生成され、その圧縮されたバージョンＲＡＮＤ´がｆ１、ｆ２、…等の通常のＡＫＡ計算で使用される。応答ＡＶ９０において、ＨＳＳは、（ＭＭＥが後で共有鍵を計算できるようにするため）ｘを含める／追加する。従って、ＭＭＥはｘからＲＡＮＤを計算することができることから、ＨＳＳは、ＲＡＮＤを送信することを省略してもよい。同様に、今やセッション鍵Ｋ´をＤＨ値（ｇ＾ｘ及びｇ＾ｙ）から推測し得ることから、必ずしもＣＫ及びＩＫ（又はそこから導出される鍵、例えばＬＴＥのＫａｓｍｅ）を送信することは必要ではないかもしれない。ＣＫ及びＩＫが移送される必要があるかどうかは、本開示の他の箇所で議論される実施形態の詳細に依存する。・ＭＭＥは、２０で、ＲＡＮＤ及びＡＵＮＴをＵＥ／ＵＳＩＭへ転送する。ここで、ＲＡＮＤは、チャレンジであると共に第１のＰＦＳパラメータＰＦＳ_１であり、ＡＵＴＮのＭＡＣフィールドは、第１のＰＦＳパラメータＰＦＳ_１についての第１の検証コードＶＣ_１Ａであり、なぜならそれは、実質的にｇ＾ｘでもあるＲＡＮＤに依存して計算されているためである。・ＵＥ（例えば、ＭＥ部分）は、ＲＡＮＤ´＝Ｈ（ＲＡＮＤ）を計算し、９２で、それをＡＫＡパラメータ導出（ＲＥＳ、ＣＫ、ＩＫ）のためにＵＳＩＭへ送信する。注記したように、ＵＳＩＭが内部的にＡＵＴＮのＭＡＣ部分を検証する際、これは、ｇ＾ｘの真正性を検証するためにも供される。・ＵＳＩＭは、９４で、ＲＥＳ、ＣＫ、ＩＫによって応答し得る。ＭＥがこの応答を受信することを通じて、第１のＰＦＳパラメータＰＦＳ_１が真正であると判定することもでき、さもなければ、これらのパラメータを含む応答は提供されないはずである。・ＵＥは、９６で、ＤＨ値ｇ＾ｙ及び関連付けられる認証情報を生成する。従って、ＵＥは、第２のＰＦＳパラメータＰＦＳ_２及び第２の検証コードＶＣ_２Ａを生成する。第２の検証コードＶＣ_２Ａは、ＭＡＣ（Ｋｄ｜｜…，ｇ＾ｙ｜｜…）という形式の値ＲＥＳ´として実現されることができる。認証情報の厳密な形式（使用すべき鍵Ｋｄなど）は様々であってよい：
−１つの変形例では、ＲＥＳのみが鍵Ｋｄのための基底として使用される。
−別の変形例では、ＲＥＳ及びＣＫ、ＩＫのうちの少なくとも１つがＫｄのための基底として使用される（これは、認証ベクトルを生成する際にＨＳＳがこれらを含めたことを前提とする）。ＫａｓｍｅをＫｄのための基底として使用することもできる。このように、第２の検証コードＶＣ_２Ａは、鍵Ｋｄのための基底としてＲＥＳが使用されることを通じてＲＥＳ’として生成され得る。なお、ＲＥＳが認証／応答ＲＥＳ´の導出に含められない場合、ＭＥがＲＥＳをも送信する必要があり得る。概して、ＲＥＳ´は、現在のＡＫＡプロトコルのＲＥＳに置き換わってもよく、又はＲＥＳとは別の追加的なパラメータとして送信されてもよい。
次いで、ＭＥは、２４でＭＭＥへｇ＾ｙ及びＲＥＳ´を送信する。・ＭＭＥは、９８で対応する計算を実行して、ＲＥＳ´を検証し及び共有鍵Ｋ´を計算し得る。ｇ＾（ｘｙ）への依存に加えて、Ｋ´は、ＨＳＳによって供給された場合、ＣＫ、ＩＫ（又はＫａｓｍｅ鍵）に依存して計算されることもでき、たとえば、鍵導出関数Ｇについて、Ｋ´＝Ｇ（ｇ＾（ｘｙ）、ＣＫ、ＩＫ、…）である。（例えば、暗号化などデータ保護のための）さらなる鍵がＵＥ及びＭＭＥ（図示せず）によってＫ´から導出されてもよい。

【0144】

第２の実施形態の変形例では、使用されるチャレンジはｇ＾ｘのハッシュである。これは、ＨＳＳによって生成され、ＭＭＥによってＵＥへ送信されるＲＡＮＤがｇ＾ｘのハッシュであることを意味する。これにはｇ＾ｘも伴う必要がある。それにより、ＭＥがそのハッシュを計算することなく、ＭＥからＵＳＩＭへＲＡＮＤを直接的に送信することができる。

【0145】

第３の実施形態では、第２のノードは、現在のＡＫＡ仕様の一部ではないいかなるステップも実行しなくてよい。以下では、第２のノードが現在のＡＫＡ仕様に対する追加のステップを実行するいくつかのオプションが存在するが、これらのステップはオプションであり、望まれる場合には回避することができる。

【0146】

この実施形態では、ｇ＾ｘに関する情報をネットワーク（サービング又はホームネットワーク）からＵＥへ移送し又は搬送するために、ＲＡＮＤパラメータは使用されない。従って、第１の検証コードを搬送するためにＡＵＮＴを使用することもできない。代わりに、ネットワークはＲＡＮＤをＵＥへ別個に送信し、ＲＡＮＤとして、その同じメッセージの新しい情報エレメント内にｇ＾ｘを含める。注記したように、その送信はＨＳＳを起点としてもよく、又はＭＭＥを起点としてもよい（例えば、ＭＭＥがランダムｘをローカルに生成する）。このケースにおいて、ｇ＾ｘは認証される必要があり、ネットワーク（サービング又はホーム）は、メッセージにｇ＾ｘについて計算された追加のＭＡＣをもメッセージ内に含める。このＭＡＣのための鍵は、例えば、ＲＥＳ、又はＣＫ／ＩＫの一方又はその双方とすることができる。それは、Ｋａｓｍｅなど、その派生であってもよい。関数Ｈは、この実施形態では恒等関数である。それにより、派生はチャレンジと同一になる。この実施形態の１つの利点は、サービングネットワーク（例えば、ＭＭＥ）が値ｘを選択することができ、サービングネットワークとＡｕＣ／ＨＳＳとの間でこれをシグナリングする必要がないことである。実際には、今日使用されているようなこれらのノード間の同じシグナリングを再利用することができる。欠点は、より大きいｇ＾ｘ値と共に、１２８ビットＲＡＮＤをサービングネットワークからＵＥへ送信する必要があることである。従って、エアインターフェース上にいくらかより多くの帯域幅を要する。

【0147】

以下に、図１０を参照しながら第３の実施形態をさらに説明する。図１０は、ＵＳＩＭ、ＭＥ、ＭＭＥ及びＨＳＳが関与するシグナリングチャートを示している。・動作は、ＭＭＥが１０で認証ベクトルを求める要求をＨＳＳへ送信することにより開始し得る。ＨＳＳは、１００で、ＲＡＮＤ、ＡＵＴＮ、ＸＲＥＳ及びセッション鍵Ｋａｓｍｅを含む認証ベクトル応答で応答する。次いで、ＭＭＥは、第１のＰＦＳパラメータＰＦＳ_１を生成すると共に、第１の検証コードＶＣ_１Ｂを生成し、ここで、第１のＰＦＳパラメータＰＦＳ_１は、ｇ＾ｘとして生成されてもよく、第１の検証コードＶＣ_１Ｂは、例えばＸＲＥＳ又はＫａｓｍｅを共通鍵として使用して、ＭＡＣ（ｇ＾ｘ）として生成されてもよい。これが終了すると、ＭＭＥは、２０で、認証要求メッセージをＵＥのＭＥへ送信する。このケースにおける認証要求は、ＲＡＮＤ、ＡＵＴＮ、ｇ＾ｘ及びＭＡＣ（ｇ＾ｘ）を含む。次いで、ＭＥは、１０２で、ＡＵＴＮの一部としてチャレンジＲＡＮＤ及びチャレンジ検証コードをＵＳＩＭへ転送し、ＵＳＩＭは、１０４で、鍵ＣＫ／ＩＫ及び応答パラメータＲＥＳで応答する。それにより、ＵＳＩＭは、チャレンジに正しく応答したことになる。次いで、ＭＥは、第１の検証コードＶＣ_１Ｂを使用して第１のＰＦＳパラメータＰＦＳ_１を認証する。このケースでは、これは、共通鍵を通じて第１の検証コードＶＣ_１Ｂが生成されることを通じて行われ得る。共通鍵は、このケースでは、（ＭＥにおける応答パラメータ値ＲＥＳと同一である）ＸＲＥＳであった。次いで、ＭＥは、第２のＰＦＳパラメータＰＦＳ_２及び第２の検証コードＶＣ_２Ｂを生成し、第２のＰＦＳパラメータＰＦＳ_２は、ｇ＾ｙとして生成され、第２の検証コードＶＣ_１Ｂは、いずれもＭＭＥにとっては既知であるＣＫ／ＩＫ、Ｋａｓｍｅ又はＲＥＳのいずれかを使用してＭＡＣ（ｇ＾ｙ）として生成されてよく、認証応答メッセージ２４で結果ＲＥＳと共にこれらを送信する。次いで、ＭＭＥは、ＲＥＳとＸＲＥＳとの比較を通じて結果を検証し、また、ＭＡＣ（ｇ＾ｙ）及び適切な鍵、例えばＣＫ／ＩＫ又はＸＲＥＳなどを使用してｇ＾ｙを検証する。その後、ＭＥは、１０６で、ｇ＾（ｘｙ）の関数としてセッション鍵Ｋ´を計算し、その関数は、典型的にはｇ＾（ｘｙ）のハッシュである。また、ＭＭＥは、１０８で、ｇ＾（ｘｙ）の同じ関数としてセッション鍵Ｋ´を計算する。

【0148】

それにより、ＵＥは、改善されたセキュリティで第１のワイヤレスネットワークと通信することができる。

【0149】

理解すべきこととして、この第３の実施形態においても、たとえば、第２の検証コードＶＣ_２Ｂを計算するために使用される鍵が前の実施形態の場合のようにＲＥＳに依存する場合、第２の検証コードとしてＲＥＳ´を使用することが可能である。

【0150】

なお、全ての実施形態が、米国特許第７，１９４，７６５号において開示された発明と組み合わせられてもよい。このケースにおいて、ＨＳＳがＭＭＥにＸＲＥＳを提供するのではなく、むしろＸＲＥＳ´＝Ｈ（ＸＲＥＳ）である。ＵＥは、次いで、ＭＭＥがＸＲＥＳ´を計算し及び検証できるように、ＲＥＳをＭＭＥへ明示的にシグナリングし得る。このケースにおいて、ＣＫ及びＩＫ（又はそこから導出される何らかの鍵）のうちの少なくとも１つをＲＥＳ´の計算に含めるべきである。

【0151】

なお、あらためて言うと、ＧＢＡ及びＥＡＰ−ＡＫＡはＡＫＡを活用することから、当業者であれば、この説明の後に、説明した実施形態をそれら文脈にも簡易な修正により適用することができることを理解するであろう。本開示の実施形態の少なくとも１つの利点として、ネットワーク認証、たとえば、モバイルネットワーク認証にＰＦＳが低コストで又は最小のコストで追加され、ＡＫＡプロトコルのためのＳＩＭ−ＭＥインターフェースとの後方互換性が可能となり及び／又は保証される。本開示の実施形態の少なくとも１つの別の利点は、ハッキングされたＨＳＳ及びハッキングされたスマートカードベンダーサイトなど、長期鍵の侵害の影響を制限することである。他の利点は、追加的な送信信号の使用を回避することを含み、それによってエネルギーが節約される。

【0152】

モバイル機器のコンピュータプログラムコードは、例えばＣＤ ＲＯＭディスク又はメモリスティックなど、データ記憶媒体の形式のコンピュータプログラムプロダクトの形式であり得る。このケースにおいて、データ記憶媒体は、上記のモバイル機器の機能性を実装するコンピュータプログラムコードを有するコンピュータプログラムを担持する。コンピュータプログラムコード１１２を有する１つのそのようなデータ記憶媒体１１０は、図１２に概略的に示されている。

【0153】

第１のネットワークデバイスのコンピュータプログラムコードは、例えばＣＤ ＲＯＭディスク又はメモリスティックなど、データ記憶媒体の形式のコンピュータプログラムプロダクトの形式であり得る。このケースにおいて、データ記憶媒体は、上記の第１のネットワークデバイスの機能性を実装するコンピュータプログラムコードを有するコンピュータプログラムを担持する。コンピュータプログラムコード１１６を有する１つのそのようなデータ記憶媒体１１４は、図１３に概略的に示されている。

【0154】

図１４に概略的に示すように、通信デバイス４０は、いくつかの実施形態では、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードをネットワークデバイスから受信するための受信ユニット１１８と、チャレンジ又はその派生をアイデンティティモジュールへ転送するための転送ユニット１２０と、少なくとも１つの結果パラメータを、アイデンティティモジュールからの応答として受信するための受信ユニット１２２と、上記結果パラメータに基づいて、第１のＰＦＳパラメータが真正であるかを判定するための判定ユニット１２４と、上記判定において第１のＰＦＳパラメータが真正である場合に、第２のＰＦＳパラメータを生成し及びネットワークデバイスへ送信するための生成ユニット１２６と、を含み得る。これらユニットは、一実施形態において、ソフトウェア命令に対応する。別の実施形態において、これらユニットは、ＡＳＩＣ又はＦＰＧＡなど１つ以上のハードウェア回路内のハードウェアユニットとして実装される。

【0155】

通信デバイスは、通信デバイスとネットワークデバイスとの間の通信のためのセッション鍵を生成するための生成ユニットをさらに含んでもよく、セッション鍵は、第１及び第２のＰＦＳパラメータを生成するために使用される値に少なくとも基づく。

【0156】

チャレンジ、第１のＰＦＳパラメータ、及び第１の検証コードを受信するための受信ユニット１１８は、さらに、認証要求メッセージ内でネットワークデバイスからチャレンジ、第１のＰＦＳパラメータ、及び第１の検証コードを受信するための受信ユニットであってもよく、認証要求メッセージは、チャレンジ検証コードをも含む。少なくとも１つの結果パラメータを受信するための受信ユニット１２２は、転じて、チャレンジに対する応答として応答パラメータを受信するための受信ユニットであってもよく、生成ユニット１２６は、第２の検証コードと共に第２のＰＦＳパラメータを生成し及びこれらを応答パラメータをも含む認証応答メッセージ内で送信するための生成ユニットであってもよい。

【0157】

判定ユニット１２４はさらに、認証要求メッセージの対応する別個の情報エレメント内に含まれる第１の検証コードを使用して第１のＰＦＳパラメータの真正性を判定するための判定ユニットであってもよい。

【0158】

第１の検証コードがチャレンジ検証コードの少なくとも一部として提供される場合、判定ユニット１２４は、さらに、アイデンティティモジュールが少なくとも１つの結果パラメータを提供することに基づいて第１のＰＦＳパラメータの真正性を判定するための判定ユニットであってもよい。

【0159】

生成ユニット１２６は、応答パラメータに基づいて第２の検証コードを生成し、応答パラメータに割り当てられた認証応答メッセージの情報エレメント内で第２の検証コードを送信する、ための生成ユニットであってもよい。

【0160】

図１５に示すように、第１のネットワークデバイス４４は、いくつかの実施形態において、チャレンジを取得するための取得ユニット１２８と、第１のＰＦＳパラメータを取得するための取得ユニット１３０と、第１のＰＦＳパラメータについての第１の検証コードを取得するための取得ユニット１３２と、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードを通信デバイスへ送信するための送信ユニット１３４と、通信デバイスから第２のＰＦＳパラメータ、第２の検証コード及び応答パラメータを受信するための受信ユニット１３６と、応答パラメータの真正性を判定するための判定ユニット１３８と、第２の検証コードに基づいて第２のＰＦＳパラメータを検証するための検証ユニット１４０と、を含み得る。

【0161】

これらユニットは、一実施形態において、ソフトウェア命令に対応する。別の実施形態において、これらユニットは、ＡＳＩＣ又はＦＰＧＡなど１つ以上のハードウェア回路内のハードウェアユニットとして実装される。

【0162】

第１のネットワークデバイス４４は、さらに、通信デバイスと第１のネットワークデバイスとの間の通信のためのセッション鍵を計算するための計算ユニットをさらに含んでもよく、セッション鍵は、第１及び第２のＰＦＳパラメータを生成するために使用される値に少なくとも基づく。

【0163】

チャレンジを取得するための取得ユニット１２８は、チャレンジ検証コードを取得するための取得ユニットであってもよく、送信ユニット１３４は、チャレンジ、第１のＰＦＳパラメータ及び第１の検証コードを、チャレンジ検証コードと共に認証要求メッセージ内で送信するための送信ユニットであってもよく、受信ユニット１３６は、認証応答メッセージ内で第２のＰＦＳパラメータ、第２の検証コード及び応答パラメータを受信するための受信ユニットであってもよい。

【0164】

第１の検証を取得するための取得ユニット１３２は、第１のＰＦＳパラメータを使用して第１の検証コードを生成するための生成ユニットを含んでもよく、送信ユニット１３４は、認証要求メッセージの対応する別個の情報エレメント内で第１の検証コードを送信するための送信ユニットであってもよい。

【0165】

第１のネットワークデバイスは、第１のＰＦＳパラメータの生成において使用されるべき値ｘを受信するための受信ユニットを含んでもよい。指数値である値ｘは、シード値と称されてもよい。このケースにおいて、第１の検証コードを取得するための取得ユニット１３２は、チャレンジ検証コードの少なくとも一部として第１の検証コードを取得するための取得ユニットであってもよく、送信ユニット１３４は、第１の検証コードをチャレンジ検証コードの少なくとも一部として認証要求メッセージ内で送信するための送信ユニットであってもよい。

【0166】

チャレンジを取得するための取得ユニット１２８は、期待されるチャレンジ結果を取得するための取得ユニットであってもよく、判定ユニット１３８は、期待されるチャレンジ結果との比較を通じて応答パラメータの真正性を判定するための判定ユニットであってもよい。

【0167】

応答パラメータは、第２の認証コードが応答パラメータに基づくことを通じて認証応答メッセージに含められてもよい。このケースにおいて、受信ユニット１３６は、応答パラメータに割り当てられた認証応答メッセージの情報エレメント内で第２の検証コードを受信するための受信ユニットであってもよく、判定ユニット１３８及び検証ユニット１４０は、第２の検証コードを使用して、応答パラメータの真正性の判定と第２のＰＦＳパラメータの検証とを同時に行うための、組み合わせとしての判定及び検証ユニットであってもよい。

【0168】

図１６に概略的に示すように、第２のネットワークデバイスは、転じて、いくつかの実施形態において、第１のネットワークデバイスへチャレンジを送信するための送信ユニット１４を含み得る。

【0169】

第２のネットワークデバイスは、さらに、少なくとも値ｘに基づいて第１のＰＦＳパラメータを生成することを通じて、第１のＰＦＳパラメータを取得するための値を提供するための提供ユニット１４４と、第１のＰＦＳパラメータを使用してチャレンジ検証コードを生成するための生成ユニットと、第１のネットワークデバイスへ上記値を送信するための送信ユニットとを含んでもよい。

【0170】

これらユニットは、一実施形態において、ソフトウェア命令に対応する。別の実施形態において、これらユニットは、ＡＳＩＣ又はＦＰＧＡなど１つ以上のハードウェア回路内のハードウェアユニットとして実装される。

【0171】

本発明は、最も実用的で好ましい実施形態であると今のところ考えられているものとの関連で説明されているが、本発明は、開示された実施形態に限定されるものではなく、むしろ、多様な修正例及び均等の構成を包含することが意図されることが理解されるべきである。従って、本発明は、以下の特許請求の範囲によってのみ限定される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】