JP5980253B2 - ネットワークにおける望ましくないサービス要求の管理 - Google Patents

Description

本発明は、ネットワークにおける望ましくないサービス要求の管理に関し、特に、ネットワークにおける望ましくないサービス要求を管理する方法およびシステム、そのようなシステムにおいて使用するためのユーザ認証機能および端末、および、該方法を実行するためのコンピュータプログラム製品に関するが、それらには限られない。

新世代のモバイル装置、例えばスマートフォンは、オープンなネットワーク接続によって、拡張されたコンピュータ機能を提供する。そのようなモバイル装置は、例えば、ｅメールを受信すること、短距離接続を介して互いにソフトウェアを共有すること、インターネットからソフトウェアをダウンロードして実行すること、自動化された呼を生成すること、および遠隔操作の下で動作することが可能である。したがって、パーソナルコンピュータと同様に、モバイル装置および、モバイル装置とネットワークの間の接続の設定に関わる特にソフトウェア構成要素は、悪意のあるコード（マルウェア）の攻撃を受けやすい。典型的にはマルウェアはモバイル装置を悪用しようとするか、単にモバイル装置の正当な使用を妨害する。場合によってはモバイル装置に存在するチップカード、例えば（Ｕ）ＳＩＭは、この脆弱性に対する保護を提供しない。

マルウェアの１つのタイプはダイヤラ（ｄｉａｌｅｒ）と呼ばれる。ダイヤラは感染したモバイル装置上で不正に呼をセットアップすることが可能な悪意のある一連のコードである。そのようなダイヤラはモバイル装置の（Ｕ）ＳＩＭからの認証情報をしばしば使用して、あたかも接続がモバイルのユーザによって正当にセットアップされたかのように、ネットワークへのアクセスを達成する。認証過程の後で、ダイヤラは例えば高価なプレミアム番号−感染したモバイル装置のユーザにはそれとわからないことがしばしばある−への呼のセットアップを開始し、それはモバイルのユーザおよびモバイルのオペレータの両方にとって、実質的に金銭的な危険につながる。

そのようなマルウェアの望ましくない影響を除去するか少なくとも低減させるための手段をとることができる。１つの知られている手段はネットワーク内にフィルタを導入することである。そのようなフィルタは特許文献１および特許文献２に記載される。基地局にあるフィルタはモバイル装置から送信された呼を監視し、ブラックリストに挙げられた呼を阻止する。ネットワークオペレータおよび／またはモバイルのユーザはブラックリストに、フィルタによって明確に排除されるべきサービス要求を追加することができる。

そのようなフィルタの使用に関連する１つの問題は、排除されたサービス要求のリストの管理である。オペレータ側には３つの問題がある。第１に、すべての望ましくないサービス要求を阻止するためには、必要なブラックリストの大きさが非常に大きくなり、ほとんど管理不可能になりうることである。第２の問題は、ブラックリストを最新のものに保つために、悪意のあるサービスの絶え間ない探索が必要なことである。第３の問題は、疑わしい要求の識別には、モバイル装置の個別のユーザそれぞれのサービス要求の分析を必要とすることである。そのような分析は、したがって、ネットワークのかなりのリソースを必要とする。モバイルのユーザ側では、モバイル装置の望ましくないサービス要求は通常はユーザに気づかれず、課金の後、すなわち、被害がすでに現実のものとなった後にのみ気が付く、ということに１つの問題がある。ユーザにとっての他の問題は、オペレータが、ユーザが本当に使用を望むサービスをブラックリストに加えることから発生しうる。

特許文献３は、ＩＭ（インスタントメッセージ）アプリケーション内部のＵＲＬ（ユニフォームリソースロケータ）をフィルタリングする方法を開示する。ＩＭメッセージがＵＲＬを含む場合には、このＵＲＬが、知られている悪意のあるＵＲＬのブラックリストと突き合わせられる。ＵＲＬがブラックリストにない場合は、送信元には、送信元が実際のユーザでありプログラム（マルウェア）ではないことを確認するために課題が提示される。この方法は、悪意のあるＵＲＬを含むＩＭメッセージを受信することから受取先を保護する。さらに、システムは、知られている悪意のないＵＲＬの「受け入れリスト」または「ホワイトリスト」を維持するように構成されることができる。この方法では、「ホワイトリスト」にあるＵＲＬを含むＩＭメッセージが、送信元に課題を出すことなく受取先に転送されうる。

この方法は、携帯電話の分野に応用される場合には、セキュリティの観点と顧客の観点の両方から望ましくない。通信の内容ではなく、通信の宛先、例えば呼またはテキストメッセージ（ＳＭＳ）のプレミアム番号が危険を形成するため、セキュリティの観点からは、特許文献３の方法は、目前の問題に何の解決法も提示しない。したがって、上記の方法は受取先を保護しようとするが送信元を保護しようとはしない。この方法はまた、ブラックリスト（あるいはホワイトリスト）にないＵＲＬを含むＩＭメッセージごとに送信者に課題が出されるため、送信者にとっては迷惑となる。送信者が（首尾よく）課題に答えた場合、ＵＲＬを含むＩＭメッセージは転送されるが、送信者の動作に基づいてホワイトリストが更新されることはない。このことは、送信者が同じＵＲＬに対して何度も課題を提示されることを意味する。

