特許 6475366 サービスへのアクセスを管理する方法

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

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

(11)【特許番号】6475366

(24)【登録日】2019年2月8日

(45)【発行日】2019年2月27日

(54)【発明の名称】サービスへのアクセスを管理する方法

(51)【国際特許分類】

   G06F 21/31 20130101AFI20190218BHJP

   G06F 21/33 20130101ALI20190218BHJP

   H04W 12/12 20090101ALI20190218BHJP

【ＦＩ】

   G06F21/31

   G06F21/33

   H04W12/12

【請求項の数】9

【全頁数】15

(21)【出願番号】特願2017-555460(P2017-555460)

(86)(22)【出願日】2016年4月25日

(65)【公表番号】特表2018-516403(P2018-516403A)

(43)【公表日】2018年6月21日

(86)【国際出願番号】EP2016059178

(87)【国際公開番号】WO2016177597

(87)【国際公開日】20161110

【審査請求日】2017年10月23日

(31)【優先権主張番号】15305697.3

(32)【優先日】2015年5月7日

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

(73)【特許権者】

【識別番号】309014746

【氏名又は名称】ジェムアルト エスアー

(74)【代理人】

【識別番号】100086368

【弁理士】

【氏名又は名称】萩原 誠

(72)【発明者】

【氏名】カレン ル，ホンキーン

(72)【発明者】

【氏名】ジャン−イブ フィーヌ

(72)【発明者】

【氏名】ブノワ ゴンザルホ

(72)【発明者】

【氏名】アリーヌ グゲット

【審査官】 岸野 徹

(56)【参考文献】

【文献】 特開２００３−３３８８１４（ＪＰ，Ａ）

【文献】 特開２００８−０１５８７７（ＪＰ，Ａ）

【文献】 特開２００７−１０２７７８（ＪＰ，Ａ）

【文献】 特開２００６−２６８７１９（ＪＰ，Ａ）

【文献】 特開２００４−１１８５４１（ＪＰ，Ａ）

【文献】 特開２０１５−００１７６４（ＪＰ，Ａ）

【文献】 特開２００８−０７１０９７（ＪＰ，Ａ）

【文献】 特開２００９−１９３２７２（ＪＰ，Ａ）

【文献】 特開２００２−３４２２７１（ＪＰ，Ａ）

【文献】 特開２００８−０９７２６４（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００８／００１５８７７（ＵＳ，Ａ１）

【文献】 小若女 優介，Felica搭載携帯電話を使用したワンタイム認証方式の提案，電子情報通信学会技術研究報告 Ｖｏｌ．１１０ Ｎｏ．３７５，２０１１年 １月１３日，pp.93-98

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

Ｇ０６Ｆ ２１／３１

Ｇ０６Ｆ ２１／３３

Ｈ０４Ｗ １２／１２

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

【請求項1】

サービスへのアクセスを管理するための方法であって、
前記方法は、
−クライアントアプリケーション（ＣＡ）が、認証情報及び第１のアンチクローンコード（ＡＣＣ１）を用いて前記サービスにアクセスする要求をアプリケーションサーバ（ＳＶ）に送信するステップと、
−前記アプリケーションサーバ（ＳＶ）が、前記認証情報及び前記第１のアンチクローンコード（ＡＣＣ１）の検証を行うステップと、
−前記アプリケーションサーバが、検証が成功した場合のみ、前記サービスにアクセスする次の試みに必要な第２のアンチクローンコード（ＡＣＣ２）を、前記クライアントアプリケーション（ＣＡ）に送信し、前記第１のアンチクローンコード（ＡＣＣ１）を非活性化するステップと、を含み、
前記アプリケーションサーバ（ＳＶ）は、前記クライアントアプリケーション（ＣＡ）に関連付けられた復旧データ（ＲＤ）をあらかじめ記録し、前記クライアントアプリケーション（ＣＡ）は、ユーザ（ＵＳ）に割り当てられ、クローン化されたクライアントアプリケーション（ＣＡ２）が、前記クライアントアプリケーション（ＣＡ）に対する盗まれたアンチクローンコードを用いることによる前記サービスへのアクセスが認められ、前記アプリケーションサーバ（ＳＶ）は、前記ユーザ（ＵＳ）に識別データ（ＩＤ）の送信を要求し、前記識別データ（ＩＤ）が前記復旧データ（ＲＤ）に対応している場合に、前記アプリケーションサーバ（ＳＶ）は、前記クローン化されたクライアントアプリケーション（ＣＡ２）による前記サービスへのアクセスを取り除き、前記クライアントアプリケーション（ＣＡ）による前記サービスへのアクセスを許可し、前記クライアントアプリケーション（ＣＡ）に、前記サービスにアクセスする次の試みに必要な新しいアンチクローンコードを送信する、ことを特徴とする方法。

