JP2019527893A - エンドツーエンド鍵管理のためのシステム及び方法 - Google Patents

Abstract

モバイル機器上の支払アプリケーションによって用いられる暗号鍵を管理するためのシステム及び方法を開示する。該方法は、モバイル支払アプリケーションをモバイル機器のユーザドメイン内にて実行するステップであってユーザドメインはユーザによってアプリケーションの実行及びアクセスがなされるオペレーティング環境であるステップと、モバイル支払アプリケーションで用いるための複数の暗号鍵をモバイル機器のシステムドメイン内にインポートするステップであってシステムドメインはオペレーティングシステムによって制御されるよりセキュアなオペレーティング環境であるステップと、ユーザドメイン内にてモバイル支払アプリケーションを実行しつつシステムドメイン内にてモバイル支払アプリケーションの支払情報をインポートされた鍵の１つ以上を用いて暗号化するステップと、暗号化された支払情報を商人へと送信するステップとを含む。

Description

本明細書に記載の例示的実施形態は、商品及び／又は役務に関しての支払についてのトランザクションに一般的に関するのであり、より具体的には、モバイル機器上に格納されておりトランザクション中に用いられる暗号鍵のセキュリティの向上に関する。

関連出願への相互参照
本願は、２０１６年７月２５日に出願された米国特許出願第１５／２１８，８４２号の利益及び優先権を主張する。上記出願の全開示は参照によって本明細書に取り込まれる。

クラウドベースド支払は、モバイル機器におけるデジタル支払クレデンシャルの管理・生成・プロビジョニングを支援し、より単純かつよりセキュアなデジタル支払体験を可能とする。クラウドベースド支払システムは、伝統的な支払カード上に格納された消費者口座クレデンシャル、モバイル機器にプロビジョニングされたデジタルクレデンシャルへと、金融業界が移行できるようにするために開発された。デジタル化されたクレデンシャルは、非接触ＰｏＳシステムを介して又はアプリ内支払等の遠隔支払を介して、消費者のモバイル機器が支払を行うことを可能とする。デジタル化されたクレデンシャルは、モバイル機器上にインストールされたウォレットアプリケーションを用いてデジタルウォレット内に格納され得る。デジタルウォレットには次のような機密アセットがプロビジョニングされていることができる：カードプロファイル、並びにトランザクション鍵及び管理鍵の諸セット等。

クラウドベースド支払のセキュリティモデルは、諸々の対策や技術的設計のセットに頼っており、これらにはデジタルウォレットのライフサイクルの諸局面において関与する幾つかのコントロールが含まれる。リスク管理はデジタルウォレット及びモバイル機器の様々なレベルにてなされ、並びに、遠隔支払事案においてはトランザクションのオンライン許可（online authorization）中になされる。デジタルウォレットの不正使用を検出したり、並びに、トランザクションの却下を惹起するアクションを為したり、又は、デジタルウォレット内に含まれるデジタル化されたカード若しくはデジタルウォレットそれ自体の一時停止をも惹起するアクションを為すために、監視及びトランザクション分析を用いる。

他の任意のソフトウェアベースドな技術と同様に、クラウドベースド支払は幾つかのタイプの攻撃の対象とされるのであり、これらは機密アセットを抽出しようとしたり、又は、デジタルウォレットを不正な態様で使用したりしようと試みる。さらに、デジタルウォレットやモバイルバンキングアプリケーション等の金融系モバイルアプリケーションは、長らく使用されてきたセキュアコーディング手法用いている。難読化及びソフトウェア改竄関連開発ツールをさらに用いてモバイルアプリケーションのセキュリティレベルを増強することができるも、ユーザ装置のユーザドメイン内における暗号鍵のインポート・生成・使用に関しては幾つもの抜け穴が依然存在しているのであり、これらの鍵は攻撃の影響を受け易い。

近時においては、ソフトウェアベースド環境内におけるセキュア暗号学オペレーションへのサポートを提供するために、ホワイトボックスクリプトグラフィ（ＷＢＣ、white-box cryptography）の概念の導入を図る試みが幾つか為されている。もっとも、ＷＢＣは、追加のコストを要するのであり、また、ＷＢＣの更新プロセス等のデジタルウォレットのライフサイクルにわたってのホワイトボックス管理のための複雑な管理を要する。

例示的実施形態の特徴及び利点並びにそれらが達成される態様は、以下の詳細な説明を添付の図面と共に参照することによってより明らかなものとなる。
反対の説明無き限り、図面及び詳細な説明においては、同じ参照符号をもって示されているものは、同じ要素・特徴・構造を指し示しているものと解されるべきである。これらの要素の相対的サイズ及び描写態様は、明確性の為、説明の為、及び／又は利便性の為に誇張又は調整されていることがあり得る。

例示的実施形態による、トークン支払システムを示す概略図である。 例示的実施形態による、ユーザドメイン及びシステムドメインを含むモバイルオペレーティング環境を示す概略図である。 例示的実施形態による、モバイル支払アプリケーションによって使用され得る暗号鍵について示す概略図である。 例示的実施形態による、モバイル機器のシステムドメインにて使用され得る暗号鍵について示す概略図である。 別の例示的実施形態による、モバイル機器のシステムドメインにて使用され得る暗号鍵について示す概略図である。 例示的実施形態による、モバイル機器について示す概略図である。 例示的実施形態による、モバイル機器の複数のドメインにて行われる支払方法について示す流れ図である。

後述の説明においては、様々な例示的実施形態について十分な理解をもたらすために、具体的な詳細事項を提示する。諸実施形態に様々な変更を加えることができるということは当業者にとって明かであり、また、本発明の精神及び範疇から逸脱せずにして本明細書にて規定される一般的な原理を他の実施形態及び用途に適用し得る。さらに、説明の目的で幾つもの詳細事項が後続の説明で提示されている。もっとも、当業者であれば、これらの詳細事項無くしても諸実施形態を実施し得るということを理解できよう。他の場合においては、不要な詳細を伴うことによって説明の明瞭性を損なわないようにするために、周知の構造及び処理は示されなかったり説明されなかったりされている。したがって、本開示は示された実施形態に限定されることを意図してはおらず、本明細書にて開示されている原理及び特徴に沿う態様で最大限に広義に解されるべきである。

本明細書にて説明する場合、モバイル支払アプリケーションは、近距離無線通信（ＮＦＣ、near field communication）や無線周波数識別技術（ＲＦＩＤ、radio frequency identification）等を介してなされる非接触型支払を行うために用いられ得る。非接触型支払をなすに際して、ユーザはモバイル機器を非接触リーダにタップしてトランザクションを進行させることができ、ユーザの認証（authentication）は機器を介してなされるかＰＯＳ（例えば、オンラインＰＩＮ又はシグネチャ）を介してなされるか両者を介してなされるか（低価額トランザクション等に関しては）ｎｏＣＶＭを用いてなされる。また、モバイル支払アプリケーションを用いて遠隔支払をもなし得る。遠隔支払トランザクションをなすに際して、ユーザは、商人のオンラインサイトでお買い物をしたりモバイルアプリケーションを使ったりするのであり、処理のどこかの段階でトランザクションを行うように要請され得る。したがって、ユーザは、デジタルウォレット等のモバイル支払アプリケーションを用いて、インターネット接続を使用しながらトランザクションを行うことができる（なお、非接触型の場合に物理的実世界で使用されるものと対比されたい。）。

クラウドベースド支払は、カード所有者（cardholder）がモバイル支払アプリケーションをモバイル機器にダウンロード・インストールすることを可能とし、商人と行う非接触・遠隔トランザクションに用いることができる。カード所有者は、１つ以上の支払口座をモバイル支払アプリケーションと関連付けることができ、モバイル機器を用いてモバイル支払アプリケーションを介して商人とトランザクションをなすことができる。トランザクションに際しては、カード所有者の機器が幾つかの暗号鍵を用いて、カード所有者のモバイル機器と商人及び／若しくは支払ネットワークとの間で送信される機密支払口座情報（sensitive payment account information）や他の支払データについてセキュア性を確保することができる。

クラウドベースド支払システムの当初の設計の結果故に、カード所有者の機器上のモバイル支払アプリケーションによって用いられる暗号鍵のエンドツーエンド管理に関して複数のセキュリティ上の抜け穴（gap）が存在する。本明細書にて説明する抜け穴とは、ユーザ装置のユーザドメイン内において何らかの態様で管理鍵（management key）やトランザクション鍵等の機密アセットが開示された時点で生じるものといえるのであり、ユーザドメインは信頼されていない環境であり、該ドメインをユーザ装置のシステムドメインと対比すると、後者はオペレーティングシステム（ＯＳ、operating system）によって制御されておりユーザドメインよりもセキュアである。近時においては、次の各領域において多大な労力が投じられてきた：モバイル機器のセキュリティレベルを向上させること、及び、モバイルＯＳを介して新たなセキュリティフィーチャを導入すること。向上したモバイル機器セキュリティの例としては、鍵ストア（keystore）等のセキュア記憶域（secure storage）が挙げられる。例について述べるに、Android（登録商標）オペレーティングシステムに含まれるAndroid Keystoreは、ユーザ装置上のセキュアデジタルコンテナ内に暗号鍵を格納することを可能として、そこから鍵を抽出するのがより困難となる。諸々の鍵が鍵ストア内に入ったならば、それらを暗号学的オペレーションのために使うことができる。また、鍵ストアは鍵の使用時及び使用態様を律する規則を提供し得るのであり、例えば、鍵の使用のためにはユーザ認証を要求したり、特定の暗号学的モードに入っている場合に限って鍵の使用を認めたりすることができる。