従来技術の問題点を要約する。
・すべての疑わしいサービスをブラックリストに入れなければならないため、ブラックリストのサイズが管理できなくなりうる。
・自動的にホワイトリストを構築することがない。
・マルウェア検出が特定のサービス上でのテストを含まない。
・新しい悪意のある送信先へのサービス要求の拒絶がない。したがって、ブラックリストを最新の状態に保つためにはネットワークオペレータまたはユーザの継続的な努力が必要である。
・ユーザは、同一のサービス要求を実行する際に何度も面倒な思いをする。
・ユーザが本当に使用を望むサービスを、ネットワークオペレータがブラックリストに入れる可能性がある。

国際公開第２００７／０４１１５７号 米国特許出願公開第２００５／００６０３９９号明細書 米国特許出願公開第２００８／０１９６０９９号明細書

したがって、当該技術においては、望ましくないサービス要求を効率的に管理して誤用を防ぐ簡単な方法が必要である。

従来技術において知られている欠点の少なくとも１つを低減または除去して、本発明の第１の特徴における、少なくとも１つの端末（モバイル通信装置）からネットワークに送信された望ましくないサービス要求を管理する方法およびシステムを提供することが、本発明の目的である。ネットワークは信頼されるサービス情報を記憶するネットワークノードを有してもよい。方法は以下のステップの少なくとも１つを含むことができる。前記ネットワークが端末からのサービス要求を受信するステップであって、要求はサービス要求情報を含む、ステップ。および／または、サービス要求情報の少なくとも一部が、信頼されるサービス情報のリストにない場合、端末によって要求されたサービスを認証するようにユーザに要求するユーザ認証要求を、好ましくは安全な通信チャネルを介して送信するステップ。信頼されるサービス情報は、サービス（ＳＭＳ、ＭＭＳ、呼、インスタントメッセージ、動画など）のタイプの少なくとも１つと、要求されるサービスの送信先（例えばアドレス、電話番号）と、に関する情報を含み、該タイプおよび送信先の両方が受け入れられるか、または受け入れられないものがあるかである。本発明の実施形態では、リストに入れられた信頼されるサービス情報が、それに続く要求によって満たされ、可能であれば、信頼されるサービス情報を独立して満たすことによって補完される。本発明の別の実施形態では、信頼されるサービス情報を有するリストは、信頼されるサービス情報を独立して満たすことによって満たされる。ユーザは端末を効率的に用いるユーザであってもよく、端末に頼っているユーザであってもよく、サービス要求の認証を実行する権利を有するか、実行するよう指定されたユーザであってもよい。

本方法およびシステムは、提示されたサービス要求が正当な要求であるかどうかユーザへの認証を行うことによって、マルウェアによって生ずる被害を効率的に阻止する。この効果は、ネットワークにおいて受け入れられるサービスの信頼されるサービス情報（例えば、ホワイトリストの形式）を動的に維持し、サービスを受け入れる前に、サービスが信頼されるサービス情報に含まれていることについて、サービス要求ごとに認証を行うことによって達成される。サービスが含まれていない場合、ネットワークは安全な方法でユーザに、要求が確立されるべきものであるかどうかを認証するよう動的に要求するものとする。この方法によって、マルウェアに由来する要求がユーザによって認識されることができ、ユーザはそのようなサービスのセットアップを拒絶することができる。

一実施形態では、本方法はさらに、以下のステップの少なくとも１つを含む。好ましくは安全な通信チャネルを介して、ユーザ認証応答を受信するステップであって、前記応答はユーザによって提供される認証情報を含み、前記認証情報はユーザがサービス要求を受け入れるか拒絶するかを示す、ステップ。および／または、認証情報が、要求されたサービスが受け入れられる旨を提示する場合、信頼されるサービス情報に前記サービス要求情報の少なくとも一部を加えるステップ。したがって、ネットワークはサービス認証のためにユーザとのダイアログを自動的にセットアップする。サービスがユーザに受け入れられる場合は、信頼されるサービス情報が動的に更新される。

他の実施形態では、本方法はさらに、以下のステップの少なくとも１つを含んでもよい。好ましくは端末の識別モジュールに記憶された安全な鍵を用いて暗号化された通信チャネルを、前記端末と前記ネットワークの間で確立するステップ。前記暗号化された通信チャネルを介してユーザ認証要求を端末に送信するステップ。および／または、暗号化された通信チャネルを介してユーザ認証応答を受信するステップであって、前記応答は、ユーザによって提供された、ユーザがサービス要求を受け入れるか拒絶するかを示す認証情報を含むステップ。端末の識別モジュールに記憶されたプライベートキーを用いて暗号化された通信チャネルを用いて、ユーザダイアログが確立されてもよい。

さらなる実施形態では、端末は以下の要素の少なくとも１つを含んでもよい。識別モジュール、１つ以上の入力／出力インターフェイス、および／または、少なくとも１つの信頼されるハードウェア構成要素。前記信頼されるハードウェア構成要素は、前記信頼されるハードウェア構成要素と前記識別モジュールおよび／または前記１つ以上の入力／出力インターフェイスとの間に１つ以上の信頼される通信経路を確立するように構成されてもよい。端末内で１つ以上の信頼されるハードウェア構成要素を用いて、端末内の１つ以上の信頼される通信経路を得て、それによって、マルウェアが、ユーザとネットワークの間のユーザ認証ダイアログを妨害することを阻止してもよい。

一実施形態では、方法は以下のステップの少なくとも１つをさらに含んでもよい。前記ネットワークによってサービス要求が受信される通信チャネルとは異なる、さらなる通信チャネルを確立するステップ。安全なチャネルを介して端末に前記ユーザ認証要求を送信するステップ。および／または、前記さらなる通信チャネルを介してユーザ認証応答を受信するステップであって、前記応答は加入者がサービス要求を受け入れるか拒絶するかのいずれかを示す認証情報を含む、ステップ。さらに別の変形例では、前記さらなる通信チャネルはメッセージングサービス、好ましくはショートメッセージサービスまたはＵＳＳＤサービスによって提供されてもよい。

