JP6021923B2 - オンライン取引のための安全な認証方法およびシステム - Google Patents

Description

［他の出願の相互参照］
本願は、全ての目的のために参照により本明細書に組み込まれる、２０１１年１１月４日出願の発明の名称を「オンライン取引のための安全な認証方法およびシステム（Ａ ＳＥＣＵＲＥ ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ ＭＥＴＨＯＤ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＯＮＬＩＮＥ ＴＲＡＮＳＡＣＴＩＯＮＳ）」とする中国特許出願第２０１１１０３４６５０８．３号に基づく優先権を主張する。

本願は、オンライン取引のための安全な認証方法およびシステムに関する。

日々のインターネットの発展と成長により、オンライン取引が、毎日のビジネス活動を行うための重要な方法になってきた。しかしながら、オンライン取引は、通常、インターネット接続を必要とする。ユーザは、通常、取引決済処理の際にインターネットに接続されたコンピュータを通してパスワードを入力する必要がある。取引決済中にハッカー攻撃が起こった場合、ユーザアカウントに対するパスワードが容易に暴かれ、その結果、ユーザが経済的な損失を被る可能性がある。

ハッカー攻撃のいくつかの形態としては、フィッシング、トロイの木馬、および、トロイの木馬型フィッシング（Ｔｒｏｊａｎ ｐｈｉｓｈｉｎｇ）が挙げられる。フィッシングとは、偽の電子メールまたはウェブサイトに個人情報を送るようユーザに要求するなど詐欺的な手段でハッカーがユーザのパスワードを取得するために利用する方法のことである。トロイの木馬とは、ユーザのマシンに不正プログラムを侵入させることにより、ユーザがハッカーに代わって支払いをするようにユーザの取引を改竄するためにハッカーが使用する方法のことである。トロイの木馬型フィッシングとは、以下を完了させるためにトロイの木馬およびフィッシングを同時に用いる方法のことである。ユーザの取引を乗っ取り、第三者のウェブサイト上で取引を作成し、ユーザの取引の表示を改竄ざんし、ユーザが見たい取引を提示し、第三者のウェブサイト上でハッカーの代わりにユーザに支払いをさせる。

取引の安全性を高める目的で、パスワード制御技術および動的パスワード（ワンタイムパスワード、略してＯＴＰ、すなわち、機会ごとに１つのパスワードが発行される）技術が、オンライン取引の保護を改善するために開発されてきた。しかしながら、最も初期のパスワード制御技術は、静的パスワード保護プラグインであり、第１世代のＯＴＰ技術は、パスワードの安全性を向上させるためだけに設計されたもので、それらのＯＴＰ技術は、フィッシングおよびトロイの木馬に対する防御をほとんど提供しなかった。第２世代のＯＴＰ技術は、取引情報を外部入力として用いてパスワードを生成する。しかしながら、この場合に生成されたパスワードは、パスワードの安全性に基づくと、もはや安全ではない。結果的に、安全性は向上するが、主に利用されている第２世代ＯＴＰ技術は、ＵＳＢキーなどのハードウェア製品に依存している。しかしながら、ハードウェア製品には、動作範囲および耐用年数の両方に関して制限がある。特に、技術がアップグレードされると、一般に、新しいハードウェア技術を導入して、ハードウェア製品もアップグレードする必要がある。

したがって、ハードウェアを利用することなしに第２世代ＯＴＰ技術を実装しつつ、フィッシング、トロイの木馬、および、トロイの木馬型フィッシングに対する防御を行うことが望ましい。

以下の詳細な説明と添付の図面において、本発明の様々な実施形態を開示する。

オンライン取引のための安全な認証方法の一実施形態を示すフローチャート。

クライアントおよびサーバの間の通信を暗号化するためのランダムセッション鍵を生成する処理の一実施形態を示すフローチャート。

ユーザマシン情報を用いてユーザＩＤを検証する処理の一実施形態を示すフローチャート。

携帯電話ショートメッセージを用いてユーザＩＤを検証する一実施形態を示すフローチャート。

携帯電話ショートメッセージ情報の内容の一実施形態を示す図。

取引画像情報を取得する処理の一実施形態を示すフローチャート。

取引画像情報の一例を示す図。

取引画像情報を生成する処理の一実施形態を示すフローチャート。

取引署名を検証する処理の一実施形態を示すフローチャート。

パスワードコントロールユーザがＯＴＰコントロールユーザにアップグレードされる一実施形態を示すフローチャート。

オンライン取引のための安全な認証システムの一実施形態を示す構造図。

オンライン取引のための安全な認証システムの別の実施形態を示す構造図。

決済ウェブサイトがウェブサイト内でフィッシングされる一実施形態を示す図。

ユーザが第三者の外部業者にフィッシングされる一実施形態を示す図。

ユーザが第三者の決済プラットフォームにフィッシングされる一実施形態を示す図。

本発明は、処理、装置、システム、物質の組成、コンピュータ読み取り可能な格納媒体上に具現化されたコンピュータプログラム製品、および／または、プロセッサ（プロセッサに接続されたメモリに格納および／またはそのメモリによって提供される命令を実行するよう構成されたプロセッサ）を含め、様々な形態で実装されうる。本明細書では、これらの実装または本発明が取りうる任意の他の形態を、技術と呼ぶ。一般に、開示された処理の工程の順序は、本発明の範囲内で変更されてもよい。特に言及しない限り、タスクを実行するよう構成されるものとして記載されたプロセッサまたはメモリなどの構成要素は、ある時間にタスクを実行するよう一時的に構成された一般的な構成要素として、または、タスクを実行するよう製造された特定の構成要素として実装されてよい。本明細書では、「プロセッサ」という用語は、１または複数のデバイス、回路、および／または、コンピュータプログラム命令などのデータを処理するよう構成された処理コアを指すものとする。

以下では、本発明の原理を示す図面を参照しつつ、本発明の１または複数の実施形態の詳細な説明を行う。本発明は、かかる実施形態に関連して説明されているが、どの実施形態にも限定されない。本発明の範囲は、特許請求の範囲によってのみ限定されるものであり、多くの代替物、変形物、および、等価物を含む。以下の説明では、本発明の完全な理解を提供するために、多くの具体的な詳細事項が記載されている。これらの詳細事項は、例示を目的としたものであり、本発明は、これらの具体的な詳細事項の一部または全てがなくとも特許請求の範囲に従って実施可能である。簡単のために、本発明に関連する技術分野で周知の技術要素については、本発明が必要以上にわかりにくくならないように、詳細には説明していない。

上述の本願の課題、特徴、および利点をより容易に理解できるように、以下では、添付の図面および具体的な実施形態を参照しつつ、本願について詳細に説明する。

本願は、ハードウェア製品が動作範囲、サービス、および、技術向上に関して持つ問題、ならびに、オンライン取引がフィッシング、トロイの木馬、および、トロイの木馬型フィッシングに対する防御で現在直面している問題の両方を最小限に抑えることができるオンライン取引のための安全な認証方法およびシステムをソフトウェアの形態で実施する。

以下では、図１から図９を参照して、本願の処理について詳述する。

図１から図９の処理は、ＯＴＰコントロール、ＪａｖａＳｃｒｉｐｔ（登録商標）（ＪＳ、コンピュータスクリプト言語の一種）、クライアントに配置されたブラウザ、オンライン決済ゲートウェイ、ＯＴＰコントロールサーバ（図ではコントロールサーバと省略）、ＯＴＰ認証プラットフォーム、ビジネスシステム、および、サーバ側データベースを含む。ＯＴＰコントロールは、クライアントマシン（例えば、パーソナルコンピュータ、スマートフォン、タブレット、または、その他の適切なデバイス）にインストールされており、ＯＴＰコントロールサーバおよびＯＴＰ認証プラットフォームと協働して機能することで、オンライン取引のための安全な認証を達成する。ＯＴＰコントロールサーバは、主に、ＯＴＰコントロールのユーザＩＤを検証し、ＯＴＰ認証プラットフォームは、主に、取引検証を完了させるよう機能する。オンライン決済セキュア・ソケット・レイヤ（ＳＳＬ）サーバが、オンライン取引におけるオンライン決済を完了させる。ビジネスシステムは、主に、オンライン取引のデータを処理する。

図１を参照する。図１は、クライアントおよびサーバの間で暗号化された通信を行うためのオンライン取引の安全な認証処理の一実施形態を示す。この処理は、サーバ上で実行されてよく、クライアントとの協働を必要とする。処理は、以下の工程を含む。

工程１０１において、サーバは、ランダムセッション鍵を生成する。

ランダムセッション鍵の生成は、クライアントおよびサーバがランダムセッション鍵を交換することを含みうる。いくつかの実施形態において、クライアントは、乱数を生成して、その乱数をサーバに送信し；サーバは、ランダムセッション鍵およびキャプチャファクタ（ｃａｐｔｕｒｅ ｆａｃｔｏｒｓ）を生成して、それらのランダムセッション鍵およびキャプチャファクタをクライアントに返す。この工程の詳細については、図２を参照して後述する。

工程１０２では、クライアントのユーザＩＤが、ランダムセッション鍵に基づいて検証される。この時点でのクライアントの検証は、トロイの木馬ソフトウェアによるセッションの乗っ取りを防ぐ。図３および図４を参照して、２つの検証アプローチについて後述する。

工程１０３では、ユーザＩＤの検証が成功したか否かが判定される。検証が成功した場合、工程１０４において取引画像情報が生成され、ランダムセッション鍵に基づいて暗号化され、クライアントに送信される。そうでない場合、工程１０７において検証失敗の状態を示す検証結果が、クライアントに送信される。

工程１０５では、取引画像の確認が受信される。いくつかの実施形態において、確認は、取引署名を含む。工程１０６では、取引署名がランダムセッション鍵に基づいて正しく検証されうるか否かが判定される。検証結果は、工程１０７においてクライアントに送信される。

図２は、ランダムセッション鍵を生成するための処理の一実施形態を示す。処理２００は、処理１００の工程１０１を実行するために用いられてよい。処理に関わる構成要素が図の上部に示されている。ブラウザ（ブラウザ部）、ＪＳ（ＪＳ部）、および、ＯＴＰコントロール（ＯＴＰコントロール部）は、クライアント側にあり、オンライン決済ゲートウェイ、コントロールサーバ、および、データベースは、サーバ側にある。処理は、以下の工程を含む。

