JP6704919B2 - 支払いトークンのセキュリティを確保する方法 - Google Patents

Description

本発明の分野は、支払い手段（instrument de paiement）から導出される支払いトークンのセキュリティを確保する方法と、移動体端末と、支払いトークンを生成するサーバと、に関する。

銀行データのセキュリティ確保の高度化および支払いネットワークにおける取引を検証する手法にも関わらず、支払いカード詐欺（fraudes a la carte de paiement）は、今日において未だに存在する。支払いカードは、電子チップに格納された個人コードを検証したり銀行取引のデータを検証する動的アルゴリズムを用いたりすることによって保護される。

デジタルエコノミーの発展に伴い、インターネットでなされる取引のシェアは、日々増加している。また、新しいトレンドは、携帯電話の移動体支払いアプリケーションにホストされた（hebergee）仮想支払いカードの統合（l'integration）である。加入者は、このように、近距離通信（ＮＦＣ）技術を用いた近距離支払いに使用できる非物質化された型の銀行カードを有する。

この新たなエコノミーは、銀行組織にとって機会であるが、この新たなエコノミーには、銀行データの露出による不正（fraudes）、具体的には、銀行カードの番号、セキュリティ暗号およびカードの有効期限の露出による不正という無視できないリスクがある。近距離支払い技術に反対する人々は、近距離通信における銀行データの脆弱性を特に懸念している。というのは、データは、暗号化されずに伝送されるためである。具体的には、取引で使用されるデータを傍受可能な装置が存在する。

さらに、オンラインの商取引者のサーバからハッカーが銀行データを盗むことは、珍しいことではない。

そのような銀行詐欺（fraudes bancaires）に対し、銀行組織は、銀行カードの加入者の銀行データの露出を防止するソリューションを探している。近年、セキュア銀行サーバに銀行データをホストするシステムと、加入者の支払いカードから導出される個々の支払いトークンを生成するソリューションとが存在する。そのようなトークンは、例えばそれらが限られた期間において単一の取引者に対してのみ有効であり得るまたは最大取引量が定められ得るなどといった使用制限を含み得るという点で、制限的である。そのような支払いソリューションは、ホストカードエミュレーション（ＨＣＥ）と称される。トークンデータが盗まれた場合において、金銭的な露出が低減される。

ＨＣＥアーキテクチャは、変化付与アルゴリズム（algorithmes de diversification）によって銀行カードから導出されるトークンを生成するサーバと、ポータブル端末（例えば携帯電話またはタブレット）の使用環境（l'environnement d'exploitation）でホストされる銀行アプリケーションにトークンを提供する遠隔サーバと、支払いトークンに対応する加入者の銀行データを特定可能なトークン検証サーバと、を必要とする。

このアーキテクチャでは、銀行カードの加入者は、種々の形式の銀行カード、電子チップまたは磁気ストライプを有する物理的カード、携帯電話における電子ウォレット（一般的に“モバイルウォレット”と称される）にホストされた仮想カード、または、遠隔サーバ（一般的に“クラウドウォレット”と称される）にホストされた仮想カードを有し得る。米国特許出願公開第２０１３／０２００１４６号明細書は、遠隔サーバに仮想銀行カードをホストするソリューションを開示している。

しかしながら、支払いトークンに使用上の制限があっても、それは、それが携帯電話に提供される時点とそれが使用される時点との間において窃盗の危険に曝される（expose）。事実、加入者は、複数の支払いのために、トークンの束が電話に提供されるようにする可能性がある。

さらに、電話の製造者および銀行組織は、携帯電話における電子ウォレットであってセキュアチップの制約を受けることのないものを提案し、ソフトウエアのみによる支払いソリューションを提案することを望んでいる。そのようなソリューションは、データの窃盗の危険に特に曝される。

このように、特にトークンがセキュアチップにホストされていない場合において、携帯電話における支払いトークンのセキュリティを確保する新たな手法を見出す必要性が存在する。

より正確には、本発明は、支払いアプリケーションによって移動体端末にホストされ得る加入者の支払い手段から導出される第１トークンのセキュリティを確保する方法を提供する。

本発明では、方法は、以下の連続的な（successives）工程を備える：
・第１に移動体端末の識別子と支払い手段との、第２に個人暗号と支払い手段との、ペアリング；
・支払いアプリケーションへの第１トークンの提供；
・支払い取引に関するデータの支払いアプリケーションによる受信；および
・少なくとも第１トークン、取引データ、端末の識別子および個人暗号を暗号化することによるセキュア第２支払いトークンの生成。

より正確には、ペアリングは、支払いアプリケーションと遠隔認証サーバとの間の成功した認証プロトコルの後に実行される。

変形例では、ペアリングは、支払い手段が支払いアプリケーションに登録されるときに実行される。

変形例では、第１トークンは、支払い手段に添付された（attache）銀行口座番号を表すデータから導出されるランダムデータである。

変形例では、第１トークンは、第１トークンを生成するサーバから受信した一時的な鍵を利用して暗号化される。