さらなる変形例では、認証要求は、ユーザが人間であるかそうでないかを判定するように構成されたテスト、好ましくは逆チューリングテスト（ｒｅｖｅｒｓｅ Ｔｕｒｉｎｇ ｔｅｓｔ）、より好ましくはＣａｐｔｃｈａを含んでもよい。認証応答はテストが成功したかそうでないかに関する情報を有する。

さらなる変形例では、ネットワークは少なくとも１つのサービス提供ネットワークノードを含んでもよい。前記サービス提供ネットワークノードは信頼されるサービス情報を含むビジティングロケーションレジスタ（ＶＬＲ）を有してもよい。前記ネットワークノードは、サービス要求情報の少なくとも一部が信頼されるサービス情報内のリストにない場合、端末からのサービス要求に応じて、端末へのユーザ認証要求を送信するためのユーザ認証機能を更に有してもよい。一変形例では、ネットワークはホームロケーションレジスタ（ＨＬＲ）を有してもよく、前記ホームロケーションレジスタは前記端末の信頼されるサービス情報を有する。方法は、前記ホームロケーションレジスタから前記ビジティングロケーションレジスタへ信頼されるサービス情報を送信するステップをさらに含んでもよい。ネットワークへの端末の登録の際、端末の役目を果たすサービス提供ネットワークノードのＶＬＲは、端末のホームネットワークのホームロケーションレジスタＨＬＲから信頼されるサービス情報を読み出してもよい。同様に、信頼されるサービス情報は、ＨＬＲにおいて、ユーザによって認証された信頼されるサービスを送信することによって更新され、ＶＬＲにおける信頼されるサービス情報に追加されてＨＬＲに戻されてもよい。

別の態様では、本発明は少なくとも１つの端末からネットワークに送信される望ましくないサービス要求を管理するためのシステムに関してもよい。システムは以下の特徴のうち少なくとも１つを含んでもよい。ネットワークと共に通信チャネルを確立する１つ以上の端末。前記端末の少なくとも１つからサービス要求情報を含むサービス要求を受信するように構成されたサービス提供ネットワークノード、および／または前記サービス提供ネットワークノードに接続された信頼されるサービスデータベース。前記サービス提供ネットワークノードは、サービス要求情報の少なくとも一部が信頼されるサービス情報のリストにない場合には、端末によって要求されたサービスを認証するようにユーザに要求するためのユーザ認証要求を、好ましくは安全な通信チャネルを介して、送信するように構成される。

さらなる態様において、本発明は上記のようなシステムにおいて使用するためのユーザ認証機能に関してもよい。ユーザ認証機能は、以下の特徴の少なくとも１つを有してもよい。端末からサービス要求を受信する手段であって、前記サービス要求はサービス要求情報を含む、手段。前記サービス要求情報の少なくとも一部が、信頼されるサービスデータベースに含まれるかどうかを確かめる手段。および／または、サービス要求情報の少なくとも一部が、信頼されるサービス情報のリストにない場合には、端末のユーザとネットワークの間の安全なダイアログを確立する手段。

さらなる態様において、本発明は上記のようなシステムにおいて使用するための端末に関してもよい。端末は以下の特徴の少なくとも１つを有してもよい。サービス提供ネットワークノードからのユーザ認証要求に応じて、端末のユーザとネットワークの間に安全なダイアログを確立するユーザ認証クライアント。前記ダイアログのために安全な通信チャネルを確立するプライベート鍵を提供する識別モジュール。前記ユーザからダイアログ情報を受けるための入力要素。前記ユーザへダイアログ情報を送るための出力要素。および／または、好ましくは信頼される計算基準を用いて、前記ユーザ認証クライアント、識別モジュール、入力要素、および／または出力要素の間に１つ以上の信頼される通信経路を確立する、信頼されるハードウェア構成要素。

本発明はまた、好ましくは１つ以上のネットワークノード内に位置する、コンピュータのメモリ内で実行される場合、上記のような方法発明のいずれかに基づく方法のステップを実施するように構成される、ソフトウェアコード部分を有するコンピュータプログラム製品に関してもよい。

本発明はさらに、本発明による実施形態を概略的に示す添付の図面を参照して記載される。本発明はこれらの特定の実施形態にいかなる意味でも制約されるものではないことが理解されるであろう。

本発明の一実施形態による通信システムを概略的に示す図である。 本発明の一実施形態による方法のフロー図である。 本発明の一実施形態による方法を含む使用のための端末の図である。

図１は本発明の一実施形態による通信システム１００の概略的な表示を示す図である。システムは通信ネットワーク１０４に接続された端末１０２を含んでもよい。一実施形態では、ネットワークは、アクセスノードとして作動するベーストランシーバ基地局（ＢＴＳ）１０６を含む２Ｇタイプ（例えばＧＳＭ）のモバイルネットワークであってもよい。ＢＴＳは、例えばビジティングネットワーク（ＶＮ）のモバイル切り換えセンタ（ＭＳＣ）１１０に、基地局コントローラ（ＢＳＣ）１０８を介して接続されてもよい。さらに、ＭＳＣは、ビジティングロケーションレジスタ（ＶＬＲ）１１２にリンクされてもよく、該レジスタは、ユーザに関するデータを記憶してセキュリティ機能を実行するデータベースである。ＭＳＣは、認証センタ（ＡｕＣ）１１６を含むホームロケーションレジスタ（ＨＲＬ）１１４にさらにリンクされてもよい。ＨＬＲ／ＡＵＣは、端末１０２のユーザがネットワークオペレータの会員となっているホームネットワーク（ＨＮ）内に位置してもよい。ＨＬＲはユーザ関連のデータ、例えば会員関連のデータを記憶し、端末の位置をたどるようにＭＳＣ／ＶＬＲ１１０と協働する。認証センタ（ＡｕＣ）は認証過程において用いられる認証パラメータの計算のためのアルゴリズムを（特に）有する。各加入者に対して、ＡｕＣは、端末内に位置する、例えば（Ｕ）ＳＩＭカードなどの、関連する識別モジュール内にも記憶される秘密認証鍵Ｋを記憶する。

