JP4861417B2 - 拡張ワンタイム・パスワード方法および装置 - Google Patents

Description

本発明は、インターネット認証、特に、ワンタイム・パスワードを用いる認証に関する。

多くのインターネット・ユーザは、サービス・プロバイダ、協同ネットワーク、有料サービス、または銀行口座あるいはクレジット・アカウントに対する特定なアクセス権を持つ。権利を行使するために、ユーザは、彼ら自身を認証する必要がある。よく知られ一般的に用いられるユーザ認証の方法は、ユーザ名およびパスワードを入力することに基づくものである。

しかし、インターネット詐欺が増加および高度化している現在、コミュニケーション・ネットワークを通るデータをアタッカーが容易に傍受してオリジナル・ユーザのＩＤおよび権利を偽って再利用することが可能なため、ユーザ名およびパスワードによる認証は、もはや安全であるとはみなされない。

ユーザ名およびパスワードによる方式の脆弱性を克服するための共通改善策として、多くの業者は、一度きりのパスワード（以下、「ＯＴＰ」）を提供している。これは、一つのパスワードを、単一のログインまたはトランザクションに対してのみ使用することに基づいている。このため、その後、このパスワードは無効となる。次のログインまたはトランザクションには、異なるパスワードが必要となる。したがって、たとえ誰かがパスワードを傍受したとしても、それは、将来のトランザクションには無効である。

ワンタイム・パスワードを生成および管理するための、三つの基本的な方法がある。一つは、紙または電子ファイル上にパスワードの長いリストを持つことである。第二のものは、パソコン（デスクトップ、ラップトップ、パームトップあるいは高度機能付き電話）上でソフトウェアを実行して、そのようなパスワードを生成することである。第三のものは、専用ハードウェア・デバイスを用いて、パスワードを生成することである。本発明は、そのようなハードウェア・デバイスに焦点を絞る。

図１Ａは、専用ＯＴＰ認証デバイス１１０（典型的に、ＯＴＰ「トークン」）を用いて、ワンタイム・パスワードを生成する、背景技術のシステム１００を示す。コンピュータ１６０は、例えば、情報またはトランザクションへアクセスする等の目標機能を達成するために、サーバ１７０上で稼働するサーバ・アプリケーション１８２と協働してクライアント・アプリケーション１６８を実行するための処理容量（図示せず）を含む。クライアント・アプリケーション１６８は、専用プログラムまたは汎用ウェブ・ブラウザである。サーバ・アプリケーション１８２は、目標機能を提供するために、ＯＴＰ検査機構１７８からの許可を必要とする。ＯＴＰ検査機構１７８は、クライアント・アプリケーション１６８からパスワードを受信したサーバ・アプリケーション１８２から（一度限りの）パスワードを受信してチェックするように考案されたソフトウェア・モジュールである。考察中の構成においては、そのパスワードは、ＯＴＰ認証デバイス１１０によって生成されてＯＴＰ認証デバイスから認証デバイス・インターフェイス１６４を介して受信されたデータから得る。ＯＴＰ認証デバイス１１０は、ユーザが携帯する、複数のコンピュータ１６０とのインターフェイスに適応した、セキュアなポータブル・デバイスである。ＯＴＰ認証デバイス１１０の核心は、ＯＴＰジェネレータ１３０であり、これは、トリガー１２０とＯＴＰ認証デバイス１１０内に記録した秘密のユーザ・キー１３２とに基づいて一度限りのパスワードを生成するように考案された、マイクロプロセッサ・ベースの暗号ソフトウェア・ルーチンである。秘密ユーザ・キー１３２データへのアクセスおよび／あるいはデータの改ざんを防止するために、ＯＴＰデバイス１１０は、典型的に、改ざん不可能に構成する。

トリガー１２０は、ＯＴＰジェネレータ１３０による一つのパスワード生成オペレーションから他の生成セッションへ変遷させる要素であり、それゆえに、パスワードの「一度限りの」局面を提供する。トリガー１２０を生成するための背景技術としては、サーバ１７０から受信されるランダムなチャレンジ１２０Ａ、ＯＴＰ認証デバイス１１０内に組み入れられた精密なリアルタイム・クロック１２０Ｂから受信される完全な日付文字列、または連続的な各パスワード生成に対して１だけ増加するカウンタ１２０Ｃの、三つの一般的なアプローチがある。

この開示全体に渡って、「セッションＯＴＰデータ」は、トリガー１２０および秘密ユーザ・キー１３２から得られるデータを指す。このセッションＯＴＰデータを、ＯＴＰ認証デバイス１１０および／あるいはクライアントワークステーション１６０内で、ユーザ認証データ（すなわち、パスワード、生物測定データなど）と組み合わせることによって、２ファクタ（またはマルチ・ファクタ）認証データを生成してもよい。ＯＴＰ認証デバイス１１０内で組み合わせが実行される特定なケースでは、２ファクタ認証データは、それ自体が「セッションＯＴＰデータ」の形式にある。それにもかかわらず、ユーザ・キー１３２およびトリガー１２０からセッションＯＴＰデータが得られる限り、ＯＴＰデバイス１１０からクライアント・ワークステーション１６０へ提供される「セッションＯＴＰデータ」が、ユーザが提供するデータ（すなわち、パスワードあるいはＰＩＮデータ、または生物測定データ）から得られるマルチ・ファクタ認証データであるという明確な要件はない。

オプションとして典型的に、ＯＴＰ認証デバイス１１０を見つけた、または盗んだ者による不正使用を防止するために、ＯＴＰ認証デバイス１１０内にユーザ識別子（またはユーザＩＤモジュール）１３４を設けてもよい。多くの実施例において、ＯＴＰジェネレータ１３０は、ユーザ識別子１３４が正しいユーザＩＤを提供しない限り、セッションＯＴＰデータを生成しない（または送信しない）。

ユーザ識別のための一般的な方法は、個人識別番号（ＰＩＮ）を受信するための小さなキーパッド、生物測定センサ、またはコンピュータすなわちクライアント・ワークステーション１６０から受信した（典型的に、クライアント・ワークステーション１６０のキーボードでクライアント・ワークステーション１６０へ入力した）ＰＩＮあるいは他のデータをチェックするためのコンパレータを用いることである。

ＯＴＰインターフェイス１４０は、ＯＴＰ認証デバイス１１０とコンピュータ１６０との間でＯＴＰに関するデータを交換するために、認証デバイス・インターフェイス１６４とインターフェイスする。特に、ＯＴＰジェネレータ１３０がセッションＯＴＰを生成するときはいつも、ＯＴＰ送信器（図示せず）は、ＯＴＰデバイス１１０からセッションＯＴＰを「送信する」（すなわち、セッションＯＴＰデータをコンピュータ１６０へＯＴＰインターフェイス１４０を介して提供するためのデータ交換を表示および／あるいは実行する）。

