JP2009246986A - 移動無線通信装置におけるコンタクトの認証及び信頼できるコンタクトの更新 - Google Patents

Abstract

【課題】移動無線通信装置におけるコンタクトの認証及び信頼できるコンタクトの更新を提供する。
【解決手段】無線通信装置において実施する方法であって、この方法では、署名付きのコンタクト情報を、信頼できるコンタクトから成るリストに含まれないソースから受信し（４５６）、署名を無線通信装置に本方法に従って保存される基準署名と比較することによって署名が有効であるかどうかを確認し（４６２）、署名が有効である場合に、信頼できるコンタクトから成るリストを、受信したコンタクト情報に関して更新する（４６８）。或るアプリケーションでは、コンタクト情報及び署名は無線通信装置プロビジョニングセッション要求メッセージに関連付けられる。
【選択図】図４

Description

本発明は概して移動体無線通信に関し、特に未知のコンタクトからの通信の信頼度の確認、移動無線通信装置に保存されている信頼できるコンタクトのリストの更新、セッションリクエストメッセージ、及びその方法に関する。

無線インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｏｖｅｒ Ｔｈｅ Ａｉｒ：ＩＯＴＡ）、無線アプリケーションプロトコル（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＷＡＰ）プロビジョニング、及びプッシュ規格（ＰＵＳＨ ｓｐｅｃｉｆｉｃａｔｉｏｎｓ）は無線通信プロトコルであり、この無線通信プロトコルによりネットワーク操作者はコンテンツを携帯電話機に無線でＷＡＰブラウザを使用して書き込み、そして渡す（プッシュする）ことができる。ＩＯＴＡプロビジョニングプロトコルは符号分割多重接続（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ
Ａｃｃｅｓｓ：ＣＤＭＡ）の無線操作者によって実行されてきており、そしてＷＡＰプロビジョニングプロトコルは移動体通信用グローバルシステム（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：ＧＳＭ）の通信ネットワーク操作者によって実行されてきた。

ＷＡＰプロビジョニングセッションを開始するために、プッシュプロキシゲートウェイ（Ｐｕｓｈ Ｐｒｏｘｙ Ｇａｔｅｗａｙ：ＰＰＧ）は、セッション開始要求（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔ：ＳＩＲ）またはハローリクエスト（Ｈｅｌｌｏ Ｒｅｑｕｅｓｔ）として知られるインターネットプロトコル（ＩＰ）メッセージを移動局に送信する。ＩＯＴＡプロビジョニングセッションは同様にして、セッション要求を、ブートストラップ要求（ｂｏｏｔｓｔｒａｐ ｒｅｑｕｅｓｔ）として知られる更新版（ｍｏｄｉｆｉｅｄ）ショートメッセージサービス（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ
Ｓｅｒｖｉｃｅ：ＳＭＳ）メッセージの形でＳＭＳセンター（ＳＭＳＣ）から移動局に送信することにより開始する。

ＩＯＴＡプロビジョニングセッションでは、ＳＭＳ要求またはブートストラップ要求は情報を含み、この情報によってフォンブラウザ（ｐｈｏｎｅ ｂｒｏｗｓｅｒ）は指定したアドレスからモバイル管理用の命令（Ｍｏｂｉｌｅ Ｍａｎａｇｅｍｅｎｔ Ｃｏｍｍａｎｄ：ＭＭＣ）ドキュメントをフェッチすることができる。ＭＭＣドキュメントでは、携帯電話機の特定のパラメータは、例えば電話機に指示して電話パラメータを読み出し、かつ書き込んでＡキー（情報をセキュリティで保護するために使う共有された共通キー）の交換を開始し、そして好適なローミングリスト（通話可能エリア：ｐｒｅｆｅｒｒｅｄ
ｒｏａｍｉｎｇ ｌｉｓｔ：ＰＲＬ）などを更新することにより管理される。

ブートストラップ要求メッセージは生成及び／又は更新が比較的容易である。電話番号及びそのＥＳＮ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｉａｌ Ｎｕｍｂｅｒ）が既知の場合、非認証ブートストラップメッセージを生成し、そして電話機に虚偽の命令を送信して不正にＭＭＣドキュメントをフェッチするように指示することができ、このドキュメントを使用して電話機を操作して、例えば電話機に指示して或るアクションを行なわせてハッカーに不正サービスを提供することができる。