信頼されるサービス（ＴＳ）データベース１１８は信頼されるサービス情報を含む。例えば、それは、ＨＬＲに接続されるかＨＬＲの一部であってもよい加入者に関する、受け入れられるサービス識別子および／または受け入れられないサービス識別子（例えば、電話番号）に関する１つ以上の信頼されるリストである。ＴＳデータベース内のリストは、加入者のＨＬＲおよび／またはサービス認証機能１２０によって更新されてもよい。サービス認証機能はＴＳデータベースにアクセスするように構成され、端末からのサービス要求に応じて、ユーザ端末に安全な通信チャネルをセットアップするように構成される。

サービス認証機能は機能的ハードウェア構成要素の形態で実施されてもよく、ＭＳＣ上で実行されるコンピュータプログラム製品またはＭＳＣに接続された他の個別のネットワーク要素として実施されてもよい。代替として、該機能は、実行されたときに呼の認証機能を提供する１つ以上のソフトウェアプログラム製品を備える２つ以上のネットワーク要素を含む分散された機能であってもよい。呼の認証機能のより詳細な説明は、図２に関連して以下に記載される。

図１に記載されたＧＳＭネットワーク以外のネットワークが使用されてもよい。例えば、一実施形態では、ネットワークは３Ｇネットワーク要素を含む３Ｇタイプ（ＵＭＴＳ）のモバイルネットワークであってもよい。この場合には、ネットワークは無線ネットワークコントローラ（ＲＮＣ）１０８を介してサービングＧＰＲＳサポートノード（ＳＧＳＮ）１１０に接続される無線基地局（ＲＢＳ）１０６を有してもよい。ＳＧＳＮはさらに、上記のような２Ｇタイプのネットワークと同じようにして、ＶＬＲ１１２およびＡｕＣ／ＨＬＲ１１４、１１６に接続される。さらなる実施形態では、通信ネットワーク１０４は、例えばプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、問い合わせ（ｉｎｔｅｒｒｏｇａｔｉｎｇ）ＣＳＣＦ（Ｉ−ＣＳＣＦ）、サービングＣＳＣＦ（Ｓ−ＣＳＣＦ）などの呼／セッション制御機能（ＣＳＣＦ）、およびホーム加入者サーバ（ＨＳＳ）のセットの形態のＩＭＳベースのネットワーク要素を含んでもよい。さらなる変形例は３ＧＰＰ ＬＴＥまたは３ＧＰＰ ＳＡＥネットワーク要素を含む。

端末１０２はパーソナルコンピュータ、またはスマートフォン、パーソナルデジタルアシスタント（ＰＤＡ）、ラップトップ、または１つ以上のモバイルネットワーク（２Ｇ、２．５Ｇ、３Ｇ、４Ｇ、ＮＧ、ＷｉＭａｘなど）においてサービスを提供することができる任意の他のモバイル通信装置などの、モバイル装置であってもよい。端末は無線モジュール１２２、オペレーティングシステム（ＯＳ）１２４、および識別モジュール１２０を含む。

無線モジュール１２２はワイヤレスネットワークサービスへの接続ポイントとして機能し、この目的のために１つ以上のアンテナと接続されるＲＦ受信器を含む少なくとも１つのエアインターフェイスを有する。図１は、無線カード１２２が基地局１０６との無線接続を提供する例示的な実施形態を示す。無線モジュールのＲＦインターフェイスは様々な無線テクノロジ（例えばＧＳＭサービスのためのＴＤＭＡ、ＵＭＴＳサービスのためのＷ−ＣＤＭＡ、ＷｉＦｉサービスのためのＩＥＥＥ ８０２．１１、ブルートゥース、ＤＥＣＴなど）に従ってＲＦ信号を受信および／または送信することが可能である。

端末のオペレーティングシステム（ＯＳ）１２４は、モバイル装置のリソース、例えば中央処理装置（ＣＰＵ）、プログラム命令１３０およびデータを記憶するメモリ、および、無線モジュール１２２、ディスプレイ１３４およびキーパッド１３２などの入力／出力（Ｉ／Ｏ）デバイスなどを管理するカーネルを含んでもよい。さらに、ＯＳは典型的には、アプリケーションプログラム１２８がＯＳによって提供されるサービスにアクセス可能となる１つ以上のアプリケーションプログラムインターフェイス（ＡＰＩ）、例えばモバイルネットワークとの無線接続をセットアップするための無線ネットワークＡＰＩを備える。