変形例では、方法は、さらに、支払いアプリケーションによる端末の識別子および個人暗号の生成であって、取引に関するデータの受信を契機とする生成を備える。

支払いアプリケーションによる端末の識別子および個人暗号の生成は、変形例では個人パスワードが入力された状態における端末のセキュアメモリの読み取りを備え、別の変形例では個人パスワードが入力された状態における暗号計算の実行を備える。

変形例では、支払いアプリケーションによる端末の識別子および個人暗号の生成は、支払い取引中における加入者を認証するリクエストを契機に実行され、支払い取引は、ＩＳＯ／ＩＥＣ１４４４３規格に準拠した非接触支払い取引である。

好ましくは、銀行取引の実行中において、識別子および個人暗号は端末の揮発性メモリに格納されている。

第１トークンの提供は、端末の不揮発性メモリへの第１トークンの書き込みを備え得る。

また、本発明は、加入者の支払い手段から導出される第１トークンを処理する処理エージェントと、支払い取引に関するデータを受信する手段と、を備えた支払いアプリケーションを含む移動体端末を提供する。支払いアプリケーションは、さらに、
・移動体端末の識別子および個人暗号と支払い手段とをペアリングするペアリング手段；を含み、
・トークンを処理する処理エージェントは、少なくともトークン、取引データ、移動体端末の識別子および個人暗号を暗号化することによってセキュア第２支払いトークンを生成する手段を含む。

変形例では、支払いアプリケーションは、さらに、支払いアプリケーションによって移動体端末の識別子および個人暗号を生成する手段を含む。

また、本発明は、第１トークンを生成するサーバであって、サーバは加入者の支払い手段から導出される第１トークンを生成する手段を備え、サーバはさらに
・移動体端末の識別子および加入者の個人暗号と支払い手段とをペアリングする手段；
・少なくとも第１トークン、取引データ、移動体端末の識別子および個人暗号を暗号化することによって生成されたセキュア第２支払いトークンを検証する手段、を備えることを特徴とするサーバを提供する。

変形例では、移動体端末の識別子および加入者の個人暗号は、認証サーバから受信される。

変形例では、第１トークンは、支払い手段に添付された銀行口座番号を表すデータに少なくとも基づいて、乱数生成装置を利用して生成される。

本発明によれば、個人暗号によりユーザと事前にペアにされかつ固有の識別子によって登録されたユーザの移動体端末と事前にペアにされることで、支払いトークンの使用のセキュリティが確保される。端末およびユーザの両方の識別データを統合することにより、銀行取引検証サーバが、登録された端末および登録されたユーザによってトークンが使用されたことを検証できる。

本発明の他の特徴および利点は、非限定的な例として提示され添付の図面に示された本発明の実施形態に関する以下の詳細な説明を読むことでより明らかとなる。

図１は、ＨＣＥ型の支払いアーキテクチャのエコシステムを示す。 図２は、セキュア支払いトークンをホストおよび生成する携帯電話のソフトウエア使用環境を示す。 図３は、加入者用の支払いトークンを提供および生成する前におけるユーザおよび移動体端末のペアリングのシーケンスの流れを示す。 図４は、銀行取引を実行しセキュア支払いトークンを生成する際のシーケンスの流れを示す。

本発明は、支払い手段の加入者にセキュア支払いトークンを提供する支払いシステムの範囲で適用される。支払いシステムは、ＨＣＥという頭字語で一般的には呼ばれる。

図１に、ＨＣＥ支払いソリューションのエコシステムを示す。それは、銀行エンティティ１６を提供する。銀行エンティティ１６は、銀行または支払いサービスであり、支払い手段１７を発行できる。支払い手段１７は、銀行カード、インターネットポータルを介したオンライン支払いサービス、または加入者の移動体端末１２に提供され得る支払いトークンを利用した支払いサービスという形式の複数の支払いプロダクト（produits de paiement）を備え得る。

支払い手段１７は、
・支払い手段に添付された加入者の銀行データ、例えば口座番号と、個人データ；
・支払い手段を使用する基準、具体的には、有効期限、地理的領域、取引上限；および
・銀行取引のデータの検証を可能とするセキュリティデータ、例えば支払いカードに組み込まれたセキュリティ暗号または電子セキュリティ機構；によって定まる。

支払いトークンを受信する移動体端末１２では、セキュリティ機構は、端末に結合されたセキュアモジュール、例えばＮＦＣ型の集積回路などでホストされていてもよく、または、トラステッド実行環境（ＴＥＥ）として知られているセキュア環境でホストされていてもよい。後者の場合、ソリューションは、支払いアプリケーションを実行する移動体端末の使用環境のアプリケーション領域が種々のセキュリティ機構によって信頼できると考えられる完全なソフトウエア型のソリューションである。それらの機構は、メモリ領域を検証するものであってもよく、または、支払いプロファイルもしくは支払いアプリケーションをインストールする認証プロコトルであって遠隔認証サーバ１０を用いて使用する認証プロトコルであってもよい。本発明の範囲で用いられるセキュア支払いトークン１０４を生成可能な移動体端末１２の機能は、以下でより詳細に説明される。