偽りの通信及び他の無許可通信からの保護を、セッション開始要求が発信される発信元アドレスを無線電話機に保存される既知の有効コンタクト、または信頼できるコンタクトから成るリストと比較することによって行なうことが提案されている。しかしながらこの提案では、無線電話機に保存され、かつ信頼できるコンタクトから成るリストは固定されていて、容易にアドレス変更を行ない、そして／または新規の信頼できるコンタクトを容易に消去及び追加することができない。

本発明の種々の態様、特徴及び利点は、この技術分野の当業者には、本発明に関する次の詳細な記述を以下に示す添付の図とともに注意深く考察することにより一層完全に近い形で明らかになるものと思われる。

本発明における例示としてのアプリケーションによる通信システム。 本発明における例示としてのアプリケーションに関するプロセスフロー図。 本発明における幾つかのアプリケーションに関する通信方法の例を示す図。 例示としての無線通信装置のプロビジョニングセッション要求メッセージ図。

図１は、無線通信装置に通信サービスを提供する一般的な無線ネットワーク１１０、例えばＣＤＭＡまたはＧＳＭ／ＧＰＲＳセルラーネットワーク、または他の或る無線ネットワークインフラストラクチャを備える通信システム１００を示している。

無線通信装置は、移動無線電話機１２０、例えばＣＤＭＡまたはＧＳＭ／ＧＰＲＳ、または他の或る移動通信装置とすることができる。図２は例示としての無線通信装置２００であり、この装置は、メモリ２２０、例えばＲＡＭ及びＲＯＭ、及び或る実施形態ではＳＩＭ，ＵＳＩＭ，Ｒ−ＵＩＭ，ＮＶＭなどに接続される一般的なプロセッサ２１０を備える。プロセッサはまた、無線トランシーバ２３０及びディスプレイデバイス２４０に接続される。プロセッサはまた、入力２５０、例えばマイクロホン及びデータポート、さらに出力２６０、例えばスピーカ及びデータポートに接続される。

図１では、無線通信ネットワーク１１０はゲートウェイ１３０に接続され、このゲートウェイはサーバ１４０に接続される。今ではボイス及びデータサービスを提供する多くのＣＤＭＡ無線操作者が必要とする無線インターネット（Ｉｎｔｅｒｎｅｔ Ｏｖｅｒ Ｔｈｅ Ａｉｒ：ＩＯＴＡ）プロビジョニングアプリケーションでは、サーバ１４０はＩＯＴＡプロビジョニングサーバであり、そしてゲートウェイ１３０はプロビジョニングゲートウェイ、例えば無線アプリケーションプロトコル（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：ＷＡＰ）プロビジョニングゲートウェイである。例示としての実施形態では、無線ネットワーク１１０はショートメッセージサービスセンター（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ Ｓｅｒｖｉｃｉｎｇ Ｃｅｎｔｅｒ：ＳＭＳＣ）を含む。ＷＡＰ及び他のプロビジョニングアプリケーションでは、サーバ及びゲートウェイは異なるものとして識別することができるが、これらの指定及び他の例示としての指定は本発明を制限するものではない。

無線通信装置セッション要求は通常、サーバから開始されるが、セッション要求の開始ポイントはサーバと通信する他の或る発信元とすることができる。特に、図３のプロセスフロー図３００では、ブロック３１０でプッシュプロキシゲートウェイ（Ｐｕｓｈ Ｐｒｏｘｙ Ｇａｔｅｗａｙ：ＰＰＧ）がＳＩＲまたはハローリクエスト（Ｈｅｌｌｏ Ｒｅｑｕｅｓｔ）をクライアントに送信する。他の実施形態では、更に一般的な形で、セッション要求は他の或るサーバから、かつＳＩＲ以外のフォーマット、例えばブートストラップ要求のフォーマットで開始することができる。

図３では、ブロック３１０において、セッション要求は通常、要求元に関する情報、例えばＩＰアドレスまたは他の或る情報を含み、これらの情報を使用して、セッション要求の送信元及び発信元の信頼度を確認することができる。

例示としてのアプリケーションでは、セッション要求は無線通信装置プロビジョニングセッション要求、例えばブートストラップ要求、またはセッション開始要求（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔ：ＳＩＲ）、或いは他の或るプロビジョニングセッション要求である。他のアプリケーションでは、更に一般的な形で、セッション要求は無線装置プロビジョニングセッション以外のセッションに対する要求とすることができる。

