無線ネットワークを使用してクレジットカード個人化を利用可能にすることができる方法、システム、及びモバイルデバイス
クレジットカード個人化データを無線(OTA)で送信することができるセキュアチャンネルを作成する方法が提供される。詳細には、汎用認証アーキテクチャ(GAA)を使用して、ユーザ装置(UE)とネットワークアプリケーション機能(NAF)サーバとして機能を果たす個人化アプリケーションサーバ又はビューロー間のセキュア通信チャンネルを設定することができる。ユーザ装置、個人化アプリケーションサーバ(例えばNAFサーバ)、個人化アプリケーションサーバ及びユーザ装置を具現化するシステム、及びコンピュータプログラム製品もまた、クレジットカード個人化データをOTAで送信することができるGAAなどを介したセキュアチャンネルを作成するために提供される。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、モバイル端末をクレジットカード個人化に対して利用可能にすることに関し、更に詳細には、無線ネットワークを使用してモバイル端末をクレジットカード個人化に利用可能にすることに関する。
【背景技術】
【0002】
MasterCard及びVisaなどのクレジットカード会社は、現在のところクレジットカード個人化を行うためにEMV(Europay、Mastercard、及びVisa)クレジットカード決済規格を利用することに成功している。クレジットカード個人化とは、EMVチップを含むスマートカードなどのユーザのクレジットカードにセキュリティ及びユーザデータが送信されるプロセスのことを指す。この個人化プロセスの最初のステップは、発行者セキュリティドメインを設定する段階であり、現在では通常スマートカード製造業者の工場で行われる。セキュリティドメインは、アプリケーションデータのダウンロード及び実際の個人化を行うのに使用される個人化デバイスと、クレジットカードに埋め込まれたEMVチップとの間でセキュアチャンネルを作成するのに使用される。セキュアチャンネルは、公的に容易に入手可能ではない状態で情報を送信することができるあらゆるチャンネルであり、例えば、種々の暗号化方式を使用して或いはチャンネルのエンドポイント両方を認証することによって作成することができる。セキュアチャンネルが作成されると、個人化デバイスはEMVチップを起動し、最終的には個人化データをEMVチップに送信することができる。クレジットカード会社は、この個人化プロセスを行うためにOrga、Axalto、Giesecke及びDevrient、又はCedexなどのスマートカード製造業者に頼ることが多い。これらの製造業者は、ユーザ固有のデータを各クレジットカードに埋め込むために、必要とされるユーザ個人化データをクレジットカード会社から受け取り、以下に説明されるステップを行う。このように、スマートカード製造業者は、クレジットカード会社に代わってクレジットカード発行者として役割を果たすことができる。
【0003】
図1は、今日クレジットカード個人化を行う場合に、例えばスマートカード製造業者が行うことができるステップを示すフローチャートである。ステップ101で、個人化デバイスは、EMVチップにリセットコマンドを送ることによってEMVチップを起動する。ステップ102で、EMVチップは、リセット応答(ATR)を個人化デバイスに送ることによって応答する。次いでステップ103で、個人化する必要のあるアプリケーション、例えばカードに予めロードされていた特定のクレジットカードアプリケーションが選択コマンドを使用して選択される。ステップ104で、EMVチップは、ファイルデータ構造情報などの必要なファイル制御情報を返し、ステップ105で、初期化更新コマンドがEMVチップに個人化デバイス乱数を提供する。この乱数は、セキュアチャンネルを設定するために暗号文作成の一部として使用される。
【0004】
ステップ106で、チップは、シーケンスカウンタ(セッションキー導出用)、チャレンジ(暗号文作成の一部として使用される)、カード暗号文(チップを認証するのに使用される)、セッションDES(データ暗号化標準)マスターキーの識別子及びバージョン、暗号化用導出データ、解読及びメッセージ認証コード(MAC)DES(データ暗号化標準)キー、及びソースチャンネルプロトコル識別子を送ることによって応答する。
【0005】
ステップ107で、個人化デバイスは、外部認証コマンドで暗号文を提供することによって自らをEMVチップに対して認証する。次にステップ108で、EMVチップは外部認証を確認し、次いで、ステップ109で、個人化デバイスが、幾つかの格納データコマンドの1つ及び最終的には特別な最後の格納データを送出することによってデータのEMVチップへの転送を開始する。最後にステップ110で、データ記憶が確認される。
【0006】
最近では、MasterCard及びVisaなどの会社が、例えばPayPass又はVisa Waverとして知られる新しい決済方法を導入しており、RFID(無線識別)機能を有するクレジットカードが製造されている。この新しい方法では、RFIDデバイスが小売店に備え付けられ、該RFIDデバイスは、ユーザが読取装置の数センチメートル手前に自分のカードを置くと、これらのRFID対応クレジットカードを読み取ることができる。この新しい方法によってクレジットカードの決済がより早くより簡単になる。類似の近接RFIDシステムは、Octopus(オクトパス)又はヘルシンキ公共交通などの公共交通システムでも使用されている。例えば、RFID機能を含むプリペイドのバス又は列車のカードが顧客によって購入され、バス停又は列車の駅にあるRFID読取装置と共に使用して、バス又は列車に乗るためのチケットを購入することができる。
【0007】
種々のベンダーロケーション、並びに種々の公共交通ステーションでのRFID読取装置の使用は、これらの販売時点情報管理(POS)RFID読取装置を利用できる他のタイプの決済方法の機会を与える。このような1つの決済方法によって、個人が自分の携帯電話或いは携帯電話又はPDAに接続(例えば、ブルートゥース、ケーブル、RFID、又は赤外線を介して)されているパーソナルデジタルアシスタント(PDA)又はモバイルパーソナルコンピュータ(PC)などのある他のモバイルデバイスを使用して、クレジットカード又は他のユーザ固有の情報を転送することが可能になる。言い換えると、個人が、自分のクレジットカード又はプリペイド公共交通カードを使用する場合と同じ状況で自分の携帯電話を使用することができるようになる。例えば、ユーザの個人クレジットカードの詳細をモバイルデバイスに組み込み、POS RFID読取装置に送信することができるようになる。例えば、PayPass及びVisaWaveに使用されるのと同じプロトコルを使用することができる。この場合、モバイルデバイスは、PCに接続されることになり、PCは、モバイルデバイスに必要なデータを要求し、次いで、このデータをPOSに(インターネットを介して)転送することになる。
【0008】
このモバイルEMVシステムを実施するために、最初にシステム全体を証明する必要がある。EMV証明は、EMV発行者として役割を果たすことを意図する全てのスマートカード発行者が従う必要のある、EMVによって定められた高価な手続である。証明なしでは、クレジットカード会社は、内包する固有リスクを受け入れてモバイルEMVソリューションを会社の決済インフラストラクチャに「接続する」可能性は低い。しかしながら、モバイルデバイスは、付加的なソフトウェアアプリケーションを実行しスマートカードよりも多くの外部インターフェースを有することができるので、スマートカードよりも遙かにオープンである。この結果、既存のモバイルデバイスハードウェア上で構築されたモバイルEMVソフトウェアアプリケーションは、EMV証明を取得しようとする場合に重大な問題に直面する可能性があり、従って、必要な証明の取得が非常に困難で費用のかかるものになる。
【0009】
1つの代替の解決策は、既存のモバイルデバイスハードウェア上にモバイルEMVソフトウェアアプリケーションを構築するのではなく、既に証明済みのEMVチップ又はスマートカードをモバイルデバイスに組み込むことである。これを行うための1つの選択肢は、第2のスロットをモバイルデバイスに取り入れることであり、この場合、EMVチップは、例えばスマートカード製造業者で通常通り個人化し、次いで、後でユーザによってモバイルデバイスに挿入することができる。しかしながら、この方法も大量市場に対するモバイルデバイスのハードウェアコストが追加されることに起因して、極めて高価になる可能性がある。他の選択肢は、多くのアプリケーションをサポートする汎用ICカード(UICC)をモバイルデバイスに組み込むか、或いは、証明済みのEMVチップをモバイルデバイスの製造中にデバイスに埋め込むかのいずれかになる。
【0010】
しかしながら、製造中には、最終的に誰が各モバイルデバイスを所有するかが分からず、従って、通常の製造プロセス中にあらゆる決済データが完全に個人化されるのが阻止される。これは、カードの受取人がカードの発行中に既知である今日のクレジットカードビジネスとは相違する。1つの解決策は、クレジットカードに関して上述されたのと類似の方法で、製造中にモバイルデバイスにUICCを組み込むか或いは証明済みEMVチップを埋め込み、次いで、ユーザがスマートカード製造業者又は個人化ビューローに自分のモバイルデバイスを送ることを必要とし、そこで個人化を行うことができるようにすることである。しかしながら、これには、ユーザがある時間期間の間自分のモバイルデバイスをスマートカード製造業者に明け渡すことが必要になる。別の解決策では、ユーザがクレジットカードを申し込むのと同じ方法でクレジットカード機能を有する電話を申し込むことが必要である。次いで、クレジットカード機能を有する完全に個人化されたモバイルデバイスは、直接ユーザに送られることになる。しかしながら、これらの選択肢では、既存の製造プロセス及び販売網を変更することが必要になり、これらは、高コストで時間がかかることになる。
【0011】
別の解決策は、ユーザが自分のモバイルデバイスを購入した後で、無線(OTA)で個人化を行うことである。しかしながら、セキュリティデータのOTA送信には一定のリスクが内在する。上述のように、個人化プロセスを開始する前に、個人化デバイスとEMVチップ又はUICCとの間のセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成する必要がある。従って、モバイルデバイスにOTAでクレジットカード個人化データを送信する安全な手段、すなわち必要な発行者セキュリティドメイン及びセキュアチャンネルを作成する手段に対するニーズがある。
【発明の開示】
【0012】
一般的に言えば、本発明の例示的な実施形態は、クレジットカード個人化又は公共交通チケット発券データなどの個人化データを無線(OTA)で送信することができるセキュアチャンネルの設定のための発行者セキュリティドメインを作成する方法を提供することによって、公知の従来技術に対して改善をもたらす。詳細には、例示的な実施形態では、汎用認証アーキテクチャ(GAA)を使用して、ユーザ装置(UE)とネットワークアプリケーション機能(NAF)サーバとして働く個人化アプリケーションサーバ又はビューローとの間のセキュア通信チャンネルを作成するのに使用することができる共有秘密を設定することができる。
【0013】
一般に、本明細書で使用されるユーザ装置とは、ユーザ装置のユーザによってリクエストされた商品又はサービスに課金する機能を組み込んだモバイルデバイス(例えば、セルラー電話、パーソナルデジタルアシスタント(PDA)、ラップトップ、ページャーなど)を指す。例えばユーザ装置は、モバイルデバイスに埋め込まれたEMV証明済みチップ、或いはモバイルデバイスに関連したUICC又はスマートカードに記憶された1つ又はそれ以上のEMVアプリケーションのいずれかを介してEMV機能を有するモバイルデバイスを意味することができる。1つの例示的な実施形態では、EMVアプリケーションは、ネットワークオペレータのUICC又はスマートカード上に記憶することができる。或いは、1つ又はそれ以上のEMVアプリケーションを含む別個のEMV固有UICC又はスマートカードを提供することができる。この実施形態では、モバイルデバイスは、それぞれのUICC(すなわち、ネットワークオペレータUICCとEMV固有のUICC)に対して2つのスロットを含み、EMV固有のUICC又はスマートカードは、取り除くことができ、2つのスロットを所有する別のモバイルデバイスと共に使用することができる。このようにしてユーザは、EMV固有のUICC又はスマートカードをモバイルデバイスに挿入することによって異なるモバイルデバイス(例えばユーザ自身の、並びにユーザの母親、父親、姉妹などの)をクレジットカード又は公共交通チケット発券カードとして簡単に使用することができる。
【0014】
例示的な実施形態において、セキュアチャンネルを介して個人化データを受信することができるユーザ装置、セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバ(例えばGAAが使用されているNAFサーバ)、及びこのユーザ装置と個人化アプリケーションサーバを実現するシステムもまた備えられる。
【0015】
従って本発明の1つの態様によれば、個人化アプリケーションサーバからユーザ装置への個人化データの無線(OTA)送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するための方法が提供される。1つの例示的な実施形態では、本方法は、(1)ユーザ装置及び個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する段階と、(2)1つ又はそれ以上の共有秘密鍵を使用して発行者セキュリティドメインを作成する段階とを含み、ここで発行者セキュリティドメインは、個人化アプリケーションサーバからユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる。
【0016】
本発明の別の態様によれば、第1エンティティから第2エンティティにセキュアな方法で個人化データをOTAで送信する方法が提供される。1つの例示的な実施形態では、本方法は、(1)汎用認証アーキテクチャ(GAA)を使用して第1及び第2エンティティに既知の1つ又はそれ以上の共有秘密鍵を生成する段階と、(2)1つ又はそれ以上の共有秘密鍵を使用して第1と第2エンティティとの間に発行者セキュリティドメインを作成する段階と、(3)発行者セキュリティドメインを使用して第1と第2エンティティとの間にセキュアチャンネルを設定する段階と、(4)セキュアチャンネルを介して個人化データを送信する段階とを含む。
【0017】
本発明の更に別の態様によれば、セキュアチャンネルを介して個人化アプリケーションサーバからの個人化データを受信することができるユーザ装置が提供される。1つの例示的な実施形態では、ユーザ装置は、該ユーザ装置に固有の少なくとも1つの秘密鍵を含むユーザ識別モジュールと、ユーザ識別モジュールと通信するセキュアコアとを含む。秘密鍵は、セキュアコア上に記憶することができる個人化アプリケーションサーバ及びユーザ装置に既知の1つ又はそれ以上の共有秘密鍵を生成するのに使用することができる。これらの共有秘密鍵は次いで、発行者セキュリティドメインを作成するのに使用され、該発行者セキュリティドメインが、ユーザ装置が個人化データを受信することができるセキュアチャンネルを設定するのに使用することができる。
【0018】
本発明の別の態様によれば、モバイルクレジットカード決済システムが提供される。1つの例示的な実施形態では、本システムは、個人化アプリケーションサーバと、個人化アプリケーションサーバからユーザ装置に個人化データをOTAで送信するためのセキュアチャンネルを介して個人化アプリケーションサーバと通信するユーザ装置とを含む。個人化アプリケーションサーバ及びユーザ装置に既知の1つ又はそれ以上の共有秘密鍵は、セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するのに使用することができる。
【0019】
本発明の更に別の態様によれば、個人化アプリケーションサーバからユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するためのシステムが提供される。1つの例示的な実施形態において、本システムは、(1)ユーザ装置及び個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する手段と、(2)1つ又はそれ以上の共有秘密鍵を使用して発行者セキュリティドメインを作成する手段と、を含み、ここで発行者セキュリティドメインは、個人化アプリケーションサーバからユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる。
【0020】
本発明の更に別の態様によれば、個人化アプリケーションサーバからユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するためのコンピュータプログラム製品が提供される。1つの例示的な実施形態では、コンピュータプログラム製品は、コンピュータ可読プログラムコード部分が記憶された少なくとも1つのコンピュータ可読記憶媒体を含む。コンピュータ可読プログラムコード部分は、(1)ユーザ装置及び個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成するための第1の実行可能部分と、(2)1つ又はそれ以上の共有秘密鍵を使用して発行者セキュリティドメインを作成する第2の実行可能部分と、を含むことができ、ここで発行者セキュリティドメインは、個人化アプリケーションサーバからユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる。
【0021】
本発明の別の態様によれば、セキュアチャンネルを介して個人化アプリケーションサーバから個人化データを受信することができるユーザ装置が提供される。1つの例示的な実施形態では、このユーザ装置は、(1)ユーザ装置及び個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成するための手段と、(2)ユーザ装置に共有秘密鍵を記憶するための手段と、(3)共有秘密鍵を使用して、発行者セキュリティドメインを作成する手段とを含むことができる。発行者セキュリティドメインは、ユーザ装置が個人化データを受信することができるセキュアチャンネルを設定するのに使用することができる。1つの例示的な実施形態では、共用鍵をユーザ装置上でセキュアな環境で記憶することができる。
【0022】
本発明の更に別の態様によれば、セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバが提供される。1つの例示的な実施形態では、個人化アプリケーションサーバは、プロセッサと、該プロセッサと通信するメモリとを備え、該メモリは、プロセッサによって実行可能なアプリケーションを記憶する。1つの例示的な実施形態では、このアプリケーションは、実行時にセキュリティデータに対するリクエストを受信し、該リクエストに応答して認証チャレンジを送信することができ、ここでチャレンジは、共有秘密鍵を認証に使用するようにする旨のリクエストを含む。本アプリケーションは更に、実行時に共有秘密鍵を使用して暗号化された応答を受信し、該応答を検証し、検証時に共有秘密鍵を使用してリクエストされたセキュリティデータを暗号化して、暗号化されたセキュリティデータを送信することができる。暗号化されたセキュリティデータは次に、セキュアチャンネルを設定するのに更に使用することができる発行者セキュリティドメインを作成するために使用することができる。メモリ上に記憶されたアプリケーションは更に、実行時に設定されたセキュアチャンネルを介して個人化データを送信することができる。
【0023】
本発明の更に別の態様によれば、セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバが提供される。1つの例示的な実施形態では、個人化アプリケーションサーバは、(1)セキュリティデータに対するリクエストを受信する手段と、(2)このリクエストに応答して、共有秘密鍵を認証に使用する旨のリクエストを含む認証チャレンジを送信する手段と、(3)共有秘密鍵を使用して暗号化された応答を受信する手段と、(4)応答を検証する手段と、(5)検証時に、共有秘密鍵を使用してリクエストされたセキュリティデータを暗号化し、セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するために使用することができる暗号化されたセキュリティデータを送信する手段と、(6)セキュアチャンネルを介して個人化データを送信する手段とを含む。
【発明を実施するための最良の形態】
【0024】
このように本発明について概略的に説明したが、ここで、必ずしも一定の縮尺ではない添付図面について述べる。
【0025】
添付図面を参照しながら本発明を以下により詳細に説明するが、該図面には本発明の全てではなく一部の実施形態が図示されている。実際、これらの発明は、多くの異なる形式で具現化することができ、本明細書に記載される実施形態に限定されるものと解釈すべきではなく、逆に、これらの実施形態は、本開示が適用される法的要件を満たすように提供される。同じ番号は全体を通して同じ要素を示す。
【0026】
1つの例示的な実施形態では、クレジットカード個人化又は公共交通チケット発券データなどの個人化情報をOTAでモバイルデバイスに送信するためのセキュアチャンネルを作成するのに使用することができる発行者セキュリティドメインが作成される。有利な実施形態では、この発行者セキュリティドメインは、汎用認証アーキテクチャ(GAA)を使用して設定される。GAAは、第3世代パートナーシッププロジェクト(3GPP)によって提案され、「Generic Authentication Architecture(GAA:汎用認証アーキテクチャ);システム概要(2005年3月6日発行)(3GPP TS33.919v6.2.0(2005−03)」と題された3GPP技術仕様33.919において説明された認証メカニズムであり、この内容は引用により全体が本明細書に組み込まれる。GAAは、携帯電話、パーソナルデジタルアシスタント(PDA)、又はモバイルPC(パーソナルコンピュータ)、或いは同様のものなどのモバイルデバイスのユーザのための種々のアプリケーション及びサービスに対するセキュリティ手続として使用されることを目的とする。
【0027】
GAA及び汎用ブートストラッピング手続
GAAは、ユーザ装置(UE)に関連して提供された特定のセキュア記憶エンティティ上、並びにモバイルオペレータネットワークの加入者データベース内に記憶されている共有秘密鍵に基づく。UEのセキュア記憶エンティティは、加入者識別モジュール(SIM)又は例えばユニバーサルSIM(USIM)であるSIM様アプリケーションを含み汎用ICカード(UICC)などの適切なセキュリティモジュール又は識別モジュールによって提供することができる。加入者データベースは、ホームロケーションレジスタ(HLR)又はホーム加入者サーバ(HSS)などのネットワークエンティティによって提供することができる。セキュアユーザ識別記憶エンティティ及び加入者データベースエンティティは通常、ユーザ識別を発行し、通常は加入者データベースを実行し所有するモバイルネットワークオペレータによって制御される。オペレータは、例えば、モバイルデバイスに関連するGAAのアプリケーションにおいて、モバイルデバイスユーザのサービスプロバイダ(例えばT−Mobile又はSprint)とすることができる。GAA下で、HSS又はHRL及びUEのセキュア記憶エンティティは、モバイルネットワークオペレータによってHSS/HRL及びセキュア記憶エンティティに与えられ、ユーザ及びモバイルネットワークを認証するのに使用される共通の共有秘密を有する。次いで、このオペレータ所有の共有秘密は、新しいアプリケーション固有の共用鍵を導出するためにGAAによって使用される。
【0028】
図2は、ホーム加入者サーバ(HSS)30、ユーザ装置(UE)40、及びネットワークエンティティ(NE)50と相互関係にあるGAA環境20の概要である。GAA20は、基本的に、汎用ブートストラッピングアーキテクチャ(GBA)22、加入者証明書24、及び認証プロキシ(AP)26からなる。GAA20の例示的な使用は、モバイルデバイス及びアプリケーションサーバにクレデンシャル(例えば共有秘密)を提供することになり、該クレデンシャルは、後でHTTPS(セキュアハイパーテキスト転送プロトコル)に対して使用することができる。GBA22は、共有秘密に基づく種々のアプリケーションに対して汎用認証機能を提供することによって加入者証明書24及びAP26の両方に対する基礎を構築する。GBA機能とは通常、アプリケーションセキュリティに対する認証及び鍵共有をブートストラップすることであり、更にこれは、通常、Niemi等による「Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)(認証及び鍵共有(AKA)を使用したハイパーテキスト転送プロトコル(HTTP)ダイジェスト認証)」(2002年9月)と題するインターネットエンジニアリングタスクフォース(IETF)、ネットワークワーキンググループ、コメントに対するリクエスト:3310に従うHTTPダイジェストAKA(認証及び鍵共有)メカニズムに基づいており、この内容は、引用により全体が本明細書に組み込まれる。
【0029】
図3は、汎用ブートストラッピングのための例示的なネットワークモデルを示す。図に示すように、ブートストラッピングサーバ機能(BSF)60は、双方向リンクを介してユーザ装置(UE)40に接続されている。BSF60及びUE40は、AKAプロトコルを使用して相互に認証し、セッション鍵に合意することができる。これらのセッション鍵は、後で、ユーザ装置とネットワークアプリケーション機能(NAF)サーバ70との間のセッションに使用することができ、該サーバは、双方向リンクによってユーザ装置40及びBSF60に接続されている。1つの例示的な実施形態では、NAFサーバ70は、オペレータのシステム内に含まれる。或いは、NAFサーバ70は単に、セキュリティクレデンシャルサービスを提供するためにオペレータと契約することができる。サードパーティネットワークの場合には、アーキテクチャは、図示されていないが「Generic Authentication Architecture(GAA:汎用認証アーキテクチャ);Generic Bootstrapping Architecture(汎用ブートストラッピングアーキテクチャ)」(2005年6月7日発行)(3GPP TS33.220v7.0.0(2005−06))(以下「TS33.220」)と題された3GPP技術仕様33.220に説明されるようなDiameter(ダイアメータ)−プロキシ(D−プロキシ)を含むことができ、この内容は、引用により全体が本明細書に組み込まれ、www.3gpp.orgで見ることができる。
【0030】
以下に詳細に説明されるブートストラッピング手続の後で、ユーザ装置40及びNAF70は、例えばクレジットカード個人化又は公共交通チケット発券アプリケーションであるアプリケーション固有プロトコルを実行することができ、ここでは、メッセージの認証及び機密保護が相互認証の間に生成されたセッション鍵に基づくことになる。従って、GAA/GBA22は、一般的に、3パーティ認証ケースとして見なすことができ、BSF60は更に、例えばGBAユーザセキュリティ設定(GUSS)を記憶するHSS30又はHLRに接続される。幾つかのHSSが存在する場合には、BSFとHSSとの間の接続はSLF(サーバロケーション機能)を利用でき、これによってBSFは、適切なユーザデータを記憶するHSSを見つけることができる。
【0031】
図3の個々のエンティティ間の基準ポイント(インターフェース)は、Ub、Ua、Zn、及びZhで示されている。1つの実施形態では、インターフェースZn及びZhはダイアメータに基づく(Diameter Base Protocol(ダイアメータベースプロトコル)に従う。これは、Calhoun等による「Diameter Base Protocol(ダイアメータベースプロトコル)」(2003年9月)と題されたIETF、ネットワークワーキンググループ、コメントに対するリクエスト:3588で規定されており、この内容は引用により全体が本明細書に組み込まれる)。或いは、インターフェースZnは、ハイパーテキスト転送プロトコル(HTTP)に基づくことができる。インターフェースUbは、HTTPダイジェストAKAメッセージの再利用又はHTTPダイジェストメッセージの変形に基づき、インターフェースUaによって使用されるプロトコルは、実行されることになるアプリケーションに依存する。訪問側NAFの場合には、付加的なZn基準ポイントが挿入されることになる。
【0032】
汎用ブートストラッピングアーキテクチャの利用は、2つの段階に分けることができる。図4は、第1段階、すなわちそれ自体(汎用)ブートストラッピング手続を示し、図5は、第2段階、すなわち汎用ブートストラッピング利用手続を示す。
【0033】
図4に示されるように、ブートストラッピング手続の第1段階では、ユーザ装置(UE)40がHTTPリクエストをBSF60に送る。ステップ2で、BSF60は、ユーザプロファイル(Prof)及び認証ベクトル(AV)をHSS30からZhインターフェースを通じて検索し、該認証ベクトルは、5つの要素、すなわち乱データ(RAND)、認証トークン(AUTN)、予測される応答(XRES)、保全鍵(IK)、及び機密鍵(CK)を含む。BSF60はまた、GBAユーザセキュリティ設定(GUSS)を検索することができる。次にステップ3で、BSF60は、認証パラメータRAND及びAUTNをUE40に転送し、UE40が自己を認証するよう要求するようにする。UE40は、ステップ4で認証済みネットワークからのチャレンジを検証するためにメッセージ認証コード(MAC)を計算し、セッション鍵CK、IK、及び応答RESを導出する。これらのセッション鍵CK、IK、及び応答RESは、BSF60とUE40の両方が利用可能である。ステップ5で、UE40は、ここではHTTPダイジェストのパスワードとして応答RESを使用してBSF60にリクエストを再送する。BSF60は、ステップ6で、受信パラメータがRESを使用して計算されており、且つHSS30から認証ベクトルの一部として前に取得されていたXRESを使用して同様に計算されたパラメータに等しいかどうかをチェックする。これらのパラメータが等しい場合、UE40は認証され、BSF60は、ステップ7でセッション鍵CK及びIKを連結することによって鍵(「マスターキー」)Ksを生成する。
【0034】
ステップ8で、BSF60は、ブートストラッピングトランザクション識別子B−TID及び他のデータ(例えば、鍵Ksの有効期間など)を含むOKメッセージをUE40に送り、これによって認証の成功が示される。次に、セッション鍵CKとIKを連結することによって、鍵KsがUE40で生成される(ステップ9)。この後すぐに、ユーザ装置(クライアント)40とブートストラッピングサーバ機能(BSF)60との間のブートストラッピングセッションが正常に開始される。
【0035】
図5は、ブートストラップされたセキュリティアソシエーションを用いた例示的な手続(すなわち第2段階)を示す。ブートストラッピングセッションを開始した後、UE40は、NAF70との通信を開始することができる。これによって、UE40及びBSF60においてブートストラッピング手続中に生成されたマスターキーKsを用いて、Ks_NAF、又はKs_ext_NAF及びKs_int_NAFで示される1つ又は2つのNAF固有鍵(以下に説明されるように、UEがGBA対応のUICCを備えているかどうかで異なる)を導出する。ステップ1で、UE40は、アプリケーションリクエストをUaインターフェースを介してNAF70に送信する。アプリケーションリクエストは、ブートストラッピング中に取得されたトランザクション識別子B−TID、msgで示されるアプリケーション固有データセット、及びMACで示される全てのクレデンシャルを含む。
【0036】
ステップ2で、NAF70は、1つ又はそれ以上の鍵と、場合によってはUE40により提供された情報に対応するユーザプロファイルデータをZnインターフェースを介してBSF60にリクエストする。このようなリクエストは、例えば、トランザクション識別子に基づくことができる。ステップ2と3の間で、NAF固有鍵Ks_NAF、又はKs_ext_NAF及びKs_int_NAFがBSFエンティティ60で生成される。ステップ3で、BSF60は、要求された1つ又は複数の鍵(NAF固有鍵、ブートストラッピング時間、鍵の有効期間、及びProfで示されるユーザプロファイルのアプリケーション固有部分を含む)をNAF70に提供することによって応答し、これをNAF70が直接使用するか、或いはこれを用いてNAF70が、UE40に向けたUaインターフェースを介して使用されるプロトコルを保護するのに必要な別の鍵を導出することができ、これはアプリケーション固有の機能であり、GAA仕様では対処されない。このような導出は、UE40が事前に行ったのと同じ方法で行われる。次に、NAFエンティティ70は、少なくとも、NAF固有鍵、ブートストラッピング時間、Prof、及び鍵の有効期間といったパラメータを記憶する。ステップ4で、NAF70は、アプリケーション応答をUE40に送ることによってUaインターフェースを介して用いられたプロトコルを継続する。
【0037】
汎用ブートストラッピングアーキテクチャ(GBA)に関する更なる詳細については、上記に引用されたTS33.220を参照されたい。
【0038】
セキュア方式でのOTA個人化送信
本発明の例示的な実施形態は、セキュアチャンネルを介したユーザ装置(UE)への個人化データの無線(OTA)送信を可能にする手段を提供する。上述のように、セキュアチャンネルは、公的に容易に識別され又は修正されることなく情報を転送することができる何らかのチャンネルであり、ユーザ装置は、製造中にモバイルデバイスに埋め込まれたEMV証明済みチップ、或いはモバイルデバイスに関連するUICC又はスマートカードに記憶された1つ又はそれ以上のEMVアプリケーションのいずれかに基づくEMV機能を有するモバイルデバイスを指す。特に、例示的な実施形態は、個人化アプリケーションサーバからUEにクレジットカード個人データ化又は公共交通チケット発券データなどの個人化データを送信するためのセキュアチャンネルを作成するのに用いることができる発行者セキュリティドメインを設定する段階を含む。発行者セキュリティドメインは、例えば、以下に説明されるEMVアプリケーションなどのモバイルデバイスによって実行される1つ又はそれ以上のアプリケーションプログラムを含む種々の手段によって設定できる。この結果、ユーザは、クレジットカード又は公共交通カードを使用する場合と同じように自分のモバイルデバイスを使用することができる。例示的な実施形態は更に、UEと個人化アプリケーションサーバとの間で共有される1つ又はそれ以上の秘密鍵の生成を含み、生成された共有秘密鍵は、セキュアチャンネルを設定するのに使用される。この鍵は、例えば、以下に説明されるブートストラッピングサーバ機能(BSF)サーバと共にGBA又はGBA_UなどのUEによって実行される1つ又はそれ以上のアプリケーションプログラムを含む種々の手段によって生成することができる。
【0039】
当業者には理解されるように、セキュアチャンネルの設定に必要な共有秘密鍵は、本発明の例示的な実施形態による種々の方法で生成することができる。単に例証の目的で、本発明の実施形態は、UEとネットワークアプリケーション機能(NAF)サーバとして動作する個人化アプリケーションサーバ又はビューローとの間で共有できる共有秘密鍵を生成するために汎用認証アーキテクチャ(GAA)を使用するものとして説明される。しかしながら、例示的な実施形態におけるGAAの使用は、どのような点でも本発明をこのGAAの使用に限定するものとみなすべきではない。
【0040】
本発明の1つの例示的な実施形態では、セキュアチャンネルを介して個人化データをモバイルデバイスにOTA送信できるようにするために、製造中のモバイルデバイスにブランクチップがインストールされる。共有秘密鍵のインストレーションプロセスは、エンドユーザがモバイルデバイスを所有した後に行うことができ(すなわち、発行者セキュリティドメインを作成することができる)、共有秘密鍵が生成され(例えば上述のGAA手続に従って)、次いでブランクチップに記憶される。1つの例示的な実施形態では、このブランクチップへの通信インターフェースを保護することができる。次に、UE(すなわち、モバイルデバイス+EMV証明済みチップ)がこれらの鍵を使用して、クレジットカード用の個人化アプリケーションサーバ(例えばNAFサーバ)又は類似の個人化手続へのセキュアリンクを設定することができる。
【0041】
他の例示的な実施形態では、1つ又はそれ以上のEMVアプリケーションを含むUICC又はスマートカードは、モバイルデバイスに関連付けられる。上述のように、1つの例示的な実施形態では、製造中にモバイルデバイスに組み込まれたネットワークオペレータUICC又はスマートカード上にEMVアプリケーションを記憶することができる。或いは、モバイルデバイスは、取り外し可能であり且つ2つのスロットを有するあらゆるモバイルデバイスと共に利用可能なEMV固有UICC又はスマートカードに第2スロットを設けることができる。
【0042】
従って、例示的な実施形態のシステムは、ハードウェア要素、ソフトウェア要素、又はこれらの何らかの組み合わせなど、共有秘密鍵を生成して該鍵を記憶し、鍵を使用して発行者セキュリティドメインを設定するための手段を含み、該手段は、例えばモバイルデバイス、BSFサーバ又は個人化アプリケーション(例えばNAF)サーバに埋め込まれ、以下で詳細に説明される。このような説明がなされていない他のこうした手段はまた、本発明の例示的な実施形態の精神から逸脱することなく、これらの機能を実行するのに使用することができる。
【0043】
図6は、本発明の例示的な実施形態に従って動作することができるUEのブロック図である。UEは、以下に説明されるようなEMV機能を有する、例えば携帯電話、パーソナルデジタルアシスタント(PDA)、ページャー、パーソナルコンピュータ(PC)、ラップトップ、タブレット、又は他のいずれかの類似のデバイスなどのモバイルデバイスを含むことができる。図示のように、UEは、少なくともセキュアコア610、UICC(汎用ICカード)620、EMVアプリケーション632、及びGBAアプリケーション634からなることができる。セキュアコア610は、モバイルデバイスの中心又は最も内側の部分である必要はなく、本明細書で説明されるように機能することができるいずれかの1つ又は複数の要素を単に表わすものであって、製造中にインストールされ、生成された共有秘密鍵612を記憶することができるブランクチップ、並びに決済又はチケット発券のためにUEの使用を可能にするためにユーザによって或いはユーザに代わってインストールされた1つ又はそれ以上の決済又はチケット発券アプリケーション614からなることができる。
【0044】
UICC620は、これが配置されるモバイルデバイスのユーザに固有の識別情報626を記憶するユーザ識別モジュールを含むことができる。ユーザ識別モジュールは、実際にはモジュラーである必要はない。言い換えると、ユーザ識別モジュール内に記憶されている識別情報は、1つのモジュラーエンティティの一部として記憶する必要はなく、代わりに、モバイルデバイス全体に分散されてもよい。この識別情報626は、GAA手続(又は共有秘密鍵インストレーションプロセス)中に使用して、BSFサーバに対してUEを識別することができる。1つの実施形態では、UICC620は更にEMV_U622及びGBA_U624アプリケーションを含み、これらはまた、UICC620とNAFサーバとの間にセキュアリンクを設定するために共有秘密鍵インストレーションプロセスにおいて使用される。詳細には、GBA_Uアプリケーション624を用いてNAF固有鍵を生成することができ、該固有鍵を用いて、モバイルネットワークオペレータとUICC620との間で共有される秘密鍵(すなわちCK及びIK)に基づいて、UEをNAFサーバに対して認証するか、或いは2つの間の通信をセキュアにすることができる。1つの実施形態では、UEは、UICC620においてGBA_Uアプリケーション624を含まない場合がある。この場合、鍵生成及び記憶機能は、UEのGBAアプリケーション634によって行われ、UICCは必要な情報を配信するだけである。1つの実施形態では、EMV_Uアプリケーションは、共有秘密鍵インストレーションプロセスの進行をモニターするのに使用される状態機械を含む。この実施形態では、インストレーションプロセスが中断された場合、状態機械は、インストレーションを再開する必要があることを指示する。UEがGBA_Uアプリケーションを含まない場合、EMV_Uアプリケーションはまた、モバイル端末に常駐し、UICCには常駐しない。
【0045】
UEに含まれるEMVアプリケーション632は、UEの外部にあるエンティティ(例えばNAF及びBSFサーバ)と、UICC620及びセキュアコア610との間の通信を可能にすることによって通信エンティティとして動作する。例えば、共有秘密鍵インストレーションプロセスにおいて、EMVアプリケーション632は、以下に詳細に説明されるように、NAFサーバに発行者セキュリティドメイン鍵を要求し、これらを解読するためにUICC620に渡し、更にこれらの鍵をセキュアコア610上に記憶する役割を果たす。上述のように、UICC620内にGBA_Uアプリケーション624が存在しない1つの実施形態では、UEにあるGBAアプリケーション634が、以下に説明される鍵生成及び記憶機能を実行する。
【0046】
図7Aは、クレジットカード用にUEを準備する場合、或いは類似の個人化、すなわちセキュリティ及びユーザデータをUEに送信することができるセキュア通信チャンネルを設定するのに用いることができる発行者セキュリティドメインを作成する場合の例示的な実施形態において実行されるステップを示す信号フロー図である。第1のステップで、EMVアプリケーション(モバイル/ユーザデバイス(UE)に常駐している)は、NAFサーバ(すなわち、オペレータによってホストされるか或いはオペレータとビジネス関係にある個人化ビューロー)に付加的なセキュリティデータをリクエストする。付加的なセキュリティデータは、実際の個人化プロセスに後で使用され、例えば暗号化鍵及び/又はMAC(メッセージ認証コード)鍵とすることができる発行者セキュリティドメイン鍵を表わす。ステップ2で、NAFサーバは、認証チャレンジをEMVアプリケーションに返し、EMVアプリケーションがGAA共有秘密方法を使用して自らを認証するようリクエストする。次にステップ3で、UEのEMVアプリケーションは、UEに同様に位置付けられたGBAアプリケーションにGAA共有秘密をリクエストする。
【0047】
ステップ4で、共有秘密は、上記に詳細に説明されたブートストラッピング手続を使用して設定される。UEのGBAアプリケーション、UICCのGBA_Uアプリケーション、及びブートストラッピングサーバ機能(BSF)サーバは各々、このプロセスに含まれる。この手続の最後で鍵が生成される(GBA_UがUICCによってサポートされる場合、Ks_ext_NAF及びKs_int_NAF、そうでない場合はKs_NAF)。Ks_int_NAF及び/又はKs_ext_NAFは、GBA_Uアプリケーション及びBSFの両方に既知である。GBA_Uが使用されない場合、BSFはKs_NAFを認知しており、NAFはこれらの鍵をBSFにリクエストすることができる。UEは、Ks_ext_NAFとKs_NAFのみを認知している。共有秘密が設定されると、GBAアプリケーションは、ステップ5で、Ks_ext_NAFをUEのEMVアプリケーションに与える(或いは、GBA手続がUEのみに依存する場合には、UEは既にKs_NAFを有している)。ステップ6で、EMVアプリケーションは、Ks_ext_NAF又はKs_NAFを使用してNAFサーバの認証チャレンジへの応答をNAFサーバに返す。
【0048】
ステップ7で、NAFサーバは、BSFサーバからNAF固有鍵(すなわちKs_ext_NAF及びKs_int_NAF、又はKs_NAF)をフェッチする。次いでステップ8で、NAFサーバは認証応答を検証し、例えばKs_int_NAF又はKs_NAFを使用して付加的なセキュリティデータを暗号化し、暗号化されたデータをUEのEMVアプリケーションに転送する。しかしながら、EMVアプリケーションは、Ks_int_NAFで暗号化された受信データを解読することができない。一方では、データがKs_NAFで暗号化された場合には、UEはこれを解読することができ、ステップ11でセキュリティデータのインストレーションに進むことになる点に留意されたい。UEが受信されたデータを解読できないと仮定すると、ステップ9で、EMVアプリケーションは、暗号化された付加的なセキュリティデータ(すなわち発行者セキュリティドメイン鍵)をUICC上のEMV_Uアプリケーションに渡す。UEでのセキュリティオペレーションは、セキュアな環境又は信頼できるプラットフォームにおいて実行することができる。
【0049】
ステップ10で、EMV_Uアプリケーションは、メッセージを解読するために必要なKs_int_NAF鍵をEMV_Uが持たないので、暗号化された付加的なセキュリティデータ(すなわち発行者セキュリティドメイン鍵)をGBA_Uに与える。GBA_Uアプリケーションは、ステップ11でデータを解読し、これをEMV_Uアプリケーションに返す。或いは、ステップ10及び11で、EMV_Uアプリケーションは、GBA_UアプリケーションにKs_int_NAF鍵をリクエストすることができる。Ks_int_NAF鍵を受け取ると、EMV_Uアプリケーションは自らデータを解読することができる。これによって、UICC上でのEMV_Uアプリケーションが付加的なセキュリティデータのインストレーション及び発行者セキュリティドメインの作成を行うことが可能となる。付加的なセキュリティデータ、例えば鍵、鍵の有効期間、鍵生成時間、及び/又はB−TIDは、セキュアコア上に発行者セキュリティドメインを作成するのに使用される。次いで、この発行者セキュリティドメインを用いて、決済アプリケーションデータ、クレジットカード個人化データ、又は同様のものなどのアプリケーション固有のセキュリティドメインを記憶することができる。
【0050】
インストレーションプロセスが図7Bに示されており、EMV_UがUE内のEMVアプリケーションに解読された付加的なセキュリティデータを渡すステップ11aから始まる。次いで、EMVアプリケーションは、ステップ11bで、付加的なセキュリティデータを使用してセキュアコア上に発行者セキュリティドメインを作成することができる。ステップ11cで、発行者セキュリティドメインの成功した作成の確認が、セキュアコアからUE内のEMVアプリケーションに送られる。最後に、任意選択であるステップ11dで、EMVアプリケーションがEMV_Uに発行者セキュリティドメインの成功した作成を確認する。
【0051】
図7A及び7Bに示されるステップ12で、EMV_Uアプリケーションは、任意選択的であるが、成功(又は失敗)メッセージをUE上のEMVアプリケーションに返す。次いで、EMVアプリケーションは、ステップ13(図7Bには示されていない)でこの成功(又は失敗)メッセージをNAFサーバに返す。1つの実施形態では、EMV及びEMV_Uアプリケーションの両方によって返された成功メッセージは、送信側の真正性を与えるためにNAF固有鍵を使用して暗号化される。最後に、同様に任意選択であるステップ14(図7Bには示されていない)で、NAFサーバは成功メッセージに対する肯定応答を返す。
【0052】
幾つかの実施形態では、セキュアチャンネルプロトコル2(http://www.globalPlatform.org/specificationview.asp?id=cardで入手可能な、グローバルプラットフォームカード仕様バージョン2.1.1を参照、本内容は、引用により全体が本明細書に組み込まれる)、TLS、事前共用鍵(PSK)TLS、IPSec又はHTTPダイジェストなどの付加的なセキュリティプロトコルは、上述されたプロセスの幾つかのステップにおいてGAAと共に使用することができる。セキュリティドメイン鍵は、個人化データのダウンロードをセキュアにするためのセキュアチャンネルプロトコル2によって使用することができる。NAF固有鍵はまた、例えばPSK TLSを使用して通信チャンネルをセキュアにするのに使用することができる。
【0053】
上記のステップの終わりで、クレジットカード個人化データ又は公共交通チケット発券データなどの個人化データをセキュアチャンネルがUEにOTAで送信することができるように共用鍵が設定され、これによってUEは、例えばユーザのクレジットカード又はプリペイド公共交通カードとして機能を果たすことができるようになる。
【0054】
例示的な使用のケース
図8−11は、本発明の例示的な実施形態によるクレジットカード個人化のためのモバイルデバイスを準備するための4つの段階を示すフローチャートである。これらの段階のステップは、本質的には例示的なものに過ぎず、各状況において当てはまる場合もあればそうでない場合もある幾つかの仮定に基づいている。例えば、以下の例証では、モバイルデバイスユーザは、該ユーザが例えば自分のパーソナルコンピュータ(PC)を使用しているいずれかの場所からアクセスできるパーソナルインターネットバンキングアカウントを有していると仮定する。このインターネットバンキングアカウントを介して、ユーザは自分のモバイルデバイスにクレジットカード機能を使用することができるようにリクエストする。しかしながら、インターネットバンキングアカウントなどを持たないモバイルデバイスユーザでも、本発明の使用を禁じられてはいない。これらのユーザは、例えばメール又はファクシミリを介して利用可能性をリクエストすることができる。
【0055】
図8に示される段階1では、ユーザは、例えばクレジットカード又は公共交通チケット発券カードとして自分のモバイルデバイスを利用可能にすることを決定し、すなわち、ユーザは、製造中の自分のモバイルデバイスにインストールされたセキュアコア/チップを利用可能にするプロセスを開始する。ステップ801で、ユーザは、自分のPCを使用して自分のインターネットバンキングアカウントにアクセスし、自分のモバイルデバイスを利用可能にすることを選択する。ステップ802で、ユーザは、自分の電話番号を入力するよう促されて入力する。図12及び13は、クレジットカード機能に対して自分のモバイルデバイスを利用可能にするよう選択した場合にユーザが見ることのできる例示的なウェブページを示す。ステップ803で、ユーザが口座を持っている金融機関、すなわち銀行このリクエストを受け取り、モバイルデバイスを利用可能にすることに同意する。最後にステップ804で、金融機関は、個人化アプリケーションサーバ又はビューロー(例えば、GAAが使用される場合にNAFサーバとして働く)と連絡を取り、必要なユーザデータを個人化アプリケーションサーバに送信する。このユーザデータは、例えば、ユーザの名前、個人化コード、又はPIN、電話番号などを含むことができる。
【0056】
図9に示される段階2では、発行者セキュリティドメイン鍵がユーザのモバイルデバイスにインストールされたセキュアコード/チップに無線(OTA)で提供される。1つの実施形態では、セキュアチップは、シリアルナンバーのみによって製造中に初期化される。或いは、発行者セキュリティドメインクレデンシャルが発行時にセキュアコア/チップ上に既に配置させることができる。この実施形態では、段階2は完全に無排除され、図では以下に説明される段階3に直接進む。しかしながら、セキュアチップがシリアルナンバーだけを有すると仮定すると、段階2は、ステップ901で始まり、ここでは、金融サーバがNAFサーバに対して、モバイルデバイスがGAA及び共有秘密法を使用する旨のリクエストを通知する。このステップは、例えばWAPプッシュ、OMAデバイス管理手段、SMS、又はHTTPメッセージを電話へのローカル接続を有するPCに送ることによって、或いはユーザがその番号に電話をかけるか又は専用ウェブサイトを閲覧するようリクエストすることによって行われる。
【0057】
ステップ902で、共有秘密は、上述の方法でモバイルデバイスのUICCとBSFサーバとの間に設定される。次にステップ903で、NAFサーバは、BSFサーバからの共有秘密をリクエストする。ステップ904で、UICCは、後でUEを介してセキュアコアに与えられる新しい秘密鍵を取得する。1つの実施形態では、BSFサーバはまたこの秘密鍵を導出する。次にステップ905で、ユーザのモバイルデバイス上のセキュアコア/チップは、共有秘密鍵を記憶する。セキュアコアはここで、セキュリティ発行者ドメイン鍵として使用することができる秘密鍵を有する。
【0058】
図10に示される段階3では、セキュリティドメインは、非接触型決済又はチケット発券アプリケーション用のユーザのモバイルデバイスのセキュアコアに提供される。ステップ1001で、例えば図7A及び7Bに示されるように生成され記憶されたセキュリティ発行者ドメイン鍵を使用して、セキュアコアとNAFサーバとの間にセキュアトンネルが設定される。モバイルデバイスは、例えばHTTP又はGPRS(汎用パケット無線サービス)を使用してこのトンネルの設定をサポートする。このトンネルは、ステップ1002でセキュリティドメインデータをセキュアコアにダウンロードするのに使用される。最後にステップ1003で、セキュアコアは、非接触型決済又はチケット発券アプリケーション用のセキュリティドメインを設定する。
【0059】
図11に示される最後の段階である段階4は、決済アプリケーション(例えばモバイルクレジットカード個人化)のダウンロードを表わす。ステップ1101で、ユーザは、自分のPCでアクセスしたウェブサイト上で個人化コードを受け取る。次いでステップ1102で、NAFサーバ又は個人化ビューローは、例えばWAPプッシュを使用してURLをユーザにプッシュし、ユーザに自分のモバイルデバイスを使用して当該URLを閲覧するように指示する。ステップ1103で、ユーザは受け取ったURLを閲覧し、受け取った個人化コードを自分のモバイルデバイスに挿入して、妥当性確認のためにこれをNAFサーバに送るように促される。ステップ1104で、NAFサーバは、段階2で設定されたセキュリティドメイン鍵によって暗号化された個人化コードをセキュアコアにプッシュする。ステップ1105で、モバイルデバイスは、セキュアコアを個人化し(すなわち、アプリケーション固有のセキュリティドメインを作成し、公共交通チケット又はクレジットカード番号などの個人ユーザデータを当該ドメインに入れる)、金融機関及び/又はNAFサーバにセキュアコアの正しい初期化を確認する。最後に、ステップ1106及び1107それぞれにおいて、端末決済アプリケーション及びセキュアコア決済アプリケーションがダウンロードされインストールされる。図14は、上記のステップを実行した場合にユーザが自分のモバイルデバイス上で見ることのできる例示的な画面を示す。これ以降、ユーザは、自分のモバイルデバイスを利用してRFID通信などを介してカードリーダーと対話することができ、クレジット又はデビットカードと同様の方法で商品又はサービスを購入し、或いは公共交通チケットの決済を行うことができる。
【0060】
結論
上述され並びに当業者によって理解されるように、本発明の実施形態は、システム、方法、モバイルデバイス又は他の装置、或いはコンピュータプログラム製品として構成することができる。従って、本発明の実施形態は、完全にハードウェアだけ、完全にソフトウェアだけ、或いはソフトウェア及びハードウェアのあらゆる組合せを含む種々の手段から構成することができる。更に、本発明の実施形態は、記憶媒体に組み込まれたコンピュータ可読プログラム命令(例えばコンピュータソフトウェア)を有するコンピュータ可読記憶媒体上のコンピュータプログラム製品の形式を取ることができる。ハードディスク、CD−ROM、光記憶デバイス、又は磁気記憶デバイスを含むあらゆる適切なコンピュータ可読記憶媒体を利用することができる。
【0061】
本発明の例示的な実施形態について、方法、装置(すなわちシステム)、及びコンピュータプログラム製品のブロック図及びフローチャートを参照しながら上記で説明してきた。ブロック図の各ブロック及びフローチャート図、並びにブロック図のブロックとフローチャート図との組み合わせはそれぞれ、コンピュータプログラム命令を含む種々の手段によって実施することができる。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置にロードして、コンピュータ又は他のプログラム可能データ処理装置上で実行される命令が、1つ又は複数のフローチャートブロックにおいて指定された機能を実施するための手段を生成するような機械をもたらす。
【0062】
これらのコンピュータプログラム命令はまた、コンピュータ又は他のプログラム可能データ処理装置に特定の方法で機能するよう指示できるコンピュータ可読メモリ内に記憶することができ、これによってコンピュータ可読メモリ内に記憶された命令は、1つ又は複数のフローチャートブロックにおいて指定される機能を実施するためのコンピュータ可読命令を含む製造物品を生成する。コンピュータプログラム命令はまた、コンピュータ又は他のプログラム可能データ処理装置にロードし、コンピュータ又は他のプログラム可能装置上で一連の動作ステップを行わせ、コンピュータ又は他のプログラム可能装置上で実行される命令が1つ又は複数のフローチャートブロックで指定される機能を実施するためのステップを提供するようにコンピュータ実装プロセスを生成することができる。
【0063】
従って、ブロック図のブロック及びフローチャート図は、指定された機能を実行する手段の組み合わせ、指定された機能を実行するステップの組み合わせ、及び指定された機能を実行するプログラム命令手段の組み合わせをサポートする。ブロック図の各ブロック及びフローチャート図、並びにブロック図のブロックとフローチャート図の組み合わせが、指定された機能又はステップ、或いは専用ハードウェア及びコンピュータ命令の組み合わせを行う専用ハードウェアベースのコンピュータシステムによって実現できる。
【0064】
本明細書に記載される本発明の多くの修正形態及び他の実施形態は、これらの発明が上記の説明及び関連の図面で提示された教示の利益を有することが本発明の関連する当業者には想起されるであろう。従って、本発明は、開示された特定の実施形態に限定されるものではなく、当該修正及び他の実施形態は、添付の請求項の範囲に含まれるものとすることを理解されたい。特定の用語を本明細書で用いているが、これらは一般的且つ説明的な意味でのみ使用されており、限定を目的とするものではない。
【図面の簡単な説明】
【0065】
【図1】クレジットカードの個人化を行う従来技術のステップを示すフローチャートである。
【図2】従来技術による汎用認証アーキテクチャ環境の概要を示す図である。
【図3】従来技術による汎用ブートストラッピングのためのネットワークモデルを示す図である。
【図4】従来技術による汎用ブートストラッピング手続を示す図である。
【図5】従来技術による汎用ブートストラッピング使用手続を示す図である。
【図6】本発明の例示的な実施形態による動作可能なユーザ装置を示すブロック図である。
【図7A】本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備する場合に行われるステップを示す信号フロー図である。
【図7B】本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備する場合に行われるステップを示す信号フロー図である。
【図8】本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備するための4つの段階を示すフローチャートである。
【図9】本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備するための4つの段階を示すフローチャートである。
【図10】本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備するための4つの段階を示すフローチャートである。
【図11】本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備するための4つの段階を示すフローチャートである。
【図12】本発明の例示的な実施形態によるクレジットカード機能に自分のユーザ装置を利用可能にするように選択する場合にユーザが見ることのできる例示的なウェブページを示す図である。
【図13】本発明の例示的な実施形態によるクレジットカード機能に自分のユーザ装置を利用可能にするように選択する場合にユーザが見ることのできる例示的なウェブページを示す図である。
【図14】本発明の例示的な実施形態によるクレジットカード機能を利用可能にする場合にユーザが自分のユーザ装置で見ることのできる例示的な画面を示す図である。
【符号の説明】
【0066】
610 セキュアコア
612 共有秘密鍵
614 1つ又はそれ以上の決済又はチケット発券アプリケーション
620 UICC
622 EMV_Uアプリケーション
624 GBA_Uアプリケーション
626 ユーザに固有の識別情報
632 EMVアプリケーション
634 GBAアプリケーション
【技術分野】
【0001】
本発明は、モバイル端末をクレジットカード個人化に対して利用可能にすることに関し、更に詳細には、無線ネットワークを使用してモバイル端末をクレジットカード個人化に利用可能にすることに関する。
【背景技術】
【0002】
MasterCard及びVisaなどのクレジットカード会社は、現在のところクレジットカード個人化を行うためにEMV(Europay、Mastercard、及びVisa)クレジットカード決済規格を利用することに成功している。クレジットカード個人化とは、EMVチップを含むスマートカードなどのユーザのクレジットカードにセキュリティ及びユーザデータが送信されるプロセスのことを指す。この個人化プロセスの最初のステップは、発行者セキュリティドメインを設定する段階であり、現在では通常スマートカード製造業者の工場で行われる。セキュリティドメインは、アプリケーションデータのダウンロード及び実際の個人化を行うのに使用される個人化デバイスと、クレジットカードに埋め込まれたEMVチップとの間でセキュアチャンネルを作成するのに使用される。セキュアチャンネルは、公的に容易に入手可能ではない状態で情報を送信することができるあらゆるチャンネルであり、例えば、種々の暗号化方式を使用して或いはチャンネルのエンドポイント両方を認証することによって作成することができる。セキュアチャンネルが作成されると、個人化デバイスはEMVチップを起動し、最終的には個人化データをEMVチップに送信することができる。クレジットカード会社は、この個人化プロセスを行うためにOrga、Axalto、Giesecke及びDevrient、又はCedexなどのスマートカード製造業者に頼ることが多い。これらの製造業者は、ユーザ固有のデータを各クレジットカードに埋め込むために、必要とされるユーザ個人化データをクレジットカード会社から受け取り、以下に説明されるステップを行う。このように、スマートカード製造業者は、クレジットカード会社に代わってクレジットカード発行者として役割を果たすことができる。
【0003】
図1は、今日クレジットカード個人化を行う場合に、例えばスマートカード製造業者が行うことができるステップを示すフローチャートである。ステップ101で、個人化デバイスは、EMVチップにリセットコマンドを送ることによってEMVチップを起動する。ステップ102で、EMVチップは、リセット応答(ATR)を個人化デバイスに送ることによって応答する。次いでステップ103で、個人化する必要のあるアプリケーション、例えばカードに予めロードされていた特定のクレジットカードアプリケーションが選択コマンドを使用して選択される。ステップ104で、EMVチップは、ファイルデータ構造情報などの必要なファイル制御情報を返し、ステップ105で、初期化更新コマンドがEMVチップに個人化デバイス乱数を提供する。この乱数は、セキュアチャンネルを設定するために暗号文作成の一部として使用される。
【0004】
ステップ106で、チップは、シーケンスカウンタ(セッションキー導出用)、チャレンジ(暗号文作成の一部として使用される)、カード暗号文(チップを認証するのに使用される)、セッションDES(データ暗号化標準)マスターキーの識別子及びバージョン、暗号化用導出データ、解読及びメッセージ認証コード(MAC)DES(データ暗号化標準)キー、及びソースチャンネルプロトコル識別子を送ることによって応答する。
【0005】
ステップ107で、個人化デバイスは、外部認証コマンドで暗号文を提供することによって自らをEMVチップに対して認証する。次にステップ108で、EMVチップは外部認証を確認し、次いで、ステップ109で、個人化デバイスが、幾つかの格納データコマンドの1つ及び最終的には特別な最後の格納データを送出することによってデータのEMVチップへの転送を開始する。最後にステップ110で、データ記憶が確認される。
【0006】
最近では、MasterCard及びVisaなどの会社が、例えばPayPass又はVisa Waverとして知られる新しい決済方法を導入しており、RFID(無線識別)機能を有するクレジットカードが製造されている。この新しい方法では、RFIDデバイスが小売店に備え付けられ、該RFIDデバイスは、ユーザが読取装置の数センチメートル手前に自分のカードを置くと、これらのRFID対応クレジットカードを読み取ることができる。この新しい方法によってクレジットカードの決済がより早くより簡単になる。類似の近接RFIDシステムは、Octopus(オクトパス)又はヘルシンキ公共交通などの公共交通システムでも使用されている。例えば、RFID機能を含むプリペイドのバス又は列車のカードが顧客によって購入され、バス停又は列車の駅にあるRFID読取装置と共に使用して、バス又は列車に乗るためのチケットを購入することができる。
【0007】
種々のベンダーロケーション、並びに種々の公共交通ステーションでのRFID読取装置の使用は、これらの販売時点情報管理(POS)RFID読取装置を利用できる他のタイプの決済方法の機会を与える。このような1つの決済方法によって、個人が自分の携帯電話或いは携帯電話又はPDAに接続(例えば、ブルートゥース、ケーブル、RFID、又は赤外線を介して)されているパーソナルデジタルアシスタント(PDA)又はモバイルパーソナルコンピュータ(PC)などのある他のモバイルデバイスを使用して、クレジットカード又は他のユーザ固有の情報を転送することが可能になる。言い換えると、個人が、自分のクレジットカード又はプリペイド公共交通カードを使用する場合と同じ状況で自分の携帯電話を使用することができるようになる。例えば、ユーザの個人クレジットカードの詳細をモバイルデバイスに組み込み、POS RFID読取装置に送信することができるようになる。例えば、PayPass及びVisaWaveに使用されるのと同じプロトコルを使用することができる。この場合、モバイルデバイスは、PCに接続されることになり、PCは、モバイルデバイスに必要なデータを要求し、次いで、このデータをPOSに(インターネットを介して)転送することになる。
【0008】
このモバイルEMVシステムを実施するために、最初にシステム全体を証明する必要がある。EMV証明は、EMV発行者として役割を果たすことを意図する全てのスマートカード発行者が従う必要のある、EMVによって定められた高価な手続である。証明なしでは、クレジットカード会社は、内包する固有リスクを受け入れてモバイルEMVソリューションを会社の決済インフラストラクチャに「接続する」可能性は低い。しかしながら、モバイルデバイスは、付加的なソフトウェアアプリケーションを実行しスマートカードよりも多くの外部インターフェースを有することができるので、スマートカードよりも遙かにオープンである。この結果、既存のモバイルデバイスハードウェア上で構築されたモバイルEMVソフトウェアアプリケーションは、EMV証明を取得しようとする場合に重大な問題に直面する可能性があり、従って、必要な証明の取得が非常に困難で費用のかかるものになる。
【0009】
1つの代替の解決策は、既存のモバイルデバイスハードウェア上にモバイルEMVソフトウェアアプリケーションを構築するのではなく、既に証明済みのEMVチップ又はスマートカードをモバイルデバイスに組み込むことである。これを行うための1つの選択肢は、第2のスロットをモバイルデバイスに取り入れることであり、この場合、EMVチップは、例えばスマートカード製造業者で通常通り個人化し、次いで、後でユーザによってモバイルデバイスに挿入することができる。しかしながら、この方法も大量市場に対するモバイルデバイスのハードウェアコストが追加されることに起因して、極めて高価になる可能性がある。他の選択肢は、多くのアプリケーションをサポートする汎用ICカード(UICC)をモバイルデバイスに組み込むか、或いは、証明済みのEMVチップをモバイルデバイスの製造中にデバイスに埋め込むかのいずれかになる。
【0010】
しかしながら、製造中には、最終的に誰が各モバイルデバイスを所有するかが分からず、従って、通常の製造プロセス中にあらゆる決済データが完全に個人化されるのが阻止される。これは、カードの受取人がカードの発行中に既知である今日のクレジットカードビジネスとは相違する。1つの解決策は、クレジットカードに関して上述されたのと類似の方法で、製造中にモバイルデバイスにUICCを組み込むか或いは証明済みEMVチップを埋め込み、次いで、ユーザがスマートカード製造業者又は個人化ビューローに自分のモバイルデバイスを送ることを必要とし、そこで個人化を行うことができるようにすることである。しかしながら、これには、ユーザがある時間期間の間自分のモバイルデバイスをスマートカード製造業者に明け渡すことが必要になる。別の解決策では、ユーザがクレジットカードを申し込むのと同じ方法でクレジットカード機能を有する電話を申し込むことが必要である。次いで、クレジットカード機能を有する完全に個人化されたモバイルデバイスは、直接ユーザに送られることになる。しかしながら、これらの選択肢では、既存の製造プロセス及び販売網を変更することが必要になり、これらは、高コストで時間がかかることになる。
【0011】
別の解決策は、ユーザが自分のモバイルデバイスを購入した後で、無線(OTA)で個人化を行うことである。しかしながら、セキュリティデータのOTA送信には一定のリスクが内在する。上述のように、個人化プロセスを開始する前に、個人化デバイスとEMVチップ又はUICCとの間のセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成する必要がある。従って、モバイルデバイスにOTAでクレジットカード個人化データを送信する安全な手段、すなわち必要な発行者セキュリティドメイン及びセキュアチャンネルを作成する手段に対するニーズがある。
【発明の開示】
【0012】
一般的に言えば、本発明の例示的な実施形態は、クレジットカード個人化又は公共交通チケット発券データなどの個人化データを無線(OTA)で送信することができるセキュアチャンネルの設定のための発行者セキュリティドメインを作成する方法を提供することによって、公知の従来技術に対して改善をもたらす。詳細には、例示的な実施形態では、汎用認証アーキテクチャ(GAA)を使用して、ユーザ装置(UE)とネットワークアプリケーション機能(NAF)サーバとして働く個人化アプリケーションサーバ又はビューローとの間のセキュア通信チャンネルを作成するのに使用することができる共有秘密を設定することができる。
【0013】
一般に、本明細書で使用されるユーザ装置とは、ユーザ装置のユーザによってリクエストされた商品又はサービスに課金する機能を組み込んだモバイルデバイス(例えば、セルラー電話、パーソナルデジタルアシスタント(PDA)、ラップトップ、ページャーなど)を指す。例えばユーザ装置は、モバイルデバイスに埋め込まれたEMV証明済みチップ、或いはモバイルデバイスに関連したUICC又はスマートカードに記憶された1つ又はそれ以上のEMVアプリケーションのいずれかを介してEMV機能を有するモバイルデバイスを意味することができる。1つの例示的な実施形態では、EMVアプリケーションは、ネットワークオペレータのUICC又はスマートカード上に記憶することができる。或いは、1つ又はそれ以上のEMVアプリケーションを含む別個のEMV固有UICC又はスマートカードを提供することができる。この実施形態では、モバイルデバイスは、それぞれのUICC(すなわち、ネットワークオペレータUICCとEMV固有のUICC)に対して2つのスロットを含み、EMV固有のUICC又はスマートカードは、取り除くことができ、2つのスロットを所有する別のモバイルデバイスと共に使用することができる。このようにしてユーザは、EMV固有のUICC又はスマートカードをモバイルデバイスに挿入することによって異なるモバイルデバイス(例えばユーザ自身の、並びにユーザの母親、父親、姉妹などの)をクレジットカード又は公共交通チケット発券カードとして簡単に使用することができる。
【0014】
例示的な実施形態において、セキュアチャンネルを介して個人化データを受信することができるユーザ装置、セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバ(例えばGAAが使用されているNAFサーバ)、及びこのユーザ装置と個人化アプリケーションサーバを実現するシステムもまた備えられる。
【0015】
従って本発明の1つの態様によれば、個人化アプリケーションサーバからユーザ装置への個人化データの無線(OTA)送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するための方法が提供される。1つの例示的な実施形態では、本方法は、(1)ユーザ装置及び個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する段階と、(2)1つ又はそれ以上の共有秘密鍵を使用して発行者セキュリティドメインを作成する段階とを含み、ここで発行者セキュリティドメインは、個人化アプリケーションサーバからユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる。
【0016】
本発明の別の態様によれば、第1エンティティから第2エンティティにセキュアな方法で個人化データをOTAで送信する方法が提供される。1つの例示的な実施形態では、本方法は、(1)汎用認証アーキテクチャ(GAA)を使用して第1及び第2エンティティに既知の1つ又はそれ以上の共有秘密鍵を生成する段階と、(2)1つ又はそれ以上の共有秘密鍵を使用して第1と第2エンティティとの間に発行者セキュリティドメインを作成する段階と、(3)発行者セキュリティドメインを使用して第1と第2エンティティとの間にセキュアチャンネルを設定する段階と、(4)セキュアチャンネルを介して個人化データを送信する段階とを含む。
【0017】
本発明の更に別の態様によれば、セキュアチャンネルを介して個人化アプリケーションサーバからの個人化データを受信することができるユーザ装置が提供される。1つの例示的な実施形態では、ユーザ装置は、該ユーザ装置に固有の少なくとも1つの秘密鍵を含むユーザ識別モジュールと、ユーザ識別モジュールと通信するセキュアコアとを含む。秘密鍵は、セキュアコア上に記憶することができる個人化アプリケーションサーバ及びユーザ装置に既知の1つ又はそれ以上の共有秘密鍵を生成するのに使用することができる。これらの共有秘密鍵は次いで、発行者セキュリティドメインを作成するのに使用され、該発行者セキュリティドメインが、ユーザ装置が個人化データを受信することができるセキュアチャンネルを設定するのに使用することができる。
【0018】
本発明の別の態様によれば、モバイルクレジットカード決済システムが提供される。1つの例示的な実施形態では、本システムは、個人化アプリケーションサーバと、個人化アプリケーションサーバからユーザ装置に個人化データをOTAで送信するためのセキュアチャンネルを介して個人化アプリケーションサーバと通信するユーザ装置とを含む。個人化アプリケーションサーバ及びユーザ装置に既知の1つ又はそれ以上の共有秘密鍵は、セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するのに使用することができる。
【0019】
本発明の更に別の態様によれば、個人化アプリケーションサーバからユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するためのシステムが提供される。1つの例示的な実施形態において、本システムは、(1)ユーザ装置及び個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する手段と、(2)1つ又はそれ以上の共有秘密鍵を使用して発行者セキュリティドメインを作成する手段と、を含み、ここで発行者セキュリティドメインは、個人化アプリケーションサーバからユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる。
【0020】
本発明の更に別の態様によれば、個人化アプリケーションサーバからユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するためのコンピュータプログラム製品が提供される。1つの例示的な実施形態では、コンピュータプログラム製品は、コンピュータ可読プログラムコード部分が記憶された少なくとも1つのコンピュータ可読記憶媒体を含む。コンピュータ可読プログラムコード部分は、(1)ユーザ装置及び個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成するための第1の実行可能部分と、(2)1つ又はそれ以上の共有秘密鍵を使用して発行者セキュリティドメインを作成する第2の実行可能部分と、を含むことができ、ここで発行者セキュリティドメインは、個人化アプリケーションサーバからユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる。
【0021】
本発明の別の態様によれば、セキュアチャンネルを介して個人化アプリケーションサーバから個人化データを受信することができるユーザ装置が提供される。1つの例示的な実施形態では、このユーザ装置は、(1)ユーザ装置及び個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成するための手段と、(2)ユーザ装置に共有秘密鍵を記憶するための手段と、(3)共有秘密鍵を使用して、発行者セキュリティドメインを作成する手段とを含むことができる。発行者セキュリティドメインは、ユーザ装置が個人化データを受信することができるセキュアチャンネルを設定するのに使用することができる。1つの例示的な実施形態では、共用鍵をユーザ装置上でセキュアな環境で記憶することができる。
【0022】
本発明の更に別の態様によれば、セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバが提供される。1つの例示的な実施形態では、個人化アプリケーションサーバは、プロセッサと、該プロセッサと通信するメモリとを備え、該メモリは、プロセッサによって実行可能なアプリケーションを記憶する。1つの例示的な実施形態では、このアプリケーションは、実行時にセキュリティデータに対するリクエストを受信し、該リクエストに応答して認証チャレンジを送信することができ、ここでチャレンジは、共有秘密鍵を認証に使用するようにする旨のリクエストを含む。本アプリケーションは更に、実行時に共有秘密鍵を使用して暗号化された応答を受信し、該応答を検証し、検証時に共有秘密鍵を使用してリクエストされたセキュリティデータを暗号化して、暗号化されたセキュリティデータを送信することができる。暗号化されたセキュリティデータは次に、セキュアチャンネルを設定するのに更に使用することができる発行者セキュリティドメインを作成するために使用することができる。メモリ上に記憶されたアプリケーションは更に、実行時に設定されたセキュアチャンネルを介して個人化データを送信することができる。
【0023】
本発明の更に別の態様によれば、セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバが提供される。1つの例示的な実施形態では、個人化アプリケーションサーバは、(1)セキュリティデータに対するリクエストを受信する手段と、(2)このリクエストに応答して、共有秘密鍵を認証に使用する旨のリクエストを含む認証チャレンジを送信する手段と、(3)共有秘密鍵を使用して暗号化された応答を受信する手段と、(4)応答を検証する手段と、(5)検証時に、共有秘密鍵を使用してリクエストされたセキュリティデータを暗号化し、セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するために使用することができる暗号化されたセキュリティデータを送信する手段と、(6)セキュアチャンネルを介して個人化データを送信する手段とを含む。
【発明を実施するための最良の形態】
【0024】
このように本発明について概略的に説明したが、ここで、必ずしも一定の縮尺ではない添付図面について述べる。
【0025】
添付図面を参照しながら本発明を以下により詳細に説明するが、該図面には本発明の全てではなく一部の実施形態が図示されている。実際、これらの発明は、多くの異なる形式で具現化することができ、本明細書に記載される実施形態に限定されるものと解釈すべきではなく、逆に、これらの実施形態は、本開示が適用される法的要件を満たすように提供される。同じ番号は全体を通して同じ要素を示す。
【0026】
1つの例示的な実施形態では、クレジットカード個人化又は公共交通チケット発券データなどの個人化情報をOTAでモバイルデバイスに送信するためのセキュアチャンネルを作成するのに使用することができる発行者セキュリティドメインが作成される。有利な実施形態では、この発行者セキュリティドメインは、汎用認証アーキテクチャ(GAA)を使用して設定される。GAAは、第3世代パートナーシッププロジェクト(3GPP)によって提案され、「Generic Authentication Architecture(GAA:汎用認証アーキテクチャ);システム概要(2005年3月6日発行)(3GPP TS33.919v6.2.0(2005−03)」と題された3GPP技術仕様33.919において説明された認証メカニズムであり、この内容は引用により全体が本明細書に組み込まれる。GAAは、携帯電話、パーソナルデジタルアシスタント(PDA)、又はモバイルPC(パーソナルコンピュータ)、或いは同様のものなどのモバイルデバイスのユーザのための種々のアプリケーション及びサービスに対するセキュリティ手続として使用されることを目的とする。
【0027】
GAA及び汎用ブートストラッピング手続
GAAは、ユーザ装置(UE)に関連して提供された特定のセキュア記憶エンティティ上、並びにモバイルオペレータネットワークの加入者データベース内に記憶されている共有秘密鍵に基づく。UEのセキュア記憶エンティティは、加入者識別モジュール(SIM)又は例えばユニバーサルSIM(USIM)であるSIM様アプリケーションを含み汎用ICカード(UICC)などの適切なセキュリティモジュール又は識別モジュールによって提供することができる。加入者データベースは、ホームロケーションレジスタ(HLR)又はホーム加入者サーバ(HSS)などのネットワークエンティティによって提供することができる。セキュアユーザ識別記憶エンティティ及び加入者データベースエンティティは通常、ユーザ識別を発行し、通常は加入者データベースを実行し所有するモバイルネットワークオペレータによって制御される。オペレータは、例えば、モバイルデバイスに関連するGAAのアプリケーションにおいて、モバイルデバイスユーザのサービスプロバイダ(例えばT−Mobile又はSprint)とすることができる。GAA下で、HSS又はHRL及びUEのセキュア記憶エンティティは、モバイルネットワークオペレータによってHSS/HRL及びセキュア記憶エンティティに与えられ、ユーザ及びモバイルネットワークを認証するのに使用される共通の共有秘密を有する。次いで、このオペレータ所有の共有秘密は、新しいアプリケーション固有の共用鍵を導出するためにGAAによって使用される。
【0028】
図2は、ホーム加入者サーバ(HSS)30、ユーザ装置(UE)40、及びネットワークエンティティ(NE)50と相互関係にあるGAA環境20の概要である。GAA20は、基本的に、汎用ブートストラッピングアーキテクチャ(GBA)22、加入者証明書24、及び認証プロキシ(AP)26からなる。GAA20の例示的な使用は、モバイルデバイス及びアプリケーションサーバにクレデンシャル(例えば共有秘密)を提供することになり、該クレデンシャルは、後でHTTPS(セキュアハイパーテキスト転送プロトコル)に対して使用することができる。GBA22は、共有秘密に基づく種々のアプリケーションに対して汎用認証機能を提供することによって加入者証明書24及びAP26の両方に対する基礎を構築する。GBA機能とは通常、アプリケーションセキュリティに対する認証及び鍵共有をブートストラップすることであり、更にこれは、通常、Niemi等による「Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)(認証及び鍵共有(AKA)を使用したハイパーテキスト転送プロトコル(HTTP)ダイジェスト認証)」(2002年9月)と題するインターネットエンジニアリングタスクフォース(IETF)、ネットワークワーキンググループ、コメントに対するリクエスト:3310に従うHTTPダイジェストAKA(認証及び鍵共有)メカニズムに基づいており、この内容は、引用により全体が本明細書に組み込まれる。
【0029】
図3は、汎用ブートストラッピングのための例示的なネットワークモデルを示す。図に示すように、ブートストラッピングサーバ機能(BSF)60は、双方向リンクを介してユーザ装置(UE)40に接続されている。BSF60及びUE40は、AKAプロトコルを使用して相互に認証し、セッション鍵に合意することができる。これらのセッション鍵は、後で、ユーザ装置とネットワークアプリケーション機能(NAF)サーバ70との間のセッションに使用することができ、該サーバは、双方向リンクによってユーザ装置40及びBSF60に接続されている。1つの例示的な実施形態では、NAFサーバ70は、オペレータのシステム内に含まれる。或いは、NAFサーバ70は単に、セキュリティクレデンシャルサービスを提供するためにオペレータと契約することができる。サードパーティネットワークの場合には、アーキテクチャは、図示されていないが「Generic Authentication Architecture(GAA:汎用認証アーキテクチャ);Generic Bootstrapping Architecture(汎用ブートストラッピングアーキテクチャ)」(2005年6月7日発行)(3GPP TS33.220v7.0.0(2005−06))(以下「TS33.220」)と題された3GPP技術仕様33.220に説明されるようなDiameter(ダイアメータ)−プロキシ(D−プロキシ)を含むことができ、この内容は、引用により全体が本明細書に組み込まれ、www.3gpp.orgで見ることができる。
【0030】
以下に詳細に説明されるブートストラッピング手続の後で、ユーザ装置40及びNAF70は、例えばクレジットカード個人化又は公共交通チケット発券アプリケーションであるアプリケーション固有プロトコルを実行することができ、ここでは、メッセージの認証及び機密保護が相互認証の間に生成されたセッション鍵に基づくことになる。従って、GAA/GBA22は、一般的に、3パーティ認証ケースとして見なすことができ、BSF60は更に、例えばGBAユーザセキュリティ設定(GUSS)を記憶するHSS30又はHLRに接続される。幾つかのHSSが存在する場合には、BSFとHSSとの間の接続はSLF(サーバロケーション機能)を利用でき、これによってBSFは、適切なユーザデータを記憶するHSSを見つけることができる。
【0031】
図3の個々のエンティティ間の基準ポイント(インターフェース)は、Ub、Ua、Zn、及びZhで示されている。1つの実施形態では、インターフェースZn及びZhはダイアメータに基づく(Diameter Base Protocol(ダイアメータベースプロトコル)に従う。これは、Calhoun等による「Diameter Base Protocol(ダイアメータベースプロトコル)」(2003年9月)と題されたIETF、ネットワークワーキンググループ、コメントに対するリクエスト:3588で規定されており、この内容は引用により全体が本明細書に組み込まれる)。或いは、インターフェースZnは、ハイパーテキスト転送プロトコル(HTTP)に基づくことができる。インターフェースUbは、HTTPダイジェストAKAメッセージの再利用又はHTTPダイジェストメッセージの変形に基づき、インターフェースUaによって使用されるプロトコルは、実行されることになるアプリケーションに依存する。訪問側NAFの場合には、付加的なZn基準ポイントが挿入されることになる。
【0032】
汎用ブートストラッピングアーキテクチャの利用は、2つの段階に分けることができる。図4は、第1段階、すなわちそれ自体(汎用)ブートストラッピング手続を示し、図5は、第2段階、すなわち汎用ブートストラッピング利用手続を示す。
【0033】
図4に示されるように、ブートストラッピング手続の第1段階では、ユーザ装置(UE)40がHTTPリクエストをBSF60に送る。ステップ2で、BSF60は、ユーザプロファイル(Prof)及び認証ベクトル(AV)をHSS30からZhインターフェースを通じて検索し、該認証ベクトルは、5つの要素、すなわち乱データ(RAND)、認証トークン(AUTN)、予測される応答(XRES)、保全鍵(IK)、及び機密鍵(CK)を含む。BSF60はまた、GBAユーザセキュリティ設定(GUSS)を検索することができる。次にステップ3で、BSF60は、認証パラメータRAND及びAUTNをUE40に転送し、UE40が自己を認証するよう要求するようにする。UE40は、ステップ4で認証済みネットワークからのチャレンジを検証するためにメッセージ認証コード(MAC)を計算し、セッション鍵CK、IK、及び応答RESを導出する。これらのセッション鍵CK、IK、及び応答RESは、BSF60とUE40の両方が利用可能である。ステップ5で、UE40は、ここではHTTPダイジェストのパスワードとして応答RESを使用してBSF60にリクエストを再送する。BSF60は、ステップ6で、受信パラメータがRESを使用して計算されており、且つHSS30から認証ベクトルの一部として前に取得されていたXRESを使用して同様に計算されたパラメータに等しいかどうかをチェックする。これらのパラメータが等しい場合、UE40は認証され、BSF60は、ステップ7でセッション鍵CK及びIKを連結することによって鍵(「マスターキー」)Ksを生成する。
【0034】
ステップ8で、BSF60は、ブートストラッピングトランザクション識別子B−TID及び他のデータ(例えば、鍵Ksの有効期間など)を含むOKメッセージをUE40に送り、これによって認証の成功が示される。次に、セッション鍵CKとIKを連結することによって、鍵KsがUE40で生成される(ステップ9)。この後すぐに、ユーザ装置(クライアント)40とブートストラッピングサーバ機能(BSF)60との間のブートストラッピングセッションが正常に開始される。
【0035】
図5は、ブートストラップされたセキュリティアソシエーションを用いた例示的な手続(すなわち第2段階)を示す。ブートストラッピングセッションを開始した後、UE40は、NAF70との通信を開始することができる。これによって、UE40及びBSF60においてブートストラッピング手続中に生成されたマスターキーKsを用いて、Ks_NAF、又はKs_ext_NAF及びKs_int_NAFで示される1つ又は2つのNAF固有鍵(以下に説明されるように、UEがGBA対応のUICCを備えているかどうかで異なる)を導出する。ステップ1で、UE40は、アプリケーションリクエストをUaインターフェースを介してNAF70に送信する。アプリケーションリクエストは、ブートストラッピング中に取得されたトランザクション識別子B−TID、msgで示されるアプリケーション固有データセット、及びMACで示される全てのクレデンシャルを含む。
【0036】
ステップ2で、NAF70は、1つ又はそれ以上の鍵と、場合によってはUE40により提供された情報に対応するユーザプロファイルデータをZnインターフェースを介してBSF60にリクエストする。このようなリクエストは、例えば、トランザクション識別子に基づくことができる。ステップ2と3の間で、NAF固有鍵Ks_NAF、又はKs_ext_NAF及びKs_int_NAFがBSFエンティティ60で生成される。ステップ3で、BSF60は、要求された1つ又は複数の鍵(NAF固有鍵、ブートストラッピング時間、鍵の有効期間、及びProfで示されるユーザプロファイルのアプリケーション固有部分を含む)をNAF70に提供することによって応答し、これをNAF70が直接使用するか、或いはこれを用いてNAF70が、UE40に向けたUaインターフェースを介して使用されるプロトコルを保護するのに必要な別の鍵を導出することができ、これはアプリケーション固有の機能であり、GAA仕様では対処されない。このような導出は、UE40が事前に行ったのと同じ方法で行われる。次に、NAFエンティティ70は、少なくとも、NAF固有鍵、ブートストラッピング時間、Prof、及び鍵の有効期間といったパラメータを記憶する。ステップ4で、NAF70は、アプリケーション応答をUE40に送ることによってUaインターフェースを介して用いられたプロトコルを継続する。
【0037】
汎用ブートストラッピングアーキテクチャ(GBA)に関する更なる詳細については、上記に引用されたTS33.220を参照されたい。
【0038】
セキュア方式でのOTA個人化送信
本発明の例示的な実施形態は、セキュアチャンネルを介したユーザ装置(UE)への個人化データの無線(OTA)送信を可能にする手段を提供する。上述のように、セキュアチャンネルは、公的に容易に識別され又は修正されることなく情報を転送することができる何らかのチャンネルであり、ユーザ装置は、製造中にモバイルデバイスに埋め込まれたEMV証明済みチップ、或いはモバイルデバイスに関連するUICC又はスマートカードに記憶された1つ又はそれ以上のEMVアプリケーションのいずれかに基づくEMV機能を有するモバイルデバイスを指す。特に、例示的な実施形態は、個人化アプリケーションサーバからUEにクレジットカード個人データ化又は公共交通チケット発券データなどの個人化データを送信するためのセキュアチャンネルを作成するのに用いることができる発行者セキュリティドメインを設定する段階を含む。発行者セキュリティドメインは、例えば、以下に説明されるEMVアプリケーションなどのモバイルデバイスによって実行される1つ又はそれ以上のアプリケーションプログラムを含む種々の手段によって設定できる。この結果、ユーザは、クレジットカード又は公共交通カードを使用する場合と同じように自分のモバイルデバイスを使用することができる。例示的な実施形態は更に、UEと個人化アプリケーションサーバとの間で共有される1つ又はそれ以上の秘密鍵の生成を含み、生成された共有秘密鍵は、セキュアチャンネルを設定するのに使用される。この鍵は、例えば、以下に説明されるブートストラッピングサーバ機能(BSF)サーバと共にGBA又はGBA_UなどのUEによって実行される1つ又はそれ以上のアプリケーションプログラムを含む種々の手段によって生成することができる。
【0039】
当業者には理解されるように、セキュアチャンネルの設定に必要な共有秘密鍵は、本発明の例示的な実施形態による種々の方法で生成することができる。単に例証の目的で、本発明の実施形態は、UEとネットワークアプリケーション機能(NAF)サーバとして動作する個人化アプリケーションサーバ又はビューローとの間で共有できる共有秘密鍵を生成するために汎用認証アーキテクチャ(GAA)を使用するものとして説明される。しかしながら、例示的な実施形態におけるGAAの使用は、どのような点でも本発明をこのGAAの使用に限定するものとみなすべきではない。
【0040】
本発明の1つの例示的な実施形態では、セキュアチャンネルを介して個人化データをモバイルデバイスにOTA送信できるようにするために、製造中のモバイルデバイスにブランクチップがインストールされる。共有秘密鍵のインストレーションプロセスは、エンドユーザがモバイルデバイスを所有した後に行うことができ(すなわち、発行者セキュリティドメインを作成することができる)、共有秘密鍵が生成され(例えば上述のGAA手続に従って)、次いでブランクチップに記憶される。1つの例示的な実施形態では、このブランクチップへの通信インターフェースを保護することができる。次に、UE(すなわち、モバイルデバイス+EMV証明済みチップ)がこれらの鍵を使用して、クレジットカード用の個人化アプリケーションサーバ(例えばNAFサーバ)又は類似の個人化手続へのセキュアリンクを設定することができる。
【0041】
他の例示的な実施形態では、1つ又はそれ以上のEMVアプリケーションを含むUICC又はスマートカードは、モバイルデバイスに関連付けられる。上述のように、1つの例示的な実施形態では、製造中にモバイルデバイスに組み込まれたネットワークオペレータUICC又はスマートカード上にEMVアプリケーションを記憶することができる。或いは、モバイルデバイスは、取り外し可能であり且つ2つのスロットを有するあらゆるモバイルデバイスと共に利用可能なEMV固有UICC又はスマートカードに第2スロットを設けることができる。
【0042】
従って、例示的な実施形態のシステムは、ハードウェア要素、ソフトウェア要素、又はこれらの何らかの組み合わせなど、共有秘密鍵を生成して該鍵を記憶し、鍵を使用して発行者セキュリティドメインを設定するための手段を含み、該手段は、例えばモバイルデバイス、BSFサーバ又は個人化アプリケーション(例えばNAF)サーバに埋め込まれ、以下で詳細に説明される。このような説明がなされていない他のこうした手段はまた、本発明の例示的な実施形態の精神から逸脱することなく、これらの機能を実行するのに使用することができる。
【0043】
図6は、本発明の例示的な実施形態に従って動作することができるUEのブロック図である。UEは、以下に説明されるようなEMV機能を有する、例えば携帯電話、パーソナルデジタルアシスタント(PDA)、ページャー、パーソナルコンピュータ(PC)、ラップトップ、タブレット、又は他のいずれかの類似のデバイスなどのモバイルデバイスを含むことができる。図示のように、UEは、少なくともセキュアコア610、UICC(汎用ICカード)620、EMVアプリケーション632、及びGBAアプリケーション634からなることができる。セキュアコア610は、モバイルデバイスの中心又は最も内側の部分である必要はなく、本明細書で説明されるように機能することができるいずれかの1つ又は複数の要素を単に表わすものであって、製造中にインストールされ、生成された共有秘密鍵612を記憶することができるブランクチップ、並びに決済又はチケット発券のためにUEの使用を可能にするためにユーザによって或いはユーザに代わってインストールされた1つ又はそれ以上の決済又はチケット発券アプリケーション614からなることができる。
【0044】
UICC620は、これが配置されるモバイルデバイスのユーザに固有の識別情報626を記憶するユーザ識別モジュールを含むことができる。ユーザ識別モジュールは、実際にはモジュラーである必要はない。言い換えると、ユーザ識別モジュール内に記憶されている識別情報は、1つのモジュラーエンティティの一部として記憶する必要はなく、代わりに、モバイルデバイス全体に分散されてもよい。この識別情報626は、GAA手続(又は共有秘密鍵インストレーションプロセス)中に使用して、BSFサーバに対してUEを識別することができる。1つの実施形態では、UICC620は更にEMV_U622及びGBA_U624アプリケーションを含み、これらはまた、UICC620とNAFサーバとの間にセキュアリンクを設定するために共有秘密鍵インストレーションプロセスにおいて使用される。詳細には、GBA_Uアプリケーション624を用いてNAF固有鍵を生成することができ、該固有鍵を用いて、モバイルネットワークオペレータとUICC620との間で共有される秘密鍵(すなわちCK及びIK)に基づいて、UEをNAFサーバに対して認証するか、或いは2つの間の通信をセキュアにすることができる。1つの実施形態では、UEは、UICC620においてGBA_Uアプリケーション624を含まない場合がある。この場合、鍵生成及び記憶機能は、UEのGBAアプリケーション634によって行われ、UICCは必要な情報を配信するだけである。1つの実施形態では、EMV_Uアプリケーションは、共有秘密鍵インストレーションプロセスの進行をモニターするのに使用される状態機械を含む。この実施形態では、インストレーションプロセスが中断された場合、状態機械は、インストレーションを再開する必要があることを指示する。UEがGBA_Uアプリケーションを含まない場合、EMV_Uアプリケーションはまた、モバイル端末に常駐し、UICCには常駐しない。
【0045】
UEに含まれるEMVアプリケーション632は、UEの外部にあるエンティティ(例えばNAF及びBSFサーバ)と、UICC620及びセキュアコア610との間の通信を可能にすることによって通信エンティティとして動作する。例えば、共有秘密鍵インストレーションプロセスにおいて、EMVアプリケーション632は、以下に詳細に説明されるように、NAFサーバに発行者セキュリティドメイン鍵を要求し、これらを解読するためにUICC620に渡し、更にこれらの鍵をセキュアコア610上に記憶する役割を果たす。上述のように、UICC620内にGBA_Uアプリケーション624が存在しない1つの実施形態では、UEにあるGBAアプリケーション634が、以下に説明される鍵生成及び記憶機能を実行する。
【0046】
図7Aは、クレジットカード用にUEを準備する場合、或いは類似の個人化、すなわちセキュリティ及びユーザデータをUEに送信することができるセキュア通信チャンネルを設定するのに用いることができる発行者セキュリティドメインを作成する場合の例示的な実施形態において実行されるステップを示す信号フロー図である。第1のステップで、EMVアプリケーション(モバイル/ユーザデバイス(UE)に常駐している)は、NAFサーバ(すなわち、オペレータによってホストされるか或いはオペレータとビジネス関係にある個人化ビューロー)に付加的なセキュリティデータをリクエストする。付加的なセキュリティデータは、実際の個人化プロセスに後で使用され、例えば暗号化鍵及び/又はMAC(メッセージ認証コード)鍵とすることができる発行者セキュリティドメイン鍵を表わす。ステップ2で、NAFサーバは、認証チャレンジをEMVアプリケーションに返し、EMVアプリケーションがGAA共有秘密方法を使用して自らを認証するようリクエストする。次にステップ3で、UEのEMVアプリケーションは、UEに同様に位置付けられたGBAアプリケーションにGAA共有秘密をリクエストする。
【0047】
ステップ4で、共有秘密は、上記に詳細に説明されたブートストラッピング手続を使用して設定される。UEのGBAアプリケーション、UICCのGBA_Uアプリケーション、及びブートストラッピングサーバ機能(BSF)サーバは各々、このプロセスに含まれる。この手続の最後で鍵が生成される(GBA_UがUICCによってサポートされる場合、Ks_ext_NAF及びKs_int_NAF、そうでない場合はKs_NAF)。Ks_int_NAF及び/又はKs_ext_NAFは、GBA_Uアプリケーション及びBSFの両方に既知である。GBA_Uが使用されない場合、BSFはKs_NAFを認知しており、NAFはこれらの鍵をBSFにリクエストすることができる。UEは、Ks_ext_NAFとKs_NAFのみを認知している。共有秘密が設定されると、GBAアプリケーションは、ステップ5で、Ks_ext_NAFをUEのEMVアプリケーションに与える(或いは、GBA手続がUEのみに依存する場合には、UEは既にKs_NAFを有している)。ステップ6で、EMVアプリケーションは、Ks_ext_NAF又はKs_NAFを使用してNAFサーバの認証チャレンジへの応答をNAFサーバに返す。
【0048】
ステップ7で、NAFサーバは、BSFサーバからNAF固有鍵(すなわちKs_ext_NAF及びKs_int_NAF、又はKs_NAF)をフェッチする。次いでステップ8で、NAFサーバは認証応答を検証し、例えばKs_int_NAF又はKs_NAFを使用して付加的なセキュリティデータを暗号化し、暗号化されたデータをUEのEMVアプリケーションに転送する。しかしながら、EMVアプリケーションは、Ks_int_NAFで暗号化された受信データを解読することができない。一方では、データがKs_NAFで暗号化された場合には、UEはこれを解読することができ、ステップ11でセキュリティデータのインストレーションに進むことになる点に留意されたい。UEが受信されたデータを解読できないと仮定すると、ステップ9で、EMVアプリケーションは、暗号化された付加的なセキュリティデータ(すなわち発行者セキュリティドメイン鍵)をUICC上のEMV_Uアプリケーションに渡す。UEでのセキュリティオペレーションは、セキュアな環境又は信頼できるプラットフォームにおいて実行することができる。
【0049】
ステップ10で、EMV_Uアプリケーションは、メッセージを解読するために必要なKs_int_NAF鍵をEMV_Uが持たないので、暗号化された付加的なセキュリティデータ(すなわち発行者セキュリティドメイン鍵)をGBA_Uに与える。GBA_Uアプリケーションは、ステップ11でデータを解読し、これをEMV_Uアプリケーションに返す。或いは、ステップ10及び11で、EMV_Uアプリケーションは、GBA_UアプリケーションにKs_int_NAF鍵をリクエストすることができる。Ks_int_NAF鍵を受け取ると、EMV_Uアプリケーションは自らデータを解読することができる。これによって、UICC上でのEMV_Uアプリケーションが付加的なセキュリティデータのインストレーション及び発行者セキュリティドメインの作成を行うことが可能となる。付加的なセキュリティデータ、例えば鍵、鍵の有効期間、鍵生成時間、及び/又はB−TIDは、セキュアコア上に発行者セキュリティドメインを作成するのに使用される。次いで、この発行者セキュリティドメインを用いて、決済アプリケーションデータ、クレジットカード個人化データ、又は同様のものなどのアプリケーション固有のセキュリティドメインを記憶することができる。
【0050】
インストレーションプロセスが図7Bに示されており、EMV_UがUE内のEMVアプリケーションに解読された付加的なセキュリティデータを渡すステップ11aから始まる。次いで、EMVアプリケーションは、ステップ11bで、付加的なセキュリティデータを使用してセキュアコア上に発行者セキュリティドメインを作成することができる。ステップ11cで、発行者セキュリティドメインの成功した作成の確認が、セキュアコアからUE内のEMVアプリケーションに送られる。最後に、任意選択であるステップ11dで、EMVアプリケーションがEMV_Uに発行者セキュリティドメインの成功した作成を確認する。
【0051】
図7A及び7Bに示されるステップ12で、EMV_Uアプリケーションは、任意選択的であるが、成功(又は失敗)メッセージをUE上のEMVアプリケーションに返す。次いで、EMVアプリケーションは、ステップ13(図7Bには示されていない)でこの成功(又は失敗)メッセージをNAFサーバに返す。1つの実施形態では、EMV及びEMV_Uアプリケーションの両方によって返された成功メッセージは、送信側の真正性を与えるためにNAF固有鍵を使用して暗号化される。最後に、同様に任意選択であるステップ14(図7Bには示されていない)で、NAFサーバは成功メッセージに対する肯定応答を返す。
【0052】
幾つかの実施形態では、セキュアチャンネルプロトコル2(http://www.globalPlatform.org/specificationview.asp?id=cardで入手可能な、グローバルプラットフォームカード仕様バージョン2.1.1を参照、本内容は、引用により全体が本明細書に組み込まれる)、TLS、事前共用鍵(PSK)TLS、IPSec又はHTTPダイジェストなどの付加的なセキュリティプロトコルは、上述されたプロセスの幾つかのステップにおいてGAAと共に使用することができる。セキュリティドメイン鍵は、個人化データのダウンロードをセキュアにするためのセキュアチャンネルプロトコル2によって使用することができる。NAF固有鍵はまた、例えばPSK TLSを使用して通信チャンネルをセキュアにするのに使用することができる。
【0053】
上記のステップの終わりで、クレジットカード個人化データ又は公共交通チケット発券データなどの個人化データをセキュアチャンネルがUEにOTAで送信することができるように共用鍵が設定され、これによってUEは、例えばユーザのクレジットカード又はプリペイド公共交通カードとして機能を果たすことができるようになる。
【0054】
例示的な使用のケース
図8−11は、本発明の例示的な実施形態によるクレジットカード個人化のためのモバイルデバイスを準備するための4つの段階を示すフローチャートである。これらの段階のステップは、本質的には例示的なものに過ぎず、各状況において当てはまる場合もあればそうでない場合もある幾つかの仮定に基づいている。例えば、以下の例証では、モバイルデバイスユーザは、該ユーザが例えば自分のパーソナルコンピュータ(PC)を使用しているいずれかの場所からアクセスできるパーソナルインターネットバンキングアカウントを有していると仮定する。このインターネットバンキングアカウントを介して、ユーザは自分のモバイルデバイスにクレジットカード機能を使用することができるようにリクエストする。しかしながら、インターネットバンキングアカウントなどを持たないモバイルデバイスユーザでも、本発明の使用を禁じられてはいない。これらのユーザは、例えばメール又はファクシミリを介して利用可能性をリクエストすることができる。
【0055】
図8に示される段階1では、ユーザは、例えばクレジットカード又は公共交通チケット発券カードとして自分のモバイルデバイスを利用可能にすることを決定し、すなわち、ユーザは、製造中の自分のモバイルデバイスにインストールされたセキュアコア/チップを利用可能にするプロセスを開始する。ステップ801で、ユーザは、自分のPCを使用して自分のインターネットバンキングアカウントにアクセスし、自分のモバイルデバイスを利用可能にすることを選択する。ステップ802で、ユーザは、自分の電話番号を入力するよう促されて入力する。図12及び13は、クレジットカード機能に対して自分のモバイルデバイスを利用可能にするよう選択した場合にユーザが見ることのできる例示的なウェブページを示す。ステップ803で、ユーザが口座を持っている金融機関、すなわち銀行このリクエストを受け取り、モバイルデバイスを利用可能にすることに同意する。最後にステップ804で、金融機関は、個人化アプリケーションサーバ又はビューロー(例えば、GAAが使用される場合にNAFサーバとして働く)と連絡を取り、必要なユーザデータを個人化アプリケーションサーバに送信する。このユーザデータは、例えば、ユーザの名前、個人化コード、又はPIN、電話番号などを含むことができる。
【0056】
図9に示される段階2では、発行者セキュリティドメイン鍵がユーザのモバイルデバイスにインストールされたセキュアコード/チップに無線(OTA)で提供される。1つの実施形態では、セキュアチップは、シリアルナンバーのみによって製造中に初期化される。或いは、発行者セキュリティドメインクレデンシャルが発行時にセキュアコア/チップ上に既に配置させることができる。この実施形態では、段階2は完全に無排除され、図では以下に説明される段階3に直接進む。しかしながら、セキュアチップがシリアルナンバーだけを有すると仮定すると、段階2は、ステップ901で始まり、ここでは、金融サーバがNAFサーバに対して、モバイルデバイスがGAA及び共有秘密法を使用する旨のリクエストを通知する。このステップは、例えばWAPプッシュ、OMAデバイス管理手段、SMS、又はHTTPメッセージを電話へのローカル接続を有するPCに送ることによって、或いはユーザがその番号に電話をかけるか又は専用ウェブサイトを閲覧するようリクエストすることによって行われる。
【0057】
ステップ902で、共有秘密は、上述の方法でモバイルデバイスのUICCとBSFサーバとの間に設定される。次にステップ903で、NAFサーバは、BSFサーバからの共有秘密をリクエストする。ステップ904で、UICCは、後でUEを介してセキュアコアに与えられる新しい秘密鍵を取得する。1つの実施形態では、BSFサーバはまたこの秘密鍵を導出する。次にステップ905で、ユーザのモバイルデバイス上のセキュアコア/チップは、共有秘密鍵を記憶する。セキュアコアはここで、セキュリティ発行者ドメイン鍵として使用することができる秘密鍵を有する。
【0058】
図10に示される段階3では、セキュリティドメインは、非接触型決済又はチケット発券アプリケーション用のユーザのモバイルデバイスのセキュアコアに提供される。ステップ1001で、例えば図7A及び7Bに示されるように生成され記憶されたセキュリティ発行者ドメイン鍵を使用して、セキュアコアとNAFサーバとの間にセキュアトンネルが設定される。モバイルデバイスは、例えばHTTP又はGPRS(汎用パケット無線サービス)を使用してこのトンネルの設定をサポートする。このトンネルは、ステップ1002でセキュリティドメインデータをセキュアコアにダウンロードするのに使用される。最後にステップ1003で、セキュアコアは、非接触型決済又はチケット発券アプリケーション用のセキュリティドメインを設定する。
【0059】
図11に示される最後の段階である段階4は、決済アプリケーション(例えばモバイルクレジットカード個人化)のダウンロードを表わす。ステップ1101で、ユーザは、自分のPCでアクセスしたウェブサイト上で個人化コードを受け取る。次いでステップ1102で、NAFサーバ又は個人化ビューローは、例えばWAPプッシュを使用してURLをユーザにプッシュし、ユーザに自分のモバイルデバイスを使用して当該URLを閲覧するように指示する。ステップ1103で、ユーザは受け取ったURLを閲覧し、受け取った個人化コードを自分のモバイルデバイスに挿入して、妥当性確認のためにこれをNAFサーバに送るように促される。ステップ1104で、NAFサーバは、段階2で設定されたセキュリティドメイン鍵によって暗号化された個人化コードをセキュアコアにプッシュする。ステップ1105で、モバイルデバイスは、セキュアコアを個人化し(すなわち、アプリケーション固有のセキュリティドメインを作成し、公共交通チケット又はクレジットカード番号などの個人ユーザデータを当該ドメインに入れる)、金融機関及び/又はNAFサーバにセキュアコアの正しい初期化を確認する。最後に、ステップ1106及び1107それぞれにおいて、端末決済アプリケーション及びセキュアコア決済アプリケーションがダウンロードされインストールされる。図14は、上記のステップを実行した場合にユーザが自分のモバイルデバイス上で見ることのできる例示的な画面を示す。これ以降、ユーザは、自分のモバイルデバイスを利用してRFID通信などを介してカードリーダーと対話することができ、クレジット又はデビットカードと同様の方法で商品又はサービスを購入し、或いは公共交通チケットの決済を行うことができる。
【0060】
結論
上述され並びに当業者によって理解されるように、本発明の実施形態は、システム、方法、モバイルデバイス又は他の装置、或いはコンピュータプログラム製品として構成することができる。従って、本発明の実施形態は、完全にハードウェアだけ、完全にソフトウェアだけ、或いはソフトウェア及びハードウェアのあらゆる組合せを含む種々の手段から構成することができる。更に、本発明の実施形態は、記憶媒体に組み込まれたコンピュータ可読プログラム命令(例えばコンピュータソフトウェア)を有するコンピュータ可読記憶媒体上のコンピュータプログラム製品の形式を取ることができる。ハードディスク、CD−ROM、光記憶デバイス、又は磁気記憶デバイスを含むあらゆる適切なコンピュータ可読記憶媒体を利用することができる。
【0061】
本発明の例示的な実施形態について、方法、装置(すなわちシステム)、及びコンピュータプログラム製品のブロック図及びフローチャートを参照しながら上記で説明してきた。ブロック図の各ブロック及びフローチャート図、並びにブロック図のブロックとフローチャート図との組み合わせはそれぞれ、コンピュータプログラム命令を含む種々の手段によって実施することができる。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置にロードして、コンピュータ又は他のプログラム可能データ処理装置上で実行される命令が、1つ又は複数のフローチャートブロックにおいて指定された機能を実施するための手段を生成するような機械をもたらす。
【0062】
これらのコンピュータプログラム命令はまた、コンピュータ又は他のプログラム可能データ処理装置に特定の方法で機能するよう指示できるコンピュータ可読メモリ内に記憶することができ、これによってコンピュータ可読メモリ内に記憶された命令は、1つ又は複数のフローチャートブロックにおいて指定される機能を実施するためのコンピュータ可読命令を含む製造物品を生成する。コンピュータプログラム命令はまた、コンピュータ又は他のプログラム可能データ処理装置にロードし、コンピュータ又は他のプログラム可能装置上で一連の動作ステップを行わせ、コンピュータ又は他のプログラム可能装置上で実行される命令が1つ又は複数のフローチャートブロックで指定される機能を実施するためのステップを提供するようにコンピュータ実装プロセスを生成することができる。
【0063】
従って、ブロック図のブロック及びフローチャート図は、指定された機能を実行する手段の組み合わせ、指定された機能を実行するステップの組み合わせ、及び指定された機能を実行するプログラム命令手段の組み合わせをサポートする。ブロック図の各ブロック及びフローチャート図、並びにブロック図のブロックとフローチャート図の組み合わせが、指定された機能又はステップ、或いは専用ハードウェア及びコンピュータ命令の組み合わせを行う専用ハードウェアベースのコンピュータシステムによって実現できる。
【0064】
本明細書に記載される本発明の多くの修正形態及び他の実施形態は、これらの発明が上記の説明及び関連の図面で提示された教示の利益を有することが本発明の関連する当業者には想起されるであろう。従って、本発明は、開示された特定の実施形態に限定されるものではなく、当該修正及び他の実施形態は、添付の請求項の範囲に含まれるものとすることを理解されたい。特定の用語を本明細書で用いているが、これらは一般的且つ説明的な意味でのみ使用されており、限定を目的とするものではない。
【図面の簡単な説明】
【0065】
【図1】クレジットカードの個人化を行う従来技術のステップを示すフローチャートである。
【図2】従来技術による汎用認証アーキテクチャ環境の概要を示す図である。
【図3】従来技術による汎用ブートストラッピングのためのネットワークモデルを示す図である。
【図4】従来技術による汎用ブートストラッピング手続を示す図である。
【図5】従来技術による汎用ブートストラッピング使用手続を示す図である。
【図6】本発明の例示的な実施形態による動作可能なユーザ装置を示すブロック図である。
【図7A】本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備する場合に行われるステップを示す信号フロー図である。
【図7B】本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備する場合に行われるステップを示す信号フロー図である。
【図8】本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備するための4つの段階を示すフローチャートである。
【図9】本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備するための4つの段階を示すフローチャートである。
【図10】本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備するための4つの段階を示すフローチャートである。
【図11】本発明の例示的な実施形態によるクレジットカード個人化用にユーザ装置を準備するための4つの段階を示すフローチャートである。
【図12】本発明の例示的な実施形態によるクレジットカード機能に自分のユーザ装置を利用可能にするように選択する場合にユーザが見ることのできる例示的なウェブページを示す図である。
【図13】本発明の例示的な実施形態によるクレジットカード機能に自分のユーザ装置を利用可能にするように選択する場合にユーザが見ることのできる例示的なウェブページを示す図である。
【図14】本発明の例示的な実施形態によるクレジットカード機能を利用可能にする場合にユーザが自分のユーザ装置で見ることのできる例示的な画面を示す図である。
【符号の説明】
【0066】
610 セキュアコア
612 共有秘密鍵
614 1つ又はそれ以上の決済又はチケット発券アプリケーション
620 UICC
622 EMV_Uアプリケーション
624 GBA_Uアプリケーション
626 ユーザに固有の識別情報
632 EMVアプリケーション
634 GBAアプリケーション
【特許請求の範囲】
【請求項1】
個人化アプリケーションサーバからユーザ装置への個人化データの無線(OTA:over the air)送信のためのセキュアチャンネル(secure channel)を設定するのに使用することができる発行者セキュリティドメインを作成する方法であって、前記方法は、
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する段階と、
前記1つ又はそれ以上の共有秘密鍵を使用して、前記個人化アプリケーションサーバから前記ユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成する段階と、
を含む方法。
【請求項2】
前記ユーザ装置は、EMV証明済みチップが埋め込まれたモバイルデバイスを含む、
ことを特徴とする請求項1に記載の方法。
【請求項3】
前記ユーザ装置は、1つ又はそれ以上のEMVアプリケーションを記憶している汎用ICカード(UICC)を更に含むモバイルデバイスを含む、
ことを特徴とする請求項1に記載の方法。
【請求項4】
前記UICCは、前記モバイルデバイスから取り除くことができ、別のモバイルデバイスと共に使用することができる、
ことを特徴とする請求項3に記載の方法。
【請求項5】
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する段階は、汎用認証アーキテクチャ(GAA)に従って行われ、前記個人化アプリケーションサーバは、ネットワークアプリケーション機能(NAF)サーバを含む、
ことを特徴とする請求項1に記載の方法。
【請求項6】
前記1つ又はそれ以上の共有秘密鍵を前記ユーザ装置上に記憶する段階を更に含む、
ことを特徴とする請求項1に記載の方法。
【請求項7】
前記個人化データは、クレジットカード個人化データを含む、
ことを特徴とする請求項1に記載の方法。
【請求項8】
前記個人化データは、公共交通チケット発券データを含む、
ことを特徴とする請求項1に記載の方法。
【請求項9】
第1エンティティから第2エンティティにセキュアな方法で個人化データを無線(OTA)で送信する方法であって、
汎用認証アーキテクチャ(GAA)を使用して前記第1及び前記第2エンティティに既知の1つ又はそれ以上の共有秘密鍵を生成する段階と、
前記1つ又はそれ以上の共有秘密鍵を使用して前記第1と前記第2エンティティとの間に発行者セキュリティドメインを作成する段階と、
前記発行者セキュリティドメインを使用して前記第1と前記第2エンティティとの間にセキュアチャンネルを設定する段階と、
前記セキュアチャンネルを介して前記個人化データを送信する段階と、
を含む方法。
【請求項10】
前記第1エンティティはネットワークアプリケーション機能(NAF)サーバであり、前記第2エンティティはユーザ装置である、
ことを特徴とする請求項9に記載の方法。
【請求項11】
前記ユーザ装置は、EMV証明済みチップが埋め込まれたモバイルデバイスを含む、
ことを特徴とする請求項9に記載の方法。
【請求項12】
前記ユーザ装置は、1つ又はそれ以上のEMVアプリケーションを記憶した汎用ICカード(UICC)を更に含むモバイルデバイスを含む、
ことを特徴とする請求項9に記載の方法。
【請求項13】
前記UICCは、前記モバイルデバイスから取り外すことができ、且つ別のモバイルデバイスと共に使用することができる、
ことを特徴とする請求項12に記載の方法。
【請求項14】
前記個人化データは、クレジットカード個人化データを含む、
ことを特徴とする請求項9に記載の方法。
【請求項15】
前記個人化データは、公共交通チケット発券データを含む、
ことを特徴とする請求項9に記載の方法。
【請求項16】
セキュアチャンネルを介して個人化アプリケーションサーバから個人化データを受信することができるユーザ装置であって、前記ユーザ装置は、
前記ユーザ装置に固有の少なくとも1つの秘密鍵を含むユーザ識別モジュールと、
前記ユーザ識別モジュールと通信するセキュアコア(secure core)と、
を備え、
前記秘密鍵は、前記セキュアコア上に記憶されることになる、前記個人化アプリケーションサーバ及び前記ユーザ装置に既知の1つ又はそれ以上の共有秘密鍵を生成するのに使用され、前記1つ又はそれ以上の共有秘密鍵は、発行者セキュリティドメインを作成するのに使用され、該発行者セキュリティドメインが、前記ユーザ装置が前記個人化データを受信することができる前記セキュアチャンネルを設定するのに使用される、
ことを特徴とするユーザ装置。
【請求項17】
前記1つ又はそれ以上の共有秘密鍵は、汎用認証アーキテクチャ(GAA)に従って生成され、前記個人化アプリケーションサーバは、ネットワークアプリケーション機能(NAF)サーバを含む、
ことを特徴とする請求項16に記載のユーザ装置。
【請求項18】
コンピュータ可読媒体に記憶され、前記ユーザ識別モジュール及び前記セキュアコアと通信する1つ又はそれ以上のGAAサポーティングアプリケーションを更に備え、
前記GAAサポーティングアプリケーションは、前記1つ又はそれ以上の共有秘密鍵を生成するために前記NAFサーバ及びブートストラッピングサーバ機能(BSF)サーバと通信するように構成されている、
ことを特徴とする請求項17に記載のユーザ装置。
【請求項19】
前記個人化データは、クレジットカード個人化データを含む、
ことを特徴とする請求項16に記載のユーザ装置。
【請求項20】
前記個人化データは、公共交通チケット発券データを含む、
ことを特徴とする請求項16に記載のユーザ装置。
【請求項21】
個人化アプリケーションサーバと、
前記個人化アプリケーションサーバから無線(OTA)で個人化データを送信するためのセキュアチャンネルを介して前記個人化アプリケーションサーバと通信するユーザ装置と、
を備え、
前記個人化アプリケーションサーバ及び前記ユーザ装置に既知の1つ又はそれ上の共有秘密鍵が、前記セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するのに使用される、
ことを特徴とするモバイルクレジットカード決済システム。
【請求項22】
前記1つ又はそれ以上の共有秘密鍵が、汎用認証アーキテクチャ(GAA)に従って作成され、前記個人化アプリケーションサーが、ネットワークアプリケーション機能(NAF)サーバを含む、
ことを特徴とする請求項21に記載のシステム。
【請求項23】
前記1つ又はそれ以上の共有秘密鍵が、前記ユーザ装置上に記憶される、
ことを特徴とする請求項21に記載のシステム。
【請求項24】
前記ユーザ装置が、EMV証明済みチップが埋め込まれたモバイルデバイスを含む、
ことを特徴とする請求項21に記載のシステム。
【請求項25】
前記ユーザ装置が、1つ又はそれ以上のEMVアプリケーションが記憶された汎用ICカード(UICC)を更に含むモバイルデバイスを備える、
ことを特徴とする請求項21に記載のシステム。
【請求項26】
前記UICCが、前記モバイルデバイスから取り除くことができ、且つ別のモバイルデバイスと共に使用することができる、
ことを特徴とする請求項25に記載のシステム。
【請求項27】
前記NAFサーバ及び前記ユーザ装置と通信するブートストラッピングサーバ機能(BSF)サーバを更に備え、
前記BSFが、前記1つ又はそれ以上の共有秘密鍵の生成を可能にする、
ことを特徴とする請求項22に記載のシステム。
【請求項28】
個人化アプリケーションサーバからユーザ装置への個人化データの無線(OTA)送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するためのシステムであって、前記システムは、
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する手段と、
前記1つ又はそれ以上の共有秘密鍵を使用して、前記個人化アプリケーションサーバから前記ユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成する手段と、
を含むシステム。
【請求項29】
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する前記手段が、汎用認証アーキテクチャ(GAA)に従って前記1つ又はそれ以上の共有秘密鍵を生成する手段を含み、
前記個人化アプリケーションサーバが、ネットワークアプリケーション機能(NAF)サーバを含む、
ことを特徴とする請求項28に記載のシステム。
【請求項30】
前記ユーザ装置上に前記1つ又はそれ以上の共有秘密鍵を記憶する手段を更に含む、
ことを特徴とする請求項28に記載のシステム。
【請求項31】
個人化アプリケーションサーバからユーザ装置への個人化データの無線(OTA)送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するためのコンピュータプログラム製品であって、前記コンピュータプログラム製品が、コンピュータ可読プログラムコード部分が記憶された少なくとも1つのコンピュータ可読記憶媒体を含み、前記コンピュータ可読プログラムコード部分が、
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成するための第1実行可能部分と、
前記1つ又はそれ以上の共有秘密鍵を使用して、発行者セキュリティドメインを作成するための第2実行可能部分と、
を含み、
前記発行者セキュリティドメインが、前記個人化アプリケーションサーバから前記ユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる、
ことを特徴とするコンピュータプログラム製品。
【請求項32】
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する段階が、汎用認証アーキテクチャ(GAA)に従って前記1つ又はそれ以上の共有秘密鍵を生成する段階を含み、前記個人化アプリケーションサーバが、ネットワークアプリケーション機能(NAF)サーバを含む、
ことを特徴とする請求項31に記載のコンピュータプログラム製品。
【請求項33】
前記ユーザ装置上に前記1つ又はそれ以上の共有秘密鍵を記憶するための第3実行可能部分を更に含む、
ことを特徴とする請求項31に記載のコンピュータプログラム製品。
【請求項34】
セキュアチャンネルを介して個人化アプリケーションサーバから個人化データを受信することができるユーザ装置であって、前記ユーザ装置が、
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する手段と、
前記1つ又はそれ以上の共有秘密鍵を前記ユーザ装置に記憶する手段と、
前記1つ又はそれ以上の共有秘密鍵を使用して、発行者セキュリティドメインを作成する手段と、
を備え、
前記発行者セキュリティドメインが、前記ユーザ装置が前記個人化データを受信することができる前記セキュアチャンネルを設定するのに使用することができる、
ことを特徴とするユーザ装置。
【請求項35】
セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバであって、前記個人化アプリケーションサーバが、
プロセッサと、
前記プロセッサによって実行可能なアプリケーションを記憶する前記プロセッサと通信するメモリと、
を備え、
前記アプリケーションが、実行時にセキュリティデータに対するリクエストを受信し、該リクエストに応答して認証チャレンジを送信することができ、前記チャレンジが共有秘密鍵を認証に使用するようにするリクエストを含み、前記アプリケーションが更に、実行時に前記共有秘密鍵を使用して暗号化された応答を受信し、前記応答を検証し、更に検証時に、前記共有秘密鍵を使用してリクエストされた前記セキュリティデータを暗号化して、前記暗号化されたセキュリティデータを送信することができ、前記暗号化されたセキュリティデータは、前記セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するのに使用でき、前記アプリケーションは更に、実行時に前記セキュアチャンネルを介して前記個人化データを送信することができる、
ことを特徴とする個人化アプリケーションサーバ。
【請求項36】
前記個人化アプリケーションサーバが、ネットワークアプリケーション機能(NAF)サーバを含む、
ことを特徴とする請求項35に記載の個人化アプリケーションサーバ。
【請求項37】
前記セキュリティデータは、1つ又はそれ以上の発行者セキュリティドメイン鍵を含む、
ことを特徴とする請求項35に記載の個人化アプリケーションサーバ。
【請求項38】
前記セキュリティデータが更に、前記1つ又はそれ以上の発行者セキュリティドメイン鍵の有効期間及び作成時期を含む、
ことを特徴とする請求項35に記載の個人化アプリケーションサーバ。
【請求項39】
セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバであって、前記個人化アプリケーションサーバが、
セキュリティデータに対するリクエストを受信する手段と、
前記リクエストに応答して、共有秘密鍵を認証に使用する旨のリクエストを含む認証チャレンジを送信する手段と、
前記共有秘密鍵を使用して暗号化された応答を受信する手段と、
前記応答を検証する手段と、
検証時に、前記共有秘密鍵を使用してリクエストされたセキュリティデータを暗号化し、前記セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するために使用することができる前記暗号化されたセキュリティデータを送信する手段と、
前記セキュアチャンネルを介して前記個人化データを送信する手段と、
を含む個人化アプリケーションサーバ。
【請求項1】
個人化アプリケーションサーバからユーザ装置への個人化データの無線(OTA:over the air)送信のためのセキュアチャンネル(secure channel)を設定するのに使用することができる発行者セキュリティドメインを作成する方法であって、前記方法は、
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する段階と、
前記1つ又はそれ以上の共有秘密鍵を使用して、前記個人化アプリケーションサーバから前記ユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成する段階と、
を含む方法。
【請求項2】
前記ユーザ装置は、EMV証明済みチップが埋め込まれたモバイルデバイスを含む、
ことを特徴とする請求項1に記載の方法。
【請求項3】
前記ユーザ装置は、1つ又はそれ以上のEMVアプリケーションを記憶している汎用ICカード(UICC)を更に含むモバイルデバイスを含む、
ことを特徴とする請求項1に記載の方法。
【請求項4】
前記UICCは、前記モバイルデバイスから取り除くことができ、別のモバイルデバイスと共に使用することができる、
ことを特徴とする請求項3に記載の方法。
【請求項5】
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する段階は、汎用認証アーキテクチャ(GAA)に従って行われ、前記個人化アプリケーションサーバは、ネットワークアプリケーション機能(NAF)サーバを含む、
ことを特徴とする請求項1に記載の方法。
【請求項6】
前記1つ又はそれ以上の共有秘密鍵を前記ユーザ装置上に記憶する段階を更に含む、
ことを特徴とする請求項1に記載の方法。
【請求項7】
前記個人化データは、クレジットカード個人化データを含む、
ことを特徴とする請求項1に記載の方法。
【請求項8】
前記個人化データは、公共交通チケット発券データを含む、
ことを特徴とする請求項1に記載の方法。
【請求項9】
第1エンティティから第2エンティティにセキュアな方法で個人化データを無線(OTA)で送信する方法であって、
汎用認証アーキテクチャ(GAA)を使用して前記第1及び前記第2エンティティに既知の1つ又はそれ以上の共有秘密鍵を生成する段階と、
前記1つ又はそれ以上の共有秘密鍵を使用して前記第1と前記第2エンティティとの間に発行者セキュリティドメインを作成する段階と、
前記発行者セキュリティドメインを使用して前記第1と前記第2エンティティとの間にセキュアチャンネルを設定する段階と、
前記セキュアチャンネルを介して前記個人化データを送信する段階と、
を含む方法。
【請求項10】
前記第1エンティティはネットワークアプリケーション機能(NAF)サーバであり、前記第2エンティティはユーザ装置である、
ことを特徴とする請求項9に記載の方法。
【請求項11】
前記ユーザ装置は、EMV証明済みチップが埋め込まれたモバイルデバイスを含む、
ことを特徴とする請求項9に記載の方法。
【請求項12】
前記ユーザ装置は、1つ又はそれ以上のEMVアプリケーションを記憶した汎用ICカード(UICC)を更に含むモバイルデバイスを含む、
ことを特徴とする請求項9に記載の方法。
【請求項13】
前記UICCは、前記モバイルデバイスから取り外すことができ、且つ別のモバイルデバイスと共に使用することができる、
ことを特徴とする請求項12に記載の方法。
【請求項14】
前記個人化データは、クレジットカード個人化データを含む、
ことを特徴とする請求項9に記載の方法。
【請求項15】
前記個人化データは、公共交通チケット発券データを含む、
ことを特徴とする請求項9に記載の方法。
【請求項16】
セキュアチャンネルを介して個人化アプリケーションサーバから個人化データを受信することができるユーザ装置であって、前記ユーザ装置は、
前記ユーザ装置に固有の少なくとも1つの秘密鍵を含むユーザ識別モジュールと、
前記ユーザ識別モジュールと通信するセキュアコア(secure core)と、
を備え、
前記秘密鍵は、前記セキュアコア上に記憶されることになる、前記個人化アプリケーションサーバ及び前記ユーザ装置に既知の1つ又はそれ以上の共有秘密鍵を生成するのに使用され、前記1つ又はそれ以上の共有秘密鍵は、発行者セキュリティドメインを作成するのに使用され、該発行者セキュリティドメインが、前記ユーザ装置が前記個人化データを受信することができる前記セキュアチャンネルを設定するのに使用される、
ことを特徴とするユーザ装置。
【請求項17】
前記1つ又はそれ以上の共有秘密鍵は、汎用認証アーキテクチャ(GAA)に従って生成され、前記個人化アプリケーションサーバは、ネットワークアプリケーション機能(NAF)サーバを含む、
ことを特徴とする請求項16に記載のユーザ装置。
【請求項18】
コンピュータ可読媒体に記憶され、前記ユーザ識別モジュール及び前記セキュアコアと通信する1つ又はそれ以上のGAAサポーティングアプリケーションを更に備え、
前記GAAサポーティングアプリケーションは、前記1つ又はそれ以上の共有秘密鍵を生成するために前記NAFサーバ及びブートストラッピングサーバ機能(BSF)サーバと通信するように構成されている、
ことを特徴とする請求項17に記載のユーザ装置。
【請求項19】
前記個人化データは、クレジットカード個人化データを含む、
ことを特徴とする請求項16に記載のユーザ装置。
【請求項20】
前記個人化データは、公共交通チケット発券データを含む、
ことを特徴とする請求項16に記載のユーザ装置。
【請求項21】
個人化アプリケーションサーバと、
前記個人化アプリケーションサーバから無線(OTA)で個人化データを送信するためのセキュアチャンネルを介して前記個人化アプリケーションサーバと通信するユーザ装置と、
を備え、
前記個人化アプリケーションサーバ及び前記ユーザ装置に既知の1つ又はそれ上の共有秘密鍵が、前記セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するのに使用される、
ことを特徴とするモバイルクレジットカード決済システム。
【請求項22】
前記1つ又はそれ以上の共有秘密鍵が、汎用認証アーキテクチャ(GAA)に従って作成され、前記個人化アプリケーションサーが、ネットワークアプリケーション機能(NAF)サーバを含む、
ことを特徴とする請求項21に記載のシステム。
【請求項23】
前記1つ又はそれ以上の共有秘密鍵が、前記ユーザ装置上に記憶される、
ことを特徴とする請求項21に記載のシステム。
【請求項24】
前記ユーザ装置が、EMV証明済みチップが埋め込まれたモバイルデバイスを含む、
ことを特徴とする請求項21に記載のシステム。
【請求項25】
前記ユーザ装置が、1つ又はそれ以上のEMVアプリケーションが記憶された汎用ICカード(UICC)を更に含むモバイルデバイスを備える、
ことを特徴とする請求項21に記載のシステム。
【請求項26】
前記UICCが、前記モバイルデバイスから取り除くことができ、且つ別のモバイルデバイスと共に使用することができる、
ことを特徴とする請求項25に記載のシステム。
【請求項27】
前記NAFサーバ及び前記ユーザ装置と通信するブートストラッピングサーバ機能(BSF)サーバを更に備え、
前記BSFが、前記1つ又はそれ以上の共有秘密鍵の生成を可能にする、
ことを特徴とする請求項22に記載のシステム。
【請求項28】
個人化アプリケーションサーバからユーザ装置への個人化データの無線(OTA)送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するためのシステムであって、前記システムは、
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する手段と、
前記1つ又はそれ以上の共有秘密鍵を使用して、前記個人化アプリケーションサーバから前記ユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成する手段と、
を含むシステム。
【請求項29】
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する前記手段が、汎用認証アーキテクチャ(GAA)に従って前記1つ又はそれ以上の共有秘密鍵を生成する手段を含み、
前記個人化アプリケーションサーバが、ネットワークアプリケーション機能(NAF)サーバを含む、
ことを特徴とする請求項28に記載のシステム。
【請求項30】
前記ユーザ装置上に前記1つ又はそれ以上の共有秘密鍵を記憶する手段を更に含む、
ことを特徴とする請求項28に記載のシステム。
【請求項31】
個人化アプリケーションサーバからユーザ装置への個人化データの無線(OTA)送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するためのコンピュータプログラム製品であって、前記コンピュータプログラム製品が、コンピュータ可読プログラムコード部分が記憶された少なくとも1つのコンピュータ可読記憶媒体を含み、前記コンピュータ可読プログラムコード部分が、
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成するための第1実行可能部分と、
前記1つ又はそれ以上の共有秘密鍵を使用して、発行者セキュリティドメインを作成するための第2実行可能部分と、
を含み、
前記発行者セキュリティドメインが、前記個人化アプリケーションサーバから前記ユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる、
ことを特徴とするコンピュータプログラム製品。
【請求項32】
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する段階が、汎用認証アーキテクチャ(GAA)に従って前記1つ又はそれ以上の共有秘密鍵を生成する段階を含み、前記個人化アプリケーションサーバが、ネットワークアプリケーション機能(NAF)サーバを含む、
ことを特徴とする請求項31に記載のコンピュータプログラム製品。
【請求項33】
前記ユーザ装置上に前記1つ又はそれ以上の共有秘密鍵を記憶するための第3実行可能部分を更に含む、
ことを特徴とする請求項31に記載のコンピュータプログラム製品。
【請求項34】
セキュアチャンネルを介して個人化アプリケーションサーバから個人化データを受信することができるユーザ装置であって、前記ユーザ装置が、
前記ユーザ装置及び前記個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する手段と、
前記1つ又はそれ以上の共有秘密鍵を前記ユーザ装置に記憶する手段と、
前記1つ又はそれ以上の共有秘密鍵を使用して、発行者セキュリティドメインを作成する手段と、
を備え、
前記発行者セキュリティドメインが、前記ユーザ装置が前記個人化データを受信することができる前記セキュアチャンネルを設定するのに使用することができる、
ことを特徴とするユーザ装置。
【請求項35】
セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバであって、前記個人化アプリケーションサーバが、
プロセッサと、
前記プロセッサによって実行可能なアプリケーションを記憶する前記プロセッサと通信するメモリと、
を備え、
前記アプリケーションが、実行時にセキュリティデータに対するリクエストを受信し、該リクエストに応答して認証チャレンジを送信することができ、前記チャレンジが共有秘密鍵を認証に使用するようにするリクエストを含み、前記アプリケーションが更に、実行時に前記共有秘密鍵を使用して暗号化された応答を受信し、前記応答を検証し、更に検証時に、前記共有秘密鍵を使用してリクエストされた前記セキュリティデータを暗号化して、前記暗号化されたセキュリティデータを送信することができ、前記暗号化されたセキュリティデータは、前記セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するのに使用でき、前記アプリケーションは更に、実行時に前記セキュアチャンネルを介して前記個人化データを送信することができる、
ことを特徴とする個人化アプリケーションサーバ。
【請求項36】
前記個人化アプリケーションサーバが、ネットワークアプリケーション機能(NAF)サーバを含む、
ことを特徴とする請求項35に記載の個人化アプリケーションサーバ。
【請求項37】
前記セキュリティデータは、1つ又はそれ以上の発行者セキュリティドメイン鍵を含む、
ことを特徴とする請求項35に記載の個人化アプリケーションサーバ。
【請求項38】
前記セキュリティデータが更に、前記1つ又はそれ以上の発行者セキュリティドメイン鍵の有効期間及び作成時期を含む、
ことを特徴とする請求項35に記載の個人化アプリケーションサーバ。
【請求項39】
セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバであって、前記個人化アプリケーションサーバが、
セキュリティデータに対するリクエストを受信する手段と、
前記リクエストに応答して、共有秘密鍵を認証に使用する旨のリクエストを含む認証チャレンジを送信する手段と、
前記共有秘密鍵を使用して暗号化された応答を受信する手段と、
前記応答を検証する手段と、
検証時に、前記共有秘密鍵を使用してリクエストされたセキュリティデータを暗号化し、前記セキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するために使用することができる前記暗号化されたセキュリティデータを送信する手段と、
前記セキュアチャンネルを介して前記個人化データを送信する手段と、
を含む個人化アプリケーションサーバ。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7A】
【図7B】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7A】
【図7B】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【公表番号】特表2008−537370(P2008−537370A)
【公表日】平成20年9月11日(2008.9.11)
【国際特許分類】
【出願番号】特願2008−500286(P2008−500286)
【出願日】平成18年3月1日(2006.3.1)
【国際出願番号】PCT/IB2006/000412
【国際公開番号】WO2006/095230
【国際公開日】平成18年9月14日(2006.9.14)
【出願人】(398012616)ノキア コーポレイション (1,359)
【Fターム(参考)】
【公表日】平成20年9月11日(2008.9.11)
【国際特許分類】
【出願日】平成18年3月1日(2006.3.1)
【国際出願番号】PCT/IB2006/000412
【国際公開番号】WO2006/095230
【国際公開日】平成18年9月14日(2006.9.14)
【出願人】(398012616)ノキア コーポレイション (1,359)
【Fターム(参考)】
[ Back to top ]