(57)【要約】  本発明は、低コストなカードリーダとリモートサーバの間の通信に対する、エンドツーエンドのセキュリティの実装に係わる。本発明の目的は、信頼できない通信デバイス（例えばスマートフォンまたはタブレット）を経由して、カードリーダとリモートサーバの間にセキュアなチャネルを確立することにある。このセキュアなチャネルは、カードリーダ内にセキュアな乱数発生器もエントロピソースも存在しない状況で、以下の特徴を提供しながら、幾つかの基本的差分サイドチャネル解析に対し、本質的に耐性を持つものである：−  カードリーダとサーバの相互認証。−  セッションキーに基づくセキュアなチャネル。これにより、正規の取引であっても、過去の取引に関するセキュアなチャネルのキーを再実行することが不可能となるか、あるいは、将来の取引のセッションキーを、カードリーダが事前計算することや、後から再利用することが不可能となる。
2016537887.tif 000002
【特許請求の範囲】
【請求項１】
非セキュアなネットワークを経由する、モバイルデバイスに接続された非セキュアなカードリーダとリモートサーバとの間の取引を安全化するための方法であって、取引の検証ステップが開始されたときに、
セキュアな通信を確立するための要求をモバイルデバイスを通じてリモートサーバへと送信するように、カードリーダを操作し、
予測可能値をインクリメントするようにリモートサーバを操作し、
サーバによって生成されたランダム値およびインクリメントされた予測可能値からセッション暗号化キーおよびセッション完全性キーを導出するように、リモートサーバを操作し、
モバイルデバイスを通じてカードリーダへと認証要求を送信するように、リモートサーバを操作し、このとき、この認証要求が、ランダム値と、セッション完全性キーおよびランダム値の少なくとも一部分から計算されたＭａｃ値とを含み、
現在の予測可能値をインクリメントし、受信したランダム値およびインクリメントされた現在の予測可能値からセッション暗号化キーおよびセッション完全性キーを計算するように、カードリーダを操作し、
計算されたセッション完全性キーおよび受信したランダム値からＭａｃ値を計算し、計算されたＭａｃ値を受信したＭａｃ値と比較することによりリモートサーバを認証するように、カードリーダを操作し、
リモートサーバの認証に成功した場合、カードリーダを、カードリーダのデータベース内にあるインクリメントされた現在の予測可能値でカードリーダの現在の予測可能値を更新するように操作し、
モバイルデバイスを通じてリモートサーバへと認証要求を送信するように、カードリーダを操作し、このとき、この認証要求が、更新された現在の予測可能値と、セッション完全性キーおよび更新された現在の予測可能値の少なくとも一部分から計算されたＭａｃ値とを含み、
計算されたセッション完全性キーおよび受信した更新された現在の予測可能値からＭａｃ値を計算し、計算されたＭａｃ値を受信したＭａｃ値と比較することによりカードリーダを認証するように、リモートサーバを操作し、
リモートサーバの認証に成功した場合、カードリーダとリモートサーバの間にセキュアなセッションチャネルがセットアップされ、セッション暗号化キーおよびセッション完全性キーが、カードリーダとリモートサーバの間で交換されるメッセージの機密性および完全性を保護する、方法。
【請求項２】
リモートサーバおよびカードリーダの認証に成功した場合、
セキュアなセッションチャネルを介して、カードリーダに接続されたスマートカードへとコマンドを送信するように、リモートサーバを操作し、
セキュアなチャネルを介して、カードリーダ経由でスマートカードからコマンド応答を受信するように、リモートサーバを操作する、請求項１に記載の方法。
【請求項３】
モバイルデバイスを通じてリモートサーバへとカードリーダによって送信された、セキュアな通信を確立するための要求が、カードリーダの識別子を含む、請求項１または２に記載の方法。
【請求項４】
セッション暗号化キーおよびセッション完全性キーが、リーダマスタキー、サーバによって生成されたランダム値、カードリーダの識別子、およびインクリメントされた予測可能値から導出される、請求項３に記載の方法。
【請求項５】
予測可能値が、カードリーダのカウンタによって生成される、請求項１から４のいずれか一項に記載の方法。
【請求項６】
サーバによってインクリメントされた予測可能値が、
リモートサーバへと送信されたセキュアな通信を確立するための要求にカードリーダの現在の更新された予測可能値を追加するカードリーダ、または、
サーバのシーケンス番号カウンタによって提供される、請求項１から５のいずれか一項に記載の方法。
【請求項７】
サーバによるカードリーダの認証が、
カードリーダ認証要求に含まれる更新予測可能値がリモートサーバのインクリメントされた予測可能値と一致するかどうかをチェックするように、リモートサーバを操作するステップと、
検証に成功した場合、前記カードリーダを認証するためのカードリーダ認証要求に含まれるＭＡＣ値を検証するように、リモートサーバを操作するステップとを含む、請求項１から６のいずれか一項に記載の方法。
【請求項８】
ランダム値が３バイト長である、請求項１から７のいずれか一項に記載の方法。
【請求項９】
更新された予測可能値が所定の最大予測可能値に達した場合、新たな所定の最大値が定義されるまで、カードリーダがロックされるか、スタンバイ状態となる、請求項１から８のいずれか一項に記載の方法。
【請求項１０】
カードリーダによるサーバの認証に失敗した場合、カードリーダの無効化カウンタをインクリメントし、
無効化カウンタ値が所定の最大エラーに達した場合、カードリーダがそれ自体を非アクティブ化する、請求項１から９のいずれか一項に記載の方法。
【請求項１１】
セキュアなチャネルの確立後に、
無効な着信メッセージを受信したときにカードリーダのエラーカウンタをインクリメントし、
エラーカウンタ値が所定の最大エラーに達した場合、カードリーダが取引検証ステップのセッションを終了し、
取引検証ステップセッションが完了し、エラーカウンタ値が所定の最大エラーを下回っている場合、エラーカウンタがクリアされる、請求項１から１０のいずれか一項に記載の方法。
【請求項１２】
カードリーダの識別子が、カードリーダごとに一意のシリアル番号である、請求項１から１１のいずれか一項に記載の方法。
【請求項１３】
セッション暗号化キーおよびセッション完全性キーが、取引セッションごとに一意となる４つの対称キー、即ち、
カードリーダに接続されたスマートカードに対するコマンドを暗号化するためにサーバによって使用され、コマンドを復号するためにカードリーダによって使用される、送信暗号化キーＴＥＮＣと、
コマンドからＭＡＣ値を計算するためにサーバによって使用され、受信したＭＡＣ値をチェックするためにカードリーダによって使用される、送信完全性キーＴＭＡＣと、
コマンドの応答を暗号化するためにカードリーダによって使用され、受信した応答を復号するためにサーバによって使用される、受信暗号化キーＲＥＮＣと、
コマンド応答からＭＡＣ値を計算するためにカードリーダによって使用され、受信したＭＡＣ値をチェックするためにサーバによって使用される、受信完全性キーＲＭＡＣとを含む、請求項１から１２のいずれか一項に記載の方法。
【請求項１４】
非セキュアなネットワークを経由する、モバイルデバイスに接続された非セキュアなカードリーダとリモートサーバとの間の取引を安全化するためのシステムであって、
セキュアな通信を確立するための要求をモバイルデバイスを通じてリモートサーバへと送信するように、カードリーダを操作し、
請求項１から１３のいずれか一項に記載のリモートサーバを認証するように、カードリーダを操作し、
請求項１から１３のいずれか一項に記載のカードリーダを認証するように、リモートサーバを操作し、
相互認証に成功した場合、請求項１から１３のいずれか一項に従って、カードリーダとリモートサーバの間にセキュアなセッションチャネルがセットアップされ、セッション暗号化キーおよびセッション完全性キーが、カードリーダとリモートサーバの間で交換されるメッセージの機密性および完全性を保護する、システム。
【請求項１５】
リモートサーバおよびカードリーダの認証に成功した場合、
セキュアなセッションチャネルを介して、カードリーダに接続されたスマートカードへとコマンドを送信するように、リモートサーバを操作し、
セキュアなチャネルを介して、カードリーダ経由でスマートカードからコマンド応答を受信するように、リモートサーバを操作する、請求項１４に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概して、接続端末を介したカードリーダデバイスとリモートサーバの間の通信を安全（セキュア）化するためのシステムおよび方法に関する。
【０００２】
詳細には、本発明は、端末に接続されたカード決済用リーダとリモートサーバとの間で非セキュアなネットワークを経由して行われる取引決済に対し、エンドツーエンドでセキュアなチャネルを確立するためのシステムおよび方法に関する。
【背景技術】
【０００３】
様々な種類の商取引を円滑化するため、よく知られている決済カードは、全世界で何百万もの人々によって使用されている。販売業者の下での、製品またはサービスの購入を伴う通常の取引では、販売業者の営業所に設置された販売時点情報管理端末（「ＰＯＳ端末」）に、決済カードを提示する。ＰＯＳ端末は、決済カードに格納されたデータにアクセス可能な、カードリーダや類似のデバイスであり得る。このデータには、識別および認証データが含まれている。決済カードから読み取られたデータは、販売業者の取引処理システムへと提供され、その後、アクワイアラ（通例、販売業者の口座を管理する銀行またはその他の機関となる）へと提供される。
【０００４】
チップベースの決済カードに関するセキュリティおよびグローバルな相互運用性を確実にするために、ＥＭＶ規格がよく知られている。この規格は、ＥＭＶ対応決済カードとＥＭＶ対応ＰＯＳ端末の相互作用について定義している。よって、ＥＭＶ決済を受け付けるためには、販売業者がＥＭＶ対応ＰＯＳ端末を配備する必要がある。こうしたＥＭＶ対応ＰＯＳ端末のハードウェアを配備し整備することは、販売業者にとって相当なコストとなる。
【０００５】
現在では、科学技術が消費者の購入手段に革命をもたらし、小売ルートの範囲を拡大させている。実際、携帯電話などのモバイルデバイスが日常生活で果たす役割は、ますます多方面にわたるものとなってきている。音声とメッセージの送信という、従来の役割を越えた所まで携帯電話を発展させようという試みの中、多くの新しい機能やサービスが今も開発されている。
【０００６】
しかし、決済カードは、電子商取引を行うため最高のセキュリティを提供するにもかかわらず、オンライン市場では採用されていない。その主な理由は、カードリーダが高コストであること、そして多くの人々にとって、システムが複雑だからである。この市場の基盤を形成する数百万人の潜在的エンドユーザに対し、カードのみならず、リーダも提供しなくてはならない。
【０００７】
決済カードがオンライン市場によって採用されるように、低コストなカードリーダデバイスが開発されてきた。低コストなカードリーダデバイスは、モバイルデバイスに接続可能なインタフェースを備えている。この種のカードリーダは、セキュアな乱数発生器、即ちエントロピソースを持たない。更に、こうした実装形態では、サイドチャネル攻撃に対する高度な防護手段が組み込まれていない可能性が高い。この非セキュアで低コストなカードリーダは、電子商取引の処理に必要なセキュリティを提供しない。
【０００８】
この種のカードリーダについて言えば、安全な取引を行うために、より速く、より安価で、セキュアかつ一層便利な低コストカードリーダへの要求が高まっていることは明白である。
【０００９】
安価で扱い易く、持ち運びも可能というような、店舗内、インターネット上、および対面での安全なクレジットカード決済を実現する必要性が存在している。
【発明の概要】
【課題を解決するための手段】
【００１０】
本発明に関する以下の概要は、本発明の幾つかの態様および機能についての基本的認識を提供するために設けられる。この概要は、本発明の大規模な全体像ではなく、したがって、本発明にとって重要または不可欠な要素を詳細に特定するものでも、本発明の範囲を明確化するものでもない。その唯一の目的は、以下に示すより詳細な説明の前置として、本発明の幾つかの概念を、簡略化した形式で提示することにある。
【００１１】
本発明は、低コストなカードリーダを用いた取引に関する上述のセキュリティ面での欠点に対処する。本発明は、非セキュアなネットワーク上での取引中、モバイルデバイスを介した、カードリーダとリモートサーバの間のデータ送信を保護するための、システムおよび方法に関する。
【００１２】
本発明は、低コストなカードリーダとリモートサーバの間の通信に対する、エンドツーエンドのセキュリティの実装に係わるものである。本発明の目的は、信頼できない通信デバイス（例えばスマートフォンまたはタブレット）を経由して、カードリーダとリモートサーバの間にセキュアなチャネルを確立することにある。このセキュアなチャネルは、カードリーダ内にセキュアな乱数発生器もエントロピソースも存在しない状況で、以下の特徴を提供しながら、幾つかの基本的差分サイドチャネル解析に対する耐性を本質的に持つものである：
−  カードリーダとサーバの相互認証
−  セッションキーに基づくセキュアなチャネル。これにより、正規の取引であっても、過去の取引に関するセキュアなチャネルのキーを再実行することが不可能となるか、あるいは、将来の取引のセッションキーを、カードリーダが事前計算することや、後から再利用することが不可能となる。
【００１３】
本発明は、単純電磁波解析（ＳＥＭＡ）や単純電力解析（ＳＰＡ）などの攻撃の緩和を試みるものではない。そのような緩和技術は、ハードウェアに強く依存する。
【００１４】
代わりに、本発明は、差分電磁波解析（ＤＥＭＡ）、相関電磁波解析（ＣＥＭＡ）、差分電力解析（ＤＰＡ）、相関電力解析（ＣＰＡ）などの差分攻撃の実行可能性を緩和することのみを意図している。
【００１５】
本発明を使用すると、暗号計算の管理がカードリーダ内のものとなり、一方、サーバは必ずしも関与しない。それどころか、攻撃者が電磁波または電力測定値を十分に入手するためには、正規取引の使用が強制されるということにより、第一に攻撃時間が増加するはずであり、第二に攻撃者はサーバ側で（ある程度は）検出可能となる。
【００１６】
本発明は、「電話などの」モバイルデバイスを介したあらゆる取引を（たとえオンライン取引であったとしても）安全化するカードリーダを使用するための、安価で簡易な方法を提供する。例えば、銀行口座の管理、決済の実行、ゆくゆくはオンライン投票などの際に、カードリーダとリモートサーは、双方を認証する。
【００１７】
本発明は、カードリーダとリモートサーバの間で転送されるデータを安全化する方法を提案する。これに関して、本発明は、転送されるデータを暗号化する方法を提案する。加えて、本発明は、転送されるデータの発信元／完全性を検証する方法を提案する。
【００１８】
本発明に関する実施形態の態様は、全体として、カードリーダとリモートサーバの間でセキュアなチャネルをどのようにセットアップするか、それがどのように動作するか、そして必要なデータおよび暗号化アルゴリズムは何であるかを定義する方法に関する。本発明は、モバイルデバイスに接続されたカードリーダを用いたセキュアな取引を行うための、セキュアで簡単かつ効率的なプロトコルを定義する。
【００１９】
本発明の様々な方法では、パーソナライゼーション／登録フェーズの間、以下のステップを実行することができる：
−  リーダキーＲＫを生成し、前記カードリーダにパーソナライズすることができる。リーダキーはカードリーダごとに一意である。このカードキーはサーバによって取得可能である。
−  各カードリーダは、一意のシリアル番号ＳＮでパーソナライズされている。このシリアル番号を、サーバのデータベース内へのリーダキーに関連付ける。
−  各カードリーダは、例えばデバイス取引カウンタ（ＤＴＣ）など、カウンタを備えている。サーバの認証が成功する度に、このカウンタをインクリメントする。
【００２０】
本発明は、通信において正規サーバが必ずしも関与しない、カードリーダとの間で送受信可能な全てのコマンド／応答の保護に主眼を置くものである。
【００２１】
本発明は、感知可能なＳｅｓｓｉｏｎ−Ｓｅｔｕｐコマンドを保護する方法を提案する。というのも、このコマンドは、攻撃者が正規サーバの関与なしに、暗号計算におけるリーダマスタキーを無理矢理使用することを可能にし得る、唯一のコマンドだからである。このコマンドを使用すると、カードリーダは、ランダム値Ｓｅｒｖｅｒ−ＲＮＤ、および値Ｓｅｒｖｅｒ−ＲＮＤを含む、所定フォーマットメッセージのメッセージ認証コード（ＭＡＣ）を入力に持つ。一例として、所定のメッセージは、以下のようなものとなり得る：
Ｍｅｓｓａｇｅ＝ＣｏｎｓｔａｎｔＶａｌｕｅ｜｜ｒａｎｄｏｍ  ｖａｌｕｅ（ランダム値）  Ｓｅｒｖｅｒ−ＲＮＤ
【００２２】
カードリーダによるＭＡＣの検証には、第一に、ＭＡＣ検証用セッションキーの計算が必要となる。
【００２３】
本発明は、全体として、暗号化セッションキーおよび完全性セッションキーを生成する方法に関する。セッションキーは、秘密リーダキーと多様化データを用いて計算される。多様化データは、正規サーバ（または攻撃者）によって選択されたランダム値Ｓｅｒｖｅｒ−ＲＮＤと、カードリーダの制御下にある予測可能値（カウンタＤＴＣ）とを含む。リーダキーは、マスタキーおよびカードリーダのシリアル番号ＳＮから導出される。
【００２４】
正規サーバ（または攻撃者）によって選択されたランダム値は、サーバに対し、現在のセキュアチャネルセッションが事前計算されておらず、正規カードリーダが実際にチャネルの他端に存在するということの保証を与えるのに役立つ。このランダム値のサイズは特別大きいものとする必要はなく、数ビットでも十分である。ランダム値Ｓｅｒｖｅｒ−ＲＮＤのサイズは、エラー管理と、受け入れ可能とみなされる許容レベルとに基づいて設定されることが好ましい。ランダム値のサイズは、例えばＤＥＭＡやＤＰＡを用いて、ＭＡＣ検証セッションキーを再生しようとする攻撃者の適応性の上限程度にまで小さいものとすることができる。
【００２５】
ＤＴＣの値は、カードリーダの単独制御下にある。ＤＴＣ値はセッションキー導出機能に関与するものであり、この値は、カードリーダによるＭＡＣ検証が成功し、サーバの認証を可能となった後にのみ更新される。ＤＴＣの一意性は、本発明において重要なものである。というのも、ＤＴＣの一意性が、セッションキーがセキュアチャネルセッションごとに一意となることの保証だからである。ＤＴＣのサイズは、製品の耐用年数全体を通じて有効とするのに十分な大きさであることが好ましい。一例として、取引の最大数を２３２で上限としなければならない場合、４バイトのＤＴＣ値は適切なものとなる。
【００２６】
その場合、サーバの関与なしに、攻撃者は有効なＭＡＣの偽造に成功することはなく（ＭＡＣアルゴリズムが暗号学的にセキュアであると仮定する）、多様化アルゴリズムのメッセージ入力における攻撃者の適応性は、ランダム値Ｓｅｒｖｅｒ−ＲＮＤのサイズによってのみ決定される。
【００２７】
多様化データのフォーマットおよびランダム値Ｓｅｒｖｅｒ−ＲＮＤのサイズは、セッションキー導出機能の仕様を考慮して設定されなくてはならない。本発明の主な利点の１つは、サーバ／攻撃者によって選択されたランダム性と、カードリーダの単独制御下にあるセッション単位の一意の値との両方を関与させる、シングルステップキー導出を、２ステップキー導出（つまり、カードリーダの単独制御下にあるセッション単位の一意の値を関与させる１ステップと、サーバ／攻撃者によって選択されたランダム値を使用するための、もう１つの追加ステップ）の代わりに使用するということにある。
【００２８】
ＭＡＣの検証フェーズ中、およびＤＴＣをインクリメントするステップの間、攻撃者の標的は、ＭＡＣ検証セッションキーとなる。ランダム値Ｓｅｒｖｅｒ−ＲＮＤのサイズおよび所定のメッセージのフォーマットは、攻撃者の適応性（即ち、メッセージのサイズ、定数のサイズ、ランダム値Ｓｅｒｖｅｒ−ＲＮＤの限定化）を制限するための手段である。ＭＡＣによって検証されるメッセージのフォーマットは、ＭＡＣアルゴリズムの仕様を考慮して設定することが好ましい。
【００２９】
本発明のこうしたシステムおよび方法は、セキュアな通信チャネル向けに効率的手段を提供することにより、カードリーダとサーバの間で転送される情報のセキュリティを向上させる。
【００３０】
これらの、およびその他の利点を達成するため、具体化され広く説明される本発明の趣旨に従えば、本発明は、非セキュアなネットワークを経由する、モバイルデバイスに接続された非セキュアなカードリーダとリモートサーバとの間の取引を、安全化するための方法を提供するものであり、取引の検証ステップが開始されたときに、以下の動作がなされる：
−  セキュアな通信を確立するための要求をモバイルデバイスを通じてリモートサーバへと送信するように、カードリーダを操作する。
−  予測可能値をインクリメントするようにリモートサーバを操作する。
−  サーバによって生成されたランダム値およびインクリメントされた予測可能値からセッション暗号化キーおよびセッション完全性キーを導出するように、リモートサーバを操作する。
−  モバイルデバイスを通じてカードリーダへと認証要求を送信するように、リモートサーバを操作する。このとき、この認証要求が、ランダム値と、セッション完全性キーおよびランダム値の少なくとも一部分から計算されたＭａｃ値とを含む。
−  現在の予測可能値をインクリメントし、受信したランダム値およびインクリメントされた現在の予測可能値からセッション暗号化キーおよびセッション完全性キーを計算するように、カードリーダを操作する。
−  計算されたセッション完全性キーおよび受信したランダム値からＭａｃ値を計算し、計算されたＭａｃ値を受信したＭａｃ値と比較することによりリモートサーバを認証するように、カードリーダを操作する。
−  リモートサーバの認証に成功した場合、カードリーダを、カードリーダのデータベース内にあるインクリメントされた現在の予測可能値で、現在の予測可能値を更新するように操作する。
−  モバイルデバイスを通じてリモートサーバへと認証要求を送信するように、カードリーダを操作する。このとき、この認証要求が、更新された現在の予測可能値と、セッション完全性キーおよび更新された現在の予測可能値の少なくとも一部分から計算されたＭａｃ値とを含む。
−  計算されたセッション完全性キーおよび受信した更新された現在の予測可能値からＭａｃ値を計算し、計算されたＭａｃ値を受信したＭａｃ値と比較することによりカードリーダを認証するように、リモートサーバを操作する。
−  リモートサーバの認証に成功した場合、カードリーダとリモートサーバの間にセキュアなセッションチャネルをセットアップし、セッション暗号化キーおよびセッション完全性キーが、カードリーダとリモートサーバの間で交換されるメッセージの機密性および完全性を保護する。
−  セキュアなセッションチャネルを介して、カードリーダに接続されたスマートカードへとコマンドを送信するように、リモートサーバを操作する。
−  セキュアなチャネルを介して、カードリーダ経由でスマートカードからコマンド応答を受信するように、リモートサーバを操作する。
【００３１】
本発明は、モバイルデバイスに接続された非セキュアなカードリーダとリモートサーバとの間の取引を安全化するための方法に関するものであり、取引が開始されたときに、以下の動作がなされる：
−  セッション暗号化キーおよびセッション完全性を、リーダキーおよび多様化データから導出する。このとき、前記多様化データが、サーバによって生成されたランダム値と、カードリーダによって生成された更新された予測可能値とを含む。
−  カードリーダによるサーバの認証に成功した場合、予測可能値を更新する。
−  サーバによるカードリーダの認証に成功した場合、カードリーダとサーバの間にセキュアなセッションチャネルをセットアップし、セッション暗号化キーおよびセッション完全性キーが、カードリーダとサーバの間で交換されるメッセージの機密性および完全性を保護する。
−  セキュアなセッションチャネルを介して、カードリーダに接続されたスマートカードへと、サーバからのコマンドを送信する。
−  セキュアなチャネルを介して、カードリーダ経由で、スマートカードからサーバへのコマンド応答を受信する。
【００３２】
他の様々な方法では、リーダキーは、マスタキーおよびカードリーダの識別子から導出される。カードリーダの識別子は、カードリーダごとに一意のシリアル番号となる。
【００３３】
他の様々な方法では、サーバによるセッションキーを導出することは、以下のステップを含む：
−  セキュアなチャネルを確立するための要求を、モバイルデバイスを通じて、カードリーダからサーバへと送信するステップであって、前記要求が、現在の更新された予測可能値と、カードリーダ識別子とを含む、送信するステップ。
−  受信した予測可能値をインクリメントするステップ。
−  ランダム値を生成するステップ。
−  サーバが、格納したリーダマスタキー、受信したカードリーダ識別子、生成されたランダム値、およびインクリメントされた受信予測可能値から、セッション暗号化キーおよびセッション完全性キーを導出するステップ。
【００３４】
他の様々な方法では、カードリーダによるサーバの認証ステップは、以下のステップを含む：
−  セッション完全性キーと、生成されたランダム値の内容の少なくとも一部分とから、ＭＡＣ署名値を計算するステップ。
−  認証要求を、モバイルデバイスを通じて、サーバからカードリーダへと送信するステップであって、前記要求が、生成されたランダム値と、計算されたＭＡＣ値とを含む、送信するステップ。
−  カードリーダが認証要求を受信した際に、最後に更新された予測可能値をインクリメントするステップ。
−  カードリーダが、リーダマスタキー、カードリーダ識別子、受信したランダム値、およびインクリメントされた最後に更新された予測可能値から、セッション暗号化キーおよびセッション完全性キーを導出するステップ。
−  受信したＭＡＣ値の検証に成功した場合、サーバが、カードリーダによって認証されるステップ。
【００３５】
他の様々な方法では、サーバの認証に成功した場合、現在の予測可能値が、インクリメントされた値で更新される。更新された予測可能値は、カードリーダのデータベース、またはカードリーダのセキュアエレメントに格納される。更新された予測可能値が所定の最大予測可能値に達した場合、カードリーダは、新たな所定の最大値が定義されるまでロックされるか、スタンバイ状態となる。
【００３６】
他の様々な方法では、サーバによるカードリーダの認証ステップは、以下のステップを含む：
−  セッション完全性キーと、更新された予測可能値の少なくとも一部分とから、ＭＡＣ署名値を計算するステップ。
−  認証要求を、モバイルデバイスを通じて、カードリーダからサーバへと送信するステップであって、前記要求が、更新された予測可能値と、計算されたＭＡＣ値とを含む、送信するステップ。
−  受信したＭＡＣ値の検証に成功した場合、カードリーダが、サーバによって認証されるステップ。
【００３７】
他の様々な方法では、サーバの認証要求がカードリーダに送信されたときに、サーバのシーケンス番号カウンタが逐次インクリメントされる。サーバがカードリーダによって認証されたとき、カードリーダのシーケンス番号カウンタが逐次インクリメントされる。サーバによるカードリーダの認証要求は、カードリーダの現在のシーケンス番号値を含む。認証要求を受信すると、サーバは、受信したシーケンス番号値が、サーバのシーケンス番号カウンタの値と一致するかどうかをチェックする。検証に成功した場合、受信したＭＡＣ値を検証して、カードリーダを認証する。
【００３８】
他の様々な方法では、カードリーダによるサーバの認証に失敗した場合、カードリーダの無効化カウンタがインクリメントされる。無効化カウンタ値が所定の最大エラーに達した場合、カードリーダがそれ自体を非アクティブ化する。
【００３９】
他の様々な方法では、カードリーダとリモートサーバの間にセキュアなチャネルを確立した後、無効な着信メッセージの受信時にカードリーダのエラーカウンタがインクリメントされる。エラーカウンタ値が所定の最大エラーに達した場合、カードリーダが取引検証ステップのセッションを終了する。取引検証ステップセッションが完了し、エラーカウンタ値が所定の最大エラーを下回っている場合、エラーカウンタがクリアされる。
【００４０】
他の様々な方法では、サーバによるカードリーダの認証は、以下のステップを含む：
−  カードリーダ認証要求に含まれる更新予測可能値が、リモートサーバのインクリメントされた予測可能値と一致するかどうかをチェックするように、リモートサーバを操作するステップ。
−  検証に成功した場合、前記カードリーダを認証するために、カードリーダ認証要求に含まれるＭＡＣ値を検証する。
【００４１】
他の様々な方法では、セッション暗号化キーおよびセッション完全性キーは、取引セッションごとに一意となる、以下の４つの対称キーを含む。
−  送信暗号化キーＴＥＮＣ。カードリーダに接続されたスマートカードに対するコマンドを暗号化するためにサーバによって使用され、コマンドを復号するためにカードリーダによって使用される。
−  送信完全性キーＴＭＡＣ。コマンドからＭＡＣ値を計算するためにサーバによって使用され、受信したＭＡＣ値をチェックするためにカードリーダによって使用される。
−  受信暗号化キーＲＥＮＣ。コマンドの応答を暗号化するためにカードリーダによって使用され、受信した応答を復号するためにサーバによって使用される。
−  受信完全性キーＲＭＡＣ。コマンド応答からＭＡＣ値を計算するためにカードリーダによって使用され、受信したＭＡＣ値をチェックするためにサーバによって使用される。
【００４２】
本発明はまた、モバイルデバイスに接続された非セキュアなカードリーダと、リモートサーバとを含む、取引検証処理システムに関するものでもあり、カードリーダに接続されたスマートカードとリモートサーバとの間における取引検証メッセージ送信が、本発明によって安全化される。
【００４３】
本発明の方法は、多くの技術的利点を有しており、とりわけ、低コストなカードリーダの継続使用、セッションキー生成の単純性、および送信データの強力な保護が挙げられる。
【００４４】
以下の詳細な説明は、図面を用いることにより、よりよく理解されよう。
【図面の簡単な説明】
【００４５】
【図１】モバイルデバイスに接続されたカードリーダとリモートサーバとの間で、非セキュアなネットワークを経由して行われる取引を安全化する処理に関与する、様々なエンティティを示す図である。
【図２】本発明の例示的実施形態による、キー生成のセットアップフェーズ中の論理フロー図である。
【図３】本発明の例示的実施形態による、カードリーダとリモートサーバの間にセキュアなチャネルを確立しているときの取引フロー図である。
【発明を実施するための形態】
【００４６】
本発明は、特定のハードウェアまたはソフトウェアでの実装に指定されるものではなく、実装形態の細目を超えた、概念レベルに属するものである。本発明に関する他の様々な実施形態および変形例が、本発明の趣旨または範囲から逸脱することなく製作可能であるということを理解されたい。以下は、本発明の特定の実施形態について、その実践的な実装形態の理解を援助するために設けられる。
【００４７】
異なる図面であっても、同一の要素には同一の参照番号が割り当てられている。明瞭なものとするために、本発明の理解に有用な要素およびステップのみが図面に示され、説明されることになる。
【００４８】
また、本発明はやはり、一般的な機構に対応するものであって、当事者間のデータ通信が持つ機構およびその環境については、どちらも詳らかにはしない。
【００４９】
更に、本明細書に含まれる諸図面に示した接続線は、様々な要素間における、例示としての機能的関係および／または物理的結合を表すためのものである。実際のシステムには、多数の代替物、または追加の機能的関係や物理的結合が存在し得るということに留意されたい。更に、図１の様々なエンティは、適当な通信媒体（インターネットを含む）を介して、適当な通信プロトコルを用いて通信することができる。
【００５０】
更に、ある動作がデバイスによって実行されると述べる場合、その動作は実際には、このデバイス内部のマイクロプロセッサによって実行されるのであり、このマイクロプロセッサは、前記デバイスのプログラムメモリに記録された、命令コードによって制御されている。動作は、アプリケーションまたはソフトウェアに基づくものでもある。これは、アプリケーションまたはソフトウェアを構成する命令コード部分が、マイクロプロセッサによって実行されるということを意味している。
【００５１】
本明細書の全体を通じて、「実施形態」または「別の実施形態」に対する言及では、ある実施形態に関連して説明された特定の機能、構造、または特徴が、開示する主題の少なくとも１つの実施形態に含まれるということが意味される。したがって、本明細書全体の様々な箇所に見られる「ある実施形態では」または「別の実施形態では」という表現は、必ずしも同一の実施形態について言及しているものではない。更に、こうした特定の機能、構造、または特徴は、１つ以上の実施形態において、あらゆる好適な方法で組み合わされてよい。
【００５２】
図１は、カードリーダを用いたモバイル取引の安全化に関するフロー図が内包する、エンティティについて示したものである。解説を簡略化するため、図１には各エンティティがそれぞれ１つだけ示されている。図１は、モバイルデバイスとサーバが実装されるシステムの例を表している。
【００５３】
本発明の実施形態は、携帯電話などのモバイル通信デバイスを用いて例証される。但し、本発明は、ワイヤードおよび／またはワイヤレス無線通信機能を有する電子デバイスに、等しく適用可能なものであることを理解されたい。そのようなデバイスとしては、例えば、あらゆる種類の携帯電話、ラップトップ（標準的なもの、超小型軽量のもの、ネットブック、マイクロラップトップ、パッド、など）、ハンドヘルドコンピュータ、ＰＤＡ、ゲーム機、携帯電話の付属品、などが挙げられる。但し、明瞭かつ簡略なものとするため、本明細書で概説される実施形態は、携帯電話のみを例示し、また携帯電話のみに関するものとなる。
【００５４】
携帯電話１０は、通常、プロセッサ、メモリ、入力デバイス、出力デバイス、および適当な通信スキームを備え、これらの全てがプロセッサへと動作可能に結合されている。モバイルデバイス１０は、ディスプレイエリア１１と、ディスプレイエリア１１内に表示される項目をナビゲートし、テキストや数字を携帯電話に入力するための手段１２とを備えている。ディスプレイエリア１１（タッチセンシティブであることが好ましい）は、１つ以上のステータス表示エリアおよび／またはソフトキーバーを含むことができる。ディスプレイエリア１１、およびそこに表示される項目は、ナビゲーション手段１２を使用するか、ペン型の物体または指でタップすることにより、操作が可能なものとすることができる。携帯電話１０は、外部ユニット用の通信インタフェース１３も備え得る。スタンドアロンのデバイスとして、この携帯電話は、安全な取引という観点からは、非セキュアであり安全な取引を行うには適さないものに分類される。よって、携帯電話それ自体では、安全な取引をするために用いることはできない。
【００５５】
カードリーダデバイス１４は、携帯電話１０などの別のデバイスに、好ましくは自由なトランスポートプロトコルを通じて接続するための、インタフェース１５を備えている。インタフェース１５は、モバイル通信およびコンピュータ業界で使用される、一般的な通信インタフェース（例えば、ＵＳＢコネクタやオーディオコネクタなど）とすることも、または本発明の実施形態と併用される、特殊なインタフェースとすることもできる。カードリーダデバイス１４は、カードリーダデバイスの通信インタフェース１５を用いて、携帯電話１０とワイヤレスに、または直接に接続することができる。カードリーダは、通信インタフェース１３に対応する携帯電話に対し、物理的なプラグ接続が可能であるかまたは、携帯電話１０の通信インタフェース１３とカードリーダデバイス１４の通信インタフェース１５との間のアダプタを介して接続されることも可能である。幾つかの異なる実施形態では、このカードリーダデバイスは、ワイヤを使用して携帯電話１０に接続されてもよい。
【００５６】
別の実施形態では、カードリーダ１４は、適当な通信スキームを用いて携帯電話１０と通信することが可能な、非接触インタフェースを備えている。非接触インタフェースとは、近距離無線通信（ＮＦＣ）トランシーバ、非接触リーダ、または無給電ＲＦＩＤのことを指し得る。カードリーダ１４の非接触インタフェースは、携帯電話１０との非接触通信チャネルを確立して、近距離無線通信（ＮＦＣ）機能などの短距離通信方法を使用することにより、データを交換する。こうしたＮＦＣ技術、または類似する短距離通信技術の例としては、ＩＳＯ標準１４４４３、ＲＦＩＤ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、および赤外線通信方法が挙げられる。
【００５７】
ある実施例では、非接触通信チャネルとは、通信するデバイスを「タップ」する（つまり、非接触インタフェース同士を数センチ以内に近づける）必要がある、ＮＦＣ技術を用いた情報交換のことを指し得る。
【００５８】
本明細書に記述する実施形態では、カードリーダ１４のインタフェース１５は、モバイルデバイス１０のインタフェース１３に接続されたオーディオコネクタであり、オーディオ信号を用いる通信を確立してデータを交換する。
【００５９】
カードリーダデバイス１４は、スマートカードリーダスロット１６を備えることができ、ここにスマートカード１７を十分に（完全に）、または部分的に（一部分のみを）挿入することが可能である。異なる実施形態では、カードリーダデバイス４は、リーダスリットを有する一般的な磁気ストライプリーダを備えることもできる。このリーダスリットにカードを通して読み取ることができる。カードリーダ１４は、セキュアなカードリーダデバイスよりも遥かに安価で製造される、非セキュアなカードリーダデバイスに分類されるものであってよい。
【００６０】
スマートカード１７は、セキュアエレメント１８を備えている。セキュアエレメント１８は、高度なセキュリティを要求するデータやアプリケーションをホストし格納するために使用される。スマートカード１７は、セキュアエレメントのイシュアによってユーザに提供される。セキュアエレメントのイシュアは、必ずしも取引処理またはサーバ１９と同一のエンティティに関係した成員でなくても構わない。スマートカード１７は、自由なトランスポートプロトコルを通じて、カードリーダ１４に接続することができる。通常、この自由なトランスポートプロトコルは、ＩＳＯ−７８１６  １および３のプロトコルとすることができる。
【００６１】
携帯電話１０は、モバイル取引アプリケーション２０を通じて、カードリーダ１４と相互作用する。モバイル取引アプリケーションとは、携帯電話１０の内部で実装される取引機能を提供するアプリケーションである。例えば、モバイル取引アプリケーション２０は、取引の間、ネットワーク２１を介してサーバ１９と相互作用することができ、それによって、携帯電話を用いた取引が可能となる。ある実施形態では、モバイル取引アプリケーションを発行するエンティティは、カードリーダ１４の製造元や、サーバ１９と同一のエンティティとすることができるが、この取引処理に係わる成員でなくとも構わない。サーバ１９は、ネットワーク２１を通じ、携帯電話１０のモバイル取引アプリケーション２０を介して、カードリーダ１４と通信する。
【００６２】
「取引」という表現は、その最も広範な意味で解釈されてよい。「取引」とは、金銭上の取引に限定されてはならず、あらゆるインターネット取引、即ち、通信ネットワークなどを通じて発生する、あらゆる取引もその範囲に含むことができる。「取引」という用語は、決済要求、注文要求、株式移転、予算移替、ＩＤ要求の立証、情報開示要求、またはこれらの行為の組合せというような、様々な行為を広く対象とすることが意図されている。また、こうした行為は、様々な方法で開始することができる。例えば決済要求であれば、実際の店舗におけるクレジットカード取引、電子商取引ウェブサイトでの購入（ｃｌｉｃｋ−ｔｏ−ｂｕｙ）、またはリモート決済システム（顧客の携帯電話を使用して商品やサービスの支払いを行う、ｔｅｘｔ−ｔｏ−ｂｕｙまたはｔａｌｋ−ｔｏ−ｂｕｙなどのシステム）から発生し得る。
【００６３】
本明細書における「サーバ」とは、ネットワーク上で他のデバイスと自動的に相互作用することにより、コンテンツとウェブページをサービス提供し、他のネットワークデバイスからの通信に対する応答を発行し、他のネットワークデバイスからの問合せに応答するように構成可能な、コンピューティングデバイスのことである。
【００６４】
図２は、カードリーダデバイス１４のパーソナライゼーションフェーズ３０の間の例示的フロー図を示している。この図では、カードリーダデバイス１４、キー管理システム２２、およびサーバ１９の間の処理フローが、各番号の割り当てられたラベル付き矢印で描かれている。このフローは、番号の小さいものから順に、上から下へと順次実行されるものと解釈される。但し、このプロトコルの複数のインスタンスが、指定された順序通りではなく、並行して実行される可能性もあるということに留意されたい。
【００６５】
図２は、例示的実施形態に基づいて実行可能な機能セット３０を表すフローチャートである。機能セット３０は、カードリーダ１４のパーソナライゼーションフェーズ中に実行することができる。機能セット３０は、ステップ３１から３６に示される。これらのステップについて、以下に説明する。
【００６６】
このパーソナライゼーション処理では、リーダマスタキーＲＭＫが生成される。リーダマスタキーＲＭＫは、ステップ３１において、キー管理システム２２によって生成され得る。図２に示すキー管理システム２２は、コンピュータ内で実行するソフトウェアプログラムである。キー管理システムのソフトウェアやデータベースが持つ論理機能は、クライアント／サーバネットワーク内のコンピュータ間で分散されてもよいし、単一プロセッサに集中化されてもよい。この機能は、標準的なローカルエリアネットワーク、ワイドエリアネットワーク、専用電話回線、またはプロセッサを緩やかに結合するのに用いられる他の通信手段を通じて、接続されたプロセッサの間で分散されてもよい。キー管理システム２２は、カードリーダの製造元サーバ、サーバ１９、または任意の信頼できるシステムによって実行させることができる。
【００６７】
ステップ３２では、カードリーダの識別子が生成される。ある実施形態では、識別子はキー管理システム２２によって生成され得る。別の実施形態では、この識別子はカードリーダの製造元によって生成され得る。この識別子は、カードリーダ１４のシリアル番号ＳＮとすることができる。この識別子ＳＮは、各カードリーダに一意のものとすることが好ましい。
【００６８】
好ましい実施形態では、キー管理システム２２が、導出アルゴリズム、マスタキーＲＭＫ、および識別子ＳＮから、リーダキーＲＫを導出する。本明細書で使用する導出アルゴリズムは、当業者によく知られているものであって、これ以上の説明は必要としない。
【００６９】
ステップ３３では、キー管理システム２２が、一意識別子ＳＮと、導出された関連リーダキーＲＫとを、カードリーダ１４にロードする。ある実施形態では、カードリーダはセキュアエレメントを備えており、このセキュアエレメントにおいて、識別子ＳＮおよびリーダキーがロードされる。
【００７０】
ある実施形態では、キー管理システム２２は、導出されたリーダキーの代わりに、マスタキーをカードリーダにロードする。この場合には、カードリーダが、導出アルゴリズム、マスタキーＲＭＫ、および関連付けられた識別子ＳＮから、リーダキーＲＫを導出する。導出されたリーダキーＲＫは、次の使用に備え、カードリーダに格納することができる。
【００７１】
ステップ３４では、キー管理システム２２は、サーバ１９との間で、生成されたマスタキーＲＭＫおよび関連付けられた一意識別子ＳＮを共有する。それらの受信後、サーバ１９は、このマスタキーＲＭＫを、関連付けられたカードリーダ１４に関する一意識別子ＳＮと併せて、サーバのデータベースに格納する。
【００７２】
つまり、キー管理システム２２は、カードリーダ１４およびサーバ１９と通信するためのセッションキーを生成するのに使用しなくてはならない、カードリーダに対する静的キーを生成する。
【００７３】
カードリーダとサーバ１９の間における共有キーおよび識別子ＳＮの生成や共有に関し、そのあらゆる好適な形態が、当業者の想到し得る通りに実装されてよい。エンティティ間で共有キーおよび識別子ＳＮを生成や共有する方法は、本発明の範囲外のものである。
【００７４】
カードリーダデバイス１４は、カウンタ２３を備えている。このカウンタ２３は、デバイス取引カウンタＤＴＣと名付けることができる。ステップ３６では、カードリーダ１４は、値ＤＴＣを代入することにより、カウンタ２３を初期化する。値ＤＴＣは整数となる。図２に示す実施形態では、初期化された値ＤＴＣはｎｕｌｌ値である。
【００７５】
図３は、カードリーダ１４を用いた、例示的取引検証フロー図４０を示している。この取引を検証するために、カードリーダ１４の通信インタフェース１５を携帯電話１０の通信インタフェースへと物理的に押し込み、次いでスマートカード１７を、カードリーダデバイス１４のカードスロットに挿入、または磁気ストライプリーダにスライドすることができる。
【００７６】
取引の検証が開始されると、ステップ４１において、携帯電話１０がモバイル取引アプリケーション２０を起動させる。ステップ４２では、モバイル取引アプリケーション２０は、カードリーダ１４との間に通信セッションを確立する。カードリーダがセットアップされると、ステップ４３において、セキュアなチャネルを確立するための要求が、カードリーダ１４からサーバ１９へと、モバイル取引アプリケーションを介して送信される。セキュアなチャネルを確立するための要求は、カードリーダのカウンタ２０の現在値ＤＴＣと、カードリーダの識別子ＳＮとを含むことができる。現在値ＤＴＣとは、カードリーダのデータベースに更新された最後のＤＴＣ値である。
【００７７】
受信後、ステップ４４において、サーバ１９は受信した識別子ＳＮに関連付けられたマスタキーＲＭＫを、サーバのデータベースから抽出する。次いで、サーバ１９は、導出アルゴリズム、抽出したマスタキーＲＭＫ、および受信した識別子ＳＮから、リーダキーを導出する。
【００７８】
ある実施形態では、キー管理システムがリーダキーを導出する。この導出されたリーダキーは、関連付けられた識別子ＳＮと共に、サーバへと送信されて格納される。その場合、サーバは、ステップ４３における識別子ＳＮの受信時に、サーバのデータベースから対応するリーダキーを抽出する。
【００７９】
別の実施形態では、導出されたリーダキーまたはマスタキー（実施形態によって異なる）は、セキュアなデータベースに格納される。サーバは、ステップ４３における識別子ＳＮの受信時に、要求をこのデータベースへと送信して、対応するリーダキーまたはマスタキーを取得する。受信後、セキュアなデータベースは、識別子ＳＮに対応するリーダキーまたはマスタキーを抽出する。次いで、抽出されたリーダキーまたはマスタキーは、応答としてサーバへと送信される。
【００８０】
ステップ４５では、サーバ１９が、セッションキーを計算するのに用いる多様化データを定義する。これに関して、サーバ１９は、受信したカウンタ２３の現在値をインクリメントし、ランダム値Ｓｅｒｖｅｒ−ＲＮＤまたはチャレンジを生成する。生成されたランダム値は、サーバ１９に対し、現在のセキュアチャネルセッションが事前計算されておらず、正規カードリーダが実際にチャネルの他端に存在するということの保証を与えることができる。このランダム値のサイズは特別大きいものとする必要はなく、数ビットでも十分である。多様化データは、インクリメントされたカウンタ現在値と、生成されたランダム値とを含んでいる。
【００８１】
ある実施形態では、ランダム値Ｓｅｒｖｅｒ−ＲＮＤは３バイト長となる。３バイト長は、生成されるセッションキーに対しては、十分な多様性を持つほどには大きいものである。３バイト長は、リーダキーの取得を目的とした、カードリーダに対する差分攻撃を緩和するためには、小さいものとなる。
【００８２】
ステップ４６では、サーバ１９が、導出したリーダキー、多様化データ、および導出アルゴリズムから、セッション暗号化キーおよびセッション完全性キーを導出する。
【００８３】
ステップ４７では、サーバ１９が、生成されたランダム値およびＭＡＣ値を含む、認証要求を生成する。ＭＡＣ署名値は、ランダム値の少なくとも一部分に対するＭＡＣ（メッセージ認証コード）処理の結果である。ＭＡＣ処理は、セッション完全性キーおよび暗号チェックサムアルゴリズムを使用して、ＭＡＣ署名値を生成する。このＭＡＣ署名値を後に用いて、データが改変されていないことを保証することができる。
【００８４】
ステップ４８では、サーバ１９が、携帯電話１０のモバイル取引アプリケーション２０に対し、ネットワーク２１を通じて認証要求を送信する。受信後、モバイル取引アプリケーションは、認証要求をカードリーダ１４へと転送する。
【００８５】
ステップ４８での受信後、カードリーダ１４は、多様化データを定義する。これに関して、カードリーダは、カードリーダのカウンタ２３の現在値ＤＴＣをインクリメントする。多様化データは、インクリメントされたカウンタ２３の値と、受信したチャレンジまたはランダム値Ｓｅｒｖｅｒ−ＲＮＤとを含んでいる。ステップ４９では、カードリーダ１４が、カードリーダのデータベースに格納されている導出したリーダキー、定義した多様化データ、および導出アルゴリズムから、セッション暗号化キーおよびセッション完全性キーを導出する。
【００８６】
ステップ５０では、カードリーダが、受信したランダム値および計算したセッション完全性キーから、ＭＡＣ値を計算する。計算されたＭＡＣ値は、ランダム値が変更されたかどうかをチェックするために、受信したＭＡＣ値と比較される。ある実施形態では、ＭＡＣ値の検証に失敗した場合、ステップ５１において処理フローを終了することができ、カードリーダ１４が、モバイル取引アプリケーションおよび／またはサーバ１９に、ＭＡＣ値が改竄されたということを通知してもよい。一方、ＭＡＣ値の検証に成功した場合には、カードリーダ１４により、サーバ１９は正規サーバであると認証される。
【００８７】
ステップ５２では、サーバ１９の認証に成功した場合、カウンタの現在値が、インクリメントされたカウンタの現在値で更新される。更新されたこの現在値は、カードリーダのデータベースに格納される。カウンタの現在値はサーバの認証が成功した場合にのみ更新され、また取引ごとに全て異なるため、得られるセッションキーも様々なものとなり、反射攻撃が回避される。
【００８８】
ある実施形態では、カウンタの現在値がデータベースに更新されると、カードリーダ１４が、更新されたカウンタ値が所定の最大値ＤＴＣ＿ＭＡＸに達しているかどうかを分析する。所定の最大値ＤＴＣ＿ＭＡＸは、認可される取引の最大数である。この所定の最大値は、カードリーダまたはカードリーダの製造元が既定値として定義することができる。ある実施形態では、所定の最大値ＤＴＣ＿ＭＡＸは、携帯電話１０のモバイル取引アプリケーションを通じて、ユーザによって入力される。所定の最大値ＤＴＣ＿ＭＡＸは、カードリーダの耐用年数全体を通じて有効とするのに十分な大きさであることが好ましい。
【００８９】
更新されたカウンタ値が所定の最大値ＤＴＣ＿ＭＡＸと等しい場合には、新たな所定の最大値が定義されるまで、カードリーダをロックし、またはスタンバイ状態にすることができる。
【００９０】
ステップ５３では、カードリーダ１４が、格納されたカウンタ２３の更新値およびＭＡＣ値を含む、認証要求を生成する。ＭＡＣ署名値は、カウンタ２３の更新値の少なくとも一部分に対するＭＡＣ（メッセージ認証コード）処理の結果である。ＭＡＣ処理は、セッション完全性キーおよび暗号チェックサムアルゴリズムを使用して、ＭＡＣ署名値を生成する。このＭＡＣ署名値を後に用いて、データが改変されていないことを保証することができる。
【００９１】
ステップ５４では、カードリーダ１４が、携帯電話１０のモバイル取引アプリケーション２０に対して認証要求を送信する。受信後、モバイル取引アプリケーションは、ネットワーク２１を通じて、認証要求をサーバ１９へと転送する。
【００９２】
ステップ５５での受信後、サーバ１９は、受信したカウンタ２３の更新値および計算したセッション完全性キーから、ＭＡＣ値を計算する。計算されたＭＡＣ値は、カウンタ２３の更新値が変更されたかどうかをチェックするために、受信したＭＡＣ値と比較される。ある実施形態では、ＭＡＣ値の検証に失敗した場合、ステップ５６において処理フローを終了することができ、サーバ１９が、モバイル取引アプリケーションおよび／またはカードリーダ１４に、ＭＡＣ値が改竄されており、カードリーダは正規のものではないということを通知してもよい。一方、ＭＡＣ値の検証に成功した場合には、サーバ１９により、カードリーダ１４は正規のものであると認証される。
【００９３】
ステップ５７では、サーバ１９およびカードリーダ１４の認証に成功した場合、取引を検証するためのセキュアセッション通信が、カードリーダとサーバ１９の間に確立される。
【００９４】
図３で説明した処理フローは、カードリーダ１４とサーバ１９の間に、エンドツーエンドのセキュリティを構築する。本発明によって定義されるセッション暗号化キーおよびセッション完全性キーは、セキュアなチャネルを提供するものである。情報は、このセキュアなチャネルにより、認可されたカードリーダを通じて、携帯電話１０を経て、ネットワーク２１および認可されたサーバ１９上で、安全に送信することができる。セッション暗号化キーおよびセッション完全性キーは、カードリーダ１４とサーバ１９の間で交換されるメッセージの機密性および完全性を保護するために使用される。
【００９５】
ステップ５７でセキュアなチャネルがセットアップされると、サーバ１９およびカードリーダは、モバイルアプリケーション取引を「パススルーゲートウェイ」として使用する。取引検証ステップを完了するため、例えば以下のステップを実行することができる：
−  サーバ１９がＭＡＣ署名を用いてコマンドを暗号化し、そのコマンドに署名する。このコマンドは、ネットワーク２１経由でモバイル取引アプリケーションへと送信される。
−  モバイル取引アプリケーションが、暗号化／署名されたコマンドを取得する。
−  モバイル取引アプリケーションが、暗号化／署名されたコマンドをカードリーダへと転送する。
−  カードリーダが署名をチェックし、コマンドを復号する。
−  カードリーダがコマンドをスマートカード１７へと送信し、その応答を受信する。
−  カードリーダが応答を暗号化し、その応答に署名する。
−  カードリーダがその応答をモバイル取引アプリケーションへと返信する。
−  モバイル取引アプリケーションが、暗号化／署名された応答をサーバへと送信する。
など。
【００９６】
サーバは、セキュアなチャネルを使用して、スマートカードコマンドを送信し、スマートカード応答を受信する。ひとたび取引検証処理が完了すると、サーバはこのセキュアなチャネルを閉じる。
【００９７】
ある実施形態では、カードリーダは無効化カウンタを備えている。カードリーダ１４は、ｎｕｌｌ値を代入することにより、無効化カウンタを初期化する。図３のステップ５０におけるＭＡＣの検証に失敗した場合、カードリーダ１４は、無効化カウンタ値を１ずつインクリメントする。次いで、カードリーダは、無効化カウンタ値が所定の最大エラー（例えば「３」）に達したかどうかを分析する。
【００９８】
無効化カウンタ値が所定の最大エラーを下回っていれば、取引検証フロー図４０を再度繰り返すこともできる。無効化カウンタ値が所定の最大エラーと等しければ、カードリーダは次に必要な処理の実行を拒否すると同時に、可能であればユーザに対し、カードリーダを非アクティブ化したことを知らせるメッセージを、携帯電話１０および／またはサーバ１９を通じて送信することにより、更なる処理の進行を禁止することができる。
【００９９】
カードリーダ１４を再アクティブ化するには、ユーザがアンロックコードを入力しなくてはならない。このコードは、別媒体でユーザに提供されるものとなる可能性があり、ユーザは必要に応じて、サービスプロバイダに当該コードを要求することができる。
【０１００】
別の実施形態では、カードリーダはエラーカウンタを備えている。カードリーダ１４は、ｎｕｌｌ値を代入することにより、エラーカウンタを初期化する。図３のステップ５７で確立されたセキュアなチャネル上で、無効な着信メッセージが受信された場合、カードリーダ１４は、エラーカウンタ値を１ずつインクリメントする。この着信メッセージは、サーバから受信したＭＡＣ値または暗号化されたコマンドとすることができる。
【０１０１】
次に、カードリーダは、エラーカウンタ値が所定の最大エラー（例えば「３」）に達したかどうかを分析する。エラーカウンタ値が所定の最大エラーに等しければ、カードリーダはセッションを終了し、ＥＲＲ＿ＳＥＳＳＩＯＮ＿ＣＬＯＳＥＤを、携帯電話１０および／またはサーバ１９を通じてユーザに返すことができる。
【０１０２】
これらの実施形態は、カードリーダを保護すると共に、エラー管理に柔軟性をもたらす。
【０１０３】
別の実施形態では、カードリーダ１４およびサーバ１９は、シーケンス番号カウンタＳＣＮＴＲを備えている。このシーケンス番号カウンタＳＮＣＴＲは、サーバおよびカードリーダによるセッション取引の度、逐次的にインクリメントされる。図３のステップ４７では、認証要求の生成中、サーバ１９は、サーバのシーケンス番号カウンタＳＣＮＴＲを初期化または逐次的にインクリメントする。また、ステップ５０でサーバがカードリーダ１４によって認証されると、カードリーダはそのシーケンス番号カウンタＳＣＮＴＲを初期化または逐次的にインクリメントする。
【０１０４】
このシーケンス番号カウンタ値ＳＣＮＴＲは、図３のステップ５３でカードリーダ１４によってサーバ１９へ送信された認証要求に追加される。ステップ５５では、ＭＡＣの検証中、サーバ１９は、受信したシーケンス番号ＳＣＮＴＲが然るべきものかどうか、つまり、受信したＳＣＮＴＲがサーバ１９のＳＣＮＴＲカウンタの値に等しいかどうかをチェックする。等しくなければ、メッセージ認証コードの検証は失敗となる。本発明によって定義されるシーケンス番号値を用いると、反射攻撃からカードリーダを保護することが可能となる。実際、サーバ側でＭＡＣの検証が失敗するため、それまでのコマンドの再実行は不可能となる。ある実施形態では、シーケンス番号値は２バイト長となる。
【０１０５】
ある実施形態では、セッション暗号化キーおよびセッション完全性キーは、取引セッションごとに一意となる４つの対称キーを含んでいる。この４つの対称キーは、以下のものとすることができる：
−  送信暗号化キーＴＥＮＣ。コマンドを暗号化するために、サーバによって使用される。この送信暗号化キーＴＥＮＣは、コマンドを復号するために、カードリーダによっても使用される。
−  送信完全性キーＴＭＡＣ。コマンドからＭＡＣ値を計算するために、サーバによって使用される。この送信完全性キーＴＭＡＣは、受信したＭＡＣ値をチェックするために、カードリーダによっても使用される。
−  受信暗号化キーＲＥＮＣ。コマンドの応答を暗号化するために、カードリーダによって使用される。この受信暗号化キーＲＥＮＣは、受信した応答を復号するために、サーバによっても使用される。
−  受信完全性キーＲＭＡＣ。コマンド応答からＭＡＣ値を計算するために、カードリーダによって使用される。この受信完全性キーＲＭＡＣは、受信したＭＡＣ値をチェックするために、サーバによっても使用される。
【０１０６】
本発明を実装するのに使用される計算関数の例を以下に示す。それらの計算関数に対し、以下の暗号データおよびセキュリティ機能が設けられる：
−  ｉｄｅｎｔｉｆｉｅｒ  ＳＮ（識別子ＳＮ）：１０進数からエンコードされた８バイトのバイナリ
−  Ｍａｓｔｅｒ  Ｋｅｙ  ＲＭＫ（マスタキーＲＭＫ）：「キーセレモニー」を使用してＨＳＭ内で生成された１６バイト
−  ｃｏｕｎｔｅｒ  ＤＴＣ（カウンタＤＴＣ）：ＭＳＢファーストの４バイト
−  ｐｒｅｄｅｆｉｎｅｄ  ｍａｘｉｍｕｍ  ｖａｌｕｅ  ＤＴＣ＿ＭＡＸ（所定の最大値ＤＴＣ＿ＭＡＸ）：５００００
−  ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ  ｖａｌｕｅ  ＳＣＮＴＲ（シーケンス番号値ＳＣＮＴＲ）：２バイト：ＭＳＢファースト
−  ｒｅａｄｅｒ  ｋｅｙ（リーダキー）：ＴＭＡＣ、ＲＭＡＣ、ＴＥＮＣ、ＲＥＮＣ用の１６バイト３ＤＥＳキー
【０１０７】
リーダキーの計算：
【数１】
2016537887.tif 000003
【０１０８】
セッションキーの計算：
【数２】
2016537887.tif 000004
【０１０９】
セッションキーＴＥＮＣ、ＴＭＡＣ、ＲＥＮＣ、そして、ＲＭＡＣは、追加データ（例えば、外部のエントロピソースによって生成されたランダム値、または一定値）を使用し、かつＨＭＡＣ−ＳＨＡ２アルゴリズムを使用することによって計算される。完全性キーおよび暗号化キーの計算関数の結果は、それぞれが異なったものになり得ると共に、セッションキーの多様性および予測不能性、ひいてはそれまでのセッションキーを再計算や再実行しようとする働きに対する不可能性を、十分に実現することができる。そうしたセッションキーの多様性および予測不能性、ならびに先行セッションキーの再計算や再実行への働きに対する不可能性の実現は、実施形態に応じたものとなる。
【０１１０】
データの暗号化：
暗号化関数は、パディング（ｐａｄｄｉｎｇ）を扱うことができる。
【数３】
2016537887.tif 000005
【０１１１】
データの復号：
復号関数は、暗号化データが誤り（例えばパディングの不整合のため）である場合、ｎｕｌｌを返すことができる。
【数４】
2016537887.tif 000006
【０１１２】
ＭＡＣの計算：
ＭＡＣ値は８バイト長とすることができる。
【数５】
2016537887.tif 000007
【０１１３】
ある実施形態では、セッションキーは、カードリーダのカードリーダホストコントローラによって取得される。関数ＥｎｃｒｙｐｔＤａｔａ（）、ＤｅｃｒｙｐｔＤａｔａ（）、ＣｏｍｐｕｔｅＭａｃ（）は、セキュアエレメント内ではなく、カードリーダファームウェア内で実装される。
【０１１４】
別の実施形態では、セッションキーはカードリーダのセキュアエレメントに格納され、関数ＥｎｃｒｙｐｔＤａｔａ（）、ＤｅｃｒｙｐｔＤａｔａ（）、ＣｏｍｐｕｔｅＭａｃ（）がセキュアエレメント内で実装される。
【０１１５】
本発明の実装例を以下に示す。この実装形態に対して、上述した計算関数が用いられる。
【０１１６】
利用可能なコマンド／応答の種類：
「｜」というシンタックスは、データの連結を意味する。
【数６】
2016537887.tif 000008
【０１１７】
取引検証フロー図：
【数７】
2016537887.tif 000009
2016537887.tif 000010
2016537887.tif 000011
2016537887.tif 000012
2016537887.tif 000013
2016537887.tif 000014
【０１１８】
本発明を使用すると、スマートカードデータは、クリアな状態でモバイル取引アプリケーションへと送信されず、またモバイルデバイスからリモートサーバへの転送中も、クリアな状態で循環することはない。
【０１１９】
本発明は簡単で実装が容易である。決済アプリケーションとゲートウェイの相互認証は、ユーザクレデンシャルの機密性、およびメッセージの完全性／発信元を保証するために実行される。
【０１２０】
本発明によって定義されるプロトコルを用いると、以下の理由により、差分攻撃からカードリーダを保護することが可能となる：
−  メッセージ認証コードがセッションセットアップ中および全てのコマンド内で強制適用される。
−  セッションセットアップ中のメッセージ認証コードを計算するのに用いられるチャレンジのサイズが制限される。
【０１２１】
更に、本発明によって定義されるプロトコルは、１）ＭＡＣ機能の使用と、２）得られるパディングを検証することによる復号データの無矛盾性検証とによって、自己信頼型のものとなる。
【図１】
2016537887.tif 000015
【図２】
2016537887.tif 000016
【図３】
2016537887.tif 000017
【国際調査報告】
2016537887.tif 000018
2016537887.tif 000019
2016537887.tif 000020