工程２０１において、ユーザは精算の準備ができているため、ウェブページはレジページへと移行する。

工程２０２において、ＪａｖａＳｃｒｉｐｔ（登録商標）（ＪＳ）は、ＯＴＰコントロールを初期化する。

工程２０３において、ＪＳは、ランダムセッション鍵要求を生成し、ＯＴＰコントロールにランダムセッション鍵要求を送信する。

工程２０４において、ＯＴＰコントロールは、乱数を生成する。例えば、乱数は、２４バイト乱数であってよい。

工程２０５において、ＯＴＰコントロールは、事前設定されたＲＳＡ公開鍵を用いて、生成された乱数を暗号化する。ＲＳＡは、当業者に周知の公開鍵暗号化アルゴリズムである。

工程２０６において、ＯＴＰコントロールは、暗号化された乱数をＪＳに返す。

工程２０７において、ＪＳは、ブラウザを起動して、セッション鍵交換要求を送信する。

工程２０８において、ブラウザは、セッション鍵交換要求をオンライン決済ゲートウェイに送信する。

工程２０９において、オンライン決済ゲートウェイは、ＯＴＰコントロールサーバにメッセージを送信する。

送信されたメッセージは、セッション鍵交換要求を含む。

工程２１０において、ＯＴＰコントロールサーバは、メッセージを復号し、ＯＴＰコントロールによって生成された乱数を取得する。

例えば、ＯＴＰコントロールサーバは、ＲＳＡ秘密鍵に基づいて、メッセージを復号してＯＴＰコントロールの２４バイト乱数を取得する。

工程２１１において、ＯＴＰコントロールサーバは、乱数を生成する。例えば、乱数は、１２バイト乱数であってよい。

工程２１２において、ＯＴＰコントロールサーバは、生成した乱数と、クライアント側でＯＴＰコントロールによって送信された乱数とを結合する。例えば、ＯＴＰコントロールサーバは、ＯＴＰコントロールの２４バイト乱数の最初の１２バイトをＯＴＰコントロールサーバの１２バイト乱数と結合して、２４バイトのランダムセッション鍵を生成することができる。

工程２１３において、ＯＴＰコントロールサーバは、２４バイトのランダムセッション鍵をデータベースに格納する。

工程２１４において、ＯＴＰコントロールサーバは、キャプチャファクタを生成する。

例えば、キャプチャファクタは、ランダムに選択されたＮ個の乱数のセットを含んでよく、その乱数のセットは、工程１０２においてユーザマシン情報をキャプチャして、キャプチャしたユーザマシン情報を検証するために用いられる。Ｎは、任意の正の整数であってよい。

工程２１５において、ＯＴＰコントロールサーバは、ＯＴＰコントロールの２４バイト乱数に基づいて、１２バイト乱数およびキャプチャファクタの両方を暗号化する。

工程２１６において、ＯＴＰコントロールサーバは、セッション鍵交換応答をオンライン決済ゲートウェイに送信する。

工程２１７において、オンライン決済ゲートウェイは、セッション鍵交換応答をブラウザに転送する。

工程２１８において、ブラウザは、セッション鍵交換応答を受信し、ＪＳにセッション鍵交換応答を送信し、ＪＳは呼び出される。

工程２１９において、ＪＳは、１２バイト乱数およびキャプチャファクタを含む暗号化された情報を受信する。

工程２２０において、ＪＳは、暗号化された情報を含むマシン情報検証要求をＯＴＰコントロールに送信する。

工程２２１において、ＯＴＰコントロールは、自身の生成した２４バイト乱数に基づいて、暗号化された情報を復号して、ＯＴＰコントロールサーバの１２バイト乱数を取得する。

工程２２２において、ＯＴＰコントロールは、自身の生成した２４バイト乱数の最初の１２バイトと、ＯＴＰコントロールサーバによって生成された復号済みの１２バイト乱数とを用いて、ランダムセッション鍵を取得する。その後のメッセージが、ランダムセッション鍵に基づいて暗号化されうる。

工程２２３において、ＯＴＰコントロールは、さらに、暗号化された情報からキャプチャファクタを取得する。上述のように、ランダムセッション鍵は、ＯＴＰコントロールおよびＯＴＰコントロールサーバの間で生成され、ＯＴＰコントロールおよびＯＴＰコントロールサーバの各々が、ランダムセッション鍵の半分を生成する。したがって、ランダムセッション鍵は、非常に安全である。

図１の工程１０２を参照すると、クライアントのユーザＩＤの検証は、少なくとも２つのアプローチを含む。一方のアプローチでは、図３に示すように、ユーザマシン情報を用いて、検証が行われてもよい。もう一方のアプローチでは、図４に示すように、携帯電話のショートメッセージを用いて、クライアントのユーザＩＤが検証されてもよい。

図３は、ユーザマシン情報を用いてユーザＩＤを検証する処理の一実施形態を示す。処理３００は、ランダムセッション鍵が生成された後に、処理１００の工程１０２を実行するために用いられてよい。処理３００は、以下の工程を含む。

工程３０１において、ＪＳは、ランダムセッション鍵とキャプチャファクタとを含むセッション鍵応答メッセージをＯＴＰコントロールに送信する。

工程３０２において、ＯＴＰコントロールは、受信したセッション鍵応答メッセージからランダムセッション鍵およびキャプチャファクタを取得する。

ＯＴＰコントロールは、自身が生成した２４バイト乱数を用いて、セッション鍵応答メッセージを復号し、ＯＴＰコントロールサーバの復号された１２バイト乱数を用いて、自身が生成した２４バイト乱数の最後の１２バイトと置き換える。その結果、ＯＴＰコントロールは、ランダムセッション鍵を取得する。

工程３０３において、ＯＴＰコントロールは、ユーザマシン情報を抽出する。

ＯＴＰコントロールは、キャプチャファクタに基づいてユーザマシン情報を抽出する。いくつかの実施形態において、キャプチャファクタは乱数に対応しており、各乱数はマシン情報の異なる部分と対応している。各キャプチャファクタは、ユーザマシン情報の一部に関連する。一例において、キャプチャファクタは、１０個の乱数を含んでよい。この例において、キャプチャファクタは、１０個の乱数に対応するユーザマシン情報の部分と関連しており、ユーザマシン情報のそれらの部分に関連する情報が抽出される。ＯＴＰコントロールは、毎回、ユーザマシン情報の異なる部分を抽出しうる。

キャプチャファクタがランダムなので、キャプチャファクタに基づいて毎回抽出されるユーザマシン情報も様々である。例えば、コントロールサーバによって或る時点に発行されるキャプチャファクタが、１６個の乱数であって、別の時点に発行されるキャプチャファクタが、２０個の乱数であってもよい。この例において、抽出されるユーザマシン情報は、同じＯＴＰコントロールおよび同じユーザマシンに関して毎回変化しうる。その結果、ユーザＩＤの検証の安全性が向上されうる。ユーザマシン情報は、マシンのハードウェア情報、ソフトウェア情報、オペレーティングシステムのバージョンなどを含みうる。ユーザマシン情報の例としては、メディアアクセス制御（ＭＡＣ）アドレス、ＣＰＵシリアル番号、ハードドライブシリアル番号、ソフトウェア情報（オペレーティングシステムのバージョンおよび主なアプリケーションのバージョン）などが挙げられる。ただし、多くの他の例および組み合わせが存在する。同じユーザマシン情報は、セッションの継続期間中に変化しない。

工程３０４において、ＯＴＰコントロールは、ランダムセッション鍵に基づいてユーザマシン情報を暗号化し、暗号化したユーザマシン情報をＪＳに返す。

上述のキャプチャファクタの方法が利用されたのに応答して、ＯＴＰコントロールは、キャプチャファクタをユーザマシン情報と共に暗号化して送信してよい。

工程３０５において、ＪＳは、ブラウザを起動して、要求メッセージを送信する。要求メッセージは、ユーザマシン情報およびキャプチャファクタを含みうる。

工程３０６において、ブラウザは、要求メッセージをオンライン決済ゲートウェイに送信する。

工程３０７において、オンライン決済ゲートウェイは、要求メッセージをＯＴＰコントロールサーバに転送する。

工程３０８において、ＯＴＰコントロールサーバは、データベースから情報をリトリーブする。いくつかの実施形態において、データベースは、様々なクライアントの所定のマシン情報を格納する。その後、データベースに提供されたキャプチャファクタに基づいて、特定のクライアントのためのキャプチャファクタに対応する様々なマシン情報が、データベースから要求されうる。

工程３０９において、ＯＴＰコントロールサーバは、データベースから得られたキャプチャファクタに関連する情報を、抽出されたユーザマシン情報と比較する。ＯＴＰコントロールサーバは、ユーザマシン情報の各部分を、データベースからの情報と比較して、一致するか否かを判定する。

ＯＴＰコントロールサーバは、キャプチャファクタに対応する抽出されたユーザマシン情報とデータベース内のキャプチャファクタに対応する情報との比較を行い、抽出されたユーザマシン情報がデータベースに格納されている情報と異なるか否かを判定する。

工程３１０において、ユーザマシン情報の一致率が所定の閾値を超える場合、ＯＴＰコントロールサーバは、ユーザマシン情報の一致が成功したと確認する。

ＯＴＰサーバがユーザマシン情報の一致が成功したと確認するための所定の閾値は、８０％以上であってよい。ユーザマシン情報の一致率が８０％未満であった場合、ＯＴＰサーバは、ユーザマシン情報の一致が不成功であったと確認する。

工程３１１において、ＯＴＰコントロールサーバは、マッチング結果をオンライン決済ゲートウェイに返す。

工程３１２において、オンライン決済ゲートウェイは、マッチング結果をブラウザに転送する。

工程３１３において、ブラウザは、マッチング結果を受信し、そのマッチング結果をＪＳに返し、ＪＳは、マッチング結果が成功を示す場合に成功した取引を表示するため、または、マッチング結果が失敗を示す場合に失敗した取引／警告メッセージを表示するために呼び出される。

ここで、図４を参照すると、図４は、以下で説明するように、携帯電話のショートメッセージを用いてユーザＩＤを検証する処理の一実施形態を示す。