ＯＴＰインターフェイス１４０の一般的な実施例としては、以下のものがある。パスワードを読んでそれを手作業で、認証デバイス・インターフェイス１６４として機能するキーボードで入力するためにユーザが使用するディスプレイ１４０Ａ（この場合、トリガー１２０としては、リアルタイム・クロック１２０Ｂまたはカウンタ１２０Ｃが好ましい）。双方向シリアル通信を確立するために、認証デバイス・インターフェイス１６４として機能する適合ＵＳＢインターフェイスとインターフェイスするＵＳＢインターフェイス１４０Ｂ（または他の「接触」インターフェイス）。または認証デバイス・インターフェイス１６４として機能する互換性赤外線あるいはラジオ波トランシーバとインターフェイスするＩＲ/ＲＦインターフェイス１４０Ｃ（または他の「無線インターフェイス）。ＵＳＢ１４０ＢおよびＩＲ/ＲＦインターフェイス１４０Ｃのケースでは、トリガー１２０に対するすべての三つのアプローチが実行可能である。

注目すべきことは、ＯＴＰインターフェイス１４０がディスプレイ１４０Ａを適用するケースにおいては、ＯＴＰ認証デバイス１１０とコンピュータ１６０と間に、直接的な電子通信リンクが要らないということである。多くの例では、ユーザが、ディスプレイ１４０Ｂから読んだセッションＯＴＰデータ１４０と、ユーザ認証データ（すなわち、「２ファクタ」認証の二番目のものに対する、例えば、パスワードおよび／あるいは生物測定データ）との両方をクライアント・ワークステーション１６０へ入力する。このクライアント・ワークステーションで、これらデータが、（それ自体が一種のＯＴＰである）２ファクタ認証パスワードを生成するために組み合わされる。

サーバ１７０は、ＯＴＰ検査機構１７８の許可があった場合にのみ、サーバ・アプリケーション１８２が目標サービスをクライアント・アプリケーション１６８へ提供することを可能にする。ＯＴＰ検査機構１７８は、ユーザ・キー１３２およびトリガー１２０を考慮しながら、コンピュータ１６０を介してＯＴＰ認証デバイス１１０から受信したパスワードをチェックするための処理および暗号手段を含む。ユーザ・キー１３２は、適格なユーザの記録を持ち彼らのユーザ名およびキーを含むユーザ・データベース１７６から読み込む。トリガー１２０の値は、各々、チャレンジ１２０Ａ、リアルタイム・クロック１２０Ｂおよびカウンタ１２０Ｃから選択したトリガー１２０のための方法に対応して、チャレンジ・ジェネレータ、リアルタイム・クロックまたはカウンタを含むトリガー・シンクロナイザ１７４からＯＴＰ検査機構１７８によって読み込む。

図１Ｂは、図１Ａと同じ、従来の技術によるシステムを図解する。図１Ｂは、ＯＴＰ認証デバイス１１０、コンピュータ１６０（すなわち、クライアント・ワークステーション）およびサーバ１７０の配置を明示する。より具体的には、図１Ｂに図解するように、クライアント・ワークステーションすなわちコンピュータ１６０は、ＩＳＰ（ＩＳＰアクセス・ポイント）が提供するＷＡＮゲートウェイ２２で、インターネット・アクセス・リンク（例えば、ブロードバンド・リンク、ダイヤルアップ・リンク、ソーホー・リンクあるいは他のＩＳＰ（インターネット・サービス・プロバイダ）アクセス・リンク、または携帯デバイスでのサーフィンのための携帯電話インターネット・アクセス・リンク）を介して広域ネットワーク２０へ接続する。サーバ１７０は、広域ネットワーク２０を介して、（典型的に、パケット切り替えプロトコルを用いて）クライアント・ワークステーション１６０にセッションＯＴＰの要求を送信する。クライアント・ワークステーション１６０がこの要求を受信すると即座に、ＯＴＰ認証デバイス１１０は、（自動的に、またはユーザがクライアント・ワークステーションのキーボードを介して入力することによって）セッションＯＴＰをクライアント・ワークステーション１６０へ送信する。このセッションＯＴＰデータは、サーバ１７０へ直接的に送信する、または認証データ（すなわち、パスワード、ＰＩＮ、生物測定値）と組み合わせて、それから広域ネットワーク（すなわち、インターネット）２０を介して、サーバ１７０へ送信する。

図２は、背景技術による、図１Ａおよび１Ｂに示すシステム１００のオペレーションを表す。ステップ２０１では、コンピュータ１６０のユーザが、クライアント・アプリケーション１６８を起動する。クライアント・アプリケーション１６８は、例えば、データへのアクセス、またはトランザクションの開始などの、ユーザに対する所望の目標機能を提供するために、サーバ・アプリケーション１８２と通信して相互作用する必要がある。ステップ２２１では、サーバ・アプリケーション１８２が、クライアント・アプリケーション１６８に応答して、ＯＴＰによるユーザ認証を要求する。この要求はＯＴＰ認証デバイス１１０へ転送され、ステップ２２１で、ＯＴＰジェネレータ１３０が、トリガー・ユニット１２０からの、ＯＴＰを生成するためのトリガーを要求する。トリガーがチャレンジ１２０Ａである場合、サーバ１７０は、トリガー・シンクロナイザ１７４内で、ランダムなチャレンジ文字列を生成し、それを、コンピュータ１６０を介してＯＴＰジェネレータ１３０へ提供する。トリガーがリアルタイム・クロック１２０Ｂまたはカウンタ１２０Ｃのいずれかである場合は、それは、ＯＴＰ認証デバイス１１０内で自動的に生成する。ステップ２３１では、ＯＴＰジェネレータ１３０が、トリガー１２０およびユーザ・キー１３２を処理して、ＯＴＰを生成する。ステップ２４１では、ステップ２３１で生成したＯＴＰを、ＯＴＰデバイス１１０からクライアント・ワークステーション１６０へ送信し、クライアント・ワークステーションが、ＯＴＰから得たデータをサーバ１７０へ送信する。ステップ２５１では、ＯＴＰ検査機構１７８は、トリガー・シンクロナイザ１７４から読み込んだトリガーとユーザ・データベース１７６から読み込んだユーザ・キーとに基づいて予想ＯＴＰを計算し、それを、コンピュータ１６０を介してＯＴＰ認証デバイス１１０から受信したＯＴＰと比較する。その検証が肯定である場合、プロセスはステップ２６１からステップ２７１へ進み、クライアント・サーバ・セッションが開始し、クライアント・アプリケーション１６８とサーバ・アプリケーション１８２との協調による所望の目標サービスが提供される。検証が否定である場合、プロセスはステップ２６１からステップ２８１へ進み、サーバ１７０は、コンピュータ１６０から受信したサービス要求を拒否し、コンピュータ１６０によって、そのことをユーザへ通知する。

背景技術の典型的なユーザ認証方法を用いる上記説明のシステムは、（サーバ１７０を稼働する）サービス・プロバイダによる、（コンピュータ１６０を用いる）ユーザの認証に焦点を合わせている。この一方向の認証方法は、サービス・プロバイダおよびユーザをユーザＩＤの盗難からかなり安全に保護してきたが、現在は、「フィッシング」と呼ばれる新手の詐欺が主流となってきている。フィッシングでは、銀行、または正規の評判のよいインターネット商取引サイトからのものと思いこませる電子メール・メッセージがユーザに届く。このメッセージは、ユーザに、彼の情報を更新するよう、または商取引を処理するよう促す。このプロセス中、ユーザは、彼自身を認証するように要求される。そして犯人は、彼が提供する情報を、ユーザのＩＤを盗むために、また、ユーザに代わって他のトランザクションを提供するために用いる。ユーザ名とパスワードの組み合わせは、犯人が、ユーザが渡してしまったユーザ名およびパスワードを、より多くのトランザクションに再利用できるため、フィッシングに非常に脆弱である。ＯＴＰの使用は、フィッシングの有効性を激減させるが、「仲裁者」と呼ばれるフィッシングの異形式に対しては、完全な保護を提供しない。仲裁者攻撃は、偽のサイトからのメッセージが、ユーザには正規の銀行業務または商取引として始まる。トランザクション中、犯人は、実際のサイトで彼自身のトランザクションを処理する。犯人は、ＯＴＰに基づく認証セッションを通過し、それから、彼自身または彼のパートナーへお金を転送する、あるいは商品を発送するトランザクションを処理する。