典型的には取り外し可能な識別モジュール１２６は、２Ｇタイプのネットワークサービス（ＧＳＭ）または３Ｇタイプのネットワークサービス（ＵＭＴＳ）に適したモバイル装置において使用するＵＩＣＣ（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）であってもよい。この目的のために、ＵＩＣＣはＳＩＭアプリケーションを含む加入者識別モジュール（ＳＩＭ）および／またはＵＳＩＭアプリケーションを含むＵＭＴＳ加入者識別モジュール（ＵＳＩＭ）を含んでもよい。識別モジュールがＳＩＭおよび／またはＵＳＩＭアプリケーションに限られないことは理解されるべきである。さらなる実施形態では、識別モジュールは、所定のＩＭＳベースのＡＫＡに基づいてＩＭＳベースのサービスを認証する、またはＩＭＳベースのサービスにアクセスするＩＰマルチメディアサブシステムＳＩＭ（ＩＳＩＭ）であってもよい。所定のＩＭＳベースのＡＫＡは、例えばＲＦＣ４１８７に記載の所定のＥＡＰベースのＡＫＡによるネットワークに認証されてアクセスするための、例えば、ＥＴＳＩ技術仕様ＴＳ ３３．２０３または拡張可能認証プロトコル（ＥＡＰ）ベースのＳＩＭに記載されている。

識別モジュールはプロセッサ、例えばＲＯＭ、ＲＡＭ、および／またはＥＥＰＲＯＭなどの１つ以上のメモリ構成要素、およびＩ／Ｏ回路を含んでよい。認証目的のために、ＵＩＣＣは秘密のサービス加入者認証鍵Ｋと、ランダムな課題（チャレンジ）を受け取った際に１つ以上の認証パラメータを含む応答を計算するための１つ以上のアルゴリズムと、を含む。

ネットワークにアクセスするために、端末はまず、ネットワークによって用いられる通信標準の認証および鍵一致（ＡＫＡ）の一方によって定義される認証過程を実行する。ＧＳＭ ＡＫＡは端末においてランダム数ＲＡＮＤをＳＩＭに送信することを含む、課題応答タイプの認証過程である。ＳＩＭはネットワークに送り返される応答ＲＥＳを生成し、該応答をネットワークによって計算される期待される応答と比較する。ＧＳＭ ＡＫＡの一部として、モバイル端末と、ＧＳＭエアインターフェイスを介して、データを暗号化するために作動しているネットワークとの間で対称暗号鍵ＣＫが確立される。ＧＳＭ ＡＫＡはＥＴＳＩ標準ＧＳＭ ０２．０９およびＧＳＭ ０３．２０に詳細に記載され、それは参照によって本明細書に組み込まれる。

標準ＵＭＴＳ認証過程において、ＧＳＭ ＡＫＡにおける場合と同様のステップが実行される。しかしながら、セキュリティを向上させるために、ネットワークは自分自身の認証をも端末に対して行う。ＵＭＴＳスキームではＡｕＣ／ＨＬＲはランダム数ＲＡＮＤを生成し、認証ベクトル（ＡＶ）｛ＡＵＴＮ、ＲＡＮＤ、ＸＲＥＳ、ＣＫ、ＩＫ｝を決定する。その後、ＳＧＳＮ／ＶＬＲはＲＡＮＤおよびＡＵＴＮを端末に転送する。端末内のＵＳＩＭはＲＡＮＤおよびＡＵＴＮに基づいて応答ＲＥＳを決定し、その後、応答ＲＥＳはネットワークに送信されて、ネットワークによって決定された期待される応答と比較される。ＧＳＭ ＡＫＡと同様に、暗号鍵ＣＫおよびインテグリティ鍵ＩＫが、モバイル端末と作動しているネットワークとの間でエアインターフェイスを介して送信されるデータを暗号化してインテグリティ保護を行うために用いられるＵＭＴＳ ＡＫＡの最中に、確立される。ＵＭＴＳ ＡＫＡはＥＴＳＩ技術仕様ＴＳ ３３．１０２に詳細に記載され、それは参照によって本明細書に組み込まれる。

図２は本発明の一実施形態によるＧＳＭネットワークにおいて発生した呼のセットアップのフロー図を示す。上記の認証過程の最中、加入者識別子（ＩＭＳＩ）、認証データ、加入者の電話番号、受け入れ可能なサービスのリスト、加入者のＨＬＲアドレス、および特にホワイトリストおよび／またはブラックリストを含む信頼されるサービス情報、を含む加入者登録データが、ＨＬＲからＭＳＣ／ＶＬＲに転送されてもよい（ステップ２０２）。認証が成功した後、端末はサービス要求を送信することによって、すなわち、ＢＳＳを介してＭＳＣ／ＶＬＲにモバイル加入者総合デジタル通信網番号（ＭＳＩＳＤＮ）を含む呼をセットアップする要求を送信することによって、ネットワークサービスにアクセスしてもよい（ステップ２０４）。

応答として、ＭＳＣはＶＬＲと共に、端末が要求されたサービスにアクセスすることを許可されているかどうか確かめる。さらに、ＭＳＣ内のサービス認可機能は、サービス要求内の情報が、特にＭＳＩＳＤＮが、信頼されるサービス情報（例えば、信頼される電話番号のリストの形態で）のリストにあるかどうかを確かめる。リストはＭＳＣに接続されたＶＬＲにアクセスすることによって確かめられてもよい（ステップ２０６および２０８）。合致するものが見つかった場合、ＭＳＣはＢＳＳに呼のリソースの割り当ておよびＧＭＳＣを介した呼の経路指定を要求する。ここでＧＭＳＣは、固定されたＰＳＴＮネットワークによってモバイルネットワークを受信先（図示せず）に接続するゲートウェイである。

番号が受け入れ可能な番号のリストに見つからない場合は、ＭＳＣサービス認証機能は、呼が受け入れ可能かそうでないかを認証するように端末のユーザに要求するために、生成端末によってダイアログを開始させてもよい。この目的のために、マルウェアによって侵されることが困難な、安全な通信チャネルが端末とネットワークの間で確立されてもよい。そのような安全な通信チャネルの例は、以下により詳細に記載される。