図４において、工程４０１から４０９は、実質的に図３の工程３０１から３０９と同じであるため、工程４０１から４０９の説明は簡単のために省略する。

工程４１０では、ユーザマシン情報の一致率が所定の閾値を超えなかったことに応じて、ユーザＩＤは、一致不成功と判定される。

上述のように、ユーザマシン情報の一致率が８０％を超えない場合には、ユーザＩＤ検証は失敗である。

工程４１１において、ＯＴＰコントロールサーバは、ユーザＩＤ検証が不成功であったことを示すメッセージをオンライン決済ゲートウェイに返す。

工程４１２において、オンライン決済ゲートウェイは、ユーザＩＤ検証が不成功であったことを示すメッセージをブラウザに転送する。

工程４１３において、ブラウザは、ユーザＩＤ検証が不成功であったことを示すメッセージを受信し、そのメッセージをＪＳに返し、ＪＳは呼び出される。

工程４１４において、ＪＳは、ショートメッセージ検証コード検証ページをリトリーブする。

工程４１５において、ＪＳは、ショートメッセージ検証コード検証ページを表示する。

一般に、ショートメッセージ検証コード検証ページは、携帯電話番号またはその他のユーザ関連情報を入力するようユーザにプロンプトする。

工程４１６において、ＪＳは、ショートメッセージ送信要求をＯＴＰコントロールサーバに送信する。

ユーザがユーザの携帯電話番号またはその他のユーザ関連情報をショートメッセージ検証コード検証ページに入力した後、ＪＳは、ショートメッセージ送信要求をユーザに送信する。

工程４１７において、コントロールサーバは、ショートメッセージ送信要求をＯＴＰ認証プラットフォームに送信する。

工程４１８において、ＯＴＰ認証プラットフォームは、以前に（例えば、ユーザがアカウントを登録した時に）ユーザ情報を格納したビジネスシステムからユーザ情報をリトリーブする。ユーザ情報は、携帯電話番号、ユーザ名、電子メールアドレス、連絡先住所、または、その他のユーザ関連情報を含みうる。

工程４１９において、ＯＴＰ認証プラットフォームは、検証コードを生成する。ＯＴＰ認証プラットフォームは、ユーザ情報に基づいて検証コードを生成する。

工程４２０において、ＯＴＰ認証プラットフォームは、ショートメッセージ送信要求をビジネスシステムに送信する。

工程４２１において、ビジネスシステムは、ユーザによって登録された携帯電話にショートメッセージを送信する。

ショートメッセージは、ＯＴＰ認証プラットフォームによって生成された検証コードを含む。図５は、携帯電話に表示されたショートメッセージの情報の内容の一例を示す。

工程４２２において、ユーザがショートメッセージを受信した後、ユーザは、ショートメッセージに含まれる検証コードをウェブページのプロンプトされた位置に入力する。

工程４２３において、ＪＳは、ショートメッセージ検証要求をＯＴＰコントロールサーバに送信する。ショートメッセージ検証要求は、ユーザが入力した検証コードを含む。

工程４２４において、ＯＴＰコントロールサーバは、ショートメッセージ検証要求をＯＴＰ認証プラットフォームに転送する。

工程４２５において、ＯＴＰ認証プラットフォームは、検証メッセージに含まれる検証コードを検証する。

工程４２６において、検証が成功した場合、ＯＴＰ認証プラットフォームは、検証成功応答をＯＴＰコントロールサーバに送信する。

工程４２７において、ＯＴＰコントロールサーバは、検証成功応答をＪＳに送信する。

工程４２８において、ＪＳは、マシン情報キャプチャ要求をＯＴＰコントロールに送信する。

工程４２９において、ＯＴＰコントロールは、ユーザマシンの全マシン情報をキャプチャする。

工程４３０において、ＯＴＰコントロールは、キャプチャしたマシン情報をＪＳに返す。

ＯＴＰコントロールは、ランダムセッション鍵に基づいてマシン情報を暗号化する。

工程４３１において、ＪＳは、キャプチャされたマシン情報を送信するために、ブラウザを起動する。

工程４３２において、ブラウザは、キャプチャされたマシン情報を含む要求メッセージをオンライン決済ゲートウェイに送信する。

工程４３３において、オンライン決済ゲートウェイは、要求メッセージをＯＴＰコントロールサーバに転送する。

工程４３４において、ＯＴＰコントロールサーバは、ユーザマシン情報を更新する。

工程４３５において、ＯＴＰコントロールサーバは、応答メッセージをオンライン決済ゲートウェイに送信する。

工程４３６において、オンライン決済ゲートウェイは、応答メッセージをブラウザに転送する。

工程４３７において、ブラウザは、ＪＳを呼び出し、応答メッセージをＪＳに返す。

工程４３８において、ＪＳは、応答メッセージを受信し、ユーザＩＤ検証を完了させる。

図１を再び参照すると、工程１０３は、ユーザＩＤの検証が成功した後、取引画像情報を生成し、ランダムセッション鍵に基づいて取引画像情報を暗号化し、取引画像情報をクライアントに送信する。

サーバが、取引画像情報を生成してよい。図７は、取引画像情報の一例を示す。さらに、サーバは、取引画像情報をクライアントに送信してよい。

図６を参照すると、図６は、クライアントが取引画像情報を取得する処理を示す。その処理について以下で説明する。

工程６０１において、ＪＳは、ユーザマシン情報検証結果をＯＴＰコントロールに送信する。

マシン検証の不成功に応答して、携帯電話ショートメッセージ検証アプローチが採用されてよい。それに応じて、携帯電話ショートメッセージ検証結果が、ＯＴＰコントロールに送信されてよい。

工程６０２において、ＯＴＰコントロールは、取引画像情報要求をＪＳに送信する。

工程６０３において、ＪＳは、取引画像情報要求をブラウザに送信する。

工程６０４において、ブラウザは、取引画像情報要求をオンライン決済ゲートウェイに送信する。

工程６０５において、オンライン決済ゲートウェイは、取引画像情報要求をＯＴＰコントロールサーバに転送する。

工程６０６において、コントロールサーバは、取引画像情報要求をＯＴＰ認証プラットフォームに送信する。

工程６０７において、ＯＴＰ認証プラットフォームは、注文番号に基づいてビジネスシステムから取引情報をリトリーブする。

ＯＴＰ認証プラットフォームは、取引画像情報要求に対応する注文番号をビジネスシステムから取得し、注文番号に基づいて対応する取引情報を取得する。取引情報は、図７に示すように、取引の内容、取引の金額または数量、取引時刻、ならびに、取引に関するその他の情報を含みうる。

工程６０８において、ＯＴＰ認証プラットフォームは、取引情報に基づいて画像要素を生成する。

画像要素は、例えば、取引検証コード、要約情報、および、ベース画像などの要素を指しうる。画像要素は、取引画像情報を生成するために用いられてよい。

工程６０９において、ＯＴＰ認証プラットフォームは、取引画像情報を生成する。

ＯＴＰ認証プラットフォームは、画像要素を用いて取引画像情報を生成するよう構成された画像サーバを含んでよい。

図８は、工程６０８および６０９で取引画像情報を生成する処理の一実施形態を示す。

工程６１０において、ＯＴＰ認証プラットフォームは、ランダムセッション鍵に基づいて取引画像情報を暗号化し、暗号化した取引画像情報をＯＴＰコントロールサーバに送信する。

工程６１１において、ＯＴＰコントロールサーバは、取引画像情報をオンライン決済ゲートウェイに送信する。

工程６１２において、オンライン決済ゲートウェイは、取引画像情報をブラウザに転送する。

工程６１３において、ブラウザは、取引画像情報を受信して、ＪＳに取引画像情報を返し、ＪＳは呼び出される。

工程６１４において、ＪＳは、ＯＴＰコントロールに取引画像情報を表示する。

図８を参照すると、図８は、ＯＴＰ認証プラットフォーム上で取引画像情報を生成する処理の一実施形態を示す。処理は、以下の工程を含む。

工程８０１において、ＯＴＰアルゴリズム駆動モジュールは、取引情報、ランダムセッション鍵、時刻、および、ユーザシード（ｕｓｅｒ ｓｅｅｄ）に基づいて、取引検証コードを生成する。

いくつかの実施形態において、時刻とは、取引時刻のことであり、ユーザシードとは、乱数（例えば、２０バイトの乱数）のことである。固有のユーザシードが、各ユーザに割り当てられてよい。

工程８０２において、ＯＴＰビジネスシステムは、取引情報およびランダムセッション鍵に基づいて、要約情報を生成する。各取引は、固有の要約情報を有する。

工程８０３において、画像サーバは、ベース画像を生成する。

工程８０４において、要約情報が、ベース画像に追加される。要約情報およびベース画像は、同じ色を有してよい。

工程８０５では、取引情報および取引検証コードが、要約情報を含むベース画像に追加される。取引画像情報は、取引情報および取引検証コードが追加された後の要約情報を含むベース画像に対応する。このように、取引画像情報が生成される。

図１を参照すると、工程１０５および１０６において、クライアントは、取引画像情報の確認を送信し、それに応答して、サーバは、ランダムセッション鍵に基づいて取引署名を検証する。

ユーザは、取引画像情報を取得すると、取引画像情報から取引検証コードを取得し、取引検証コードを入力して取引を確認することができる。ＯＴＰコントロールは、ランダムセッション鍵に基づいて、取引画像情報および取引検証コードにデジタル署名して取引署名を生成し、確認として取引署名をＯＴＰ認証プラットフォームに送信する。ＯＴＰ認証プラットフォームは、取引署名が正しいか否かを検証し、検証結果をクライアントに返す。

図９は、取引署名を検証する処理の一実施形態を示す。図９を参照すると、図９は、以下の工程を含む。

工程９０１において、ＪＳは、取引画像情報表示要求をＯＴＰコントロールに送信する。

工程９０２において、ＯＴＰコントロールは、取引画像情報を表示する。図７は、表示された取引画像情報の一例を示す。

工程９０３では、ユーザが、ＯＴＰコントロールで取引検証コードを入力する。

工程９０４において、ＯＴＰコントロールは、ランダムセッション鍵に基づいて、取引画像および取引検証コードにデジタル署名して、取引署名を生成する。

工程９０５において、ＯＴＰコントロールは、取引署名を含む署名検証要求をＪＳに送信する。