例示的実施形態によれば、モバイル支払処理又は非接触支払処理に際して用いられる暗号鍵に関しては、Android Keystore等のモバイルＯＳのセキュリティフィーチャを、トランザクション中のエンドツーエンド暗号鍵管理に統合することによって、セキュア性を増強できる。典型的には、モバイル支払アプリケーションは、デフォルトでは鍵をユーザドメイン内に格納する。これに対して、例示的実施形態では、鍵はシステムドメイン内でインポート・操作されるのであり、モバイル機器のセキュリティフィーチャを向上させるため及び鍵管理における抜け穴の個数を減少させるためにこれがなされる。例えば、ユーザドメインの代わりに、鍵を、システムドメインにあてがわれている信頼済み実行環境（trusted execution environment）若しくはハードウェア要素にインポートした上で実行できる。

本明細書にて説明する場合、ユーザドメインとはデジタルウォレット等のモバイルアプリケーションの実行及び動作がなされる環境を指すのであって該実行・動作はユーザからの制御に応答してなされており、また、システムドメインとはＯＳのみによって制御されているよりセキュアな環境を指す。システムドメインは低レベル機能へのアクセスを有しており、信頼済み実行環境又はハードウェアベースド機構によって提供され得るセキュリティフィーチャとのインタフェースがこれに含まれる。さらに、ユーザ装置のユーザドメインとシステムドメインとの間では強度の隔離（例えば、ファイアウォール）が施されており、それ故にシステムドメインへのアクセスは制限されている。一般的に、攻撃者はユーザドメインを攻撃対象とする。なぜならば、該ドメインの方が容易であり、アクセス機会が有意に多いからである。他方、先進的な攻撃者のみがシステムドメインに対してアクセスを試みるであろう。なぜならば、システムドメインを攻略するためには相当にスキルレベルの高い理解が必要となるからである。

暗号鍵（即ち、鍵）は別の機器からインポートされたり、モバイル機器によって生成されたりすることができる。鍵を用いて暗号化、復号化、署名等の様々なオペレーションをなすことができ、これらのオペレーションはモバイル機器と支払ネットワークとの間で送信されるデータに対してなされる。様々な例示的実施形態によれば、鍵のインポート及び生成並びに鍵を用いる諸オペレーションは、ユーザドメインの代わりにシステムドメインにてなすことでき、これによって鍵がユーザドメインにて曝露されることを予防することができる。さらに、例示的実施形態では、ＯＳ内で鍵ストアを管理するために用いられる機能を組み合わせるのであり、これによって鍵のセキュリティレベルを増強させるのであり、ユーザドメインにて管理鍵及びトランザクション鍵の漏洩がないようにする。したがって、（セキュア鍵インポートに始まって、鍵の実際の使用に至るまでの）暗号学的オペレーションの全てをシステムドメイン内にて行うことができるのであり、信頼済み実行環境や埋込型セキュア要素等のＯＳによって提供される最先端の手法の利点を活用できるのであり、これらは制限されたかつ制御された態様でＯＳによって用いられ得る。

例示的実施形態ではシステムドメイン内の鍵に対してなせるオペレーションの種類を限定することができる。例えば、システムは、インポートを許すがエクスポートを許さなかったり、暗号化を許すが復号化を許さなかったりすることができ（又はその逆もあり得る）、アクセス制御を用いて鍵へのアクセスを制限したりでき、また、（例えば、非対称鍵等の）鍵の暗号学的性質を活用して鍵の一部たる公開鍵を用いて誰でもデータを暗号化できるようにしたりすることができる。さらに、鍵が関係するオペレーションには、追加のレベルの暗号化及び復号化を組み合わせることができ、追加の制御を施すことができる。例えば、鍵の伝送（transport）及び鍵の使用に関しては、当該鍵についてアクセス規則定義済みの別の鍵を用いて行う先行する復号化における当該鍵の使用を、前提条件とすることができる。

図１は、例示的実施形態による、トークン支払システム１００について示す。図１を参照するに、トークン支払システム１００は、モバイル機器１１０、商人コンピューティング装置１２０、発行者コンピューティング装置１３０、モバイルアプリケーションサーバ１４０、管理サーバ１５０、アクワイアラ１６０、及び支払ネットワーク１７０を含む。また、トークン支払システム１００は、例えば支払ゲートウェイ等の不図示の追加の装置を含み得るのであり、１つ以上の例示的装置は互いに組み合わされたり統合されたりすることができる。また、トークン支払システム１００は、複数の、モバイル機器１１０、商人コンピューティング装置１２０、発行者コンピューティング装置１３０、モバイルアプリケーションサーバ１４０、管理サーバ１５０、及びアクワイアラコンピューティング装置１６０を含むことができる。

トークン支払システム１００は、モバイル機器１１０から商人１２０へとなされる非接触支払及び遠隔支払を支援するクラウドベースド支払システムたり得る。例えば、モバイル機器１１０は、モバイルアプリケーションサーバ１４０からモバイル支払アプリケーションをダウンロード及びインストールできる。支払アプリケーションは、発行者ベースド支払アプリケーション、商人ベースド支払アプリケーション、デジタルウォレット等とすることができる。発行者ベースドモバイル支払アプリケーションの例においては、支払機能を発行者（例えば、発行者１３０）のモバイルアプリケーションの一部としてモバイル機器１１０内に統合することができ、クレデンシャルをモバイルアプリケーションに提供して支払トランザクションを遂行することができる。デジタルウォレットの例においては、支払機能をデジタルウォレットの一部として統合することができ、モバイルアプリケーションサーバ１４０は、１つ以上の支払カードを同一のデジタルウォレット内へとデジタル化できるウォレットプロバイダとすることができる。

ユーザは、モバイル機器１１０上にインストールされたモバイル支払アプリケーションと関連付けられている１つ以上の支払カードについてのトークン化支払口座情報（tokenized payment account information）を、格納することができる。モバイル支払アプリケーションは、次のものを含み得る：MasterCard（登録商標） MasterPass（登録商標）、Google（登録商標） Wallet、Samsung（登録商標） Pay、Apple Pay（登録商標）等。支払口座情報はプライマリ口座番号（ＰＡＮ、primary account number）や失効期限等を含み得るのであり、これらは発行者１３０によって提供された支払カードからのものであり、これらはトークン化してモバイル機器１１０にて格納することができる。別の例について述べるに、モバイル機器１１０はデジタルウォレットを格納していることができ、該ウォレットはその中にトークン化支払情報を有していることができ、該情報は１つ以上の支払カードからのものであり、これらは任意の個数の発行者・銀行・金融機関等から提供されたものであり、それらはユーザによってデジタルウォレットと関連付けられている。結果として、モバイル機器１１０は、遠隔的に及び面前的に支払を商人１２０へとつなぐことができる商業用装置に、変容することができる。

管理サーバ１５０は、複数の装置、モジュール、プログラム、ソフトウェア等を含み得る。例えば、管理サーバ１５０は、MasterCard Incorporated等の金融主体によって支配されていることができ、次のものを含み得る：クレデンシャル管理システム（ＣＭＳ、credential management system）、口座イネーブルメントシステム（ＡＥＳ、account enablement system）、トランザクション管理システム（ＴＭＳ、transaction management system）、トークン保管庫等。これらの例では、管理サーバ１５０は、トークンサービス提供装置を含むか又はトークンサービス提供装置と接続されていることができる。トークンサービス提供装置は、支払カード情報の代わりにトークンを生成でき、トークン化支払情報（例えば、トークン化ＰＡＮ等）を実際の支払情報に転換（convert）するために必要なマッピング又は情報テーブルを格納及び維持できる。様々な例示的実施形態によれば、管理サーバ１５０は、モバイル機器１１０に格納されたモバイル支払アプリケーションと共に用いるための様々な暗号鍵を格納でき、支払処理又はトランザクション中に用いることができる。例えば、鍵には、トークン用のマスター鍵、トランザクションにて用いるためのセッション鍵、管理用の鍵等が含まれ得る。鍵は、トランザクション前に又はトランザクション中に、管理サーバ１５０からモバイル機器へと転送（transfer）されることができる。

図１の例では、モバイル機器１１０にインストールされたモバイル支払アプリケーションは、フロントエンドインタフェースをカード所有者に提供するのであり、サインアップに始まって支払サービスやモバイル機器１１０とトランザクションをなすことに至るユーザエクスペリエンスを管理するのであり、個人識別番号（ＰＩＮ、personal identification number）の変更等の機能を管理する。モバイルアプリケーションサーバ１４０は、フロントエンドインタフェースをカード所有者に提供するのであり、カード所有者のユーザアカウントを管理するのであり、モバイル支払アプリケーション内へと向かって支払カードをデジタル化するためのクラウドベースドデジタル化サービスを統合することができる。

様々な例示的実施形態によれば、トークン支払システム１００に対して複数の改良が加えられており、モバイル機器１１０と商人１２０との間での支払トランザクションのセキュリティをさらに強化するためにこれがなされている。改良の第一波はモバイル機器１１０によってなされる暗号鍵のインポート・格納・使用に対して施されており、鍵のインポート、鍵の格納及び鍵の諸オペレーションをモバイル機器１１０のシステムドメインに統合することによって改良がなされる。改良の第二波は、鍵に対しての変更を管理サーバ１５０のＣＭＳへと波及させることによって施されている。改良の第三波は、管理サーバ１５０のＴＭＳのトランザクションクリプトグラムを異なる暗号化アルゴリズムに移行（migrate）させることによって施されている。改良の第四波は、モバイル機器１１０のモバイルＯＳに対して変更を加えることによって施されている。