仲裁者攻撃の危険性がある環境におけるセキュリティ向上技術に関する、多数の文書が公表されている。潜在的に関連する特許および公表特許出願は、ＵＳ２００１００４５４５１、ＵＳ２００６００４１７５９、ＵＳ６１４１７５２、ＷＯ２００５０９８６３０、ＷＯ０６０１８６４７およびＷＯ０６０６２８３８を含む。これらすべては、参照によって全部を含むものとする。

ＲＳＡセキュリティ社からの白書「リアルタイム・フィッシング攻撃に対する予防のための、ワンタイム・パスワードの改良」は、ＯＴＰデバイス（すなわち、電子トークン）をクライアント・ワークステーションと共に使用する技術を開示している。ＯＴＰデバイスは、クライアント・ワークステーション（例えば、ＵＳＢインターフェイスを介して、トリガーから得られるデータを提供する、ＵＳＢインターフェイスを介して通信する「接触」ＯＴＰデバイス）と通信するか、または人間であるユーザが使用して、クライアント・ワークステーションのキーボードで、トリガーから得られたＯＴＰコード（すなわち、トリガーから得られたデータ）をタイプするかのどちらかである。（自動的に提供される、またはＯＴＰトークンのスクリーンからコピーする）トリガーから得られたＯＴＰコードは、クライアント・ワークステーション上で、クライアント・ワークステーションへ入力されたパスワードあるいはＰＩＮデータと組み合わせて、「２ファクタ」パスワードを提供する。より具体的には、ブラウザへこのパスワードあるいはＰＩＮデータを入力して、データを組み合わせた２ファクタ認証データをインターネット上へ直接送信する代わりに、ユーザ・パスワードあるいはＰＩＮを受信するためにクライアント・ワークステーション上に存在する（典型的に、ブラウザから分離した）ソフトウェア「パスワード保護モジュール」（ＰＰＭ）が提供される。クライアント・ワークステーション上では、ＰＰＭモジュールが、ユーザ・パスワードあるいはＰＩＮを、ＯＴＰデバイス・トークンから提供されたＯＴＰデータと組み合わせる。クライアント・ワークステーションからサーバへ送信する前に、組み合わせたデータを、要求サーバのＩＤに応じてＰＰＭによって暗号化あるいはハッシュする。これは、建前として、「仲裁者」が、ハッシュ・パスワードにアクセスすること、そしてＯＴＰデータおよび／あるいは２ファクタ認証データおよび／あるいはユーザ認証データを知ることを困難にする。

ＰＰＭは、典型的に、攻撃を受けやすいブラウザから分離したアプリケーションではあるが、この従来の技術の一つの欠点は、ＯＴＰ認証を要求しているサーバが正規なものでないという危険性がある場合でさえも、セッションＯＴＰデータが、常に、（ユーザによって、またはデバイス・インターフェイスを通して）典型的に改ざん不可能なＯＴＰデバイスから、潜在的に不安定なクライアント・ワークステーションへ提供されることである。

フィッシングおよび仲裁者攻撃の脅威があるため、認可当事者によるアクセスからＯＴＰデータを保護するための、改善された方法および装置の必要性がある。

さて、本発明者は、フィッシング攻撃を有効的にブロックするために、ワンタイム・パスワード（ＯＴＰ）インフラストラクチャが提供する保護を拡張するためのシステムおよび機能を開示する。さて、本発明者は、特に、セッションＯＴＰを要求するサーバが正規サーバであるといういくつかの表示がある場合にだけ、クライアント・ワークステーションへセッションＯＴＰデータを提供することが有利であることを開示する。そうでない場合、すなわち、セッションＯＴＰデータを要求するサーバが正規サーバであるという表示が全くない（または表示が不十分である）場合、ＯＴＰデバイスが、クライアント・ワークステーションあるいは端末へ、セッションＯＴＰデータを知らせないことは有利である。

明白な要件ではないけれども、模範的な実施例においては、要求サーバが正規であるかどうかを判定することに関わる特定の機能は、改ざん不可能なＯＴＰデバイス内で実行してもよい。そうすることによって、サーバのＩＤを検証するためのメカニズムで、（例えば、クラッカーおよび／あるいはサギ師および／あるいは仲裁者による）改ざんに対する、より一層の保護を提供する。択一的に、または追加的に、この機能は、クライアント・ワークステーション内で実行してもよい。

さて、（例えば、セッションＯＴＰに対する、サーバで生成された要求に応じて）セッションＯＴＰデータの送信を処理する方法を初めて開示する。本開示の方法は、サーバ、広域ネットワーク（典型的に、インターネット）を介してサーバと通信するクライアント・ワークステーション、そしてデバイス・インターフェイスを介して（すなわち、『接触』または『無線』インターフェイスを介して）クライアント・ワークステーションとインターフェイスしたＯＴＰトークンからなるシステムで実行してもよい。本開示の方法は、ａ）サーバを少なくとも部分的に識別する情報を、（ＯＴＰデバイスおよび／あるいはクライアント・ワークステーションによって）サーバから受信するステップ、ｂ）識別情報が正規サーバを表示するかどうかを判定するステップ、そしてｃ）判定に応じて、ｉ）ＯＴＰトークンから、内部で生成したセッションＯＴＰ（すなわち、クライアント・ワークステーション内ではなく、ＯＴＰトークン内で生成されるセッションＯＴＰであり、トリガーと秘密ユーザ・キーとによって、またオプションとして、ユーザ認証データに応じて生成されるセッションＯＴＰ）を表示するデータを送信すること、そしてii）送信を抑止することからなるグループから選択した一つの処置を実行するように決定する（すなわち、ＯＴＰトークンおよび／あるいはクライアント・ワークステーションによる決定を実行する）ステップを含む。決定が肯定的な決定（すなわち、セッションＯＴＰを表示するデータを送信するという決定）である場合にだけ、ＯＴＰトークンから、セッションＯＴＰを表示するデータを送信する。

いくつかの実施例によれば、決定が肯定である場合にだけ、送信は、インターフェイスを介してＯＴＰトークンからクライアント・ワークステーションへ、表示データのデバイス間データ転送を実行することを含む。

いくつかの実施例によれば、決定が肯定である場合にだけ、送信は、ＯＴＰトークンのディスプレイ・スクリーン上に、セッションＯＴＰを表示するデータを示すことを含む。

いくつかの実施例によれば、セッションＯＴＰを表示するデータは、ユーザ認証データから得たマルチ・ファクタ認証データである。

択一的に、セッションＯＴＰを表示するデータは、ユーザ認証データとは無関係である。

いくつかの実施例によれば、方法は、さらに、ｄ）決定が否定的決定である場合、セッションＯＴＰを生成することを、ＯＴＰトークンによって抑止することからなる。