工程９０６において、ＪＳは、署名検証要求をブラウザに送信する。

工程９０７において、ブラウザは、署名検証要求をオンライン決済ゲートウェイに送信する。

工程９０８において、オンライン決済ゲートウェイは、署名検証要求をＯＴＰコントロールサーバに転送する。

工程９０９において、ＯＴＰコントロールサーバは、署名検証要求をＯＴＰ認証プラットフォームに送信する。

工程９１０において、ＯＴＰ認証プラットフォームは、取引署名が正しいか否かを検証する。

工程９１１において、ＯＴＰ認証プラットフォームは、署名検証結果をＯＴＰコントロールサーバに送信する。

工程９１２において、ＯＴＰコントロールサーバは、署名検証結果をオンライン決済ゲートウェイに送信する。

工程９１３において、オンライン決済ゲートウェイは、署名検証結果をブラウザに転送する。

工程９１４において、ブラウザは、署名検証結果を受信して、ＪＳに署名検証結果を返し、ＪＳが呼び出される。

工程９１５において、ＪＳは、フォローアップ処理を実行する。

上述の安全な認証処理が送信処理にランダムセッション鍵を追加するという事実により、取引画像情報が送信処理のどの部分においても改ざんされないことが保証される。また、取引画像情報は、コントロールに表示されてよい。ユーザがパスワード（すなわち取引検証コード）を入力すると、コントロールは、ランダムセッション鍵に基づいて取引画像情報およびパスワードにデジタル署名し、検証のために取引画像情報およびパスワードをＯＴＰコントロールサーバに送信する。したがって、取引処理全体の安全性が確保される。

上述のユーザは、ＯＴＰコントロールユーザである。ＯＴＰコントロールユーザは、ＯＴＰコントロールをインストールし、実名認証および携帯電話バインディングを行った（すなわち、ユーザの携帯電話がユーザのアカウントにリンクされている）ユーザである。図１０は、パスワードコントロールユーザがＯＴＰコントロールユーザにアップグレードされる一実施形態を示す。図１０によると、ＯＴＰコントロールユーザにアップグレードする処理は、以下の工程を含む。

ユーザは、ブラウザを開き（１００１）、決済ウェブサイトアドレスまたは決済ユニフォームリソースロケータ（ＵＲＬ）をブラウザに入力する（１００２）。ブラウザは、オンライン決済ゲートウェイからアップグレード情報を要求する（１００３）。オンライン決済ゲートウェイは、アップグレードプロンプトを含むスクリプトをブラウザに送信する（１００４）。ブラウザは、アップグレードプロンプトを表示する（１００５）。ユーザは、ブラウザによって表示されたアップグレードプロンプトを見る（１００６）。ユーザは、ブラウザによって表示されたアップグレードプロンプトをクリックまたはアクティブ化する（１００７）。ブラウザは、ダウンロード要求をダウンロードサーバに送信する（１００８）。ダウンロードサーバは、アップグレード情報をブラウザに送信する（１００９）。ユーザは、ブラウザからアップグレード情報をインストールする（１０１０）。ユーザがアップグレード情報をインストールした後の最初の決済（１０１１）で、ブラウザは、要求メッセージをオンライン決済ゲートウェイに送信する（１０１２）。オンライン決済ゲートウェイは、ビジネスシステムからユーザタイプをリトリーブする（１０１３）。ビジネスシステムは、ユーザの本名が認証されているか否かを判定する（１０１４）。ユーザの本名が認証されていない場合、ビジネスシステムは、本名認証を要求するページをオンライン決済ゲートウェイに送信する（１０１５）。オンライン決済ゲートウェイは、本名認証ページをブラウザに返し（１０１６）、ブラウザは、ユーザに対して本名認証ページを表示する（１０１７）。ユーザは、ＩＤ情報およびクレジットカード情報をブラウザに入力し（１０１８）、ブラウザは、ＩＤ情報およびクレジットカード情報をオンライン決済ゲートウェイに送信する（１０１９）。オンライン決済ゲートウェイは、ユーザのＩＤを検証し、ユーザのＩＤの検証後に、決済のための資金をビジネスシステムに引き渡す（１０２０）。ビジネスシステムは、決済リリースメッセージをオンライン決済ゲートウェイに送信し（１０２１）、オンライン決済ゲートウェイは、決済リリースメッセージをブラウザに転送する（１０２２）。ブラウザは、ユーザに対して決済リリースメッセージを表示する（１０２３）。ユーザは、決済リリース情報および携帯電話情報をブラウザに入力する（１０２４）。ブラウザは、検証要求をオンライン決済ゲートウェイに送信する（１０２５）。オンライン決済ゲートウェイは、検証要求をビジネスシステムに転送する（１０２６）。ビジネスシステムは、検証結果をオンライン決済ゲートウェイに返す（１０２７）。オンライン決済ゲートウェイは、検証結果をブラウザに送信する（１０２８）。ブラウザは、ユーザに対して検証結果を表示する（１０２９）。

このように、新しい申し込みについて、ユーザは、登録後に、図１０に示した処理に基づいてＯＴＰコントロールユーザにアップグレードされる。

さらに、工程１０２のユーザＩＤ検証処理において、サーバは、最初に、ユーザマシン情報を用いて、ユーザのＩＤを検証する。ユーザＩＤ検証が失敗した場合、サーバは、携帯電話ショートメッセージ検証アプローチを用いて、ユーザのＩＤを検証してよい。したがって、ユーザに関連する携帯電話番号が、安全な決済にとって重要である。そのため、ユーザに関連する携帯電話番号を変更するために、以下に記載する２つの方法の内のいずれかを利用する必要がある。

ユーザに関連する携帯電話番号を変更するための一の方法は、ユーザに関連する電子メールアドレスに電子メールを送信する工程を含む。ユーザは、電子メールに含まれるリンクを用いて自分のＩＤを検証し、次いで、自分の携帯電話番号を更新する。

ユーザに関連する携帯電話番号を変更するための他の方法は、ユーザがカスタマーサービスに電話することによって自分のＩＤを検証した後に携帯電話番号を更新する工程を含む。

本願は、さらに、上述の方法の実施形態に対応するシステムの実施形態を提供する。

図１１は、オンライン取引用の安全な認証システムの一実施形態を示す。

図１１を参照すると、図１１は、ＯＴＰコントロール１０と、ＯＰＴコントロールサーバ２０と、ＯＴＰ認証プラットフォーム３０とを備えるオンラインの安全な認証システムの一実施形態を示す。

ＯＴＰコントロール１０およびＯＴＰコントロールサーバ２０は、ＯＴＰコントロール１０とＯＴＰコントロールサーバ２０との間の通信を暗号化するためのランダムセッション鍵を生成し、ランダムセッション鍵に基づいてＯＴＰコントロール１０のユーザＩＤを検証するよう構成されている。

ＯＴＰ認証プラットフォーム３０は、ＯＴＰコントロールサーバ２０に接続されており、ＯＴＰコントロールサーバ２０によって送信されたユーザＩＤ検証成功メッセージを受信した後に、取引画像情報を生成するよう構成されている。ＯＴＰ認証プラットフォーム３０は、ランダムセッション鍵に基づいて取引画像情報を暗号化し、取引画像情報をＯＴＰコントロール１０に送信する。ＯＴＰコントロール１０が取引画像情報を確認した後、ＯＴＰコントロールサーバ２０は、別のランダムセッション鍵に基づいて、取引署名を検証する。

ランダムセッション鍵が上述の処理で生成されると、ＯＴＰコントロール１０は、乱数を生成し、事前設定されたＲＳＡ公開鍵に基づいて乱数を暗号化して、暗号化した乱数をＯＴＰコントロールサーバ２０に送信する。ＯＴＰコントロールサーバ２０は、暗号化された乱数に基づいて、別のランダムセッション鍵を生成して、そのランダムセッション鍵をＯＴＰコントロール１０に送信する。

ＯＴＰコントロールのユーザＩＤが上述の処理で検証されると、ＯＴＰコントロール１０は、ユーザマシン情報を抽出し、ランダムセッション鍵に基づいてユーザマシン情報を暗号化して、暗号化したユーザマシン情報をＯＴＰコントロールサーバ２０に送信する。ＯＴＰコントロールサーバ２０は、ユーザマシン情報の一致度を決定する。ユーザマシン情報の一致度が所定の閾値を超えた場合、ＯＴＰコントロールサーバ２０は、ユーザＩＤの検証が成功したと判定する。ユーザマシン情報の一致度が所定の閾値を超えなかった場合、ＯＴＰコントロールサーバ２０は、ユーザＩＤの検証が失敗したと判定する。

別の例では、ＯＴＰコントロールサーバ２０は、キャプチャファクタを生成して、キャプチャファクタをＯＴＰコントロール１０に送信してもよい。その後、ＯＴＰコントロール１０は、キャプチャファクタに基づいてユーザマシン情報を抽出し、他のランダムセッション鍵に基づいてユーザマシン情報およびキャプチャファクタを暗号化して、ユーザマシン情報およびキャプチャファクタをＯＴＰコントロールサーバ２０に送信する。ＯＴＰコントロールサーバ２０は、キャプチャファクタに基づいて、ユーザマシン情報の一致度を検証してもよい。

別の実施形態において、図１２に示すように、上述のユーザＩＤ検証が失敗した場合に、システムは、さらに、以下を備えてもよい。

携帯電話ショートメッセージ送信要求を送信するよう構成されたクライアントスクリプトモジュール４０。

ＯＴＰ認証プラットフォーム３０は、さらに、携帯電話ショートメッセージ送信要求を受信した後に、ユーザ情報を取得し、携帯電話ショートメッセージ検証コードを生成して、携帯電話ショートメッセージ検証コードをユーザに関連する携帯電話に送信するよう構成されてよい。

携帯電話ショートメッセージ検証コードを受信した後、ユーザは、携帯電話ショートメッセージ検証コードをクライアントスクリプトモジュール４０に入力し、携帯電話ショートメッセージ検証コードをＯＴＰ認証プラットフォーム３０に送信する。

ＯＴＰ認証プラットフォーム３０は、さらに、携帯電話ショートメッセージ検証コードを検証するよう構成されてよい。携帯電話ショートメッセージ検証コードの検証成功に応じて、ＯＴＰ認証プラットフォーム３０は、ユーザＩＤ検証成功結果をクライアントスクリプトモジュール４０に送信してよい。