好ましくは、移動体端末１２は、携帯電話ネットワークを介して、電話ネットワークを介したＩＰ型データネットワーク上で、または、Ｗｉ−Ｆｉなどの中距離ネットワークを介したＩＰ型データネットワーク上で、遠隔でデータを受信および送信する通信手段を有する。

本発明の範囲では、認証サーバ１０は、銀行組織１６または認証サービスの第三者プロバイダーによって管理され得るようになっている。認証サーバ１０は、移動体端末１２と暗号化手段１０２を交換する。例えば、暗号化手段１０２は、セキュア交換プロトコルの実行を可能にする（permettant d'operer）、暗号セッション鍵、一時的な取引番号、または、暗号化アルゴリズムである。上記の暗号化手段は、ハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）、カードアプリケーションツールキットトランスポートプロトコル（ＣＡＴ＿ＴＰ）、または、ショートメッセージサービス（ＳＭＳ）を使用し得るセキュアチャネルを介して交換される。

さらに、認証サーバ１０は、認証サーバ１０が銀行エンティティ１６によって管理される（est opere）場合に、セキュア遠隔無線データ通信ネットワークを介してまたは有線通信ネットワークを介して、銀行エンティティ１６と情報を交換し得る。銀行エンティティ１６は、加入者の移動体端末１２と認証サーバとの間の認証プロトコルの必要のために、加入者の個人の銀行データを認証サーバ１０に伝送できる。

支払い手段１７から導出されるトークン１０３を生成するトークン生成サーバ１１も提供される。サーバ１１は、支払い手段１７に添付された銀行データ１０５からトークン１０３を生成する暗号化手段を有する。

ランダムデータ生成装置は、銀行データ１０５とカウンタなどの変化付与手段または導出手段とから、トークン１０３を生成できる。サーバ１１では、トークン１０３を生成するために他の変化付与手段が使用され得る。

なお、ランダムデータ生成装置によって使用される銀行データ１０５は、セキュア支払いトークン１０４における情報に基づいて、トークン生成サーバ１１またはパートナー検証サーバによって再現され得るようになっている。このため、銀行データは、サーバ１１において、保護され、秘密に保たれる。

さらに、トークン１０３を生成するサーバ１１は、認証サーバ１１が銀行エンティティ１６によって管理される場合に、セキュア遠隔無線データ通信ネットワークを介してまたは有線通信ネットワークを介して、銀行エンティティ１６と情報を交換し得る。このため、銀行エンティティ１６は、加入者の移動体端末１２と認証サーバとの間の認証プロトコルの必要のために、加入者の個人の銀行データを認証サーバ１０に伝送できる。

さらに、トークン生成サーバ１１は、サーバ１０および１１が同じオペレータによって管理される場合に、セキュア遠隔無線データ通信ネットワークを介してまたは有線通信ネットワークを介して、認証サーバ１０と情報を交換し得る。認証サーバ１０は、トークン１０３を生成するサーバ１１と暗号化手段１０１を交換する。例えば、暗号化手段１０１は、端末１２とのセキュア交換プロトコルの実行を可能にする、暗号セッション鍵、一時的な取引番号、または、暗号化アルゴリズムである。

具体的には、端末１２とのセキュア交換プロトコルは、ＨＴＴＰＳ、ＣＡＴ＿ＴＰまたはＳＭＳプロトコルを使用し得るセキュアチャネルを介してトークン１０３を交換することを可能とする。

ユーロペイ、マスターカード、ビザ（登録商標）（ＥＭＶ）規格の仕様に従った加入者の銀行データおよび銀行取引データ、例えば従来型の取引データおよびセキュア支払いトークン、を伝送するために、セキュア支払いネットワーク１５が提供され得る。セキュア支払いネットワーク１５は、銀行支払い取引の実行を担当する支払いサービスオペレータ１４によって管理される。

支払いサービスオペレータは、セキュアネットワーク１５を使用して、支払い端末または遠隔の支払いサーバを利用して商取引者１３から受信した取引データを伝送する。ネットワーク１５は、支払い端末間のセキュア無線通信ネットワークまたは有線通信ネットワークを使用する。

図２に、端末１２をより詳細に示す。それは、支払いアプリケーション２４を有し、支払いアプリケーション２４は、移動体端末１２の使用環境でホストされまたはセキュアモジュールにホストされており、例えば組み込み型ユニバーサル集積回路カード（ｅＵＩＣＣ）にホストされている。

移動体端末１２は、リードオンリーメモリ（ＲＯＭ）、電気的に消去可能なリードオンリーメモリ（ＥＥＰＲＯＭ）またはフラッシュ型の不揮発性メモリであって、パラメータとアプリケーションの実行コードと支払いトークンのセキュリティを確保する方法を実行する命令を有するコンピュータプログラムとを格納するものであり、例えば、端末の使用環境、アプリケーション、または、アプリケーションによって使用され得る特定の機能のライブラリを格納するものである不揮発性メモリを有する。