いくつかの実施例によれば、方法は、さらに、ｄ）決定が否定的決定である場合、ｉ）ＯＴＰトークン内で、セッションＯＴＰを内部的に生成すること、そしてii）セッションＯＴＰがＯＴＰトークン内に残留する状態を維持することからなる。

いくつかの実施例によれば、方法は、さらに、受信の前に、ＯＴＰトークン内の埋め込み型セキュリティ・ブラウザを用いて、ＯＴＰトークンとサーバとの間のセキュアなセッションを開始するステップ（ｄ）からなる。

いくつかの実施例によれば、さらに、方法は、（ｅ）セッションの開始後、セッションのクライアント・エンドを、ＯＴＰトークンからクライアント・ワークステーションへ転送するステップからなり、受信および判定の少なくとも一つは、クライアント・ワークステーションで実行する。

いくつかの実施例によれば、セッションのクライアント・テルミヌスおよび／あるいはエンドは、ＯＴＰトークンによってサーバから識別情報を受信するときに、埋め込み型ブラウザに残留する（すなわち、クライアント・ワークステーションが「データ導管」として用いられ、通信はＯＴＰデバイス内から管理する）。

いくつかの実施例によれば、受信は、ＯＴＰトークン（すなわち、ＯＴＰトークン内に組み込んだブラウザ）によって、サーバとＯＴＰトークンとの間の通信リンクを介して実行する。すなわち、ＯＴＰトークンがセッションのクライアント・エンドであり、クライアント・ワークステーションは「データ導管」としてのみ用いられ、通信はＯＴＰデバイス内から管理される。

いくつかの実施例によれば、判定はＯＴＰトークン内で実行する。いくつかの実施例においては、ＯＴＰトークン内が改ざん不可能な環境であるため、これによって、セキュリティの追加手段を提供する。

いくつかの実施例によれば、判定は、（クライアント・ワークステーションから、および／あるいはＯＴＰトークン内に存在するデータベース・クライアント・コードから）ＯＴＰトークン内に存在するデータベースに問い合わせすることを含む。

いくつかの実施例によれば、データベースは不変データベースである。したがって、一例としては、金融機関、または金融機関のグループは、（すなわち、財政的なインストラクションまたは金融機関グループに関する）正規サーバの「ホワイトリスト」を埋め込んだＯＴＰデバイスを配付できる。このホワイトリストは変更不可能なもので、「包括的な解決策」を提供するものではないが、配布する金融機関（および／あるいはそれらの顧客）にとっては適切なものであろう。また、サーバの正当性を認証するためのデータベースの不変性は、セキュリティ対策を付加したことにもなる。

いくつかの実施例によれば、データベースは、許容可能なＵＲＬの所定リスト、許容可能なＩＰアドレスの所定リスト、そして証明フィールドに対する許容可能な値の所定リストの一つを含む。

いくつかの実施例によれば、前記判定は、（例えば、サーバのＩＰアドレスを表示する送信パケット・データから抽出することによる）受信通信のプロトコル・データ、受信通信内で転送された証明データ、ＵＲＬデータ、そしてＩＰアドレス・データのうちの、少なくとも一つに応じて実行する。

いくつかの実施例によれば、判定は、サーバから受信した証明のいくつかの属性のみに応じて実行する。したがって、一例として、多くのフィールドを持たせた証明の、すべてのフィールドではなく、いくつかの証明フィールドを、サーバの正当性を確認あるいは判定するために用いることができる。これは、多数の模範的なシナリオに有用である。例えば、サーバの「ファミリー」またはサーバ・パラメータを定義する（それによって、サーバの識別子を単に『部分的に』定義する）ことが好ましい。例えば、発行人（例えば、セキュアなサーバを運営する銀行または他のオペレータ）が、複数の証明プロバイダと仕事をする場合、このフィールドが、証明を検証するのに要求されることはない。例えば、銀行が、特定なグループとして多くのサーバを配置する場合、他のフィールドは用いても、グループのどのサーバがセッションＯＴＰ要求を発しているのかを指定する証明フィールド・データは、使用しない。これは、発行人（例えば、銀行）に対して、（例えば、不変データベースを含む）ＯＴＰデバイスの発行時のサーバ識別パラメータを完璧に指定する必要性はないという柔軟性を提供する。

注目すべきは、いくつかの状況下でセキュリティを提供する「不変データベース」が、本発明を制限するものではないということである。

模範的な実施例では、送信データは、暗号化および／あるいはハッシュされる。

さて、広域ネットワークを介してサーバと通信しているクライアント・ワークステーションと共に使用するためのＯＴＰトークンを初めて開示する。本開示のＯＴＰデバイスは、次のものを含む。ａ）クライアント・ワークステーションから、サーバを少なくとも部分的に識別する情報を含むデータを受信するためのデバイス・ポート（すなわち、ＵＳＢポート等の『接触』型および／あるいは無線の、一つ以上のデバイス・ポート）。ｂ）情報が正規サーバを表示するかどうかを判定するためのサーバ正当性エンジン。ｃ）セッションＯＴＰを生成するように作動可能なＯＴＰジェネレータ。そしてｄ）判定結果に応じて、ｉ）ＯＴＰトークンから、セッションＯＴＰを表示するデータを送信すること、そしてii）その送信を抑止することからなるグループから選択した一つの処置を実行するように決定するよう作動可能なＯＴＰ送信決定エンジン。

模範的な実施例においては、デバイスは、さらに、ｃ）セッションＯＴＰを表示するデータを送信するためのＯＴＰ送信器からなる。

いくつかの実施例によれば、決定が肯定である場合、ＯＴＰ送信器は、データポートを介してクライアント・ワークステーションへ、セッションＯＴＰを表示するデータを送信するように作動可能である。

いくつかの実施例によれば、ＯＴＰトークンは、さらに、ｄ）データ・ディスプレイからなり、エンジンが、識別情報が正規サーバを表示すると判定した場合にのみ、ＯＴＰ送信器は、セッションＯＴＰを表示するデータをデータ・ディスプレイへ送信するように作動可能である。

いくつかの実施例によれば、ＯＴＰトークンは、さらに、ｄ）ＯＴＰトークン内に組み込んだ埋め込み型セキュリティ・ブラウザからなり、埋め込み型ブラウザは、ＯＴＰトークンとサーバとの間でセキュアなセッションを開始するように作動可能である。

いくつかの実施例によれば埋め込み型セキュリティ・ブラウザは、セキュアなセッション中、識別情報を受信するように作動可能である。

いくつかの実施例によればサーバ正当性エンジンは、ｄ）所定データのデータベースを含み、サーバ正当性エンジンは、判定をデータベースのコンテンツに応じて実行するように作動可能である。

いくつかの実施例によれば、データベースは不変データベースである。これは、例えば、（包括的なＯＴＰデバイスではなく）所定グループのサーバとだけ作動する特別なＯＴＰデバイスを配布する場合に有用である。この場合、サギ師および／あるいは犯罪者および／あるいはクラッカーがデータベースを修正してサーバを付加することができないよう、セキュリティを付加することが好ましい。

いくつかの実施例によれば、データベースは、許容可能なＵＲＬの所定リスト、許容可能なＩＰアドレスの所定リスト、そして証明フィールドに対する許容可能な値の所定リストの一つを含む。