管理サーバ１５０は幾つかの異なるシステムを含み得る。例えば、口座イネーブルメントシステムは、クラウドベースド支払サービスとの関係での支払カード及び機器の適格性（eligibility）を確認するためのサービスを提供でき、識別及び検証（verification）を行ってカード所有者を認証でき、支払カードをデジタル化でき、また、ライフサイクル管理を調整することができる。トークン保管庫は、トークンから口座ＰＡＮへのマッピングテーブルを維持することができる。デジタル化支払カードは、ＣＭＳにプロビジョニングされることができる。ＣＭＳは、トークンについてのマスター鍵を格納でき、トランザクション中にセッション鍵を生成でき、これらはトランザクションクレデンシャルに転換されることができる。ＣＭＳはセッション鍵をモバイルＰＩＮと組み合わせてトランザクションクレデンシャルを作成でき、それらをモバイル支払アプリケーションに提供してモバイル支払アプリケーションがトランザクションを行えるようにイネーブルすることができる。ＴＭＳはトランザクションを処理でき、アプリケーションクリプトグラムを検証して用いられたクレデンシャルを認証（authenticate）でき、正しいモバイルＰＩＮが入力されたことを検証できる。

モバイル機器１１０のユーザは、商人１２０に対して、トランザクションについての支払をなすことを試み得る。例えば、モバイル機器１１０は、デジタルウォレット又は他のモバイル支払アプリケーションによって提供された非接触支払機能又は遠隔支払機能を用いて支払をなし得る。商人１２０がモバイル機器１１０から支払データを受信したらば、商人１２０は支払データをアクワイアラ１６０へと送信（transmit）できる。アクワイアラ１６０は、処理のために支払データを支払ネットワーク１７０へと送信することができる。支払データがトークン化支払情報を含む場合、支払ネットワーク１７０は、実際の支払情報へと変換（translate）してもらうためにトークン化支払情報を発行者１３０及び／又は管理サーバ１５０へと送信することができる。また、発行者１３０は、支払データに対応する支払口座が、商人１２０との関係でなされた購入をまかなうに十分な資金を有しているか否かを検証することもできる。許可（authorization）の結果は、逆の経路を介して商人１２０へと送り戻されることができる。

図１においては不図示であるも、トークン支払システム１００は、Google Cloud Messaging、Apple Push Notification Service、Microsoft（登録商標） Push Notification Service等の遠隔通知サービスをさらに含み得る。遠隔通知サービスは、モバイル支払アプリケーションと通信して様々な通知を提供できる。

図２は、例示的実施形態による、モバイルオペレーティング環境を示すのであり、該環境はユーザドメイン２００とシステムドメイン３００とを含む。図２を参照するに、ユーザドメイン２００は、モバイル支払アプリケーションや商人アプリケーションやデジタルウォレット等のモバイルアプリケーションが動作し得るオペレーティング環境である。ユーザドメイン２００は、ユーザが、モバイル機器上で実行されている様々なアプリケーションと相互対話できるドメインである。幾つかのモバイルアプリケーションがユーザドメイン２００内にて動作している場合、モバイル機器のＯＳは、ユーザドメイン２００内のアプリケーション間で何らかの度合いのサンドボックス化を提供し得るのであり、モバイルアプリケーションがアクセスできる領域に関して制御及び／又は制約を及ぼすためにこれがなされる。

システムドメイン３００は、よりセキュアなオペレーティング環境であり、モバイル機器のＯＳの単独支配下に置かれていることができる。様々な例では、ユーザ又は未許可モバイルアプリケーションは、システムドメイン３００内のデータにアクセスすることを許されていない。システムドメイン３００は、低レベル関数へのアクセスを有していることができ、信頼済み実行環境（ＴＥＥ、trusted execution environment）や（例えば、セキュア要素、記憶域、クリプトプロセッサ等の）ハードウェアベースド機構等の様々なセキュアフィーチャのインタフェースたり得る。様々な例示的実施形態によれば、鍵ストア３１０がシステムドメイン３００内に含まれるのであり、１つ以上の鍵エントリ３１２が含まれ、ＴＥＥ３１６及びハードウェアベースド機構３１４もある。鍵ストア３１０は、対応するエントリ３１２及び所有者の識別情報を有する暗号学的な鍵の格納・維持の役割を担っている。鍵は、ユーザドメイン２００から、システムドメイン３００内の鍵ストア３１０へとインポートされ得る。鍵ストアの例としてはAndroid Keystoreが挙げられ、これはGoogle社によって設計されたAndroidモバイルＯＳに含まれている。一部の例では、鍵がシステムドメイン３００からユーザドメイン２００へとエクスポートされるのであり、例えば鍵は特定の種類の処理オペレーション及び／又はユーザドメイン２００内での条件によって制限されている事案が想定される。

例示的実施形態では、強度の隔離（例えば、ファイアウォール）がユーザドメイン２００とシステムドメイン３００との間で講じられている。その結果、システムドメイン３００へのアクセスは高度に限定されている。例えば、システムドメイン３００はＯＳの単独支配下に置かれていることができ、アプリケーション、装置、及びユーザがシステムドメイン３００にアクセスすることが防止され得るのであり、これらがシステムドメイン３００内に格納された暗号鍵にアクセスすることが防止され得る。また、ＯＳは、システムドメイン３００にて行われ得る種類のオペレーションを、防止することができる。システムドメイン３００のセキュリティ強固性故に、攻撃者は通常ユーザドメイン２００を攻撃対象とするのであり、最も先進的な攻撃者のみがシステムドメイン３００に対してのアクセスを試みるであろう。さらに、システムドメイン３００によって用いられるＴＥＥ３１６やハードウェアベースド機構３１４等のセキュア機構を扱ったり突破したりするためにはさらに熟練を要し得る。

図２の例では、ユーザドメイン２００の中にてモバイル支払アプリケーション２１０がインストール・実行されている。例えば、モバイル支払アプリケーション２１０は、デジタルウォレット、商人支払アプリケーション、発行者ベースド支払アプリケーション等たり得る。ユーザドメイン２００は、該ドメイン内にて実行され得る他のモバイルアプリケーション２２０をも含み得る。モバイル支払アプリケーション２１０は、複数のプロセス（Ｐ１，Ｐ２，Ｐｎ等）２１５を含む。一部の例では、モバイル支払アプリケーション２１０は、ユーザドメイン２００にて作動するホワイトボックスクリプトグラフィ（ＷＢＣ、white-box cryptography）コンポーネントをも含み得る。モバイル支払アプリケーション２１０は、ユーザドメイン２００の環境内にて運用されるデータベース内にて情報を格納し得る。様々な例示的実施形態によれば、モバイル支払アプリケーション２１０は、支払処理中に鍵ストア３１０を用いることができ、また、支払処理中に使用され得る鍵ストアエントリ３１２を作成できる。例えば、鍵ストア３１０内の各エントリは、鍵（そしてそのエイリアス）及び次のようなパラメータと関連付けられていることができる：暗号化アルゴリズム（例えば、ＡＥＳ、ＲＳＡ、ＥＣＣ等）、アクセス規則、及びシステムドメイン３００内にて許される暗号学的機能（例えば、暗号化、復号化、署名等）。

鍵ストア３１０は、システムドメイン３００内にて動作でき、ＴＥＥ３１６及び／又は利用可能なハードウェアコンポーネント３１４によってもたらされるセキュリティを活用できる。この例では、ユーザドメイン２００内のアプリケーション間において第１のレベルの隔離がなされている。また、ユーザドメイン２００とシステムドメイン３００との間では、第２のレベルの隔離がなされている。その結果、ユーザドメイン２００及びシステムドメイン３００は、玉葱（onion）の各層のように又は各人形がそれぞれ別の保護層を入れ子式にもたらすマトリョーシカ人形（Russian dolls）のように機能し得る。この例では、システムドメイン３００内に格納されているデータは、ユーザドメイン２００内に格納されているデータよりもより多くの層の保護をまとっている。一部の例では、鍵ストア３１０に対してコールを発しても、コール発信主体が、システムドメイン３００内の鍵ストアエントリ３１２コンポーネント内で一連のオペレーションを行えない不許可事態を招来し得るのであり、最終結果がシステムドメイン３００からユーザドメイン２００へと返戻されるだけとなり得る。例を挙げるに、システムドメイン３００にて暗号学的オペレーションがなされると、それへの応答がユーザドメイン２００へと送り戻されるのであり、ユーザドメイン２００を狙っている攻撃者に対してそれが剥き出しにされ得る。したがって、鍵ストア３１０は、一時に１つのオペレーションしか行うことができず、また、一時的な結果若しくは値を格納できないようなハードウェアセキュアモジュールとすることができる。