具体的には、端末は、アプリケーションプログラミングインタフェース（ＡＰＩ）と称される機能、クラスまたは方法のライブラリであって、トークン生成サーバ１１との交換を実行するため、支払い端末１３を用いた支払い取引を実行するため、および認証サーバ１０を用いた認証のためのライブラリを有する。アプリケーション２４は、ＡＰＩによって提供される機能を呼び出し得る。

また、移動体端末は、銀行取引データまたはセキュア支払いトークン１０４などの一時的なパラメータを格納するランダムアクセスメモリ（ＲＡＭ）を有する。ＲＡＭは、支払いトークンのセキュリティを確保する方法を実行する命令を有するコンピュータプログラムの実行中に生成される変数およびパラメータ（variables et parametres）を、それが実行されているときに格納するのに適したレジスタを含む。

また、端末１２は、加入者用のマンマシンインターフェイスであって、データを入力して表示するものであり、例えば個人識別番号（ＰＩＮ）を入力し支払いアプリケーション２４と相互作用するものであるマンマシンインターフェイスを有する。支払いアプリケーションは、端末１２を支払い端末１３の近くに移動させるリクエスト、個人コードを入力するリクエスト、または、支払い手段を選択するリクエストなどのリクエストを、移動体端末のスクリーンに表示し得るようになっている。

移動体端末は、移動体端末１２のアプリケーションの機能を実行するプロセッサを含む。

支払いアプリケーション２４は、加入者の支払い手段１７から導出されるトークン１０３を処理する処理エージェント２３と、支払い取引に関するデータを受信する手段２５と、を有する。処理エージェント２３は、支払いアプリケーション２４の機能であり、トークン生成サーバ１１によって送信されたトークン１０３が受信され移動体端末の不揮発性メモリで格納され得るようにする。処理エージェント２３は、トークン１０３を生成するサーバ１１と相互作用するＡＰＩソフトウエア機能を利用するソフトウエアアプリケーションである。

さらに、支払いアプリケーション２４は、１または複数の支払い手段１７をホストする。仮想支払いカードは、支払いカードのプロファイルに固有のアプリケーションの形式で格納されるものであり、アプリケーション識別子を利用して格納され得る。支払い手段は、支払いトークンの最初の提供の前に支払いアプリケーションに格納される。

銀行の取引データを受信する手段２５は、支払いアプリケーション２４の機能であり、支払い端末１３との通信を可能にする。受信機能は、ＩＳＯ／ＩＥＣ１４４４３規格に準拠した非接触交換プロトコルを制御する（piloter）ことができ、取引に関するデータをメモリに格納することができ、支払い端末１３にレスポンスを送り返すことができる。

また、支払いアプリケーション２４は、移動体端末の識別子２２および個人暗号２１の両方と支払い手段とをペアリングするペアリング手段２６を含む。それは、認証サーバ１０およびトークン生成サーバ１１を用いた認証のために、ＡＰＩソフトウエア機能を呼び出す機能である。具体的には、ペアリングは、端末１２に割り当てられる識別子２２および加入者に割り当てられる個人暗号２１を生成する手段を含む。

端末の識別子２２は、例えば鍵を用いて暗号化されるなど安全な態様で格納されるように、認証サーバ１０によって生成され端末１２に伝送され得る。変形例では、識別子２２は、端末１２の国際移動体加入者識別（ＩＭＳＩ）番号であり認証サーバ１０に伝送され得る。それは、ペアリング中に端末１２によって、または、銀行エンティティ１６によって、伝送され得る。

個人暗号２１は、パスワードであってもよく、個人コードであってもよく、加入者および認証サーバによって知られたデジタルバイオメトリックプリントであってもよい。また、個人暗号は、ＰＩＮまたはバイオメトリック認証を用いた認証に成功した後に関数によって生成されてもよい。変形例では、個人暗号２１は、端末１２および認証サーバだけに知られた乱数から生成されてもよく、暗号化鍵によって生成されてもよい。また、“ソルティング”と称される知られた方法は、支払いアプリケーション２４および認証サーバ１０の両方によって個人暗号２１を生成することを可能にする。

ペアリングは、支払いアプリケーション２４が支払い手段１７と端末の識別子２２および個人暗号２１との結合を完了させたときに有効である。同様に、生成サーバ１１は、識別子２２および暗号２１を支払い手段１７と結合させる。サーバ１１におけるペアリングを可能にする端末１２の識別子２２および個人暗号２１は、端末１２および加入者を用いた認証プロトコルを先に成功させた認証サーバ１０によって伝送される。

好ましくは、ペアリングは、移動体端末において支払い手段１７が登録されるときに実行される。登録は、移動体端末１２の不揮発性メモリへのデジタル支払いプロファイルのインストールに対応する。

端末のペアリングのセキュリティは、認証サーバ１０を用いた認証によって確保される。