【請求項2】

前記アプリケーションサーバ（ＳＶ）は、前記クライアントアプリケーション（ＣＡ）に関連付けられた復旧データ（ＲＤ）をあらかじめ記録し、前記クライアントアプリケーション（ＣＡ）は、ユーザ（ＵＳ）に割り当てられ、前記アプリケーションサーバ（ＳＶ）は、前記検証に失敗した場合に、前記ユーザ（ＵＳ）に識別データ（ＩＤ）の送信を要求し、前記識別データ（ＩＤ）が前記復旧データ（ＲＤ）に対応している場合に、前記アプリケーションサーバ（ＳＶ）は前記サービスへのアクセスを許可し、前記クライアントアプリケーションに、前記サービスにアクセスする次の試みに必要な新しいアンチクローンコードを送信する、請求項１に記載の方法。

【請求項3】

前記クライアントアプリケーション（ＣＡ）はデバイスに埋設され、
前記アプリケーションサーバ（ＳＶ）は前記デバイスのフィンガープリント（ＦＰ）をあらかじめ記録し、
前記認証情報は前記フィンガープリント（ＦＰ）を含む、請求項１に記載の方法。

【請求項4】

前記第１及び第２のアンチクローンコード（ＡＣＣ１、ＡＣＣ２）は、前記クライアントアプリケーション（ＣＡ）によりパスワード又はキーとして用いられる、請求項１に記載の方法。

【請求項5】

サービスをクライアントアプリケーション（ＣＡ）に提供可能なアプリケーションサーバ（ＳＶ）であって、前記アプリケーションサーバ（ＳＶ）は、前記クライアントアプリケーション（ＣＡ）とのセキュアなかつ認証されたセッションを確立するように構成され、
前記アプリケーションサーバ（ＳＶ）は、第１のアンチクローンコード（ＡＣＣ１）を、前記セッションを通じて前記クライアントアプリケーション（ＣＡ）に送信するように構成され、
前記アプリケーションサーバ（ＳＶ）は、前記クライアントアプリケーション（ＣＡ）が送信した要求が認証情報及び前記第１のアンチクローンコード（ＡＣＣ１）を用いて正しく生成されたことを検証するように適合され、
前記アプリケーションサーバ（ＳＶ）は、検証に成功した場合のみ、前記サービスにアクセスする次の試みに必要な第２のアンチクローンコード（ＡＣＣ２）を、前記クライアントアプリケーション（ＣＡ）に送信し、前記第１のアンチクローンコード（ＡＣＣ１）を非活性化するように構成され、
前記アプリケーションサーバ（ＳＶ）は、一度に１つのクライアントエンティティによる前記サービスへのアクセスを許可するように構成され、前記アプリケーションサーバ（ＳＶ）は、前記クライアントアプリケーション（ＣＡ）に関連付けられた復旧データ（ＲＤ）を、登録段階において記録するように構成され、前記クライアントアプリケーション（ＣＡ）は、ユーザ（ＵＳ）に割り当てられ、クローン化されたクライアントアプリケーション（ＣＡ２）が、前記クライアントアプリケーション（ＣＡ）に対する盗まれたアンチクローンコードを用いることによる前記サービスへのアクセスが認められた場合、前記アプリケーションサーバ（ＳＶ）は、前記ユーザ（ＵＳ）に識別データ（ＩＤ）の送信を要求するように構成され、前記識別データ（ＩＤ）が前記復旧データ（ＲＤ）に対応している場合に、前記アプリケーションサーバ（ＳＶ）は、前記クローン化されたクライアントアプリケーション（ＣＡ２）による前記サービスへのアクセスを取り除き、前記クライアントアプリケーション（ＣＡ）による前記サービスへのアクセスを許可し、前記クライアントアプリケーション（ＣＡ）に、前記サービスにアクセスする次の試みに必要な新しいアンチクローンコードを送信するように構成される、ことを特徴とするアプリケーションサーバ。

