(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0023】
本発明は、処理、装置、システム、物質の組成、コンピュータ読み取り可能な格納媒体上に具現化されたコンピュータプログラム製品、および/または、プロセッサ(プロセッサに接続されたメモリに格納および/またはそのメモリによって提供される命令を実行するよう構成されたプロセッサ)を含め、様々な形態で実装されうる。本明細書では、これらの実装または本発明が取りうる任意の他の形態を、技術と呼ぶ。一般に、開示された処理の工程の順序は、本発明の範囲内で変更されてもよい。特に言及しない限り、タスクを実行するよう構成されるものとして記載されたプロセッサまたはメモリなどの構成要素は、ある時間にタスクを実行するよう一時的に構成された一般的な構成要素として、または、タスクを実行するよう製造された特定の構成要素として実装されてよい。本明細書では、「プロセッサ」という用語は、1または複数のデバイス、回路、および/または、コンピュータプログラム命令などのデータを処理するよう構成された処理コアを指すものとする。
【0024】
以下では、本発明の原理を示す図面を参照しつつ、本発明の1または複数の実施形態の詳細な説明を行う。本発明は、かかる実施形態に関連して説明されているが、どの実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定されるものであり、多くの代替物、変形物、および、等価物を含む。以下の説明では、本発明の完全な理解を提供するために、多くの具体的な詳細事項が記載されている。これらの詳細事項は、例示を目的としたものであり、本発明は、これらの具体的な詳細事項の一部または全てがなくとも特許請求の範囲に従って実施可能である。簡単のために、本発明に関連する技術分野で周知の技術要素については、本発明が必要以上にわかりにくくならないように、詳細には説明していない。
【0025】
上述の本願の課題、特徴、および利点をより容易に理解できるように、以下では、添付の図面および具体的な実施形態を参照しつつ、本願について詳細に説明する。
【0026】
本願は、ハードウェア製品が動作範囲、サービス、および、技術向上に関して持つ問題、ならびに、オンライン取引がフィッシング、トロイの木馬、および、トロイの木馬型フィッシングに対する防御で現在直面している問題の両方を最小限に抑えることができるオンライン取引のための安全な認証方法およびシステムをソフトウェアの形態で実施する。
【0027】
以下では、
図1から
図9を参照して、本願の処理について詳述する。
【0028】
図1から
図9の処理は、OTPコントロール、JavaScript(登録商標)(JS、コンピュータスクリプト言語の一種)、クライアントに配置されたブラウザ、オンライン決済ゲートウェイ、OTPコントロールサーバ(図ではコントロールサーバと省略)、OTP認証プラットフォーム、ビジネスシステム、および、サーバ側データベースを含む。OTPコントロールは、クライアントマシン(例えば、パーソナルコンピュータ、スマートフォン、タブレット、または、その他の適切なデバイス)にインストールされており、OTPコントロールサーバおよびOTP認証プラットフォームと協働して機能することで、オンライン取引のための安全な認証を達成する。OTPコントロールサーバは、主に、OTPコントロールのユーザIDを検証し、OTP認証プラットフォームは、主に、取引検証を完了させるよう機能する。オンライン決済セキュア・ソケット・レイヤ(SSL)サーバが、オンライン取引におけるオンライン決済を完了させる。ビジネスシステムは、主に、オンライン取引のデータを処理する。
【0029】
図1を参照する。
図1は、クライアントおよびサーバの間で暗号化された通信を行うためのオンライン取引の安全な認証処理の一実施形態を示す。この処理は、サーバ上で実行されてよく、クライアントとの協働を必要とする。処理は、以下の工程を含む。
【0030】
工程101において、サーバは、ランダムセッション鍵を生成する。
【0031】
ランダムセッション鍵の生成は、クライアントおよびサーバがランダムセッション鍵を交換することを含みうる。いくつかの実施形態において、クライアントは、乱数を生成して、その乱数をサーバに送信し;サーバは、ランダムセッション鍵およびキャプチャファクタ(capture factors)を生成して、それらのランダムセッション鍵およびキャプチャファクタをクライアントに返す。この工程の詳細については、
図2を参照して後述する。
【0032】
工程102では、クライアントのユーザIDが、ランダムセッション鍵に基づいて検証される。この時点でのクライアントの検証は、トロイの木馬ソフトウェアによるセッションの乗っ取りを防ぐ。
図3および
図4を参照して、2つの検証アプローチについて後述する。
【0033】
工程103では、ユーザIDの検証が成功したか否かが判定される。検証が成功した場合、工程104において取引画像情報が生成され、ランダムセッション鍵に基づいて暗号化され、クライアントに送信される。そうでない場合、工程107において検証失敗の状態を示す検証結果が、クライアントに送信される。
【0034】
工程105では、取引画像の確認が受信される。いくつかの実施形態において、確認は、取引署名を含む。工程106では、取引署名がランダムセッション鍵に基づいて正しく検証されうるか否かが判定される。検証結果は、工程107においてクライアントに送信される。
【0035】
図2は、ランダムセッション鍵を生成するための処理の一実施形態を示す。処理200は、処理100の工程101を実行するために用いられてよい。処理に関わる構成要素が図の上部に示されている。ブラウザ(ブラウザ部)、JS(JS部)、および、OTPコントロール(OTPコントロール部)は、クライアント側にあり、オンライン決済ゲートウェイ、コントロールサーバ、および、データベースは、サーバ側にある。処理は、以下の工程を含む。
【0036】
工程201において、ユーザは精算の準備ができているため、ウェブページはレジページへと移行する。
【0037】
工程202において、JavaScript(登録商標)(JS)は、OTPコントロールを初期化する。
【0038】
工程203において、JSは、ランダムセッション鍵要求を生成し、OTPコントロールにランダムセッション鍵要求を送信する。
【0039】
工程204において、OTPコントロールは、乱数を生成する。例えば、乱数は、24バイト乱数であってよい。
【0040】
工程205において、OTPコントロールは、事前設定されたRSA公開鍵を用いて、生成された乱数を暗号化する。RSAは、当業者に周知の公開鍵暗号化アルゴリズムである。
【0041】
工程206において、OTPコントロールは、暗号化された乱数をJSに返す。
【0042】
工程207において、JSは、ブラウザを起動して、セッション鍵交換要求を送信する。
【0043】
工程208において、ブラウザは、セッション鍵交換要求をオンライン決済ゲートウェイに送信する。
【0044】
工程209において、オンライン決済ゲートウェイは、OTPコントロールサーバにメッセージを送信する。
【0045】
送信されたメッセージは、セッション鍵交換要求を含む。
【0046】
工程210において、OTPコントロールサーバは、メッセージを復号し、OTPコントロールによって生成された乱数を取得する。
【0047】
例えば、OTPコントロールサーバは、RSA秘密鍵に基づいて、メッセージを復号してOTPコントロールの24バイト乱数を取得する。
【0048】
工程211において、OTPコントロールサーバは、乱数を生成する。例えば、乱数は、12バイト乱数であってよい。
【0049】
工程212において、OTPコントロールサーバは、生成した乱数と、クライアント側でOTPコントロールによって送信された乱数とを結合する。例えば、OTPコントロールサーバは、OTPコントロールの24バイト乱数の最初の12バイトをOTPコントロールサーバの12バイト乱数と結合して、24バイトのランダムセッション鍵を生成することができる。
【0050】
工程213において、OTPコントロールサーバは、24バイトのランダムセッション鍵をデータベースに格納する。
【0051】
工程214において、OTPコントロールサーバは、キャプチャファクタを生成する。
【0052】
例えば、キャプチャファクタは、ランダムに選択されたN個の乱数のセットを含んでよく、その乱数のセットは、工程102においてユーザマシン情報をキャプチャして、キャプチャしたユーザマシン情報を検証するために用いられる。Nは、任意の正の整数であってよい。
【0053】
工程215において、OTPコントロールサーバは、OTPコントロールの24バイト乱数に基づいて、12バイト乱数およびキャプチャファクタの両方を暗号化する。
【0054】
工程216において、OTPコントロールサーバは、セッション鍵交換応答をオンライン決済ゲートウェイに送信する。
【0055】
工程217において、オンライン決済ゲートウェイは、セッション鍵交換応答をブラウザに転送する。
【0056】
工程218において、ブラウザは、セッション鍵交換応答を受信し、JSにセッション鍵交換応答を送信し、JSは呼び出される。
【0057】
工程219において、JSは、12バイト乱数およびキャプチャファクタを含む暗号化された情報を受信する。
【0058】
工程220において、JSは、暗号化された情報を含むマシン情報検証要求をOTPコントロールに送信する。
【0059】
工程221において、OTPコントロールは、自身の生成した24バイト乱数に基づいて、暗号化された情報を復号して、OTPコントロールサーバの12バイト乱数を取得する。
【0060】
工程222において、OTPコントロールは、自身の生成した24バイト乱数の最初の12バイトと、OTPコントロールサーバによって生成された復号済みの12バイト乱数とを用いて、ランダムセッション鍵を取得する。その後のメッセージが、ランダムセッション鍵に基づいて暗号化されうる。
【0061】
工程223において、OTPコントロールは、さらに、暗号化された情報からキャプチャファクタを取得する。上述のように、ランダムセッション鍵は、OTPコントロールおよびOTPコントロールサーバの間で生成され、OTPコントロールおよびOTPコントロールサーバの各々が、ランダムセッション鍵の半分を生成する。したがって、ランダムセッション鍵は、非常に安全である。
【0062】
図1の工程102を参照すると、クライアントのユーザIDの検証は、少なくとも2つのアプローチを含む。一方のアプローチでは、
図3に示すように、ユーザマシン情報を用いて、検証が行われてもよい。もう一方のアプローチでは、
図4に示すように、携帯電話のショートメッセージを用いて、クライアントのユーザIDが検証されてもよい。
【0063】
図3は、ユーザマシン情報を用いてユーザIDを検証する処理の一実施形態を示す。処理300は、ランダムセッション鍵が生成された後に、処理100の工程102を実行するために用いられてよい。処理300は、以下の工程を含む。
【0064】
工程301において、JSは、ランダムセッション鍵とキャプチャファクタとを含むセッション鍵応答メッセージをOTPコントロールに送信する。
【0065】
工程302において、OTPコントロールは、受信したセッション鍵応答メッセージからランダムセッション鍵およびキャプチャファクタを取得する。
【0066】
OTPコントロールは、自身が生成した24バイト乱数を用いて、セッション鍵応答メッセージを復号し、OTPコントロールサーバの復号された12バイト乱数を用いて、自身が生成した24バイト乱数の最後の12バイトと置き換える。その結果、OTPコントロールは、ランダムセッション鍵を取得する。
【0067】
工程303において、OTPコントロールは、ユーザマシン情報を抽出する。
【0068】
OTPコントロールは、キャプチャファクタに基づいてユーザマシン情報を抽出する。いくつかの実施形態において、キャプチャファクタは乱数に対応しており、各乱数はマシン情報の異なる部分と対応している。各キャプチャファクタは、ユーザマシン情報の一部に関連する。一例において、キャプチャファクタは、10個の乱数を含んでよい。この例において、キャプチャファクタは、10個の乱数に対応するユーザマシン情報の部分と関連しており、ユーザマシン情報のそれらの部分に関連する情報が抽出される。OTPコントロールは、毎回、ユーザマシン情報の異なる部分を抽出しうる。
【0069】
キャプチャファクタがランダムなので、キャプチャファクタに基づいて毎回抽出されるユーザマシン情報も様々である。例えば、コントロールサーバによって或る時点に発行されるキャプチャファクタが、16個の乱数であって、別の時点に発行されるキャプチャファクタが、20個の乱数であってもよい。この例において、抽出されるユーザマシン情報は、同じOTPコントロールおよび同じユーザマシンに関して毎回変化しうる。その結果、ユーザIDの検証の安全性が向上されうる。ユーザマシン情報は、マシンのハードウェア情報、ソフトウェア情報、オペレーティングシステムのバージョンなどを含みうる。ユーザマシン情報の例としては、メディアアクセス制御(MAC)アドレス、CPUシリアル番号、ハードドライブシリアル番号、ソフトウェア情報(オペレーティングシステムのバージョンおよび主なアプリケーションのバージョン)などが挙げられる。ただし、多くの他の例および組み合わせが存在する。同じユーザマシン情報は、セッションの継続期間中に変化しない。
【0070】
工程304において、OTPコントロールは、ランダムセッション鍵に基づいてユーザマシン情報を暗号化し、暗号化したユーザマシン情報をJSに返す。
【0071】
上述のキャプチャファクタの方法が利用されたのに応答して、OTPコントロールは、キャプチャファクタをユーザマシン情報と共に暗号化して送信してよい。
【0072】
工程305において、JSは、ブラウザを起動して、要求メッセージを送信する。要求メッセージは、ユーザマシン情報およびキャプチャファクタを含みうる。
【0073】
工程306において、ブラウザは、要求メッセージをオンライン決済ゲートウェイに送信する。
【0074】
工程307において、オンライン決済ゲートウェイは、要求メッセージをOTPコントロールサーバに転送する。
【0075】
工程308において、OTPコントロールサーバは、データベースから情報をリトリーブする。いくつかの実施形態において、データベースは、様々なクライアントの所定のマシン情報を格納する。その後、データベースに提供されたキャプチャファクタに基づいて、特定のクライアントのためのキャプチャファクタに対応する様々なマシン情報が、データベースから要求されうる。
【0076】
工程309において、OTPコントロールサーバは、データベースから得られたキャプチャファクタに関連する情報を、抽出されたユーザマシン情報と比較する。OTPコントロールサーバは、ユーザマシン情報の各部分を、データベースからの情報と比較して、一致するか否かを判定する。
【0077】
OTPコントロールサーバは、キャプチャファクタに対応する抽出されたユーザマシン情報とデータベース内のキャプチャファクタに対応する情報との比較を行い、抽出されたユーザマシン情報がデータベースに格納されている情報と異なるか否かを判定する。
【0078】
工程310において、ユーザマシン情報の一致率が所定の閾値を超える場合、OTPコントロールサーバは、ユーザマシン情報の一致が成功したと確認する。
【0079】
OTPサーバがユーザマシン情報の一致が成功したと確認するための所定の閾値は、80%以上であってよい。ユーザマシン情報の一致率が80%未満であった場合、OTPサーバは、ユーザマシン情報の一致が不成功であったと確認する。
【0080】
工程311において、OTPコントロールサーバは、マッチング結果をオンライン決済ゲートウェイに返す。
【0081】
工程312において、オンライン決済ゲートウェイは、マッチング結果をブラウザに転送する。
【0082】
工程313において、ブラウザは、マッチング結果を受信し、そのマッチング結果をJSに返し、JSは、マッチング結果が成功を示す場合に成功した取引を表示するため、または、マッチング結果が失敗を示す場合に失敗した取引/警告メッセージを表示するために呼び出される。
【0083】
ここで、
図4を参照すると、
図4は、以下で説明するように、携帯電話のショートメッセージを用いてユーザIDを検証する処理の一実施形態を示す。
【0084】
図4において、工程401から409は、実質的に
図3の工程301から309と同じであるため、工程401から409の説明は簡単のために省略する。
【0085】
工程410では、ユーザマシン情報の一致率が所定の閾値を超えなかったことに応じて、ユーザIDは、一致不成功と判定される。
【0086】
上述のように、ユーザマシン情報の一致率が80%を超えない場合には、ユーザID検証は失敗である。
【0087】
工程411において、OTPコントロールサーバは、ユーザID検証が不成功であったことを示すメッセージをオンライン決済ゲートウェイに返す。
【0088】
工程412において、オンライン決済ゲートウェイは、ユーザID検証が不成功であったことを示すメッセージをブラウザに転送する。
【0089】
工程413において、ブラウザは、ユーザID検証が不成功であったことを示すメッセージを受信し、そのメッセージをJSに返し、JSは呼び出される。
【0090】
工程414において、JSは、ショートメッセージ検証コード検証ページをリトリーブする。
【0091】
工程415において、JSは、ショートメッセージ検証コード検証ページを表示する。
【0092】
一般に、ショートメッセージ検証コード検証ページは、携帯電話番号またはその他のユーザ関連情報を入力するようユーザにプロンプトする。
【0093】
工程416において、JSは、ショートメッセージ送信要求をOTPコントロールサーバに送信する。
【0094】
ユーザがユーザの携帯電話番号またはその他のユーザ関連情報をショートメッセージ検証コード検証ページに入力した後、JSは、ショートメッセージ送信要求をユーザに送信する。
【0095】
工程417において、コントロールサーバは、ショートメッセージ送信要求をOTP認証プラットフォームに送信する。
【0096】
工程418において、OTP認証プラットフォームは、以前に(例えば、ユーザがアカウントを登録した時に)ユーザ情報を格納したビジネスシステムからユーザ情報をリトリーブする。ユーザ情報は、携帯電話番号、ユーザ名、電子メールアドレス、連絡先住所、または、その他のユーザ関連情報を含みうる。
【0097】
工程419において、OTP認証プラットフォームは、検証コードを生成する。OTP認証プラットフォームは、ユーザ情報に基づいて検証コードを生成する。
【0098】
工程420において、OTP認証プラットフォームは、ショートメッセージ送信要求をビジネスシステムに送信する。
【0099】
工程421において、ビジネスシステムは、ユーザによって登録された携帯電話にショートメッセージを送信する。
【0100】
ショートメッセージは、OTP認証プラットフォームによって生成された検証コードを含む。
図5は、携帯電話に表示されたショートメッセージの情報の内容の一例を示す。
【0101】
工程422において、ユーザがショートメッセージを受信した後、ユーザは、ショートメッセージに含まれる検証コードをウェブページのプロンプトされた位置に入力する。
【0102】
工程423において、JSは、ショートメッセージ検証要求をOTPコントロールサーバに送信する。ショートメッセージ検証要求は、ユーザが入力した検証コードを含む。
【0103】
工程424において、OTPコントロールサーバは、ショートメッセージ検証要求をOTP認証プラットフォームに転送する。
【0104】
工程425において、OTP認証プラットフォームは、検証メッセージに含まれる検証コードを検証する。
【0105】
工程426において、検証が成功した場合、OTP認証プラットフォームは、検証成功応答をOTPコントロールサーバに送信する。
【0106】
工程427において、OTPコントロールサーバは、検証成功応答をJSに送信する。
【0107】
工程428において、JSは、マシン情報キャプチャ要求をOTPコントロールに送信する。
【0108】
工程429において、OTPコントロールは、ユーザマシンの全マシン情報をキャプチャする。
【0109】
工程430において、OTPコントロールは、キャプチャしたマシン情報をJSに返す。
【0110】
OTPコントロールは、ランダムセッション鍵に基づいてマシン情報を暗号化する。
【0111】
工程431において、JSは、キャプチャされたマシン情報を送信するために、ブラウザを起動する。
【0112】
工程432において、ブラウザは、キャプチャされたマシン情報を含む要求メッセージをオンライン決済ゲートウェイに送信する。
【0113】
工程433において、オンライン決済ゲートウェイは、要求メッセージをOTPコントロールサーバに転送する。
【0114】
工程434において、OTPコントロールサーバは、ユーザマシン情報を更新する。
【0115】
工程435において、OTPコントロールサーバは、応答メッセージをオンライン決済ゲートウェイに送信する。
【0116】
工程436において、オンライン決済ゲートウェイは、応答メッセージをブラウザに転送する。
【0117】
工程437において、ブラウザは、JSを呼び出し、応答メッセージをJSに返す。
【0118】
工程438において、JSは、応答メッセージを受信し、ユーザID検証を完了させる。
【0119】
図1を再び参照すると、工程103は、ユーザIDの検証が成功した後、取引画像情報を生成し、ランダムセッション鍵に基づいて取引画像情報を暗号化し、取引画像情報をクライアントに送信する。
【0120】
サーバが、取引画像情報を生成してよい。
図7は、取引画像情報の一例を示す。さらに、サーバは、取引画像情報をクライアントに送信してよい。
【0121】
図6を参照すると、
図6は、クライアントが取引画像情報を取得する処理を示す。その処理について以下で説明する。
【0122】
工程601において、JSは、ユーザマシン情報検証結果をOTPコントロールに送信する。
【0123】
マシン検証の不成功に応答して、携帯電話ショートメッセージ検証アプローチが採用されてよい。それに応じて、携帯電話ショートメッセージ検証結果が、OTPコントロールに送信されてよい。
【0124】
工程602において、OTPコントロールは、取引画像情報要求をJSに送信する。
【0125】
工程603において、JSは、取引画像情報要求をブラウザに送信する。
【0126】
工程604において、ブラウザは、取引画像情報要求をオンライン決済ゲートウェイに送信する。
【0127】
工程605において、オンライン決済ゲートウェイは、取引画像情報要求をOTPコントロールサーバに転送する。
【0128】
工程606において、コントロールサーバは、取引画像情報要求をOTP認証プラットフォームに送信する。
【0129】
工程607において、OTP認証プラットフォームは、注文番号に基づいてビジネスシステムから取引情報をリトリーブする。
【0130】
OTP認証プラットフォームは、取引画像情報要求に対応する注文番号をビジネスシステムから取得し、注文番号に基づいて対応する取引情報を取得する。取引情報は、
図7に示すように、取引の内容、取引の金額または数量、取引時刻、ならびに、取引に関するその他の情報を含みうる。
【0131】
工程608において、OTP認証プラットフォームは、取引情報に基づいて画像要素を生成する。
【0132】
画像要素は、例えば、取引検証コード、要約情報、および、ベース画像などの要素を指しうる。画像要素は、取引画像情報を生成するために用いられてよい。
【0133】
工程609において、OTP認証プラットフォームは、取引画像情報を生成する。
【0134】
OTP認証プラットフォームは、画像要素を用いて取引画像情報を生成するよう構成された画像サーバを含んでよい。
【0135】
図8は、工程608および609で取引画像情報を生成する処理の一実施形態を示す。
【0136】
工程610において、OTP認証プラットフォームは、ランダムセッション鍵に基づいて取引画像情報を暗号化し、暗号化した取引画像情報をOTPコントロールサーバに送信する。
【0137】
工程611において、OTPコントロールサーバは、取引画像情報をオンライン決済ゲートウェイに送信する。
【0138】
工程612において、オンライン決済ゲートウェイは、取引画像情報をブラウザに転送する。
【0139】
工程613において、ブラウザは、取引画像情報を受信して、JSに取引画像情報を返し、JSは呼び出される。
【0140】
工程614において、JSは、OTPコントロールに取引画像情報を表示する。
【0141】
図8を参照すると、
図8は、OTP認証プラットフォーム上で取引画像情報を生成する処理の一実施形態を示す。処理は、以下の工程を含む。
【0142】
工程801において、OTPアルゴリズム駆動モジュールは、取引情報、ランダムセッション鍵、時刻、および、ユーザシード(user seed)に基づいて、取引検証コードを生成する。
【0143】
いくつかの実施形態において、時刻とは、取引時刻のことであり、ユーザシードとは、乱数(例えば、20バイトの乱数)のことである。固有のユーザシードが、各ユーザに割り当てられてよい。
【0144】
工程802において、OTPビジネスシステムは、取引情報およびランダムセッション鍵に基づいて、要約情報を生成する。各取引は、固有の要約情報を有する。
【0145】
工程803において、画像サーバは、ベース画像を生成する。
【0146】
工程804において、要約情報が、ベース画像に追加される。要約情報およびベース画像は、同じ色を有してよい。
【0147】
工程805では、取引情報および取引検証コードが、要約情報を含むベース画像に追加される。取引画像情報は、取引情報および取引検証コードが追加された後の要約情報を含むベース画像に対応する。このように、取引画像情報が生成される。
【0148】
図1を参照すると、工程105および106において、クライアントは、取引画像情報の確認を送信し、それに応答して、サーバは、ランダムセッション鍵に基づいて取引署名を検証する。
【0149】
ユーザは、取引画像情報を取得すると、取引画像情報から取引検証コードを取得し、取引検証コードを入力して取引を確認することができる。OTPコントロールは、ランダムセッション鍵に基づいて、取引画像情報および取引検証コードにデジタル署名して取引署名を生成し、確認として取引署名をOTP認証プラットフォームに送信する。OTP認証プラットフォームは、取引署名が正しいか否かを検証し、検証結果をクライアントに返す。
【0150】
図9は、取引署名を検証する処理の一実施形態を示す。
図9を参照すると、
図9は、以下の工程を含む。
【0151】
工程901において、JSは、取引画像情報表示要求をOTPコントロールに送信する。
【0152】
工程902において、OTPコントロールは、取引画像情報を表示する。
図7は、表示された取引画像情報の一例を示す。
【0153】
工程903では、ユーザが、OTPコントロールで取引検証コードを入力する。
【0154】
工程904において、OTPコントロールは、ランダムセッション鍵に基づいて、取引画像および取引検証コードにデジタル署名して、取引署名を生成する。
【0155】
工程905において、OTPコントロールは、取引署名を含む署名検証要求をJSに送信する。
【0156】
工程906において、JSは、署名検証要求をブラウザに送信する。
【0157】
工程907において、ブラウザは、署名検証要求をオンライン決済ゲートウェイに送信する。
【0158】
工程908において、オンライン決済ゲートウェイは、署名検証要求をOTPコントロールサーバに転送する。
【0159】
工程909において、OTPコントロールサーバは、署名検証要求をOTP認証プラットフォームに送信する。
【0160】
工程910において、OTP認証プラットフォームは、取引署名が正しいか否かを検証する。
【0161】
工程911において、OTP認証プラットフォームは、署名検証結果をOTPコントロールサーバに送信する。
【0162】
工程912において、OTPコントロールサーバは、署名検証結果をオンライン決済ゲートウェイに送信する。
【0163】
工程913において、オンライン決済ゲートウェイは、署名検証結果をブラウザに転送する。
【0164】
工程914において、ブラウザは、署名検証結果を受信して、JSに署名検証結果を返し、JSが呼び出される。
【0165】
工程915において、JSは、フォローアップ処理を実行する。
【0166】
上述の安全な認証処理が送信処理にランダムセッション鍵を追加するという事実により、取引画像情報が送信処理のどの部分においても改ざんされないことが保証される。また、取引画像情報は、コントロールに表示されてよい。ユーザがパスワード(すなわち取引検証コード)を入力すると、コントロールは、ランダムセッション鍵に基づいて取引画像情報およびパスワードにデジタル署名し、検証のために取引画像情報およびパスワードをOTPコントロールサーバに送信する。したがって、取引処理全体の安全性が確保される。
【0167】
上述のユーザは、OTPコントロールユーザである。OTPコントロールユーザは、OTPコントロールをインストールし、実名認証および携帯電話バインディングを行った(すなわち、ユーザの携帯電話がユーザのアカウントにリンクされている)ユーザである。
図10は、パスワードコントロールユーザがOTPコントロールユーザにアップグレードされる一実施形態を示す。
図10によると、OTPコントロールユーザにアップグレードする処理は、以下の工程を含む。
【0168】
ユーザは、ブラウザを開き(1001)、決済ウェブサイトアドレスまたは決済ユニフォームリソースロケータ(URL)をブラウザに入力する(1002)。ブラウザは、オンライン決済ゲートウェイからアップグレード情報を要求する(1003)。オンライン決済ゲートウェイは、アップグレードプロンプトを含むスクリプトをブラウザに送信する(1004)。ブラウザは、アップグレードプロンプトを表示する(1005)。ユーザは、ブラウザによって表示されたアップグレードプロンプトを見る(1006)。ユーザは、ブラウザによって表示されたアップグレードプロンプトをクリックまたはアクティブ化する(1007)。ブラウザは、ダウンロード要求をダウンロードサーバに送信する(1008)。ダウンロードサーバは、アップグレード情報をブラウザに送信する(1009)。ユーザは、ブラウザからアップグレード情報をインストールする(1010)。ユーザがアップグレード情報をインストールした後の最初の決済(1011)で、ブラウザは、要求メッセージをオンライン決済ゲートウェイに送信する(1012)。オンライン決済ゲートウェイは、ビジネスシステムからユーザタイプをリトリーブする(1013)。ビジネスシステムは、ユーザの本名が認証されているか否かを判定する(1014)。ユーザの本名が認証されていない場合、ビジネスシステムは、本名認証を要求するページをオンライン決済ゲートウェイに送信する(1015)。オンライン決済ゲートウェイは、本名認証ページをブラウザに返し(1016)、ブラウザは、ユーザに対して本名認証ページを表示する(1017)。ユーザは、ID情報およびクレジットカード情報をブラウザに入力し(1018)、ブラウザは、ID情報およびクレジットカード情報をオンライン決済ゲートウェイに送信する(1019)。オンライン決済ゲートウェイは、ユーザのIDを検証し、ユーザのIDの検証後に、決済のための資金をビジネスシステムに引き渡す(1020)。ビジネスシステムは、決済リリースメッセージをオンライン決済ゲートウェイに送信し(1021)、オンライン決済ゲートウェイは、決済リリースメッセージをブラウザに転送する(1022)。ブラウザは、ユーザに対して決済リリースメッセージを表示する(1023)。ユーザは、決済リリース情報および携帯電話情報をブラウザに入力する(1024)。ブラウザは、検証要求をオンライン決済ゲートウェイに送信する(1025)。オンライン決済ゲートウェイは、検証要求をビジネスシステムに転送する(1026)。ビジネスシステムは、検証結果をオンライン決済ゲートウェイに返す(1027)。オンライン決済ゲートウェイは、検証結果をブラウザに送信する(1028)。ブラウザは、ユーザに対して検証結果を表示する(1029)。
【0169】
このように、新しい申し込みについて、ユーザは、登録後に、
図10に示した処理に基づいてOTPコントロールユーザにアップグレードされる。
【0170】
さらに、工程102のユーザID検証処理において、サーバは、最初に、ユーザマシン情報を用いて、ユーザのIDを検証する。ユーザID検証が失敗した場合、サーバは、携帯電話ショートメッセージ検証アプローチを用いて、ユーザのIDを検証してよい。したがって、ユーザに関連する携帯電話番号が、安全な決済にとって重要である。そのため、ユーザに関連する携帯電話番号を変更するために、以下に記載する2つの方法の内のいずれかを利用する必要がある。
【0171】
ユーザに関連する携帯電話番号を変更するための一の方法は、ユーザに関連する電子メールアドレスに電子メールを送信する工程を含む。ユーザは、電子メールに含まれるリンクを用いて自分のIDを検証し、次いで、自分の携帯電話番号を更新する。
【0172】
ユーザに関連する携帯電話番号を変更するための他の方法は、ユーザがカスタマーサービスに電話することによって自分のIDを検証した後に携帯電話番号を更新する工程を含む。
【0173】
本願は、さらに、上述の方法の実施形態に対応するシステムの実施形態を提供する。
【0174】
図11は、オンライン取引用の安全な認証システムの一実施形態を示す。
【0175】
図11を参照すると、
図11は、OTPコントロール10と、OPTコントロールサーバ20と、OTP認証プラットフォーム30とを備えるオンラインの安全な認証システムの一実施形態を示す。
【0176】
OTPコントロール10およびOTPコントロールサーバ20は、OTPコントロール10とOTPコントロールサーバ20との間の通信を暗号化するためのランダムセッション鍵を生成し、ランダムセッション鍵に基づいてOTPコントロール10のユーザIDを検証するよう構成されている。
【0177】
OTP認証プラットフォーム30は、OTPコントロールサーバ20に接続されており、OTPコントロールサーバ20によって送信されたユーザID検証成功メッセージを受信した後に、取引画像情報を生成するよう構成されている。OTP認証プラットフォーム30は、ランダムセッション鍵に基づいて取引画像情報を暗号化し、取引画像情報をOTPコントロール10に送信する。OTPコントロール10が取引画像情報を確認した後、OTPコントロールサーバ20は、別のランダムセッション鍵に基づいて、取引署名を検証する。
【0178】
ランダムセッション鍵が上述の処理で生成されると、OTPコントロール10は、乱数を生成し、事前設定されたRSA公開鍵に基づいて乱数を暗号化して、暗号化した乱数をOTPコントロールサーバ20に送信する。OTPコントロールサーバ20は、暗号化された乱数に基づいて、別のランダムセッション鍵を生成して、そのランダムセッション鍵をOTPコントロール10に送信する。
【0179】
OTPコントロールのユーザIDが上述の処理で検証されると、OTPコントロール10は、ユーザマシン情報を抽出し、ランダムセッション鍵に基づいてユーザマシン情報を暗号化して、暗号化したユーザマシン情報をOTPコントロールサーバ20に送信する。OTPコントロールサーバ20は、ユーザマシン情報の一致度を決定する。ユーザマシン情報の一致度が所定の閾値を超えた場合、OTPコントロールサーバ20は、ユーザIDの検証が成功したと判定する。ユーザマシン情報の一致度が所定の閾値を超えなかった場合、OTPコントロールサーバ20は、ユーザIDの検証が失敗したと判定する。
【0180】
別の例では、OTPコントロールサーバ20は、キャプチャファクタを生成して、キャプチャファクタをOTPコントロール10に送信してもよい。その後、OTPコントロール10は、キャプチャファクタに基づいてユーザマシン情報を抽出し、他のランダムセッション鍵に基づいてユーザマシン情報およびキャプチャファクタを暗号化して、ユーザマシン情報およびキャプチャファクタをOTPコントロールサーバ20に送信する。OTPコントロールサーバ20は、キャプチャファクタに基づいて、ユーザマシン情報の一致度を検証してもよい。
【0181】
別の実施形態において、
図12に示すように、上述のユーザID検証が失敗した場合に、システムは、さらに、以下を備えてもよい。
【0182】
携帯電話ショートメッセージ送信要求を送信するよう構成されたクライアントスクリプトモジュール40。
【0183】
OTP認証プラットフォーム30は、さらに、携帯電話ショートメッセージ送信要求を受信した後に、ユーザ情報を取得し、携帯電話ショートメッセージ検証コードを生成して、携帯電話ショートメッセージ検証コードをユーザに関連する携帯電話に送信するよう構成されてよい。
【0184】
携帯電話ショートメッセージ検証コードを受信した後、ユーザは、携帯電話ショートメッセージ検証コードをクライアントスクリプトモジュール40に入力し、携帯電話ショートメッセージ検証コードをOTP認証プラットフォーム30に送信する。
【0185】
OTP認証プラットフォーム30は、さらに、携帯電話ショートメッセージ検証コードを検証するよう構成されてよい。携帯電話ショートメッセージ検証コードの検証成功に応じて、OTP認証プラットフォーム30は、ユーザID検証成功結果をクライアントスクリプトモジュール40に送信してよい。
【0186】
別の例では、OTP認証プラットフォーム30は、さらに、以下を備えてもよい。
【0187】
取引情報、ランダムセッション鍵、時刻、および、ユーザシードに基づいて、取引検証コードを生成するよう構成されたOTPアルゴリズム駆動モジュール32。
【0188】
取引情報およびランダムセッション鍵に基づいて、要約情報を生成するよう構成されたOTPビジネスシステム33。
【0189】
ベース画像を生成し、要約情報をベース画像に追加し、要約情報を含むベース画像に取引情報および取引検証コードを追加して、取引画像情報を生成するよう構成された画像サーバ31。
【0190】
上述の処理に基づいた取引署名の検証に対応して、OTPコントロール10は、取引検証コードを入力し、ランダムセッション鍵を用いて取引画像情報および取引検証コードにデジタル署名して取引署名を生成し、取引署名をOTP認証プラットフォーム30に送信するよう構成されている。
【0191】
OTP認証プラットフォーム30は、取引署名が正しいか否かを検証し、検証結果をOTPコントロール10に送信するよう構成されている。
【0192】
安全な認証システムの実施形態は、基本的に、方法の実施形態と類似しているので、簡潔にするために、説明を比較的簡略化している。方法の実施形態の一部の説明を用いて、システムの実施形態の対応する一部の説明とすることができる。
【0193】
以下では、本願の理解を助けるために、数例のハッカー攻撃を挙げて、本願の方法およびシステムが、フィッシング、トロイの木馬、および、トロイの木馬型フィッシングをどのように防ぎうるのかを説明する。
【0194】
1.決済ウェブサイトでのサイト内フィッシング
【0195】
図13を参照すると、通常、クライアントが購入したい商品を選択した後、ショッピングウェブサイトは、クライアントにレジ(例えば、レジ機能を備えたウェブページ)を提示する(1301)。クライアントは、選択した商品に関連する金額をレジで支払う(1302)。レジは、その支払いをショッピングウェブサイトに転送する(1303)。しかしながら、かかる取引は、最近現れたトロイの木馬ウイルスソフトウェアの変異型であるサイト内取引置換(intra−site transaction substitutions)にさらされる。トロイの木馬ウイルスソフトウェアは、決済ウェブサイト内に即時決済取引(例えば、「支払いを行う」)を作成し、その後、決済ウェブサイトはレジに飛んで、ユーザに支払いさせる。
【0196】
サイト内取引置換処理の一例も
図13に示されている。
【0197】
工程1301’において、ショッピングウェブサイトで商品を購入した後、ユーザは、購入を確認するためにクリックする。ブラウザが、ショッピングウェブサイトの決済ウェブサイトのレジに進むと、トロイの木馬は、例えば、ブラウザのURLフィールドを監視することにより、通常の決済処理を妨害する。
【0198】
工程1302’において、トロイの木馬は、決済ウェブサイトのブラウザを即時決済ページにリダイレクトする。
【0199】
工程1303’において、トロイの木馬は、「支払いを行う」命令を生成する。支払いの受取人すなわち受領者は、詐欺師のオンライン決済口座である。
【0200】
工程1304’において、ブラウザは、決済ウェブサイトのレジに進む。ユーザは、命令を完了させる必要があることを知る。しかしながら、ショッピングサイトへの支払いを正規の販売者にする代わりに、その命令は、詐欺師のオンライン決済口座に支払いを行う。
【0201】
工程1305’において、ユーザは、支払いを許可する。
【0202】
工程1306’において、ユーザは、トロイの木馬によって生成された即時決済命令に支払いを行う。フィッシング処理は終了する。
【0203】
本願では、ユーザの取引情報は、表示に向けて画像の形態でコントロールに送信される。さらに、処理全体が、ランダムセッション鍵によって暗号化される。ランダムセッション鍵は、アプリケーション層のデータを暗号化しうる。各コントロールのランダムセッション鍵が異なるため、ハッカーは、新たな取引を作成しても、この取引の画像をコントロールに送信することができない。ハッカーの画像は、ユーザのコントロールのランダムセッション鍵を用いても復号されえない。
【0204】
2.第三者の外部業者へのフィッシング
【0205】
図14を参照すると、通常の取引について、
図13の工程1301、1302、および、1303は、
図14の工程1401、1402、および、1403に対応する。したがって、工程1401、1402、および、1403の詳細については、簡単のために省略する。
図14は、第三者の外部業者へのフィッシングに含まれる工程を示す。
【0206】
工程1401’において、ユーザのマシンがトロイの木馬に感染した後、トロイの木馬は、ブラウザのURLアドレスフィールドを監視する。ユーザは、ショッピングウェブサイトで商品を購入した後、「購入を確認する」をクリックする。
【0207】
工程1402’において、ブラウザが決済ウェブサイトのレジに進む代わりに、トロイの木馬は、通常の決済処理を妨害し、別の第三者の外部業者にブラウザをリダイレクトする。
【0208】
工程1403’において、トロイの木馬は、クライアントにおいて詐欺師の外部商用口座番号を入力する。次いで、第三者の外部業者は、同じ金額の命令を生成する。この命令には、決済ウェブサイトを用いて支払いが行われる。
【0209】
工程1404’において、ブラウザは、決済ウェブサイトのレジに進む。この時点で、ユーザは、命令に対して支払いを行う必要があることを知る。しかしながら、この命令の支払いは、詐欺師の外部商用口座に送られる。
【0210】
工程1405’において、ユーザは、決済ウェブサイトのレジで支払いを行うよう選択する。
【0211】
工程1406’において、ユーザは、その命令について、第三者の外部業者に支払いを行う。決済ウェブサイトは、第三者の外部業者に支払いを行う。フィッシング処理は終了する。
【0212】
上述のフィッシング処理からわかるように、このタイプのトロイの木馬型フィッシングは、決済ウェブサイトの安全性に関係するだけでなく、フィッシングされた第三者の外部業者の安全性にも密接に関係する。外部業者の大多数は、オンライン取引のための安全なセキュリティシステムを持っていない。本願のソリューションを第三者の外部業者に適用できれば、かかるトロイの木馬を防止できる。例えば、決済ウェブサイトがクライアントコントロールおよびサーバサービスを提供するアプローチを用いて、フィッシングを防止できる。
【0213】
3.第三者の決済プラットフォームへのフィッシング
【0214】
図15を参照すると、通常の取引について、
図13の工程1301、1302、および、1303は、
図15の工程1501、1502、および、1503に対応する。
図15は、ユーザが決済ウェブサイトのレジにいる時に、トロイの木馬が別の第三者の決済プラットフォームでオンラインバンキングの入金命令を生成するトロイの木馬の例を示す。このように、ユーザは、オンラインバンキングの入金決済を行うようだまされる。
図15は、第三者の決済プラットフォームへのフィッシング処理を示す。
【0215】
工程1501’において、ユーザは、決済ウェブサイトのレジで入金動作を実行する。例えば、ユーザは、ショッピングウェブサイトで商品を購入し、決済に向けてレジに進みうる。ユーザは、「支払いを行う」即時決済取引を開始する。ユーザは、取引詳細をクリックして、支払いを完了させる。トロイの木馬は、ブラウザのURLアドレスフィールドを監視する。ユーザが支払いの準備をしたことに応答して、トロイの木馬は、通常の動作処理を妨害する。
【0216】
工程1502’において、トロイの木馬は、ブラウザを別の第三者の決済プラットフォームに導いて、詐欺師の口座番号を入力する。トロイの木馬は、以下の方法のいずれかを用いて、ブラウザを第三者の決済プラットフォームに導きうる。
【0217】
(1)トロイの木馬は、ブラウザが第三者の決済プラットフォームにリダイレクトされるように、ブラウザのリダイレクトアドレスを改変しうる。
【0218】
(2)トロイの木馬は、オンラインバンキングの命令送信フォームのリダイレクトアドレスを改変しうる。この方法は、
図15に示した処理とは少し異なる。トロイの木馬は、リモートサーバで命令を動的に生成した後に、リモートから命令をトロイの木馬に送信する。トロイの木馬は、ウェブページ内のフォーム情報を改ざんする。この方法は、トロイの木馬が出現し始めた頃には比較的よく見られた。
【0219】
(3)トロイの木馬は、比較的短期間に多数回のURLリダイレクトを実行しうる。例えば、ユーザがオンラインバンキング入金のためのリンクを開いた場合、トロイの木馬は、そのリンクを直接的に妨害するのではなく、ブラウザがオンラインバンキングページに進んだ後に第三者の決済プラットフォームにブラウザをリダイレクトする。
【0220】
工程1502’でトロイの木馬がブラウザを何回リダイレクトさせたかに関わらず、工程1503’では、ブラウザは、第三者の決済プラットフォームに進んで、オンラインバンキングの入金命令を生成する。
【0221】
工程1504’において、ユーザは、オンラインバンキング命令に対して支払いを行う必要があることをブラウザで知る。支払銀行および金額は、通常の取引処理と同じであるが、オンラインバンキング入金の受領者は、決済ウェブサイトではない。代わりに、詐欺師の口座が受け取り先になる。
【0222】
工程1505’において、ユーザは、入金の受け取り先が詐欺師の口座であることに気づくことなく、入金を完了させる。
【0223】
工程1506’において、銀行は、詐欺師の口座に送金する。フィッシング処理は終了する。
【0224】
上述の処理からわかるように、トロイの木馬型フィッシングは、決済ウェブサイトの安全性に関係するだけでなく、フィッシングされた第三者の決済プラットフォームの安全性にも関係する。本願の方法およびシステムを実施して、本願の方法およびシステムを第三者の決済プラットフォームに適用すれば、この種のトロイの木馬を防止できる。
【0225】
概して、本願は、少なくとも以下の利点を有する。
【0226】
第1に、本願は、例えば、OTP技術、パスワード制御技術、および、取引画像署名技術などの技術に基づいて、オンライン取引の安全な認証を実現する。本願は、さらに、ハードウェア製品の制限を克服する。例えば、ハードウェア製品の制限は、動作範囲、サービス、および、技術向上を含む。
【0227】
第2に、取引画像の安全な通信のためにランダムセッション鍵を利用することにより、本願は、ユーザ取引の二重の確認を実現する。換言すると、本願は、第2世代のOTP技術を実装して、フィッシング、トロイの木馬、および、トロイの木馬型フィッシングの防止に関してソフトウェア製品が持つ既存の課題を解決する。
【0228】
第3に、OTPコントロールサーバおよびOTP認証プラットフォームを確立することにより、本願は、OTP技術のバッチ取引を実施する。
【0229】
第4に、本願によって提供される安全な認証システムは、ソフトウェア技術で実施されるため、普及させやすい。第三者のシステム(第三者の業者または第三者の決済プラットフォームなど)で実施されれば、本願は、オンライン取引の安全性を強化しうる。
【0230】
本願に含まれる各実施形態は、漸進的に記載されている。各実施形態の説明は、他の実施形態と異なる領域に焦点を当てており、実施形態の記載は、各実施形態の同一または類似の部分について相互に参照できる。
【0231】
以上、本願に開示されたオンライン取引のための安全な認証方法およびシステムについて、詳細に説明した。本明細書は、具体的な実施形態を用いて、本願の原理および実装の形態を説明している。上記の実施形態は、単に、本願の方法およびシステムならびにその中心概念の理解を助けるよう意図されたものである。さらに、当業者は、本願に基づいて、具体的な応用例および応用例の範囲に対して修正を加えることができる。要するに、本開示の内容は、いかなる形でも本願を限定するものとして理解されるべきではない。
【0232】
上述の実施形態は、理解しやすいようにいくぶん詳しく説明されているが、本発明は、提供された詳細事項に限定されるものではない。本発明を実施する多くの代替方法が存在する。開示された実施形態は、例示であり、限定を意図するものではない。
適用例1:オンライン取引のための安全な認証方法であって、1または複数のコンピュータプロセッサを用いて、クライアントおよびサーバの間の通信を暗号化するためのランダムセッション鍵を生成し、前記生成されたランダムセッション鍵に基づいて、前記クライアントを利用するユーザのユーザIDを検証し、前記ユーザIDの前記検証が成功した場合に、取引画像情報を生成し、前記ランダムセッション鍵に基づいて前記取引画像情報を暗号化し、前記暗号化された取引画像情報を前記クライアントに送信し、取引署名を含む、前記取引画像情報の確認を受信し、前記ランダムセッション鍵に基づいて前記取引署名を検証すること、を備える、方法。
適用例2:適用例1に記載の方法であって、前記ランダムセッション鍵の生成は、前記クライアントによって生成され暗号化された乱数を受信し、前記暗号化された乱数に基づいて前記ランダムセッション鍵を生成し、前記ランダムセッション鍵を前記クライアントに送信すること、を備える、方法。
適用例3:適用例1に記載の方法であって、前記ユーザIDの検証は、ユーザマシン情報を前記クライアントから受信し、前記ユーザマシン情報が、以前に格納されたユーザマシン情報と所定の一致度まで一致するか否かを判定すること、を備える、方法。
適用例4:適用例3に記載の方法であって、さらに、キャプチャファクタを生成し、前記キャプチャファクタを前記クライアントに送信し、前記暗号化されたユーザマシン情報および前記暗号化されたキャプチャファクタを前記クライアントから受信し、前記ランダムセッション鍵に基づいて、前記受信したキャプチャファクタおよびユーザマシン情報を復号し、前記受信したキャプチャファクタに基づいて前記ユーザマシン情報の一致度を決定すること、を備える、方法。
適用例5:適用例3に記載の方法であって、さらに、前記ユーザIDの検証が失敗した場合に、携帯電話ショートメッセージ送信要求が前記クライアントから受信されたか否かを判定する工程と、前記携帯電話ショートメッセージ送信要求が前記クライアントから受信された場合に、ユーザ情報を取得する工程と、携帯電話ショートメッセージ検証コードを生成する工程と、前記携帯電話ショートメッセージ検証コードを前記ユーザに関連する携帯電話に送信する工程と、を実行する工程、前記携帯電話ショートメッセージ検証コードを前記クライアントから受信する工程と、前記携帯電話ショートメッセージ検証コードを検証する工程と、前記携帯電話ショートメッセージ検証コードの検証が成功した場合に、ユーザID検証成功結果を前記クライアントに送信する工程と、を実行することを備える、方法。
適用例6:適用例1に記載の方法であって、前記取引画像情報の生成は、取引情報、前記ランダムセッション鍵、および、ユーザシードに基づいて、取引検証コードを生成し、前記取引情報および前記ランダムセッション鍵に基づいて要約情報を生成し、ベース画像を生成し、前記要約情報を前記ベース画像に追加し、前記取引情報および前記取引検証コードを前記ベース画像に追加して、前記取引画像情報を生成すること、を備える、方法。
適用例7:適用例6に記載の方法であって、前記取引署名の検証は、前記取引署名を前記クライアントから受信し、前記取引署名が正しいか否かを検証し、検証結果を前記クライアントに送信すること、を備える、方法。
適用例8:オンライン取引のための安全な認証システムであって、ワンタイムパスワード(OTP)コントロール部と、OTPコントロールサーバと、OTP認証プラットフォームと、を備え、前記OTPコントロール部およびOTPコントロールサーバは、前記OTPコントロール部と前記OTPコントロールサーバとの間の暗号化通信のためのランダムセッション鍵を生成し、前記ランダムセッション鍵に基づいて前記OTPコントロール部のユーザIDを検証するよう構成され、前記OTP認証プラットフォームは、前記OTPコントロールサーバに接続され、前記OTPコントロールサーバによって送信されたユーザID検証成功メッセージを受信した後に、取引画像情報を生成し、ランダムセッション鍵に基づいて前記取引画像情報を暗号化し、前記取引画像情報を前記OTPコントロール部に送信し、前記OTPコントロール部が前記取引画像情報を確認した後に、前記ランダムセッション鍵に基づいて取引署名を検証する、システム。
適用例9:適用例8に記載のシステムであって、前記ランダムセッション鍵が生成されると、前記OTPコントロール部は、乱数を生成し、事前設定されたRSA公開鍵に基づいて前記乱数を暗号化して、前記暗号化された乱数を前記OTPコントロールサーバに送信し、前記OTPコントロールサーバは、前記暗号化された乱数に基づいて別のランダムセッション鍵を生成して、前記別のランダムセッション鍵を前記OTPコントロール部に送信する、システム。
適用例10:適用例8に記載のシステムであって、前記OTPコントロール部は、ユーザマシン情報を抽出し、前記ランダムセッション鍵に基づいて前記ユーザマシン情報を暗号化し、前記ユーザマシン情報を前記OTPコントロールサーバに送信し、前記OTPコントロールサーバは、前記ユーザマシン情報の一致度を検証し、前記ユーザマシン情報の前記一致度が所定の閾値を超えた場合、前記OTPコントロールサーバは、前記ユーザIDの検証が成功したことを示す結果を送信し、前記ユーザマシン情報の前記一致度が所定の閾値を超えなかった場合、前記OTPコントロールサーバは、前記ユーザIDの検証が失敗したことを示す結果を送信する、システム。
適用例11:適用例10に記載のシステムであって、前記OTPコントロールサーバは、キャプチャファクタを生成して、前記キャプチャファクタを前記OTPコントロール部に送信し、前記OTPコントロール部は、前記キャプチャファクタに基づいてユーザマシン情報を抽出し、前記ランダムセッション鍵を用いて前記ユーザマシン情報および前記キャプチャファクタを暗号化し、前記暗号化されたユーザマシン情報およびキャプチャファクタを前記OTPコントロールサーバに送信し、前記OTPコントロールサーバは、前記キャプチャファクタに基づいて、前記ユーザマシン情報の前記一致度を検証する、システム。
適用例12:適用例10に記載のシステムであって、前記ユーザIDの検証が失敗した場合、前記システムにおいて、前記OTP認証プラットフォームは、ユーザ情報を取得し、携帯電話ショートメッセージ送信要求を受信した後、前記OTPコントロールサーバは、携帯電話ショートメッセージ検証コードを生成して、前記携帯電話ショートメッセージ検証コードを前記OTPコントロール部に関連する携帯電話に送信し、前記OTPコントロールサーバは、前記ショートメッセージ検証コードを検証し、前記ショートメッセージ検証コードの検証が成功した場合、前記OTPコントロールサーバは、ユーザID検証成功結果を前記OTPコントロール部に送信する、システム。
適用例13:適用例8に記載のシステムであって、前記OTP認証プラットフォームは、取引情報、前記ランダムセッション鍵、時刻、および、ユーザシードに基づいて、取引検証コードを生成するよう構成されたOTPアルゴリズム駆動モジュールと、前記取引情報および前記ランダムセッション鍵に基づいて、要約情報を生成するよう構成されたOTPビジネスシステムと、ベース画像を生成し、前記要約情報を前記ベース画像に追加し、前記要約情報を含む前記ベース画像に前記取引情報および取引検証コードを追加して、前記取引画像情報を生成するよう構成された画像サーバと、を備える、システム。
適用例14:適用例8に記載のシステムであって、前記取引署名の検証において、前記OTPコントロール部は、前記取引検証コードを入力し、前記ランダムセッション鍵に基づいて前記取引画像情報および前記取引検証コードにデジタル署名して前記取引署名を生成し、前記取引署名を前記OTP認証プラットフォームに送信し、前記OTP認証プラットフォームは、前記取引署名が正しいか否かを検証し、検証結果を前記OTPコントロール部に送信する、システム。
適用例15:オンライン取引の安全な認証のためのコンピュータプログラム製品であって、前記コンピュータプログラム製品は、持続性のコンピュータ読み取り可能な記憶媒体内に具現化され、1または複数のコンピュータプロセッサを用いて、クライアントおよびサーバの間の通信を暗号化するためのランダムセッション鍵を生成するためのコンピュータ命令と、前記生成されたランダムセッション鍵に基づいて、前記クライアントを利用するユーザのユーザIDを検証するためのコンピュータ命令と、前記ユーザIDの前記検証が成功した場合に、取引画像情報を生成し、前記ランダムセッション鍵に基づいて前記取引画像情報を暗号化し、前記暗号化された取引画像情報を前記クライアントに送信するためのコンピュータ命令と、取引署名を含む、前記取引画像情報の確認を受信するためのコンピュータ命令とは、前記ランダムセッション鍵に基づいて前記取引署名を検証するためのコンピュータ命令と、を備える、コンピュータプログラム製品。
適用例16:適用例15に記載のコンピュータプログラム製品であって、前記ランダムセッション鍵を生成することは、前記クライアントによって生成され暗号化された乱数を受信すること、前記暗号化された乱数に基づいて前記ランダムセッション鍵を生成すること、前記ランダムセッション鍵を前記クライアントに送信すること、を備える、コンピュータプログラム製品。
適用例17:適用例15に記載のコンピュータプログラム製品であって、前記ユーザIDを検証することは、ユーザマシン情報を前記クライアントから受信すること、前記ユーザマシン情報が、以前に格納されたユーザマシン情報と所定の一致度まで一致するか否かを判定すること、を備える、コンピュータプログラム製品。
適用例18:適用例17に記載のコンピュータプログラム製品であって、さらに、キャプチャファクタを生成するためのコンピュータ命令と、前記キャプチャファクタを前記クライアントに送信するためのコンピュータ命令と、前記暗号化されたユーザマシン情報および前記暗号化されたキャプチャファクタを前記クライアントから受信するためのコンピュータ命令と、前記ランダムセッション鍵に基づいて、前記受信したキャプチャファクタおよびユーザマシン情報を復号するためのコンピュータ命令と、前記受信したキャプチャファクタに基づいて前記ユーザマシン情報の一致度を決定するためのコンピュータ命令と、を備える、コンピュータプログラム製品。
適用例19:適用例17に記載のコンピュータプログラム製品であって、さらに、前記ユーザIDの検証が失敗した場合に、携帯電話ショートメッセージ送信要求が前記クライアントから受信されたか否かを判定するためのコンピュータ命令と、前記携帯電話ショートメッセージ送信要求が前記クライアントから受信された場合に、ユーザ情報を取得し、携帯電話ショートメッセージ検証コードを生成し、前記携帯電話ショートメッセージ検証コードを前記ユーザに関連する携帯電話に送信するためのコンピュータ命令と、前記携帯電話ショートメッセージ検証コードを前記クライアントから受信するためのコンピュータ命令と、前記携帯電話ショートメッセージ検証コードを検証するためのコンピュータ命令と、前記携帯電話ショートメッセージ検証コードの検証が成功した場合に、ユーザID検証成功結果を前記クライアントに送信するためのコンピュータ命令と、を備える、コンピュータプログラム製品。
適用例20:適用例15に記載のコンピュータプログラム製品であって、前記取引画像情報を生成することは、取引情報、前記ランダムセッション鍵、および、ユーザシードに基づいて、取引検証コードを生成すること、前記取引情報および前記ランダムセッション鍵に基づいて要約情報を生成すること、ベース画像を生成すること、前記要約情報を前記ベース画像に追加すること、前記取引情報および前記取引検証コードを前記ベース画像に追加して、前記取引画像情報を生成すること、を備える、コンピュータプログラム製品。
適用例21:適用例20に記載のコンピュータプログラム製品であって、前記取引署名を検証することは、前記取引署名を前記クライアントから受信すること、前記取引署名が正しいか否かを検証すること、検証結果を前記クライアントに送信することと、を備える、コンピュータプログラム製品。
適用例22:オンライン取引のための安全な認証クライアントであって、少なくとも1つのプロセッサであって、前記クライアントおよびサーバの間の通信を暗号化するためのランダムセッション鍵を受信し、前記受信したランダムセッション鍵に基づいてユーザのユーザマシン情報を暗号化し、前記暗号化されたユーザマシン情報を前記サーバに送信し、暗号化された取引画像情報を前記サーバから受信し、前記取引画像情報の確認を暗号化し、前記取引画像情報の前記確認を前記サーバに送信するように構成されているプロセッサと、前記プロセッサに接続され、前記プロセッサに命令を提供するメモリと、
を備える、クライアント。
適用例23:適用例22に記載のクライアントであって、前記ランダムセッション鍵の受信は、乱数を生成し、事前設定されたRSA公開鍵に基づいて前記乱数を暗号化し、前記暗号化された乱数を前記サーバに送信すること、を備える、クライアント。
適用例24:適用例22に記載のクライアントであって、前記ユーザマシン情報の暗号化は、前記ユーザの前記ユーザマシン情報を抽出し、前記ランダムセッション鍵に基づいて前記ユーザマシン情報を暗号化すること、を備える、クライアント。
適用例25:適用例24に記載のクライアントであって、前記ユーザマシン情報の抽出は、キャプチャファクタを前記サーバから受信し、前記受信したキャプチャファクタに関連する前記ユーザマシン情報を抽出し、前記ランダムセッション鍵に基づいて前記ユーザマシン情報を暗号化し、前記暗号化されたユーザマシン情報を前記サーバに送信すること、を備える、クライアント。
適用例26:適用例22に記載のクライアントであって、前記少なくとも1つのプロセッサは、さらに、携帯電話ショートメッセージ送信要求を前記サーバに送信し、携帯電話ショートメッセージ検証コードを前記サーバから受信し、前記携帯電話ショートメッセージ検証コードを前記サーバに送信し、ユーザID検証成功結果を前記サーバから受信するように構成されている、クライアント。