また、トークン１０３を処理するエージェント２３は、少なくともトークン１０３、取引データ、移動体端末の識別子２２および個人暗号２１を暗号化することによってセキュア支払いトークン１０４を生成する手段を備える。暗号化の実行およびセキュア支払いトークン１０４の取得の両方は、トークン暗号化鍵および鍵付ハッシングメッセージ認証コード（ＨＭＡＣ）型の暗号化アルゴリズム、例えばｉｎｉｔｉａｔｉｖｅ ｆｏｒ ｏｐｅｎ ａｕｔｈｅｎｔｉｃａｔｉｏｎ（ＯＡＴＨ）の勧告に基づいたものである、を用いることによって実行される。暗号化アルゴリズムは、トークン生成サーバ１１との相互認証を可能とする。暗号化鍵は、トークン生成サーバ１１によって支払いアプリケーション２４に伝送される。それが使用されていないときは、鍵は移動体端末のセキュア領域に、暗号化された形式または暗号化されていない形式で格納される。暗号化鍵は、一時的なものであってもよい。それは、単一の支払いトークン１０３と関連づけられていてもよく、支払いトークン１０３の束に関連づけられていてもよく、または、時間的に制限されていてもよい。

より正確には、トークン１０３のデータ、支払い端末１３に関する取引データ（取引口座、取引番号）、端末の識別子２２および個人暗号２１は、（１２８ビットの長さを有し得る）データブロックにおいて連結されている。この連結されたデータは、暗号化鍵を用いた暗号化アルゴリズムによって暗号化される。支払いアプリケーション２４によって生成されるセキュア支払いトークン１０４は、暗号の形式であり、銀行取引を検証するリクエストを伴っており、少なくとも取引データを備えている。

なお、セキュア支払いトークン１０４は、オフラインモードで生成され得る、すなわち、取引中にトークン１０３を生成するサーバ１１と接続することは必須ではない。

さらに、処理エージェント２３は、セキュア支払いトークン１０４を従来の銀行取引プロトコルに挿入する手段を含む。例えば、それは、ＥＭＶ取引プロトコルにおける標準化されたデータフィールドに挿入され得る。

このため、セキュア支払いトークン１０４は、支払いネットワーク１５との通信プロトコルを改変することなく支払い端末によって伝送され得る。

トークン１０３を生成するサーバ１１は、支払い手段１７から導出されるトークンを生成する手段を含む。導出されるトークンは、ランダムデータである。トークン１０３は、（口座番号と関連づけられた）支払い手段１７の銀行データ１０５と、変化付与（diversifiant）と、から生成される。変化付与は、１または複数の銀行取引の妥当性、時間の長さの妥当性、取引上限の妥当性などの、サーバ１１によって定められた使用制限基準を用いた支払い取引の認証に対応する（represente）。

また、本発明の範囲では、サーバ１１は、移動体端末の識別子２２および加入者の個人暗号２１と支払い手段１７とをペアリングする手段を含む。その銀行データベースでは、それは、具体的には、：支払い手段１７に関連づけられた（口座番号に関連づけられた）銀行データ１０５；ならびに、支払い手段１７に割り当てられた端末１２の識別子２２および支払い手段１７に割り当てられた加入者の個人暗号２１、を含む。

また、それは、少なくともトークン１０３、取引データ、移動体端末の識別子２２および個人暗号２１を暗号化することにより生成されたセキュア支払いトークン１０４を検証する手段を含む。具体的には、それは、銀行取引を検証するリクエストによって伝送される取引データに基づいて検証目的の第２支払いトークンを生成する支払いアプリケーション２４の暗号化手段に対して相補的な暗号化手段（moyens cryptographiques complementaires）を含む。検証手段は、少なくともトークン１０３、取引データ、移動体端末の識別子２２および個人暗号２１を暗号化することによって検証暗号を生成する手段を備える。セキュア支払いトークン１０４と検証暗号との比較により、取引の認証または非認証が可能となる。

なお、移動体端末の識別子２２および加入者の個人暗号２１は、銀行取引を検証するために、認証サーバ１０から受信される、または、セキュア支払いトークン１０４の受信時に動的に生成され得る。

図３は、支払い手段と端末１２の識別子２２および個人暗号２１とをペアリングする工程のシーケンスの流れを示す。ペアリングは、支払い手段１７を加入者の端末１２の支払いアプリケーション２４に登録する際に実行される。

登録リクエスト工程３１において、加入者は、その支払いアプリケーション２４を用いて、支払い手段１７の使用のための登録を行う。登録リクエストは、支払い手段を運用する（operatrice）銀行エンティティ１６に伝送される。

変形例では、登録リクエスト工程３１は、ウェブポータルを用いて実行されてもよく、また、銀行エンティティのブランチ（agence）で直接的に実行されてもよい。

工程３２において、銀行エンティティ１６は登録リクエストをイニシエートする（initie）。工程３２において、認証サーバ１０を用いて認証をイニシエートするために、識別子および使い捨ての個人パスワードが生成され加入者に伝送され得る。並行して、識別子およびパスワードは、工程３３において支払いトークンを生成するサーバ１１に伝送され、次いで工程３４において認証サーバ１０に伝送される。

また、工程３３において、銀行エンティティ１６は、支払いをすることを可能にする支払い手段１７の銀行データ（具体的には、銀行口座番号および制限基準）を伝送する。