図１では、セッション要求は通常、サーバ１４０からゲートウェイに、次に通信ネットワークに送信され、この通信ネットワークによってセッション要求が携帯電話機に送信される、または渡される。図４に示す例示としてのＩＯＴＡプロビジョニングアプリケーションでは、ＩＯＴＡ／ＰＵＳＨプロビジョニングサーバ４１０がブートストラップ要求メッセージ４０２を生成し、そしてこのメッセージをＷＡＰプロビジョニングゲートウェイまたはプッシュゲートウェイ４２０に送信し、このゲートウェイがブートストラップメッセージを無線通信ネットワーク４３０、例えばネットワークのＳＭＳＣに転送する。無線通信ネットワークはメッセージを携帯電話機４４０に送信する。サーバから移動局への要求の送信は、通信スレッド４５０で識別される。

図３では、ブロック３２０において、クライアントまたは電話機は、有効かどうかを確認する必要のあるセッション要求を受信する。或る実施形態では、ブロック３３０において、セッション要求が有効であるかどうかを確認するが、この確認は、このセッション要求を移動局または電話機に保存され、かつ信頼できるコンタクトソースから成るリストと比較することにより、例えばサーバのＩＰアドレスを認証アドレスから成るリストと比較することにより行なう。

信頼できるソースから成るリストは、移動局がネットワークから取得することができ、そして定期的に更新することができる。信頼できるソースを登録したリストは移動局のメモリ、例えばＳＩＭ，ＵＳＩＭ，Ｒ−ＵＩＭ，ＮＶＭなどに保存される。

他のアプリケーションでは、セッション要求が有効かどうかの確認は、携帯電話機ではなくネットワークで行なうことができ、例えば携帯電話機はセッション要求メッセージまたはこのメッセージの関連部分、例えばＩＰアドレスをネットワークに送信して確認を行なうことができる。携帯電話機及びネットワークは通常、以下に更に議論するセキュア通信を行なう機能を備え、このセキュア通信によってネットワークで行なわれる、ネットワークの、ネットワークが実行する認証トランザクションの完全性が保証される。

図４では、セッション要求の発信元が信頼できるコンタクトから成るリストに含まれていない場合、或るアプリケーションでは、移動局は通信４５２に示すように、要求を拒絶することができる。セッション要求の拒絶はデフォルト応答であることが好ましく、このデフォルト応答では、セッション要求の発信元は例えば移動局またはネットワークによって認証されない。

図４によれば、署名要求４５４の段階では、プロビジョニングセッション要求をクライアントに送信するサーバは、無線装置が承認する無線通信ネットワークによる、または他の或る認証ソースによる署名を要求する。通信４５６の段階では、ネットワークは要求４５４に応答して署名をサーバに送信する。

署名は通常、認証情報であり、この認証情報はサーバがネットワークから受信して無線装置に提示し、この装置は、署名が関連するところの少なくともトランザクションまたはセッションの情報ソースとしてのサーバの信頼度を確認する。一の実施形態では、署名は、署名が関連するセッションにのみ有効である。更に一般的には、署名は所定の特定期間の間だけ有効とする、例えば署名は署名に関連する有効期間またはタイムスタンプを有することができる。

図４によれば、或るアプリケーションでは、サーバ４１０はネットワーク４３０による署名を要求するが、この要求は、最初にセッション要求を署名無しで送信した後に、かつ例えばセッション要求を信頼できるコンタクトポイントまたはコンタクトソースから成るリストと比較した結果として信頼度に欠けるという理由により移動局４４０からセッション拒絶を受信するときに行なわれる。他のアプリケーションでは、サーバ４１０はネットワーク４３０による署名を要求するが、この要求は、認証署名データ無しのセッション要求メッセージを最初に送信する前に行なう、または認証署名データ無しのセッション要求メッセージを最初に送信するという操作を実行しないで行なう。従って、或るアプリケーションでは、図４のステップ４５０及び４５２は不要であるので、最初にネットワークによる署名または他の認証ソースによる署名を要求することによって省略することができる。