【請求項6】

前記アプリケーションサーバ（ＳＶ）は、前記クライアントアプリケーション（ＣＡ）に関連付けられた復旧データ（ＲＤ）を登録段階において記録するように構成され、前記クライアントアプリケーション（ＣＡ）は、ユーザ（ＵＳ）に割り当てられ、前記アプリケーションサーバ（ＳＶ）は、前記検証に失敗した場合に、前記ユーザ（ＵＳ）に識別データ（ＩＤ）の送信を要求するように構成され、前記識別データ（ＩＤ）が前記復旧データ（ＲＤ）に対応している場合に、前記アプリケーションサーバ（ＳＶ）は、前記サービスへのアクセスを許可し、前記クライアントアプリケーション（ＣＡ）に、前記サービスにアクセスする次の試みに必要な新しいアンチクローンコードを送信するように構成される、請求項５に記載のアプリケーションサーバ。

【請求項7】

前記クライアントアプリケーション（ＣＡ）はデバイスに埋設され、
前記アプリケーションサーバ（ＳＶ）は前記デバイスのフィンガープリント（ＦＰ）をあらかじめ記録し、
前記認証情報は前記フィンガープリント（ＦＰ）を含む、請求項５に記載のアプリケーションサーバ。

【請求項8】

前記アプリケーションサーバ（ＳＶ）は、前記第１及び第２のアンチクローンコード（ＡＣＣ１、ＡＣＣ２）が前記クライアントアプリケーション（ＣＡ）によりパスワード又はキーとして用いられることを確認するように構成される、請求項５に記載のアプリケーションサーバ。

【請求項9】

前記アプリケーションサーバ（ＳＶ）は、前記クライアントアプリケーション（ＣＡ）が組み込まれたデバイスのフィンガープリント（ＦＰ）を記録するように構成され、前記アプリケーションサーバ（ＳＶ）は、前記認証情報が前記フィンガープリント（ＦＰ）を含むことを確認するように構成される、請求項５に記載のアプリケーションサーバ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サービスへのアクセスを管理する方法に関する。本発明は、特にクライアントアプリケーションからのサービスへのアクセスを管理する方法に関する。

【背景技術】

【0002】

スマートフォンやタブレットなどのモバイルデバイスが急速に採用されることにより、あらゆる種類のモバイルサービスの巨大な市場が創出されている。ユーザは、アプリケーションストア（すなわち市場）からアプリケーションをダウンロードし、それらを自身のモバイルデバイスにインストールし、これらのアプリケーションを通じてサービスを消費することができる。

【0003】

モバイルアプリケーションは、モバイルデバイスに格納され、実行されるソフトウェアである。一方でユーザは、利便性、良いユーザ体験、及び性能を求める。これらを満たすため、多くのモバイルアプリケーションは、接続データ（例えばアクセストークン）又は／及びユーザ認証情報（例えばパスワード）をローカルストレージ及び実行時のメモリに保持する。このようにユーザは通常、アプリケーションをタップするだけでこれを使用する。一方、攻撃者らは自らの注意をモバイルデバイスに向けている。彼らはマルウェアをルートユーザのモバイルデバイスに拡散させる様々な方法を展開している。これによって攻撃者らは、ユーザのデバイスにおけるいかなる重要なものも変更する又は盗むことができる。

【0004】

１つの特定の問題は、クローン化されたアプリケーションである。モバイルアプリケーションはアプリケーションストアから誰でもダウンロードすることができる。従って、その意味では、アプリケーションをクローン化すること自体は問題ではない。懸念は、モバイルサービスのリモートサーバと情報をやりとりするためにモバイルアプリケーションが使用する、認証トークンやアクセストークンやＡＰＩキーなどのユーザ認証情報及び他のデータである。この意味におけるクローンは、モバイルアプリケーション、ユーザ認証情報、及びアプリケーションデータが全て別のデバイスにコピーされることを意味し、それらによって、クローン化されたモバイルアプリケーションが元のユーザの名において他のデバイス上で動くことができる。

【0005】

アプリケーションのクローン化に関する同一の問題は、他のタイプのデバイスにも見ることができる。

【0006】