工程３５において、認証サーバ１０は、認証プロトコルを開始し（amorce）、ユーザの支払いアプリケーション２４からペアリングリクエストを受信するのを待つ。暗号化鍵のセットおよび認証取引識別子が準備され、支払いアプリケーションと認証サーバの間で端末識別子および個人暗号をセキュアに伝送することが可能となる。

工程３７において、支払いアプリケーション２４は、ペアリングリクエストをイニシエートし、認証プロトコル３６におけるリクエストおよびレスポンスを生成するのに必要な復号化動作および暗号化動作を実行する。

並行して、工程３８において、認証サーバ１０は、移動体端末の識別子と支払い手段との間および加入者の個人暗号と支払い手段との間のペアリング３６のための認証プロトコルを実行するための相補的な動作（operations complementaires）を実行する。

変形例では、認証プロトコルは、支払いアプリケーション２４を呼び出す（en direction de l'application de paiement 24）認証サーバによってイニシエートされ得る。

ペアリング３６の実行に対応する認証プロトコルにおいて、端末１２の識別子２２および個人暗号２１が、サーバ１０によってまたは支払いアプリケーション２４によって生成され、それらは相互に交換される。

なお、ペアリング３６は、端末の識別子２２および個人暗号２１を認証サーバ１０に格納すること、または、端末の識別子２２および個人暗号２１を生成する計算機能を認証サーバ１０に格納することを備える。

変形例では、端末の識別子２２および個人暗号２１は、各銀行取引において動的に生成される。支払いアプリケーション２４およびサーバ１０は、認証段階３６において交換される生成手段を有する。これは、特定の認証アプリケーションであってもよく、暗号化アルゴリズムであってもよい。また、識別子２２および個人暗号２１を生成する上記手段は、アプリケーションポータルを介して取得されてもよく、または、支払いアプリケーション２４に事前にインストールされてもよい。

支払いアプリケーション２４は、ＩＳＯ／ＩＥＣ１４４４３規格に準拠して銀行取引を実行するセキュアＮＦＣモジュールに銀行アプリケーションのプロファイルをインストールすることを備えたセキュアインストールプロトコルによってインストールされる。

ペアリング動作３６のための認証プロトコルが正常に終了すると、工程３９において、認証サーバ１０は、支払いトークン１０３を生成するサーバ１１に、暗号化手段１０１の一部として、端末の識別子２２および個人暗号２１を知らせるように動作する。これは、支払いトークンを用いて支払い取引を検証する目的のためである。

工程４０において、サーバ１１は、端末の識別子２２および個人暗号２１をインストールする、または、加入者の支払い手段１７と関連づけられた生成手段をインストールする。

工程４１において、銀行エンティティ１６は、セキュア支払いトークンを利用して、認証の成功および支払いソリューションを機能させる（pour le fonctionnement）ペアリングを知らされる。

図４は、銀行取引においてセキュア支払いトークン１０４を生成する際のシーケンスの流れを示す。

第１工程５０では、支払いアプリケーション２４は、トークンの提供のリクエストを作成する。加入者の認証の工程は、認証サーバ１０によって実行される。この実行は、識別子および個人パスワードを検証することによって、または、変形例ではペアリング工程において生成された端末１２の識別子２２および個人暗号２１を利用して、なされる。

認証サーバ１０を用いた認証が成功である場合、アプリケーション２４は、トークン生成サーバ１１からのトークン１０３の提供をリクエストする工程５１を実行する。提供のリクエストは、例えばＨＴＴＰＳ、ＣＡＴ＿ＴＰ、または、ＳＭＳ通信プロトコルを使用する、支払いアプリケーション２４とサーバ１１との間のセキュア通信チャネルを用いて実行される。

工程５２において、トークン生成サーバ１１は、支払い手段１７から導出される第１トークン１０３を生成する。トークン１０３は、支払い手段１７に添付された銀行口座番号を表すデータ１０５から導出されるランダムデータである。このデータは、銀行口座番号であってもよい。トークン１０３は、銀行取引の番号、有効期限または取引の量などの使用制限基準によって定まるランダムデータである。支払い手段１７に添付された銀行口座番号を表すデータ１０５に少なくとも基づいて動作する乱数生成装置を使用することが好ましい。入力データを生成装置に提供するカウンタは、データ１０５に変化を付与することを可能にする。

工程５３において、サーバ１１は、工程５１において使用されたものと同じセキュアチャネルを介して、トークン１０３を支払いアプリケーション２４に伝送する。

工程５４において、支払いアプリケーション２４は、トークン１０３を、移動体端末１２の（不揮発性の）セキュアメモリ領域に格納する。処理エージェント２３は、トークン１０３を、メモリ領域であって該メモリ領域へのアクセスが認証サーバ１０を用いた認証を条件とされるメモリ領域に格納する。変形例では、トークン１０３は、暗号化された形式で伝送され、サーバ１１によって提供される鍵を用いて使用されるのを待つ。