安全な通信チャネルを用いて、ＭＳＣ／ＶＬＲのサービス認証機能はユーザ端末にユーザ認証要求を送信してもよい。ユーザ認証要求は、端末のユーザにダイアログをトリガしてもよく、そこでは、ユーザが、要求されたサービスを確立すべきかそうでないかを認証することを求められている（ステップ２１０）。ユーザ認証要求に応答して、ユーザ応答メッセージがＭＳＣのサービス認証機能に送り返される（ステップ２１２）。ユーザ応答が、呼がユーザによって受け入れられる旨の情報を提供する場合、信頼されるサービスリストはＴＳデータベース内の信頼されるサービス情報にその番号を加えることによって更新される（ステップ２１４および２１６）。ユーザへの呼認証ダイアログの後、ＭＳＣは要求されたサービス、例えば呼のためにリソースを割り当てて、ＧＭＳＣおよび１つ以上の通信ネットワーク、例えばダイヤルされた端末への公衆交換電話網（ＰＳＴＮ）を介してサービス要求を経路指定する（ステップ２１８）。応答メッセージが、ユーザが呼を受け入れない旨を示す場合、呼はＭＳＣによって拒絶される（図示せず）。

したがって、生成した呼の従来のセットアップとは逆に、本発明は、サービス要求内の情報がホワイトリストにあるかどうかを確認することによって、端末によってネットワークに送信されたサービスに対する厳格な制御を可能にする。ホワイトリストを用いることで、サービス要求に由来して生成されたマルウェアを効率的に阻止することができる。さらに、本発明は、ホワイトリストを、対話的かつ動的な方法で構成することを可能にする。ひとたびリストがあるサイズになると、呼認証要素によって生成されるホワイトリストを使用することで、登録された呼が実際に疑いのない呼であることが、より確実にネットワークオペレータにもたらされる。

端末とネットワークの間の通信チャネルは、マルウェアに妨害をさせないという意味で、安全であるべきである。一実施形態では、安全な通信チャネルは、ＧＳＭまたはＵＭＴＳ ＡＫＡに基づく認証過程の最中にモバイル端末と作動しているネットワークとの間に確立された暗号鍵ＣＫを用いる、暗号化された無線チャネルであってもよい。このスキームでは、ＭＳＣ／ＶＬＲは暗号化されたユーザ認証要求２１０を、変更してもよい端末に送信し、マルウェアがユーザとネットワークの間のダイアログを干渉することを阻止する。そのような端末３００の１つの例示的な実施形態が図３により詳細に記載される。この実施形態では、端末は、端末のＯＳ３０４内で実行されるユーザ認証アプリケーション３０２（クライアント）を有する。端末は、ユーザ認証クライアント３０２、識別モジュール３１８（例えば（Ｕ）ＳＩＭ）、メモリ３２０、および／または、入力要素３２２（キーパッド、マイクロフォンなど）および出力要素３２４（ディスプレイ、スピーカなど）などの１つ以上のＩ／Ｏインターフェイスの間に１つ以上の信頼される通信経路３０８−３１６を確立する、１つ以上の信頼されるハードウェア構成要素３０６（ＴＨＣ）をさらに含む。

ユーザ認証要求はユーザ認証クライアントの実行をトリガしてもよく、ユーザ認証クライアントは、データを暗号化および復号する（Ｕ）ＳＩＭ、ユーザとの対話のための端末のキーパッドおよびディスプレイインターフェイス３２２、３２４と安全に通信するように構成される。

ＴＨＣは、ローカルおよび／またはリモートの認証、安全なデータ記憶および安全なＩ／Ｏ機能を含む、複数のセキュリティ機能を実施するように構成された改ざん耐性のある装置であってもよい。これらの機能は端末内に信頼される通信経路を確立するように用いられてもよい。ＴＨＣは所定の信頼される計算プラットフォーム標準、例えば信頼されるコンピュータグループ（ＴＣＧ）によって発行された、信頼されるモバイルモジュール（ＭＴＭ）仕様バージョン１．０、一訂版、２００７年６月１２日において定められたような、信頼される計算プラットフォーム（ＴＣＰ）、またはインテルの信頼される実行技術（ＴＸＴ）ハードウェアプラットフォームによって実施されてもよい。

ＴＨＣは、ローカルおよび／またはリモートの認証機能を用いて、ユーザ認証クライアントの完全性を認証してもよい。完全性が承認された後、ＴＨＣは図３に記載のように端末内に１つ以上の信頼される通信経路をセットアップしてもよい。これらの信頼される経路を用いて、ユーザ認証アプリケーションは、ユーザがサービス要求を受け入れるか拒絶するかを可能にする、ユーザとの安全なダイアログをセットアップする。ユーザ応答（すなわちキーパッド入力）は無線インターフェイス３２６および暗号化された無線チャネルを介して、ＭＳＣ／ＶＬＲのサービス認証機能に送り返される。

他の実施形態では、通信チャネルは、ネットワークに登録された追加のＳＩＭカードを用いて確立されてもよい。そのようなデュアルＳＩＭ端末は、サービス要求が、第１のＳＩＭに応じてセットアップされたチャネルを用いてネットワークに送信されることを可能にし、サービス要求の受け入れまたは拒絶のためのダイアログボックスへのユーザの反応が、第２のＳＩＭを用いて暗号化された通信チャネルを介して送信されることを可能にする。この実施形態は、マルウェアが第２のＳＩＭカードを知っておらず、したがって、暗号化された通信チャネルをＴＨＣと組み合わせて使用することと比較すると提供される安全性が小さいということに基づく。