アプリケーションのクローン化が引き起こす問題を緩和する必要性がある。

【発明の概要】

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

【0007】

本発明の目的は、上述の技術的問題を解決することである。

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

【0008】

本発明の目的は、サービスへのアクセスを管理するための方法である。本方法は、
−クライアントアプリケーションが、認証情報及び第１のアンチクローンコードを用いてサービスにアクセスする要求をアプリケーションサーバに送信するステップと、
−アプリケーションサーバが、認証情報及び第１のアンチクローンコードの検証を行うステップと、
−アプリケーションサーバが、検証に成功した場合のみ、サービスにアクセスする次の試みに必要な第２のアンチクローンコードを、クライアントアプリケーションに送信し、第１のアンチクローンコードを非活性化するステップと、を含む。

【0009】

有利には、アプリケーションサーバは、クライアントアプリケーションに関連付けられた復旧データをあらかじめ記録しておくことができ、クライアントアプリケーションは、ユーザに割り当てることができ、アプリケーションサーバは、検証に失敗した場合に、ユーザに識別データの送信を要求することができ、識別データが復旧データに対応している場合に、アプリケーションサーバは、サービスへのアクセスを許可することができ、クライアントアプリケーションに、サービスにアクセスする次の試みに必要な新しいアンチクローンコードを送信することができる。

【0010】

有利には、アプリケーションサーバは、クライアントアプリケーションに関連付けられた復旧データをあらかじめ記録しておくことができ、クライアントアプリケーションは、ユーザに割り当てることができ、クローン化されたクライアントアプリケーションは、クライアントアプリケーションに対する盗まれたアンチクローンコードを用いることによりサービスへのアクセスが認められる可能性があり、アプリケーションサーバは、ユーザに識別データの送信を要求することができ、識別データが復旧データに対応している場合に、アプリケーションサーバは、クローン化されたクライアントアプリケーションによるサービスへのアクセスを取り除き、クライアントアプリケーションによるサービスへのアクセスを許可することができ、クライアントアプリケーションに、サービスにアクセスする次の試みに必要な新しいアンチクローンコードを送信することができる。

【0011】

有利には、前記第１及び第２のアンチクローンコードは、クライアントアプリケーションによりパスワード又はキーとして用いられてもよい。

【0012】

有利には、クライアントアプリケーションは、デバイスに組み込むことができ、アプリケーションサーバは、デバイスのフィンガープリントをあらかじめ記録しておくことができ、前記認証情報はフィンガープリントを含むことができる。

【0013】

本発明の別の目的は、サービスをクライアントアプリケーションに提供可能なアプリケーションサーバである。アプリケーションサーバは、クライアントアプリケーションとのセキュアなかつ認証されたセッションを確立するように構成される。アプリケーションサーバは、第１のアンチクローンコードを、前記セッションを通じてクライアントアプリケーションに送信するように構成される。アプリケーションサーバは、クライアントアプリケーションが送信した要求が、認証情報及び第１のアンチクローンコードを用いて正しく生成されたことを検証するように適合される。アプリケーションサーバは、検証に成功した場合のみ、サービスにアクセスする次の試みに必要な第２のアンチクローンコードを、クライアントアプリケーションに送信し、前記第１のアンチクローンコードを非活性化するように構成される。

【0014】

有利には、アプリケーションサーバは、クライアントアプリケーションに関連付けられた復旧データを登録段階において記録するように構成することができ、クライアントアプリケーションは、ユーザに割り当てることができる。アプリケーションサーバは、検証に失敗した場合に、ユーザに識別データの送信を要求するように構成することができ、識別データが復旧データに対応している場合に、アプリケーションサーバは、サービスへのアクセスを許可し、クライアントアプリケーションに、サービスにアクセスする次の試みに必要な新しいアンチクローンコードを送信するように構成することができる。

【0015】

有利には、アプリケーションサーバは、一度に１つのクライアントエンティティによるサービスへのアクセスを許可するように構成することができ、アプリケーションサーバは、クライアントアプリケーションに関連付けられた復旧データを、登録段階において記録するように構成することができ、クライアントアプリケーションは、ユーザに割り当てることができる。クローン化されたクライアントアプリケーションが、クライアントアプリケーションに対する盗まれたアンチクローンコードを用いることによりサービスへのアクセスが認められる場合、アプリケーションサーバは、ユーザに識別データの送信を要求するように構成することができる。識別データが復旧データに対応している場合に、アプリケーションサーバは、クローン化されたクライアントアプリケーションによるサービスへのアクセスを取り除き、クライアントアプリケーションによるサービスへのアクセスを許可し、クライアントアプリケーションに、サービスにアクセスする次の試みに必要な新しいアンチクローンコードを送信するように構成することができる。