別の例では、ＯＴＰ認証プラットフォーム３０は、さらに、以下を備えてもよい。

取引情報、ランダムセッション鍵、時刻、および、ユーザシードに基づいて、取引検証コードを生成するよう構成されたＯＴＰアルゴリズム駆動モジュール３２。

取引情報およびランダムセッション鍵に基づいて、要約情報を生成するよう構成されたＯＴＰビジネスシステム３３。

ベース画像を生成し、要約情報をベース画像に追加し、要約情報を含むベース画像に取引情報および取引検証コードを追加して、取引画像情報を生成するよう構成された画像サーバ３１。

上述の処理に基づいた取引署名の検証に対応して、ＯＴＰコントロール１０は、取引検証コードを入力し、ランダムセッション鍵を用いて取引画像情報および取引検証コードにデジタル署名して取引署名を生成し、取引署名をＯＴＰ認証プラットフォーム３０に送信するよう構成されている。

ＯＴＰ認証プラットフォーム３０は、取引署名が正しいか否かを検証し、検証結果をＯＴＰコントロール１０に送信するよう構成されている。

安全な認証システムの実施形態は、基本的に、方法の実施形態と類似しているので、簡潔にするために、説明を比較的簡略化している。方法の実施形態の一部の説明を用いて、システムの実施形態の対応する一部の説明とすることができる。

以下では、本願の理解を助けるために、数例のハッカー攻撃を挙げて、本願の方法およびシステムが、フィッシング、トロイの木馬、および、トロイの木馬型フィッシングをどのように防ぎうるのかを説明する。

１．決済ウェブサイトでのサイト内フィッシング

図１３を参照すると、通常、クライアントが購入したい商品を選択した後、ショッピングウェブサイトは、クライアントにレジ（例えば、レジ機能を備えたウェブページ）を提示する（１３０１）。クライアントは、選択した商品に関連する金額をレジで支払う（１３０２）。レジは、その支払いをショッピングウェブサイトに転送する（１３０３）。しかしながら、かかる取引は、最近現れたトロイの木馬ウイルスソフトウェアの変異型であるサイト内取引置換（ｉｎｔｒａ−ｓｉｔｅ ｔｒａｎｓａｃｔｉｏｎ ｓｕｂｓｔｉｔｕｔｉｏｎｓ）にさらされる。トロイの木馬ウイルスソフトウェアは、決済ウェブサイト内に即時決済取引（例えば、「支払いを行う」）を作成し、その後、決済ウェブサイトはレジに飛んで、ユーザに支払いさせる。

サイト内取引置換処理の一例も図１３に示されている。

工程１３０１’において、ショッピングウェブサイトで商品を購入した後、ユーザは、購入を確認するためにクリックする。ブラウザが、ショッピングウェブサイトの決済ウェブサイトのレジに進むと、トロイの木馬は、例えば、ブラウザのＵＲＬフィールドを監視することにより、通常の決済処理を妨害する。

工程１３０２’において、トロイの木馬は、決済ウェブサイトのブラウザを即時決済ページにリダイレクトする。

工程１３０３’において、トロイの木馬は、「支払いを行う」命令を生成する。支払いの受取人すなわち受領者は、詐欺師のオンライン決済口座である。

工程１３０４’において、ブラウザは、決済ウェブサイトのレジに進む。ユーザは、命令を完了させる必要があることを知る。しかしながら、ショッピングサイトへの支払いを正規の販売者にする代わりに、その命令は、詐欺師のオンライン決済口座に支払いを行う。

工程１３０５’において、ユーザは、支払いを許可する。

工程１３０６’において、ユーザは、トロイの木馬によって生成された即時決済命令に支払いを行う。フィッシング処理は終了する。

本願では、ユーザの取引情報は、表示に向けて画像の形態でコントロールに送信される。さらに、処理全体が、ランダムセッション鍵によって暗号化される。ランダムセッション鍵は、アプリケーション層のデータを暗号化しうる。各コントロールのランダムセッション鍵が異なるため、ハッカーは、新たな取引を作成しても、この取引の画像をコントロールに送信することができない。ハッカーの画像は、ユーザのコントロールのランダムセッション鍵を用いても復号されえない。

２．第三者の外部業者へのフィッシング

図１４を参照すると、通常の取引について、図１３の工程１３０１、１３０２、および、１３０３は、図１４の工程１４０１、１４０２、および、１４０３に対応する。したがって、工程１４０１、１４０２、および、１４０３の詳細については、簡単のために省略する。図１４は、第三者の外部業者へのフィッシングに含まれる工程を示す。

工程１４０１’において、ユーザのマシンがトロイの木馬に感染した後、トロイの木馬は、ブラウザのＵＲＬアドレスフィールドを監視する。ユーザは、ショッピングウェブサイトで商品を購入した後、「購入を確認する」をクリックする。

工程１４０２’において、ブラウザが決済ウェブサイトのレジに進む代わりに、トロイの木馬は、通常の決済処理を妨害し、別の第三者の外部業者にブラウザをリダイレクトする。

工程１４０３’において、トロイの木馬は、クライアントにおいて詐欺師の外部商用口座番号を入力する。次いで、第三者の外部業者は、同じ金額の命令を生成する。この命令には、決済ウェブサイトを用いて支払いが行われる。

工程１４０４’において、ブラウザは、決済ウェブサイトのレジに進む。この時点で、ユーザは、命令に対して支払いを行う必要があることを知る。しかしながら、この命令の支払いは、詐欺師の外部商用口座に送られる。

工程１４０５’において、ユーザは、決済ウェブサイトのレジで支払いを行うよう選択する。

工程１４０６’において、ユーザは、その命令について、第三者の外部業者に支払いを行う。決済ウェブサイトは、第三者の外部業者に支払いを行う。フィッシング処理は終了する。

上述のフィッシング処理からわかるように、このタイプのトロイの木馬型フィッシングは、決済ウェブサイトの安全性に関係するだけでなく、フィッシングされた第三者の外部業者の安全性にも密接に関係する。外部業者の大多数は、オンライン取引のための安全なセキュリティシステムを持っていない。本願のソリューションを第三者の外部業者に適用できれば、かかるトロイの木馬を防止できる。例えば、決済ウェブサイトがクライアントコントロールおよびサーバサービスを提供するアプローチを用いて、フィッシングを防止できる。

３．第三者の決済プラットフォームへのフィッシング

図１５を参照すると、通常の取引について、図１３の工程１３０１、１３０２、および、１３０３は、図１５の工程１５０１、１５０２、および、１５０３に対応する。図１５は、ユーザが決済ウェブサイトのレジにいる時に、トロイの木馬が別の第三者の決済プラットフォームでオンラインバンキングの入金命令を生成するトロイの木馬の例を示す。このように、ユーザは、オンラインバンキングの入金決済を行うようだまされる。図１５は、第三者の決済プラットフォームへのフィッシング処理を示す。

工程１５０１’において、ユーザは、決済ウェブサイトのレジで入金動作を実行する。例えば、ユーザは、ショッピングウェブサイトで商品を購入し、決済に向けてレジに進みうる。ユーザは、「支払いを行う」即時決済取引を開始する。ユーザは、取引詳細をクリックして、支払いを完了させる。トロイの木馬は、ブラウザのＵＲＬアドレスフィールドを監視する。ユーザが支払いの準備をしたことに応答して、トロイの木馬は、通常の動作処理を妨害する。

工程１５０２’において、トロイの木馬は、ブラウザを別の第三者の決済プラットフォームに導いて、詐欺師の口座番号を入力する。トロイの木馬は、以下の方法のいずれかを用いて、ブラウザを第三者の決済プラットフォームに導きうる。

（１）トロイの木馬は、ブラウザが第三者の決済プラットフォームにリダイレクトされるように、ブラウザのリダイレクトアドレスを改変しうる。

（２）トロイの木馬は、オンラインバンキングの命令送信フォームのリダイレクトアドレスを改変しうる。この方法は、図１５に示した処理とは少し異なる。トロイの木馬は、リモートサーバで命令を動的に生成した後に、リモートから命令をトロイの木馬に送信する。トロイの木馬は、ウェブページ内のフォーム情報を改ざんする。この方法は、トロイの木馬が出現し始めた頃には比較的よく見られた。

（３）トロイの木馬は、比較的短期間に多数回のＵＲＬリダイレクトを実行しうる。例えば、ユーザがオンラインバンキング入金のためのリンクを開いた場合、トロイの木馬は、そのリンクを直接的に妨害するのではなく、ブラウザがオンラインバンキングページに進んだ後に第三者の決済プラットフォームにブラウザをリダイレクトする。

工程１５０２’でトロイの木馬がブラウザを何回リダイレクトさせたかに関わらず、工程１５０３’では、ブラウザは、第三者の決済プラットフォームに進んで、オンラインバンキングの入金命令を生成する。

工程１５０４’において、ユーザは、オンラインバンキング命令に対して支払いを行う必要があることをブラウザで知る。支払銀行および金額は、通常の取引処理と同じであるが、オンラインバンキング入金の受領者は、決済ウェブサイトではない。代わりに、詐欺師の口座が受け取り先になる。

工程１５０５’において、ユーザは、入金の受け取り先が詐欺師の口座であることに気づくことなく、入金を完了させる。

工程１５０６’において、銀行は、詐欺師の口座に送金する。フィッシング処理は終了する。

上述の処理からわかるように、トロイの木馬型フィッシングは、決済ウェブサイトの安全性に関係するだけでなく、フィッシングされた第三者の決済プラットフォームの安全性にも関係する。本願の方法およびシステムを実施して、本願の方法およびシステムを第三者の決済プラットフォームに適用すれば、この種のトロイの木馬を防止できる。

概して、本願は、少なくとも以下の利点を有する。

第１に、本願は、例えば、ＯＴＰ技術、パスワード制御技術、および、取引画像署名技術などの技術に基づいて、オンライン取引の安全な認証を実現する。本願は、さらに、ハードウェア製品の制限を克服する。例えば、ハードウェア製品の制限は、動作範囲、サービス、および、技術向上を含む。