他の実施形態では、安全なチャネルは同一の基盤（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）上に個別の通信チャネルを確立してもよい。例えば、端末からのサービス要求の受信に応答して、ネットワークは、例えばＳＭＳ、ＥＭＳ、ＭＭＳまたはＵＳＳＤメッセージの形態のメッセージを端末のユーザに送信し、ユーザは同一の個別の通信チャネルを使用して応答をネットワークに送り返す。

さらなる変形例では、端末とネットワークの間のサービス認証ダイアログは、好ましくはテキスト、画像および／または音からなるテストを送信するステップを有してもよく、それはユーザが人間であるかそうでないかの判定を可能にする。テストへの応答はネットワークに送信され、正しい応答は端末ユーザによるサービス要求を受容することに対応する。好ましくは、テストは逆チューリングテスト（例えばＣａｐｔｃｈａなど）であってもよい。逆チューリングテストは、ダイアログが、規則的で場合によっては安全でない基盤を用いて生成されることを可能にしてもよい。しかしながら、向上したセキュリティのため、逆チューリングテストを用いたダイアログは、上記のような暗号化されたおよび／または個別の通信チャネルと容易に組み合わされることができる。

信頼されるサービス（ＴＳ）データベースの機能は、望ましくない番号のリスト（すなわちブラックリスト）をさらに含むことにより拡張される。サービス要求がネットワーク、例えばＭＳＣによって受信された場合、ネットワークは要求においてダイヤルされた番号がブラックリストまたはホワイトリストにあるかどうかを確かめる。それがブラックリストにある場合、端末にさらなるダイアログは一切出ずに、呼は自動的に拒絶される。ブラックリストは、信頼されるサービスのリスト（ホワイトリスト）と関連して、上記と同様の方法で更新されてもよい。

一実施形態では、サービス要求のユーザによる拒絶の後、番号がブラックリストに加えられてもよい。これは、ユーザによる拒絶に応答して自動的に行われてもよく、代替として、呼認証ダイアログの最中にユーザへの選択肢としてダイアログボックス内に示されてもよい。ブラックリスト選択肢を選ぶことは、拒絶された番号を加えてＴＳデータベースにおけるブラックリストを更新することにつながる。そのようなブラックリストおよび／またはホワイトリストの更新は、ＭＳＣ／ＶＬＲとＨＬＲの間の通信が行われた場合に行われてもよい。例えば、加入者が所定の時間の間操作を行わなかった後に、加入者がＶＬＲによってカバーされた領域にいる旨の通知を、ＨＬＲがＭＳＣ／ＶＬＲによって受けた瞬間に行われてもよい。その後、端末は、作動しているＭＳＣ／ＶＬＲから登録を取り消される。さらに、そのような更新はリアルタイム、すなわち、ユーザ認証ダイアログの直後、または加入者記録がＶＬＲから消去された瞬間に行われてもよい。

さらに、ネットワークオペレータは、ユーザがリストに変更を行うことを可能にするために、ＴＳデータベース内のリストへのユーザの（間接的な）アクセス、例えば、安全なインターネット接続を介したアクセスを提供してもよい。

いかなる実施形態に関連して記載されたいかなる特徴も、単独で使用されてもよく、他の記載された特徴と組み合わされて使用されてもよく、いかなる他の実施形態の１つ以上の特徴と組み合わせて使用されてもよく、いかなる他の実施形態のいかなる組み合わせと使用されてもよいことを理解すべきである。さらに、上記されていない等価例や変形例が、添付の特許請求の範囲に定義されている、本発明の範囲から離れることなく使用されてもよい。

Claims (15)

1. 少なくとも１つの端末からネットワークに送信された少なくとも１つのサービス要求を管理する方法であって、前記ネットワークは信頼されるサービス情報を記憶するネットワークノードを含み、当該方法が、
   −前記ネットワークが端末からのサービス要求を受信するステップであって、前記要求がサービス要求情報を含む、ステップと、
   −前記ネットワークによって前記サービス要求が受信される通信チャネルとは異なる、さらなる通信チャネルを確立するステップと、
   −前記サービス要求情報の少なくとも一部が、信頼されるサービス情報のリストにない場合に、前記端末によって要求されたサービスを認証するようにユーザに要求するユーザ認証要求を、安全な通信チャネルを介して送信するステップと、
   −ユーザ認証応答を前記さらなる通信チャネルを介して受信するステップと、
   を含む方法。
2. 請求項１に記載の方法において、
   前記ユーザ認証応答は前記ユーザによって提供される認証情報を含み、前記認証情報は前記ユーザが前記サービス要求を受け入れるか拒絶するかを示し、当該方法が、さらに、
   −前記認証情報が、要求されるサービスが受け入れられない旨を提示する場合、前記信頼されるサービス情報に、前記サービス要求情報の少なくとも一部を加えるステップを含む、方法。
3. 請求項１に記載の方法であって、さらに、
   −前記端末の識別モジュールに記憶されたプライベート鍵を用いて、前記端末と前記ネットワークの間に暗号化された通信チャネルを確立するステップと、
   −前記暗号化された通信チャネルを介して前記端末に前記ユーザ認証要求を送信するステップと、
   −前記暗号化された通信チャネルを介して前記ユーザ認証応答を受信するステップであって、前記応答は、前記ユーザによって提供される、該ユーザが前記サービス要求を受け入れるか拒絶するかを示す認証情報を含む、ステップと、
   を含む方法。