署名は通常、セッション要求メッセージに、例えばメッセージのヘッダにサーバによって組み込まれてセッション要求と一緒に送信される。図４では、認証署名をネットワーク４３０または他のソースから受信すると、署名要求４５４に応答して署名がセッション要求メッセージに、例えば署名をメッセージヘッダに格納することにより、或いは署名及びメッセージを組み合わせることにより組み込まれるが、これらの構成の特殊性によって本発明が制限されるものではない。この組み合わせステップはサーバにおいて、または他の或るロケーションにおいて実施することができる。図３では、セキュリティキーと見なすこともできる署名はメッセージにブロック３４０で付加される。

図５は例示としての無線通信装置のプロビジョニングセッション要求メッセージであり、このメッセージは通常、メッセージヘッダ部５１０及びメッセージ本体部５２０を含む。一の実施形態では、メッセージヘッダメッセージ部は、認証署名データをネットワークサービスプロバイダーから受信する署名データフィールドを含み、この認証署名データを使用してセッション要求ソースの信頼度を確認することができる。しかしながら他の実施形態では、認証署名をメッセージにヘッダデータフィールドに格納する以外の手段で組み入れる、例えば認証署名をセッション要求に添付する、または連結することができる。

図５の例示としての実施形態では、メッセージヘッダは、ネットワークから受信する認証署名データを保存する署名データフィールド５１２を含む。上に記載したように、一の実施形態では、セッション要求メッセージは無線アプリケーションプロトコルセッション開始要求（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔ）であり、別の実施形態では、無線インターネット（Ｉｎｔｅｒｎｅｔ Ｏｖｅｒ ｔｈｅ Ａｉｒ：ＩＯＴＡ）ブートストラップ要求である。

図４では、署名はネットワーク４３０によって移動局４４０にも供給する必要があり、これによって移動局はサーバ４１０から受信する署名が有効であるかどうかを確認することができる。図４では、署名はネットワーク４３０から移動局４４０に、これらの間に位置する一連の関連する通信手段によって送信され、これらの通信手段は複数の通信スレッド４６０から成るグループによって識別される。

一の実施形態では、ネットワークは共有秘密データ（Ｓｈａｒｅｄ Ｓｅｃｒｅｔ Ｄａｔａ：ＳＳＤ）更新プロシージャを開始し、続いて固有のチャレンジ応答（Ｕｎｉｑｕｅ Ｃｈａｌｌｅｎｇｅ Ｒｅｓｐｏｎｓｅ）プロシージャが行なわれる。これらの公知の通信プロシージャの結果、ネットワーク及び電話機は共に、同一データ、同一値、同一署名または同一キーなどを個々に生成する機能を備える。ネットワークはまた、ＳＳＤを公知のハッシュ（Ｈａｓｈ）アルゴリズムまたはハッシュ技術のいずれかを使用して生成することができる。別の実施形態では、他のプロシージャを使用してネットワークと移動局との間でセキュア情報を授受することができる。

図４によれば、或るアプリケーションでは、署名は、サーバ４１０が署名要求４５４を行なった後にのみ移動局４４０に送信される。しかしながら、より一般的には、署名は移動局４４０に、図４の矢印４６１によって示すようにサーバによる署名要求４５４の前のいつの時点でも送信することができる。

移動局に送信される署名は、少なくともサーバからのセッション要求が有効であるかどうかを確認するために有用である。しかしながら、より一般的には、署名は更に長い期間に渡って、例えばタイムスタンプを署名に関連付けることによって有効となり得、この場合、タイムスタンプがその有効期限に達すると、新規署名または更新署名を取得する必要がある。従って移動局はネットワークからの署名を後で使用するために署名を保存する必要がある。

図４では、ネットワークまたは他の認証ソースから署名を受信し、そして署名をセッション要求と組み合わせると、通信スレッド４５８に示すように、サーバ４１０はセッション要求及び署名を移動局４４０に送信する、または再送信する。

図４では、認証プロセス４６２において、移動局は、セッション要求４５８に関連する署名が有効であるかどうかを確認するが、この確認は、署名をネットワークまたは認証ソースから直接受信する、本明細書では基準署名とも呼ぶ署名と比較することにより通知される。