いくつかの実施例によれば、サーバ正当性エンジンは、サーバからの通信プロトコル・データ、そしてサーバからの通信で送信される証明データの、少なくとも一つに応じて、判定を実行するように作動可能である。

いくつかの実施例によれば、サーバ正当性エンジンは、サーバから受信した証明のいくつかの属性にのみ応じて、判定を実行するように作動可能である。

いくつかの実施例によれば、ＯＴＰジェネレータは、ユーザ認証データに応じてセッションＯＴＰを生成するように作動可能であり、それによって、セッションＯＴＰをマルチ・ファクタ認証データとして生成する。

いくつかの実施例によれば、デバイスは、さらに、ｅ）ユーザ認証データを認証するためのユーザ識別モジュールからなる。

いくつかの実施例によれば、ＯＴＰ送信決定エンジンは、ユーザ認証データの認証結果に応じて、決定を実行するように作動可能である。

さて、セッションＯＴＰデータの送信を処理するためのシステムを初めて開示する。本開示のシステムは、以下のものからなる。ａ）広域ネットワークを介してサーバと通信するクライアント・ワークステーション。ｂ）クライアント・ワークステーションとインターフェイスしたＯＴＰトークン。なお、ＯＴＰトークンは、ｉ）クライアント・ワークステーションとインターフェイスするためのデバイス・ポート、そしてii）セッションＯＴＰを生成するように作動可能なＯＴＰジェネレータを含み、ＯＴＰトークンおよびクライアント・ワークステーションの少なくとも一つが、サーバを識別する情報を受信するように作動可能である。システムは、さらに、次のものからなる。ｃ）情報が正規サーバを表示するかどうかを判定するためのサーバ正当性エンジン。なお、サーバ正当性エンジンは、ＯＴＰトークンおよびクライアント・ワークステーションの少なくとも一つの内に少なくとも部分的に存在する。ｄ）判定結果に応じて、ｉ）ＯＴＰトークンから、セッションＯＴＰを表示するデータを送信すること、そしてii）その送信を抑止することからなるグループから選択した一つの処置を実行するように決定するよう作動可能なＯＴＰ送信決定エンジン。なお、ＯＴＰ送信決定エンジンは、ＯＴＰトークンおよびクライアント・ワークステーションの、少なくとも一つの内に少なくとも部分的に存在する。

さて、コンピュータで読み込み可能な記憶メディア内に具現化した、コンピュータで読み込み可能な、次のインストラクションからなるコードを持つコンピュータで読み込み可能な記憶メディアを初めて開示する。ａ）広域ネットワークを介してサーバと通信するクライアント・ワークステーション、そしてサーバとインターフェイスさせたＯＴＰトークンの、少なくとも一つによって、サーバを少なくとも部分的に識別する情報を受信するためのインストラクション。ｂ）識別情報が正規サーバを表示するかどうかを判定するためのインストラクション。そしてｃ）判定に応じて、ｉ）ＯＴＰトークンから、内部で生成したセッションＯＴＰを表示するデータを送信すること、そしてii）その送信を抑止することからなるグループから選択した一つの処置を実行するように決定するためのインストラクション。

以下の詳細な説明および実施例から、これらの、そして他の実施例も明らかになる。

本発明をいくつかの実施例および図面を用いて説明するが、当業者には、発明が説明の実施例または図面に限定されないことは明らかである。理解すべきことは、図面およびその詳細説明が、発明を開示の特定な形態に制限することを意図しておらず、逆に、本発明のすべての修正物、同等物および代替物が、本発明の精神および範囲内に含まれることである。この出願書を通して用いる単語「そうしてもよい」は、必須の感覚（すなわち、「そうしなければならない」という意味）ではなく、寛容な感覚（すなわち「潜在性を持つ」という意味）で用いている。

さて、本発明を、特定な実施例に関して説明する。本発明が開示の実施例に限定されず、また、添付の特定請求項に記載の発明を実行するために、セッション・データを処理するための本開示の装置、デバイスおよびコンピュータ読み取り可能なコードすべての特徴が必要なわけではないことは理解すべきである。本発明を完全に実行するために、デバイスの種々の要素および特徴を説明する。また、この開示を通して、プロセスまたは方法の図示または説明における方法のステップは、一つのステップがもう一つのステップの先行実行に依存することが文脈から明白である場合を除き、どの順序で実行してもよいし、あるいは同時に実行してもよい。文脈からそうでないことが明白である場合を除き、クライアント・ワークステーション、サーバまたはＯＴＰトークンの開示コンポーネントのいずれをも、ハードウェアおよび／あるいはソフトウェアおよび／あるいはファームウェアの、どの組み合わせで実行してもよい。

さて、図３Ａから図３Ｅを参照する。これらは、本発明の好適実施例に従って構成したシステム３００を表す。なお、システム３００の特定なブロックおよび機能は、図１Ａおよび１Ｂに示すシステム１００の対応するブロックおよび機能に類似している、または同一である。したがって、図３Ａから図３Ｄに示すＯＴＰ認証デバイス３１０は、トリガー１２０、そしてユーザ・キー・リポジトリ１３２のコンテンツとトリガー１２０の出力とに応じてセッションＯＴＰデータを生成するＯＴＰジェネレータ３３０を含む。オプションとして、セッションＯＴＰデータは、また、ユーザ認証データに応じて生成する（例えば、ユーザ識別子１３４によって取り扱う）。択一的に、セッションＯＴＰデータは、ユーザ認証データからは独立しており、トリガー１２０の出力とユーザ・キー・リポジトリ１３２（典型的に、ユーザ・キー・データが内在する、改ざん不可能な、または干渉不可能な不揮発性メモリ）のコンテンツとにのみ依存する。

ＯＴＰセッション・データは、ＯＴＰ送信器３４２によって、ＯＴＰトークン・デバイス３１０からインターフェイス１４０を介してディスプレイ・インターフェイス１４０Ａの一部として設けられたディスプレイ・スクリーンへ、またはコンタクト・インターフェイス１４０Ｂあるいは無線デバイス・インターフェイス１４０Ｃを介してクライアント・ワークステーション３６０へ送信してもよい。

ＯＴＰセッション・データは、ＯＴＰセッションの要求が受信される毎にＯＴＰトークン３１０から無条件で転送されるものではなく、その送信は、ＯＴＰ送信決定エンジン３４４が実行する「進行あるいは停止」判定に応じて実行する。 図３Ａから図３Ｅにおいては、特定なコンポーネント（例えば、ＯＴＰ送信決定エンジン３４４、ユーザ識別子１３４、ブラウザ３５０およびサーバ正当性エンジン３４０）を、ＯＴＰトークン３１０内に存在するように表している。しかし、発明者は、これらのコンポーネントの一つ以上が、部分的に、または全体的にＯＴＰトークンの外側に存在する実施例も考察している。

送信決定エンジン３４４は、前記「進行あるいは停止」送信判定を、一つ以上の要因によって実行してもよい。典型的に、ＯＴＰトークン３１０は、セッションＯＴＰの要求に関連するサーバ識別子が、要求サーバ１７０が正規である可能性が高い（サギ師またはフィッシャーあるいは「仲裁者」である可能性が低い）ことを示すことを、サーバ正当性エンジン３４０が判定した場合にのみ、セキュアなＯＴＰトークンから（よりセキュアでないクライアント・ワークステーション３６０またはディスプレイ・スクリーンへ）セッションＯＴＰを送信する。