第２に、取引画像の安全な通信のためにランダムセッション鍵を利用することにより、本願は、ユーザ取引の二重の確認を実現する。換言すると、本願は、第２世代のＯＴＰ技術を実装して、フィッシング、トロイの木馬、および、トロイの木馬型フィッシングの防止に関してソフトウェア製品が持つ既存の課題を解決する。

第３に、ＯＴＰコントロールサーバおよびＯＴＰ認証プラットフォームを確立することにより、本願は、ＯＴＰ技術のバッチ取引を実施する。

第４に、本願によって提供される安全な認証システムは、ソフトウェア技術で実施されるため、普及させやすい。第三者のシステム（第三者の業者または第三者の決済プラットフォームなど）で実施されれば、本願は、オンライン取引の安全性を強化しうる。

本願に含まれる各実施形態は、漸進的に記載されている。各実施形態の説明は、他の実施形態と異なる領域に焦点を当てており、実施形態の記載は、各実施形態の同一または類似の部分について相互に参照できる。

以上、本願に開示されたオンライン取引のための安全な認証方法およびシステムについて、詳細に説明した。本明細書は、具体的な実施形態を用いて、本願の原理および実装の形態を説明している。上記の実施形態は、単に、本願の方法およびシステムならびにその中心概念の理解を助けるよう意図されたものである。さらに、当業者は、本願に基づいて、具体的な応用例および応用例の範囲に対して修正を加えることができる。要するに、本開示の内容は、いかなる形でも本願を限定するものとして理解されるべきではない。

上述の実施形態は、理解しやすいようにいくぶん詳しく説明されているが、本発明は、提供された詳細事項に限定されるものではない。本発明を実施する多くの代替方法が存在する。開示された実施形態は、例示であり、限定を意図するものではない。
適用例１：オンライン取引のための安全な認証方法であって、１または複数のコンピュータプロセッサを用いて、クライアントおよびサーバの間の通信を暗号化するためのランダムセッション鍵を生成し、前記生成されたランダムセッション鍵に基づいて、前記クライアントを利用するユーザのユーザＩＤを検証し、前記ユーザＩＤの前記検証が成功した場合に、取引画像情報を生成し、前記ランダムセッション鍵に基づいて前記取引画像情報を暗号化し、前記暗号化された取引画像情報を前記クライアントに送信し、取引署名を含む、前記取引画像情報の確認を受信し、前記ランダムセッション鍵に基づいて前記取引署名を検証すること、を備える、方法。
適用例２：適用例１に記載の方法であって、前記ランダムセッション鍵の生成は、前記クライアントによって生成され暗号化された乱数を受信し、前記暗号化された乱数に基づいて前記ランダムセッション鍵を生成し、前記ランダムセッション鍵を前記クライアントに送信すること、を備える、方法。
適用例３：適用例１に記載の方法であって、前記ユーザＩＤの検証は、ユーザマシン情報を前記クライアントから受信し、前記ユーザマシン情報が、以前に格納されたユーザマシン情報と所定の一致度まで一致するか否かを判定すること、を備える、方法。
適用例４：適用例３に記載の方法であって、さらに、キャプチャファクタを生成し、前記キャプチャファクタを前記クライアントに送信し、前記暗号化されたユーザマシン情報および前記暗号化されたキャプチャファクタを前記クライアントから受信し、前記ランダムセッション鍵に基づいて、前記受信したキャプチャファクタおよびユーザマシン情報を復号し、前記受信したキャプチャファクタに基づいて前記ユーザマシン情報の一致度を決定すること、を備える、方法。
適用例５：適用例３に記載の方法であって、さらに、前記ユーザＩＤの検証が失敗した場合に、携帯電話ショートメッセージ送信要求が前記クライアントから受信されたか否かを判定する工程と、前記携帯電話ショートメッセージ送信要求が前記クライアントから受信された場合に、ユーザ情報を取得する工程と、携帯電話ショートメッセージ検証コードを生成する工程と、前記携帯電話ショートメッセージ検証コードを前記ユーザに関連する携帯電話に送信する工程と、を実行する工程、前記携帯電話ショートメッセージ検証コードを前記クライアントから受信する工程と、前記携帯電話ショートメッセージ検証コードを検証する工程と、前記携帯電話ショートメッセージ検証コードの検証が成功した場合に、ユーザＩＤ検証成功結果を前記クライアントに送信する工程と、を実行することを備える、方法。
適用例６：適用例１に記載の方法であって、前記取引画像情報の生成は、取引情報、前記ランダムセッション鍵、および、ユーザシードに基づいて、取引検証コードを生成し、前記取引情報および前記ランダムセッション鍵に基づいて要約情報を生成し、ベース画像を生成し、前記要約情報を前記ベース画像に追加し、前記取引情報および前記取引検証コードを前記ベース画像に追加して、前記取引画像情報を生成すること、を備える、方法。
適用例７：適用例６に記載の方法であって、前記取引署名の検証は、前記取引署名を前記クライアントから受信し、前記取引署名が正しいか否かを検証し、検証結果を前記クライアントに送信すること、を備える、方法。
適用例８：オンライン取引のための安全な認証システムであって、ワンタイムパスワード（ＯＴＰ）コントロール部と、ＯＴＰコントロールサーバと、ＯＴＰ認証プラットフォームと、を備え、前記ＯＴＰコントロール部およびＯＴＰコントロールサーバは、前記ＯＴＰコントロール部と前記ＯＴＰコントロールサーバとの間の暗号化通信のためのランダムセッション鍵を生成し、前記ランダムセッション鍵に基づいて前記ＯＴＰコントロール部のユーザＩＤを検証するよう構成され、前記ＯＴＰ認証プラットフォームは、前記ＯＴＰコントロールサーバに接続され、前記ＯＴＰコントロールサーバによって送信されたユーザＩＤ検証成功メッセージを受信した後に、取引画像情報を生成し、ランダムセッション鍵に基づいて前記取引画像情報を暗号化し、前記取引画像情報を前記ＯＴＰコントロール部に送信し、前記ＯＴＰコントロール部が前記取引画像情報を確認した後に、前記ランダムセッション鍵に基づいて取引署名を検証する、システム。
適用例９：適用例８に記載のシステムであって、前記ランダムセッション鍵が生成されると、前記ＯＴＰコントロール部は、乱数を生成し、事前設定されたＲＳＡ公開鍵に基づいて前記乱数を暗号化して、前記暗号化された乱数を前記ＯＴＰコントロールサーバに送信し、前記ＯＴＰコントロールサーバは、前記暗号化された乱数に基づいて別のランダムセッション鍵を生成して、前記別のランダムセッション鍵を前記ＯＴＰコントロール部に送信する、システム。
適用例１０：適用例８に記載のシステムであって、前記ＯＴＰコントロール部は、ユーザマシン情報を抽出し、前記ランダムセッション鍵に基づいて前記ユーザマシン情報を暗号化し、前記ユーザマシン情報を前記ＯＴＰコントロールサーバに送信し、前記ＯＴＰコントロールサーバは、前記ユーザマシン情報の一致度を検証し、前記ユーザマシン情報の前記一致度が所定の閾値を超えた場合、前記ＯＴＰコントロールサーバは、前記ユーザＩＤの検証が成功したことを示す結果を送信し、前記ユーザマシン情報の前記一致度が所定の閾値を超えなかった場合、前記ＯＴＰコントロールサーバは、前記ユーザＩＤの検証が失敗したことを示す結果を送信する、システム。
適用例１１：適用例１０に記載のシステムであって、前記ＯＴＰコントロールサーバは、キャプチャファクタを生成して、前記キャプチャファクタを前記ＯＴＰコントロール部に送信し、前記ＯＴＰコントロール部は、前記キャプチャファクタに基づいてユーザマシン情報を抽出し、前記ランダムセッション鍵を用いて前記ユーザマシン情報および前記キャプチャファクタを暗号化し、前記暗号化されたユーザマシン情報およびキャプチャファクタを前記ＯＴＰコントロールサーバに送信し、前記ＯＴＰコントロールサーバは、前記キャプチャファクタに基づいて、前記ユーザマシン情報の前記一致度を検証する、システム。
適用例１２：適用例１０に記載のシステムであって、前記ユーザＩＤの検証が失敗した場合、前記システムにおいて、前記ＯＴＰ認証プラットフォームは、ユーザ情報を取得し、携帯電話ショートメッセージ送信要求を受信した後、前記ＯＴＰコントロールサーバは、携帯電話ショートメッセージ検証コードを生成して、前記携帯電話ショートメッセージ検証コードを前記ＯＴＰコントロール部に関連する携帯電話に送信し、前記ＯＴＰコントロールサーバは、前記ショートメッセージ検証コードを検証し、前記ショートメッセージ検証コードの検証が成功した場合、前記ＯＴＰコントロールサーバは、ユーザＩＤ検証成功結果を前記ＯＴＰコントロール部に送信する、システム。
適用例１３：適用例８に記載のシステムであって、前記ＯＴＰ認証プラットフォームは、取引情報、前記ランダムセッション鍵、時刻、および、ユーザシードに基づいて、取引検証コードを生成するよう構成されたＯＴＰアルゴリズム駆動モジュールと、前記取引情報および前記ランダムセッション鍵に基づいて、要約情報を生成するよう構成されたＯＴＰビジネスシステムと、ベース画像を生成し、前記要約情報を前記ベース画像に追加し、前記要約情報を含む前記ベース画像に前記取引情報および取引検証コードを追加して、前記取引画像情報を生成するよう構成された画像サーバと、を備える、システム。
適用例１４：適用例８に記載のシステムであって、前記取引署名の検証において、前記ＯＴＰコントロール部は、前記取引検証コードを入力し、前記ランダムセッション鍵に基づいて前記取引画像情報および前記取引検証コードにデジタル署名して前記取引署名を生成し、前記取引署名を前記ＯＴＰ認証プラットフォームに送信し、前記ＯＴＰ認証プラットフォームは、前記取引署名が正しいか否かを検証し、検証結果を前記ＯＴＰコントロール部に送信する、システム。
適用例１５：オンライン取引の安全な認証のためのコンピュータプログラム製品であって、前記コンピュータプログラム製品は、持続性のコンピュータ読み取り可能な記憶媒体内に具現化され、１または複数のコンピュータプロセッサを用いて、クライアントおよびサーバの間の通信を暗号化するためのランダムセッション鍵を生成するためのコンピュータ命令と、前記生成されたランダムセッション鍵に基づいて、前記クライアントを利用するユーザのユーザＩＤを検証するためのコンピュータ命令と、前記ユーザＩＤの前記検証が成功した場合に、取引画像情報を生成し、前記ランダムセッション鍵に基づいて前記取引画像情報を暗号化し、前記暗号化された取引画像情報を前記クライアントに送信するためのコンピュータ命令と、取引署名を含む、前記取引画像情報の確認を受信するためのコンピュータ命令とは、前記ランダムセッション鍵に基づいて前記取引署名を検証するためのコンピュータ命令と、を備える、コンピュータプログラム製品。
適用例１６：適用例１５に記載のコンピュータプログラム製品であって、前記ランダムセッション鍵を生成することは、前記クライアントによって生成され暗号化された乱数を受信すること、前記暗号化された乱数に基づいて前記ランダムセッション鍵を生成すること、前記ランダムセッション鍵を前記クライアントに送信すること、を備える、コンピュータプログラム製品。
適用例１７：適用例１５に記載のコンピュータプログラム製品であって、前記ユーザＩＤを検証することは、ユーザマシン情報を前記クライアントから受信すること、前記ユーザマシン情報が、以前に格納されたユーザマシン情報と所定の一致度まで一致するか否かを判定すること、を備える、コンピュータプログラム製品。
適用例１８：適用例１７に記載のコンピュータプログラム製品であって、さらに、キャプチャファクタを生成するためのコンピュータ命令と、前記キャプチャファクタを前記クライアントに送信するためのコンピュータ命令と、前記暗号化されたユーザマシン情報および前記暗号化されたキャプチャファクタを前記クライアントから受信するためのコンピュータ命令と、前記ランダムセッション鍵に基づいて、前記受信したキャプチャファクタおよびユーザマシン情報を復号するためのコンピュータ命令と、前記受信したキャプチャファクタに基づいて前記ユーザマシン情報の一致度を決定するためのコンピュータ命令と、を備える、コンピュータプログラム製品。
適用例１９：適用例１７に記載のコンピュータプログラム製品であって、さらに、前記ユーザＩＤの検証が失敗した場合に、携帯電話ショートメッセージ送信要求が前記クライアントから受信されたか否かを判定するためのコンピュータ命令と、前記携帯電話ショートメッセージ送信要求が前記クライアントから受信された場合に、ユーザ情報を取得し、携帯電話ショートメッセージ検証コードを生成し、前記携帯電話ショートメッセージ検証コードを前記ユーザに関連する携帯電話に送信するためのコンピュータ命令と、前記携帯電話ショートメッセージ検証コードを前記クライアントから受信するためのコンピュータ命令と、前記携帯電話ショートメッセージ検証コードを検証するためのコンピュータ命令と、前記携帯電話ショートメッセージ検証コードの検証が成功した場合に、ユーザＩＤ検証成功結果を前記クライアントに送信するためのコンピュータ命令と、を備える、コンピュータプログラム製品。
適用例２０：適用例１５に記載のコンピュータプログラム製品であって、前記取引画像情報を生成することは、取引情報、前記ランダムセッション鍵、および、ユーザシードに基づいて、取引検証コードを生成すること、前記取引情報および前記ランダムセッション鍵に基づいて要約情報を生成すること、ベース画像を生成すること、前記要約情報を前記ベース画像に追加すること、前記取引情報および前記取引検証コードを前記ベース画像に追加して、前記取引画像情報を生成すること、を備える、コンピュータプログラム製品。
適用例２１：適用例２０に記載のコンピュータプログラム製品であって、前記取引署名を検証することは、前記取引署名を前記クライアントから受信すること、前記取引署名が正しいか否かを検証すること、検証結果を前記クライアントに送信することと、を備える、コンピュータプログラム製品。
適用例２２：オンライン取引のための安全な認証クライアントであって、少なくとも１つのプロセッサであって、前記クライアントおよびサーバの間の通信を暗号化するためのランダムセッション鍵を受信し、前記受信したランダムセッション鍵に基づいてユーザのユーザマシン情報を暗号化し、前記暗号化されたユーザマシン情報を前記サーバに送信し、暗号化された取引画像情報を前記サーバから受信し、前記取引画像情報の確認を暗号化し、前記取引画像情報の前記確認を前記サーバに送信するように構成されているプロセッサと、前記プロセッサに接続され、前記プロセッサに命令を提供するメモリと、
を備える、クライアント。
適用例２３：適用例２２に記載のクライアントであって、前記ランダムセッション鍵の受信は、乱数を生成し、事前設定されたＲＳＡ公開鍵に基づいて前記乱数を暗号化し、前記暗号化された乱数を前記サーバに送信すること、を備える、クライアント。
適用例２４：適用例２２に記載のクライアントであって、前記ユーザマシン情報の暗号化は、前記ユーザの前記ユーザマシン情報を抽出し、前記ランダムセッション鍵に基づいて前記ユーザマシン情報を暗号化すること、を備える、クライアント。
適用例２５：適用例２４に記載のクライアントであって、前記ユーザマシン情報の抽出は、キャプチャファクタを前記サーバから受信し、前記受信したキャプチャファクタに関連する前記ユーザマシン情報を抽出し、前記ランダムセッション鍵に基づいて前記ユーザマシン情報を暗号化し、前記暗号化されたユーザマシン情報を前記サーバに送信すること、を備える、クライアント。
適用例２６：適用例２２に記載のクライアントであって、前記少なくとも１つのプロセッサは、さらに、携帯電話ショートメッセージ送信要求を前記サーバに送信し、携帯電話ショートメッセージ検証コードを前記サーバから受信し、前記携帯電話ショートメッセージ検証コードを前記サーバに送信し、ユーザＩＤ検証成功結果を前記サーバから受信するように構成されている、クライアント。