図４では、処理４６４において、署名が有効である場合、セッション要求が移動局４４０で処理される、例えば次に移動局はＭＭＣドキュメントまたはプッシュコンテンツをフェッチする。或るアプリケーションでは、署名が有効であるかどうかを確認すると、セッション要求を処理する前に移動局はまず許可（ａｃｃｅｐｔａｎｃｅ）をサーバ４１０に許可通信４６６で送信する。

図４では、信頼できるコンタクトから成るリストは、署名セッションの署名が有効である場合に４６８で署名セッションの要求者に関して更新することができる。或るアプリケーションでは、信頼できるコンタクトから成るリストは、署名が有効な場合にセッション要求で受信するコンタクト情報により更新される。例えば、セッションの要求者を、無線通信装置に保存され、かつ信頼できるコンタクトから成るリストに加えることができる。図３では、ブロック３４０において、コンタクトポイントがユーザリストに付加される。

他の実施形態では、コンタクトから成るリスト、または信頼できる登録コンタクトから成るリストは、リストに関連付けられる有効期間を有する。期間が過ぎると、コンタクトの信頼度は、認証署名を移動局にネットワークから提出する、または再提出することにより再設定することができる。これらの場合では、認証署名を受信するとコンタクトリストクロックはリストの特定のコンタクトに関してリセットされ、新規コンタクトをリストに加える操作を必要としない。他の実施形態では、コンタクトをリストから取り除く、または許可しないようにすることができる。

移動局またはネットワーク、或いは両方において保存されるコンタクトリストが更新されると、サーバまたはセッション要求の送信者はその後、署名をネットワークまたは認証ソースから取得する必要はない。移動体装置に保存され、かつ信頼できるコンタクトから成るリストを動的に更新することにより、装置は自由に移動することができるようにもなり、信頼できるコンタクトから成るリストの更新に関して単一のソースに依存しないで済む。

本発明及び現時点で本発明の最良の形態と考えられる構成について、発明者らによる本発明の内容を構築することができ、そしてこの技術分野の当業者が本発明を作製し、そして使用できる形で記載してきたが、本明細書に開示する例示としての実施形態に関して多くの等価物が存在し、かつ無数の変形及び変更をこれらの実施形態に本発明の技術思想及び技術範囲を逸脱しない範囲で加えることができ、そして本発明の技術思想及び技術範囲が例示の実施形態に制限されず、添付の請求項によってのみ制限されることを理解できるであろう。

Claims (6)

1. ユーザ端末を偽りの通信および無許可通信から保護するために無線通信装置において署名セッションを認証する方法であって、
   信頼できるソースからの基準署名を無線通信装置に保存する工程と、
   認証署名を含むメッセージを受信する工程と、
   メッセージの認証署名を無線通信装置の基準署名と比較することによりメッセージの認証署名の有効性を確認するする工程と、
   以前に保存した基準書名の有効期限が過ぎると、信頼できるソースから受信した情報から、無線通信装置上に新しい基準署名を生成する工程と、
   からなる方法。
2. メッセージを受信する前に、基準署名を、信頼できるソースから受信する情報から無線通信装置において生成する請求項１記載の方法。
3. ユーザ端末を偽りの通信および無許可通信から保護するために無線通信装置において署名セッションを認証する方法であって、
   署名付きのコンタクト情報を、信頼できるコンタクトリストに登録されていないソースから受信する工程と、
   署名を有効であるかどうかを、無線通信装置において署名を基準署名と比較することにより確認する工程と、
   署名が有効である場合に、信頼できるコンタクトから成るリストを、受信したコンタクト情報に関して更新する工程と、
   からなる方法。
4. 基準署名を、信頼できるソースから受信する情報から無線通信装置において生成する請求項３記載の方法。
5. 署名付きのコンタクト情報が信頼できるソースからのものであるかどうかを、コンタクト情報が、無線通信装置に保存されている信頼できるコンタクトから成るリストに含まれているかどうかを判断することによって判断する請求項３記載の方法。
6. ユーザ端末を偽りの通信および無許可通信から保護するために無線通信ネットワークと通信するサーバにおいて署名セッションを認証する方法であって、
   無線通信ネットワークによる署名を要求する工程と、
   認証署名を含むセッション要求を無線通信ネットワークの移動無線通信装置に送信する工程と、
   署名要求に応答して無線通信ネットワークから情報を受信し、無線通信ネットワークから受信した情報を基に署名を認証する工程を含むセッション要求を生成する工程と、
   からなる方法。

Images