【0016】

有利には、アプリケーションサーバは、前記第１及び第２のアンチクローンコードがクライアントアプリケーションによりパスワード又はキーとして用いられることを確認するように構成することができる。

【0017】

有利には、アプリケーションサーバは、クライアントアプリケーションが組み込まれたデバイスのフィンガープリントを記録するように構成することができ、アプリケーションサーバは、前記認証情報がフィンガープリントを含むことを確認するように構成することができる。

【0018】

本発明の別の目的は、サービスにアクセスするように設計されたクライアントアプリケーションであり、前記クライアントアプリケーションは、第１のサーバとのセキュアなかつ認証されたセッションを確立するように構成される。クライアントアプリケーションは、第２のサーバに、サービスへのアクセス要求を送信するように構成され、クライアントアプリケーションは、セッションを通じて前記第１のサーバによりあらかじめ提供された認証情報と第１のアンチクローンコードの両方を用いて前記要求を生成するように構成される。クライアントアプリケーションは、前記要求が前記第２のサーバにより正常に受け入れられた場合に、サービスにアクセスする次の試みに必要な第２のアンチクローンコードを前記第１のサーバに要求するように構成される。

【0019】

有利には、第１のサーバは、クライアントアプリケーションに関連付けられた復旧データを格納することができ、クライアントアプリケーションは、ユーザに割り当てることができる。前記クライアントアプリケーションは、前記要求が前記第２のサーバにより拒絶された場合に、ユーザにより提供され、第１のサーバによる復旧データとの照合が意図された識別データに基づくアンチクローンコードの更新プロセスの開始を前記第１のサーバに要求するように構成することができる。

【図面の簡単な説明】

【0020】

本発明の他の特徴及び利点は、本発明の幾つかの好適な実施形態についての以下の説明を、対応する添付図面を参照しながら読むことにより、更に明解になるであろう。

【0021】

【図1】本発明によるサーバとのやりとりの第１の例を示すフローチャート。

【図2】クローン化されたアプリケーションが本物のクライアントアプリケーションの前にサービスへのアクセスに成功した場合の、本発明によるサーバとのやりとりの一例を示すフローチャート。

【図3】クローン化されたアプリケーションが、本物のクライアントアプリケーションがサービスへのアクセスに成功した後にサービスにアクセスしようとする場合の、本発明によるサーバとのやりとりの一例を示すフローチャート。

【図4】クローン化されたアプリケーションが、本物のクライアントアプリケーションがサービスにアクセスしようとしているのと同時にサービスにアクセスしようとする場合の、本発明によるサーバとのやりとりの一例を示すフローチャート。

【図5】本発明によるクライアントアプリケーション、ユーザ及びサーバを含むシステムの一例。

【図6】ＩＰマルチメディアサブシステム（ＩＭＳ）フレームワークにおける、本発明による本物のクライアントアプリケーションのサーバへの登録を示す図の一例。

【図7】ＩＰマルチメディアサブシステム（ＩＭＳ）フレームワークにおける、本発明による公称サービスアクセスを示す図の別の例。

【図8】ＩＰマルチメディアサブシステム（ＩＭＳ）フレームワークにおける、本発明によるクローンが検出された場合のパスワード管理を示す図の別の例。

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

【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】

第５のステップにおいて、ＨＳＳは、パスワードＰｗｄ＿Ｎ＋１及びクライアント識別子から新しいハッシュＨ（Ａ１＿Ｎ＋１）を生成する。そしてＨＳＳは、この新しいハッシュＨ（Ａ１＿Ｎ＋１）をＳ−ＣＳＣＦ（ＩＭＳコアとも呼ばれる）に送信する。

【0068】

ここで、ＩＭＳクライアントは、サービスへの次のアクセスに必要な新しいアンチクローンコードを有している。

【0069】