Claims (23)

1. サーバコンピュータによって実行されるオンライン取引のための安全な認証方法であって、
   クライアントおよびサーバの間の通信を暗号化するためのランダムセッション鍵を生成し、
   前記生成されたランダムセッション鍵に基づいて、前記クライアントを利用するユーザのユーザＩＤを検証することであって、
   乱数に対応するキャプチャファクタを生成し、
   前記キャプチャファクタを前記クライアントに送信し、
   前記サーバコンピュータから受信した前記キャプチャファクタに基づいて前記クライアントによって抽出されたユーザマシン情報を前記クライアントから受信し、
   前記ユーザマシン情報が、以前に格納されたユーザマシン情報と所定の一致度まで一致するか否かを判定すること、を備え
   前記ユーザＩＤの前記検証が成功した場合に、取引画像情報を生成し、前記ランダムセッション鍵に基づいて前記取引画像情報を暗号化し、前記暗号化された取引画像情報を前記クライアントに送信し、
   取引署名を含む、前記取引画像情報の確認を受信し、
   前記ランダムセッション鍵に基づいて前記取引署名を検証すること、
   を備える、方法。
2. 請求項１に記載の方法であって、前記ランダムセッション鍵の生成は、
   前記クライアントによって生成され暗号化された乱数を受信し、
   前記暗号化された乱数に基づいて前記ランダムセッション鍵を生成し、
   前記ランダムセッション鍵を前記クライアントに送信すること、
   を備える、方法。
3. 請求項１に記載の方法であって、さらに、
   暗号化されたユーザマシン情報および暗号化されたキャプチャファクタを前記クライアントから受信し、
   前記ランダムセッション鍵に基づいて、前記受信したキャプチャファクタおよびユーザマシン情報を復号し、
   前記受信したキャプチャファクタに基づいて前記ユーザマシン情報の一致度を決定すること、
   を備える、方法。
4. 請求項１に記載の方法であって、さらに、
   前記ユーザＩＤの検証が失敗した場合に、
   携帯電話ショートメッセージ送信要求が前記クライアントから受信されたか否かを判定する工程と、
   前記携帯電話ショートメッセージ送信要求が前記クライアントから受信された場合に、
   ユーザ情報を取得する工程と、
   携帯電話ショートメッセージ検証コードを生成する工程と、
   前記携帯電話ショートメッセージ検証コードを前記ユーザに関連する携帯電話に送信する工程と、を実行する工程、
   前記携帯電話ショートメッセージ検証コードを前記クライアントから受信する工程と、
   前記携帯電話ショートメッセージ検証コードを検証する工程と、
   前記携帯電話ショートメッセージ検証コードの検証が成功した場合に、ユーザＩＤ検証成功結果を前記クライアントに送信する工程と、を実行すること
   を備える、方法。
5. 請求項１に記載の方法であって、前記取引画像情報の生成は、
   取引情報、前記ランダムセッション鍵、および、ユーザシードに基づいて、取引検証コードを生成し、
   前記取引情報および前記ランダムセッション鍵に基づいて要約情報を生成し、
   ベース画像を生成し、
   前記要約情報を前記ベース画像に追加し、
   前記取引情報および前記取引検証コードを前記ベース画像に追加して、前記取引画像情報を生成すること、
   を備える、方法。
6. 請求項５に記載の方法であって、前記取引署名の検証は、
   前記取引署名を前記クライアントから受信し、
   前記取引署名が正しいか否かを検証し、
   検証結果を前記クライアントに送信すること、
   を備える、方法。
7. オンライン取引のための安全な認証システムであって、
   ワンタイムパスワード（ＯＴＰ）コントロール部であって、
   キャプチャファクタを受信し、
   前記キャプチャファクタに基づいてユーザマシン情報を抽出するように構成されている、ＯＴＰコントロール部と、
   ＯＴＰコントロールサーバであって、
   乱数に対応するキャプチャファクタを生成し、
   前記キャプチャファクタを前記ＯＴＰコントロール部に送信するように構成されている、ＯＴＰコントロールサーバと、
   ＯＴＰ認証プラットフォームと、
   を備え、
   前記ＯＴＰコントロール部およびＯＴＰコントロールサーバは、前記ＯＴＰコントロール部と前記ＯＴＰコントロールサーバとの間の暗号化通信のためのランダムセッション鍵を生成し、前記ランダムセッション鍵に基づいて前記ＯＴＰコントロール部のユーザＩＤを検証するよう構成され、前記ユーザＩＤの検証は、
   前記ユーザマシン情報を前記ＯＴＰコントロール部から受信し、
   前記ユーザマシン情報が、以前に格納されたユーザマシン情報と所定の一致度まで一致するか否かを判定すること、を備え
   前記ＯＴＰ認証プラットフォームは、
   前記ＯＴＰコントロールサーバに接続され、
   前記ＯＴＰコントロールサーバによって送信されたユーザＩＤ検証成功メッセージを受信した後に、取引画像情報を生成し、
   ランダムセッション鍵に基づいて前記取引画像情報を暗号化し、
   前記取引画像情報を前記ＯＴＰコントロール部に送信し、
   前記ＯＴＰコントロール部が前記取引画像情報を確認した後に、前記ランダムセッション鍵に基づいて取引署名を検証する、システム。