工程５５において、銀行取引プロコトルが支払い端末１３を用いてイニシエートされる。アプリケーション２４は、取引リクエストを受信し、これらのリクエストに対するレスポンスを発行する。実行される取引は、例えばＩＳＯ／ＩＥＣ１４４４３規格に準拠した、非接触近距離通信（ＮＦＣ）支払い取引である。第１の交換において、取引量などの取引データが伝送され得る。

工程５６において、支払いアプリケーション２４は、端末の識別子２２および個人暗号２１の生成を実行する。この生成は、端末１２のセキュアメモリにおける読み取りであってもよく、または、暗号化または復号化などの暗号計算によるデータの生成であってもよい。好ましくは、生成５６は、個人パスワード（ＰＩＮ、フレーズ、指紋などのバイオメトリックデータの読み取り、または、虹彩のスキャニング）の入力および検証を条件とする。

工程５６において、銀行取引の実行中において、識別子２２および暗号２１は、端末１２の揮発性メモリに格納されていてもよい。銀行取引が実行された後に、不正の可能性に曝されないように、それらは順次に削除される。

なお、端末の識別子２２および個人暗号２１の生成５６は、ＩＳＯ／ＩＥＣ１４４４３規格に準拠した非接触支払い取引中における加入者を認証するリクエストを契機に実行され得る。

工程５７において、支払いアプリケーション２４は、セキュア第２支払いトークン１０４を生成する。支払いアプリケーション２４は、少なくとも第１トークン１０３、取引データ、端末の識別子２２および個人暗号２１を暗号化する。アプリケーション２４は、トークン処理エージェント２３の暗号化アルゴリズムを用いて、セキュア支払いトークン１０４を生成する。結果、暗号化アルゴリズムは、端末１２毎に固有であり加入者毎に固有であるセキュア支払いトークン１０４を生成する。

先のペアリングにおいて登録されておらず端末の識別子２２を再現できない他の端末によって支払いトークン１０４が使用された場合、セキュア支払いトークン１０４を検証するサーバ１１はこの状況を検出でき銀行取引を拒絶できる。

同様に、先のペアリングにおいて登録されておらず個人暗号２１を再現できない他の加入者によって支払いトークン１０４が使用された場合、セキュア支払いトークン１０４を検証するサーバ１１は、この状況を検出し銀行取引を拒絶できる。

セキュア支払いトークン１０４のフォーマットは、ハッシュ関数を用いるなどにより改変でき、その後、銀行取引に応じた（conforme）データフィールドに挿入できる。

その後、工程５８において、セキュア支払いトークン１０４は、銀行取引の実行中に支払い端末１３に伝送される。それは、ＥＭＶ規格で従来行われていたように、銀行取引のデータとともに、ＮＦＣ通信手段を介して近接場に伝送される。

その後、支払い端末１３は、取引を検証する目的で、支払いネットワーク１５を用いて、セキュア支払いトークン１０４を、支払いトークン１０３を生成するサーバ１１に伝送する。検証サーバ１１は、トークンを生成したサーバ１１とは別のものであってもよい。

同一の加入者が、第２移動体端末、例えば第１移動体端末が携帯電話である場合にはマルチメディアタブレット、を用いたペアリングを実行してもよい。第２移動体端末を用いたペアリングにおいて、サーバ１０は、第２端末の識別子を用いて、第２端末を支払い手段１７と関連づけてもよい。個人暗号２１は、同一であり得る。

検証サーバは、セキュア支払いトークン１０４を受信すると、支払いアプリケーション２４の処理エージェント２３と同じ暗号化計算を実行する。妥当性が検証されると（Une fois valide）、認証指令が、トークン１０３と関連づけられた手段１７の銀行データ１０５とともに、支払いネットワーク１５を介して銀行エンティティに伝送される。

なお、サーバ１１によって端末１２に伝送される第１トークン１０３は、複数の支払い取引に使用され得る。その使用は、複数の支払い取引の合計によって構成され得る、定められた期間、支払い取引の数、または、取引の量に制限され得る。

Claims (15)

1. 支払いアプリケーション（２４）によって移動体端末（１２）にホストされ得る加入者の支払い手段（１７）から導出される第１トークン（１０３）のセキュリティを確保する方法であって、以下の連続的な工程を備えることを特徴とする、ホストカードエミュレーションアーキテクチャによって実行される方法。
   ・第１に前記移動体端末（１２）の識別子（２２）と前記支払い手段との、第２に個人暗号（２１）と前記支払い手段との、ペアリング（３６）；
   ・前記支払いアプリケーション（２４）による、前記第１トークンを生成するサーバ（１１）への、前記第１トークン（１０３）の提供のリクエスト（５１）；
   ・前記リクエスト（５１）の後における、前記サーバ（１１）から前記支払いアプリケーション（２４）への前記第１トークン（１０３）の提供（５３）；
   ・支払い取引に関するデータの前記支払いアプリケーションによる受信（５５）；および・少なくとも前記第１トークン（１０３）、前記取引データ、前記端末の前記識別子（２２）および前記個人暗号（２１）を暗号化することによるセキュア第２支払いトークン（１０４）の生成（５７）。