したがって、図３Ｄを参照すると、模範的な実施例では、サーバ正当性エンジン３４０は、データベース３６２、そして例えば、（単純に、ルック・アップを行うなどの）データベースに「尋ねる」操作を行うロジック３６０を含む。データベースは、「信用サーバ」を示す所定のデータを含む。したがって、サーバ正当性エンジン３４０は、現在のセッションＯＴＰが、典型的なフィッシングにおいて正規のサーバを装う偽サーバでではなく、正規のサーバで作成されることを検証するように作動する。信用サーバのデータベース３６０は、信用サーバ毎に例えば、ＩＰ（インターネット・プロトコル）アドレス、ＵＲＬ（ユニフォーム・リソース・ロケーター）または証明データ（例えば、前記要旨で論じたような『部分的な』証明データ）の少なくとも一つを含む記録から形成してもよい。

模範的な実施例においては、データベースは、ＯＴＰ認証デバイス３１０のプロバイダ（例えば、セキュアなセッションのために、そのようなデバイスを顧客に提供する銀行）によって、またはユーザによる入力を通して、または信頼できる当事者から信用サーバのファイルを受信することによって、データの蓄積を得る。いくつかの実施例においては、データベースは不変であり、ＯＴＰ認証トークン３１０の「出荷」前に構成される。

さて、図３Ｅを参照する。注目すべきは、コンピュータ３６０（すなわち、クライアント「ワークステーション」）が、図１Ａおよび１Ｂのコンピュータ１６０のものと同じ認証デバイス・インターフェイス１６４を含んでもよく、また、クライアント・アプリケーション３６８が、図１Ａおよび１Ｂのクライアント・アプリケーション１６８に類似してもよく、そして追加の機能として、（当業技術者には既知である、ＩＰ、ＬＴＲＬおよび／あるいは接続当事者の証明を識別するための標準識別サービスを用いて）ＩＤを読み込み、そのサーバＩＤをＯＴＰ認証デバイス３１０のサーバＩＤチェッカ３３４への入力として送信する問い合わせサーバ１７０を含むことである。本発明は、コンピュータ３６０またはサーバ１７０に対して、必ずしも修正を要求するものではない。注目すべきことは、コンピュータ３６０（「クライアント・ワークステーション」）が、サーバ１７０との通信が可能な、ユーザのどのようなコンピュータ・デバイスでもよいことである。例えば、コンピュータ３６０は、パーソナルデスクトップ、ラップトップまたはパームトップ・コンピュータ、携帯電話または２ウェイ・ポケットベルでもよい。ＯＴＰ認証デバイス３１０は、複数のコンピュータ３６０に接続可能な、独立した、ポータブル・デバイス（電子「トークン」）であり、ディスプレイを持つキー・フォブ、ＵＳＢトークン、トークン機能を持つＬＴＳＢディスク、リムーバブル・カード（例えば、セキュアデジタル、マルチメディア・カード、メモリ・スティックまたはＳＩＭカード）等の種々のフォーム・ファクタを持つことができる。あるいは、パソコン等のもう一つのコンピュータと共に用いるのであれば、携帯電話でもよい。

さらに、サーバ１７０は、本発明を「知る必要はない」ということにも注目すべきである。これは、本開示の方法と、既存のサーバ１７０に対するフィッシング攻撃の危険性を減少させるための装置との間に互換性を提供する。

図４Ａは、本発明の実施例による、図３Ａから図３Ｅに示すシステム３００のオペレーションを表す。大部分のステップは、図２のものと同じであるが、ステップ４０１、４１１、４２１および４３１が付加されている。したがって、クライアント・アプリケーション３６８がステップ２０１で起動された後、ステップ４０１で、クライアント・アプリケーション３６８の下で、コンピュータ３６０がサーバ１７０のＩＤを読み込んでそれをＯＴＰ認証デバイス３１０へ送信する。そしてステップ４１１で、それをサーバＩＤチェッカ３３４が、サーバＩＤチェッカ３３４の一部を形成する正規サーバのデータベースに対して検証する。サーバの検証が肯定である場合、プロセスは、ステップ４２１から、図２の場合のように、ステップ２１１、２２１、２３１、２４１、２５１、２６１、２７１および２８１へ進行し、そこで、ＯＴＰがＯＴＰ認証デバイス３１０のＯＴＰジェネレータ３３０によって生成され、それが、クライアント・サーバ・セッションを実行するための前提条件としてサーバ１７０によって検証される。もし、ステップ４１１における検証が否定である場合、プロセスは、ステップ４２１からステップ４３１の拒絶へ進む。この場合、ＯＴＰ認証デバイス３１０のＯＴＰジェネレータ３３０が有効なＯＴＰを生成せず、プロシージャは、クライアント・アプリケーション３６８またはサーバ・アプリケーション１８２のいずれかによって終了させられる。

注意すべきことは、図３および図４の構成が、ＯＴＰ認証デバイス３１０との双方向通信を必要とするため、ＵＳＢ１４０ＢまたはＩＲ/ＲＦインターフェイス１４０Ｃを使用することが好ましいことである。しかしながら、ＯＴＰインターフェイス１４０が、ＯＴＰ認証デバイス３１０とコンピュータ３６０との間の通信リンクのないディスプレイ１４０Ａを用いる場合、ＯＴＰ認証デバイス３１０には、（ユーザ識別子１３４のためのＰＩＮ入力にも使用使用可能な）キーパッド等の手作業入力デバイスが、サーバＩＤの入力のために必須となる。したがって、この場合、ユーザは、コンピュータ３６０のディスプレイ上のメッセージに促され、メッセージ内に示されたサーバＩＤをＯＴＰ認証デバイス３１０へキー入力し、それから、ディスプレイ１４０Ａ上に示されたＯＴＰを、コンピュータ３６０へキー入力する。

図４Ｂは、図４Ａで説明した模範的な認証ルーチンのサブルーチンを表す。このため、ルーチン４Ｂは、図４Ｂで説明する以外の認証ルーチンに関連して実行できることに注意すべきである。

図４Ｂに示すように、最初３８５に、（ＯＴＰデバイス１１０および／あるいはクライアント・ワークステーション１６０で）少なくとも部分的にサーバを識別する情報を受信する。それから、３８７において、識別情報が正規サーバ３８７を示しているかどうか（すなわち、サーバ１７０が、正規であり、信頼可能であり、本物である可能性が高いかどうか）を（例えば、サーバ正当性エンジン３４０によって）判定する。この判定結果に応じて、３８９において、（例えば、ＯＴＰ送信決定エンジン３４４によって）（セキュリティの低いクライアント・ワークステーションへＯＴＰセッション・データを送信するために）「進行あるいは停止」送信決定を行う（ただし、これは必ずしも、広域ネットワークを介してサーバ１７０へＯＴＰセッション・データを送信することに関する決定ではない）。３９１における決定が肯定（すなわち送信）である場合、ＯＴＰセッションを示すデータが、（デバイス・インターフェイスまたはディスプレイ・スクリーンのいずれかを介して）「送信される」。そうでない場合、４３１において、ＯＴＰトークン３１０の「外部」の、セキュリティの低い環境へＯＴＰセッション・データを送信することを抑止する。