8. 請求項７に記載のシステムであって、
   前記ランダムセッション鍵が生成されると、前記ＯＴＰコントロール部は、乱数を生成し、事前設定されたＲＳＡ公開鍵に基づいて前記乱数を暗号化して、前記暗号化された乱数を前記ＯＴＰコントロールサーバに送信し、
   前記ＯＴＰコントロールサーバは、前記暗号化された乱数に基づいて別のランダムセッション鍵を生成して、前記別のランダムセッション鍵を前記ＯＴＰコントロール部に送信する、システム。
9. 請求項７に記載のシステムであって、
   前記ＯＴＰコントロール部は、前記ランダムセッション鍵に基づいて前記ユーザマシン情報を暗号化し、前記ユーザマシン情報を前記ＯＴＰコントロールサーバに送信し、
   前記ＯＴＰコントロールサーバは、前記ユーザマシン情報の一致度を検証し、
   前記ユーザマシン情報の前記一致度が所定の閾値を超えた場合、前記ＯＴＰコントロールサーバは、前記ユーザＩＤの検証が成功したことを示す結果を送信し、
   前記ユーザマシン情報の前記一致度が所定の閾値を超えなかった場合、前記ＯＴＰコントロールサーバは、前記ユーザＩＤの検証が失敗したことを示す結果を送信する、システム。
10. 請求項９に記載のシステムであって、
    前記ＯＴＰコントロール部は、前記ランダムセッション鍵を用いて前記ユーザマシン情報および前記キャプチャファクタを暗号化し、前記暗号化されたユーザマシン情報およびキャプチャファクタを前記ＯＴＰコントロールサーバに送信し、
    前記ＯＴＰコントロールサーバは、前記キャプチャファクタに基づいて、前記ユーザマシン情報の前記一致度を検証する、システム。
11. 請求項９に記載のシステムであって、前記ユーザＩＤの検証が失敗した場合、前記システムにおいて、
    前記ＯＴＰ認証プラットフォームは、ユーザ情報を取得し、
    携帯電話ショートメッセージ送信要求を受信した後、前記ＯＴＰコントロールサーバは、携帯電話ショートメッセージ検証コードを生成して、前記携帯電話ショートメッセージ検証コードを前記ＯＴＰコントロール部に関連する携帯電話に送信し、
    前記ＯＴＰコントロールサーバは、前記ショートメッセージ検証コードを検証し、
    前記ショートメッセージ検証コードの検証が成功した場合、前記ＯＴＰコントロールサーバは、ユーザＩＤ検証成功結果を前記ＯＴＰコントロール部に送信する、システム。
12. 請求項７に記載のシステムであって、前記ＯＴＰ認証プラットフォームは、
    取引情報、前記ランダムセッション鍵、時刻、および、ユーザシードに基づいて、取引検証コードを生成するよう構成されたＯＴＰアルゴリズム駆動モジュールと、
    前記取引情報および前記ランダムセッション鍵に基づいて、要約情報を生成するよう構成されたＯＴＰビジネスシステムと、
    ベース画像を生成し、前記要約情報を前記ベース画像に追加し、前記要約情報を含む前記ベース画像に前記取引情報および取引検証コードを追加して、前記取引画像情報を生成するよう構成された画像サーバと、
    を備える、システム。
13. 請求項７に記載のシステムであって、
    前記取引署名の検証において、前記ＯＴＰコントロール部は、取引検証コードを入力し、前記ランダムセッション鍵に基づいて前記取引画像情報および前記取引検証コードにデジタル署名して前記取引署名を生成し、前記取引署名を前記ＯＴＰ認証プラットフォームに送信し、
    前記ＯＴＰ認証プラットフォームは、前記取引署名が正しいか否かを検証し、検証結果を前記ＯＴＰコントロール部に送信する、システム。
14. オンライン取引の安全な認証のためのコンピュータプログラムであって、
    クライアントおよびサーバの間の通信を暗号化するためのランダムセッション鍵を生成するための機能と、
    前記生成されたランダムセッション鍵に基づいて、前記クライアントを利用するユーザのユーザＩＤを検証するための機能であって、
    乱数に対応するキャプチャファクタを生成すること、
    前記キャプチャファクタに基づいてユーザマシン情報を抽出し、前記ユーザマシン情報を返信する前記クライアントに対して、前記キャプチャファクタを送信すること、
    前記ユーザマシン情報を前記クライアントから受信すること、
    前記ユーザマシン情報が、以前に格納されたユーザマシン情報と所定の一致度まで一致するか否かを判定することを備えるユーザＩＤを検証するための機能と、
    前記ユーザＩＤの前記検証が成功した場合に、取引画像情報を生成し、前記ランダムセッション鍵に基づいて前記取引画像情報を暗号化し、前記暗号化された取引画像情報を前記クライアントに送信するための機能と、
    取引署名を含む、前記取引画像情報の確認を受信するための機能と、
    前記ランダムセッション鍵に基づいて前記取引署名を検証するための機能と、
    をコンピュータによって実現させるコンピュータプログラム。
15. 請求項１４に記載のコンピュータプログラムであって、前記ランダムセッション鍵を生成するための機能は、
    前記クライアントによって生成され暗号化された乱数を受信すること、
    前記暗号化された乱数に基づいて前記ランダムセッション鍵を生成すること、
    前記ランダムセッション鍵を前記クライアントに送信すること、
    を備える、コンピュータプログラム。
16. 請求項１４に記載のコンピュータプログラムであって、さらに、
    暗号化されたユーザマシン情報および暗号化されたキャプチャファクタを前記クライアントから受信するための機能と、
    前記ランダムセッション鍵に基づいて、前記受信したキャプチャファクタおよびユーザマシン情報を復号するための機能と、
    前記受信したキャプチャファクタに基づいて前記ユーザマシン情報の一致度を決定するための機能と、
    をコンピュータによって実現させるコンピュータプログラム。
17. 請求項１４に記載のコンピュータプログラムであって、さらに、
    前記ユーザＩＤの検証が失敗した場合に、
    携帯電話ショートメッセージ送信要求が前記クライアントから受信されたか否かを判定するための機能と、
    前記携帯電話ショートメッセージ送信要求が前記クライアントから受信された場合に、
    ユーザ情報を取得し、
    携帯電話ショートメッセージ検証コードを生成し、
    前記携帯電話ショートメッセージ検証コードを前記ユーザに関連する携帯電話に送信するための機能と、
    前記携帯電話ショートメッセージ検証コードを前記クライアントから受信するための機能と、
    前記携帯電話ショートメッセージ検証コードを検証するための機能と、
    前記携帯電話ショートメッセージ検証コードの検証が成功した場合に、ユーザＩＤ検証成功結果を前記クライアントに送信するための機能と、
    をコンピュータによって実現させるコンピュータプログラム。
18. 請求項１４に記載のコンピュータプログラムであって、前記取引画像情報を生成するための機能は、
    取引情報、前記ランダムセッション鍵、および、ユーザシードに基づいて、取引検証コードを生成すること、
    前記取引情報および前記ランダムセッション鍵に基づいて要約情報を生成すること、
    ベース画像を生成すること、
    前記要約情報を前記ベース画像に追加すること、
    前記取引情報および前記取引検証コードを前記ベース画像に追加して、前記取引画像情報を生成すること、
    を備える、コンピュータプログラム。
19. 請求項１８に記載のコンピュータプログラムであって、前記取引署名を検証するための機能は、
    前記取引署名を前記クライアントから受信すること、
    前記取引署名が正しいか否かを検証すること、
    検証結果を前記クライアントに送信することと、
    を備える、コンピュータプログラム。
20. オンライン取引のための安全な認証クライアントであって、
    少なくとも１つのプロセッサであって、
    前記クライアントおよびサーバの間の通信を暗号化するためのランダムセッション鍵を受信し、
    乱数に対応するキャプチャファクタを前記サーバから受信し、
    前記受信したキャプチャファクタに基づいてユーザマシン情報を抽出し、
    前記受信したランダムセッション鍵に基づいてユーザの前記ユーザマシン情報を暗号化し、
    前記暗号化されたユーザマシン情報を前記サーバに送信し、前記サーバはユーザマシン情報と以前に格納されたユーザマシン情報とを比較し、前記ユーザマシン情報が、以前に格納されたユーザマシン情報と所定の一致度まで一致するか否かを判定するように構成されており、
    暗号化された取引画像情報を前記サーバから受信し、
    前記取引画像情報の確認を暗号化し、
    前記取引画像情報の前記確認を前記サーバに送信するように構成されているプロセッサと、
    前記プロセッサに接続され、前記プロセッサに命令を提供するメモリと、
    を備える、クライアント。
21. 請求項２０に記載のクライアントであって、前記ランダムセッション鍵の受信は、
    乱数を生成し、
    事前設定されたＲＳＡ公開鍵に基づいて前記乱数を暗号化し、
    前記暗号化された乱数を前記サーバに送信すること、
    を備える、クライアント。
22. 請求項２０に記載のクライアントであって、前記ユーザマシン情報の抽出は、
    前記ランダムセッション鍵に基づいて前記ユーザマシン情報を暗号化し、
    前記暗号化されたユーザマシン情報を前記サーバに送信すること、
    を備える、クライアント。
23. 請求項２０に記載のクライアントであって、前記少なくとも１つのプロセッサは、さらに、
    携帯電話ショートメッセージ送信要求を前記サーバに送信し、
    携帯電話ショートメッセージ検証コードを前記サーバから受信し、
    前記携帯電話ショートメッセージ検証コードを前記サーバに送信し、
    ユーザＩＤ検証成功結果を前記サーバから受信するように構成されている、クライアント。

Images