2. 前記ペアリング（３６）は、前記支払いアプリケーション（２４）と遠隔認証サーバ（１０）との間の成功した認証プロトコルの後に実行されることを特徴とする、請求項１に記載の方法。
3. 前記ペアリング（３６）は、前記支払い手段（１７）が前記支払いアプリケーション（２４）に登録されるときに実行されることを特徴とする、請求項２に記載の方法。
4. 前記第１トークン（１０３）は、前記支払い手段（１７）に添付された銀行口座番号を表すデータ（１０５）から導出されるランダムデータであることを特徴とする、請求項１〜３のいずれか一項に記載の方法。
5. 前記第１トークン（１０３）は、前記第１トークン（１０３）を生成する前記サーバ（１１）から受信した一時的な鍵を利用して暗号化されることを特徴とする、請求項１〜４のいずれか一項に記載の方法。
6. 前記方法は、さらに、前記支払いアプリケーション（２４）による前記端末の前記識別子（２２）および前記個人暗号（２１）の生成（５６）であって、前記取引に関するデータの受信（５５）を契機とする生成を備えることを特徴とする、請求項１〜５のいずれか一項に記載の方法。
7. 前記支払いアプリケーション（２４）による前記端末の前記識別子（２２）および前記個人暗号（２１）の生成は、個人パスワードが入力された状態における前記端末（１２）のセキュアメモリの読み取りを備える、または、個人パスワードが入力された状態における暗号計算の実行を備えることを特徴とする、請求項６に記載の方法。
8. 前記支払いアプリケーション（２４）による前記端末の前記識別子（２２）および前記個人暗号（２１）の生成は、前記支払い取引中における前記加入者を認証するリクエストを契機に実行され、前記支払い取引は、ＩＳＯ／ＩＥＣ１４４４３規格に準拠した非接触支払い取引であることを特徴とする、請求項６または請求項７に記載の方法。
9. 前記取引の実行中において、前記識別子（２２）および前記個人暗号（２１）は、前記端末（１２）の揮発性メモリに格納されていることを特徴とする、請求項６〜８のいずれか一項に記載の方法。
10. 前記提供は、前記端末（１２）の不揮発性メモリへの前記第１トークン（１０３）の書き込みを備えることを特徴とする、請求項１〜９のいずれか一項に記載の方法。
11. 移動体端末であって、前記端末は、
    ・加入者の支払い手段（１７）から導出される第１トークン（１０３）を処理する処理エージェント（２３）を備えた支払いアプリケーション（２４）と、
    ・前記支払いアプリケーション（２４）によって支払い取引に関するデータを受信する手段と、を含み、
    前記端末は、さらに、前記支払いアプリケーション（２４）によって前記移動体端末の識別子（２２）および個人暗号（２１）と前記支払い手段とをペアリングするペアリング手段（２６）；を含み、
    ・前記端末は、前記第１トークン（１０３）を受信する前に、前記第１トークンを生成するサーバ（１１）に、前記支払いアプリケーション（２４）によって前記第１トークン（１０３）の提供をリクエストし、
    ・前記端末は、さらに、前記第１トークンを処理する前記処理エージェント（２３）によって、少なくとも前記第１トークン（１０３）、前記取引データ、前記移動体端末の前記識別子（２２）および前記個人暗号（２１）を暗号化することによってセキュア第２支払いトークン（１０４）を生成する手段を含むことを特徴とする、端末。
12. 前記端末は、さらに、前記支払いアプリケーション（２４）によって前記移動体端末（１２）の前記識別子（２２）および前記個人暗号（２１）を生成する手段を含むことを特徴とする、請求項１１に記載の端末。
13. 第１トークンを生成するサーバ（１１）であって、前記サーバは加入者の支払い手段（１７）から導出される第１トークン（１０３）を、移動体端末（１２）によって前記第１トークン（１０３）の提供がリクエストされた後に生成する手段を備え、前記サーバはさらに
    ・前記移動体端末（１２）の識別子（２２）および前記加入者の個人暗号（２１）と前記支払い手段（１７）とをペアリングする手段；
    ・少なくとも前記第１トークン（１０３）、前記取引データ、前記移動体端末の前記識別子（２２）および前記個人暗号（２１）を暗号化することによって生成されたセキュア第２支払いトークン（１０４）を検証する検証手段、を備え、
    前記検証手段は、少なくとも前記第１トークン（１０３）、前記取引データ、前記移動体端末の前記識別子（２２）および前記個人暗号（２１）を暗号化することによって検証暗号を生成する手段を備え、
    前記検証手段は、前記セキュア第２支払いトークン（１０４）と前記検証暗号とを比較することを特徴とする、サーバ。
14. 前記移動体端末の前記識別子（２２）および前記加入者の前記個人暗号（２１）は、認証サーバ（１０）から受信されることを特徴とする、請求項１３に記載のサーバ。
15. 前記第１トークン（１０３）は、前記支払い手段（１７）に添付された銀行口座番号を表すデータ（１０５）に少なくとも基づいて、乱数生成装置を利用して生成されることを特徴とする、請求項１３または請求項１４に記載のサーバ。

Images