第６のステップに示されるように、ＩＭＳクライアントは、サービスにアクセスする次の試みのために、ハッシュＨ（Ａ１＿Ｎ＋１）に基づいてＳ−ＣＳＣＦへの認証を行う。

【0070】

図８は、本発明の一例によるＩＰマルチメディアサブシステム（ＩＭＳ）フレームワークにおいてクローンが検出された場合のサービスアクセスの管理を示している。

【0071】

第１のステップにおいて、現在活性なパスワードＰｗｄ＿Ｎに基づいてＩＭＳ登録が不成功に終わったと仮定する。換言すれば、Ｓ−ＣＳＣＦに対するＩＭＳクライアントの認証が失敗した。好適な例において、ＩＭＳクライアントは、ＡＣＣサーバに要求を送信することによりパスワード変更を開始する。

【0072】

代替的に、サーバ主導で現在のパスワードＰｗｄ＿Ｎを新しいパスワードに置き換えることができる。

【0073】

どちらの場合も、アンチクローンコードの更新は、ＩＭＳクライアントとＡＣＣサーバの間に確立されたセキュアチャネルを通じて回復モードで行われる。

【0074】

第２のステップにおいて、ＩＭＳクライアントは、タブレットのフィンガープリントＦＰを取得し、認証データをＡＣＣサーバに送信する。この認証データによって、ＡＣＣサーバは、ＩＭＳクライアントがフィンガープリントＦＰ及び個人認証情報ＰＣを知っていることを確認することができる。例えば、認証データは、フィンガープリントＦＰに連結された個人認証情報ＰＣを含むことができる。

【0075】

第３のステップにおいて、ＡＣＣサーバは、受信した認証データを検証する。ＡＣＣサーバは、検証に成功した場合は新しいパスワードＰｗｄ＿Ｎ＋１を生成し、そうでない場合は、プロセスは中断する。

【0076】

第４のステップにおいて、ＡＣＣサーバは、新しいパスワードＰｗｄ＿Ｎ＋１を、セキュアチャネルを介してＩＭＳクライアントに、そしてＨＳＳに送信する。

【0077】

第５のステップにおいて、ＨＳＳは、パスワードＰｗｄ＿Ｎ＋１及びクライアント識別子から新しいハッシュＨ（Ａ１＿Ｎ＋１）を生成する。そしてＨＳＳは、この新しいハッシュＨ（Ａ１＿Ｎ＋１）をＳ−ＣＳＣＦ（ＩＭＳコアとも呼ばれる）に送信する。

【0078】

ここで、ＩＭＳクライアントは、サービスへの次のアクセスに必要な新しいアンチクローンコードを有している。

【0079】

第６のステップに示されるように、ＩＭＳクライアントは、サービスにアクセスする次の試みのために、ハッシュＨ（Ａ１＿Ｎ＋１）に基づいてＳ−ＣＳＣＦへの認証を行う。

【0080】

たった１つの例に示された上記の任意選択的な事項の全てが本発明のいずれの実施形態にも適用可能であることに留意されたい。

【0081】

本発明は、攻撃者にとっての攻撃ウィンドウを削減することを可能にする。攻撃者が本物のクライアントアプリケーションをクローン化し、アンチクローンコードの次の変更まで接続できない場合、サーバは特定のクライアントによるサービスへの同時アクセスを拒否することが知られているため、クローン化されたアプリケーションは役に立たないままである。また、攻撃者がサービスに接続することに成功し、本物のクライアントが接続を望む場合は、クローンアプリケーションを検出し、切断することができる。

【0082】

本発明により、純粋なソフトウェアアプリケーションのためのログイン／パスワードをユーザに便利な方法で実装することができる。パスワードは、アプリケーション自体に格納することができ、ユーザにパスワードの入力を要求することなく目的とするサービスへのアクセスを可能にする。ユーザは、クローンが検出された場合のみ個人認証情報（識別データ）の提供を要求される。

【0083】

本発明の範囲内において、上記の実施形態は非限定的な例として提供されていることが理解されなければならない。特に、クライアントアプリケーションは、多くのサービスにアクセスすることを可能にする多数の認証情報を含むことができる。

【0084】

図５〜８に示されたサーバのアーキテクチャは、例として提供されているに過ぎない。特に、サーバＳＶは、唯一のマシン又は複数のマシンに実装することができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】