様々な態様によれば、システムドメイン３００は、ユーザドメイン２００に対してスレーブとして振る舞うことができる。図２の例では、ウォレット２１０のビジネスロジックが（モバイル支払アプリケーションを含めて）ユーザドメイン２００内にて実行される。もっとも、暗号学的オペレーションはシステムドメイン３００内で行われ得る。したがって、暗号学的オペレーションは、ユーザドメイン２００からシステムドメイン３００へのアプリケーションプログラミングインタフェース（ＡＰＩ）コール等の結果として、システムドメイン３００内にて行われ得る。ここで例を挙げるに、ユーザドメイン２００にて実行されているウォレット２１０のプロセス（Ｐ２）がｆｎ（ＫＳ，ｄａｔａ）を用いてシステムドメイン３００にコールを発するのであり、ここで、ｆｎ（）は暗号学的関数であり、ＫＳは鍵ストア３１０についてのエイリアスであり、ｄａｔａは処理されるべき何らかのデータである。次に、応答（ｒｅｓｐ）がシステムドメイン３００からユーザドメイン２００へと転送される。この例では、鍵ストア３１０は、ユーザドメイン２００にて動作しているプロセスのスレーブであり、ウォレット２１０に含まれるプロセスによって必要に応じてコールされることができる。鍵ストア３１０内に含まれる鍵は、ユーザドメイン２００からのコールに応答して鍵ストア３１０によって生成されることができるか、又は、ユーザドメイン２００から鍵ストア３１０へとインポートされることができる。様々な態様によれば、鍵はユーザドメイン２００内にある間（例えば、ユーザドメイン２００からインポートされる前、又はシステムドメインからユーザドメインへとエクスポートされた後）に暗号化されることができるのであり、従ってさらにセキュア性が強化される。

図３は、例示的実施形態による、モバイル支払アプリケーション２１０によって用いられ得る暗号鍵について示す。図３を参照するに、モバイル支払アプリケーション２１０はユーザドメイン２００内へとインポートされたかユーザドメイン２００内で生成された複数の鍵を含むのであり、それらはユーザドメイン２００にて使用されるのであり、これに対してシステムドメイン３００は空っぽである。この例では、モバイル支払アプリケーション２１０は、支払処理中に複数の暗号鍵３５０を用い得る。ここにおける例においては、（ＭＫ）との用語はモバイル鍵を表し、（ＭＳＫ）との用語はモバイルセッション鍵を表し、（ＩＣＣ）はＩＣカード鍵を表し、（ＬＤＥ）はローカルデータベース暗号鍵を表す。また、ＡＥＳ、ＲＳＡ、３ＤＥＳ等の用語は業界における暗号の種類を表す。

クラウドベースド支払サービスは、モバイル支払アプリケーション２１０を用いるに際してユーザドメイン２００内にて実行される様々なセキュリティサービスを使用できる。図３に示すクラウドベースド支払サービスについて例を挙げるに、次のものが含まれる：モバイル支払アプリケーション２１０によるランダム鍵生成（ＲＧＫ、random key generation）、及びＣＭＳへのＲＧＫエクスポート（なお、ＣＭＳによって提供されるＲＳＡ公開鍵を用いてＲＧＫを暗号化できる）。例えば、ＣＭＳは、図１に図示の管理サーバ１５０に含められているかそれに接続されていることができる。クラウドベースド支払サービスは次のようなモバイル鍵を含み得る：メッセージ認証コード（ＭＡＣ、message authentication code）モバイル鍵、トランスポート鍵（ＴＫ、transport key）、ＣＭＳから送達されてかつＲＧＫ下で暗号化され得るデータ暗号化鍵（ＤＥＫ、data encryption key）、モバイル鍵（ＭＡＣ及びＴＫ）とセッション情報とをダイバーシファイアとして用いてモバイル支払アプリケーション２１０によって生成したモバイルセッション鍵（ＭＡＣ及びＴＫ − ＡＥＳ鍵）、モバイル支払アプリケーションとＣＭＳとの間のメッセージングプロトコルの一部としてモバイル支払アプリケーションによって用いられたモバイルセッション鍵（ＭＡＣ及びＴＫ）、カードプロファイル（ＩＣＣ ＫＥＫ）内の機密アセット又はＣＭＳによってプロビジョニングされた鍵コンテナ内の鍵セット（セッション鍵及び使い捨て型鍵）を保護するために使用され得るモバイル鍵（ＤＥＫ）、モバイル支払アプリケーションによって生成されかつデータ格納に関してセキュア性を確保するため（暗号化及び復号化）に用いられるローカルデータベース暗号（ＬＤＥ）鍵（ＡＥＳ鍵）、（代理的な）モバイルＰＩＮを用いての使い捨て型鍵（３ＤＥＳ鍵）からセッション鍵（３ＤＥＳ鍵）への転換。また、クラウドベースド支払サービスは次のこともなし得る：セッション鍵（３ＤＥＳ鍵）を用いたＡＣ／ＣＶＣクリプトグラム生成、ＩＣＣ ＫＥＫ（ＡＥＳ鍵）を用いたＩＣＣ秘密鍵復号化、及びＩＣＣ鍵ペア（ＲＳＡ鍵）を用いたＣＤＡシグネチャ生成。

もっとも、図３では、暗号鍵はユーザドメイン２００内のモバイル支払アプリケーション２１０内へとインポートされまたユーザドメイン２００内のモバイル支払アプリケーション２１０によって使用される。その結果、ユーザドメイン２００へのアクセスを獲得した侵入者からの攻撃に鍵が曝され得る。図４は、例示的実施形態による、システムドメイン３００内で使用され得る暗号鍵について示す。図４の例に言及するに、図３のシステムとの比較では、追加のセキュリティ向上策への対応が施されていることが分かる。モバイル機器のＯＳを用いてシステムドメイン３００を制御することができ、モバイル支払アプリケーションをユーザドメイン２００内にて実行している間に生じるアクションに基づいてこれをなし得る。

図４を参照するに、様々な例示的実施形態によれば、モバイル鍵４１０（ＭＡＣ、ＴＫ及びＤＥＫ − ＡＥＳ鍵）をシステムドメイン３００内の鍵ストア３１０にインポートすることができ、またシステムドメイン３００内の鍵ストア３１０によってこれを用いることができるのであり、標準的装置アクセス制御を有している場合がある。この例では、標準的装置アクセス制御はユーザ認証とリンクされていない。例えば、モバイル鍵４１０は、ＣＭＳからインポートされるか、又は、図１の管理サーバ１５０内に含まれることができる。また、モバイル鍵（ＤＥＫ）下で暗号化されたアセットは、システムドメイン３００の鍵ストア３１０内で管理されることができる。

この例では、モバイル支払アプリケーションは、モバイル鍵４１０を格納し、また、モバイル鍵４１０を用いて暗号学的オペレーションを行うために、システムドメイン３００内の鍵ストア３１０を用いることができる。モバイル支払アプリケーションは、ＲＧＫ鍵下で暗号化されたモバイル鍵４１０を受信できる。これらの例では、モバイル支払アプリケーションはパラメータを伴うＭＡＣ鍵ストアエントリを作成できるのであり、該パラメータは次のようなものとできる：暗号化アルゴリズムがＡＥＳとされること、アクセス制御がユーザ認証を伴わない標準的装置とされること、並びに、関数がシステムドメイン３００内で署名（モバイルセッション鍵を導出するためのＨＭＡＣ生成）及び「署名」（ＭＡＣバリデーション）に限定されること。また、モバイル支払アプリケーションは次のようなパラメータを伴うＴＫ鍵ストアエントリを作成することもできる：暗号化アルゴリズムがＡＥＳとされること、アクセス制御がユーザ認証を伴わない標準的装置とされること、並びに、関数が署名（モバイルセッション鍵を導出するためのＨＭＡＣ生成）及び復号化に限定されること。また、モバイル支払アプリケーションは次のようなパラメータを伴うＤＥＫ鍵ストアエントリを作成することもできる：暗号化アルゴリズムがＡＥＳとされること、アクセス制御がユーザ認証を伴わない標準的装置とされること、並びに、関数が復号化及び暗号化に限定されること。

モバイル鍵ＭＡＣ、ＴＫ、及びＤＥＫ４１０は（クリア態にて）鍵ストア３１０内へとインポートされ得る。モバイル鍵ＭＡＣ（ｋｓＭｋＭａｃ）は、モバイル支払アプリケーションによって確立されるべきセッションについての情報を配信する際に、ＣＭＳによって送られた遠隔通知メッセージをもって算出されたＭＡＣをバリデートするために、用いられ得る。また、モバイル鍵ＭＡＣ（ｋｓＭｋＭａｃ）は、支払処理中にユーザドメイン２００内にて実行されているモバイル支払アプリケーション２１０に戻されるＭＡＣモバイルセッション鍵を生成することを、許される。モバイル鍵ＴＫ（ｋｓＭｋＴｋ）は、モバイル支払アプリケーションによって確立されるべきセッションについての情報を配信する際に、ＣＭＳによって送られた遠隔通知メッセージの暗号化内容を復号化するために、用いられ得る。また、モバイル鍵ＴＫ（ｋｓＭｋＴｋ）は、ユーザドメイン２００に戻されるＴＫモバイルセッション鍵を生成するためにも用いられ得る。モバイル鍵ＤＥＫは、フィールドレベルでデータを復号化及び／又は暗号化することを、許される。

図４の例では、モバイル鍵４１０の復号化は、ユーザドメイン２００内で実行されているモバイル支払アプリケーションによって行われ得るも、モバイル鍵４１０はＫＳエイリアスを用いて識別されたシステムドメイン３００内の鍵ストア３１０へと直ちにインポートされることができる。インポート処理が完了されたらば、モバイル鍵４１０を、ユーザドメイン２００からワイプ或いは抹消することができる。その時点以降、システムドメイン３００内の鍵ストア３１０を用いることによって、モバイル鍵（ＭＡＣ、ＴＫ及びＤＥＫ）４１０を用いて全ての暗号学的オペレーションを行うことができる。システムドメイン３００内にてモバイルセッション鍵を生成するためにモバイル鍵ＭＡＣ及びモバイル鍵ＴＫを用いた場合、モバイルセッション鍵は、ユーザドメイン２００のモバイル支払アプリケーション２１０へと戻されることができる。モバイルセッション鍵を用いる暗号学的オペレーションはユーザドメイン２００内にて行われ得る故に、ユーザドメイン２００を狙っている攻撃者に対して曝され得る。もっとも、モバイルセッション鍵は、ＣＭＳによって定義されたセッション識別子を用いる際、モバイル支払アプリケーションとＣＭＳとの間での１つのセッションに限って有効とされ得る。さらに、本明細書にて説明したセキュリティ向上策を統合する場合、モバイルセッション鍵の役割の致命性は減じられ得るのであり、故に、攻撃者が仮にモバイルセッション鍵をターゲティングできる場合であっても、（モバイル鍵ＤＥＫ下で暗号化された）トランザクション鍵等の機密アセットへのアクセスを獲得するためには追加のセキュリティ向上策を突破することを要することになる。

