(57)【要約】  本発明は、専用のネットワークアプリケーション機能（ＮＡＦ）及び少なくとも１つのブートストラッピングサーバ機能（ＢＳＦ１，ＢＳＦ２）を利用して２つのユーザ機器（ＵＥ１，ＵＥ２）間のセキュアな音声通信セッションを確立する方法に係り、第１及び第２のユーザ機器のブートストラッピングサービス導出外部又は内部ＮＡＦ鍵（Ｋｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦ１及びＫｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦ２）からセッション鍵（Ｋｓ＿ＳＶ）を算出するステップと、算出されたセッション鍵（Ｋｓ＿ＳＶ）を用いて保護された音声通信（ＳＶ）を確立するステップと、を備える。【選択図】図２
2016519873.tif 000002
【特許請求の範囲】
【請求項１】
専用のネットワークアプリケーション機能（ＮＡＦ）と少なくとも１つのブートストラッピングサーバ機能（ＢＳＦ１，ＢＳＦ２）とを利用して２つのユーザ機器（ＵＥ１，ＵＥ２）間にセキュアな音声通信セッションを確立する方法であって、
第１のユーザ機器（ＵＥ１）が第２のユーザ機器（ＵＥ２）との通信の要求（ＲＥＱ（ＩＤ１，ＩＤ２））及びセキュリティアソシエーション要求（ＲＥＱ（ＩＤ１，ＩＤ２），ＳＥＣ）を専用のネットワークアプリケーション機能（ＮＡＦ）に送信するステップと、
前記第１のユーザ機器（ＵＥ１）が、
前記第１のユーザ機器（ＵＥ１）が第１のブートストラッピングサーバ機能ＢＳＦ１とのリンクを確立することと、
前記ＢＳＦ１がチャレンジを前記第１のユーザ機器（ＵＥ１）に送信することと、
前記第１のユーザ機器（ＵＥ１）が前記ＢＳＦ１により送信された前記チャレンジに応答することと、
前記ＢＳＦ１が前記チャレンジ応答を検証することと、
を備えたチャレンジ手順（ＣＨ１（ＮＡＦ））に進むステップと、
前記ＮＡＦがブートストラッピングサービス導出ＮＡＦ鍵（Ｋｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦ１）を前記ＢＳＦ１から検索するステップと、
前記第２のユーザ機器（ＵＥ２）が前記第１のユーザ機器（ＵＥ１）との通信要求（ＲＥＱ（ＩＤ１，ＩＤ２））を受信するステップと、
前記第２のユーザ機器（ＵＥ２）がセキュリティアソシエーション要求（ＲＥＱ（ＩＤ１，ＩＤ２），ＳＥＣ）を専用のネットワークアプリケーション機能（ＮＡＦ）に送信するステップと、
前記第２のユーザ機器（ＵＥ２）が、
前記第２のユーザ機器（ＵＥ２）が第２のブートストラッピングサーバ機能（ＢＳＦ２）とのリンクを確立することと、
前記ＢＳＦ２がチャレンジを前記第２のユーザ機器（ＵＥ２）に送信することと、
前記第２のユーザ機器（ＵＥ２）が前記ＢＳＦ２により送信されたチャレンジに応答することと、
前記ＢＳＦ２が前記チャレンジ応答を検証することと、
を備えたチャレンジ手順（ＣＨ２（ＮＡＦ））に進むステップと、
前記ＮＡＦがブートストラッピングサービス導出外部及び内部ＮＡＦ鍵（Ｋｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦ２）を前記ＢＳＦ２から検索するステップと、
を備え、
さらに、
前記第１及び前記第２のユーザ機器のブートストラッピングサービス導出外部又は内部ＮＡＦ鍵（Ｋｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦ１及びＫｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦ２）からセッション鍵（Ｋｓ＿ＳＶ）を算出するステップと、
前記算出されたセッション鍵（Ｋｓ＿ＳＶ）を用いて保護された音声通信（ＳＶ）を確立するステップと、
を備える、方法。
【請求項２】
前記セッション鍵（Ｋｓ＿ＳＶ）を前記算出するステップ（ＣＡＬ（Ｋｓ＿ＳＶ））は、さらに前記算出されたセッション鍵（Ｋｓ＿ＳＶ）を各ＮＡＦ鍵で暗号化して両機器（ＵＥ１，ＵＥ２）に送信する前記ＮＡＦによって実行される、請求項１に記載の方法。
【請求項３】
前記ユーザ機器の少なくとも一方がＧＢＡ＿Ｕ対応のＵＩＣＣを備え、このユーザ機器は内部ＮＡＦ鍵を使用して前記ＮＡＦによる前記セッション鍵（Ｋｓ＿ＳＶ）の前記暗号化を行う、請求項２に記載の方法。
【請求項４】
前記セッション鍵（Ｋｓ＿ＳＶ）を算出するために用いられるデータを含む２つのメッセージ（ＭＳＧ１，ＭＳＧ２）を前記ＮＡＦにより生成するステップ（ＧＥＮ（ＭＳＧ１，ＭＳＧ２））であって各メッセージ（ＭＳＧ１，ＭＳＧ２）が所与の機器のために前記所与の機器自体のＮＡＦ鍵で暗号化された他方の機器の少なくとも１つのＮＡＦ鍵を含んでいるステップと、
前記暗号化されたメッセージ（ＭＳＧ１，ＭＳＧ２）を両機器に送信するステップ（ＳＤ（ＭＳＧ１），ＳＤ（ＭＳＧ２））と、
各機器が前記暗号化されたメッセージを復号化するステップ（ＤＥＣ）と、
自身の導出ＮＡＦ鍵と受信した前記メッセージ内の前記他方のユーザ機器のＮＡＦ鍵とから前記セッション鍵を算出するステップ（ＣＡＬ（Ｋｓ＿ＳＶ））と、
を備える、請求項１に記載の方法。
【請求項５】
前記転送されるＮＡＦ鍵は外部ＮＡＦ鍵である、請求項４に記載の方法。
【請求項６】
少なくとも一方のユーザ機器はＧＢＡ＿Ｕ対応のＵＩＣＣを備え、前記他方の機器の前記ＮＡＦ鍵の前記暗号化はこのユーザ機器の前記内部ＮＡＦ鍵を用いる、請求項４又は５に記載の方法。
【請求項７】
前記ＵＩＣＣは前記セッション鍵（Ｋｓ＿ＳＶ）を算出する算出モジュール（ＣＡＭ）をさらに備え、前記セッション鍵は前記ＵＩＣＣの内部で算出される、請求項６に記載の方法。
【請求項８】
第１及び第２のＢＳＦは同じＢＳＦであり、前記ＮＡＦ鍵又は前記セッション鍵はこのＢＳＦにより算出され、前記ＮＡＦによって検索され、各ＮＡＦ鍵で暗号化されて前記ユーザ機器（ＵＥ１，ＵＥ２）に送信される、請求項１に記載の方法。
【請求項９】
ユーザ機器から別のユーザ機器との通信の要求を受信する受信機と、
前記２つのユーザ機器のためにブートストラッピングサービス導出鍵Ｋｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦを少なくとも１つのＢＳＦから検索する検索装置と、
セッション鍵を算出するか、又はブートストラッピングサービス導出ＮＡＦ鍵Ｋｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦ１及びＫｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦ２からメッセージを生成する算出モジュール（ＣＡＭ）と、
前記セッション鍵又は前記メッセージを各ユーザ機器のＮＡＦ鍵を用いて暗号化する暗号化モジュールと、
前記暗号化されたセッション鍵を送信するか、又は各ユーザ機器が共通のセッション鍵を算出することを可能にする前記セッション鍵を構築するために生成されたメッセージを送信する送信機と、
を備える、ネットワークアプリケーション機能（ＮＡＦ）サーバ。
【請求項１０】
ＢＳＦから受信したチャレンジに応答するチャレンジ処理モジュール（ＣＰＭ）と、
鍵導出モジュール（ＫＤＭ）と、
少なくとも：
別のユーザ機器との通信の要求を送信する送信機と、
別のユーザ機器からの通信の要求を受信するとともに、セッション鍵を構築するためのメッセージを受信するか、又は暗号化されたセッション鍵を受信する受信機と、
前記セッション鍵を用いて別の機器との通信を確立する音声通信モジュールと、
を備えた通信モジュール（ＣＭ）と、
前記セッション鍵を構築するためのメッセージ又はセッション鍵を復号化する復号化モジュール（ＤＭ）と、
メッセージが受信された場合に、前記メッセージから前記セッション鍵を算出する算出モジュール（ＣＡＭ）と、
を備える、ＧＢＡ対応ユーザ機器（ＵＥ）。
【請求項１１】
前記チャレンジ処理モジュール（ＣＰＭ）と、前記鍵導出モジュール（ＫＤＭ）と、前記復号化モジュール（ＤＭ）とを含むＵＩＣＣを備える、請求項１０に記載のＧＢＡ対応ユーザ機器。
【請求項１２】
前記ＵＩＣＣはさらに前記算出モジュール（ＣＡＭ）を備える、請求項１１に記載のＧＢＡ対応ユーザ機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、２つのユーザ機器間でセキュアな音声通信セッションを確立する方法に係る。本発明において「ユーザ」とは、あるモバイルネットワークサービス（ＭＮＯ）への加入者を意味する。より詳細には、本発明は、汎用ブートストラッピングアーキテクチャにおけるそのようなセキュアな音声通信の実施に関する。
【０００２】
また、本発明は、ネットワークアプリケーション機能（ＮＡＦ）と、本発明の方法のステップを実施することのできるＧＢＡ対応のユーザ機器とにも関する。
【背景技術】
【０００３】
携帯電話において、汎用ブートストラッピングアーキテクチャ（ＧＢＡ）は、３ＧＰＰユーザ認証によりユーザ機器と任意のアプリケーションサーバとの間の共有鍵の確立を可能にする１つの技術である。この３ＧＰＰユーザ認証は、ユーザがホームロケーションレジスタ（ＨＬＲ）又はホーム加入者サーバ（ＨＳＳ）上に有効なアイデンティティを所有している場合に可能である。
【０００４】
ＧＢＡは３ＧＰＰで標準化されている。３ＧＰＰ  ＴＳ  ３３．２２０は汎用ブートストラッピングアーキテクチャ（ＧＢＡ）の仕様を定めており、これは、ブートストラッピングサーバ機能（ＢＳＦ）とやり取りすることによって、ユーザ機器（ＵＥ）とネットワークアプリケーション機能サーバ（ＮＡＦ）とが秘密を共有することを可能にするものである。ユーザ認証は、ユーザの携帯機器の内部のスマートカードとＨＬＲ／ＨＳＳ上との間の共有秘密によりインスタンス化される。
【０００５】
ＧＢＡブートストラッピングは、ネットワークコンポーネントチャレンジをユーザのカードに送信し、その応答がＨＬＲ／ＨＳＳによって予測されたものと類似であることを検証することによって、ユーザを認証する。
【０００６】
このアーキテクチャは、特定のサービスへのアクセスを必要とするユーザ機器（ＵＥ）、すなわちスマートカード（ＵＩＣＣ）を含む携帯機器（ＭＥ、例えば携帯セルラ電話）と、サービスを提供する例えば携帯テレビ用のアプリケーションサーバ（ＮＡＦ：ネットワークアプリケーション機能）と、ＨＳＳとの接続によりＵＥとＮＡＦとの間のセキュリティ関係を整えるブートストラッピングサーバ機能（ＢＳＦ）と、ユーザプロファイルをホストするモバイルネットワークオペレータのホーム加入者サーバ（ＨＳＳ）とを備える。
【０００７】
「ブートストラッピング」という用語は、まずこれまで未知であったデバイスとのセキュリティ関係を構築し、後でそのデバイス及びＢＳＦにセキュリティ要素（鍵）をインストールすることを可能にすることに関する。
【０００８】
したがって、鍵確立要求ごとにＨＬＲ又はＨＳＳに依存するようサービスプロバイダＮＡＦに求める代わりに、ＢＳＦがユーザのカードとサービスプロバイダのＮＡＦとの間の共有秘密を確立する。この共有秘密は、期間を限定されるとともに特定のドメインに限られる。
【０００９】
ＧＡＡ／ＧＢＡ手順を経て導出された秘密は、（ＭＥとＵＩＣＣとからなる）ＵＥとＮＡＦとの間のさらなる通信に用いられ得る。１つの利点は、ユーザ登録段階も鍵のセキュアな展開も不要であるため、このソリューションはＰＫＩに比べて非常に低費用なものになっているということである。また、この認証方法は、ＨＴＴＰの「ダイジェストアクセス認証」に基づいているため、端末及びサービスプロバイダへの統合が容易である。あらゆるウェブサーバが既にＨＴＴＰダイジェスト認証を実装しているため、ダイジェスト認証に加えてＧＢＡを実装する労力は最小となる。
【００１０】
デバイス側では、ダイジェスト認証及びＨＴＴＰヘッダの「３ｇｐｐ」ストリングにより設計された特例を実装したＨＴＴＰクライアント（ウェブブラウザ）と、スマートカードと対話しＢＳＦにより送信されたチャレンジに署名する手段とが必要である。ＡＰＤＵを通じデバイスのベースバンドを介したスマートカードとの直接通信が利用される。そうでなければ、ＧＢＡは、２つ以上及びさらに少ない当事者間のいかなる通信にも適用されない。そのような音声通信は、ウェブ上で行われる場合、保護される必要があり、したがって、当該技術分野においては、ＧＢＡに関係するさらなる代替的及び有利なソリューションが望ましいであろう。
【００１１】
また、ＧＢＡベースのＵＩＣＣをＧＢＡ＿Ｕ  ＵＩＣＣと称する。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
本発明は、専用のインフラストラクチャの使用を要さずに音声通信を保護することを狙いとしている。
【課題を解決するための手段】
【００１３】
したがって、本発明は、専用のネットワークアプリケーション機能（ＮＡＦ）と少なくとも１つのブートストラッピングサーバ機能（ＢＳＦ）とを利用して２つのユーザ機器の間にセキュアな音声通信セッションを確立する方法を提案するものであり、この方法は、
第１のユーザ機器が第２のユーザ機器との通信の要求及びセキュリティアソシエーション要求を専用のネットワークアプリケーション機能に送信するステップと、
第１のユーザ機器が、
第１のユーザ機器が第１のブートストラッピングサーバ機能ＢＳＦ１とのリンクを確立することと、
ＢＳＦ１がチャレンジを第１のユーザ機器に送信することと、
第１のユーザ機器がＢＳＦ１により送信されたチャレンジに応答することと、
ＢＳＦ１がチャレンジ応答を検証することと、
を備えたチャレンジ手順に進むステップと、
ＮＡＦがブートストラッピングサービス導出ＮＡＦ鍵をＢＳＦ１から検索するステップと、
第２のユーザ機器が第１のユーザ機器との通信要求を受信するステップと、
第２のユーザ機器がセキュリティアソシエーション要求を専用のネットワークアプリケーション機能に送信するステップと、
第２のユーザ機器が、
第２のユーザ機器が第２のブートストラッピングサーバ機能ＢＳＦ２とのリンクを確立することと、
ＢＳＦ２がチャレンジを第２のユーザ機器に送信することと、
第２のユーザ機器がＢＳＦ２により送信されたチャレンジに応答することと、
ＢＳＦ２がチャレンジ応答を検証することと、
を備えたチャレンジ手順に進むステップと、
ＮＡＦがブートストラッピングサービス導出ＮＡＦ鍵をＢＳＦ２から検索するステップと、
を備え、
この方法はさらに、
第１及び第２のユーザ機器のブートストラッピングサービス導出ＮＡＦ鍵からセッション鍵を算出するステップと、
算出されたセッション鍵を用いて保護された音声通信を確立するステップと、
を備える。
【００１４】
音声通信の両側の各ユーザのＧＢＡ認証を用いると同時に、本発明は、セキュリティ機能のさらなる実装を必要とすることなく、セキュアな音声通信をＧＢＡアーキテクチャに基づかせることを可能にする。本発明はＮＡＦの能力の拡張を伴い、これはＧＢＡインフラストラクチャに基づいている。また結局のところ、ＧＢＡ対応のＵＩＣＣの機能も高められる。本発明によれば、モバイルネットワークオペレータは、当該技術分野において展開されているＵＩＣＣを改良することを要さずに、ＧＢＡインフラストラクチャを活用したセキュリティ関係のサービスを提供することができる。ユーザ機器の数は本発明の範囲内に留まったままで増加され得ることに注意されたい。用いられる鍵素材は、３ＧＰＰ  ＴＳ  ３３．２２０又はＴＳ  ３３．１１０において定義されているものである。
【００１５】
基本的に、ＮＡＦは各ユーザについて以下の鍵素材を有している。：ＲＡＮＤ，Ｂ−ＴＩＤ，Ｋｓ＿ｅｘｔ＿ＮＡＦ，Ｋｓ＿ｉｎｔ＿ＮＡＦ，鍵の有効期間、ＵＩＣＣの種類などといった他の属性。
【００１６】
第１の実施形態によれば、前述のセッション鍵を算出するステップは、さらにセッション鍵を各ＮＡＦ鍵で暗号化して両機器へと送信するＮＡＦによって実行される。
【００１７】
この実施形態はＵＩＣＣがＧＢＡ＿Ｕでないどんな構成にも適合される。
【００１８】
有利なことには、ＧＢＡ＿Ｕ対応のＵＩＣＣを備えたユーザ機器が少なくとも１つ存在している場合には、このユーザ機器は内部ＮＡＦ鍵を使用してＮＡＦによるセッション鍵の暗号化を行う。
【００１９】
これは、セッション鍵がＵＩＣＣ自体において復号化されること、ならびにセキュリティを強化することを可能にする。
【００２０】
第２の実施形態によれば、この方法は、セッション鍵を算出するために用いられるデータを含む２つのメッセージをＮＡＦにより生成するステップであって各メッセージが所与の機器のために該所与の機器自体のＮＡＦ鍵で暗号化された他方の機器の少なくとも１つのＮＡＦ鍵を含んでいるステップと、暗号化されたメッセージを両機器に送信するステップと、各機器が暗号化されたメッセージを復号化するステップと、自身の導出ＮＡＦ鍵と受信したメッセージ内の他方のユーザ機器のＮＡＦ鍵とからセッション鍵を算出するステップと、を備える。
【００２１】
外部ＮＡＦ鍵は転送可能であり、暗号化には外部又は内部ＮＡＦ鍵が用いられ得る。両算出は同じ入力を有することを要する。一方が第１のユーザ機器用、他方が第２の機器用の同じ対のＮＡＦ鍵が算出の両側で知られていなければならない。したがって、メッセージは、セッション鍵の算出に関して相補的なＮＡＦ鍵を含む。そのような鍵素材（例えばＵｓｅｒ＿Ｐａｒａｍ，Ｋｓ＿ＮＡＦ，他の属性）がＮＡＦからＵａセキュアトンネルを経由して各ユーザ機器へと送信される。
【００２２】
好適には、転送されるＮＡＦ鍵は外部ＮＡＦ鍵である。
【００２３】
実際のところ、ＧＢＡ標準は現在、内部ＮＡＦ鍵の転送には利用できない。なぜなら、ＧＢＡの原理によれば、セキュリティの理由から、内部ＮＡＦ鍵は決してユーザ機器のＵＩＣＣを離れてはならず、別のユーザ機器と共有されてはならないためである。この特徴により、携帯機器とＮＡＦとの間で交換されるメッセージが携帯機器のＫｓ＿ｅｘｔ＿ＮＡＦで暗号化されている場合には、携帯機器のユーザは、別のユーザのＫｓ＿ｅｘｔ＿ＮＡＦのみを見ることができ、内部ＮＡＦ鍵は見ることができない。よって、理論上では、ユーザは他方のユーザのＫｓ＿ｅｘｔ＿ＮＡＦを観察及び検索することが可能である。そして、そのユーザは後で、例えば別のユーザになりすますために、そのような取得した鍵を不正に使用し得る。したがって、このソリューションは完全にセキュアではない。
【００２４】
好適な特徴によれば、少なくとも一方のユーザ機器はＧＢＡ＿Ｕ対応のＵＩＣＣを備え、このユーザ機器はこのユーザ機器の内部ＮＡＦ鍵を用いて他方の機器のＮＡＦ鍵の暗号化を行う。
【００２５】
これにより、ＧＢＡ対応のＵＩＣＣを有する携帯機器が他方のユーザ機器の鍵素材を知ることが回避される。他方の機器の内部ＮＡＦ鍵は、事実上、ＮＡＦによってのみ、且つ携帯機器の内部のＵＩＣＣからのみ知られる。好適には、両方の機器がこの状態にある。したがって、各ＵＩＣＣの内部ＮＡＦ鍵の他方への送信が回避され得る。この暗号化手順は、悪意のあるユーザが後で不正なアクションに使用することができるように途中で通信を傍受したり他のユーザの鍵を集めたりしようとするのを防止する。ＧＢＡ＿Ｕ非対応のＵＩＣＣがＧＢＡ＿Ｕ対応以外の何らかの手段によって鍵を導出することができる場合には、そのような特徴が実装可能であることに注意されたい。
【００２６】
有利な特徴によれば、ＵＩＣＣはセッション鍵を算出する算出モジュールをさらに備え、セッション鍵はＵＩＣＣの内部で算出される。
【００２７】
これはＧＢＡ＿Ｕ対応のＵＩＣＣの使用を暗示している。ここで、ユーザは、ＭＥとＵＩＣＣとの間の通信を監視することによって、理論上はすべての鍵を算出できることに注意しなければならない。したがって、この有利な実施形態において述べられているように、ＭＥではなくＵＩＣＣにセッション鍵を計算させることを強く勧める。
【００２８】
特定の特徴によれば、第１及び第２のＢＳＦは同じＢＳＦであり、ＮＡＦ鍵又はセッション鍵はこのＢＳＦにより算出され、ＮＡＦによって検索され、各ＮＡＦ鍵で暗号化されてユーザ機器に送信される。
【００２９】
この特徴は、セッション鍵の算出をＢＳＦの内部に集中させる。これはＭＮＯにとって好適であり得、あるいはＭＮＯにより要求され得る。
【００３０】
また、本発明は、
ユーザ機器から別のユーザ機器との通信の要求を受信する受信機と、
２つのユーザ機器のためにブートストラッピングサービス導出鍵Ｋｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦを少なくとも１つのＢＳＦから検索する検索装置と、
セッション鍵を算出するか、又はブートストラッピングサービス導出ＮＡＦ鍵Ｋｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦ１及びＫｓ＿（ｅｘｔ／ｉｎｔ）＿ＮＡＦ２からメッセージを生成する算出モジュールと、
セッション鍵又はメッセージを各ユーザ機器のＮＡＦ鍵を用いて暗号化する暗号化モジュールと、
暗号化されたセッション鍵を送信するか、又は各ユーザ機器が共通のセッション鍵を算出することを可能にするセッション鍵を構築するために生成されたメッセージを送信する送信機と、
を備える、ネットワークアプリケーション機能（ＮＡＦ）サーバにも関する。
【００３１】
また、本発明は、
ＢＳＦから受信したチャレンジに応答するチャレンジ処理モジュールと、
鍵導出モジュールと、
少なくとも：
別のユーザ機器との通信の要求を送信する送信機と、
別のユーザ機器からの通信の要求を受信するとともに、セッション鍵を構築するためのメッセージを受信するか、又は暗号化されたセッション鍵を受信する受信機と、
前述のセッション鍵を用いて別の機器との通信を確立する音声通信モジュールと、を備えた通信モジュールと、
セッション鍵を構築するためのメッセージ又はセッション鍵を復号化する復号化モジュールと、
セッション鍵を構築するためのメッセージが受信された場合に、そのメッセージからセッション鍵を算出する算出モジュールと、
を備える、ＧＢＡ対応のユーザ機器にも関する。
【００３２】
有利なことには、そのようなＧＢＡ対応のユーザ機器は、前述のチャレンジ処理モジュールと、前述の鍵導出モジュールと、前述の復号化モジュールとを含むＵＩＣＣを備えている。
【００３３】
そのようなユーザ機器は、本発明の好適な実施形態のうちいくつかを実装することができ、ここで、セッション鍵を構築するためのメッセージ又はセッション鍵それ自体の復号化は、ＵＩＣＣの内部で実現される。
【００３４】
好適には、前述のＵＩＣＣはさらに前述の算出モジュールを備える。
【００３５】
そのようなユーザ機器は本発明の好適な実施形態及びオプションを実装することができ、ここで、セッション鍵はＵＩＣＣの内部で算出され、最も強固なセキュリティを保証する。
【００３６】
本発明によれば、ユーザ間通信のための真のエンドツーエンドセキュリティを、当該技術分野において展開されているＵＩＣＣの物理的な置換を要することなく、達成することができる。この機構は汎用的なものであり、いかなる種類のユーザ間のセキュアな通信にも適用することができる。
【００３７】
以上の及び関連する目的を達成するため、１つ以上の実施形態は、以下に詳述し特許請求の範囲において特に指摘する特徴を備える。
【図面の簡単な説明】
【００３８】
以下の記載及び添付の図面は、ある実例的な態様を詳細に説明するものであって、実施形態の原理が用いられ得る様々なやり方のうちほんのいくつかを示している。他の有利で新規な特徴は、以下の詳細な説明を図面と併せて検討すれば明らかになるであろう。また、開示される実施形態は、そのような態様及びその均等物をすべて包含することが意図されている。
【００３９】
【図１】本発明が実装される環境を表す図。
【図２】本発明の方法の一実施形態の概略図。
【図３】本発明の別の実施形態の概略図。
【図４】本発明が有利に実装されるユーザ機器の概略図。
【図５】図４に示すユーザ機器において有利に実装されるＧＢＡ対応のＵＩＣＣ（ＧＢＡ＿Ｕ  ＵＩＣＣ）の概略図。
【発明を実施するための形態】
【００４０】
発明の実施形態の詳細な説明
以下の詳細な説明においては、本発明が実施され得る特定の実施形態を例示的に示す添付の図面を参照する。これらの実施形態は、当業者が本発明を実施できる程度に十分詳細に説明される。本発明の様々な実施形態は、異なってはいても、必ずしも相互排他的ではないことが理解されるべきである。例えば、本明細書においてある実施形態に関連して説明されている特定の特性、構造、又は特徴は、本発明の理念及び範囲を逸脱することなく、他の実施形態において実装されてもよい。図面において、同一の番号は、いくつかの図を通じて同じ又は類似の機能を参照する。明確にするため、本発明の理解に有用な要素及びステップのみを図面に示し、説明することとする。
【００４１】
また、あるアクションがデバイスにより実行されるというときには、それは実際には、そのデバイス上のプログラムメモリに記録された命令コードによって制御されたそのデバイス内のマイクロプロセッサにより実行される。また、アクションはアプリケーションに帰属する。これは、そのアプリケーションを構成する命令コードの一部がマイクロプロセッサにより実行されることを意味する。
【００４２】
図１は、本発明が適用され得るＧＢＡ環境を示す。これは、第１のインタフェースＵａを通じてネットワークアプリケーション機能ＮＡＦと接続されるとともに第２のインタフェースＵｂを通じてブートストラッピングサーバ機能ＢＳＦと接続された、少なくとも１つのユーザ機器ＵＥを備える。両機能ＮＡＦ及びＢＳＦは、インタフェースＺｎを通じて互いに接続されている。
【００４３】
ＢＳＦはさらに、インタフェースＺｈを通じて少なくとも１つのホーム加入者サーバＨＳＳと接続されている。有利なことには、ＢＳＦは、インタフェースＤｚを通じて加入者ロケータ機能ＳＬＦとも接続されている。汎用ブートストラッピングアーキテクチャ標準においては異なる機能及びインタフェースの名前が標準化されている。
【００４４】
図２は、セッション鍵がＮＡＦによって算出される、本発明の一実施形態を概略的に示す。同図において、第１のユーザ機器ＵＥ１は、ＧＢＡ対応の集積回路ＵＩＣＣ１を備える。そのような集積回路ＵＩＣＣ１は、典型的には携帯機器ＭＥ１の内部に導入されたスマートカードであり、また、ＧＢＡ対応である。この携帯機器ＭＥ１は、有利にはスマートフォンであるが、コンピュータでもあり得る。しかしながら、必ずＧＢＡ対応でなければならない。
【００４５】
本発明は、ユーザ機器ＵＥ１のユーザが第２のユーザ機器ＵＥ２を有する別のユーザとのセキュアな音声通信の確立を要求するときに、これを調停する。したがって、ＵＥ１は、典型的には例えば基礎となるＩＰマルチメディアサブシステム（ＩＭＳ）を介して、通信の要求ＲＥＱ（ＩＤ１，ＩＤ２）を第２のユーザ機器ＵＥ２に送信する。この通信の要求ＲＥＱ（ＩＤ１，ＩＤ２）は、２つのユーザ機器の識別子ＩＤ１及びＩＤ２を含む。
【００４６】
これと並行して、ＵＥ１は、この音声通信のセキュリティアソシエーション要求ＲＥＱ（ＩＤ１，ＩＤ２，ＳＥＣ）を専用のネットワークアプリケーション機能ＮＡＦに送信する。これはブートストラッピングサーバ機能ＢＳＦ１とのリンクの確立をトリガする。このＢＳＦ１は、例えばＵＥ１のモバイルネットワークオペレータの１つである。利用可能な有効なブートストラップされた鍵ＫｓがＵＥ１にない場合には、ＵＥ１とＢＳＦ１との間で、波括弧ＣＨ１（ＮＡＦ）で表された初期ブートストラッピング手順が開始される。一般的にはチャレンジがユーザ機器ＵＥ１に送信され、該機器は引き換えに応答を行う。したがって、セキュリティ全体が、一方の加入者の認証に用いられるＭＮＯの信用情報に基づいている。図２に見られるように、ＵＩＣＣ１はチャレンジ応答の算出に関わっている。チャレンジ応答がＢＳＦ１に送り返されＢＳＦ１により検証もされると、ブートストラップされた鍵Ｋｓ１を取得するためのブートストラップされた鍵の導出手順へと進む。
【００４７】
ＵＥ１からの要求ＲＥＱ（ＩＤ１，ＩＤ２，ＳＥＣ）を受けて、ＮＡＦは、ＵＥ１に関連するＮＡＦ鍵を検索するために、ＢＳＦ１に要求を送信する。ここで、ＵＥ１はＧＢＡ対応のＵＩＣＣ１を備えているため、２つのＮＡＦ鍵が取得される。１つは外部のＫｓ＿ｅｘｔ＿ＮＡＦ１、もう１つは内部のＫｓ＿ｉｎｔ＿ＮＡＦ１である。これらの鍵は次いでＢＳＦ１によりＮＡＦに送信される。
【００４８】
ＵＥ１が関与する手順と並行して、通信要求ＲＥＱ（ＩＤ１，ＩＤ２）を受信した他方のユーザ機器ＵＥ２は、セキュリティアソシエーション要求ＲＥＱ（ＩＤ１，ＩＤ２，ＳＥＣ）をＮＡＦに送信する。利用可能な有効なブートストラップされた鍵がＵＥ２にない場合には、これがＵＥ２と第２のＢＳＦ２との間での初期ブートストラッピング手順を開始する。これは、ＵＩＣＣ２が、ＧＢＡ対応でない場合であっても、ＧＢＡ要件に従って関与していることを暗示している。前述の手順は、波括弧ＣＨ２（ＮＡＦ）によって表されている。実際には、例えば２つのユーザ機器によって同じＭＮＯが使用される場合には、２つのＢＳＦは同一であってもよいが、一般的にはこれらは異なるものである。
【００４９】
ここで、図２に示す例においては、第２のＵＥ２は、それ自体ＧＢＡ対応の携帯機器ＭＥ２と、ＧＢＡ対応でないＵＩＣＣとで構成されていることに注意しなければならない。
【００５０】
手順ＣＨ２（ＮＡＦ）が終了すると、ＢＳＦは、ブートストラップされた鍵Ｋｓ２からの関係するＮＡＦの鍵の導出に進む。ここでは単一のＫｓ＿ＮＡＦ２が取得される。この鍵は、（前記携帯機器ＭＥ２に属する）外部型のものであり、次いでＮＡＦに転送される。
【００５１】
図２に示す実施形態においては、ＮＡＦは次に、ステップＣＡＬ（Ｋｓ＿ＳＶ）において、セキュアな音声通信のためのセッション鍵Ｋｓ＿ＳＶを算出している。
【００５２】
次に、セッション鍵Ｋｓ＿ＳＶは、受信側ＵＥ１又はＵＥ２に応じて異なって暗号化される。その場合、同一のＢＳＦが両方のユーザ機器にとってアクセス可能であり、セッション鍵の算出はそのＢＳＦにおいて行われてもよい。
【００５３】
例えば、Ｋｓ＿ＳＶ＝ＫＤＦ（Ｋｓ＿ｉｎｔ＿ＮＡＦ＿１，Ｋｓ＿ｉｎｔ＿ＮＡＦ＿２，Ｕｓｅｒ＿Ｐａｒａｍ＿１，Ｕｓｅｒ＿Ｐａｒａｍ＿２，・・・）
【００５４】
Ｕｓｅｒ＿Ｐａｒａｍは、ＲＡＮＤ，Ｂ−ＴＩＤ，及び各ユーザのＫｓ＿ｉｎｔ＿ＮＡＦに関連する他の属性であってもよい。
【００５５】
また、外部ＮＡＦ鍵も用いられ得る。
【００５６】
Ｋｓ＿ｅｘｔ＿ＮＡＦ１で暗号化されたセッション鍵（Ｋｓ＿ＳＶ）Ｋｓ＿ｅｘｔ＿ＮＡＦ１はＵＥ１に送信され、Ｋｓ＿ＮＡＦ２で暗号化された（Ｋｓ＿ＳＶ）Ｋｓ＿ＮＡＦ２はＵＥ２に送信される。その後、セッション鍵は両側で、携帯機器ＭＥ１及びＭＥ２により、それぞれＫｓ＿ｅｘｔ＿ＮＡＦ１及びＫｓ＿ＮＡＦ２を用いて復号化されるＤＥＣＫｓ＿ｅｘｔ＿ＮＡＦ１（Ｋｓ＿ＳＶ），ＤＥＣＫｓ＿ＮＡＦ２（Ｋｓ＿ＳＶ）。すると、２つのユーザ機器ＵＥ１とＵＥ２との間で共通のセッション鍵Ｋｓ＿ＳＶを用いて通信ＳＶを行うことができる。
【００５７】
やはり図２に示すように、ＯＲの後、一変形においては、セッション鍵Ｋｓ＿ＳＶが内部ＮＡＦ鍵Ｋｓ＿ｉｎｔ＿ＮＡＦ１を用いて暗号化されてもよい。この場合、復号化ＤＥＣＫｓ＿ｉｎｔ＿ＮＡＦ１（Ｋｓ＿ＳＶ）は携帯機器ＵＥ１側のＵＩＣＣ１の内部で行われ、次いでセッション鍵がセキュアな音声通信ＳＶでの使用のために携帯機器ＭＥ１へと内部転送される。起こり得るセキュリティ攻撃を克服するためには、ＭＥとＵＩＣＣとの間でＥＴＳＩ  ＴＳ  １０２  ４８４のセキュアなチャネルを用いるのが好適であろう。ＥＴＳＩ  ＴＳ  １０２  ４８４のセキュアなチャネルが用いられるとき、システム全体のセキュリティを強化するために、１つの追加的な制御がＵＩＣＣ側で実装されてもよい。この制御は、以下の条件が満たされた場合にのみ、ＧＢＡ機能性へのアクセスを可能にするものである。：
（１）ＧＢＡ機能性へのアクセスがセキュアなチャネルを通じて行われる。
（２）外部のアプリケーションがＧＢＡ機能にアクセスする権利を有する。
【００５８】
このような制御が存在しない場合には、攻撃者が、ＭＥにセキュアなチャネルを設定させないことによって、セキュアなチャネルの外部で交換された鍵を検索しようとする状況が発生し得る。
【００５９】
図３は本発明の別の実施形態を示しており、ここではセッション鍵が、ＮＡＦにより生成及び送信されたメッセージを用いて、両ユーザ機器ＵＥ１及びＵＥ２の各々によって局所的に算出される。
【００６０】
この方法の初めは図２に示したものと同一である。初期のブートストラッピング手順が２つのユーザ機器によって両側で実装される。
【００６１】
ＮＡＦは、Ｋｓ＿ＮＡＦ２及びＫｓ＿ｉｎｔ＿ＮＡＦ１，Ｋｓ＿ｅｘｔ＿ＮＡＦ１を受信すると、ステップＧＥＮ（ＭＳＧ１，ＭＳＧ２）において、それぞれが機器ＵＥ１及びＵＥ２の各々に送信されることを意図された２つの暗号化されたメッセージＭＳＧ１及びＭＳＧ２を生成する。
【００６２】
ステップＳＤ（ＭＳＧ２）においてＵＥ２に送信されることが意図されたメッセージＭＳＧ２は、少なくとも、ＭＥ２のＮＡＦ鍵で暗号化されたＭＥ１の外部ＮＡＦ鍵を含む。したがって、ＵＩＣＣ１の内部ＮＡＦ鍵はＮＡＦの内部に保持され、いかなる漏洩にも脅かされない。メッセージはさらに、識別子及び他のデータ、例えばセッション鍵の導出に用いられ得る乱数を含んでいてもよい。
【００６３】
第１のオプションでは、ステップＳＤ（ＭＳＧ１）においてＵＥ１に送信されることが意図されたメッセージＭＳＧ１は、少なくとも、ＭＥ１の外部ＮＡＦ鍵で暗号化されたＭＥ２のＮＡＦ鍵を含む。このオプションは、セッション鍵Ｋｓ＿ＳＶがステップＣＡＬにおいて、ＵＥ２において実装されるものと類似の手法で、携帯機器ＭＥ１で算出される場合に対応する。これは、ＭＥ１の外部ＮＡＦ鍵を用いた暗号化されたメッセージＭＳＧ１の復号化ＤＥＣの後にある。
【００６４】
図３の第１のＯＲの後に示される第２のオプションでは、携帯機器ＭＥ２のＮＡＦ鍵が、ユーザ機器ＵＥ１の内部ＮＡＦ鍵を用いて暗号化される。これは、暗号化されたメッセージＭＳＧ１がＵＩＣＣ１においてＫｓ＿ｉｎｔ＿ＮＡＦ１によって復号化されることを暗示している。次に、セッション鍵Ｋｓ＿ＳＶの算出が、ＵＩＣＣ１による復号化されたＫｓ＿ＮＡＦ２の携帯機器ＭＥ１への転送の後で、あるいは、必要なリソースがＵＩＣＣ１において利用可能であれば直接ＵＩＣＣ１の内部で、図示するように第２のＯＲの後で、行われてもよい。
【００６５】
ここで、この実施形態については後者のオプションが最もセキュアであることが理解される。なぜなら、ユーザ機器の外部ＮＡＦ鍵のみがセキュアに転送され、セッション鍵を取得するためのすべての計算がＵＩＣＣ１の内部で行われるためである。
【００６６】
ここで強調されるのは、ユーザ機器ＵＥ２もＧＢＡ対応の集積回路カードＵＩＣＣ２を有していたとすると、このオプションは両機器に適用可能であると考えられ、得られる方法は、両外部ＮＡＦ鍵Ｋｓ＿ｅｘｔ＿ＮＡＦ１及びＫｓ＿ｅｘｔ＿ＮＡＦ２のみがそれぞれ内部鍵Ｋｓ＿ｉｎｔ＿ＮＡＦ２及びＫｓ＿ｉｎｔ＿ＮＡＦ１で暗号化されて転送されるであろうから、完全にセキュアであろうということである。ＭＳＧ１及びＭＳＧ２の復号化ならびにセッション鍵Ｋｓ＿ＳＶの算出は、各ＵＩＣＣにおいて、それらを管理する各携帯機器ＭＥ１及びＭＥ２に転送される前に行われ、得られたセッション鍵Ｋｓ＿ＳＶを用いて音声通信が確立されるであろう。ここで、セッション鍵の構築を可能にするメッセージにより伝達された属性を用いて、微調整された利用制御が可能である。換言すれば、ＵＩＣＣは所定のセキュリティポリシーに従ってチェックを行うことができる。例えば、ＵＩＣＣの種類は、相手方が正しく構成されたＵＩＣＣを有するかどうかをチェックするために利用することができ、もし有さないのであれば鍵導出要求を拒否する。
【００６７】
図４は、本発明が実装されるユーザ機器ＵＥを概略的に示す。ＵＥは、携帯機器ＭＥ、典型的には携帯電話と、集積回路カードＵＩＣＣと、少なくとも：
別のユーザ機器との通信の要求を送信するよう適合された送信機と、
別のユーザ機器からの通信の要求を受信するとともに、セッション鍵の算出を可能にする暗号化されたメッセージを受信するか、又は暗号化されたセッション鍵を直接受信するよう適合された受信機と、
前述のセッション鍵を用いて別の機器との通信を確立する音声通信モジュールと、を含む通信手段ＣＭと、を備える。
【００６８】
そのような通信手段は、当業者であれば、有利には無線インタフェース、又は有線インタフェースに基づき得るそのような手段を実装することができるであろうから、これ以上開示しない。ＧＢＡシステムにおいては、ＵＩＣＣは配布されるセキュリティトークンを構成するため、ＵＩＣＣの役割は重要である。
【００６９】
図５は、図４のユーザ機器の内部に実装されたＧＢＡ対応の集積回路カードＵＩＣＣ１を概略的に示す。このＵＩＣＣ１は、ＢＳＦから受信したチャレンジに応答するチャレンジ処理モジュールＣＰＭと、鍵導出モジュールＫＤＭと、セッション鍵を算出するためのデータを含むかあるいはセッション鍵を直接的に含むメッセージを復号化する復号化モジュールＤＭと、を備える。セッション鍵を算出するためのデータを含む暗号化されたメッセージが受信される場合には、有利には、復号化されたメッセージからセッション鍵を算出する算出モジュールＣＡＭがさらに備えられる。ＵＩＣＣ１はここでは分割されたエンティティとして説明されているが、そのようなエンティティはＵＩＣＣの内部に実装された単なる機能性であってもよいことに注意しなければならない。
【００７０】
以上の詳細な説明は限定的な意味で理解されるべきものではなく、本発明の範囲は添付の特許請求の範囲によってのみ定義され、特許請求の範囲の均等物の全範囲とともに、適切に解釈されるものである。
【図１】
2016519873.tif 000003
【図２】
2016519873.tif 000004
【図３】
2016519873.tif 000005
【図４】
2016519873.tif 000006
【図５】
2016519873.tif 000007
【国際調査報告】
2016519873.tif 000008
2016519873.tif 000009