本出願の説明文および請求項における動詞「なる」、「含む」および「持つ」、そしてそれらの同根語の各々は、動詞の単数あるいは複数の目的語が、必ずしも動詞の単数あるいは複数の主語の部材、コンポーネント、要素またはパーツの完全なリストというわけではないことを示すために用いている。

本文で引用する参照のすべては、参照によってそれら全体を含むものである。参照の引用は、その参照が従来の技術であると認めるものではない。

本文では、一つまたはそれ以上の（すなわち、少なくとも一つの）ものに言及するために、文法上の目的語に品詞「ａ」および「ａｎ」を用いている。例えば、「一つの要素」は、一つの要素または複数の要素を意味する。

本文における用語「含む」は、表現「限定せずに含む」を意味し、それと置換可能である。

本文における用語「または」は、文脈がそうでないと明確に示すことがない限り、用語「および／あるいは」を意味し、それと置換可能である。本文における用語「例えば」は、表現「限定せずに例えば」を意味し、それと置換可能である。

本発明を、その実施例の詳細説明を用いて説明したが、実施例は、例証として提供したもので、発明の範囲を限定することを意図していない。説明した実施例は、種々の異なる特徴からなるが、それらのすべてが、本発明のすべての実施例に必要なものではない。本発明のいくつかの実施例は、単に、それら特徴のいくつか、またはそれら特徴の組み合わせを利用する。したがって、同業者は、説明した本発明の実施例の実施例の異形、説明した実施例の特徴の異なる組み合わせからなる本発明の実施例を想到するであろう。

（従来の技術）は、各々、セッションＯＴＰを要求するサーバ１７０、インターネット２０を介してサーバ１７０と通信するコンピュータあるいはクライアント・ワークステーション１６０、そしてクライアント・ワークステーション１６０と共に使用するＯＴＰデバイスあるいはトークン１１０を含む、模範的なシステムのブロック図である。 （従来の技術）は、各々、セッションＯＴＰを要求するサーバ１７０、インターネット２０を介してサーバ１７０と通信するコンピュータあるいはクライアント・ワークステーション１６０、そしてクライアント・ワークステーション１６０と共に使用するＯＴＰデバイスあるいはトークン１１０を含む、模範的なシステムのブロック図である。 ＯＴＰデバイス１１０により生成したＯＴＰで、クライアント・サーバ・セッションを開始するための、従来の技術によるルーチンのフローチャートである。 本発明の実施例による、模範的なシステム３００のブロック図であり、セッションＯＴＰを要求するサーバ１７０、インターネット２０を介してサーバ１７０と通信するコンピュータあるいはクライアント・ワークステーション３６０、そしてクライアント・ワークステーション１６０と共に使用するＯＴＰデバイスあるいはトークン３１０を含む。 本発明の実施例による、模範的なシステム３００のブロック図であり、セッションＯＴＰを要求するサーバ１７０、インターネット２０を介してサーバ１７０と通信するコンピュータあるいはクライアント・ワークステーション３６０、そしてクライアント・ワークステーション１６０と共に使用するＯＴＰデバイスあるいはトークン３１０を含む。 模範的なＯＴＰ認証デバイスあるいはトークン３１０のブロック図である。 模範的なサーバ正当性エンジン３４０のブロック図である。 模範的なクライアント・ワークステーションあるいはコンピュータ３６０のブロック図である。 本発明の実施例による、ＯＴＰデバイス１１０によって生成したＯＴＰで、クライアント・サーバ・セッションを開始するためのルーチンのフローチャートである。 ＯＴＰトークンからのセッションＯＴＰ送信を処理するためのルーチンのフローチャートである。

Claims (30)

1. ネットワークを介してサーバとクライアント・ワークステーションとが通信することで、ＯＴＰトークンがセッションＯＴＰを送信処理する方法であって、
   前記ＯＴＰトークンは、
   前記ＯＴＰトークン内の埋め込み型ブラウザを用いて、前記ＯＴＰトークンと前記サーバ間のセキュアなセッションを開始するステップと、
   前記セキュアなセッションを開始した後で、前記サーバを少なくとも部分的に識別するサーバ情報を前記サーバから受信するステップと、
   前記受信した情報に基づいて、前記サーバが正規サーバであるか否かを判定するステップと、を備え、
   前記判定するステップが、前記サーバが正規サーバであると判定する時に、前記ＯＴＰトークンが前記ＯＴＰトークン内部で生成された一度限りのパスワードであるＯＴＰを前記ＯＴＰトークンから送信するステップ、および前記ＯＴＰトークンが前記クライアント・ワークステーションと前記サーバ間のセッションを開始するステップを備え、
   前記判定するステップが、前記サーバが正規サーバではないと判定する時に、前記ＯＴＰトークンは、前記ＯＴＰトークン内部で生成されたＯＴＰの送信を抑止するステップを備える、方法。
2. 前記ＯＴＰトークン内部で生成されたＯＴＰのデータはセッションＯＴＰデータであり、デバイス・インタフェイスを介して前記ＯＴＰトークンから前記データを前記クライアント・ワークステーションへ送信される、請求項１の方法。
3. 前記ＯＴＰトークン内部で生成されたセッションＯＴＰデータを送信するステップは、前記ＯＴＰトークンのディスプレィ・スクリーンに前記セッションＯＴＰデータを表示するステップを含む、請求項１または２の方法。
4. 前記ＯＴＰトークン内部で生成されたセッションＯＴＰデータは、前記ＯＴＰデータとユーザ認証データの少なくとも一部とが組み合わせられたマルチ・ファクタ認証データである、請求項１〜３のいずれかの方法。
5. 前記ＯＴＰトークン内部で生成されたセッションＯＴＰデータは、ユーザ認証データとは組み合わせられていない、請求項１〜３のいずれかの方法。
6. 前記サーバが正規サーバではないとの判定する時に、
   前記ＯＴＰトークン内部でセッションＯＴＰを生成するステップ、および前記セッションＯＴＰが前記ＯＴＰトークン内に残留する状態を維持するステップを備える、請求項１〜５のいずれかの方法。
7. 前記セキュアなセッションを開始した後で、前記セキュアなセッションのクライアント側終端点を前記ＯＴＰトークンから前記クライアント・ワークステーションへ移動するステップと、を備え、
   前記クライアント・ワークステーションは、前記サーバを少なくとも部分的に識別するサーバ情報を受信するステップと、受信した前記サーバ情報に基づいて前記サーバが正規サーバであるか否かを判定するステップとの少なくとも一つのステップを実行する、請求項１〜６いずれかの方法。