様々な例示的実施形態によれば、ＬＤＥ鍵４２０は、システムドメイン３００の鍵ストア３１０内にて生成及び使用されることができる。例えば、モバイル支払アプリケーションは、ＬＤＥ鍵４２０の生成を鍵ストア３１０に委譲することができ、ＬＤＥ鍵４２０を定義して全てのオペレーションをユーザドメイン２００内で行うための処理を実施する代わりに、全ての暗号学的オペレーションをシステムドメイン３００内にて行うことができる。ＬＤＥ鍵４２０は、システムドメイン３００内の鍵ストア３１０によってランダムに生成されることができる。その時点以降、ＬＤＥ鍵４２０を用いてなされる全ての暗号学的オペレーションを、システムドメイン３００内の鍵ストア３１０を用いて行えるのであり、ＬＤＥ鍵４２０がユーザドメイン２００（即ち、ユーザドメイン２００内のモバイル支払アプリケーション）に曝されることにはならない。ＬＤＥ鍵４２０は、ユーザアクセス制御を伴ったＬＤＥ鍵を含み得る（ＬＤＥＵＳＲ鍵）。ＬＤＥＵＳＲ鍵は、鍵ストア３１０によってランダムに生成でき、ユーザドメイン２００内にて実行されているモバイル支払アプリケーションに提供される公開鍵を有することができる。ＬＤＥＵＳＲ鍵は、モバイル支払アプリケーションによって用いられているローカルデータベース内に格納されているデータを復号化するために用いられ得る。暗号化処理は、ユーザドメイン２００にてモバイル支払アプリケーションによって公開鍵を用いて、鍵ストア３１０の暗号化フィーチャへのアクセスを何ら要せずに、行われ得る。

様々な例示的実施形態によれば、ＩＣＣ鍵ペア４３０は、システムドメイン３００の鍵ストア３１０内へとインポートされるか、又は、システムドメイン３００の鍵ストア３１０によって用いられることができる。モバイル支払アプリケーションは、ＩＣＣ鍵ペア４３０及びそのコンポーネント（ｐ，ｑ，ｄｐ，ｄｑ及びｕ）を、ＣＭＳから、モバイル支払アプリケーションに対応するカード所有者のカードプロファイルの一部として、受信することができる。鍵ペアを再構築するために必要とされるコンポーネントは、鍵ＩＣＣ ＫＥＫ下で暗号化されていることができる。ＩＣＣ ＫＥＫは、カード所有者のカードプロファイルの一部であることができ、また、モバイル鍵（ＤＥＫ）下で暗号化されていることができる。モバイル支払アプリケーションは、鍵ストア３１０を用いてＩＣＣ鍵ペア４３０を格納してＣＤＡシグネチャの生成をシステムドメイン３００内にて行うことができる。

クラウドベースド支払サービスは設計としてローカルデータ認証（ＬＤＡ、local data authentication）を統合できるのであり、それはＣＤＡの変種であり、ＩＣＣ鍵ペア４３０の何らかの乱用を防止するためにこしらえてあり、成功裏なオフライントランザクションを行うためにこしらえてある。ＩＣＣ鍵ペア４３０の追加的保護レベルは、機密アセットの無制御的なエクスポート又は漏洩を防止しようとするトランジット等の環境において特に関連性を有しており、繰り延べオンライン認証の概念を支持するモデル内にて用いられ得る（即ち、トランザクションクリプトグラムがトランザクション時においてリアルタイムでバリデートされない）。トランジットを用いる場合、（間違ったトランザクションクリプトグラムを伴ってでも）有効なＣＤＡシグネチャを用いることができるのであり、次のことをするためにこれがなされる：トランザクションクリプトグラムの有効化の時点での失敗の結果としてデジタル化されたカードと関連付けられているＰＡＮがブラックリスト入りする前にトランジットゲートを通過させること。

モバイル支払アプリケーションは次のようなパラメータを伴うＩＣＣ鍵ペア鍵ストアエントリ（ICC key pair keystore entry）を作成することができる：暗号化アルゴリズムがＲＳＡとされること、アクセス制御がユーザ認証を伴わない標準的装置とされること、並びに、関数が署名（ＣＤＡ生成）に限定されること。モバイル支払アプリケーションは、モバイル鍵ＤＥＫを用いてＩＣＣ ＫＥＫを復号化することができる。ＩＣＣ ＫＥＫを用いての各ＣＲＴコンポーネントの復号化はユーザドメイン内にて行われ得るのであり、ＩＣＣ鍵ペア４３０を直ちに鍵ストア３１０へとインポートすることができる。インポート処理が完了されたらばすぐさまＩＣＣ ＫＥＫ及びＣＲＴコンポーネントをユーザドメイン２００からワイプできる。その時点以降、ＩＣＣ鍵ペア４３０を用いてなされた暗号学的オペレーション（即ち、ＣＤＡシグネチャ生成）は、システムドメイン３００内の鍵ストア３１０を用いて行うことができる。

追加の鍵ストア３１０エントリ（ＲＳＡ鍵）を用いて鍵との関係で特定のアクセス制御を伴わせることによって記憶域を堅牢化する手段を提供することができる。その向上策を用いるに際してＵＭＤ鍵へのアクセスはモバイル機器を用いるカード所有者の認証を要求できる（例えば、指紋を用いてなされる機器アンロック処理の一部としての機器ＣＤＣＶＭの使用等）。この随意的フィーチャはＵＭＤセッション鍵にさらなる暗号化の段階を加えるのであり、これはＵＭＤ鍵へのアクセスを（機器ＣＤＣＶＭを用いての）モバイル機器上での成功裏なカード所有者認証に条件付けるためになされる。ウォレットは次のようなパラメータを伴うＬＤＥＵＳＲ鍵 鍵ストア エントリ（LDEUSR key keystore entry）を作成できる：アルゴリズムがＲＳＡ（又はＥＣＣ）とされること、アクセス制御がユーザ認証（機器アンロック）とされること、並びに、関数が復号化に限定されること。ＬＤＥＵＳＲ鍵はシステムドメイン３００内の鍵ストア３１０によってランダムに生成されることができる。公開鍵コンポーネントを検索できユーザドメイン２００内に格納できる。

モバイル支払アプリケーションは、暗号化ＭＤセッション鍵（ＳＫ＿ｘｘ＿ＭＤ）及び暗号化ＩＤＮ値を格納できる。（モバイル鍵ＤＥＫ下で暗号化された）暗号化ＵＭＤ単一使用鍵（ＳＵＫ＿ｘｘ＿ＵＭＤ）は、ローカル暗号化データベース内に格納される前にモバイル支払アプリケーションによってＲＳＡ公開コンポーネント（Ｐｋ）を用いて、暗号化されることができる。ここで述べるに、公開鍵はユーザドメイン２００内にて利用可能とされ得るのであり、ユーザアクセス制御を伴わずにしてモバイル支払アプリケーションによって何時でも使用されることができる。トランザクション時におけるＵＭＤ単一使用鍵へのアクセスはＲＳＡ秘密コンポーネント（Ｓｋ）と関連付けられているアクセス制御規則によって保護され得るのであり、これはＵＭＤ鍵がシステムドメイン３００内でＲＳＡ秘密コンポーネント（Ｓｋ）を用いて復号化できるのは次の場合に限られるからである：即ち、モバイル機器のレベルで（機器ＣＤＣＶＭ）成功裏なカード所有者認証がなされた場合。モバイル鍵ＤＥＫを用いて第２の復号化を行い得るのであり、ＵＭＤやＭＤ鍵やＩＤＮ値等のモバイル鍵ＤＥＫによって保護されたアセットを取り戻すためにこれをなし得る。

図５は、別の例示的実施形態による、システムドメイン３００内で用いられ得る暗号鍵について示す。この例では、様々な例示的実施形態にならってネットワーク管理サーバ１５０のＣＭＳを更新できるのであり、図１のトークン支払システム１００に対して第二波たる向上策を施すことができる。図５を参照するに、そして様々な例示的実施形態によれば、モバイル支払アプリケーション用の新たに作成されたモバイル鍵（モバイル鍵ＤＥＫＵＳＲ５１０）を、システムドメイン３００の鍵ストア３１０内へとインポートするのであり、また、モバイル支払アプリケーションの実行中にそれを用いてデータに関して暗号化及び復号化をなす。モバイル鍵ＤＥＫＵＳＲ５１０を用いるためにユーザ認証を要求し得る。