4. 前記端末が識別モジュール、１つ以上の入力／出力インターフェイス、および少なくとも１つの信頼されるハードウェア構成要素を含み、前記信頼されるハードウェア構成要素は、前記信頼されるハードウェア構成要素と前記識別モジュールおよび／または前記１つ以上の入力／出力インターフェイスとの間に１つ以上の信頼される通信経路を確立するように構成される、請求項３に記載の方法。
5. ユーザ認証応答が、加入者がサービス要求を受け入れるか拒絶するかの認証情報を含む、請求項１から３のいずれか一項に記載の方法。
6. 前記安全な通信チャネルがメッセージングサービスによって提供される、請求項４に記載の方法。
7. 前記認証要求が、前記ユーザが人間であるかそうでないかを判定するように構成されたテストを含み、前記認証応答が、テストが成功したかそうでないかに関する情報を含む、請求項１から６のいずれか一項に記載の方法。
8. 前記ネットワークが、サービス提供ネットワークノードを含み、前記サービス提供ネットワークノードは、信頼されるサービス情報を有するビジティングロケーションレジスタ（ＶＬＲ）を含み、前記ネットワークノードは、前記サービス要求情報の少なくとも一部が前記信頼されるサービス情報のリストにない場合、端末からのサービス要求に応じて前記端末にユーザ認証要求を送信するためのユーザ認証機能をさらに含む、請求項１から７のいずれか一項に記載の方法。
9. 前記ネットワークがホームロケーションレジスタ（ＨＬＲ）をさらに含み、前記ホームロケーションレジスタは前記端末の信頼されるサービス情報を含み、当該方法が、さらに、
   −前記ホームロケーションレジスタから前記ビジティングロケーションレジスタへ前記信頼されるサービス情報を送信するステップを含む、請求項８に記載の方法。
10. 少なくとも１つの端末からネットワークに送信された少なくとも１つのサービス要求を管理するシステムであって、
    −前記ネットワークと共に通信チャネルを確立する１つ以上の端末と、
    −前記端末の少なくとも１つからサービス要求情報を含むサービス要求を受信するように構成された、サービス提供ネットワークノードと、
    −前記サービス提供ネットワークノードに接続された信頼されるサービスデータベースと、を有し、
    前記サービス提供ネットワークノードは、前記サービス要求情報の少なくとも一部が信頼されるサービス情報のリストにない場合に、前記端末によって要求されたサービスを認証することをユーザに要求するユーザ認証要求を、安全な通信チャネルを介して送信するように構成され、
    ユーザ認証応答を、前記ネットワークによって前記サービス要求が受信される前記通信チャネルとは異なるさらなる通信チャネルを介して、前記サービス提供ネットワークノードが受信するように構成される、システム。
11. 請求項１０に記載のシステムにおいて使用するユーザ認証装置であって、
    −端末からサービス要求を受信する手段であって、前記サービス要求がサービス要求情報を含む、手段と、
    −前記サービス要求情報の少なくとも一部が信頼されるサービスデータベースに含まれるか確かめる手段と、
    −前記サービス要求情報の少なくとも一部が前記信頼されるサービス情報のリストにない場合に、前記端末のユーザまたは前記端末に関連する他のユーザと前記ネットワークとの間で安全なダイアログを確立する手段と、を備え、
    前記ユーザ認証装置が前記サービス提供ネットワークノードによって具備される、ユーザ認証装置。
12. 請求項１０に記載のシステムにおいて使用する端末であって、
    −サービス提供ネットワークノードからのユーザ認証要求に応じて、端末のユーザとネットワークの間に安全なダイアログを確立するユーザ認証クライアントと、
    −前記ダイアログのために安全な通信チャネルを確立する暗号化鍵を提供する識別モジュールと、
    −前記ユーザからダイアログ情報を受信する入力要素と、
    −前記ユーザにダイアログ情報を送信する出力要素と、
    −前記ユーザ認証クライアント、識別モジュール、入力要素、および／または出力要素の間に１つ以上の信頼される通信経路を確立する、信頼されるハードウェア構成要素と、を含み、
    前記ユーザ認証応答が、前記ユーザ認証クライアントによって生成および送信される、端末。
13. コンピュータのメモリ内で実行される場合、請求項１から９のいずれか一項に記載の方法のステップを実行するように構成されたソフトウェアコード部分を含む、コンピュータプログラム。
14. コンピュータのメモリ内で実行される場合、
    サービス要求情報を含み、少なくとも１つの端末からネットワークに送信されるサービス要求に対してサービス認証機能を実行し、ソフトウェアコード部分が、
    −前記サービス要求情報の少なくとも一部が信頼されるサービス情報のリストにない場合に、前記端末によって要求されるサービスの認証をユーザに要求するサービス認証要求を、安全なチャネルを介して送信し、
    −ユーザ認証応答は前記ユーザが前記サービス要求を受け入れるか拒絶するかを示す、前記ユーザによって提供される認証情報を含み、前記ネットワークによって前記サービス要求が受信される通信チャネルとは異なるさらなる通信チャネルを介して前記ユーザ認証応答を受信し、
    −前記認証情報が、前記サービス要求が受け入れられる旨を提示する場合、前記サービス要求情報の少なくとも一部を前記信頼されるサービス情報に加える、
    ように構成されたソフトウェアコード部分を含む、コンピュータプログラム。
15. 前記サービス認証機能が機能的ハードウェア構成要素の形態で実施されるか、ＭＳＣまたはＭＳＣに接続された別のネットワーク要素で実行されるコンピュータプログラムとして実施されるか、あるいは１つ以上のソフトウェアプログラムを含む２つ以上のネットワーク要素を含む分散された機能である、
    請求項１４に記載のコンピュータプログラム。

Images