8. 前記サーバを少なくとも部分的に識別する前記サーバ情報が前記ＯＴＰトークンで受信され、前記サーバ情報が前記サーバから前記ＯＴＰトークンによって受信された時点で、前記セキュアなセッションのクライアント側終端点が前記埋め込まれたブラウザ内に留まる、請求項１〜６のいずれかの方法。
9. 前記受信するステップが、前記ＯＴＰトークンによって、前記サーバと前記ＯＴＰトークンとの間の通信リンクを介して実行される、請求項１〜８のいずれかの方法。
10. 前記サーバが正規サーバであるか否かを判定するステップが、前記ＯＴＰトークン内で実行される、請求項１〜９のいずれかの方法。
11. 前記サーバが正規サーバであるか否かを判定するステップが、前記ＯＴＰトークン内に存在するデータベースへ問い合わせることを含む、請求項１〜１０いずれかの方法。
12. 前記問い合わせが、前記クライアント・ワークステーションから実行される、請求項１１の方法。
13. 前記サーバが正規サーバであるか否かを前記ＯＴＰトークンが判定し、前記ＯＴＰトークン内に存在するクライアント・コードが前記データベースに前記問合せを実行する、請求項１１の方法。
14. 前記データベースが不変データベースである、請求項１１の方法。
15. 前記データベースが、許容可能なＵＲＬの所定リスト、許容可能なＩＰアドレスの所定リスト、そして証明フィールドに対する許容可能な値の所定リストのうちの一つを含む、請求項１１の方法。
16. ネットワークを介してサーバとクライアント・ワークステーションとが通信することで、ＯＴＰトークンがセッションＯＴＰを送信処理する方法であって、
    前記ＯＴＰトークンが、前記サーバを少なくとも部分的に識別するサーバ情報を前記サーバから受信するステップと、
    前記受信した情報に基づいて、前記サーバが正規サーバであるか否かを判定するステップと、を備え、
    前記判定するステップが、前記サーバが正規サーバであると判定する時に、前記ＯＴＰトークンは、前記ＯＴＰトークン内部で生成されたセッションＯＴＰデータを前記ＯＴＰトークンから送信するステップ、および前記ＯＴＰトークンが前記クライアント・ワークステーションと前記サーバ間のセッションを開始するステップを備え
    前記判定するステップが、前記サーバが正規サーバではないと判定する時に、前記ＯＴＰトークンは、前記ＯＴＰトークン内部で生成されたセッションＯＴＰデータの送信を抑止するステップを備え、
    前記サーバが正規サーバであるか否かを判定するステップは、前記受信した情報のプロトコル・データである、前記受信したデータの証明書データ、ＩＰアドレス、またはＵＲＬデータの少なくとも一つに基づいて実行される、方法。
17. 前記サーバが正規サーバであるか否かを判定するステップが、前記サーバから受信した証明書データの、いくつかの属性に基づいて実行される、請求項１６の方法。
18. ネットワークを介してサーバと通信するクライアント・ワークステーションで用いるＯＴＰトークンであって、
    前記サーバを少なくとも部分的に識別する入力情報を入力するための手作業入力デバイスと、
    前記情報に基づいて前記サーバが正規サーバであるか否かを判定するためのサーバ正当性エンジンと、
    セッションＯＴＰを生成するように作動可能なＯＴＰジェネレータと、
    前記サーバが正規サーバであると判定された場合に前記ＯＴＰトークンからセッションＯＴＰデータを送信するか、あるいは前記サーバが正規サーバではないと判定された場合に前記セッションＯＴＰデータの送信を抑止するかを決定するように作動可能なＯＴＰ送信決定エンジンと、
    前記ＯＴＰトークンと前記サーバ間においてセキュアなセッションを開始するように作動可能である、前記ＯＴＰトークン内に埋め込まれたセキュアなブラウザと、
    を備える、ＯＴＰトークン。
19. 前記ＯＴＰ送信決定エンジの決定に基づいて、前記ＯＴＰトークンから、セッションＯＴＰを表示するデータを送信するためのＯＴＰ送信器を備える、請求項１８のＯＴＰトークン。
20. 前記サーバが正規サーバであると判定された場合にだけ、前記ＯＴＰ送信器が、デバイス・ポートを介して、前記セッションＯＴＰの前記データのデバイス間データ転送を実行するように作動可能である、請求項１９のＯＴＰトークン。
21. 前記ＯＴＰトークンがデータ・ディスプレイを備え、
    前記サーバが正規サーバであると判定された場合にだけ、前記ＯＴＰ送信器が、前記データ・ディスプレイへ、前記セッションＯＴＰの前記データを送信するように作動可能である、請求項１９のＯＴＰトークン。
22. 前記セキュアなセッション中に、前記埋め込まれたセキュアなブラウザが、前記サーバを少なくとも部分的に識別する情報を受信するように作動可能である、請求項１９のＯＴＰトークン。
23. 前記サーバ正当性エンジンが、
    所定データのデータベースを含み、
    前記サーバ正当性エンジンが、前記データベースのコンテンツに基づいて前記サーバが正規サーバであるか否かを判定するように作動可能である、請求項１９のＯＴＰトークン。
24. 前記データベースが不変データベースである、請求項２３のＯＴＰトークン。
25. 前記データベースが、許容可能なＵＲＬの所定リスト、許容可能なＩＰアドレスの所定リスト、そして証明フィールドに対する許容可能な値の所定リストのうちの一つを含む、請求項２３のＯＴＰトークン。
26. ネットワークを介してサーバと通信するクライアント・ワークステーションで用いるＯＴＰトークンであって、
    前記サーバを少なくとも部分的に識別する入力情報を入力するためのマニュアル入力デバイスと、
    前記情報に基づいて前記サーバが正規サーバであるか否かを判定するためのサーバ正当性エンジンと、
    セッションＯＴＰを生成するように作動可能なＯＴＰジェネレータと、
    前記サーバが正規サーバであると判定された場合に前記ＯＴＰトークンからセッションＯＴＰデータを送信するか、あるいは前記サーバが正規サーバではないと判定された場合には前記セッションＯＴＰデータの送信を抑止するかを決定するように作動可能なＯＴＰ送信決定エンジンと、
    を備え、
    前記サーバ正当性エンジンは、前記サーバから通信で送信された前記サーバ証明データ、ＩＰアドレス、またはＵＲＬデータの少なくとも一つの通信プロトコル・データに基づいて、前記サーバが正規サーバであるか否かを判定するように作動可能である、ＯＴＰトークン。
27. 前記サーバ正当性エンジンが、前記サーバから受信した証明のいくつかの属性にのみ基づいて、前記サーバが正規サーバであるか否かを判定するよう作動可能である、請求項２６のＯＴＰトークン。
28. ネットワークを介してサーバと通信するクライアント・ワークステーションで用いるＯＴＰトークンであって、
    前記サーバを少なくとも部分的に識別する入力情報を入力するためのマニュアル入力デバイスと、
    前記情報に基づいて前記サーバが正規サーバであるか否かを判定するためのサーバ正当性エンジンと、
    セッションＯＴＰを生成するように作動可能なＯＴＰジェネレータと、
    前記サーバが正規サーバであると判定された場合に前記ＯＴＰトークンからセッションＯＴＰデータを送信するか、あるいは前記サーバが正規サーバではないと判定された場合には前記セッションＯＴＰデータの送信を抑止するかを決定するように作動可能なＯＴＰ送信決定エンジンと、
    を備え、
    前記ＯＴＰジェネレータが、ユーザ認証データに基づいて、前記セッションＯＴＰを生成するように作動可能であり、それによって、前記セッションＯＴＰをマルチ・ファクタ認証データとして生成する、ＯＴＰトークン。
29. 前記ユーザ認証データを認証するためのユーザ識別モジュールを備える、請求項２８のＯＴＰトークン。
30. 前記ＯＴＰ送信決定エンジンが、前記ユーザ認証データの前記認証の結果に基づいて、前記セッションＯＴＰデータを送信するか否か、前記セッションＯＴＰデータの送信を抑止するか否かを決定するように作動可能である、請求項２８のＯＴＰトークン。

Images