この例では、モバイル支払アプリケーションとＣＭＳとの間での通信には、メッセージングプロトコルを用いることができ、該プロトコルでは、トランスポートレベルでモバイルセッション鍵（ＭＡＣ及びＴＫ）４１０を用いて、そしてフィールド暗号化に関してはモバイル鍵（ＤＥＫ）４１０を用いて、データ保護がなされる。ユーザアクセス制御とリンクされたフィールド暗号化という概念を統合するために幾つかの選択肢を検討した。非対称暗号を用いるソリューションはやめた。なぜならば、システム性能に影響を及ぼし得るものの利益が限定的であるからである。この理由は、鍵ストアとの通信に関してはセキュアな鍵インポートが今日においては定義されていないということに求められる。様々な例示的実施形態によれば、このセキュリティ向上策を用いる場合、モバイル鍵ＤＥＫＵＳＲ５１０を導入する。ＣＭＳのレベルでユーザアクセス制御の統合を移すためにこれがなされる。それによって、プロビジョニング処理において前もってアクセス制御規則を堅牢化できる。モバイル鍵ＤＥＫＵＳＲ５１０の導入の結果、ＬＤＥＵＳＲ鍵４２０は使用されないこととなり得るのであり、関連付けられている処理がモバイル支払アプリケーションのレベルでもう用いられないものとなり得る。図５の例においては、モバイル支払アプリケーションがモバイル鍵ＤＥＫＵＳＲ５１０についての鍵ストア３１０エントリを作成できるのであり、該構成には次の設定が伴う：暗号化アルゴリズムはＡＥＳとされて、アクセス制御はユーザ認証（機器アンロック）とされて、並びに、関数は暗号化及び復号化とされる設定。

図５の例においては、クリプトグラム生成用の随意的なＷＢＣが示されている。トランザクションセッション鍵のエンドツーエンド保護を拡張することについて積極的な発行者又はウォレットプロバイダ（即ち、モバイル支払アプリケーションプロバイダ）は、クラウドベースド支払サービスのセキュリティレベルを向上させる選択肢としてＷＢＣを検討し得るのであり、自己のカスタマイズ版のソフトウェア開発キット（ＳＤＫ）を用い得る。目的はユーザドメイン２００におけるトランザクション鍵の曝露を減らすことであり、また、ユーザドメイン２００内にて実行されるＷＢＣを活用して鍵復号をなしてＷＢＣコンポーネント内に実装されているプロセスを用いてトランザクションクリプトグラムを生成することである。この場合、ウォレットのＷＢＣコンポーネントとＣＭＳとの間で共有されるトランスポート鍵（ＡＥＳ）の値をＣＭＳが知っていることを要する。ＣＭＳ−Ｄのカスタマイズ版はトランザクションセッション鍵を暗号化する必要があり、これらの暗号化された鍵は上述の改良型機構を用いてウォレットへと配信される。この例では、ウォレット内のＷＢＣコンポーネントは、ＷＢＣコンポーネントへの単一のコールを用いて一連のオペレーションを実施できるのであり、暗号化されたトランザクションセッション鍵を復号化しトランザクションセッション鍵の一時的な値を保持しトランザクションセッション鍵を用いてトランザクションクリプトグラムを生成することをなすためにそれがなされる。この場合、ＷＢＣ鍵を用いての追加的暗号化がＣＭＳによってなされてウォレットのＷＢＣコンポーネントによって用いられることになるデータを準備する。各レコードはＬＤＥ鍵４２０の下で格納及び暗号化されることができる。ＷＢＣに対してのサポートはＷＢＣベンダーによってカスタマイズされたＳＤＫレリーズの一部として提供されることができ、セキュリティ向上策に関しては鍵ストア３１０を優先することができる（このようなことがモバイル機器のＯＳにとって標準的なフィーチャである）。

管理サーバ１５０に含まれるかそれに接続されているトランザクション管理システム（ＴＭＳ、transaction management system）に対して施し得るセキュリティ向上策に関しての第三波について述べる。一部の場合においては、鍵ストア３１０の対応アルゴリズムリストに、３ＤＥＳがその一部として含まれていない場合がある。その結果、ユーザドメイン２００を狙っている攻撃者に曝されているかもしれないトランザクションセッション鍵を用いてユーザドメイン２００からトランザクションクリプトグラムを生成する代わりに、鍵ストア（システムドメイン３００）からトランザクションクリプトグラムを生成できる鍵ストアを用いる鍵マネジメントについてのエンドツーエンドなソリューションをもたらすことが困難となり得る。様々な例示的実施形態によれば、この問題に対処する別の方法としては、Android Keystoreにて定義されているＡＥＳサポートを用いて次のことに関して３ＤＥＳからＡＥＳへと移行することである：（ウォレットレベルでの）トランザクションクリプトグラム生成及び（ＴＭＳレベルでの）バリデーション。トランザクションクリプトグラム管理のアルゴリズムとしてＡＥＳを用いる場合、データ準備を担うＣＭＳへの追加の変更を避けるために次のオペレーションは変更されないものと想定されている：磁気ストライプＩＶＣＶＣ３値の生成に用いられるアルゴリズムは変更されず３ＤＥＳ鍵（ＣＭＫ＿ＣＬ＿ＵＭＤ）を伴うＭＡＣが用いられ、カードマスター鍵（ＣＭＫ＿ＣＬ＿ＭＤ又はＣＭＫ＿ＣＬ＿ＵＭＤ）及びＡＴＣをダイバーシファイアとして用いるセッション鍵生成（ＳＫ＿ＣＬ＿ＭＤ又はＳＫ＿ＣＬ＿ＵＭＤ）のアルゴリズムは変更されずパリティについての調整を導出された鍵についてなさずにＥＭＶ ＣＳＫ法が３ＤＥＳ鍵を伴って用いられ、トランザクションセッション鍵（ＳＫ＿ｘｘ＿ＭＤ及びＳＫ＿ｘｘ＿ＵＭＤ）の長さは１６バイトでありＡＥＳ（１６バイト）を（８バイトの鍵２つを用いる）３ＤＥＳの代わりに用いる場合に変更されない。ＥＭＶ及び磁気ストライプトランザクションのために用いられるクリプトグラム生成（及びバリデーション）処理に関しては調和が図られており、１６バイトブロックサイファ（ＡＥＳ）を用いるＭＡＣアルゴリズムを用いる１つの共通プロセスをＡＣ又はＣＶＣ３生成のために用い得る。ＥＭＶと磁気ストライプトランザクションの相違点は、ＭＡＣされるべきメッセージ（ＭＳＧ）を定義するために用いられるデータリストにある。（パディング処理を含む）メッセージ準備はユーザドメイン２００にてなされるのであり、これに対して、クリプトグラム生成はシステムドメイン３００にて鍵ストアを用いてトランザクション鍵をユーザドメイン２００に曝さないで行われる。トランザクション鍵の鍵ストアへのセキュア鍵インポートが利用可能とされたらば、該ソリューションの完全な堅固性が発現される。トランザクションをバリデートするに際しては、ＴＭＳは、クリプトグラム生成に関して３ＤＥＳの代わりにＡＥＳをサポートするウォレットを（例えば、具体的なＰＡＮ範囲を用いて）識別する必要がある。８バイトブロックサイファ（３ＤＥＳ）を用いるＭＡＣアルゴリズムを用いる代わりに１６バイトブロックサイファ（ＡＥＳ）を用いるＭＡＣアルゴリズムを用いるＭＡＣバリデーションをサポートするためには、ＴＭＳによって用いられるハードウェアセキュアモジュールを更新することを要する。

更新されたモバイルＯＳを用いることによって向上策に関しての第四波を実現できる。例えば、Android MarshMallow (Android M -API 23+)において定義されるAndroid Keystoreを用いる場合、鍵は鍵ストアによってランダムに生成されるか鍵ストア内にインポートされることができる。インポートフィーチャを用いる場合、鍵は、システムドメイン３００内の鍵ストアへロードされる前においては、ユーザドメイン２００において平文で利用可能にされている。鍵ストア内へとインポートされ得る鍵（例えば、モバイル鍵やトランザクション鍵）はユーザドメインを狙っている攻撃者に曝されているかもしれないのであり、今日においては、ＣＭＳ−Ｄとシステムドメイン３００内のAndroid Keystoreとの間ではエンドツーエンド鍵管理施策をデプロイすることができない。様々な例示的実施形態によれば、ＯＳプロバイダによって定義される機構を用いてセキュアな鍵インポートをサポートできる。必要があればMasterCard Incorporated社等の管理サーバ１５０のプロバイダが用いられるべきプロセスについての幾つかの選択肢を提示することができるも、新たなＡＰＩを介して利用可能とされるものと想定されるソリューションに合わせて各自が自己のプロセス（例えば、ＣＭＳによってなされる鍵のプロビジョニング等）を調整することが期待されている。

図６は、例示的実施形態による、モバイル機器６００について示す。図６を参照するに、モバイル機器６００は、プロセッサ６１０と、入力ユニット６２０と、インポータ６３０と、トランスミッタ６４０とを有する。非限定的に例示するに、モバイル機器６００は次のものたり得る：携帯電話、タブレット、ラップトップコンピュータ、ファブレット、パソコン、アプライアンス、テレビジョン等。また、モバイル機器６００は、本明細書にて説明した１つ以上の例示的実施形態を実装するモバイルＯＳ又はＯＳを含むことができる。モバイル機器６００は、図１のモバイル機器１１０に対応することができる。また、モバイル機器６００は図６に図示されていない１つ以上のコンポーネントを含むことができ、例えば受信機、ネットワークインタフェース、出力ユニット等が含まれる。

様々な例によると、モバイル機器６００は、図２のモバイル支払アプリケーション２１０等のモバイル支払アプリケーションをダウンロード及びインストールできる。非限定的に例示するに、モバイル支払アプリケーションは、デジタルウォレット、商人アプリケーション、発行者ベースド支払アプリケーション等であることができる。モバイル機器６００のユーザは、入力ユニット６２０を用いてコマンドを入力したりモバイル支払アプリケーション内に含まれる支払口座に対応するカード所有者としてのユーザの正体を検証したりすることができる。入力ユニット６２０はキーパッド、タッチパッド、マウス、音声認識モジュール、モーション認識モジュール等を含むことができ、これらはユーザからのタイピング入力、タッチ入力、入力型入力、発話入力、又はキャプチャ型入力を受信するためのものである。

プロセッサ６１０は、入力ユニット６２０を介してユーザによるコマンド入力を受信したことに応答して、モバイル機器６００のユーザドメイン内でモバイル支払アプリケーションを実行できる。本明細書にて説明するように、ユーザドメインはオペレーティング環境を含むことができ、ここにてモバイルアプリケーションが実行されまたモバイル機器のユーザらにそれへのアクセスがもたらされる。インポータ６３０はモバイル支払アプリケーションが使用する複数の暗号鍵をモバイル機器６００のシステムドメイン内へとインポートすることができる。例えば、インポータ６３０は、鍵を、システムドメイン内に含まれる鍵ストア内へとインポートすることができる。様々な態様によれば、システムドメインは、ユーザドメインよりも強く制約されたオペレーティング環境を有するのであり、また、モバイル機器６００のＯＳによって制御されていることができる。例えば、システムドメインはモバイル機器６００のユーザからアクセスすることはできないものとでき、また、ＯＳの単独支配下に置かれていることができる。ＯＳの例としては、Google Android、Apple iOS、Windows Phone OS等が挙げられる。

プロセッサ６１０は、１つ以上のインポートされた鍵を用いてシステムドメイン内のモバイル支払アプリケーションの支払情報を暗号化でき、ユーザドメインにてモバイル支払アプリケーションを実行している間にこれをなせる。例えば、プロセッサ６１０は、モバイル支払アプリケーションと関連付けられている１つ以上の支払カードからの支払情報について暗号化を行いうる。例を挙げるに、暗号化支払情報は次のものを含み得る：ＰＡＮ、失効関係、カードセキュリティコード、ＰＩＮ、トークン化支払情報等。別の例を挙げるに、暗号化支払情報は、モバイル機器６００と支払ネットワークやＣＭＳや管理サーバ等との間で送信されたメッセージ等の支払データを含み得る。よって、鍵をシステムドメインにインポートすることによって及びシステムドメインにて支払情報を暗号化することによって、機密なカード所有者情報及び気密な支払アプリケーション情報（payment application information）（即ち、鍵、暗号化オペレーション、支払情報等）がユーザドメインにて曝露されることを防止できこれらをシステムドメインに画することができる。また、システムドメインは、ユーザドメインに対しての追加の保護レイヤを含んでいることができる。例えば、ユーザドメインとシステムドメインとの間でファイアウォールを実装しておくことができ、攻撃者がユーザドメインへのアクセスを獲得したとしてもシステムドメインに関して更なる保護がもたらされていることになる。

トランスミッタ６４０は、商人とした商品及び／又は役務についてのトランザクションに関して支払をなすために、暗号化支払情報を商人（即ち、商人サーバ又は他のコンピューティング装置）へと送信（transmit）できる。様々な例示的実施形態によれば、トランスミッタ６４０は、暗号化支払情報をユーザドメイン経由で転送（transfer）せずに、暗号化支払情報をシステムドメインから直接的に商人へと送信できる。したがって、機密暗号化データはモバイル機器６００のユーザドメイン内で曝露されることが防止されるのであり、システムドメイン内にてインポート及びオペレートされるに限られる。

インポータ６３０によってシステムドメイン内へとインポートされた（例えば、システムドメインによって受信された）複数の暗号鍵は、次のような様々な鍵を含み得る：公開鍵、秘密鍵、モバイル鍵、モバイルセッション鍵、ランダム生成鍵等。例えば、暗号鍵は次のことをなすための少なくとも１つのモバイル鍵を含み得る：ＣＭＳから受信された内容を復号化すること及びＣＭＳへと送られるべき内容を暗号化すること。別の例に言及するに、複数の暗号鍵は、ＣＤＡシグネチャを生成するためのＩＣカード（ＩＣＣ）鍵ペアを含み得る。プロセッサ６１０は、鍵をシステムドメインにインポートすることに加えて、モバイル支払アプリケーションで用いるための暗号鍵をシステムドメイン内で生成でき、システムドメインの鍵ストア内に生成された暗号鍵を格納できる。例えば、プロセッサ６１０は、モバイル支払アプリケーションによって用いられるローカルデータベース内に格納されたデータに関して復号化及び暗号化を行うためのＬＤＥ鍵を生成することができる。

図７は、例示的実施形態による、モバイル機器の複数のドメインでなされる支払方法７００について示す。図７を参照するに、Ｓ７１０では、モバイル機器内においてユーザドメインとシステムドメインとが確立される。ユーザドメインは、モバイルアプリケーションが実行されまたモバイル機器のユーザにアクセスをもたらすオペレーティング環境を、含み得る。システムドメインは、ユーザドメインよりもより制限的なオペレーティング環境を有することができ、モバイル機器のＯＳによって制御されていることができる。様々な例示的実施形態によれば、システムドメインは、ユーザドメインと比較して、より厳重に制御されたオペレーティング環境とされることができる。システムドメインに関してはそこへの限定アクセスを伴い得るのであり、また、そこでなし得るオペレーションタイプに制約が課されていることができる。例を挙げるに、システムドメインは、ＯＳによって規制乃至制御されていることができる。

方法について述べるに、Ｓ７２０ではモバイル機器のユーザドメイン内にてモバイル支払アプリケーションを実行することが含まれ、Ｓ７３０ではモバイル支払アプリケーションによって用いられるための複数の暗号鍵をモバイル機器のシステムドメイン内にインポートすることが含まれる。モバイル支払アプリケーションの実行ステップがインポートステップに先行しているも、例示的実施形態はそのような構成には限定されないことに留意されたい。例えば、モバイル支払アプリケーションの実行に先んじて暗号鍵がインポートされることができる。別の例を挙げるに、暗号鍵のインポートがモバイル支払アプリケーションの実行と同時になされてもよい。方法について述べるに、Ｓ７４０では、ユーザドメインにてモバイル支払アプリケーションを実行している間に、システムドメインにて１つ以上のインポートされた鍵を用いてモバイル支払アプリケーションの支払情報を暗号化することがさらに含まれる。様々な例示的実施形態によれば、各鍵によってなされ得るオペレーション及び関数のタイプは、モバイル機器のＯＳによって妨げられたり制限されたりすることができる。例えば、鍵の用途を復号化ではなく暗号化のみに限定できる（その逆も可）。別の例を挙げるに、鍵のインポートを可能とするもエクスポート（export）を許さないこともできる。方法について述べるに、Ｓ７５０では商人ウェブサイトを実行している商人サーバや第三者サーバ等の商人へと暗号化支払情報を送信することがさらに含まれる。ここで、送信行為（transmitting）は、暗号化支払情報をユーザドメインを介して転送（transfer）することなく暗号化支払情報をシステムドメインから直接的に商人へと送信（transmit）することを含み得る。

図７の例においては、インポート行為は、システムドメイン内で運用される鍵ストア内へと複数の暗号鍵をインポートすることを含み得る。この場合、ユーザドメインとシステムドメインとの間でファイアウォールが存在し得るのであり、従って、システムドメイン内に格納されたデータについて更なる保護のレイヤが追加されることとなる。また、システムドメインはモバイル機器のユーザによってアクセスできないものとされ得るのであり、また、ＯＳの単独支配下に置かれているものとされ得る。その結果、ユーザドメインにて実行されているモバイル支払アプリケーションを用いる支払プロセス中においては、暗号鍵がよりセキュアな環境下において格納及びオペレートされていることとなり得る。例えば、複数の暗号鍵は次のものを含み得る：ＣＭＳから受信された内容を複合するための少なくとも１つのモバイル鍵、ＣＤＡシグネチャを生成するためのＩＣカード（ＩＣＣ）鍵ペア等その他類するもの。また、１つ以上の暗号鍵をシステムドメイン内にて生成でき例えば鍵ストア等のシステムドメイン内において格納することができる。例えば、モバイル支払アプリケーションによって用いられるローカルデータベース内に格納されたデータについて復号化及び暗号化をなすためのＬＤＥ鍵を生成することができる。

様々な例示的実施形態によれば、本明細書ではモバイル支払アプリケーションの暗号鍵を保護するためのシステム及び方法が説明されている。例示的実施形態では、支払アプリケーションによって使用される暗号鍵がモバイル機器のシステムドメインを介してインポート（import）、実行、デポート（deport）、送信、受信される。システムドメインはモバイルＯＳの単独支配下に置かれていることができ、それによって暗号鍵へのアクセスを制限することができ、また、暗号鍵を用いてなされ得るオペレーションを制限することができる。

本明細書では、カード、トランザクションカード、金融トランザクションカード、支払カード等の用語は、クレジットカード、デビットカード、プリペイドカード、チャージカード、会員カード、プロモーションカード、頻繁搭乗者カード、ＩＤカード、ギフトカード等の任意の適切なトランザクションカードを意味する。別の例を挙げるに、先述の用語は、携帯電話、スマートフォン、パーソナルデジタルアシスタント（ＰＤＡ）、キーフォブ、コンピュータ等の支払口座情報を格納し得る任意の他の装置又は媒体を意味することができる。トランザクションカードは、トランザクションを行うための支払方法として用いられることができる。

上述の記載に基づいて理解されるように、上述した本開示の前記実施形態は、コンピュータソフトウェア、ファームウェア、ハードウェア、又はそれらの任意の組合せ若しくはサブセットを含む、コンピュータのプログラミング又はエンジニアリング技術を用いて実施され得る。コンピュータ可読な命令を有する、そのような結果として生じるプログラムのいずれについても、１つ又はそれ以上の非一時的コンピュータ可読媒体内に組み込まれ、又はそれと共に提供され得るのであり、その結果、本開示で説明される実施形態に係るコンピュータプログラム製品、すなわち、製造品を構成する。非限定的に述べるに、非一時的コンピュータ可読媒体は例えば、固定ドライブ、ディスケット（登録商標）、光学ディスク、磁気テープ、フラッシュメモリ、ＲＯＭ等の半導体メモリ等であることができ、並びに／又は、インターネットや他の通信ネットワーク若しくはリンク等の伝送／受信媒体等とされ得る。コンピュータコードを含む製造品は、１つの記録媒体から直接命令を実行することによって、又は、１つの記録媒体から別の記録媒体へコードをコピーすることによって、又はコードをネットワーク上で送信することによって、構成され及び／又は利用され得る。

（プログラム、ソフトウェア、ソフトウェアアプリケーション、アプリ、コード等とも称される）コンピュータプログラムは、プログラム可能プロセッサ用のマシン命令を含み得るのであり、また、高レベルの手続き型言語及び／若しくはオブジェクト指向型プログラミング言語をもって並びに／又はアセンブリ／マシン言語をもって実装され得る。本明細書にて用いられる場合、「マシン可読媒体」という用語及び「コンピュータ可読媒体」という用語は、マシン命令及び／又はデータをプログラム可能なプロセッサに提供するために用いられる任意のコンピュータプログラム製品、機器、及び／又は装置（例えば、磁気ディスク、光学ディスク、メモリ、プログラマブル論理装置（ＰＬＤ、programmable logic device））を意味するのであり、マシン可読信号としてマシン命令を受信するマシン可読媒体も含まれる。もっとも、「マシン可読媒体」及び「コンピュータ可読媒体」には、一時的信号は含まれない。「マシン可読信号」との用語は、マシン命令及び／又は任意の他の種類のデータをプログラム可能なプロセッサに提供するために用いられ得る任意の信号を意味する。

上述の説明及び本明細書における処理の例示は、処理の諸ステップの実行順序について固定順序を示唆するものとみなすべきではない。むしろ、処理のステップは実施可能な任意の順序で行われ得るのであり、少なくとも一部のステップに関しては同時実行も含まれる。

本発明は具体的な例示的実施形態との関連で説明されているも、添付の特許請求の範囲にて提示されている本発明の精神及び範疇から逸脱せずに、当業者にとって明かである様々な変更、置換、修正を開示の実施形態に対して施し得るものと理解されたい。

Claims (20)

1. モバイル機器に関する方法であって、
   モバイル支払アプリケーションを前記モバイル機器のユーザドメイン内にて実行するステップであって、前記ユーザドメインは前記モバイル機器のユーザによってモバイルアプリケーションの実行及びアクセスがなされるオペレーティング環境を備える、ステップと、
   前記モバイル支払アプリケーションで用いるための複数の暗号鍵を、前記モバイル機器のシステムドメイン内にインポートするステップであって、前記システムドメインは前記モバイル機器のオペレーティングシステムによって制御される更にセキュアなオペレーティング環境を備える、ステップと、
   前記ユーザドメイン内にて前記モバイル支払アプリケーションを実行しつつ、前記システムドメイン内にて前記モバイル支払アプリケーションの支払情報を、インポートされた前記鍵の１つ以上を用いて暗号化するステップと、
   暗号化された前記支払情報を商人へと送信するステップとを含む、方法。
2. 請求項１に記載の方法において、前記インポートするステップは、前記システムドメイン内で運用される鍵ストア内に前記複数の暗号鍵をインポートすることを含む、方法。
3. 請求項１に記載の方法において、前記ユーザドメインと前記システムドメインとの間にファイアウォールが存在する、方法。
4. 請求項１に記載の方法において、前記システムドメイン内にインポートされた前記複数の暗号鍵は、クレデンシャル管理システム（ＣＭＳ、credential management system）から受信された内容を復号化するための少なくとも１つのモバイル鍵を備える、方法。
5. 請求項１に記載の方法において、前記システムドメイン内にインポートされた前記複数の暗号鍵は、ＣＤＡシグネチャを生成するための集積回路カード（ＩＣＣ、integrated circuit card）鍵ペアを備える、方法。
6. 請求項１に記載の方法において、前記モバイル支払アプリケーションと共に用いるために暗号鍵を前記システムドメイン内にて生成するステップと、生成された前記暗号鍵を前記システムドメイン内に格納するステップとをさらに含む、方法。
7. 請求項６に記載の方法において、生成された前記暗号鍵は、前記モバイル支払アプリケーションによって用いられるローカルデータベース内に格納されたデータを復号化及び暗号化するためのローカルデータベース暗号（ＬＤＥ、local database encryption）鍵を備える、方法。
8. 請求項１に記載の方法において、前記システムドメインは、前記モバイル機器の前記ユーザによってアクセスすることができずまた前記オペレーティングシステムの単独支配下にある、方法。
9. 請求項１に記載の方法において、前記送信するステップは、暗号化された前記支払情報を前記システムドメインから前記ユーザドメインへと転送することと、暗号化された前記支払情報を前記ユーザドメインから前記商人へと送信することとを含む、方法。
10. モバイル機器であって、
    モバイル支払アプリケーションを前記モバイル機器のユーザドメイン内にて実行するように構成されたプロセッサであって、前記ユーザドメインは前記モバイル機器のユーザによってモバイルアプリケーションの実行及びアクセスがなされるオペレーティング環境を備える、プロセッサと、
    前記モバイル支払アプリケーションで用いるための複数の暗号鍵を前記モバイル機器のシステムドメイン内にインポートするように構成されたインポータであって、前記システムドメインは前記モバイル機器のオペレーティングシステムによって制御される更にセキュアなオペレーティング環境を備える、インポータとを備えるモバイル機器であって、
    前記プロセッサは、前記ユーザドメイン内にて前記モバイル支払アプリケーションを実行しつつ、前記システムドメイン内にて前記モバイル支払アプリケーションの支払情報を、インポートされた前記鍵の１つ以上を用いて暗号化するようにさらに構成されている、モバイル機器。
11. 請求項１０に記載のモバイル機器において、暗号化された前記支払情報を商人へと送信するように構成されたトランスミッタをさらに備える、モバイル機器。
12. 請求項１１に記載のモバイル機器において、前記プロセッサは暗号化された前記支払情報を前記システムドメインから前記ユーザドメインへと転送し、前記トランスミッタは暗号化された前記支払情報を前記ユーザドメインから前記商人へと送信する、モバイル機器。
13. 請求項１０に記載のモバイル機器において、前記インポータは前記システムドメイン内に含まれている鍵ストア内に前記複数の暗号鍵をインポートする、モバイル機器。
14. 請求項１０に記載のモバイル機器において、前記ユーザドメインと前記システムドメインとの間にファイアウォールが存在する、モバイル機器。
15. 請求項１０に記載のモバイル機器において、前記システムドメイン内にインポートされた前記複数の暗号鍵は、クレデンシャル管理システム（ＣＭＳ、credential management system）から受信された内容を復号化するための少なくとも１つのモバイル鍵を備える、モバイル機器。
16. 請求項１０に記載のモバイル機器において、前記システムドメイン内にインポートされた前記複数の暗号鍵は、ＣＤＡシグネチャを生成するための集積回路カード（ＩＣＣ、integrated circuit card）鍵ペアを備える、モバイル機器。
17. 請求項１０に記載のモバイル機器において、前記プロセッサは、前記モバイル支払アプリケーションと共に用いるために暗号鍵を前記システムドメイン内にて生成し、また、生成された前記暗号鍵を前記システムドメイン内に格納するようにさらに構成されている、モバイル機器。
18. 請求項１６に記載のモバイル機器において、生成された前記暗号鍵は、前記モバイル支払アプリケーションによって用いられるローカルデータベース内に格納されたデータを復号化及び暗号化するためのローカルデータベース暗号（ＬＤＥ、local database encryption）鍵を備える、モバイル機器。
19. 請求項１０に記載のモバイル機器において、前記システムドメインは、前記モバイル機器の前記ユーザによってアクセスすることができずまた前記モバイル機器の前記オペレーティングシステムの単独支配下にある、モバイル機器。
20. 命令が格納された非一時的コンピュータ可読媒体であって該命令が実行されるとモバイル機器に関する方法をコンピュータに行わせる非一時的コンピュータ可読媒体であって、該方法は、
    モバイル支払アプリケーションを前記モバイル機器のユーザドメイン内にて実行するステップであって、前記ユーザドメインは前記モバイル機器のユーザによってモバイルアプリケーションの実行及びアクセスがなされるオペレーティング環境を備える、ステップと、
    前記モバイル支払アプリケーションで用いるための複数の暗号鍵を、前記モバイル機器のシステムドメイン内にインポートするステップであって、前記システムドメインは前記モバイル機器のオペレーティングシステムによって制御される更にセキュアなオペレーティング環境を備える、ステップと、
    前記ユーザドメイン内にて前記モバイル支払アプリケーションを実行しつつ、前記システムドメイン内にて前記モバイル支払アプリケーションの支払情報を、インポートされた前記鍵の１つ以上を用いて暗号化するステップと、
    暗号化された前記支払情報を商人へと送信するステップとを含む、非一時的コンピュータ可読媒体。

Images