ユーザ認証の方法およびデバイス
遠隔通信ネットワークを介してサーバ（４）にアクセスするのに通信端末（１）を使用するユーザを認証するために、個人識別コードが、ユーザから受け取られる。通信端末（１）とサーバ（４）との間で交換されたセキュア・セッション確立プロトコル・メッセージ（Ｓ１、Ｓ２、Ｓ３）から、データ・セットが生成される（Ｓ４）。データ・セットに基づいて、トランザクション認証番号が、個人識別コードを使用して生成される（Ｓ５２）。トランザクション認証番号が、通信端末（１）からサーバ（４）に送信される（Ｓ５４）。サーバ（４）で、受信されたトランザクション認証番号が、通信端末（１）と交換されたセキュア・セッション確立プロトコル・メッセージに基づいて検証される（Ｓ２０）。トランザクション認証番号は、リアルタイム中間者攻撃に対してオンライン・ユーザを保護する、セッションを意識したユーザ認証を可能にする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバにアクセスするユーザを認証する方法およびデバイスに関する。具体的に言うと、本発明は、遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証する方法、コンピュータ・プログラム製品、およびコンピュータ化されたサーバに関する。
【背景技術】
【０００２】
インターネット上でのログイン機構に対する攻撃の洗練は、すばやく発達しつつある。銀行などの機関は、速いペースで、ますます高くなるコストで、一部はチャレンジ−レスポンス機構さえ含む、ツー・ファクタ認証（ｔｗｏ−ｆａｃｔｏｒ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）デバイスを展開しつつある。中間者（ＭＩＴＭ）攻撃は、インターネット・バンキングなど、すべてのＳＳＬ／ＴＬＳベースのオンライン・アプリケーションに深刻な脅威を与える。これに対する一般的な回答は、オリジナルのＳｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ（ＳＳＬ）プロトコル（米国特許第５，６５７，３９０号）またはＴｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ）プロトコル標準規格（Ｄｉｅｒｋｓ，Ｔ．およびＣ．Ａｌｌｅｎ、「Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．０」、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ２２４６、１９９９年１月）によって要求されるものなどのクライアント証明書ベースの相互認証を使用することである。しかし、会社の影響の厳しく制御された領域を超えて、この手法は、設計者が予想したほどに広範囲に受け入れられてはいない。
【０００３】
米国特許第４，４０５，８２９号、米国特許第４，７２０，８６０号、米国特許第４，８８５，７７８号、および米国特許第４，８５６，０６２号は、一般にＳｅｃｕｒＩＤトークンと称する認証トークン・デバイスに関する。このトークン・デバイスは、強いユーザ認証を提供するが、リアルタイムで動作するＭＩＴＭ攻撃に対して保護はしない。
【０００４】
米国特許出願第２００４／００６４６８７号には、オンライン・サードパーティすなわち「アイデンティティ・プロバイダ」によってＭＩＴＭ攻撃を防ぐ方法が記載されている。説明された方法は、ＳＳＬ／ＴＬＳプロトコルに対する変更を必要とせず、完全な公開鍵インフラストラクチャ（ＰＫＩ）の展開をも必要としない。しかし、この方法は、クライアントを変更し、アイデンティティ・プロバイダのハードコーディングされた証明書をクライアントに含めることを必要とする。
【０００５】
米国特許出願第２００２／１０７７９８ Ａ１号に、セキュリティ・デバイスに対してスマート・カードを認証する方法が記載されている。説明された方法は、チップ・カードがプロトコルの開始の前にセキュリティ・デバイスの公開鍵を所有し、（クライアント）アプリケーションがこの公開鍵だけを使用することに限定されるという仮定に基づく。しかし、この仮定は、一般的に行うことができない。
【０００６】
【特許文献１】米国特許第５，６５７，３９０号
【非特許文献１】Ｄｉｅｒｋｓ，Ｔ．およびＣ．Ａｌｌｅｎ、「Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．０」、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ２２４６、１９９９年１月
【特許文献２】米国特許第４，４０５，８２９号
【特許文献３】米国特許第４，７２０，８６０号
【特許文献４】米国特許第４，８８５，７７８号
【特許文献５】米国特許第４，８５６，０６２号
【特許文献６】米国特許出願第２００４／００６４６８７号
【特許文献７】米国特許出願第２００２／１０７７９８ Ａ１号
【非特許文献２】「ＰＫＣＳ ＃１１：Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｔｏｋｅｎ Ｉｎｔｅｒｆａｃｅ Ｓｔａｎｄａｒｄ」、ＲＳＡ Ｓｅｃｕｒｉｔｙ Ｉｎｃ．
【非特許文献３】ｈｔｔｐ：／／ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｌｉｂｒａｒｙ／ｄｅｆａｕｌｔ．ａｓｐ？ｕｒｌ＝／ｌｉｂｒａｒｙ／ｅｎ−ｕｓ／ｓｅｃｃｒｙｐｔｏ／ｓｅｃｕｒｉｔｙ／ｃｒｙｐｔｏｇｒａｐｈｙ＿＿ｃｒｙｐｔｏａｐｉ＿＿ａｎｄ＿ｃａｐｉｃｏｍ．ａｓｐ
【非特許文献４】Ｋｒａｗｃｚｙｋ，Ｈ．，他、「ＨＭＡＣ：Ｋｅｙｅｄ−Ｈａｓｈｉｎｇ ｆｏｒ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ２１０４、１９９７年２月
【非特許文献５】Ｍｏｌｖａ，Ｒ．およびＧ．Ｔｓｕｄｉｋ、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍｅｔｈｏｄ ｗｉｔｈ Ｉｍｐｅｒｓｏｎａｌ Ｔｏｋｅｎ Ｃａｒｄｓ」、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＩＥＥＥ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｒｅｓｅａｒｃｈ ｉｎ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ、ＩＥＥＥ Ｐｒｅｓｓ、１９９３年５月
【非特許文献６】Ｌａｍｐｏｒｔ，Ｌ．、「Ｐａｓｓｗｏｒｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｗｉｔｈ Ｉｎｓｅｃｕｒｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ」、Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｏｆ ｔｈｅ ＡＣＭ、Ｖｏｌ．２４、１９８１年、７７０〜７７２頁
【非特許文献７】ｈｔｔｐ：／／ｗｗｗ．ｒｓａｓｅｃｕｒｉｔｙ．ｃｏｍ／
【非特許文献８】ｈｔｔｐ：／／ｗｗｗ．ｒｆｃ．ｎｅｔ／ｒｆｃ２２４６．ｈｔｍｌ＃ｓ７．４．４
【非特許文献９】ｈｔｔｐ：／／ｗｗｗ．ｅｍｖｃｏ．ｃｏｍ
【非特許文献１０】ｈｔｔｐ：／／ａｘｓｉｏｎｉｃｓ．ｃｈ
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明の目的は、遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証する方法およびデバイスを提供することである。具体的に言うと、本発明の目的は、リアルタイムで動作するＭＩＴＭ攻撃に対して保護するユーザ認証の方法およびデバイスを提供することである。本発明のもう１つの目的は、セキュア・セッション確立プロトコルを用いて確立されたセキュア・セッションを使用して、遠隔通信ネットワークを介してサーバにアクセスするユーザを認証する方法およびデバイスを提供することである。
【課題を解決するための手段】
【０００８】
本発明によれば、これらの目的は、特に、独立請求項の特徴を介して達成される。それに加えて、さらなる有利な実施形態が、従属請求項およびこの説明から得られる。
【０００９】
本発明によれば、上で述べた目的は、特に、遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証するために、個人識別コードが、ユーザから受け取られ、データ・セットが、通信端末とサーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージから生成され、トランザクション認証番号が、個人識別コードを使用してデータ・セットに基づいて生成され、トランザクション認証番号が、通信端末からサーバに送信され、サーバ内で、トランザクション認証番号が（したがって、ユーザが）、通信端末と交換されたセキュア・セッション確立プロトコル・メッセージに基づいて検証されるという点で達成される。たとえば、データ・セットは、交換されるセキュア・セッション確立プロトコル・メッセージからハッシュ値として通信端末内で生成される。本明細書で説明するトランザクション認証番号が、本発明の文脈でセッション認証番号またはセッション認証コードとして使用され、いくつかの実施形態で、トランザクション認証番号が、ディジタル・データ・セットすなわちディジタル・トランザクション認証番号によって表されることを強調しなければならない。個人識別コードおよび通信端末とサーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージに基づくトランザクション認証番号の生成は、リアルタイム中間者攻撃に対してオンライン・ユーザを効率的に保護する、セッションを意識したユーザ認証を可能にする。
【００１０】
一実施形態では、通信端末に関連する認証モジュール内および／または通信端末内で、認証ベース番号が、データ・セットから生成され、トランザクション認証番号が、個人識別コードを使用して認証ベース番号から生成される。たとえば、認証ベース番号は、通信端末に関連する認証モジュール内で生成される。さらに、サーバ内で、認証ベース番号が、交換されたセキュア・セッション確立プロトコル・メッセージから生成され、トランザクション認証番号が、サーバ内で生成された認証ベース番号および個人識別コードを使用してサーバ内で検証される。
【００１１】
好ましい実施形態では、認証ベース番号および個人識別コードが、通信端末に接続されないチャレンジ／レスポンス（Ｃ／Ｒ）トークン・デバイスに（ユーザによって）入力される。トランザクション認証番号が、認証ベース番号および個人識別コードに基づいてトークン・レスポンス値としてチャレンジ／レスポンス・トークン・デバイス内で生成される。トランザクション認証番号すなわちトークン・レスポンス値は、トランザクション認証番号をサーバに送信する前に、通信端末に（ユーザによって）入力される。
一実施形態で、認証ベース番号は、乱数を生成することと、選択された桁をデータ・セットから選択することであって、桁が乱数の桁によって決定される、選択することと、選択された桁および乱数の桁から認証ベース番号を合成することとによって、データ・セットから生成される。
【００１２】
一実施形態で、ディジタル署名は、認証モジュールに関連する鍵対の秘密鍵を使用してデータ・セットから生成され、認証モジュール内で、認証ベース番号は、認証モジュールに関連する秘密トークン鍵を使用してデータ・セットから生成され、トランザクション認証番号は、認証ベース番号から生成され、個人識別コードは、ディジタル署名を生成する際またはトランザクション認証番号を生成する際に使用され、ディジタル署名は、通信端末からサーバに送信され、サーバ内で、ディジタル署名は、鍵対の公開鍵を使用して検証され、トランザクション認証番号は、通信端末からサーバに送信され、サーバ内で、認証ベース番号は、データ・セットを暗号化する秘密トークン鍵を使用して、通信端末から受信されたデータ・セットから生成され、サーバ内で、トランザクション認証番号は、サーバ内で生成された認証ベース番号を使用して検証される。
【００１３】
一実施形態で、トランザクション認証番号は、認証ベース番号および個人識別コードから生成される。トランザクション認証番号およびユーザ識別子は、通信端末からサーバに送信される。トランザクション認証番号は、サーバ内で生成された認証ベース番号およびユーザ識別子に割り当てられた個人識別コードを使用してサーバ内で検証される。
【００１４】
一実施形態で、認証モジュールは、通信端末に取り外し可能に接続可能な認証トークン・デバイスとして実施される。データ・セットは、認証モジュールを通信端末に接続するデバイス・インターフェースを介して通信端末から認証モジュールに転送される。適用可能な場合に、鍵対および秘密トークン鍵は、認証モジュールに格納され、ディジタル署名は、認証モジュールから通信端末へデバイス・インターフェースを介して転送される。
さらなる実施形態で、トークン識別子は、通信端末からサーバへトランザクション認証番号と一緒に送信され、秘密トークン鍵は、トークン識別子に基づいてサーバ内で判定される。マスタ鍵は、サーバに格納され、秘密トークン鍵は、サーバ内で、トークン識別子を暗号化するためにマスタ鍵を使用してトークン識別子から生成される。
【００１５】
一実施形態で、認証ベース番号は、認証モジュールから通信端末に転送される。個人識別コードは、通信端末内でユーザから受け取られ、トランザクション認証番号は、通信端末内で、認証ベース番号および個人識別コードから生成される。
【００１６】
もう１つの実施形態で、個人識別コードは、認証モジュール内でユーザから受け取られる。トランザクション認証番号は、認証モジュール内で、認証ベース番号および個人識別コードから生成され、トランザクション認証番号は、認証モジュールから通信端末に転送される。
【００１７】
もう１つの実施形態で、個人識別コードは、バイオメトリック識別子と一緒にユーザから受け取られる。トランザクション認証番号は、サーバ内で生成された認証ベース番号およびサーバに格納されたバイオメトリック識別子ならびにユーザ識別子に割り当てられた個人識別コードを使用してサーバ内で検証される。
【００１８】
もう１つの実施形態で、認証ベース番号は、認証モジュールによって表示される。トランザクション認証番号は、個人識別コードおよび認証モジュールによって表示された認証ベース番号によってユーザによって生成され、ユーザによって通信端末に入力される。
【００１９】
もう１つの実施形態で、サーバ内でのトランザクション認証番号の成功の検証の後に、サーバ認証コードが、サーバ内で、データ・セットに公開関数を適用し、暗号化に秘密トークン鍵を使用して、データ・セットから生成される。サーバ認証コードは、サーバから通信端末に送信される。サーバ認証コードが、認証モジュール内で、データ・セットに公開関数を適用し、暗号化に秘密トークン鍵を使用して、データ・セットから生成される。認証モジュールは、認証モジュール内で生成されたサーバ認証コードに基づいて、サーバからのサーバ認証コードを検証する。一実施形態で、サーバ認証コードは、サーバから受信され、認証モジュール内で生成されたサーバ認証コードは、ユーザによる視覚的検証のために認証モジュールによって表示される。
【００２０】
追加の実施形態で、ユーザは、認証モジュールの複数の可能な機関スコープのうちの１つを選択する。ユーザによって選択された機関スコープは、認証モジュールに、認証ベース番号を生成するための複数の秘密トークン鍵の組のうちの１つの機関固有秘密トークン鍵を使用させる。サーバは、特定の機関に関連し、認証ベース番号を生成するのに機関固有秘密トークン鍵を使用する。サーバは、トランザクション認証番号を検証するのに機関固有個人識別コードを使用する。
【００２１】
提案されるユーザ認証方法は、何らかの形で同期化されなければならないクロックを必要としない。そうではなく、この方法は、通信端末とサーバとの間で交換されるセキュア・セッション確立プロトコル・メッセージ（たとえば、ＳＳＬ／ＴＬＳ）から導出されるナンス（たとえば、そのハッシュ値）を使用して、トランザクション認証番号の通用を保証する。
【００２２】
さらに、提案される方法のセキュリティは、ユーザ識別子が、およびユーザが特定の転送可能トークンを使用する時間期間の間にトークン識別子も、たとえばブラウザのフォーム・プリ・フィル（ｆｏｒｍ−ｐｒｅ−ｆｉｌｌ）機能によって、通信端末に格納される場合に、特に傷つけられない。特に、通信端末が、共有されるワークステーションである場合に、これは、他の当事者およびおそらくは敵対者がこれら２つの値を知ることにつながる可能性があるが、提案される方法は、これに耐える。
【００２３】
クライアント側ＳＳＬ／ＴＬＳ実施態様のほとんど遍在する基礎を変更する必要はない。ほとんどの実施形態について、ＳＳＬ／ＴＬＳスタックを使用するウェブ・ブラウザなどのクライアント・アプリケーションも、変更する必要がない。
【００２４】
認証されたセキュア・セッション・ブートストラッピングを動作させることは、セキュリティの知識がないエンド・ユーザにとって、現在広く展開されているツー・ファクタ解決策より複雑ではない。
【００２５】
エンド・ユーザ登録または他の高価なプロセスは、このＭＩＴＭに耐える手法を実施するのに必要ではない。ツー・ファクタ解決策を実行する機関は、エンド・ユーザが使用しているデバイスを交換するだけでよく（しかし、エンド・ユーザが使用するＰＩＮまたはパスワードは変更されないままである）、あるいは、その中で実施されるアルゴリズムおよびプロトコルを変更し（既知のファームウェア更新に類似する）、それ自体のサーバ・インフラストラクチャを提案される方法と共に働くように適合させるだけでよい。
【００２６】
本発明のもう１つの目的によれば、遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザが個人識別コードを変更するために、古い個人識別コードおよび新しい個人識別コードが、ユーザから受け取られ、データ・セットが、通信端末とサーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージから生成され、通信端末に関連する認証モジュール内で、認証ベース番号が、認証モジュールに関連する秘密トークン鍵を使用して、データ・セットから生成され、識別変更コードが、認証ベース番号、古い個人識別コード、および新しい個人識別コードから生成され、識別変更コードが、通信端末からサーバに送信され、サーバ内で、認証ベース番号が、秘密トークン鍵を使用して、交換されたセキュア・セッション確立プロトコル・メッセージから生成され、サーバ内で、新しい個人識別コードが、古い個人識別コードおよびサーバ内で生成された認証ベース番号を使用して、識別変更コードから導出される。
【００２７】
遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザの認証のもう１つの実施形態では、トランザクション認証番号が、通信端末に関連する認証モジュール内で、個人識別コードからおよび通信端末とサーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージから、鍵としてサーバと共有される秘密を使用して、鍵付き暗号ダイジェスト値として生成される。鍵付き暗号ダイジェスト値は、トランザクション認証番号として通信端末からサーバに送信される。サーバ内で、鍵付き暗号ダイジェスト値が、サーバに格納された個人識別コードを使用して生成される。その後、サーバ内で、トランザクション認証番号が、したがってユーザの真正性が、通信端末から受信された鍵付き暗号ダイジェスト値とサーバ内で生成された鍵付き暗号ダイジェスト値との比較に基づいて検証される。たとえば、認証モジュールに関連する個人識別コードまたは秘密トークン鍵が、鍵として使用される。鍵付き暗号ダイジェスト値は、鍵付き暗号ダイジェスト関数すなわち、暗号ハッシュ関数などの擬似乱数関数を使用して生成される。代替実施形態では、ルックアップ・インデックスが、データ・セットから生成され、コード・テーブル（たとえば、鍵リスト）内で、ルックアップ・インデックスを使用して、選択されたコードが判定される。選択されたコードは、（ハッシュ）鍵として使用され、サーバは、サーバに格納されたコード・テーブルからの選択されたコードを（ハッシュ）鍵として使用して、鍵付き暗号ダイジェスト値を生成する。副実施形態では、サーバは、通信端末によって使用される以前に選択されたコードを追跡し、サーバは、選択されたコードが以前に通信端末によって使用されたとサーバが判定する場合に、通信端末とのセッション確立を再開始する。
【００２８】
遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザの認証のもう１つの実施形態では、トランザクション認証番号は、通信端末に関連する認証モジュール内で、公開鍵を使用してデータ・セット、個人識別コード、およびナンスを暗号化することによって、暗号文として生成される。暗号文は、トランザクション認証番号として通信端末からサーバに送信される。サーバ内で、秘密鍵を使用して暗号文を暗号化解除することによって、データ・セットおよび個人識別コードが判定される。その後、サーバ内で、暗号化解除されたトランザクション認証番号が、したがってユーザの真正性が、セキュア・セッション確立プロトコル・メッセージからサーバ内で生成されたデータ・セットとの受信されたデータ・セットの比較およびサーバに格納された個人識別コードとの個人識別コードの比較に基づいて検証される。
【００２９】
一実施形態で、ルックアップ・インデックスが、データ・セットから生成され、コード・テーブル（たとえば、鍵リスト）内で、ルックアップ・インデックスを使用して、選択されたコードが判定される。選択されたコードは、さらに、暗号文を生成するのに使用される。サーバは、秘密鍵を使用して、選択されたコードを暗号文から判定する。トランザクション認証番号は、したがってユーザの真正性は、選択されたコードをサーバに格納されたコード・テーブルからサーバによって判定された選択されたコードと比較することによって検証される。副実施形態で、サーバは、通信端末によって使用される選択されたコードを追跡し、サーバは、選択されたコードが通信端末によって以前に使用されたとサーバが判定する場合に、通信端末とのセッション確立を再開始する。
【００３０】
本発明の追加の目的によれば、遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証するために、データ・セットが、通信端末とサーバとの間で交換されるセキュア・セッション確立プロトコル・メッセージから生成され、通信端末内で、認証暗号文が、データ・セット、個人識別コード、および１つまたは２つのナンスから生成される。事前定義の公開鍵が、暗号化に使用される。この鍵は、サーバまたは複数機関の場合に認証サーバのいずれかに属する。結果の暗号文は、通信端末からサーバへ通常のプロトコル・メッセージの内部で不透明に送信され、サーバ内で、データ・セットは、交換されたセキュア・セッション確立プロトコル・メッセージから生成され、サーバ内で、暗号文は、対応する秘密鍵を使用して暗号化解除される。サーバ・データベースから取り出され、暗号文から暗号化解除された個人識別コードが、比較され、暗号化解除されたデータ・セットが、サーバが計算したデータ・セットと比較される。ユーザが、サーバからユーザへの認証を望む場合に、第２のナンスも、暗号文から暗号化解除され、ユーザに送り返される。この手法は、個人識別コードを変更するのにも使用することができる。
【００３１】
本発明の追加の目的によれば、遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証するために、データ・セットが、通信端末とサーバとの間で交換されるセキュア・セッション確立プロトコル・メッセージから生成され、通信端末内で、インデックスが、帯域外で配信されるコード・テーブル（たとえば、鍵リスト）から短い鍵をルックアップするために、サーバから受信されるか、作成される。短い鍵および個人識別コードが、通信端末に入力され、暗号文であれ鍵付き暗号ダイジェスト値であれ、認証符号が、データ・セット、個人識別コード、短い鍵、および２つまでのナンスに基づいて生成される。認証符号は、通信端末からサーバに送信され、サーバ内で、データ・セットが、交換されたセキュア・セッション確立プロトコル・メッセージから生成され、サーバ内で、認証符号が、サーバ内で生成されたデータ・セット、個人識別コード、およびサーバ・データベース内の短い鍵を使用して、暗号化解除によってまたはたとえば暗号ハッシュ化によるなど、鍵付き暗号ダイジェスト関数を使用することによって、検証される。同様に、その短い鍵を、既に説明した他の実施形態と共に使用することもできる。
本発明を、図面を参照して例としてより詳細に説明する。
【発明を実施するための最良の形態】
【００３２】
図１では、符号１が、遠隔通信ネットワーク３を介するコンピュータ化されたサーバ４とのデータ交換のために構成された通信端末を指す。通信端末１は、固定されたパーソナル・コンピュータ（ＰＣ）、可動のラップトップ・コンピュータ、可動の無線電話機、および／または可動の携帯情報端末（ＰＤＡ）を含むが、これらに限定はされない。通信端末１のそれぞれは、ディスプレイ１１と、キーボードおよびたとえばコンピュータ・マウス、トラック・ボール、または類似物などのポインティング・デバイスなどのデータ入力手段１２とを有する。通信端末１は、遠隔通信ネットワーク３を介して、ＳＳＬ／ＴＬＳなどのセキュア・セッション確立プロトコルを用いて確立されたセキュア・セッションを介してサーバ４上でホスティングされるオンライン・アプリケーションにアクセスするクライアント・アプリケーション、好ましくはブラウザ（たとえば、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ ＥｘｐｌｏｒｅｒまたはＭｏｚｉｌｌａ Ｆｉｒｅｆｏｘ）を含む。さらに、通信端末１は、後で図２および３を参照してより詳細に説明する認証モジュール２を含む。
【００３３】
遠隔通信ネットワーク３は、固定ネットワークおよび無線ネットワークを含む。たとえば、遠隔通信ネットワーク３は、ローカル・エリア・ネットワーク（ＬＡＮ）、サービス統合ディジタル網（ＩＳＤＮ）、インターネット、ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ（ＧＳＭ）、ｕｎｉｖｅｒｓａｌ ｍｏｂｉｌｅ ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｙｓｔｅｍ（ＵＭＴＳ）、または別の地上もしくは衛星ベースのモバイル無線電話システム、ならびに／あるいは無線ローカル・エリア・ネットワーク（ＷＬＡＮ）を含む。
【００３４】
コンピュータ化されたサーバ４は、１つまたは複数のコンピュータを含み、各コンピュータは、１つまたは複数のプロセッサ、プログラム・メモリ、データ・メモリ、ならびにオペレーティング・システムおよびＳＳＬ／ＴＬＳなどのセキュア・セッション確立プロトコルを用いて確立されたセキュア・セッションを介して遠隔通信端末１からアクセス可能なオンライン・アプリケーションを有する。たとえば、サーバ４は、Ａｐａｃｈｅ ｈｔｔｐｄサーバまたはＪａｋａｒｔａ Ｔｏｍｃａｔサーバである。さらに、サーバ４は、ユーザ認証モジュール４０およびデータベース４１を含む。好ましくは、ユーザ認証モジュール４０およびデータベース４１は、プログラムされたソフトウェア・モジュールとして実施される。データベース４１は、たとえば、マスタ鍵（ＭＫ）４２、ユーザ・データ４００の複数の組を含むことができ、ユーザ・データ４００のそれぞれは、ユーザ識別子（ＩＤ＿Ｕ）４３、個人識別コード（ＰＩＮ＿Ｕ）４４、およびおそらくは対称秘密トークン鍵（Ｋ＿Ｔ）４５を含む。個人識別コード（ＰＩＮ＿Ｕ）４４は、ユーザとサーバ４との間で共有される秘密であり、バイオメトリック・データ（バイオメトリック識別子）を含むことができる。さらに、データベース４１は、公開鍵（ｋ）４６を含むことができる。公開鍵（ｋ）４６を含む証明書は、ユーザ・データ・セット４００のユーザ固有部分とすることもできる、すなわち、その通し番号（ＳＮ＿Ｔ）を、特定のユーザが特定のトークンを使用する時間の間にＩＤ＿Ｕを用いて割り当てることができる。ユーザは、サーバが最後のＳＮ＿Ｔ−ＩＤ＿Ｕ関連付けを記憶しなければならないか否かを選択できなければならない。それを行うことによって、ユーザがトークンをさまざまな通信端末に挿入する場合であっても便宜が提供される。その一方で、この場合にトークンを紛失することは、ＩＤ＿Ｕをそのトークンの次のユーザに開示する可能性があり、これは認証を脅かしはしないが、サーバに関するユーザのプライバシに影響する。
【００３５】
図２に示されているように、各認証モジュール２は、複数の機能モジュールすなわち、証明モジュール２５、認証番号ジェネレータ２６、ディスプレイ・モジュール２７、ならびにおそらくはサーバ認証モジュール２８および／または選択モジュール２９を含む。さらに、認証モジュール２は、好ましくは完全性保護される（ｉｎｔｅｇｒｉｔｙ ｐｒｏｔｅｃｔｅｄ）秘密鍵（ｋ＾｛−１｝）および公開鍵（ｋ）を含む、非対称鍵対（ｋ，ｋ＾｛−１｝）２０１を有するメモリ・モジュールを含むことができる。識別のために、認証モジュール２を、公に知られたトークン識別子ＳＮ＿Ｔに関連付けることができる。好ましくは、認証モジュール２は、非人格的であり、ＰＫＳＣ＃１１またはＭＳ−ＣＡＰＩ（Ｍｉｃｒｏｓｏｆｔ Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）または別の標準デバイス・インターフェースに準拠する。一実施形態で、認証モジュール２は、トークン識別子２０３を有するメモリ・モジュールを含む。トークン識別子は、たとえばブラウザのフォーム・プリ・フィル機能によって、通信端末１に格納することもできる。さらに、認証モジュール２は、秘密トークン鍵（Ｋ＿Ｔ）２０２を有するセキュア・メモリ・モジュールまたはより好ましくない事例でマスタ鍵（ＭＫ）２０４を有するメモリ・モジュールのいずれかを含む。鍵対ｋおよびｋ＾｛−１｝は、すべての認証モジュール２について同一とすることができる（トークンを非人格的とすることができる理由）が、秘密トークン鍵Ｋ＿Ｔは、一意であり、１つの認証モジュール２に固有である。秘密トークン鍵Ｋ＿Ｔは、次式に従って、マスタ鍵ＭＫを使用してトークン識別子ＳＮ＿Ｔから生成することができる。
Ｋ＿Ｔ＝Ｅ＿｛ＭＫ｝（ＳＮ＿Ｔ）
【００３６】
その結果、中央ですべての秘密トークン鍵を格納する必要はない。そうではなく、秘密トークン鍵は、マスタ鍵を知っている誰もがトークン識別子から動的に生成することができる。マスタ鍵は、通常、サーバ４のみによって所有され、保持される。マスタ鍵またはむしろ秘密トークン鍵は、エクスポート不能な形でタンパプルーフ鍵ストア内に保持される。トークン秘密鍵ｋ＾｛−１｝も、同一のセキュア・ストレージによって保持されるが、公に開示されるようになる後者が、それでも、提案される方法に従って発行される認証モジュール２の母集団およびその機能を危険にさらさないようにすることができることが推奨される。
【００３７】
好ましくは、機能モジュールは、プログラムされたソフトウェア・モジュールとして実施される。このソフトウェア・モジュールのコンピュータ・プログラム・コードは、コンピュータ・プログラム製品の一部であり、好ましくは、通信端末１に挿入できるデータ・キャリア上、通信端末１内に一体化されたメモリ内、または通信端末１に接続された、図３に示された認証トークン・デバイス２０に一体化されたメモリ内のいずれかの、コンピュータ可読媒体に格納される。
【００３８】
一実施形態で、認証モジュール２は、ＰＫＳＣ＃１１に準拠する、おそらくは非人格的な認証トークン・デバイス２０として実施される。したがって、認証モジュール２は、Ｃｒｙｐｔｏｋｉ（「ＰＫＣＳ ＃１１：Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｔｏｋｅｎ Ｉｎｔｅｒｆａｃｅ Ｓｔａｎｄａｒｄ」、ＲＳＡ Ｓｅｃｕｒｉｔｙ Ｉｎｃ．）またはＭｉｃｒｏｓｏｆｔ ＣｒｙｐｔｏＡＰＩ（ｈｔｔｐ：／／ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｌｉｂｒａｒｙ／ｄｅｆａｕｌｔ．ａｓｐ？ｕｒｌ＝／ｌｉｂｒａｒｙ／ｅｎ−ｕｓ／ｓｅｃｃｒｙｐｔｏ／ｓｅｃｕｒｉｔｙ／ｃｒｙｐｔｏｇｒａｐｈｙ＿＿ｃｒｙｐｔｏａｐｉ＿＿ａｎｄ＿ｃａｐｉｃｏｍ．ａｓｐ）などの標準インターフェースを介して、セキュア・セッション確立プロトコル、たとえばＳＳＬ／ＴＬＳハンドシェークに参加するセキュア・ハードウェア・トークンである。図３に示されているように、認証モジュール２の文脈で上で説明した機能モジュールおよびメモリ・モジュールに加えて、認証トークン・デバイス２０は、デバイス・インターフェース２１、データ入力キー２３またはセンサ２４の形のデータ入力手段、およびおそらくはディスプレイ２２を含む。任意選択で、センサ２４は、バイオメトリック・データ（バイオメトリック識別子）の入力用に構成され、たとえば指紋リーダーを含む。デバイス・インターフェース２１は、認証トークン・デバイス２０を通信端末１に取り外し可能に接続するために構成される。デバイス・インターフェース２１は、たとえばＵＳＢインターフェース（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）を含む接点ベースまたはたとえばＢｌｕｅｔｏｏｔｈもしくはＩｒＤＡインターフェースを含む無接点である。認証モジュール２を、オフライン・デバイス（Ｃ／Ｒまたは使い捨てパスワード（ＯＴＰ））と、データ・セットまたは認証ベース番号からビットをランダムに選択するなどの機能によってクライアント・アプリケーション・ソフトウェアを補完する通信端末１内のソフトウェア・モジュールとの間で分割することもできる。
【００３９】
続く段落では、図４、５、６、７、８、９、および１０を参照して、提案されるユーザ認証方法を実行する可能なシーケンスならびにユーザ認証モジュール４０および機能モジュールの機能性を説明する。基本的な前提は、ユーザ・インフラストラクチャが、必ずしも信頼されるコンピュータ・ベースを実行していないことであるが、それでも、特にＳＳＬ／ＴＬＳ実施態様が、たとえばトロイの木馬実行可能ファイルによって打倒されず、したがって正しく動作していると仮定しなければならない。しかし、エンド・ユーザは、情報テクノロジにおいて特に技量を有するとは期待されず、たとえば、ＳＳＬ／ＴＬＳ保護されたセッション内でサーバ証明書の妥当性を完全にチェックできることは、期待されない。同様に、「ＵＢＳ．ＣＯＭ」と「Ｕ８Ｓ．ＣＯＭ」とを信頼できる形で区別できることは、期待されない。
【００４０】
サーバ４によってホスティングされるオンライン・アプリケーションにアクセスするために、ユーザは、そのユーザの通信端末１上のクライアント・アプリケーションに、それ相応に指示する。セキュア・セッション確立プロトコル、たとえばＳＳＬ／ＴＬＳハンドシェーク・プロトコルの一部として、サーバ４は、公開鍵証明書を使用してそれ自体を認証し、ユーザが、所期のサイトに実際に属するものとしてこの証明書を正しく検証はしないと仮定するが、これにはこれ以上対処しない。
【００４１】
図４に示されているように、ステップＳ１で、通信端末１は、セキュア・セッション確立プロトコルに従って、たとえばＳＳＬ／ＴＬＳに従ってサーバ４に「ＣｌｉｅｎｔＨｅｌｌｏ」メッセージを送信することによって、サーバ４とのセキュア・セッション確立を開始する。
【００４２】
ステップＳ２で、セキュア・セッション確立プロトコルに従って、サーバ４は、たとえばＳＳＬ／ＴＬＳに従って通信端末１に「ＳｅｒｖｅｒＨｅｌｌｏ」メッセージを送信することによって、ステップＳ１の開始メッセージに応答する。
【００４３】
ステップＳ３で、セキュア・セッション確立プロトコルの一部として、サーバ４は、通信端末１に証明書要求または「Ｆｉｎｉｓｈｅｄ」メッセージ、たとえばＳＳＬ／ＴＬＳに従う「ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔ」または「Ｆｉｎｉｓｈｅｄ」メッセージを送信する。
【００４４】
ステップＳ４で、セキュア・セッション確立プロトコルに従って、通信端末１のデータ・セット生成モジュールが、サーバ４と交換された、以前のセキュア・セッション確立プロトコル・メッセージに基づいてデータ・セットを作成する。たとえば、データ・セット生成モジュールは、ＳＳＬ／ＴＬＳに従ってハッシュ関数を適用することによって、以前のセキュア・セッション確立プロトコル・メッセージからデータ・セットを作成する（本明細書に明示的にリストされるものより多数の、交換されるセキュア・セッション確立プロトコル・メッセージが存在する可能性がある）。
【００４５】
ステップＳ５で、ステップＳ４で生成されたデータ・セット（たとえばハッシュ、以下では「ハッシュ」と呼ぶ）を、それぞれ認証モジュール２または認証トークン・デバイス２０に渡す。通信端末１とそれぞれ認証モジュール２または認証トークン・デバイス２０との間の情報の受渡しは、たとえば、通信端末１および／または認証トークン・デバイス２０内の共有メモリ・エリアを使用して、デバイス・インターフェース２１を介して達成することができる。
【００４６】
ステップＳ６で、証明モジュール２５が、鍵対２０１を有するメモリ・モジュールからの秘密鍵ｋ＾｛−１｝を使用して、ステップＳ５で受け取られたデータ・セットに暗号的に署名することによって、電子署名を生成する。変形形態では、公開署名妥当性検査鍵（ｋ）４６を含む署名に結び付けられた署名する証明書が、使用される特定のトークンの通し番号ＳＮ＿Ｔを含む。
【００４７】
ステップＳ７で、ステップＳ６で生成された電子署名を、通信端末１に渡す。
ステップＳ８で、通信端末１が、ステップＳ３で受け取られた証明要求に対する応答、たとえば、ステップＳ４で生成されたデータ・セットおよびステップＳ６で生成された電子署名を含む、ＳＳＬ／ＴＬＳに従う「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージを用意する。
【００４８】
ステップＳ９で、ステップＳ８で用意したセキュア・セッション確立プロトコル・メッセージが、通信端末１によってサーバ４に送信される。
【００４９】
ステップＳ１０で、公開鍵（ｋ）４６を使用して、サーバ４が、ステップＳ９で受け取ったデータ・セットを基礎として、ステップＳ９で受け取った電子署名を検証する。ｋ＾｛−１｝が通常はすべてのトークンについて同一なので、認証モジュール２が非人格的であるという事実に起因して、「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージは、実際にはクライアント・アプリケーションを認証しない。そうではなく、「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージは、トークンが、サーバへのセキュア・セッションを確立するのにクライアント・アプリケーションによって使用され、後の使用のためにデータ・セットを取り込むことだけを確実にする。ステップＳ４で生成されたデータ・セットが、「Ｆｉｎｉｓｈｅｄ」メッセージに基づく場合に、ステップＳ５〜Ｓ９は、必要ではなく、ステップＳ１０で、サーバ４は、後の使用のためにデータ・セット（ハッシュ）を取り込むのみである。この手法が使用されるのは、「Ｆｉｎｉｓｈｅｄ」メッセージの内容を点検できるクライアント拡張もしくはクライアント・プラグインまたは外部「スニッファ」があるか、「Ｆｉｎｉｓｈｅｄ」メッセージが既に暗号化されている場合である。好ましくは、そのような拡張は、小さく、プラットフォーム独立であり、したがって、クライアント・アプリケーションの内部にあるか、製造される時にクライアント・アプリケーションに一体化される。
【００５０】
ステップＳ１１で、認証番号ジェネレータ２６が、ステップＳ５で受け取ったデータ・セット（ハッシュ）から認証ベース番号Ｎ＿Ｔを生成する。認証ベース番号Ｎ＿Ｔは、認証モジュール２に関連する秘密トークン鍵Ｋ＿Ｔを使用して、データ・セットから生成される。
Ｎ＿Ｔ＝Ｅ＿｛Ｋ＿Ｔ｝（ｈａｓｈ）
【００５１】
好ましくは、Ｎ＿Ｔは、個人識別コードＰＩＮ＿Ｕの定義された長さに短縮される（一実施形態では、Ｎ＿Ｔを切り捨てることによって）。
【００５２】
ステップＳ１２で、サーバ４のユーザ認証モジュール４０が、通信端末にトランザクション認証番号（ＴＡＮ）を要求する。公開鍵４６がＳ６でトークン固有公開鍵証明書内にある場合には、ユーザ識別子ＩＤ＿Ｕを、たとえば所与のトークンＳＮ＿Ｔと共に使用される最も最近のＩＤ＿Ｕを反映する要求と一緒に送信することができる、すなわち、ＩＤ＿Ｕは、トークンが異なるユーザによって使用される場合に、ＨＴＭＬフォーム・フィールドに既にプリフィルされており、訂正される必要だけがあるので、ユーザによって入力される必要がない。
【００５３】
ステップＳ１３で、ステップＳ１１で生成された認証ベース番号Ｎ＿Ｔが、通信端末１に渡される。
【００５４】
ステップＳ１４で、通信端末１の制御モジュールが、ユーザに個人識別コードＰＩＮ＿Ｕを要求し、受け取る。実施形態に応じて、個人識別コードＰＩＮ＿Ｕは、データ入力手段１２またはバイオメトリック・データ（バイオメトリック識別子）用のセンサ、たとえば指紋リーダー（たとえば、異なる指の指紋が、異なる番号または文字を割り当てられる）を使用して入力される。
【００５５】
ステップＳ１５で、通信端末１の制御モジュールが、ステップ１４で受け取った個人識別コードＰＩＮ＿ＵおよびステップＳ１１で生成された認証ベース番号Ｎ＿Ｔから、たとえばユーザに透過的な形で擬似乱数関数ＰＲＦを使用して、トランザクション認証番号ＴＡＮを生成する。
ＴＡＮ＝ＰＲＦ＿｛ＰＩＮ＿Ｕ｝（Ｎ＿Ｔ）
【００５６】
副実施形態として、ＰＩＮを通信端末１によって受け取ることができ、Ｓ１５を、非人格的な認証トークン・デバイス２０上で実行することができ、その後、ＴＡＮを通信端末１に返すことができる。
【００５７】
この場合に、副実施形態として、「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージを生成するステップおよびトランザクション認証番号ＴＡＮを生成するステップを、異なってグループ化することができ、データ・セット（ハッシュ）を生成するのに使用される関数ｈが、暗号ハッシュ関数の特性を満足する場合には、たとえば、ＨＭＡＣコンストラクション（Ｋｒａｗｃｚｙｋ，Ｈ．，他、「ＨＭＡＣ：Ｋｅｙｅｄ−Ｈａｓｈｉｎｇ ｆｏｒ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ２１０４、１９９７年２月）を使用して、ハッシュ関数ｈを実施することができ、その場合に、ＰＩＮ＿Ｕは、データ・セット（ハッシュ’）のＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ計算への引数になる。この実施形態では、認証ベース番号Ｎ＿Ｔ’は、トランザクション認証番号になり、ＴＡＮ＝Ｎ＿Ｔ’である。この実施形態では、データ・セット（ハッシュ’）およびハッシュ関数ｈへの１つの入力すなわちＰＩＮ＿Ｕを除くすべての入力を有することから、ＰＩＮ＿Ｕを再構成することが実現可能でないことが必須である。ＨＭＡＣは、これを満足する１つの関数である。また、ＨＭＡＣは、擬似乱数関数ＰＲＦに使用され、トランザクション認証番号ＴＡＮを生成するのに使用される。
ＴＡＮ＝ＨＭＡＣ＿｛ＰＩＮ＿Ｕ｝（Ｎ＿Ｔ）＝ｈ（Ｋ＋ｏｐａｄ‖ｈ（Ｋ＋ｉｐａｄ‖Ｎ＿Ｔ））
【００５８】
この場合に、Ｋは、ある独自の指定された形で（たとえば、ＰＫＣＳ ＃５に従って）ＰＩＮ＿Ｕから導出される。記号＋は、加算の２を法とする剰余を指し、‖は、文字列連結を指す。ｏｐａｄおよびｉｐａｄは、定数値である。特に、ユーザがＴＡＮをユーザ自身で計算する必要がないときに、数字［０．．９］のみ以外のアルファベットが好ましい可能性がある。
【００５９】
トランザクション認証番号ＴＡＮは、正確に１つのセキュア（ＳＳＬ／ＴＬＳ）セッションについて有効である。
【００６０】
ステップＳ１６で、ステップＳ１２で受け取った要求に応答して、通信端末１が、生成されたＴＡＮ、ユーザによって確認されたか新たに入力されたユーザ識別子ＩＤ＿Ｕ、ならびにｋを含むトークン証明書がＳＮ＿Ｔをも含む（Ｓ６で任意選択）のでない限りユーザによって入力されたトークン識別子ＳＮ＿Ｔをサーバ４に送信する。ＳＮ＿Ｔは、たとえば、トークン識別子２０３を有するメモリ・モジュールから読み取られ、またはブラウザに関連する通信端末１内のメモリから読み取られる。
【００６１】
ステップＳ１７で、サーバ４のユーザ認証モジュール４０が、データベース４１内で、ステップＳ１６で受け取られたユーザ識別子ＩＤ＿Ｕに割り当てられた個人識別コード（ＰＩＮ＿Ｕ）４４を判定する。
【００６２】
ステップＳ１８で、認証モジュール２に関連する秘密トークン鍵Ｋ＿Ｔを使用して、ユーザ認証モジュール４０が、ステップＳ１０で受け取ったデータ・セット（ハッシュ）から認証ベース番号Ｎ＿Ｔを生成する。一実施形態で、秘密トークン鍵Ｋ＿Ｔは、ステップＳ１６で受け取ったトークン識別子ＳＮ＿Ｔから、マスタ鍵（ＭＫ）４２を使用して生成される。しかし、秘密トークン鍵（Ｋ＿Ｔ）４５がサーバ４上で格納される場合には、これをＭＫを用いて再計算する必要はなく、完全にランダムに選択することができる。トークン識別子ＳＮ＿Ｔが、セキュア・セッション確立プロトコルの途中で交換されるトークンのクライアント証明書、たとえばステップＳ３とＳ９との間の「クライアント証明書」メッセージの一部である場合に、ＳＮ＿Ｔは、ステップＳ１６で通信端末１からサーバ４には送信されない。
【００６３】
ステップＳ１９で、ユーザ認証モジュール４０は、ステップＳ１７で判定された個人識別コードＰＩＮ＿ＵおよびステップＳ１８で生成された認証ベース番号Ｎ＿Ｔから、トランザクション認証番号ＴＡＮを生成する。
【００６４】
ステップＳ２０で、ユーザ認証モジュール４０は、ステップＳ１９で生成されたトランザクション認証番号との比較を介して、ステップＳ１６で受け取ったトランザクション認証番号を検証する。肯定の検証の際に、通信端末１は、サーバ４へのアクセスを与えられ、あるいは、一実施形態で、サーバは、図８を参照して後で説明するステップＳ４１で継続する。
【００６５】
図５に示されているように、代替実施形態では、ステップＳ１３、Ｓ１４、およびＳ１５を含むブロックＡが、ステップＳ２１、Ｓ２２、Ｓ２３、およびＳ２４を含むブロックＢに置換される。
【００６６】
ステップＳ２１で、それぞれ認証トークン・デバイス２０または認証モジュール２のデータ入力手段２３またはセンサ２４を介して、個人識別コードＰＩＮ＿Ｕが、ユーザから受け取られる。
【００６７】
ステップＳ２２で、証明モジュール２５が、ステップＳ２１で受け取った個人識別コードＰＩＮ＿ＵおよびステップＳ１１で生成した認証ベース番号Ｎ＿Ｔから、ステップＳ１５の文脈で上で説明したようにトランザクション認証番号ＴＡＮを生成する。したがって、ステップＳ１５の文脈で説明した副実施形態も、図５に示された実施形態にあてはまる。
【００６８】
ステップＳ２３で、ステップＳ２２で生成されたトランザクション認証番号ＴＡＮが、通信端末１に渡される。
【００６９】
ステップＳ２４で、トランザクション認証番号ＴＡＮが、通信端末１内で受け取られ、おそらくはディスプレイ１１に表示される。その後、通信端末１は、上で説明したステップＳ１６で継続する。
【００７０】
図６に示されているように、代替実施形態では、ステップＳ１３、Ｓ１４、およびＳ１５を含むブロックＡが、ステップＳ３１およびＳ３２を含むブロックＣに置換される。
【００７１】
ステップＳ３１で、ディスプレイ・モジュール２７が、ステップＳ１１で生成された認証ベース番号Ｎ＿Ｔをディスプレイ２２に表示する。
【００７２】
ステップＳ３２で、通信端末１の制御モジュールが、トランザクション認証番号ＴＡＮをユーザから受け取る。ステップＳ３２で入力されるトランザクション認証番号は、ディスプレイ２２に表示された認証ベース番号Ｎ＿Ｔおよびユーザの個人識別コードＰＩＮ＿Ｕの組合せとしてユーザによって定義される。
ＴＡＮ＝ｆ（Ｎ＿Ｔ，ＰＩＮ＿Ｕ）
【００７３】
一般に、適当な関数ｆを定義する多数の可能性がある。Ｍｏｌｖａ，Ｒ．およびＧ．Ｔｓｕｄｉｋ、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍｅｔｈｏｄ ｗｉｔｈ Ｉｍｐｅｒｓｏｎａｌ Ｔｏｋｅｎ Ｃａｒｄｓ」、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＩＥＥＥ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｒｅｓｅａｒｃｈ ｉｎ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ、ＩＥＥＥ Ｐｒｅｓｓ、１９９３年５月で、引数の１０を法とする剰余の合計を使用することが提案されている。この提案は、適当であるが、同等によく働く多数の他の関数がある。たとえば、ＳｗｉｖｅｌのＰＩＮｓａｆｅによるもう１つの手法は、長さ１０のＮ＿Ｔを表示し、選択に数値ＰＩＮの数を使用することである。その後、通信端末１は、上で説明したステップＳ１６で継続する。
【００７４】
図７に示された実施形態では、認証モジュール２が、通信端末１内のプログラムされたソフトウェア・モジュールによって排他的に実施される。図４に示された実施形態と比較して、図７による実施形態は、ステップＳ５、Ｓ７、およびＳ１３を含まない。というのは、通信端末１と通信端末１の外部の認証モジュール（トークン・デバイス２０）との間のデータ交換がないからである。情報は、通信端末１と認証モジュール２との間で、ソフトウェア・インターフェースまたは通信端末１内の共有メモリ・エリアを使用して交換される。それ以外の点では、ステップＳ１、Ｓ２、Ｓ３、Ｓ４、Ｓ６、Ｓ８、Ｓ９、Ｓ１０、Ｓ１１、Ｓ１２、Ｓ１４、Ｓ１６、Ｓ１７、Ｓ１８、Ｓ１９、およびＳ２０は、図４に関して上で説明したように実行される。
【００７５】
図８に示されているように、ステップＳ４１で、サーバ４は、ステップＳ９で受け取ったデータ・セット（ハッシュ）からサーバ認証コードを生成する。サーバ認証コードＡ＿Ｔは、データ・セット（ハッシュ）に公開関数ｇを適用することと、ステップＳ１８で判定された秘密トークン鍵Ｋ＿Ｔを暗号化に使用することとによって生成される。
Ａ＿Ｔ＝Ｅ＿｛Ｋ＿Ｔ｝（ｇ（ｈａｓｈ））
【００７６】
Ａ＿Ｔの構成は、基本的に認証ベース番号Ｎ＿Ｔの構成と同一である。唯一の相違は、データ・セット（ハッシュ）が、秘密トークン鍵Ｋ＿Ｔを用いて暗号化される前に、公に知られた関数ｇにかけられることである。関数ｇが複雑である必要はない。関数ｇは、ハッシュ値の補数を計算すること程度に単純なものとすることができる。このサーバ認証に本質的なのは、データ・セット（ハッシュ）と認証ベース番号Ｎ＿Ｔとの両方を見ることができる可能性がある敵対者が、トークン鍵Ｋ＿Ｔが秘密であることと、暗号化関数Ｅ＿（一実施形態で、これをｔｒｉｐｌｅ−ＤＥＳなどの対称暗号とすることができる）の特性とのゆえに、Ａ＿Ｔを構成できないことである。
【００７７】
ステップＳ４２で、ステップＳ４１で生成されたサーバ認証コードが、通信端末１に送信される。
【００７８】
ステップＳ４３で、ステップＳ４２で受信されたサーバ認証コードが、通信端末１によってディスプレイ１１に表示される。
【００７９】
ステップＳ４４で、サーバ認証モジュール２８が、公開関数（ｇ）をデータ・セットに適用することと、認証モジュール２に関連する秘密トークン鍵Ｋ＿Ｔを暗号化に使用することとによって、ステップＳ５で受け取られたデータ・セット（ハッシュ）からサーバ認証コードを生成する。
【００８０】
ステップＳ４５で、ディスプレイ・モジュール２７が、ステップＳ４４で生成されたサーバ認証コードをディスプレイ２２に表示する。
【００８１】
ステップＳ４６で、サーバ４は、ユーザが、ディスプレイ２２に表示されたサーバ認証コードとの比較を介してディスプレイ１１に表示されたサーバ認証コードを検証することによって認証される。
【００８２】
図９に示された実施形態では、認証モジュール２が、通信端末１内のプログラムされたソフトウェア・モジュールによって排他的に実施される。図８に示された実施形態と比較して、図９による実施形態は、ステップＳ４７で、ディスプレイ・モジュール２７が、ステップＳ４４で生成されたサーバ認証コードをディスプレイ１１に表示する。さらに、ステップＳ４８で、サーバ４は、ユーザが、サーバ認証モジュール２８からのサーバ認証コードとの比較を介してサーバ４からのサーバ認証コードをディスプレイ１１上で検証することによって認証される。
【００８３】
ここまでで提案された認証モジュール２は、単一の機関に対してユーザを認証する（単一の個人識別コードを使用して）のに使用することができる。さらなる実施形態では、認証モジュール２は、複数の機関を伴う応用例のために、すなわち、複数の機関のサーバに対してユーザを認証するように構成される。複数機関認証モジュールを実施する好ましい手法は、マスタ鍵ＭＫを機関固有マスタ鍵ＭＫ＿Ｉの組に置換し、トークン鍵Ｋ＿Ｔを機関固有トークン鍵Ｋ＿｛ＩＴ｝の組に置換することであり、ここで、Ｋ＿｛ＩＴ｝は、認証モジュールが機関Ｉと共有する秘密トークン鍵を指す。各サーバ４は、特定の機関に関連し、認証ベース番号を生成するのに、その機関に固有の秘密トークン鍵を使用する。単一機関セッティングに似て、秘密トークン鍵Ｋ＿｛ＩＴ｝は、次式に従って動的に生成することができる。
Ｋ＿｛ＩＴ｝＝Ｅ＿｛ＭＫ＿Ｉ｝（ＳＮ＿Ｔ）
【００８４】
次に、この鍵が、認証ベース番号およびトランザクション認証番号の機関固有の値を生成するのに使用される。
Ｎ＿｛ＩＴ｝＝Ｅ＿｛Ｋ＿｛ＩＴ｝｝（Ｈａｓｈ）
および
ＴＡＮ＝ｆ（Ｎ＿｛ＩＴ｝，ＰＩＮ＿｛ＩＵ｝）
【００８５】
次に、結果のＴＡＮを、ユーザが機関Ｉ（のサーバ４）への認証に使用することができる。個人識別コードＰＩＮ＿｛ＩＵ｝は、ユーザ固有であるだけではなく、機関固有でもある。したがって、複数機関認証モジュールは、複数の機関固有秘密トークン鍵の組を格納したことによってまたは機関固有秘密トークン鍵を動的に生成するために複数の機関固有トークン識別子およびマスタ鍵の組を格納したことによってのいずれかで、複数の機関固有秘密トークン鍵に関連する。選択モジュール２９は、ユーザが、それぞれ認証モジュール２または認証トークン・デバイス２０について複数の可能な機関スコープのうちの１つを選択するために設計されている。ユーザによって選択された機関スコープをセットされて、認証モジュール２は、認証ベース番号を生成するのに、１つのめいめいの機関固有秘密トークン鍵を使用する。たとえば、選択モジュール２９は、ディスプレイ２２または１１上で、サポートされる機関のリストをユーザに提示し、データ入力手段２３または１２を介してユーザ選択を受け取る。代替実施態様では、データ入力手段２３または１２の特定のキーが、特定の機関に割り当てられる。
【００８６】
認証モジュール２が複数のＫ＿｛ＩＴ｝ではなく１つだけを安全に保持するさらなる実施形態では、オンライン包括的発行機関（ｏｎｌｉｎｅ ｏｖｅｒａｒｃｈｉｎｇ ｉｓｓｕｉｎｇ ｉｎｓｔｉｔｕｔｉｏｎ）（ＡＳ）が追加される。これは、認証モジュール２の発行グループの一部である機関の組の柔軟性を高める。認証モジュール２は、ナンスＲ＿Ｔを作成する。ユーザは、認証モジュール２のディスプレイから２つの値をコピーしなければならない、すなわち、ＳＮ＿Ｔではなく、ＴＡＮ＿ＡＳが、代わりに生成され、ユーザ認証フェーズ中に成功のＳＳＬ／ＴＬＳセッション確立の後に入力される必要がある。
ＴＡＮ＿Ｉ＝ｆ’（Ｒ＿Ｔ，ＰＩＮ＿Ｕ＿Ｉ）
ＴＡＮ＿ＡＳ＝Ｅ＿ＭＫ（Ｒ＿Ｔ，Ｈａｓｈ，ＩＤ＿Ｉ）
ここで、ＩＤ＿Ｉは、「機関ＸＹＺ」の「ＸＹＺ」など、短い識別子文字列である。
【００８７】
機関Ｉは、両方の値を見るが、単独ではこれらについて何もすることができない。機関Ｉは、ＴＡＮ＿ＡＳを発行機関ＡＳに転送し、それと引き換えにＲ＿ＴおよびＨａｓｈを受け取る。ＡＳとＩとの間の接続が、相互に認証され、機密であると仮定する。
【００８８】
犯罪の意図がない限り、ＴＡＮ＿Ｉは、発行機関ＡＳによって絶対に見られず、したがって、発行機関ＡＳがＰＩＮ＿Ｕ＿Ｉを判定できる危険性はない。しかし、この実施形態では、前に述べた強い暗号ハッシュ関数であるｆ’を選択することだけが推奨される。
同様に、この手法は、機関Ｉ＿１…Ｉ＿ｎを、互いのユーザのＰＩＮを知ることを試みることから保護する。
【００８９】
この実施形態は、新しい機関の追加を非常に単純にする。本質において、追加のＩＤ＿Ｉ＿ｎ文字列を、認証モジュール２に単純に追加することができる。認証モジュール２が、偽物のＩＤ＿Ｉ文字列であふれる場合には、これは、ユーザビリティの懸念にはなるが、それ以外の点で提案される方法のセキュリティを実際に傷つけはしない。
【００９０】
一実施形態で、認証モジュール２または認証トークン・デバイス２０は、それぞれ、「使い捨てパスワード」（ＯＴＰ）システム（たとえば、ＬａｍｐｏｒｔスタイルＯＴＰ（Ｌａｍｐｏｒｔ，Ｌ．、「Ｐａｓｓｗｏｒｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｗｉｔｈ Ｉｎｓｅｃｕｒｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ」、Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｏｆ ｔｈｅ ＡＣＭ、Ｖｏｌ．２４、１９８１年、７７０〜７７２頁）またはＳｅｃｕｒＩＤトークン（ｈｔｔｐ：／／ｗｗｗ．ｒｓａｓｅｃｕｒｉｔｙ．ｃｏｍ／））を補完するのに使用される。この場合に、ユーザは、ステップＳ１５のＰＲＦまたはｆの入力としてＯＴＰを使用する（ＰＩＮ＿Ｕの代わりに）。しばしば、ＯＴＰはＰＩＮ＿Ｕを含む。それ以外のすべてが、本質的に同一のままになる。プロトコルにおける小さい変更ではあるが、これは、ＲＳＡのＳｅｃｕｒＩＤなど、既に使用されているツー・ファクタ・セキュリティ要素を用いるソフトウェア変形形態の使用を可能にする。
【００９１】
もう１つの実施形態では、バイオメトリック認証ステップが、認証トークン・デバイス２０をアクティブ化する前に追加される。これは、トークンが、別々のプロセスでパーソナライズされ、バイオメトリックスが一致する場合に限ってトークンの少なくとも「一時的な」所有者の要求を満たし始めることを暗示する。
【００９２】
さらなる実施形態で、ユーザのバイオメトリック特性Ｂ＿Ｕが、前に説明したようにＰＩＮ＿Ｕを入力するのには使用されない場合に、バイオメトリック・データは、認証ベース番号Ｎ＿Ｔの計算に含められる。また、この実施形態のサーバは、ＰＩＮ＿Ｕの上にＢ＿Ｕを格納し、したがって、認証モジュール２は、完全に個人的に転送可能なままになる。
Ｎ＿Ｔ’’＝Ｅ＿｛Ｋ＿Ｔ｝（Ｈａｓｈ，Ｂ＿Ｕ）
【００９３】
図４、５、６、７、８、および９に示されたステップの異なるシーケンスが、本発明の範囲から逸脱せずに可能であることを指摘しなければならない。
【００９４】
個人識別コードの変更に関する実施形態
エンド・ユーザ教育の展望から、単純な行動ガイドラインを有することが重要である。説明されるすべての実施形態について、これは、確かに「絶対に現在のまたは新しい個人識別コードをウェブ・ブラウザに入力してはならない」になる。図５に示された個人識別コードを入力するモジュールなど、追加ハードウェアを含む実施形態について、ガイドラインは、「絶対に主キーボードを用いて画面にＰＩＮを入力してはならない」にさえなる。しかし、好ましくは、ユーザが周期的に自発的にそのユーザの個人識別コードＰＩＮ＿Ｕを変更することが可能でなければならない。
【００９５】
たとえば、個人識別コードＰＩＮ＿Ｕを変更するために、本質的に上で説明したものと同一のステップを実行する、もう１つのセキュア・セッションが確立される。具体的に言うと、図４、５、または７に示されているように、ステップＳ１からＳ１０の後に、ステップＳ１１で、認証ベース番号Ｎ＿Ｔが生成される。
【００９６】
個人識別コードＰＩＮ＿Ｕの変更に関するユーザまたはサーバの指示に応答して、それぞれステップＳ１４またはステップＳ２１で、古い個人識別コードＰＩＮｏｌｄ＿Ｕおよび新しい個人識別コードＰＩＮｎｅｗ＿Ｕが、それぞれ通信端末１、認証トークン・デバイス２０、または認証モジュール２内でユーザから受け取られる。好ましくは、タイピング・エラーを避けるために、新しい個人識別コードＰＩＮｎｅｗ＿Ｕは、二重入力を介して確認される。
【００９７】
それぞれステップＳ１５またはＳ２２で、トランザクション認証番号ＴＡＮを生成するのではなく、識別変更コード（ＰＣＣ）が生成される。本質的に、ＰＣＣの計算に使用されるＰＲＦは、個人識別コードを回復可能にしなければならない。たとえば、排他的論理和（ＸＯＲ）関数が、この特性を有する。
【００９８】
次に、ＰＣＣが、適当に選択された関数ｆ０についてＰＣＣ＝ｆ０（Ｎ＿Ｔ，ＰＩＮｏｌｄ＿Ｕ，ＰＩＮｎｅｗ＿Ｕ）として計算される。たとえば、ｆが１０を法とする剰余での桁単位の加算を表す場合に、ｆ０を次のように定義することができる。
ｆ０（Ｎ＿Ｔ，ＰＩＮｏｌｄ＿Ｕ，ＰＩＮｎｅｗ＿Ｕ）＝ｆ（ｆ（Ｎ＿Ｔ，ＰＩＮｏｌｄ＿Ｕ），ＰＩＮｎｅｗ＿Ｕ）
【００９９】
たとえば、Ｎ＿Ｔ＝１２３、ＰＩＮｏｌｄ＿Ｕ＝３４５、およびＰＩＮｎｅｗ＿Ｕ＝７８１の場合に、ｆ（Ｎ＿Ｔ，ＰＩＮｏｌｄ＿Ｕ）＝４６８であり、ｆ（ｆ（Ｎ＿Ｔ，ＰＩＮｏｌｄ＿Ｕ），ＰＩＮｎｅｗ＿Ｕ）＝１４９である。
【０１００】
その後、ステップＳ１６、Ｓ２３、Ｓ２４で、トランザクション認証番号ＴＡＮではなく、識別変更コード（ＰＣＣ）がサーバ４に通信される。ステップＳ１７およびＳ１８は、上で説明したように実行される。ステップＳ１９およびＳ２０では、その結果、トランザクション認証番号ＴＡＮを検証するのではなく、サーバ４は、（ＰＩＮｏｌｄ＿Ｕの検証を介して）個人識別コードＰＩＮ＿Ｕを変更したのが正当なユーザであって、進行中のセッションが正当なユーザによって無人のままにされたアンロックされた端末を利用した他の誰かではないことを保証しながら、ユーザによってサブミットされたＰＣＣからＰＩＮｎｅｗ＿Ｕを導出する。ｆ０について与えた例では、サービス拒否につながり得る盲目的置換攻撃に対する保護が、与えられない。しかし、現在優勢なセッション確立プロトコル（ＳＳＬ／ＴＬＳ）の文脈では、相補的なメッセージ完全性保護が、この攻撃を防ぐ。
【０１０１】
もう１つの実施形態では、個人識別コードＰＩＮ＿Ｕが、３つのセキュア・セッション確立によって実施される。
【０１０２】
第１は、ユーザがＰＩＮｏｌｄ＿Ｕを再供給するセッションであり、第２は、ユーザがＰＩＮｎｅｗ＿Ｕを提示するセッションであり、第３は、ユーザがタイピング・エラーを避けるためにＰＩＮｎｅｗ＿Ｕを再提示するセッションである。
【０１０３】
ＰＩＮ変更が、サーバによって開始された場合に、このプロトコルの状態をシグナリングするために、サーバは、この３つのステップのそれぞれについて異なるオーソリティである、ｈｔｔｐ：／／ｗｗｗ．ｒｆｃ．ｎｅｔ／ｒｆｃ２２４６．ｈｔｍｌ＃ｓ７．４．４に概要を示された擬似「ＤｉｓｔｉｎｇｕｉｓｈｅｄＮａｍｅ ｃｅｒｔｉｆｉｃａｔｅ＿ａｕｔｈｏｒｉｔｉｅｓ」をアドバタイズすることができる。同様に、トークンは、４つすなわち、通常の認証用に１つとこの実施形態用に３つの異なる証明書を有する必要がある。
【０１０４】
代替案では、認証ベース番号Ｎ＿Ｔを計算する時に、認証トークン・デバイス２０または認証モジュール２は、それぞれ、ステップ識別子を含む。したがって、それぞれ認証トークン・デバイス２０または認証モジュール２で必要な異なる証明書の個数を減らすことができる。
【０１０５】
個人識別コードの変更が、クライアントによって開始された場合に、サーバは、少なくとも、通常の認証用に１つおよび個人識別コードの変更のステップ１用に１つの２つのＣＡを提供しなければならない。
【０１０６】
暗号なしの認証モジュールを用いる実施形態
もう１つの実施形態で、認証トークン・デバイス２０または認証モジュール２は、それぞれ、暗号化のために構成される必要がない。
【０１０７】
この実施形態では、認証ベース番号Ｎ＿Ｔが、ＨＭＡＣなどの暗号ハッシュ関数によって、秘密としてトークン鍵Ｋ＿Ｔを使用して計算される。これは、多少より少ない計算オーバーヘッドで同一のセキュリティを提供する。共有される秘密およびセキュア・ストレージの必要は、この実施形態でも残る。たとえば、ステップＳ１５の文脈で説明した副実施形態で概要を示した暗号ハッシュ（ＣＨ）を使用して、ステップＳ１１で使用される暗号化を置換することができる。
Ｎ＿Ｔ＝ＣＨ＿｛Ｋ＿Ｔ｝（ｈａｓｈ）
これは、ステップＳ４１またはＳ４４など、暗号化の他の使用にもあてはまる。
【０１０８】
代替トランザクション認証番号（ＴＡＮ）を用いる実施形態
この実施形態では、個人識別コードＰＩＮ＿Ｕが、ステップＳ４の後に、ステップＳ１４またはＳ２１の文脈で前に（図４）説明した形で入力される。その後、鍵付き暗号ダイジェスト値、たとえば暗号ハッシュが、個人識別コードおよび通信端末とサーバ４との間で交換されたセキュア・セッション確立プロトコル・メッセージから生成される。プロトコル・フローに関して、セキュリティ目的ではなく、このステップに通し番号ＳＮ＿Ｔをも含めることが有用である場合がある。鍵付き暗号ダイジェスト値は、鍵付き暗号ダイジェスト関数、たとえば、サーバ４と共有される秘密を（ハッシュ）鍵として使用するいわゆる「鍵付きハッシュ関数」を用いて、生成される。実施形態に応じて、（ハッシュ）鍵として使用されるのは、トークン鍵Ｋ＿Ｔ、個人識別コードＰＩＮ＿Ｕ、またはセキュア・セッション確立プロトコル内でセッション鍵を確立するための基礎として使用されたプリマスタ秘密である。具体的に言うと、個人識別コードＰＩＮ＿Ｕが、明確に選択された秘密である場合に、その個人識別コードＰＩＮ＿Ｕを（ハッシュ）鍵として使用することができる。これによって、認証トークン・デバイス２０が、それ自体の秘密のトークン鍵Ｋ＿Ｔまたは私有署名鍵ｋー１あるいはその両方を有することから解放され、認証モジュール２または認証トークン・デバイス２０が、それぞれ、単に「信頼される観察者」になる。サーバ４は、「高い金額を人ｘｙｚに送れ」などのアプリケーション・レベル指示が認証されたＳＳＬセッション内から来るのか否かを即座に検出する。
【０１０９】
たとえば、ステップＳ５で、サーバ４と交換されたセキュア・セッション確立プロトコル・メッセージから通信端末１によって生成されたデータ・セット（ハッシュ）および個人識別コードＰＩＮ＿Ｕが、それぞれ認証モジュール２または認証トークン・デバイス２０に渡される。ステップＳ６で、証明モジュール２５が、データ・セット（ハッシュ）および個人識別コードＰＩＮ＿Ｕから暗号ハッシュを生成する。ステップＳ６での電子署名の生成は、任意選択である。ステップＳ７で、暗号ハッシュ（電子署名を伴うまたは伴わない）が、通信端末１に渡される。この副実施形態では、ＰＩＮ＿Ｕも、ユーザによってステップＳ６で認証トークン・デバイス２０に直接に入力することだけができる。
【０１１０】
代替案では、暗号ハッシュは、ステップＳ４で、個人識別コードＰＩＮ＿Ｕおよび通信端末１とサーバ４との間で交換されたセキュア・セッション確立プロトコル・メッセージから生成される。その結果、ステップＳ５からＳ７は、必要なステップのすべてがステップＳ４で実行されるので、省略される。
【０１１１】
ステップＳ８で、通信端末１は、ステップＳ３で受け取った証明要求に対する応答、たとえば、それぞれステップＳ６またはＳ４で生成された暗号ハッシュおよびユーザによって確認されたか新たに入力されたユーザ識別子ＩＤ＿Ｕを含む、ＳＳＬ／ＴＬＳに従う「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージを用意する。
【０１１２】
ステップＳ１０で、サーバ４は、サーバ４に格納されたユーザの個人識別コードを使用して暗号ハッシュを生成し、サーバ４で生成された暗号ハッシュとステップＳ９で通信端末から受信した暗号ハッシュとの比較に基づいてユーザの真正性を検証する。肯定の検証の際に、通信端末１は、たとえばサーバ４へのアクセスを与えられる。したがって、暗号ハッシュが、上で説明したトランザクション認証番号ＴＡＮの代替データ要素として生成され、交換され、検証される。
【０１１３】
サーバ４がユーザを認証しなければならない場合に、サーバ４は、ステップＳ４１で継続する。しかし、さらなる副実施形態では、サーバ認証コードＡ＿Ｔが、ステップＳ４〜Ｓ６の直後に表示される。
【０１１４】
外部チャレンジ／レスポンス・デバイスを用いる実施形態
この好ましい実施形態では、認証モジュール２は、図７および１０に示されているように、通信端末１内のプログラムされたソフトウェア・モジュールによって排他的に実施される。ステップＳ１、Ｓ２、Ｓ３、Ｓ４、Ｓ６、Ｓ８、Ｓ９、Ｓ１０、およびＳ１１は、本質的に図４を参照して上で説明したように実行される。ステップＳ１１の一部として、認証ベース番号Ｎ＿Ｔが、ディスプレイ１１に表示される。副実施形態では、認証モジュール２が、信頼されるオブザーバとしてのみ働き、認証ベース番号（Ｎ＿Ｔ’’’）が、プロトコル・メッセージから、たとえば通常のＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージから生成されるデータ・セットの短い派生物（たとえば、６桁または８桁）として生成される。本質的に、認証ベース番号Ｎ＿Ｔは、活用可能な形でＭＩＴＭによって判定することのできない任意の他のセッション関連識別子とすることができ、たとえば、セッション鍵およびサーバ公開鍵の短いダイジェストを、ＭＩＴＭ攻撃に耐えるセキュア・セッション識別子として認証ベース番号Ｎ＿Ｔを計算するもう１つの形とすることができる。「Ｆｉｎｉｓｈｅｄ」メッセージのハッシュまたは暗号化された「Ｆｉｎｉｓｈｅｄ」メッセージ、あるいは外部観察可能ハンドシェーク・メッセージのシーケンス全体が、このセッション関連識別子（それぞれＮ＿ＴまたはＮ＿Ｔ’’’）を構成するための他の候補であり、下でより詳細に説明される。したがって、この実施形態では、Ｎ＿Ｔを構成するために秘密トークン鍵Ｋ＿Ｔを有することが、任意選択である。同様に、秘密署名鍵ｋ−１も、任意選択とすることができる。
【０１１５】
その後、図１０に示されているように、ステップＳ５１で、ユーザが、認証ベース番号Ｎ＿Ｔ（クライアント側で生成されたチャレンジとして）およびそのユーザの個人識別コードＰＩＮ＿Ｕ（たとえば、コードまたはバイオメトリック・データとして）を、通信端末１に接続されていない従来のＣ／Ｒトークン・デバイス５に入力する。ステップＳ５２で、ステップＳ５１で入力された値に応答して、Ｃ／Ｒトークン・デバイス５が、それ自体の論理に基づいて、トークン・レスポンス値を生成し、表示する。ステップＳ１４およびＳ１５を置換するステップＳ５３で、ユーザが、トランザクション認証番号としてＣ／Ｒトークン・デバイス５からのトークン・レスポンス値を通信端末１に入力する。
【０１１６】
ステップＳ５４で、ステップＳ１２で受信した要求に応答して、通信端末１が、トランザクション認証番号ＴＡＮとして以前に入力されたトークン・レスポンス値をサーバ４に送信する。
【０１１７】
本質的に、ステップＳ１７からＳ２０は、それぞれ図４または７を参照して上で説明したようにサーバ４によって実行されるが、Ｃ／Ｒトークン・デバイス５の論理に対応して、サーバ４は、トランザクション認証番号ＴＡＮとしてトークン・レスポンス値を生成し、検証する。トランザクション認証番号すなわちトークン・レスポンス値の肯定の検証時に、それぞれ図８または９に示されているように、通信端末１が、サーバ４へのアクセスを与えられ、あるいは、一実施形態で、サーバ４が、ステップＳ４１で継続する。
【０１１８】
たとえば、Ｃ／Ｒトークン・デバイス５は、数百万枚の銀行カードおよびクレジット・カードで流通しているＥＭＶチップ（Ｅｕｒｏｐａｙ Ｉｎｔｅｒｎａｔｉｏｎａｌ、ＭａｓｔｅｒＣａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ、およびＶｉｓａ Ｉｎｔｅｒｎａｔｉｏｎａｌ）に基づく（ｈｔｔｐ：／／ｗｗｗ．ｅｍｖｃｏ．ｃｏｍを参照されたい）。ＥＭＶチップによって生成されるいくつかのトークン・レスポンス値は、個人識別コードＰＩＮ＿Ｕを含まない。ＭａｓｔｅｒＣａｒｄチップ認証プログラム（ＣＡＰ）に従うカードＩＣＣは、以前のＫ＿Ｔに似た役割を有するサーバ（発行者）と鍵を共有する。個人識別コードＰＩＮ＿Ｕおよびチャレンジ（認証ベース番号Ｎ＿Ｔ）の正しい入力の後に、とりわけ（たとえば、ＣＶＶ）チャレンジおよび正しい個人識別コードＰＩＮ＿Ｕが提示されたことの信頼できる確認を含む暗号文（通常は３ＤＥＳ）が作成される。通常、数字キーパッドを有する接続されないリーダーが、認証ベース番号Ｎ＿Ｔおよび個人識別コードＰＩＮ＿Ｕの入力に使用され、トークン・レスポンス値は、接続されないリーダーのディスプレイに表示される。認証ベース番号Ｎ＿Ｔ’’’が４桁または６桁に短縮されている場合に、たとえば、ＭＩＴＭが、認証ベース番号Ｎ＿Ｔ’’’への短いデータ・セット（ハッシュ）依存入力がサーバとＭＩＴＭとの間で開かれた主詐欺セッションと衝突する端末上のクライアントとの副詐欺セッションを確立できる可能性が、大きく高まる。ＭＩＴＭは、おそらくは、どちらの当事者にも衝突しない推測を気付かれずに、衝突が見つかったか否かをオフラインで検証することができる。そのような攻撃を防ぐために、「短縮」アルゴリズムは、ＭＩＴＭに完全に知られている単純なハッシュ関数または一方向ダイジェスト関数とすることはできず、さらなる特性を有する必要がある。基本的に、「セッション・アウェアネス」のオフラインでの推測が、ＭＩＴＭにとって、Ｃ／Ｒデバイス５を使用する時のすべての他のタイプの攻撃に関する個人識別コードＰＩＮ＿Ｕのオフラインでの推測と同等に魅力的でなくなる必要がある。これは、短縮されたハッシュでの衝突を見つけることが、もはやオフラインで検証可能ではなく、オンライン・オーソリティすなわち推測の回数を制限するサーバとの交換を必要としなければならないことを意味する。Ｃ／Ｒトークン・デバイス５の対称鍵（ユーザがパスワードとして記憶できると期待されるものより高いエントロピを有する）が、暗号化を介してＭＩＴＭから擬似乱数セレクタを隠すのに使用される。これは、本質的に、３６バイト長のハッシュ（データ・セット）全体に対する衝突を見つけることをＭＩＴＭに強いるが、これはほとんど実現不能である。
【０１１９】
したがって、一実施形態で、ステップＳ１１の一部として、クライアント側で、認証モジュール２が、たとえばクライアント・アプリケーション（たとえば、ブラウザ）の一部として、後で「ランダム選択数（ｒａｎｄｏｍ ｐｉｃｋｉｎｇ ｄｉｇｉｔ）」と称する短い乱数、たとえば４桁を生成する。この乱数は、プロトコル・メッセージから生成されたデータ・セットから、たとえばＴＬＳハンドシェークの「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージまたは「Ｆｉｎｉｓｈｅｄ」メッセージの３６バイト・ハッシュから任意のビットを選択するのに使用され、この任意のビットは、たとえばもう１つの４桁を表す。その後、後者の４桁および「ランダム選択数」が、たとえば８桁の短縮された認証ベース番号Ｎ＿Ｔ’’’としてディスプレイ１１でユーザに表示される。ステップＳ５１で、ユーザは、この認証ベース番号Ｎ＿Ｔ’’’（クライアント側で生成されたチャレンジとして）およびそのユーザの個人識別コードＰＩＮ＿Ｕを、図１０を参照して上で説明したようにＣ／Ｒトークン・デバイス５に入力する。ステップＳ５２からＳ５４は、図１０の文脈で上で説明したものと同一のままである。
【０１２０】
「ランダム選択数」がＭＩＴＭに知られ「ない」ために、Ｃ／Ｒトークン・デバイス５上のアルゴリズムは、「ランダム選択数」が暗号化された形でサーバ４に送られるように適合される。これは、トランザクション認証番号としてＣ／Ｒトークン・デバイス５によって生成されたトークン・レスポンス値が、暗号化された形で「ランダム選択数」を含むことを意味する。その結果、サーバ４は、それが受け取ったレスポンスから「ランダム選択数」を回復するように構成される。たとえば、３ＤＥＳ（またはたとえば６４ビットのブロック長を有する別の暗号化システム）を用いると、レスポンスは６４ビットである。たとえば、レスポンスについて、３２文字の英数字文字セットが許容され、したがって、レスポンスは、１３文字の長さになる。その結果、ユーザは、１３個の英数字文字をＣ／Ｒトークン・デバイス５からクライアント・アプリケーションに、たとえばブラウザのフォーム・フィールドにコピーしなければならない。ユーザが定期的に１９桁のクレジット・カード番号（ＣＶＶを含む）をタイプすることを考慮すると、チャレンジの８桁およびレスポンスの１３文字をタイプすることは、ユーザビリティの観点から許容されると思われる。この手法のセキュリティは、チャレンジおよびレスポンスの長さに対して相対的に高まり、あるいは下がる。
【０１２１】
サーバ側では、ステップＳ１８が変更され、「ランダム選択数」が、秘密トークン鍵Ｋ＿Ｔを使用して暗号化解除され、その後、短縮された認証ベース番号Ｎ＿Ｔ’’’を計算するための短縮された入力をデータ・セット（ハッシュ）から選択するのに使用されるようになる。他のすべてが、前と同じままである。
【０１２２】
さらなる実施形態として、認証ベース番号Ｎ＿Ｔが、たとえばｈｔｔｐ：／／ａｘｓｉｏｎｉｃｓ．ｃｈに記載のグラフィカル点滅（ｇｒａｐｈｉｃａｌ ｆｌｉｃｋｅｒｉｎｇ）など、ユーザがキーボードにタイプすることによるもの以外の手段を介してデバイスに入力される。重要な機能強化は、通常は完全にサーバによって作成される点滅チャレンジが、あるクライアント側で生成されるセキュア・セッション識別子によって修正される必要があることである。この点滅方法の実施態様は、好ましくは、ブラウザ（ｊａｖａ）プラグイン、Ｆｌａｓｈ、またはｊａｖａｓｃｒｉｐｔなど、あるクライアント側アクティブ・コンポーネントを有するので、いくつかの実施形態で、これを使用して、たとえば、サーバ公開鍵と、セッション鍵または他のタイプのセキュア・セッション識別子のダイジェストとを取り出し、これを点滅イメージ生成すなわち関連するプロトコルのチャレンジに含めることができる。このアクティブ・コンポーネントは、好ましくは、署名される。というのは、そうでなければ、ＭＩＴＭが、クライアント通信端末１に真に組み込まれた認証ベース番号Ｎ＿ＴではなくＭＩＴＭの認証ベース番号Ｎ＿Ｔを提示できる変更された版を簡単に注入するからである。
【０１２３】
さらなる副実施形態（「ハンドシェーク中のクライアント証明書認証なし」）では、通信端末１のクライアント・アプリケーション・ソフトウェア・モジュール、たとえばブラウザが、セキュア・セッション確立プロトコル・スタックへの読取専用アクセスを介してまたは「アウトサイダ」としてプロトコル・メッセージをスニッフ／取り込むことができることによってさえ、ＭＩＴＭ攻撃に耐えるセキュア・セッション識別子として認証ベース番号Ｎ＿Ｔｉｖを計算するように構成された認証番号ジェネレータ２６を設けられる。したがって、この副実施形態では、クライアント証明書認証を実行する必要がない、すなわち、片側のセキュア・セッションのためにステップＳ３〜Ｓ１０を実行する必要がなく、ＭＳ−ＣＡＰＩまたはＰＫＣＳ１１などのトークン・デバイス・ドライバは、もはや不要である。
【０１２４】
上で述べた認証番号ジェネレータ２６は、ステップＳ１１で、下に概要を示すように、ＭＩＴＭ攻撃に耐えるセキュア・セッション識別子として認証ベース番号Ｎ＿Ｔｉｖを計算するように構成される。
【０１２５】
ａ）認証ベース番号Ｎ＿Ｔｉｖは、データ・セット（ハッシュ）に基づき、ＭＩＴＭが知ることのできない（たとえば、入力として暗号化される前にプリマスタ秘密を有することに起因して）通信端末１とサーバ４との間で交換されるセキュア・セッション確立プロトコル・メッセージに基づいて生成され、または、
ｂ）認証ベース番号Ｎ＿Ｔｉｖは、既知の入力データおよび秘密の鍵から生成され（この実施形態では、クライアント・アプリケーションでの秘密トークン鍵Ｋ＿Ｔの必要を回避しなければならないが）、または、
ｃ）認証ベース番号Ｎ＿Ｔｉｖは、すべてがＭＩＴＭにも既知であるが、セキュア・セッション確立プロトコルへの論理的接続によってＭＩＴＭに対する抵抗を保証する入力データに基づいて生成される。この実施形態では、サーバの公開鍵および新しさを保証するもの（ナンスまたはタイムスタンプ）を使用することが、十分である。たとえば、暗号化されたプリマスタ秘密のハッシュすなわちＭＩＴＭによって観察可能なメッセージが、そのようなナンスとして働くことができる。この場合に、チャレンジを知り、レスポンスを観察することによって、ＭＩＴＭが（オフライン）ＰＩＮ推測攻撃を開始することができないことを、Ｃ／Ｒトークン・デバイスの論理が保証することが重要である。
【０１２６】
たとえば、認証番号ジェネレータ２６は、このＭＩＴＭに耐えるセキュア認証ベース番号Ｎ＿Ｔｉｖ（チャレンジ）をクライアント・アプリケーション内で表示するように構成される。たとえば、認証番号ジェネレータ２６は、ユーザがマウスのポインタを定義された区域、たとえばブラウザの右下の上、たとえばブラウザ内に表示されたロックの上に移動する時に、この区域内でチャレンジをユーザに可視にする。
【０１２７】
上で説明したように、ユーザは、認証ベース番号Ｎ＿Ｔｉｖ（チャレンジとして）およびそのユーザの個人識別コードＰＩＮ＿ＵをＣ／Ｒトークン・デバイスに入力し、この方法は、上で説明したように進行する。
【０１２８】
秘密の鍵を用いないがクライアント側でナンスを用いる実施形態
Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ２２４６に概要を示されているように、ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージの構造を、ＰＫＣＳ１エンコードされた署名ではなく任意のレスポンスによってオーバーロードする可能性がある。これは、トークンがもはや秘密トークン鍵Ｋ＿Ｔを必要としない可能性を提供する。この実施形態では、上で説明した「代替トランザクション認証番号（ＴＡＮ）を用いる実施形態」に類似して、ステップＳ６で、認証モジュール２または認証トークン・デバイス２０が、それぞれ、ハッシュ（データ・セット）、個人識別コードＰＩＮ＿Ｕ、およびさらに１つまたは２つの真にランダムなナンスＮ＿Ｔｔ（およびＮ＿Ｔａ）を公開鍵ｋ＿Ｓを用いて暗号化することによって、暗号文を生成する（ナンスは、「ｎｕｍｂｅｒ ｕｓｅｄ ｏｎｃｅ（１回だけ使用される数）」である）。公開鍵ｋ＿Ｓは、ＭＩＴＭがシステムをだましてＭＩＴＭ自身の鍵ｋ＿ＭＩＴＭを使用させるのを防ぐために、それぞれ認証モジュール２または認証トークン・デバイス２０に事前にインストールされなければならない。公開鍵ｋ＿Ｓは、サーバ４または複数機関の場合に認証サーバＡＳのいずれかに属する（認証サーバは、公開鍵ｋ＿ＡＳに関連する）。任意選択で、暗号文の入力値は、公開鍵ｋ＿（Ａ）Ｓによる暗号化の前に、秘密の鍵ｋ−１を用いて署名される。同様に、Ｓ１５の副実施形態に従って、暗号ハッシュ関数（ＨＭＡＣ）を、暗号化の前に適用することができる。
【０１２９】
ステップＳ７〜Ｓ９では、ほとんどの「セキュア・セッション確立プロトコル」によって要求されるように「電子署名」を送信するのではなく、この暗号文が、プロトコル仕様によって課せられる制約なしで、構造化されないデータとして送信される。他のプロトコル部分も、通信端末１のクライアント・アプリケーション内ではなく認証トークン・デバイス２０上で実行される（たとえば、セッション鍵の生成）実施態様では、「ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅ」メッセージなど、他のプロトコル・メッセージを使用して暗号文を送信することができる。
【０１３０】
ステップＳ１０で、サーバ４が、暗号文を暗号化解除する。これは、ナンスＮ＿Ｔｔ、個人識別コードＰＩＮ＿Ｕ、およびおそらくはナンスＮ＿Ｔａをサーバに与える。ナンスＮ＿Ｔｔは、「使い捨て」ナンスであり、ｐｉｎ推測攻撃を防ぐ塩として追加される。
【０１３１】
ステップＳ１０で、サーバ４は、ステップＳ４の文脈で説明したように「ハッシュ」も生成する。ステップＳ１１〜Ｓ１７は不要である。
【０１３２】
ステップＳ１８〜Ｓ２０で、認証モジュール４０は、もはや認証ベース番号Ｎ＿Ｔおよびトランザクション認証番号ＴＡＮを生成するのではなく、単純にハッシュとステップＳ１０で暗号化解除されたＰＩＮ＿Ｕとを比較する。暗号文から導出されたハッシュは、サーバ４で生成されたハッシュと比較され、個人識別コードＰＩＮ＿Ｕは、データベース４１に格納された個人識別コードと比較される。暗号ハッシュ関数がＳ６で使用される場合に、これらの値は、比較の前にまずサーバ側で暗号的にハッシュ化される必要もある。それ以外のすべてが、同一のままである。したがって、それぞれ暗号文または暗号ハッシュが、上で説明したトランザクション認証番号ＴＡＮの代替データ要素として生成され、交換され、検証される。
【０１３３】
サーバ４が、ユーザに対してサーバ４を認証もしなければならない場合に、ステップＳ４１からＳ４３の計算の代わりに、サーバは、暗号文から暗号化解除したナンスＮ＿Ｔａを単純にユーザに表示する。ステップＳ４４〜Ｓ４６の比較は、同一のままであり、計算は不要であるが、ナンスＮ＿Ｔａが単純にディスプレイ２２に表示される。
【０１３４】
この実施形態に対する追加として、個人識別コードＰＩＮ＿Ｕを変更するプロトコルをも実施することができる。新しい個人識別コードＰＩＮ＿Ｕは、単純に、Ｓ６の暗号文へのもう１つの入力である。
【０１３５】
セキュア・セッション確立プロトコル標準規格が、そのプロトコル・フィールドの固定されたフィールド長を指定しないという事実にもかかわらず、一部のクライアント・アプリケーション実施態様が、割り振られたメモリを、たとえば「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージ用に厳密に制限する場合がある。その場合に、楕円曲線暗号など、空間を最適化する公開鍵暗号に焦点を合わせる必要がある。
【０１３６】
個人識別コードＰＩＮ＿Ｕがユーザによって計算される、この実施形態に対する副実施形態もある。このために、ステップＳ６で、個人識別コードＰＩＮ＿Ｕが省略される。ナンスＮ＿Ｔｔが、ステップＳ３１について説明したようにユーザに表示され、トランザクション認証番号ＴＡＮが、ステップＳ３２について説明したように計算される。上で説明した、認証ベース番号Ｎ＿Ｔおよび個人識別コードＰＩＮ＿Ｕからトランザクション認証番号ＴＡＮを生成する他の変形形態を、認証ベース番号Ｎ＿Ｔに同様に適用することができる。
【０１３７】
短い（おそらくは使い捨ての）秘密の鍵を用いる実施形態
スクラッチ・リストまたはインデックス付きスクラッチ・リスト（たとえば、「ｉＴＡＮ」、「インデックス付きスクラッチ・リスト」、「アクセス・カード」）などのコード（または鍵）テーブルが、金融機関によって広く使用されているが、これらは、中間者攻撃に脆弱である。上の「秘密の鍵を用いないがクライアント側でナンスを用いる実施形態」を拡張して、あるレベルの「ツー・ファクタ」認証を達成することができる。
【０１３８】
ステップＳ６ａ（図４、５、６、および７ではステップＳ６として表される） あるアクセス・カードがたとえば１００個のエントリすなわち、４〜６個の数字文字の通常は短い「鍵」（Ｋ＿ＳＳＵ）を有する場合に、ステップＳ４で生成されるデータ・セット（以前のハンドシェーク・メッセージのハッシュ）が、そのアクセス・カードの鍵テーブルに対するルックアップ・インデックスとして働けるようになるまで圧縮される。
【０１３９】
Ｓ６ｂ（図４、５、６、および７ではステップＳ６として表される）では、圧縮された値（通常は２文字の長さ）が、インデックスとして表示される（たとえば、認証モジュール２または認証トークン・デバイス２０によって）。ルックアップ・インデックスをクライアント・アプリケーションに通信する代替の形があり、たとえば、「隠しチャネル」としての上で述べた「ＤｉｓｔｉｎｇｕｉｓｈｅｄＮａｍｅ ｃｅｒｔｉｆｉｃａｔｅ＿ａｕｔｈｏｒｉｔｉｅｓ」リストは、それぞれ認証モジュール２または認証トークン・デバイス２０にステップＳ６ｂで表示すべきインデックスを知らせるもう１つの手法を表すことができる。
【０１４０】
ステップＳ６ｃ（図４、５、６、および７ではステップＳ６として表される）では、前にステップＳ６で入力された値に加えて、セッションによって導出されたルックアップ・インデックスによってルックアップされる鍵Ｋ＿ＳＳＵも入力される。ナンスＮ＿Ｔｔの高い度合のランダムさに起因して、鍵Ｋ＿ＳＳＵを複数回使用することができる。クライアント・アプリケーションが、セキュア・セッション・プロトコル確立メッセージ（具体的にはＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージ）内で通常のメッセージより長い暗号文をトランスポートすることを許容しない場合には、「トランザクション認証番号（ＴＡＮ）なしの実施形態」に基づくもう１つの実施形態があり、上記は、次のステップによって拡張される。
【０１４１】
ステップＳ６ａは、上で説明したままである。ナンスＮ＿Ｔｔのランダムさが利用可能ではないので、鍵Ｋ＿ＳＳＵは１回しか使用することができない。ステップＳ６ｂ’（ステップＳ６ｂを置換する）では、サーバ４が、これまでに使用されたすべてのルックアップを記録する。衝突がある場合には、再ハンドシェークがサーバ４によってトリガされる。これは、未使用のインデックスに達するまで繰り返される。「ＤｉｓｔｉｎｇｕｉｓｈｅｄＮａｍｅ ｃｅｒｔｉｆｉｃａｔｅ＿ａｕｔｈｏｒｉｔｉｅｓ」手法は、この場合により効率的になる可能性がある。あるレベルの使用の後に、新しいアクセス・カードが、帯域外で配布される。
【０１４２】
ステップＳ６ｃ’（ステップＳ６ｃを置換する）で、暗号ハッシュが、ナンスなしで秘密の鍵Ｋ＿Ｔの代わりに生成され、鍵Ｋ＿ＳＳＵが使用される。次に、やはり、後続ステップは、ステップＳ１５まで残る。ステップＳ１５で、鍵Ｋ＿ＳＳＵが短いので、暗号ハッシュ関数は、有効な暗号ハッシュＮ＿ＳＳＵ＝ＣＨ＿｛Ｋ＿ＳＳＵ｝（ｈａｓｈ，ＰＩＮ＿Ｕ）を個人識別コードＰＩＮ＿Ｕおよび鍵Ｋ＿ＳＳＵの１つの対ではなく、個人識別コードＰＩＮ＿Ｕおよび鍵Ｋ＿ＳＳＵの多数の対（個人識別コードＰＩＮ＿Ｕと鍵Ｋ＿ＳＳＵとの両方の組み合わされた「鍵空間」のサイズまで）によって得ることができるようになっていることが重要である。これによって、攻撃者は、推測攻撃で正しい個人識別コードＰＩＮ＿Ｕを見つけたかどうかを知るのではなく、推測を妥当性検査するために必ずサーバ４に暗号ハッシュＮ＿ＳＳＵを提示しなければならない。また、このハッシュは、通常は４０バイト長なので、推測辞書は、この組み合わされた鍵よりはるかに長くする必要があり、セッションを認証にバインドすることに加えて、ここで、ハッシュは「塩」として働く。この鍵空間が十分なエントロピを有し、推測攻撃が通常のサーバ側ログイン・タイムアウトより長い時間を要するようになっている場合に、これは、ローエンド解決策として働くことができる。
【０１４３】
個人識別コードＰＩＮ＿Ｕに対するキー・ロギング攻撃（ｋｅｙ ｌｏｇｇｉｎｇ ａｔｔａｃｋ）を防ぐために、個人識別コードＰＩＮ＿Ｕおよび鍵Ｋ＿ＳＳＵを端末に別々に入力するのではなく、その組合せを入力することができる。
【０１４４】
同様に、鍵Ｋ＿ＳＳＵを、トランザクション認証番号ＴＡＮに基づく上で説明した主実施形態および他の実施形態と共に使用することもできる。
【図面の簡単な説明】
【０１４５】
【図１】ユーザ認証モジュールを備え、認証モジュールを有する通信端末に遠隔通信ネットワークを介して接続された、コンピュータ化されたサーバの例示的構成を概略的に示すブロック図である。
【図２】認証モジュールの例示的構成を概略的に示すブロック図である。
【図３】認証トークン・デバイスとしての認証モジュールの例示的実施を概略的に示すブロック図である。
【図４】遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証する、本発明の実施形態に従って実行されるステップのシーケンスの例を示す流れ図である（「通信端末で入力されるＰＩＮ＿Ｕおよび端末で作成されるＴＡＮ」）。
【図５】ユーザを認証する、本発明のもう１つの実施形態に従って実行されるステップのシーケンスの例を示す流れ図である（「デバイスで入力されるＰＩＮ＿Ｕおよびデバイスで作成されるＴＡＮ」）。
【図６】ユーザを認証する、本発明のもう１つの実施形態に従って実行されるステップのシーケンスの例を示す流れ図である（「ユーザによって心の中で作成されるＴＡＮ」）。
【図７】ユーザを認証する、本発明のもう１つの実施形態に従って実行されるステップのシーケンスの例を示す流れ図である（「ソフトトークン」）。
【図８】通信端末を使用するユーザによって遠隔通信ネットワークを介してアクセスされるサーバを認証する、本発明の実施形態に従って実行されるステップの追加のシーケンスの例を示す流れ図である（「デバイス上のサーバ認証コード」）。
【図９】サーバを認証する、本発明のもう１つの実施形態に従って実行されるステップの追加のシーケンスの例を示す流れ図である（「ソフト・トークン・デバイスによるサーバ認証コード」）。
【図１０】ユーザを認証する、本発明のもう１つの実施形態に従って実行されるステップのシーケンスの例を示す流れ図である（「標準デバイス・インターフェースに基づくチャレンジ・レスポンス」）。
【技術分野】
【０００１】
本発明は、サーバにアクセスするユーザを認証する方法およびデバイスに関する。具体的に言うと、本発明は、遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証する方法、コンピュータ・プログラム製品、およびコンピュータ化されたサーバに関する。
【背景技術】
【０００２】
インターネット上でのログイン機構に対する攻撃の洗練は、すばやく発達しつつある。銀行などの機関は、速いペースで、ますます高くなるコストで、一部はチャレンジ−レスポンス機構さえ含む、ツー・ファクタ認証（ｔｗｏ−ｆａｃｔｏｒ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）デバイスを展開しつつある。中間者（ＭＩＴＭ）攻撃は、インターネット・バンキングなど、すべてのＳＳＬ／ＴＬＳベースのオンライン・アプリケーションに深刻な脅威を与える。これに対する一般的な回答は、オリジナルのＳｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ（ＳＳＬ）プロトコル（米国特許第５，６５７，３９０号）またはＴｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ）プロトコル標準規格（Ｄｉｅｒｋｓ，Ｔ．およびＣ．Ａｌｌｅｎ、「Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．０」、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ２２４６、１９９９年１月）によって要求されるものなどのクライアント証明書ベースの相互認証を使用することである。しかし、会社の影響の厳しく制御された領域を超えて、この手法は、設計者が予想したほどに広範囲に受け入れられてはいない。
【０００３】
米国特許第４，４０５，８２９号、米国特許第４，７２０，８６０号、米国特許第４，８８５，７７８号、および米国特許第４，８５６，０６２号は、一般にＳｅｃｕｒＩＤトークンと称する認証トークン・デバイスに関する。このトークン・デバイスは、強いユーザ認証を提供するが、リアルタイムで動作するＭＩＴＭ攻撃に対して保護はしない。
【０００４】
米国特許出願第２００４／００６４６８７号には、オンライン・サードパーティすなわち「アイデンティティ・プロバイダ」によってＭＩＴＭ攻撃を防ぐ方法が記載されている。説明された方法は、ＳＳＬ／ＴＬＳプロトコルに対する変更を必要とせず、完全な公開鍵インフラストラクチャ（ＰＫＩ）の展開をも必要としない。しかし、この方法は、クライアントを変更し、アイデンティティ・プロバイダのハードコーディングされた証明書をクライアントに含めることを必要とする。
【０００５】
米国特許出願第２００２／１０７７９８ Ａ１号に、セキュリティ・デバイスに対してスマート・カードを認証する方法が記載されている。説明された方法は、チップ・カードがプロトコルの開始の前にセキュリティ・デバイスの公開鍵を所有し、（クライアント）アプリケーションがこの公開鍵だけを使用することに限定されるという仮定に基づく。しかし、この仮定は、一般的に行うことができない。
【０００６】
【特許文献１】米国特許第５，６５７，３９０号
【非特許文献１】Ｄｉｅｒｋｓ，Ｔ．およびＣ．Ａｌｌｅｎ、「Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．０」、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ２２４６、１９９９年１月
【特許文献２】米国特許第４，４０５，８２９号
【特許文献３】米国特許第４，７２０，８６０号
【特許文献４】米国特許第４，８８５，７７８号
【特許文献５】米国特許第４，８５６，０６２号
【特許文献６】米国特許出願第２００４／００６４６８７号
【特許文献７】米国特許出願第２００２／１０７７９８ Ａ１号
【非特許文献２】「ＰＫＣＳ ＃１１：Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｔｏｋｅｎ Ｉｎｔｅｒｆａｃｅ Ｓｔａｎｄａｒｄ」、ＲＳＡ Ｓｅｃｕｒｉｔｙ Ｉｎｃ．
【非特許文献３】ｈｔｔｐ：／／ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｌｉｂｒａｒｙ／ｄｅｆａｕｌｔ．ａｓｐ？ｕｒｌ＝／ｌｉｂｒａｒｙ／ｅｎ−ｕｓ／ｓｅｃｃｒｙｐｔｏ／ｓｅｃｕｒｉｔｙ／ｃｒｙｐｔｏｇｒａｐｈｙ＿＿ｃｒｙｐｔｏａｐｉ＿＿ａｎｄ＿ｃａｐｉｃｏｍ．ａｓｐ
【非特許文献４】Ｋｒａｗｃｚｙｋ，Ｈ．，他、「ＨＭＡＣ：Ｋｅｙｅｄ−Ｈａｓｈｉｎｇ ｆｏｒ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ２１０４、１９９７年２月
【非特許文献５】Ｍｏｌｖａ，Ｒ．およびＧ．Ｔｓｕｄｉｋ、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍｅｔｈｏｄ ｗｉｔｈ Ｉｍｐｅｒｓｏｎａｌ Ｔｏｋｅｎ Ｃａｒｄｓ」、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＩＥＥＥ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｒｅｓｅａｒｃｈ ｉｎ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ、ＩＥＥＥ Ｐｒｅｓｓ、１９９３年５月
【非特許文献６】Ｌａｍｐｏｒｔ，Ｌ．、「Ｐａｓｓｗｏｒｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｗｉｔｈ Ｉｎｓｅｃｕｒｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ」、Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｏｆ ｔｈｅ ＡＣＭ、Ｖｏｌ．２４、１９８１年、７７０〜７７２頁
【非特許文献７】ｈｔｔｐ：／／ｗｗｗ．ｒｓａｓｅｃｕｒｉｔｙ．ｃｏｍ／
【非特許文献８】ｈｔｔｐ：／／ｗｗｗ．ｒｆｃ．ｎｅｔ／ｒｆｃ２２４６．ｈｔｍｌ＃ｓ７．４．４
【非特許文献９】ｈｔｔｐ：／／ｗｗｗ．ｅｍｖｃｏ．ｃｏｍ
【非特許文献１０】ｈｔｔｐ：／／ａｘｓｉｏｎｉｃｓ．ｃｈ
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明の目的は、遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証する方法およびデバイスを提供することである。具体的に言うと、本発明の目的は、リアルタイムで動作するＭＩＴＭ攻撃に対して保護するユーザ認証の方法およびデバイスを提供することである。本発明のもう１つの目的は、セキュア・セッション確立プロトコルを用いて確立されたセキュア・セッションを使用して、遠隔通信ネットワークを介してサーバにアクセスするユーザを認証する方法およびデバイスを提供することである。
【課題を解決するための手段】
【０００８】
本発明によれば、これらの目的は、特に、独立請求項の特徴を介して達成される。それに加えて、さらなる有利な実施形態が、従属請求項およびこの説明から得られる。
【０００９】
本発明によれば、上で述べた目的は、特に、遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証するために、個人識別コードが、ユーザから受け取られ、データ・セットが、通信端末とサーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージから生成され、トランザクション認証番号が、個人識別コードを使用してデータ・セットに基づいて生成され、トランザクション認証番号が、通信端末からサーバに送信され、サーバ内で、トランザクション認証番号が（したがって、ユーザが）、通信端末と交換されたセキュア・セッション確立プロトコル・メッセージに基づいて検証されるという点で達成される。たとえば、データ・セットは、交換されるセキュア・セッション確立プロトコル・メッセージからハッシュ値として通信端末内で生成される。本明細書で説明するトランザクション認証番号が、本発明の文脈でセッション認証番号またはセッション認証コードとして使用され、いくつかの実施形態で、トランザクション認証番号が、ディジタル・データ・セットすなわちディジタル・トランザクション認証番号によって表されることを強調しなければならない。個人識別コードおよび通信端末とサーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージに基づくトランザクション認証番号の生成は、リアルタイム中間者攻撃に対してオンライン・ユーザを効率的に保護する、セッションを意識したユーザ認証を可能にする。
【００１０】
一実施形態では、通信端末に関連する認証モジュール内および／または通信端末内で、認証ベース番号が、データ・セットから生成され、トランザクション認証番号が、個人識別コードを使用して認証ベース番号から生成される。たとえば、認証ベース番号は、通信端末に関連する認証モジュール内で生成される。さらに、サーバ内で、認証ベース番号が、交換されたセキュア・セッション確立プロトコル・メッセージから生成され、トランザクション認証番号が、サーバ内で生成された認証ベース番号および個人識別コードを使用してサーバ内で検証される。
【００１１】
好ましい実施形態では、認証ベース番号および個人識別コードが、通信端末に接続されないチャレンジ／レスポンス（Ｃ／Ｒ）トークン・デバイスに（ユーザによって）入力される。トランザクション認証番号が、認証ベース番号および個人識別コードに基づいてトークン・レスポンス値としてチャレンジ／レスポンス・トークン・デバイス内で生成される。トランザクション認証番号すなわちトークン・レスポンス値は、トランザクション認証番号をサーバに送信する前に、通信端末に（ユーザによって）入力される。
一実施形態で、認証ベース番号は、乱数を生成することと、選択された桁をデータ・セットから選択することであって、桁が乱数の桁によって決定される、選択することと、選択された桁および乱数の桁から認証ベース番号を合成することとによって、データ・セットから生成される。
【００１２】
一実施形態で、ディジタル署名は、認証モジュールに関連する鍵対の秘密鍵を使用してデータ・セットから生成され、認証モジュール内で、認証ベース番号は、認証モジュールに関連する秘密トークン鍵を使用してデータ・セットから生成され、トランザクション認証番号は、認証ベース番号から生成され、個人識別コードは、ディジタル署名を生成する際またはトランザクション認証番号を生成する際に使用され、ディジタル署名は、通信端末からサーバに送信され、サーバ内で、ディジタル署名は、鍵対の公開鍵を使用して検証され、トランザクション認証番号は、通信端末からサーバに送信され、サーバ内で、認証ベース番号は、データ・セットを暗号化する秘密トークン鍵を使用して、通信端末から受信されたデータ・セットから生成され、サーバ内で、トランザクション認証番号は、サーバ内で生成された認証ベース番号を使用して検証される。
【００１３】
一実施形態で、トランザクション認証番号は、認証ベース番号および個人識別コードから生成される。トランザクション認証番号およびユーザ識別子は、通信端末からサーバに送信される。トランザクション認証番号は、サーバ内で生成された認証ベース番号およびユーザ識別子に割り当てられた個人識別コードを使用してサーバ内で検証される。
【００１４】
一実施形態で、認証モジュールは、通信端末に取り外し可能に接続可能な認証トークン・デバイスとして実施される。データ・セットは、認証モジュールを通信端末に接続するデバイス・インターフェースを介して通信端末から認証モジュールに転送される。適用可能な場合に、鍵対および秘密トークン鍵は、認証モジュールに格納され、ディジタル署名は、認証モジュールから通信端末へデバイス・インターフェースを介して転送される。
さらなる実施形態で、トークン識別子は、通信端末からサーバへトランザクション認証番号と一緒に送信され、秘密トークン鍵は、トークン識別子に基づいてサーバ内で判定される。マスタ鍵は、サーバに格納され、秘密トークン鍵は、サーバ内で、トークン識別子を暗号化するためにマスタ鍵を使用してトークン識別子から生成される。
【００１５】
一実施形態で、認証ベース番号は、認証モジュールから通信端末に転送される。個人識別コードは、通信端末内でユーザから受け取られ、トランザクション認証番号は、通信端末内で、認証ベース番号および個人識別コードから生成される。
【００１６】
もう１つの実施形態で、個人識別コードは、認証モジュール内でユーザから受け取られる。トランザクション認証番号は、認証モジュール内で、認証ベース番号および個人識別コードから生成され、トランザクション認証番号は、認証モジュールから通信端末に転送される。
【００１７】
もう１つの実施形態で、個人識別コードは、バイオメトリック識別子と一緒にユーザから受け取られる。トランザクション認証番号は、サーバ内で生成された認証ベース番号およびサーバに格納されたバイオメトリック識別子ならびにユーザ識別子に割り当てられた個人識別コードを使用してサーバ内で検証される。
【００１８】
もう１つの実施形態で、認証ベース番号は、認証モジュールによって表示される。トランザクション認証番号は、個人識別コードおよび認証モジュールによって表示された認証ベース番号によってユーザによって生成され、ユーザによって通信端末に入力される。
【００１９】
もう１つの実施形態で、サーバ内でのトランザクション認証番号の成功の検証の後に、サーバ認証コードが、サーバ内で、データ・セットに公開関数を適用し、暗号化に秘密トークン鍵を使用して、データ・セットから生成される。サーバ認証コードは、サーバから通信端末に送信される。サーバ認証コードが、認証モジュール内で、データ・セットに公開関数を適用し、暗号化に秘密トークン鍵を使用して、データ・セットから生成される。認証モジュールは、認証モジュール内で生成されたサーバ認証コードに基づいて、サーバからのサーバ認証コードを検証する。一実施形態で、サーバ認証コードは、サーバから受信され、認証モジュール内で生成されたサーバ認証コードは、ユーザによる視覚的検証のために認証モジュールによって表示される。
【００２０】
追加の実施形態で、ユーザは、認証モジュールの複数の可能な機関スコープのうちの１つを選択する。ユーザによって選択された機関スコープは、認証モジュールに、認証ベース番号を生成するための複数の秘密トークン鍵の組のうちの１つの機関固有秘密トークン鍵を使用させる。サーバは、特定の機関に関連し、認証ベース番号を生成するのに機関固有秘密トークン鍵を使用する。サーバは、トランザクション認証番号を検証するのに機関固有個人識別コードを使用する。
【００２１】
提案されるユーザ認証方法は、何らかの形で同期化されなければならないクロックを必要としない。そうではなく、この方法は、通信端末とサーバとの間で交換されるセキュア・セッション確立プロトコル・メッセージ（たとえば、ＳＳＬ／ＴＬＳ）から導出されるナンス（たとえば、そのハッシュ値）を使用して、トランザクション認証番号の通用を保証する。
【００２２】
さらに、提案される方法のセキュリティは、ユーザ識別子が、およびユーザが特定の転送可能トークンを使用する時間期間の間にトークン識別子も、たとえばブラウザのフォーム・プリ・フィル（ｆｏｒｍ−ｐｒｅ−ｆｉｌｌ）機能によって、通信端末に格納される場合に、特に傷つけられない。特に、通信端末が、共有されるワークステーションである場合に、これは、他の当事者およびおそらくは敵対者がこれら２つの値を知ることにつながる可能性があるが、提案される方法は、これに耐える。
【００２３】
クライアント側ＳＳＬ／ＴＬＳ実施態様のほとんど遍在する基礎を変更する必要はない。ほとんどの実施形態について、ＳＳＬ／ＴＬＳスタックを使用するウェブ・ブラウザなどのクライアント・アプリケーションも、変更する必要がない。
【００２４】
認証されたセキュア・セッション・ブートストラッピングを動作させることは、セキュリティの知識がないエンド・ユーザにとって、現在広く展開されているツー・ファクタ解決策より複雑ではない。
【００２５】
エンド・ユーザ登録または他の高価なプロセスは、このＭＩＴＭに耐える手法を実施するのに必要ではない。ツー・ファクタ解決策を実行する機関は、エンド・ユーザが使用しているデバイスを交換するだけでよく（しかし、エンド・ユーザが使用するＰＩＮまたはパスワードは変更されないままである）、あるいは、その中で実施されるアルゴリズムおよびプロトコルを変更し（既知のファームウェア更新に類似する）、それ自体のサーバ・インフラストラクチャを提案される方法と共に働くように適合させるだけでよい。
【００２６】
本発明のもう１つの目的によれば、遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザが個人識別コードを変更するために、古い個人識別コードおよび新しい個人識別コードが、ユーザから受け取られ、データ・セットが、通信端末とサーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージから生成され、通信端末に関連する認証モジュール内で、認証ベース番号が、認証モジュールに関連する秘密トークン鍵を使用して、データ・セットから生成され、識別変更コードが、認証ベース番号、古い個人識別コード、および新しい個人識別コードから生成され、識別変更コードが、通信端末からサーバに送信され、サーバ内で、認証ベース番号が、秘密トークン鍵を使用して、交換されたセキュア・セッション確立プロトコル・メッセージから生成され、サーバ内で、新しい個人識別コードが、古い個人識別コードおよびサーバ内で生成された認証ベース番号を使用して、識別変更コードから導出される。
【００２７】
遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザの認証のもう１つの実施形態では、トランザクション認証番号が、通信端末に関連する認証モジュール内で、個人識別コードからおよび通信端末とサーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージから、鍵としてサーバと共有される秘密を使用して、鍵付き暗号ダイジェスト値として生成される。鍵付き暗号ダイジェスト値は、トランザクション認証番号として通信端末からサーバに送信される。サーバ内で、鍵付き暗号ダイジェスト値が、サーバに格納された個人識別コードを使用して生成される。その後、サーバ内で、トランザクション認証番号が、したがってユーザの真正性が、通信端末から受信された鍵付き暗号ダイジェスト値とサーバ内で生成された鍵付き暗号ダイジェスト値との比較に基づいて検証される。たとえば、認証モジュールに関連する個人識別コードまたは秘密トークン鍵が、鍵として使用される。鍵付き暗号ダイジェスト値は、鍵付き暗号ダイジェスト関数すなわち、暗号ハッシュ関数などの擬似乱数関数を使用して生成される。代替実施形態では、ルックアップ・インデックスが、データ・セットから生成され、コード・テーブル（たとえば、鍵リスト）内で、ルックアップ・インデックスを使用して、選択されたコードが判定される。選択されたコードは、（ハッシュ）鍵として使用され、サーバは、サーバに格納されたコード・テーブルからの選択されたコードを（ハッシュ）鍵として使用して、鍵付き暗号ダイジェスト値を生成する。副実施形態では、サーバは、通信端末によって使用される以前に選択されたコードを追跡し、サーバは、選択されたコードが以前に通信端末によって使用されたとサーバが判定する場合に、通信端末とのセッション確立を再開始する。
【００２８】
遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザの認証のもう１つの実施形態では、トランザクション認証番号は、通信端末に関連する認証モジュール内で、公開鍵を使用してデータ・セット、個人識別コード、およびナンスを暗号化することによって、暗号文として生成される。暗号文は、トランザクション認証番号として通信端末からサーバに送信される。サーバ内で、秘密鍵を使用して暗号文を暗号化解除することによって、データ・セットおよび個人識別コードが判定される。その後、サーバ内で、暗号化解除されたトランザクション認証番号が、したがってユーザの真正性が、セキュア・セッション確立プロトコル・メッセージからサーバ内で生成されたデータ・セットとの受信されたデータ・セットの比較およびサーバに格納された個人識別コードとの個人識別コードの比較に基づいて検証される。
【００２９】
一実施形態で、ルックアップ・インデックスが、データ・セットから生成され、コード・テーブル（たとえば、鍵リスト）内で、ルックアップ・インデックスを使用して、選択されたコードが判定される。選択されたコードは、さらに、暗号文を生成するのに使用される。サーバは、秘密鍵を使用して、選択されたコードを暗号文から判定する。トランザクション認証番号は、したがってユーザの真正性は、選択されたコードをサーバに格納されたコード・テーブルからサーバによって判定された選択されたコードと比較することによって検証される。副実施形態で、サーバは、通信端末によって使用される選択されたコードを追跡し、サーバは、選択されたコードが通信端末によって以前に使用されたとサーバが判定する場合に、通信端末とのセッション確立を再開始する。
【００３０】
本発明の追加の目的によれば、遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証するために、データ・セットが、通信端末とサーバとの間で交換されるセキュア・セッション確立プロトコル・メッセージから生成され、通信端末内で、認証暗号文が、データ・セット、個人識別コード、および１つまたは２つのナンスから生成される。事前定義の公開鍵が、暗号化に使用される。この鍵は、サーバまたは複数機関の場合に認証サーバのいずれかに属する。結果の暗号文は、通信端末からサーバへ通常のプロトコル・メッセージの内部で不透明に送信され、サーバ内で、データ・セットは、交換されたセキュア・セッション確立プロトコル・メッセージから生成され、サーバ内で、暗号文は、対応する秘密鍵を使用して暗号化解除される。サーバ・データベースから取り出され、暗号文から暗号化解除された個人識別コードが、比較され、暗号化解除されたデータ・セットが、サーバが計算したデータ・セットと比較される。ユーザが、サーバからユーザへの認証を望む場合に、第２のナンスも、暗号文から暗号化解除され、ユーザに送り返される。この手法は、個人識別コードを変更するのにも使用することができる。
【００３１】
本発明の追加の目的によれば、遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証するために、データ・セットが、通信端末とサーバとの間で交換されるセキュア・セッション確立プロトコル・メッセージから生成され、通信端末内で、インデックスが、帯域外で配信されるコード・テーブル（たとえば、鍵リスト）から短い鍵をルックアップするために、サーバから受信されるか、作成される。短い鍵および個人識別コードが、通信端末に入力され、暗号文であれ鍵付き暗号ダイジェスト値であれ、認証符号が、データ・セット、個人識別コード、短い鍵、および２つまでのナンスに基づいて生成される。認証符号は、通信端末からサーバに送信され、サーバ内で、データ・セットが、交換されたセキュア・セッション確立プロトコル・メッセージから生成され、サーバ内で、認証符号が、サーバ内で生成されたデータ・セット、個人識別コード、およびサーバ・データベース内の短い鍵を使用して、暗号化解除によってまたはたとえば暗号ハッシュ化によるなど、鍵付き暗号ダイジェスト関数を使用することによって、検証される。同様に、その短い鍵を、既に説明した他の実施形態と共に使用することもできる。
本発明を、図面を参照して例としてより詳細に説明する。
【発明を実施するための最良の形態】
【００３２】
図１では、符号１が、遠隔通信ネットワーク３を介するコンピュータ化されたサーバ４とのデータ交換のために構成された通信端末を指す。通信端末１は、固定されたパーソナル・コンピュータ（ＰＣ）、可動のラップトップ・コンピュータ、可動の無線電話機、および／または可動の携帯情報端末（ＰＤＡ）を含むが、これらに限定はされない。通信端末１のそれぞれは、ディスプレイ１１と、キーボードおよびたとえばコンピュータ・マウス、トラック・ボール、または類似物などのポインティング・デバイスなどのデータ入力手段１２とを有する。通信端末１は、遠隔通信ネットワーク３を介して、ＳＳＬ／ＴＬＳなどのセキュア・セッション確立プロトコルを用いて確立されたセキュア・セッションを介してサーバ４上でホスティングされるオンライン・アプリケーションにアクセスするクライアント・アプリケーション、好ましくはブラウザ（たとえば、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ ＥｘｐｌｏｒｅｒまたはＭｏｚｉｌｌａ Ｆｉｒｅｆｏｘ）を含む。さらに、通信端末１は、後で図２および３を参照してより詳細に説明する認証モジュール２を含む。
【００３３】
遠隔通信ネットワーク３は、固定ネットワークおよび無線ネットワークを含む。たとえば、遠隔通信ネットワーク３は、ローカル・エリア・ネットワーク（ＬＡＮ）、サービス統合ディジタル網（ＩＳＤＮ）、インターネット、ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ（ＧＳＭ）、ｕｎｉｖｅｒｓａｌ ｍｏｂｉｌｅ ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｓｙｓｔｅｍ（ＵＭＴＳ）、または別の地上もしくは衛星ベースのモバイル無線電話システム、ならびに／あるいは無線ローカル・エリア・ネットワーク（ＷＬＡＮ）を含む。
【００３４】
コンピュータ化されたサーバ４は、１つまたは複数のコンピュータを含み、各コンピュータは、１つまたは複数のプロセッサ、プログラム・メモリ、データ・メモリ、ならびにオペレーティング・システムおよびＳＳＬ／ＴＬＳなどのセキュア・セッション確立プロトコルを用いて確立されたセキュア・セッションを介して遠隔通信端末１からアクセス可能なオンライン・アプリケーションを有する。たとえば、サーバ４は、Ａｐａｃｈｅ ｈｔｔｐｄサーバまたはＪａｋａｒｔａ Ｔｏｍｃａｔサーバである。さらに、サーバ４は、ユーザ認証モジュール４０およびデータベース４１を含む。好ましくは、ユーザ認証モジュール４０およびデータベース４１は、プログラムされたソフトウェア・モジュールとして実施される。データベース４１は、たとえば、マスタ鍵（ＭＫ）４２、ユーザ・データ４００の複数の組を含むことができ、ユーザ・データ４００のそれぞれは、ユーザ識別子（ＩＤ＿Ｕ）４３、個人識別コード（ＰＩＮ＿Ｕ）４４、およびおそらくは対称秘密トークン鍵（Ｋ＿Ｔ）４５を含む。個人識別コード（ＰＩＮ＿Ｕ）４４は、ユーザとサーバ４との間で共有される秘密であり、バイオメトリック・データ（バイオメトリック識別子）を含むことができる。さらに、データベース４１は、公開鍵（ｋ）４６を含むことができる。公開鍵（ｋ）４６を含む証明書は、ユーザ・データ・セット４００のユーザ固有部分とすることもできる、すなわち、その通し番号（ＳＮ＿Ｔ）を、特定のユーザが特定のトークンを使用する時間の間にＩＤ＿Ｕを用いて割り当てることができる。ユーザは、サーバが最後のＳＮ＿Ｔ−ＩＤ＿Ｕ関連付けを記憶しなければならないか否かを選択できなければならない。それを行うことによって、ユーザがトークンをさまざまな通信端末に挿入する場合であっても便宜が提供される。その一方で、この場合にトークンを紛失することは、ＩＤ＿Ｕをそのトークンの次のユーザに開示する可能性があり、これは認証を脅かしはしないが、サーバに関するユーザのプライバシに影響する。
【００３５】
図２に示されているように、各認証モジュール２は、複数の機能モジュールすなわち、証明モジュール２５、認証番号ジェネレータ２６、ディスプレイ・モジュール２７、ならびにおそらくはサーバ認証モジュール２８および／または選択モジュール２９を含む。さらに、認証モジュール２は、好ましくは完全性保護される（ｉｎｔｅｇｒｉｔｙ ｐｒｏｔｅｃｔｅｄ）秘密鍵（ｋ＾｛−１｝）および公開鍵（ｋ）を含む、非対称鍵対（ｋ，ｋ＾｛−１｝）２０１を有するメモリ・モジュールを含むことができる。識別のために、認証モジュール２を、公に知られたトークン識別子ＳＮ＿Ｔに関連付けることができる。好ましくは、認証モジュール２は、非人格的であり、ＰＫＳＣ＃１１またはＭＳ−ＣＡＰＩ（Ｍｉｃｒｏｓｏｆｔ Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）または別の標準デバイス・インターフェースに準拠する。一実施形態で、認証モジュール２は、トークン識別子２０３を有するメモリ・モジュールを含む。トークン識別子は、たとえばブラウザのフォーム・プリ・フィル機能によって、通信端末１に格納することもできる。さらに、認証モジュール２は、秘密トークン鍵（Ｋ＿Ｔ）２０２を有するセキュア・メモリ・モジュールまたはより好ましくない事例でマスタ鍵（ＭＫ）２０４を有するメモリ・モジュールのいずれかを含む。鍵対ｋおよびｋ＾｛−１｝は、すべての認証モジュール２について同一とすることができる（トークンを非人格的とすることができる理由）が、秘密トークン鍵Ｋ＿Ｔは、一意であり、１つの認証モジュール２に固有である。秘密トークン鍵Ｋ＿Ｔは、次式に従って、マスタ鍵ＭＫを使用してトークン識別子ＳＮ＿Ｔから生成することができる。
Ｋ＿Ｔ＝Ｅ＿｛ＭＫ｝（ＳＮ＿Ｔ）
【００３６】
その結果、中央ですべての秘密トークン鍵を格納する必要はない。そうではなく、秘密トークン鍵は、マスタ鍵を知っている誰もがトークン識別子から動的に生成することができる。マスタ鍵は、通常、サーバ４のみによって所有され、保持される。マスタ鍵またはむしろ秘密トークン鍵は、エクスポート不能な形でタンパプルーフ鍵ストア内に保持される。トークン秘密鍵ｋ＾｛−１｝も、同一のセキュア・ストレージによって保持されるが、公に開示されるようになる後者が、それでも、提案される方法に従って発行される認証モジュール２の母集団およびその機能を危険にさらさないようにすることができることが推奨される。
【００３７】
好ましくは、機能モジュールは、プログラムされたソフトウェア・モジュールとして実施される。このソフトウェア・モジュールのコンピュータ・プログラム・コードは、コンピュータ・プログラム製品の一部であり、好ましくは、通信端末１に挿入できるデータ・キャリア上、通信端末１内に一体化されたメモリ内、または通信端末１に接続された、図３に示された認証トークン・デバイス２０に一体化されたメモリ内のいずれかの、コンピュータ可読媒体に格納される。
【００３８】
一実施形態で、認証モジュール２は、ＰＫＳＣ＃１１に準拠する、おそらくは非人格的な認証トークン・デバイス２０として実施される。したがって、認証モジュール２は、Ｃｒｙｐｔｏｋｉ（「ＰＫＣＳ ＃１１：Ｃｒｙｐｔｏｇｒａｐｈｉｃ Ｔｏｋｅｎ Ｉｎｔｅｒｆａｃｅ Ｓｔａｎｄａｒｄ」、ＲＳＡ Ｓｅｃｕｒｉｔｙ Ｉｎｃ．）またはＭｉｃｒｏｓｏｆｔ ＣｒｙｐｔｏＡＰＩ（ｈｔｔｐ：／／ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｌｉｂｒａｒｙ／ｄｅｆａｕｌｔ．ａｓｐ？ｕｒｌ＝／ｌｉｂｒａｒｙ／ｅｎ−ｕｓ／ｓｅｃｃｒｙｐｔｏ／ｓｅｃｕｒｉｔｙ／ｃｒｙｐｔｏｇｒａｐｈｙ＿＿ｃｒｙｐｔｏａｐｉ＿＿ａｎｄ＿ｃａｐｉｃｏｍ．ａｓｐ）などの標準インターフェースを介して、セキュア・セッション確立プロトコル、たとえばＳＳＬ／ＴＬＳハンドシェークに参加するセキュア・ハードウェア・トークンである。図３に示されているように、認証モジュール２の文脈で上で説明した機能モジュールおよびメモリ・モジュールに加えて、認証トークン・デバイス２０は、デバイス・インターフェース２１、データ入力キー２３またはセンサ２４の形のデータ入力手段、およびおそらくはディスプレイ２２を含む。任意選択で、センサ２４は、バイオメトリック・データ（バイオメトリック識別子）の入力用に構成され、たとえば指紋リーダーを含む。デバイス・インターフェース２１は、認証トークン・デバイス２０を通信端末１に取り外し可能に接続するために構成される。デバイス・インターフェース２１は、たとえばＵＳＢインターフェース（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）を含む接点ベースまたはたとえばＢｌｕｅｔｏｏｔｈもしくはＩｒＤＡインターフェースを含む無接点である。認証モジュール２を、オフライン・デバイス（Ｃ／Ｒまたは使い捨てパスワード（ＯＴＰ））と、データ・セットまたは認証ベース番号からビットをランダムに選択するなどの機能によってクライアント・アプリケーション・ソフトウェアを補完する通信端末１内のソフトウェア・モジュールとの間で分割することもできる。
【００３９】
続く段落では、図４、５、６、７、８、９、および１０を参照して、提案されるユーザ認証方法を実行する可能なシーケンスならびにユーザ認証モジュール４０および機能モジュールの機能性を説明する。基本的な前提は、ユーザ・インフラストラクチャが、必ずしも信頼されるコンピュータ・ベースを実行していないことであるが、それでも、特にＳＳＬ／ＴＬＳ実施態様が、たとえばトロイの木馬実行可能ファイルによって打倒されず、したがって正しく動作していると仮定しなければならない。しかし、エンド・ユーザは、情報テクノロジにおいて特に技量を有するとは期待されず、たとえば、ＳＳＬ／ＴＬＳ保護されたセッション内でサーバ証明書の妥当性を完全にチェックできることは、期待されない。同様に、「ＵＢＳ．ＣＯＭ」と「Ｕ８Ｓ．ＣＯＭ」とを信頼できる形で区別できることは、期待されない。
【００４０】
サーバ４によってホスティングされるオンライン・アプリケーションにアクセスするために、ユーザは、そのユーザの通信端末１上のクライアント・アプリケーションに、それ相応に指示する。セキュア・セッション確立プロトコル、たとえばＳＳＬ／ＴＬＳハンドシェーク・プロトコルの一部として、サーバ４は、公開鍵証明書を使用してそれ自体を認証し、ユーザが、所期のサイトに実際に属するものとしてこの証明書を正しく検証はしないと仮定するが、これにはこれ以上対処しない。
【００４１】
図４に示されているように、ステップＳ１で、通信端末１は、セキュア・セッション確立プロトコルに従って、たとえばＳＳＬ／ＴＬＳに従ってサーバ４に「ＣｌｉｅｎｔＨｅｌｌｏ」メッセージを送信することによって、サーバ４とのセキュア・セッション確立を開始する。
【００４２】
ステップＳ２で、セキュア・セッション確立プロトコルに従って、サーバ４は、たとえばＳＳＬ／ＴＬＳに従って通信端末１に「ＳｅｒｖｅｒＨｅｌｌｏ」メッセージを送信することによって、ステップＳ１の開始メッセージに応答する。
【００４３】
ステップＳ３で、セキュア・セッション確立プロトコルの一部として、サーバ４は、通信端末１に証明書要求または「Ｆｉｎｉｓｈｅｄ」メッセージ、たとえばＳＳＬ／ＴＬＳに従う「ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔ」または「Ｆｉｎｉｓｈｅｄ」メッセージを送信する。
【００４４】
ステップＳ４で、セキュア・セッション確立プロトコルに従って、通信端末１のデータ・セット生成モジュールが、サーバ４と交換された、以前のセキュア・セッション確立プロトコル・メッセージに基づいてデータ・セットを作成する。たとえば、データ・セット生成モジュールは、ＳＳＬ／ＴＬＳに従ってハッシュ関数を適用することによって、以前のセキュア・セッション確立プロトコル・メッセージからデータ・セットを作成する（本明細書に明示的にリストされるものより多数の、交換されるセキュア・セッション確立プロトコル・メッセージが存在する可能性がある）。
【００４５】
ステップＳ５で、ステップＳ４で生成されたデータ・セット（たとえばハッシュ、以下では「ハッシュ」と呼ぶ）を、それぞれ認証モジュール２または認証トークン・デバイス２０に渡す。通信端末１とそれぞれ認証モジュール２または認証トークン・デバイス２０との間の情報の受渡しは、たとえば、通信端末１および／または認証トークン・デバイス２０内の共有メモリ・エリアを使用して、デバイス・インターフェース２１を介して達成することができる。
【００４６】
ステップＳ６で、証明モジュール２５が、鍵対２０１を有するメモリ・モジュールからの秘密鍵ｋ＾｛−１｝を使用して、ステップＳ５で受け取られたデータ・セットに暗号的に署名することによって、電子署名を生成する。変形形態では、公開署名妥当性検査鍵（ｋ）４６を含む署名に結び付けられた署名する証明書が、使用される特定のトークンの通し番号ＳＮ＿Ｔを含む。
【００４７】
ステップＳ７で、ステップＳ６で生成された電子署名を、通信端末１に渡す。
ステップＳ８で、通信端末１が、ステップＳ３で受け取られた証明要求に対する応答、たとえば、ステップＳ４で生成されたデータ・セットおよびステップＳ６で生成された電子署名を含む、ＳＳＬ／ＴＬＳに従う「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージを用意する。
【００４８】
ステップＳ９で、ステップＳ８で用意したセキュア・セッション確立プロトコル・メッセージが、通信端末１によってサーバ４に送信される。
【００４９】
ステップＳ１０で、公開鍵（ｋ）４６を使用して、サーバ４が、ステップＳ９で受け取ったデータ・セットを基礎として、ステップＳ９で受け取った電子署名を検証する。ｋ＾｛−１｝が通常はすべてのトークンについて同一なので、認証モジュール２が非人格的であるという事実に起因して、「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージは、実際にはクライアント・アプリケーションを認証しない。そうではなく、「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージは、トークンが、サーバへのセキュア・セッションを確立するのにクライアント・アプリケーションによって使用され、後の使用のためにデータ・セットを取り込むことだけを確実にする。ステップＳ４で生成されたデータ・セットが、「Ｆｉｎｉｓｈｅｄ」メッセージに基づく場合に、ステップＳ５〜Ｓ９は、必要ではなく、ステップＳ１０で、サーバ４は、後の使用のためにデータ・セット（ハッシュ）を取り込むのみである。この手法が使用されるのは、「Ｆｉｎｉｓｈｅｄ」メッセージの内容を点検できるクライアント拡張もしくはクライアント・プラグインまたは外部「スニッファ」があるか、「Ｆｉｎｉｓｈｅｄ」メッセージが既に暗号化されている場合である。好ましくは、そのような拡張は、小さく、プラットフォーム独立であり、したがって、クライアント・アプリケーションの内部にあるか、製造される時にクライアント・アプリケーションに一体化される。
【００５０】
ステップＳ１１で、認証番号ジェネレータ２６が、ステップＳ５で受け取ったデータ・セット（ハッシュ）から認証ベース番号Ｎ＿Ｔを生成する。認証ベース番号Ｎ＿Ｔは、認証モジュール２に関連する秘密トークン鍵Ｋ＿Ｔを使用して、データ・セットから生成される。
Ｎ＿Ｔ＝Ｅ＿｛Ｋ＿Ｔ｝（ｈａｓｈ）
【００５１】
好ましくは、Ｎ＿Ｔは、個人識別コードＰＩＮ＿Ｕの定義された長さに短縮される（一実施形態では、Ｎ＿Ｔを切り捨てることによって）。
【００５２】
ステップＳ１２で、サーバ４のユーザ認証モジュール４０が、通信端末にトランザクション認証番号（ＴＡＮ）を要求する。公開鍵４６がＳ６でトークン固有公開鍵証明書内にある場合には、ユーザ識別子ＩＤ＿Ｕを、たとえば所与のトークンＳＮ＿Ｔと共に使用される最も最近のＩＤ＿Ｕを反映する要求と一緒に送信することができる、すなわち、ＩＤ＿Ｕは、トークンが異なるユーザによって使用される場合に、ＨＴＭＬフォーム・フィールドに既にプリフィルされており、訂正される必要だけがあるので、ユーザによって入力される必要がない。
【００５３】
ステップＳ１３で、ステップＳ１１で生成された認証ベース番号Ｎ＿Ｔが、通信端末１に渡される。
【００５４】
ステップＳ１４で、通信端末１の制御モジュールが、ユーザに個人識別コードＰＩＮ＿Ｕを要求し、受け取る。実施形態に応じて、個人識別コードＰＩＮ＿Ｕは、データ入力手段１２またはバイオメトリック・データ（バイオメトリック識別子）用のセンサ、たとえば指紋リーダー（たとえば、異なる指の指紋が、異なる番号または文字を割り当てられる）を使用して入力される。
【００５５】
ステップＳ１５で、通信端末１の制御モジュールが、ステップ１４で受け取った個人識別コードＰＩＮ＿ＵおよびステップＳ１１で生成された認証ベース番号Ｎ＿Ｔから、たとえばユーザに透過的な形で擬似乱数関数ＰＲＦを使用して、トランザクション認証番号ＴＡＮを生成する。
ＴＡＮ＝ＰＲＦ＿｛ＰＩＮ＿Ｕ｝（Ｎ＿Ｔ）
【００５６】
副実施形態として、ＰＩＮを通信端末１によって受け取ることができ、Ｓ１５を、非人格的な認証トークン・デバイス２０上で実行することができ、その後、ＴＡＮを通信端末１に返すことができる。
【００５７】
この場合に、副実施形態として、「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージを生成するステップおよびトランザクション認証番号ＴＡＮを生成するステップを、異なってグループ化することができ、データ・セット（ハッシュ）を生成するのに使用される関数ｈが、暗号ハッシュ関数の特性を満足する場合には、たとえば、ＨＭＡＣコンストラクション（Ｋｒａｗｃｚｙｋ，Ｈ．，他、「ＨＭＡＣ：Ｋｅｙｅｄ−Ｈａｓｈｉｎｇ ｆｏｒ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ２１０４、１９９７年２月）を使用して、ハッシュ関数ｈを実施することができ、その場合に、ＰＩＮ＿Ｕは、データ・セット（ハッシュ’）のＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ計算への引数になる。この実施形態では、認証ベース番号Ｎ＿Ｔ’は、トランザクション認証番号になり、ＴＡＮ＝Ｎ＿Ｔ’である。この実施形態では、データ・セット（ハッシュ’）およびハッシュ関数ｈへの１つの入力すなわちＰＩＮ＿Ｕを除くすべての入力を有することから、ＰＩＮ＿Ｕを再構成することが実現可能でないことが必須である。ＨＭＡＣは、これを満足する１つの関数である。また、ＨＭＡＣは、擬似乱数関数ＰＲＦに使用され、トランザクション認証番号ＴＡＮを生成するのに使用される。
ＴＡＮ＝ＨＭＡＣ＿｛ＰＩＮ＿Ｕ｝（Ｎ＿Ｔ）＝ｈ（Ｋ＋ｏｐａｄ‖ｈ（Ｋ＋ｉｐａｄ‖Ｎ＿Ｔ））
【００５８】
この場合に、Ｋは、ある独自の指定された形で（たとえば、ＰＫＣＳ ＃５に従って）ＰＩＮ＿Ｕから導出される。記号＋は、加算の２を法とする剰余を指し、‖は、文字列連結を指す。ｏｐａｄおよびｉｐａｄは、定数値である。特に、ユーザがＴＡＮをユーザ自身で計算する必要がないときに、数字［０．．９］のみ以外のアルファベットが好ましい可能性がある。
【００５９】
トランザクション認証番号ＴＡＮは、正確に１つのセキュア（ＳＳＬ／ＴＬＳ）セッションについて有効である。
【００６０】
ステップＳ１６で、ステップＳ１２で受け取った要求に応答して、通信端末１が、生成されたＴＡＮ、ユーザによって確認されたか新たに入力されたユーザ識別子ＩＤ＿Ｕ、ならびにｋを含むトークン証明書がＳＮ＿Ｔをも含む（Ｓ６で任意選択）のでない限りユーザによって入力されたトークン識別子ＳＮ＿Ｔをサーバ４に送信する。ＳＮ＿Ｔは、たとえば、トークン識別子２０３を有するメモリ・モジュールから読み取られ、またはブラウザに関連する通信端末１内のメモリから読み取られる。
【００６１】
ステップＳ１７で、サーバ４のユーザ認証モジュール４０が、データベース４１内で、ステップＳ１６で受け取られたユーザ識別子ＩＤ＿Ｕに割り当てられた個人識別コード（ＰＩＮ＿Ｕ）４４を判定する。
【００６２】
ステップＳ１８で、認証モジュール２に関連する秘密トークン鍵Ｋ＿Ｔを使用して、ユーザ認証モジュール４０が、ステップＳ１０で受け取ったデータ・セット（ハッシュ）から認証ベース番号Ｎ＿Ｔを生成する。一実施形態で、秘密トークン鍵Ｋ＿Ｔは、ステップＳ１６で受け取ったトークン識別子ＳＮ＿Ｔから、マスタ鍵（ＭＫ）４２を使用して生成される。しかし、秘密トークン鍵（Ｋ＿Ｔ）４５がサーバ４上で格納される場合には、これをＭＫを用いて再計算する必要はなく、完全にランダムに選択することができる。トークン識別子ＳＮ＿Ｔが、セキュア・セッション確立プロトコルの途中で交換されるトークンのクライアント証明書、たとえばステップＳ３とＳ９との間の「クライアント証明書」メッセージの一部である場合に、ＳＮ＿Ｔは、ステップＳ１６で通信端末１からサーバ４には送信されない。
【００６３】
ステップＳ１９で、ユーザ認証モジュール４０は、ステップＳ１７で判定された個人識別コードＰＩＮ＿ＵおよびステップＳ１８で生成された認証ベース番号Ｎ＿Ｔから、トランザクション認証番号ＴＡＮを生成する。
【００６４】
ステップＳ２０で、ユーザ認証モジュール４０は、ステップＳ１９で生成されたトランザクション認証番号との比較を介して、ステップＳ１６で受け取ったトランザクション認証番号を検証する。肯定の検証の際に、通信端末１は、サーバ４へのアクセスを与えられ、あるいは、一実施形態で、サーバは、図８を参照して後で説明するステップＳ４１で継続する。
【００６５】
図５に示されているように、代替実施形態では、ステップＳ１３、Ｓ１４、およびＳ１５を含むブロックＡが、ステップＳ２１、Ｓ２２、Ｓ２３、およびＳ２４を含むブロックＢに置換される。
【００６６】
ステップＳ２１で、それぞれ認証トークン・デバイス２０または認証モジュール２のデータ入力手段２３またはセンサ２４を介して、個人識別コードＰＩＮ＿Ｕが、ユーザから受け取られる。
【００６７】
ステップＳ２２で、証明モジュール２５が、ステップＳ２１で受け取った個人識別コードＰＩＮ＿ＵおよびステップＳ１１で生成した認証ベース番号Ｎ＿Ｔから、ステップＳ１５の文脈で上で説明したようにトランザクション認証番号ＴＡＮを生成する。したがって、ステップＳ１５の文脈で説明した副実施形態も、図５に示された実施形態にあてはまる。
【００６８】
ステップＳ２３で、ステップＳ２２で生成されたトランザクション認証番号ＴＡＮが、通信端末１に渡される。
【００６９】
ステップＳ２４で、トランザクション認証番号ＴＡＮが、通信端末１内で受け取られ、おそらくはディスプレイ１１に表示される。その後、通信端末１は、上で説明したステップＳ１６で継続する。
【００７０】
図６に示されているように、代替実施形態では、ステップＳ１３、Ｓ１４、およびＳ１５を含むブロックＡが、ステップＳ３１およびＳ３２を含むブロックＣに置換される。
【００７１】
ステップＳ３１で、ディスプレイ・モジュール２７が、ステップＳ１１で生成された認証ベース番号Ｎ＿Ｔをディスプレイ２２に表示する。
【００７２】
ステップＳ３２で、通信端末１の制御モジュールが、トランザクション認証番号ＴＡＮをユーザから受け取る。ステップＳ３２で入力されるトランザクション認証番号は、ディスプレイ２２に表示された認証ベース番号Ｎ＿Ｔおよびユーザの個人識別コードＰＩＮ＿Ｕの組合せとしてユーザによって定義される。
ＴＡＮ＝ｆ（Ｎ＿Ｔ，ＰＩＮ＿Ｕ）
【００７３】
一般に、適当な関数ｆを定義する多数の可能性がある。Ｍｏｌｖａ，Ｒ．およびＧ．Ｔｓｕｄｉｋ、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｍｅｔｈｏｄ ｗｉｔｈ Ｉｍｐｅｒｓｏｎａｌ Ｔｏｋｅｎ Ｃａｒｄｓ」、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＩＥＥＥ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｒｅｓｅａｒｃｈ ｉｎ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ、ＩＥＥＥ Ｐｒｅｓｓ、１９９３年５月で、引数の１０を法とする剰余の合計を使用することが提案されている。この提案は、適当であるが、同等によく働く多数の他の関数がある。たとえば、ＳｗｉｖｅｌのＰＩＮｓａｆｅによるもう１つの手法は、長さ１０のＮ＿Ｔを表示し、選択に数値ＰＩＮの数を使用することである。その後、通信端末１は、上で説明したステップＳ１６で継続する。
【００７４】
図７に示された実施形態では、認証モジュール２が、通信端末１内のプログラムされたソフトウェア・モジュールによって排他的に実施される。図４に示された実施形態と比較して、図７による実施形態は、ステップＳ５、Ｓ７、およびＳ１３を含まない。というのは、通信端末１と通信端末１の外部の認証モジュール（トークン・デバイス２０）との間のデータ交換がないからである。情報は、通信端末１と認証モジュール２との間で、ソフトウェア・インターフェースまたは通信端末１内の共有メモリ・エリアを使用して交換される。それ以外の点では、ステップＳ１、Ｓ２、Ｓ３、Ｓ４、Ｓ６、Ｓ８、Ｓ９、Ｓ１０、Ｓ１１、Ｓ１２、Ｓ１４、Ｓ１６、Ｓ１７、Ｓ１８、Ｓ１９、およびＳ２０は、図４に関して上で説明したように実行される。
【００７５】
図８に示されているように、ステップＳ４１で、サーバ４は、ステップＳ９で受け取ったデータ・セット（ハッシュ）からサーバ認証コードを生成する。サーバ認証コードＡ＿Ｔは、データ・セット（ハッシュ）に公開関数ｇを適用することと、ステップＳ１８で判定された秘密トークン鍵Ｋ＿Ｔを暗号化に使用することとによって生成される。
Ａ＿Ｔ＝Ｅ＿｛Ｋ＿Ｔ｝（ｇ（ｈａｓｈ））
【００７６】
Ａ＿Ｔの構成は、基本的に認証ベース番号Ｎ＿Ｔの構成と同一である。唯一の相違は、データ・セット（ハッシュ）が、秘密トークン鍵Ｋ＿Ｔを用いて暗号化される前に、公に知られた関数ｇにかけられることである。関数ｇが複雑である必要はない。関数ｇは、ハッシュ値の補数を計算すること程度に単純なものとすることができる。このサーバ認証に本質的なのは、データ・セット（ハッシュ）と認証ベース番号Ｎ＿Ｔとの両方を見ることができる可能性がある敵対者が、トークン鍵Ｋ＿Ｔが秘密であることと、暗号化関数Ｅ＿（一実施形態で、これをｔｒｉｐｌｅ−ＤＥＳなどの対称暗号とすることができる）の特性とのゆえに、Ａ＿Ｔを構成できないことである。
【００７７】
ステップＳ４２で、ステップＳ４１で生成されたサーバ認証コードが、通信端末１に送信される。
【００７８】
ステップＳ４３で、ステップＳ４２で受信されたサーバ認証コードが、通信端末１によってディスプレイ１１に表示される。
【００７９】
ステップＳ４４で、サーバ認証モジュール２８が、公開関数（ｇ）をデータ・セットに適用することと、認証モジュール２に関連する秘密トークン鍵Ｋ＿Ｔを暗号化に使用することとによって、ステップＳ５で受け取られたデータ・セット（ハッシュ）からサーバ認証コードを生成する。
【００８０】
ステップＳ４５で、ディスプレイ・モジュール２７が、ステップＳ４４で生成されたサーバ認証コードをディスプレイ２２に表示する。
【００８１】
ステップＳ４６で、サーバ４は、ユーザが、ディスプレイ２２に表示されたサーバ認証コードとの比較を介してディスプレイ１１に表示されたサーバ認証コードを検証することによって認証される。
【００８２】
図９に示された実施形態では、認証モジュール２が、通信端末１内のプログラムされたソフトウェア・モジュールによって排他的に実施される。図８に示された実施形態と比較して、図９による実施形態は、ステップＳ４７で、ディスプレイ・モジュール２７が、ステップＳ４４で生成されたサーバ認証コードをディスプレイ１１に表示する。さらに、ステップＳ４８で、サーバ４は、ユーザが、サーバ認証モジュール２８からのサーバ認証コードとの比較を介してサーバ４からのサーバ認証コードをディスプレイ１１上で検証することによって認証される。
【００８３】
ここまでで提案された認証モジュール２は、単一の機関に対してユーザを認証する（単一の個人識別コードを使用して）のに使用することができる。さらなる実施形態では、認証モジュール２は、複数の機関を伴う応用例のために、すなわち、複数の機関のサーバに対してユーザを認証するように構成される。複数機関認証モジュールを実施する好ましい手法は、マスタ鍵ＭＫを機関固有マスタ鍵ＭＫ＿Ｉの組に置換し、トークン鍵Ｋ＿Ｔを機関固有トークン鍵Ｋ＿｛ＩＴ｝の組に置換することであり、ここで、Ｋ＿｛ＩＴ｝は、認証モジュールが機関Ｉと共有する秘密トークン鍵を指す。各サーバ４は、特定の機関に関連し、認証ベース番号を生成するのに、その機関に固有の秘密トークン鍵を使用する。単一機関セッティングに似て、秘密トークン鍵Ｋ＿｛ＩＴ｝は、次式に従って動的に生成することができる。
Ｋ＿｛ＩＴ｝＝Ｅ＿｛ＭＫ＿Ｉ｝（ＳＮ＿Ｔ）
【００８４】
次に、この鍵が、認証ベース番号およびトランザクション認証番号の機関固有の値を生成するのに使用される。
Ｎ＿｛ＩＴ｝＝Ｅ＿｛Ｋ＿｛ＩＴ｝｝（Ｈａｓｈ）
および
ＴＡＮ＝ｆ（Ｎ＿｛ＩＴ｝，ＰＩＮ＿｛ＩＵ｝）
【００８５】
次に、結果のＴＡＮを、ユーザが機関Ｉ（のサーバ４）への認証に使用することができる。個人識別コードＰＩＮ＿｛ＩＵ｝は、ユーザ固有であるだけではなく、機関固有でもある。したがって、複数機関認証モジュールは、複数の機関固有秘密トークン鍵の組を格納したことによってまたは機関固有秘密トークン鍵を動的に生成するために複数の機関固有トークン識別子およびマスタ鍵の組を格納したことによってのいずれかで、複数の機関固有秘密トークン鍵に関連する。選択モジュール２９は、ユーザが、それぞれ認証モジュール２または認証トークン・デバイス２０について複数の可能な機関スコープのうちの１つを選択するために設計されている。ユーザによって選択された機関スコープをセットされて、認証モジュール２は、認証ベース番号を生成するのに、１つのめいめいの機関固有秘密トークン鍵を使用する。たとえば、選択モジュール２９は、ディスプレイ２２または１１上で、サポートされる機関のリストをユーザに提示し、データ入力手段２３または１２を介してユーザ選択を受け取る。代替実施態様では、データ入力手段２３または１２の特定のキーが、特定の機関に割り当てられる。
【００８６】
認証モジュール２が複数のＫ＿｛ＩＴ｝ではなく１つだけを安全に保持するさらなる実施形態では、オンライン包括的発行機関（ｏｎｌｉｎｅ ｏｖｅｒａｒｃｈｉｎｇ ｉｓｓｕｉｎｇ ｉｎｓｔｉｔｕｔｉｏｎ）（ＡＳ）が追加される。これは、認証モジュール２の発行グループの一部である機関の組の柔軟性を高める。認証モジュール２は、ナンスＲ＿Ｔを作成する。ユーザは、認証モジュール２のディスプレイから２つの値をコピーしなければならない、すなわち、ＳＮ＿Ｔではなく、ＴＡＮ＿ＡＳが、代わりに生成され、ユーザ認証フェーズ中に成功のＳＳＬ／ＴＬＳセッション確立の後に入力される必要がある。
ＴＡＮ＿Ｉ＝ｆ’（Ｒ＿Ｔ，ＰＩＮ＿Ｕ＿Ｉ）
ＴＡＮ＿ＡＳ＝Ｅ＿ＭＫ（Ｒ＿Ｔ，Ｈａｓｈ，ＩＤ＿Ｉ）
ここで、ＩＤ＿Ｉは、「機関ＸＹＺ」の「ＸＹＺ」など、短い識別子文字列である。
【００８７】
機関Ｉは、両方の値を見るが、単独ではこれらについて何もすることができない。機関Ｉは、ＴＡＮ＿ＡＳを発行機関ＡＳに転送し、それと引き換えにＲ＿ＴおよびＨａｓｈを受け取る。ＡＳとＩとの間の接続が、相互に認証され、機密であると仮定する。
【００８８】
犯罪の意図がない限り、ＴＡＮ＿Ｉは、発行機関ＡＳによって絶対に見られず、したがって、発行機関ＡＳがＰＩＮ＿Ｕ＿Ｉを判定できる危険性はない。しかし、この実施形態では、前に述べた強い暗号ハッシュ関数であるｆ’を選択することだけが推奨される。
同様に、この手法は、機関Ｉ＿１…Ｉ＿ｎを、互いのユーザのＰＩＮを知ることを試みることから保護する。
【００８９】
この実施形態は、新しい機関の追加を非常に単純にする。本質において、追加のＩＤ＿Ｉ＿ｎ文字列を、認証モジュール２に単純に追加することができる。認証モジュール２が、偽物のＩＤ＿Ｉ文字列であふれる場合には、これは、ユーザビリティの懸念にはなるが、それ以外の点で提案される方法のセキュリティを実際に傷つけはしない。
【００９０】
一実施形態で、認証モジュール２または認証トークン・デバイス２０は、それぞれ、「使い捨てパスワード」（ＯＴＰ）システム（たとえば、ＬａｍｐｏｒｔスタイルＯＴＰ（Ｌａｍｐｏｒｔ，Ｌ．、「Ｐａｓｓｗｏｒｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｗｉｔｈ Ｉｎｓｅｃｕｒｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ」、Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｏｆ ｔｈｅ ＡＣＭ、Ｖｏｌ．２４、１９８１年、７７０〜７７２頁）またはＳｅｃｕｒＩＤトークン（ｈｔｔｐ：／／ｗｗｗ．ｒｓａｓｅｃｕｒｉｔｙ．ｃｏｍ／））を補完するのに使用される。この場合に、ユーザは、ステップＳ１５のＰＲＦまたはｆの入力としてＯＴＰを使用する（ＰＩＮ＿Ｕの代わりに）。しばしば、ＯＴＰはＰＩＮ＿Ｕを含む。それ以外のすべてが、本質的に同一のままになる。プロトコルにおける小さい変更ではあるが、これは、ＲＳＡのＳｅｃｕｒＩＤなど、既に使用されているツー・ファクタ・セキュリティ要素を用いるソフトウェア変形形態の使用を可能にする。
【００９１】
もう１つの実施形態では、バイオメトリック認証ステップが、認証トークン・デバイス２０をアクティブ化する前に追加される。これは、トークンが、別々のプロセスでパーソナライズされ、バイオメトリックスが一致する場合に限ってトークンの少なくとも「一時的な」所有者の要求を満たし始めることを暗示する。
【００９２】
さらなる実施形態で、ユーザのバイオメトリック特性Ｂ＿Ｕが、前に説明したようにＰＩＮ＿Ｕを入力するのには使用されない場合に、バイオメトリック・データは、認証ベース番号Ｎ＿Ｔの計算に含められる。また、この実施形態のサーバは、ＰＩＮ＿Ｕの上にＢ＿Ｕを格納し、したがって、認証モジュール２は、完全に個人的に転送可能なままになる。
Ｎ＿Ｔ’’＝Ｅ＿｛Ｋ＿Ｔ｝（Ｈａｓｈ，Ｂ＿Ｕ）
【００９３】
図４、５、６、７、８、および９に示されたステップの異なるシーケンスが、本発明の範囲から逸脱せずに可能であることを指摘しなければならない。
【００９４】
個人識別コードの変更に関する実施形態
エンド・ユーザ教育の展望から、単純な行動ガイドラインを有することが重要である。説明されるすべての実施形態について、これは、確かに「絶対に現在のまたは新しい個人識別コードをウェブ・ブラウザに入力してはならない」になる。図５に示された個人識別コードを入力するモジュールなど、追加ハードウェアを含む実施形態について、ガイドラインは、「絶対に主キーボードを用いて画面にＰＩＮを入力してはならない」にさえなる。しかし、好ましくは、ユーザが周期的に自発的にそのユーザの個人識別コードＰＩＮ＿Ｕを変更することが可能でなければならない。
【００９５】
たとえば、個人識別コードＰＩＮ＿Ｕを変更するために、本質的に上で説明したものと同一のステップを実行する、もう１つのセキュア・セッションが確立される。具体的に言うと、図４、５、または７に示されているように、ステップＳ１からＳ１０の後に、ステップＳ１１で、認証ベース番号Ｎ＿Ｔが生成される。
【００９６】
個人識別コードＰＩＮ＿Ｕの変更に関するユーザまたはサーバの指示に応答して、それぞれステップＳ１４またはステップＳ２１で、古い個人識別コードＰＩＮｏｌｄ＿Ｕおよび新しい個人識別コードＰＩＮｎｅｗ＿Ｕが、それぞれ通信端末１、認証トークン・デバイス２０、または認証モジュール２内でユーザから受け取られる。好ましくは、タイピング・エラーを避けるために、新しい個人識別コードＰＩＮｎｅｗ＿Ｕは、二重入力を介して確認される。
【００９７】
それぞれステップＳ１５またはＳ２２で、トランザクション認証番号ＴＡＮを生成するのではなく、識別変更コード（ＰＣＣ）が生成される。本質的に、ＰＣＣの計算に使用されるＰＲＦは、個人識別コードを回復可能にしなければならない。たとえば、排他的論理和（ＸＯＲ）関数が、この特性を有する。
【００９８】
次に、ＰＣＣが、適当に選択された関数ｆ０についてＰＣＣ＝ｆ０（Ｎ＿Ｔ，ＰＩＮｏｌｄ＿Ｕ，ＰＩＮｎｅｗ＿Ｕ）として計算される。たとえば、ｆが１０を法とする剰余での桁単位の加算を表す場合に、ｆ０を次のように定義することができる。
ｆ０（Ｎ＿Ｔ，ＰＩＮｏｌｄ＿Ｕ，ＰＩＮｎｅｗ＿Ｕ）＝ｆ（ｆ（Ｎ＿Ｔ，ＰＩＮｏｌｄ＿Ｕ），ＰＩＮｎｅｗ＿Ｕ）
【００９９】
たとえば、Ｎ＿Ｔ＝１２３、ＰＩＮｏｌｄ＿Ｕ＝３４５、およびＰＩＮｎｅｗ＿Ｕ＝７８１の場合に、ｆ（Ｎ＿Ｔ，ＰＩＮｏｌｄ＿Ｕ）＝４６８であり、ｆ（ｆ（Ｎ＿Ｔ，ＰＩＮｏｌｄ＿Ｕ），ＰＩＮｎｅｗ＿Ｕ）＝１４９である。
【０１００】
その後、ステップＳ１６、Ｓ２３、Ｓ２４で、トランザクション認証番号ＴＡＮではなく、識別変更コード（ＰＣＣ）がサーバ４に通信される。ステップＳ１７およびＳ１８は、上で説明したように実行される。ステップＳ１９およびＳ２０では、その結果、トランザクション認証番号ＴＡＮを検証するのではなく、サーバ４は、（ＰＩＮｏｌｄ＿Ｕの検証を介して）個人識別コードＰＩＮ＿Ｕを変更したのが正当なユーザであって、進行中のセッションが正当なユーザによって無人のままにされたアンロックされた端末を利用した他の誰かではないことを保証しながら、ユーザによってサブミットされたＰＣＣからＰＩＮｎｅｗ＿Ｕを導出する。ｆ０について与えた例では、サービス拒否につながり得る盲目的置換攻撃に対する保護が、与えられない。しかし、現在優勢なセッション確立プロトコル（ＳＳＬ／ＴＬＳ）の文脈では、相補的なメッセージ完全性保護が、この攻撃を防ぐ。
【０１０１】
もう１つの実施形態では、個人識別コードＰＩＮ＿Ｕが、３つのセキュア・セッション確立によって実施される。
【０１０２】
第１は、ユーザがＰＩＮｏｌｄ＿Ｕを再供給するセッションであり、第２は、ユーザがＰＩＮｎｅｗ＿Ｕを提示するセッションであり、第３は、ユーザがタイピング・エラーを避けるためにＰＩＮｎｅｗ＿Ｕを再提示するセッションである。
【０１０３】
ＰＩＮ変更が、サーバによって開始された場合に、このプロトコルの状態をシグナリングするために、サーバは、この３つのステップのそれぞれについて異なるオーソリティである、ｈｔｔｐ：／／ｗｗｗ．ｒｆｃ．ｎｅｔ／ｒｆｃ２２４６．ｈｔｍｌ＃ｓ７．４．４に概要を示された擬似「ＤｉｓｔｉｎｇｕｉｓｈｅｄＮａｍｅ ｃｅｒｔｉｆｉｃａｔｅ＿ａｕｔｈｏｒｉｔｉｅｓ」をアドバタイズすることができる。同様に、トークンは、４つすなわち、通常の認証用に１つとこの実施形態用に３つの異なる証明書を有する必要がある。
【０１０４】
代替案では、認証ベース番号Ｎ＿Ｔを計算する時に、認証トークン・デバイス２０または認証モジュール２は、それぞれ、ステップ識別子を含む。したがって、それぞれ認証トークン・デバイス２０または認証モジュール２で必要な異なる証明書の個数を減らすことができる。
【０１０５】
個人識別コードの変更が、クライアントによって開始された場合に、サーバは、少なくとも、通常の認証用に１つおよび個人識別コードの変更のステップ１用に１つの２つのＣＡを提供しなければならない。
【０１０６】
暗号なしの認証モジュールを用いる実施形態
もう１つの実施形態で、認証トークン・デバイス２０または認証モジュール２は、それぞれ、暗号化のために構成される必要がない。
【０１０７】
この実施形態では、認証ベース番号Ｎ＿Ｔが、ＨＭＡＣなどの暗号ハッシュ関数によって、秘密としてトークン鍵Ｋ＿Ｔを使用して計算される。これは、多少より少ない計算オーバーヘッドで同一のセキュリティを提供する。共有される秘密およびセキュア・ストレージの必要は、この実施形態でも残る。たとえば、ステップＳ１５の文脈で説明した副実施形態で概要を示した暗号ハッシュ（ＣＨ）を使用して、ステップＳ１１で使用される暗号化を置換することができる。
Ｎ＿Ｔ＝ＣＨ＿｛Ｋ＿Ｔ｝（ｈａｓｈ）
これは、ステップＳ４１またはＳ４４など、暗号化の他の使用にもあてはまる。
【０１０８】
代替トランザクション認証番号（ＴＡＮ）を用いる実施形態
この実施形態では、個人識別コードＰＩＮ＿Ｕが、ステップＳ４の後に、ステップＳ１４またはＳ２１の文脈で前に（図４）説明した形で入力される。その後、鍵付き暗号ダイジェスト値、たとえば暗号ハッシュが、個人識別コードおよび通信端末とサーバ４との間で交換されたセキュア・セッション確立プロトコル・メッセージから生成される。プロトコル・フローに関して、セキュリティ目的ではなく、このステップに通し番号ＳＮ＿Ｔをも含めることが有用である場合がある。鍵付き暗号ダイジェスト値は、鍵付き暗号ダイジェスト関数、たとえば、サーバ４と共有される秘密を（ハッシュ）鍵として使用するいわゆる「鍵付きハッシュ関数」を用いて、生成される。実施形態に応じて、（ハッシュ）鍵として使用されるのは、トークン鍵Ｋ＿Ｔ、個人識別コードＰＩＮ＿Ｕ、またはセキュア・セッション確立プロトコル内でセッション鍵を確立するための基礎として使用されたプリマスタ秘密である。具体的に言うと、個人識別コードＰＩＮ＿Ｕが、明確に選択された秘密である場合に、その個人識別コードＰＩＮ＿Ｕを（ハッシュ）鍵として使用することができる。これによって、認証トークン・デバイス２０が、それ自体の秘密のトークン鍵Ｋ＿Ｔまたは私有署名鍵ｋー１あるいはその両方を有することから解放され、認証モジュール２または認証トークン・デバイス２０が、それぞれ、単に「信頼される観察者」になる。サーバ４は、「高い金額を人ｘｙｚに送れ」などのアプリケーション・レベル指示が認証されたＳＳＬセッション内から来るのか否かを即座に検出する。
【０１０９】
たとえば、ステップＳ５で、サーバ４と交換されたセキュア・セッション確立プロトコル・メッセージから通信端末１によって生成されたデータ・セット（ハッシュ）および個人識別コードＰＩＮ＿Ｕが、それぞれ認証モジュール２または認証トークン・デバイス２０に渡される。ステップＳ６で、証明モジュール２５が、データ・セット（ハッシュ）および個人識別コードＰＩＮ＿Ｕから暗号ハッシュを生成する。ステップＳ６での電子署名の生成は、任意選択である。ステップＳ７で、暗号ハッシュ（電子署名を伴うまたは伴わない）が、通信端末１に渡される。この副実施形態では、ＰＩＮ＿Ｕも、ユーザによってステップＳ６で認証トークン・デバイス２０に直接に入力することだけができる。
【０１１０】
代替案では、暗号ハッシュは、ステップＳ４で、個人識別コードＰＩＮ＿Ｕおよび通信端末１とサーバ４との間で交換されたセキュア・セッション確立プロトコル・メッセージから生成される。その結果、ステップＳ５からＳ７は、必要なステップのすべてがステップＳ４で実行されるので、省略される。
【０１１１】
ステップＳ８で、通信端末１は、ステップＳ３で受け取った証明要求に対する応答、たとえば、それぞれステップＳ６またはＳ４で生成された暗号ハッシュおよびユーザによって確認されたか新たに入力されたユーザ識別子ＩＤ＿Ｕを含む、ＳＳＬ／ＴＬＳに従う「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージを用意する。
【０１１２】
ステップＳ１０で、サーバ４は、サーバ４に格納されたユーザの個人識別コードを使用して暗号ハッシュを生成し、サーバ４で生成された暗号ハッシュとステップＳ９で通信端末から受信した暗号ハッシュとの比較に基づいてユーザの真正性を検証する。肯定の検証の際に、通信端末１は、たとえばサーバ４へのアクセスを与えられる。したがって、暗号ハッシュが、上で説明したトランザクション認証番号ＴＡＮの代替データ要素として生成され、交換され、検証される。
【０１１３】
サーバ４がユーザを認証しなければならない場合に、サーバ４は、ステップＳ４１で継続する。しかし、さらなる副実施形態では、サーバ認証コードＡ＿Ｔが、ステップＳ４〜Ｓ６の直後に表示される。
【０１１４】
外部チャレンジ／レスポンス・デバイスを用いる実施形態
この好ましい実施形態では、認証モジュール２は、図７および１０に示されているように、通信端末１内のプログラムされたソフトウェア・モジュールによって排他的に実施される。ステップＳ１、Ｓ２、Ｓ３、Ｓ４、Ｓ６、Ｓ８、Ｓ９、Ｓ１０、およびＳ１１は、本質的に図４を参照して上で説明したように実行される。ステップＳ１１の一部として、認証ベース番号Ｎ＿Ｔが、ディスプレイ１１に表示される。副実施形態では、認証モジュール２が、信頼されるオブザーバとしてのみ働き、認証ベース番号（Ｎ＿Ｔ’’’）が、プロトコル・メッセージから、たとえば通常のＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージから生成されるデータ・セットの短い派生物（たとえば、６桁または８桁）として生成される。本質的に、認証ベース番号Ｎ＿Ｔは、活用可能な形でＭＩＴＭによって判定することのできない任意の他のセッション関連識別子とすることができ、たとえば、セッション鍵およびサーバ公開鍵の短いダイジェストを、ＭＩＴＭ攻撃に耐えるセキュア・セッション識別子として認証ベース番号Ｎ＿Ｔを計算するもう１つの形とすることができる。「Ｆｉｎｉｓｈｅｄ」メッセージのハッシュまたは暗号化された「Ｆｉｎｉｓｈｅｄ」メッセージ、あるいは外部観察可能ハンドシェーク・メッセージのシーケンス全体が、このセッション関連識別子（それぞれＮ＿ＴまたはＮ＿Ｔ’’’）を構成するための他の候補であり、下でより詳細に説明される。したがって、この実施形態では、Ｎ＿Ｔを構成するために秘密トークン鍵Ｋ＿Ｔを有することが、任意選択である。同様に、秘密署名鍵ｋ−１も、任意選択とすることができる。
【０１１５】
その後、図１０に示されているように、ステップＳ５１で、ユーザが、認証ベース番号Ｎ＿Ｔ（クライアント側で生成されたチャレンジとして）およびそのユーザの個人識別コードＰＩＮ＿Ｕ（たとえば、コードまたはバイオメトリック・データとして）を、通信端末１に接続されていない従来のＣ／Ｒトークン・デバイス５に入力する。ステップＳ５２で、ステップＳ５１で入力された値に応答して、Ｃ／Ｒトークン・デバイス５が、それ自体の論理に基づいて、トークン・レスポンス値を生成し、表示する。ステップＳ１４およびＳ１５を置換するステップＳ５３で、ユーザが、トランザクション認証番号としてＣ／Ｒトークン・デバイス５からのトークン・レスポンス値を通信端末１に入力する。
【０１１６】
ステップＳ５４で、ステップＳ１２で受信した要求に応答して、通信端末１が、トランザクション認証番号ＴＡＮとして以前に入力されたトークン・レスポンス値をサーバ４に送信する。
【０１１７】
本質的に、ステップＳ１７からＳ２０は、それぞれ図４または７を参照して上で説明したようにサーバ４によって実行されるが、Ｃ／Ｒトークン・デバイス５の論理に対応して、サーバ４は、トランザクション認証番号ＴＡＮとしてトークン・レスポンス値を生成し、検証する。トランザクション認証番号すなわちトークン・レスポンス値の肯定の検証時に、それぞれ図８または９に示されているように、通信端末１が、サーバ４へのアクセスを与えられ、あるいは、一実施形態で、サーバ４が、ステップＳ４１で継続する。
【０１１８】
たとえば、Ｃ／Ｒトークン・デバイス５は、数百万枚の銀行カードおよびクレジット・カードで流通しているＥＭＶチップ（Ｅｕｒｏｐａｙ Ｉｎｔｅｒｎａｔｉｏｎａｌ、ＭａｓｔｅｒＣａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ、およびＶｉｓａ Ｉｎｔｅｒｎａｔｉｏｎａｌ）に基づく（ｈｔｔｐ：／／ｗｗｗ．ｅｍｖｃｏ．ｃｏｍを参照されたい）。ＥＭＶチップによって生成されるいくつかのトークン・レスポンス値は、個人識別コードＰＩＮ＿Ｕを含まない。ＭａｓｔｅｒＣａｒｄチップ認証プログラム（ＣＡＰ）に従うカードＩＣＣは、以前のＫ＿Ｔに似た役割を有するサーバ（発行者）と鍵を共有する。個人識別コードＰＩＮ＿Ｕおよびチャレンジ（認証ベース番号Ｎ＿Ｔ）の正しい入力の後に、とりわけ（たとえば、ＣＶＶ）チャレンジおよび正しい個人識別コードＰＩＮ＿Ｕが提示されたことの信頼できる確認を含む暗号文（通常は３ＤＥＳ）が作成される。通常、数字キーパッドを有する接続されないリーダーが、認証ベース番号Ｎ＿Ｔおよび個人識別コードＰＩＮ＿Ｕの入力に使用され、トークン・レスポンス値は、接続されないリーダーのディスプレイに表示される。認証ベース番号Ｎ＿Ｔ’’’が４桁または６桁に短縮されている場合に、たとえば、ＭＩＴＭが、認証ベース番号Ｎ＿Ｔ’’’への短いデータ・セット（ハッシュ）依存入力がサーバとＭＩＴＭとの間で開かれた主詐欺セッションと衝突する端末上のクライアントとの副詐欺セッションを確立できる可能性が、大きく高まる。ＭＩＴＭは、おそらくは、どちらの当事者にも衝突しない推測を気付かれずに、衝突が見つかったか否かをオフラインで検証することができる。そのような攻撃を防ぐために、「短縮」アルゴリズムは、ＭＩＴＭに完全に知られている単純なハッシュ関数または一方向ダイジェスト関数とすることはできず、さらなる特性を有する必要がある。基本的に、「セッション・アウェアネス」のオフラインでの推測が、ＭＩＴＭにとって、Ｃ／Ｒデバイス５を使用する時のすべての他のタイプの攻撃に関する個人識別コードＰＩＮ＿Ｕのオフラインでの推測と同等に魅力的でなくなる必要がある。これは、短縮されたハッシュでの衝突を見つけることが、もはやオフラインで検証可能ではなく、オンライン・オーソリティすなわち推測の回数を制限するサーバとの交換を必要としなければならないことを意味する。Ｃ／Ｒトークン・デバイス５の対称鍵（ユーザがパスワードとして記憶できると期待されるものより高いエントロピを有する）が、暗号化を介してＭＩＴＭから擬似乱数セレクタを隠すのに使用される。これは、本質的に、３６バイト長のハッシュ（データ・セット）全体に対する衝突を見つけることをＭＩＴＭに強いるが、これはほとんど実現不能である。
【０１１９】
したがって、一実施形態で、ステップＳ１１の一部として、クライアント側で、認証モジュール２が、たとえばクライアント・アプリケーション（たとえば、ブラウザ）の一部として、後で「ランダム選択数（ｒａｎｄｏｍ ｐｉｃｋｉｎｇ ｄｉｇｉｔ）」と称する短い乱数、たとえば４桁を生成する。この乱数は、プロトコル・メッセージから生成されたデータ・セットから、たとえばＴＬＳハンドシェークの「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージまたは「Ｆｉｎｉｓｈｅｄ」メッセージの３６バイト・ハッシュから任意のビットを選択するのに使用され、この任意のビットは、たとえばもう１つの４桁を表す。その後、後者の４桁および「ランダム選択数」が、たとえば８桁の短縮された認証ベース番号Ｎ＿Ｔ’’’としてディスプレイ１１でユーザに表示される。ステップＳ５１で、ユーザは、この認証ベース番号Ｎ＿Ｔ’’’（クライアント側で生成されたチャレンジとして）およびそのユーザの個人識別コードＰＩＮ＿Ｕを、図１０を参照して上で説明したようにＣ／Ｒトークン・デバイス５に入力する。ステップＳ５２からＳ５４は、図１０の文脈で上で説明したものと同一のままである。
【０１２０】
「ランダム選択数」がＭＩＴＭに知られ「ない」ために、Ｃ／Ｒトークン・デバイス５上のアルゴリズムは、「ランダム選択数」が暗号化された形でサーバ４に送られるように適合される。これは、トランザクション認証番号としてＣ／Ｒトークン・デバイス５によって生成されたトークン・レスポンス値が、暗号化された形で「ランダム選択数」を含むことを意味する。その結果、サーバ４は、それが受け取ったレスポンスから「ランダム選択数」を回復するように構成される。たとえば、３ＤＥＳ（またはたとえば６４ビットのブロック長を有する別の暗号化システム）を用いると、レスポンスは６４ビットである。たとえば、レスポンスについて、３２文字の英数字文字セットが許容され、したがって、レスポンスは、１３文字の長さになる。その結果、ユーザは、１３個の英数字文字をＣ／Ｒトークン・デバイス５からクライアント・アプリケーションに、たとえばブラウザのフォーム・フィールドにコピーしなければならない。ユーザが定期的に１９桁のクレジット・カード番号（ＣＶＶを含む）をタイプすることを考慮すると、チャレンジの８桁およびレスポンスの１３文字をタイプすることは、ユーザビリティの観点から許容されると思われる。この手法のセキュリティは、チャレンジおよびレスポンスの長さに対して相対的に高まり、あるいは下がる。
【０１２１】
サーバ側では、ステップＳ１８が変更され、「ランダム選択数」が、秘密トークン鍵Ｋ＿Ｔを使用して暗号化解除され、その後、短縮された認証ベース番号Ｎ＿Ｔ’’’を計算するための短縮された入力をデータ・セット（ハッシュ）から選択するのに使用されるようになる。他のすべてが、前と同じままである。
【０１２２】
さらなる実施形態として、認証ベース番号Ｎ＿Ｔが、たとえばｈｔｔｐ：／／ａｘｓｉｏｎｉｃｓ．ｃｈに記載のグラフィカル点滅（ｇｒａｐｈｉｃａｌ ｆｌｉｃｋｅｒｉｎｇ）など、ユーザがキーボードにタイプすることによるもの以外の手段を介してデバイスに入力される。重要な機能強化は、通常は完全にサーバによって作成される点滅チャレンジが、あるクライアント側で生成されるセキュア・セッション識別子によって修正される必要があることである。この点滅方法の実施態様は、好ましくは、ブラウザ（ｊａｖａ）プラグイン、Ｆｌａｓｈ、またはｊａｖａｓｃｒｉｐｔなど、あるクライアント側アクティブ・コンポーネントを有するので、いくつかの実施形態で、これを使用して、たとえば、サーバ公開鍵と、セッション鍵または他のタイプのセキュア・セッション識別子のダイジェストとを取り出し、これを点滅イメージ生成すなわち関連するプロトコルのチャレンジに含めることができる。このアクティブ・コンポーネントは、好ましくは、署名される。というのは、そうでなければ、ＭＩＴＭが、クライアント通信端末１に真に組み込まれた認証ベース番号Ｎ＿ＴではなくＭＩＴＭの認証ベース番号Ｎ＿Ｔを提示できる変更された版を簡単に注入するからである。
【０１２３】
さらなる副実施形態（「ハンドシェーク中のクライアント証明書認証なし」）では、通信端末１のクライアント・アプリケーション・ソフトウェア・モジュール、たとえばブラウザが、セキュア・セッション確立プロトコル・スタックへの読取専用アクセスを介してまたは「アウトサイダ」としてプロトコル・メッセージをスニッフ／取り込むことができることによってさえ、ＭＩＴＭ攻撃に耐えるセキュア・セッション識別子として認証ベース番号Ｎ＿Ｔｉｖを計算するように構成された認証番号ジェネレータ２６を設けられる。したがって、この副実施形態では、クライアント証明書認証を実行する必要がない、すなわち、片側のセキュア・セッションのためにステップＳ３〜Ｓ１０を実行する必要がなく、ＭＳ−ＣＡＰＩまたはＰＫＣＳ１１などのトークン・デバイス・ドライバは、もはや不要である。
【０１２４】
上で述べた認証番号ジェネレータ２６は、ステップＳ１１で、下に概要を示すように、ＭＩＴＭ攻撃に耐えるセキュア・セッション識別子として認証ベース番号Ｎ＿Ｔｉｖを計算するように構成される。
【０１２５】
ａ）認証ベース番号Ｎ＿Ｔｉｖは、データ・セット（ハッシュ）に基づき、ＭＩＴＭが知ることのできない（たとえば、入力として暗号化される前にプリマスタ秘密を有することに起因して）通信端末１とサーバ４との間で交換されるセキュア・セッション確立プロトコル・メッセージに基づいて生成され、または、
ｂ）認証ベース番号Ｎ＿Ｔｉｖは、既知の入力データおよび秘密の鍵から生成され（この実施形態では、クライアント・アプリケーションでの秘密トークン鍵Ｋ＿Ｔの必要を回避しなければならないが）、または、
ｃ）認証ベース番号Ｎ＿Ｔｉｖは、すべてがＭＩＴＭにも既知であるが、セキュア・セッション確立プロトコルへの論理的接続によってＭＩＴＭに対する抵抗を保証する入力データに基づいて生成される。この実施形態では、サーバの公開鍵および新しさを保証するもの（ナンスまたはタイムスタンプ）を使用することが、十分である。たとえば、暗号化されたプリマスタ秘密のハッシュすなわちＭＩＴＭによって観察可能なメッセージが、そのようなナンスとして働くことができる。この場合に、チャレンジを知り、レスポンスを観察することによって、ＭＩＴＭが（オフライン）ＰＩＮ推測攻撃を開始することができないことを、Ｃ／Ｒトークン・デバイスの論理が保証することが重要である。
【０１２６】
たとえば、認証番号ジェネレータ２６は、このＭＩＴＭに耐えるセキュア認証ベース番号Ｎ＿Ｔｉｖ（チャレンジ）をクライアント・アプリケーション内で表示するように構成される。たとえば、認証番号ジェネレータ２６は、ユーザがマウスのポインタを定義された区域、たとえばブラウザの右下の上、たとえばブラウザ内に表示されたロックの上に移動する時に、この区域内でチャレンジをユーザに可視にする。
【０１２７】
上で説明したように、ユーザは、認証ベース番号Ｎ＿Ｔｉｖ（チャレンジとして）およびそのユーザの個人識別コードＰＩＮ＿ＵをＣ／Ｒトークン・デバイスに入力し、この方法は、上で説明したように進行する。
【０１２８】
秘密の鍵を用いないがクライアント側でナンスを用いる実施形態
Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ２２４６に概要を示されているように、ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージの構造を、ＰＫＣＳ１エンコードされた署名ではなく任意のレスポンスによってオーバーロードする可能性がある。これは、トークンがもはや秘密トークン鍵Ｋ＿Ｔを必要としない可能性を提供する。この実施形態では、上で説明した「代替トランザクション認証番号（ＴＡＮ）を用いる実施形態」に類似して、ステップＳ６で、認証モジュール２または認証トークン・デバイス２０が、それぞれ、ハッシュ（データ・セット）、個人識別コードＰＩＮ＿Ｕ、およびさらに１つまたは２つの真にランダムなナンスＮ＿Ｔｔ（およびＮ＿Ｔａ）を公開鍵ｋ＿Ｓを用いて暗号化することによって、暗号文を生成する（ナンスは、「ｎｕｍｂｅｒ ｕｓｅｄ ｏｎｃｅ（１回だけ使用される数）」である）。公開鍵ｋ＿Ｓは、ＭＩＴＭがシステムをだましてＭＩＴＭ自身の鍵ｋ＿ＭＩＴＭを使用させるのを防ぐために、それぞれ認証モジュール２または認証トークン・デバイス２０に事前にインストールされなければならない。公開鍵ｋ＿Ｓは、サーバ４または複数機関の場合に認証サーバＡＳのいずれかに属する（認証サーバは、公開鍵ｋ＿ＡＳに関連する）。任意選択で、暗号文の入力値は、公開鍵ｋ＿（Ａ）Ｓによる暗号化の前に、秘密の鍵ｋ−１を用いて署名される。同様に、Ｓ１５の副実施形態に従って、暗号ハッシュ関数（ＨＭＡＣ）を、暗号化の前に適用することができる。
【０１２９】
ステップＳ７〜Ｓ９では、ほとんどの「セキュア・セッション確立プロトコル」によって要求されるように「電子署名」を送信するのではなく、この暗号文が、プロトコル仕様によって課せられる制約なしで、構造化されないデータとして送信される。他のプロトコル部分も、通信端末１のクライアント・アプリケーション内ではなく認証トークン・デバイス２０上で実行される（たとえば、セッション鍵の生成）実施態様では、「ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅ」メッセージなど、他のプロトコル・メッセージを使用して暗号文を送信することができる。
【０１３０】
ステップＳ１０で、サーバ４が、暗号文を暗号化解除する。これは、ナンスＮ＿Ｔｔ、個人識別コードＰＩＮ＿Ｕ、およびおそらくはナンスＮ＿Ｔａをサーバに与える。ナンスＮ＿Ｔｔは、「使い捨て」ナンスであり、ｐｉｎ推測攻撃を防ぐ塩として追加される。
【０１３１】
ステップＳ１０で、サーバ４は、ステップＳ４の文脈で説明したように「ハッシュ」も生成する。ステップＳ１１〜Ｓ１７は不要である。
【０１３２】
ステップＳ１８〜Ｓ２０で、認証モジュール４０は、もはや認証ベース番号Ｎ＿Ｔおよびトランザクション認証番号ＴＡＮを生成するのではなく、単純にハッシュとステップＳ１０で暗号化解除されたＰＩＮ＿Ｕとを比較する。暗号文から導出されたハッシュは、サーバ４で生成されたハッシュと比較され、個人識別コードＰＩＮ＿Ｕは、データベース４１に格納された個人識別コードと比較される。暗号ハッシュ関数がＳ６で使用される場合に、これらの値は、比較の前にまずサーバ側で暗号的にハッシュ化される必要もある。それ以外のすべてが、同一のままである。したがって、それぞれ暗号文または暗号ハッシュが、上で説明したトランザクション認証番号ＴＡＮの代替データ要素として生成され、交換され、検証される。
【０１３３】
サーバ４が、ユーザに対してサーバ４を認証もしなければならない場合に、ステップＳ４１からＳ４３の計算の代わりに、サーバは、暗号文から暗号化解除したナンスＮ＿Ｔａを単純にユーザに表示する。ステップＳ４４〜Ｓ４６の比較は、同一のままであり、計算は不要であるが、ナンスＮ＿Ｔａが単純にディスプレイ２２に表示される。
【０１３４】
この実施形態に対する追加として、個人識別コードＰＩＮ＿Ｕを変更するプロトコルをも実施することができる。新しい個人識別コードＰＩＮ＿Ｕは、単純に、Ｓ６の暗号文へのもう１つの入力である。
【０１３５】
セキュア・セッション確立プロトコル標準規格が、そのプロトコル・フィールドの固定されたフィールド長を指定しないという事実にもかかわらず、一部のクライアント・アプリケーション実施態様が、割り振られたメモリを、たとえば「ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ」メッセージ用に厳密に制限する場合がある。その場合に、楕円曲線暗号など、空間を最適化する公開鍵暗号に焦点を合わせる必要がある。
【０１３６】
個人識別コードＰＩＮ＿Ｕがユーザによって計算される、この実施形態に対する副実施形態もある。このために、ステップＳ６で、個人識別コードＰＩＮ＿Ｕが省略される。ナンスＮ＿Ｔｔが、ステップＳ３１について説明したようにユーザに表示され、トランザクション認証番号ＴＡＮが、ステップＳ３２について説明したように計算される。上で説明した、認証ベース番号Ｎ＿Ｔおよび個人識別コードＰＩＮ＿Ｕからトランザクション認証番号ＴＡＮを生成する他の変形形態を、認証ベース番号Ｎ＿Ｔに同様に適用することができる。
【０１３７】
短い（おそらくは使い捨ての）秘密の鍵を用いる実施形態
スクラッチ・リストまたはインデックス付きスクラッチ・リスト（たとえば、「ｉＴＡＮ」、「インデックス付きスクラッチ・リスト」、「アクセス・カード」）などのコード（または鍵）テーブルが、金融機関によって広く使用されているが、これらは、中間者攻撃に脆弱である。上の「秘密の鍵を用いないがクライアント側でナンスを用いる実施形態」を拡張して、あるレベルの「ツー・ファクタ」認証を達成することができる。
【０１３８】
ステップＳ６ａ（図４、５、６、および７ではステップＳ６として表される） あるアクセス・カードがたとえば１００個のエントリすなわち、４〜６個の数字文字の通常は短い「鍵」（Ｋ＿ＳＳＵ）を有する場合に、ステップＳ４で生成されるデータ・セット（以前のハンドシェーク・メッセージのハッシュ）が、そのアクセス・カードの鍵テーブルに対するルックアップ・インデックスとして働けるようになるまで圧縮される。
【０１３９】
Ｓ６ｂ（図４、５、６、および７ではステップＳ６として表される）では、圧縮された値（通常は２文字の長さ）が、インデックスとして表示される（たとえば、認証モジュール２または認証トークン・デバイス２０によって）。ルックアップ・インデックスをクライアント・アプリケーションに通信する代替の形があり、たとえば、「隠しチャネル」としての上で述べた「ＤｉｓｔｉｎｇｕｉｓｈｅｄＮａｍｅ ｃｅｒｔｉｆｉｃａｔｅ＿ａｕｔｈｏｒｉｔｉｅｓ」リストは、それぞれ認証モジュール２または認証トークン・デバイス２０にステップＳ６ｂで表示すべきインデックスを知らせるもう１つの手法を表すことができる。
【０１４０】
ステップＳ６ｃ（図４、５、６、および７ではステップＳ６として表される）では、前にステップＳ６で入力された値に加えて、セッションによって導出されたルックアップ・インデックスによってルックアップされる鍵Ｋ＿ＳＳＵも入力される。ナンスＮ＿Ｔｔの高い度合のランダムさに起因して、鍵Ｋ＿ＳＳＵを複数回使用することができる。クライアント・アプリケーションが、セキュア・セッション・プロトコル確立メッセージ（具体的にはＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージ）内で通常のメッセージより長い暗号文をトランスポートすることを許容しない場合には、「トランザクション認証番号（ＴＡＮ）なしの実施形態」に基づくもう１つの実施形態があり、上記は、次のステップによって拡張される。
【０１４１】
ステップＳ６ａは、上で説明したままである。ナンスＮ＿Ｔｔのランダムさが利用可能ではないので、鍵Ｋ＿ＳＳＵは１回しか使用することができない。ステップＳ６ｂ’（ステップＳ６ｂを置換する）では、サーバ４が、これまでに使用されたすべてのルックアップを記録する。衝突がある場合には、再ハンドシェークがサーバ４によってトリガされる。これは、未使用のインデックスに達するまで繰り返される。「ＤｉｓｔｉｎｇｕｉｓｈｅｄＮａｍｅ ｃｅｒｔｉｆｉｃａｔｅ＿ａｕｔｈｏｒｉｔｉｅｓ」手法は、この場合により効率的になる可能性がある。あるレベルの使用の後に、新しいアクセス・カードが、帯域外で配布される。
【０１４２】
ステップＳ６ｃ’（ステップＳ６ｃを置換する）で、暗号ハッシュが、ナンスなしで秘密の鍵Ｋ＿Ｔの代わりに生成され、鍵Ｋ＿ＳＳＵが使用される。次に、やはり、後続ステップは、ステップＳ１５まで残る。ステップＳ１５で、鍵Ｋ＿ＳＳＵが短いので、暗号ハッシュ関数は、有効な暗号ハッシュＮ＿ＳＳＵ＝ＣＨ＿｛Ｋ＿ＳＳＵ｝（ｈａｓｈ，ＰＩＮ＿Ｕ）を個人識別コードＰＩＮ＿Ｕおよび鍵Ｋ＿ＳＳＵの１つの対ではなく、個人識別コードＰＩＮ＿Ｕおよび鍵Ｋ＿ＳＳＵの多数の対（個人識別コードＰＩＮ＿Ｕと鍵Ｋ＿ＳＳＵとの両方の組み合わされた「鍵空間」のサイズまで）によって得ることができるようになっていることが重要である。これによって、攻撃者は、推測攻撃で正しい個人識別コードＰＩＮ＿Ｕを見つけたかどうかを知るのではなく、推測を妥当性検査するために必ずサーバ４に暗号ハッシュＮ＿ＳＳＵを提示しなければならない。また、このハッシュは、通常は４０バイト長なので、推測辞書は、この組み合わされた鍵よりはるかに長くする必要があり、セッションを認証にバインドすることに加えて、ここで、ハッシュは「塩」として働く。この鍵空間が十分なエントロピを有し、推測攻撃が通常のサーバ側ログイン・タイムアウトより長い時間を要するようになっている場合に、これは、ローエンド解決策として働くことができる。
【０１４３】
個人識別コードＰＩＮ＿Ｕに対するキー・ロギング攻撃（ｋｅｙ ｌｏｇｇｉｎｇ ａｔｔａｃｋ）を防ぐために、個人識別コードＰＩＮ＿Ｕおよび鍵Ｋ＿ＳＳＵを端末に別々に入力するのではなく、その組合せを入力することができる。
【０１４４】
同様に、鍵Ｋ＿ＳＳＵを、トランザクション認証番号ＴＡＮに基づく上で説明した主実施形態および他の実施形態と共に使用することもできる。
【図面の簡単な説明】
【０１４５】
【図１】ユーザ認証モジュールを備え、認証モジュールを有する通信端末に遠隔通信ネットワークを介して接続された、コンピュータ化されたサーバの例示的構成を概略的に示すブロック図である。
【図２】認証モジュールの例示的構成を概略的に示すブロック図である。
【図３】認証トークン・デバイスとしての認証モジュールの例示的実施を概略的に示すブロック図である。
【図４】遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証する、本発明の実施形態に従って実行されるステップのシーケンスの例を示す流れ図である（「通信端末で入力されるＰＩＮ＿Ｕおよび端末で作成されるＴＡＮ」）。
【図５】ユーザを認証する、本発明のもう１つの実施形態に従って実行されるステップのシーケンスの例を示す流れ図である（「デバイスで入力されるＰＩＮ＿Ｕおよびデバイスで作成されるＴＡＮ」）。
【図６】ユーザを認証する、本発明のもう１つの実施形態に従って実行されるステップのシーケンスの例を示す流れ図である（「ユーザによって心の中で作成されるＴＡＮ」）。
【図７】ユーザを認証する、本発明のもう１つの実施形態に従って実行されるステップのシーケンスの例を示す流れ図である（「ソフトトークン」）。
【図８】通信端末を使用するユーザによって遠隔通信ネットワークを介してアクセスされるサーバを認証する、本発明の実施形態に従って実行されるステップの追加のシーケンスの例を示す流れ図である（「デバイス上のサーバ認証コード」）。
【図９】サーバを認証する、本発明のもう１つの実施形態に従って実行されるステップの追加のシーケンスの例を示す流れ図である（「ソフト・トークン・デバイスによるサーバ認証コード」）。
【図１０】ユーザを認証する、本発明のもう１つの実施形態に従って実行されるステップのシーケンスの例を示す流れ図である（「標準デバイス・インターフェースに基づくチャレンジ・レスポンス」）。
【特許請求の範囲】
【請求項１】
遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証する方法であって、
個人識別コードを前記ユーザから受け取ることと、
前記通信端末と前記サーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージからデータ・セットを生成することと、
前記個人識別コードを使用して、前記データ・セットに基づいてトランザクション認証番号を生成することと、
前記トランザクション認証番号を前記通信端末から前記サーバに送信することと、
前記サーバ内で、前記通信端末と交換された前記セキュア・セッション確立プロトコル・メッセージに基づいて前記トランザクション認証番号を検証することと
を含む方法。
【請求項２】
前記方法が、さらに、前記通信端末に関連する認証モジュール内で前記データ・セットから認証ベース番号を生成することを含み、前記トランザクション認証番号が、前記個人識別コードを使用して前記認証ベース番号から生成され、前記方法が、さらに、前記サーバ内で、交換された前記セキュア・セッション確立プロトコル・メッセージから認証ベース番号を生成することを含み、前記トランザクション認証番号が、前記サーバ内で生成された前記認証ベース番号を使用して前記サーバ内で検証される、請求項１に記載の方法。
【請求項３】
前記方法が、さらに、前記認証ベース番号および前記個人識別コードを前記通信端末に接続されないチャレンジ／レスポンス・トークン・デバイスに入力することを含み、前記トランザクション認証番号が、前記認証ベース番号および前記個人識別コードに基づいてトークン・レスポンス値として前記チャレンジ／レスポンス・トークン・デバイス内で生成され、前記方法が、さらに、前記トランザクション認証番号を前記サーバに送信する前に、前記トランザクション認証番号を前記通信端末に入力することを含む、請求項２に記載の方法。
【請求項４】
前記データ・セットから前記認証ベース番号を生成することが、乱数を生成することと、選択された桁を前記データ・セットから選択することであって、前記桁が前記乱数の桁によって決定される、選択することと、前記選択された桁および前記乱数の前記桁から前記認証ベース番号を合成することとを含む、請求項２または３のいずれか１項に記載の方法。
【請求項５】
前記トランザクション認証番号が、前記通信端末に関連する認証モジュール内で、前記個人識別コードからおよび前記通信端末と前記サーバとの間で交換された前記セキュア・セッション確立プロトコル・メッセージから、鍵として前記サーバと共有される秘密を使用して、鍵付き暗号ダイジェスト値として生成され、前記方法が、さらに、前記サーバ内で、前記サーバに格納された個人識別コードを使用して鍵付き暗号ダイジェスト値を生成することを含み、前記トランザクション認証番号が、前記サーバ内で、前記通信端末から受信された前記鍵付き暗号ダイジェスト値と前記サーバ内で生成された前記鍵付き暗号ダイジェスト値との比較に基づいて検証される、請求項１に記載の方法。
【請求項６】
前記鍵として、前記個人識別コードおよび前記認証モジュールに関連する秘密トークン鍵のうちの１つを使用する、請求項５に記載の方法。
【請求項７】
前記方法が、さらに、前記データ・セットからルックアップ・インデックスを生成することを含み、前記方法が、さらに、前記ルックアップ・インデックスを使用して、選択されたコードをコード・テーブル内で判定することを含み、前記選択されたコードが、前記鍵として使用され、前記サーバが、前記サーバに格納されたコード・テーブルからの選択されたコードを前記鍵として使用して、前記鍵付き暗号ダイジェスト値を生成する、請求項５に記載の方法。
【請求項８】
前記サーバが、前記通信端末によって使用される選択されたコードを追跡し、選択されたコードが以前に前記通信端末によって使用されたと前記サーバが判定する場合に、前記サーバが、前記通信端末とのセッション確立を再開始する、請求項７に記載の方法。
【請求項９】
前記トランザクション認証番号が、前記通信端末に関連する認証モジュール内で、公開鍵を使用して前記データ・セット、前記個人識別コード、および少なくとも１つのナンスを暗号化することによって、暗号文として生成され、前記方法が、さらに、前記サーバ内で、秘密鍵を使用して前記暗号文を暗号化解除することによって、受信されたデータ・セットおよび受信された個人識別コードを判定することを含み、前記トランザクション認証コードが、前記サーバ内で、交換された前記セキュア・セッション確立プロトコル・メッセージから前記サーバ内で生成されたデータ・セットとの前記受信されたデータ・セットの比較および前記サーバに格納された個人識別コードとの前記受信された個人識別コードの比較に基づいて検証される、請求項１に記載の方法。
【請求項１０】
前記方法が、さらに、前記データ・セットからルックアップ・インデックスを生成することと、前記ルックアップ・インデックスを使用して、選択されたコードをコード・テーブル内で判定することとを含み、前記選択されたコードが、前記暗号文を生成するのに使用され、前記サーバが、前記秘密鍵を使用して、受信された選択されたコードを前記暗号文から判定し、前記トランザクション認証番号を検証することが、前記受信された選択されたコードを前記サーバに格納されたコード・テーブルから前記サーバによって判定された選択されたコードと比較することを含む、請求項９に記載の方法。
【請求項１１】
前記サーバが、前記通信端末によって使用される選択されたコードを追跡し、選択されたコードが前記通信端末によって以前に使用されたと前記サーバが判定する場合に、前記サーバが、前記通信端末とのセッション確立を再開始する、請求項１０に記載の方法。
【請求項１２】
前記トランザクション認証番号およびユーザ識別子が、前記通信端末から前記サーバに送信され、前記トランザクション認証番号が、前記ユーザ識別子に割り当てられた前記個人識別コードを使用して前記サーバ内で検証される、請求項１に記載の方法。
【請求項１３】
前記個人識別コードが、バイオメトリック識別子と一緒に前記ユーザから受け取られ、前記トランザクション認証番号が、前記サーバに格納されたバイオメトリック識別子を使用して前記サーバ内で検証される、請求項１２に記載の方法。
【請求項１４】
前記方法が、さらに、前記通信端末に関連する認証モジュール内で、前記認証モジュールに関連する鍵対の秘密鍵を使用して前記データ・セットからディジタル署名を生成することと、前記ディジタル署名を前記通信端末から前記サーバに送信することと、前記サーバ内で前記鍵対の公開鍵を使用して前記ディジタル署名を検証することとを含む、請求項１に記載の方法。
【請求項１５】
前記認証ベース番号が、前記通信端末に関連する認証モジュール内で、前記認証モジュールに関連する秘密トークン鍵を使用して前記データ・セットから生成され、前記認証ベース番号が、前記サーバ内で、前記秘密トークン鍵を使用して、交換された前記セキュア・セッション確立プロトコル・メッセージから生成される、請求項２に記載の方法。
【請求項１６】
前記データ・セットが、前記認証モジュールを前記通信端末に接続するデバイス・インターフェースを介して前記通信端末から前記認証モジュールに転送され、前記秘密トークンが、前記認証モジュールに格納される、請求項１５に記載の方法。
【請求項１７】
トークン識別子が、前記通信端末から前記サーバへ前記トランザクション認証番号と一緒に送信され、前記秘密トークン鍵が、前記トークン識別子に基づいて前記サーバ内で判定される、請求項１６に記載の方法。
【請求項１８】
マスタ鍵が、前記サーバに格納され、前記秘密トークン鍵が、前記サーバ内で、前記トークン識別子を暗号化するために前記マスタ鍵を使用して前記トークン識別子から生成される、請求項１７に記載の方法。
【請求項１９】
前記ユーザが、前記認証モジュールの複数の可能な機関スコープのうちの１つを選択し、前記ユーザによって選択された前記機関スコープが、前記認証モジュールに、前記認証ベース番号を生成するための複数の秘密トークン鍵の組のうちの１つの機関固有秘密トークン鍵を使用させ、前記サーバが、特定の機関に関連し、前記認証ベース番号を生成するのに前記機関固有秘密トークン鍵を使用し、前記サーバが、前記トランザクション認証番号を検証するのに機関固有個人識別コードを使用する、請求項１５に記載の方法。
【請求項２０】
前記認証ベース番号が、前記通信端末に関連する認証モジュールによって表示され、前記個人識別コードおよび前記認証モジュールによって表示された前記認証ベース番号によって前記ユーザによって生成された前記トランザクション認証番号が、前記通信端末内で前記ユーザから受け取られる、請求項２に記載の方法。
【請求項２１】
前記サーバ内での前記トランザクション認証番号の成功の検証の後に、サーバ認証コードが、前記サーバ内で、前記データ・セットに公開関数を適用し、暗号化に秘密トークン鍵を使用して、前記データ・セットから生成され、前記サーバ認証コードが、前記サーバから前記通信端末に送信され、前記サーバから受信された前記サーバ認証コードが、前記通信端末によって表示され、サーバ認証コードが、前記通信端末に関連する認証モジュール内で、前記データ・セットに前記公開関数を適用し、暗号化に前記秘密トークン鍵を使用して、前記データ・セットから生成され、前記認証モジュール内で生成された前記サーバ認証コードが、前記通信端末によって表示される前記サーバ認証コードを用いる視覚的検証のために前記認証モジュールによって表示される、請求項１に記載の方法。
【請求項２２】
通信端末が、
個人識別コードをユーザから受け取り、
前記通信端末とサーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージからデータ・セットを生成し、
前記データ・セットに基づいて、前記個人識別コードを使用してトランザクション認証番号を生成し、
前記トランザクション認証番号を検証のために前記サーバに送信する
ように前記通信端末の１つまたは複数のプロセッサを制御するコンピュータ・プログラム・コード手段を含むコンピュータ・プログラム製品。
【請求項２３】
前記通信端末が、前記データ・セットから認証ベース番号を生成し、前記個人識別コードを使用して前記認証ベース番号から前記トランザクション認証番号を生成するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２２に記載のコンピュータ・プログラム製品。
【請求項２４】
前記通信端末が、乱数を生成し、前記乱数の桁によって決定される選択された桁を前記データ・セットから選択し、前記選択された桁および前記乱数の前記桁から前記認証ベース番号を合成するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２３に記載のコンピュータ・プログラム製品。
【請求項２５】
前記通信端末が、鍵として前記サーバと共有される秘密を使用して、前記個人識別コードからおよび前記通信端末と前記サーバとの間で交換された前記セキュア・セッション確立プロトコル・メッセージから、鍵付き暗号ダイジェスト値として前記トランザクション認証番号を生成するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２２に記載のコンピュータ・プログラム製品。
【請求項２６】
前記通信端末が、前記鍵として、前記個人識別コードおよび秘密トークン鍵のうちの１つを使用するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２５に記載のコンピュータ・プログラム製品。
【請求項２７】
前記通信端末が、前記データ・セットからルックアップ・インデックスを生成することを実行し、前記ルックアップ・インデックスを使用して、選択されたコードをコード・テーブル内で判定し、前記選択されたコードを前記鍵として使用するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２５に記載のコンピュータ・プログラム製品。
【請求項２８】
前記通信端末が、公開鍵を使用して前記データ・セット、前記個人識別コード、および少なくとも１つのナンスを暗号化することによって、前記トランザクション認証番号を暗号文として生成するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２２に記載のコンピュータ・プログラム製品。
【請求項２９】
前記通信端末が、前記データ・セットからルックアップ・インデックスを生成することを実行し、前記ルックアップ・インデックスを使用して、選択されたコードをコード・テーブル内で判定し、前記暗号文を生成するのに前記選択されたコードを使用するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２８に記載のコンピュータ・プログラム製品。
【請求項３０】
前記通信端末が、前記通信端末のセンサを介してバイオメトリック識別子を前記ユーザから受け取り、前記通信端末が、前記個人識別コードとして前記バイオメトリック識別子を使用するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２２に記載のコンピュータ・プログラム製品。
【請求項３１】
前記通信端末が、複数の可能な機関スコープのうちの１つを選択する指示を受け取り、前記通信端末が、前記認証ベース番号を生成するための複数の秘密トークン鍵の組のうちの１つの機関固有秘密トークン鍵を使用するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２３に記載のコンピュータ・プログラム製品。
【請求項３２】
前記通信端末が、前記サーバからサーバ認証コードを受信し、前記通信端末が、前記データ・セットに公開関数を適用し、暗号化に秘密トークン鍵を使用して、前記データ・セットからサーバ認証コードを生成し、前記通信端末が、前記通信端末によって生成された前記サーバ認証コードに基づいて前記サーバから受信された前記サーバ認証コードを検証するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２２に記載のコンピュータ・プログラム製品。
【請求項３３】
遠隔通信ネットワークを介して通信端末とデータを構成するように構成されたコンピュータ化されたサーバであって、
前記通信端末のユーザから受け取られた個人識別コードと、前記通信端末と前記サーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージから生成されたデータ・セットとに基づくトランザクション認証番号を前記通信端末から受信し、
前記通信端末と交換された前記セキュア・セッション確立プロトコル・メッセージに基づいて、受信された前記トランザクション認証番号を検証する
ように構成されたユーザ認証モジュールを含む、サーバ。
【請求項３４】
前記ユーザ認証モジュールが、交換された前記セキュア・セッション確立プロトコル・メッセージから認証ベース番号を生成し、生成された前記認証ベース番号および前記個人識別コードを使用して、受信された前記トランザクション認証番号を検証するように構成される、請求項３３に記載のサーバ。
【請求項３５】
前記ユーザ認証モジュールが、乱数を生成することと、選択された桁を前記データ・セットから選択することであって、前記桁が、前記乱数の桁によって決定される、選択することと、前記選択された桁および前記乱数の前記桁から前記認証ベース番号を合成することとによって、前記認証ベース番号を生成するように構成される、請求項３４に記載のサーバ。
【請求項３６】
前記ユーザ認証モジュールが、前記個人識別コードからおよび前記通信端末と前記サーバとの間で交換された前記セキュア・セッション確立プロトコル・メッセージから、前記サーバに格納された個人識別コードを使用し、前記通信端末と共有される秘密を鍵として使用して、鍵付き暗号ダイジェスト値としてトランザクション認証番号を生成し、受信された前記トランザクション認証番号と前記サーバ内で生成された前記鍵付き暗号ダイジェスト値との比較に基づいて、受信された前記トランザクション認証番号を検証するように構成される、請求項３３に記載のサーバ。
【請求項３７】
前記ユーザ認証モジュールが、前記鍵付き暗号ダイジェスト値を生成するために、前記個人識別コードおよびユーザに関連する秘密トークン鍵のうちの１つを前記鍵として使用するように構成される、請求項３６に記載のサーバ。
【請求項３８】
前記ユーザ認証モジュールが、前記鍵付き暗号ダイジェスト値を生成するために、前記サーバに格納されたコード・テーブルからの選択されたコードを前記鍵として使用するように構成される、請求項３６に記載のサーバ。
【請求項３９】
前記ユーザ認証モジュールが、公開鍵を使用して前記データ・セット、前記個人識別コード、および少なくとも１つのナンスを暗号化することによって、暗号文としてトランザクション認証番号を生成し、秘密鍵を使用して、前記通信端末から受信された暗号文を暗号化解除することによって、受信されたデータ・セットおよび受信された個人識別コードを判定し、前記受信されたデータ・セットと交換された前記セキュア・セッション確立プロトコル・メッセージから前記サーバ内で生成されたデータ・セットとの比較、ならびに前記受信された個人識別コードの前記サーバに格納された個人識別コードとの比較に基づいて、受信された前記トランザクション認証番号を検証するように構成される、請求項３３に記載のサーバ。
【請求項４０】
前記ユーザ認証モジュールが、前記秘密鍵を使用して、前記通信端末から受信された前記暗号文から、受信された選択されたコードを判定し、前記トランザクション認証番号を検証する時に、前記受信された選択されたコードを、前記サーバに格納されたコード・テーブルから判定された選択されたコードと比較するように構成される、請求項３９に記載のサーバ。
【請求項４１】
前記ユーザ認証モジュールが、前記通信端末に関して使用される選択されたコードを追跡し、選択されたコードが前記通信端末によって以前に使用された場合に、前記通信端末とのセッション確立を再開始するように構成される、請求項３８または４０のいずれか１項に記載のサーバ。
【請求項４２】
前記ユーザ認証モジュールが、前記ユーザのバイオメトリック識別子を含む個人識別コードを受け取り、前記サーバに格納されたバイオメトリック識別子を使用して前記トランザクション認証番号を検証するように構成される、請求項３３に記載のサーバ。
【請求項４３】
前記ユーザ認証モジュールが、秘密トークン鍵を使用して、交換された前記セキュア・セッション確立プロトコル・メッセージから前記認証ベース番号を生成するように構成される、請求項３４に記載のサーバ。
【請求項４４】
前記ユーザ認証モジュールが、前記通信端末から前記トランザクション認証番号と共にトークン識別子を受信し、前記トークン識別子に基づいて前記秘密トークン鍵を判定するように構成される、請求項４３に記載のサーバ。
【請求項４５】
前記サーバが、さらに、格納されたマスタ鍵を含み、前記ユーザ認証モジュールが、前記トークン識別子を暗号化するための前記マスタ鍵を使用して前記トークン識別子から前記秘密トークン鍵を生成するように構成される、請求項４３に記載のサーバ。
【請求項４６】
前記ユーザ認証モジュールが、前記トランザクション認証番号の成功の検証の後に、前記データ・セットに公開関数を適用し、暗号化に前記秘密トークン鍵を使用して、前記データ・セットからサーバ認証コードを生成し、前記サーバ認証コードを前記通信端末に送信するように構成される、請求項３３に記載のサーバ。
【請求項４７】
遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザによって個人識別コードを変更する方法であって、
古い個人識別コードを前記ユーザから受け取ることと、
新しい個人識別コードを前記ユーザから受け取ることと、
前記通信端末と前記サーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージからデータ・セットを生成することと、
前記通信端末に関連する認証モジュール内で、前記認証モジュールに関連する秘密トークン鍵を使用して、前記データ・セットから認証ベース番号を生成することと、
前記認証ベース番号、前記古い個人識別コード、および前記新しい個人識別コードから識別変更コードを生成することと、
前記識別変更コードを前記通信端末から前記サーバに送信することと、
前記サーバ内で、前記秘密トークン鍵を使用して、交換された前記セキュア・セッション確立プロトコル・メッセージから認証ベース番号を生成することと、
前記サーバ内で、前記古い個人識別コードおよび前記サーバ内で生成された前記認証ベース番号を使用して、前記識別変更コードから前記新しい個人識別コードを導出することと
を含む方法。
【請求項１】
遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザを認証する方法であって、
個人識別コードを前記ユーザから受け取ることと、
前記通信端末と前記サーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージからデータ・セットを生成することと、
前記個人識別コードを使用して、前記データ・セットに基づいてトランザクション認証番号を生成することと、
前記トランザクション認証番号を前記通信端末から前記サーバに送信することと、
前記サーバ内で、前記通信端末と交換された前記セキュア・セッション確立プロトコル・メッセージに基づいて前記トランザクション認証番号を検証することと
を含む方法。
【請求項２】
前記方法が、さらに、前記通信端末に関連する認証モジュール内で前記データ・セットから認証ベース番号を生成することを含み、前記トランザクション認証番号が、前記個人識別コードを使用して前記認証ベース番号から生成され、前記方法が、さらに、前記サーバ内で、交換された前記セキュア・セッション確立プロトコル・メッセージから認証ベース番号を生成することを含み、前記トランザクション認証番号が、前記サーバ内で生成された前記認証ベース番号を使用して前記サーバ内で検証される、請求項１に記載の方法。
【請求項３】
前記方法が、さらに、前記認証ベース番号および前記個人識別コードを前記通信端末に接続されないチャレンジ／レスポンス・トークン・デバイスに入力することを含み、前記トランザクション認証番号が、前記認証ベース番号および前記個人識別コードに基づいてトークン・レスポンス値として前記チャレンジ／レスポンス・トークン・デバイス内で生成され、前記方法が、さらに、前記トランザクション認証番号を前記サーバに送信する前に、前記トランザクション認証番号を前記通信端末に入力することを含む、請求項２に記載の方法。
【請求項４】
前記データ・セットから前記認証ベース番号を生成することが、乱数を生成することと、選択された桁を前記データ・セットから選択することであって、前記桁が前記乱数の桁によって決定される、選択することと、前記選択された桁および前記乱数の前記桁から前記認証ベース番号を合成することとを含む、請求項２または３のいずれか１項に記載の方法。
【請求項５】
前記トランザクション認証番号が、前記通信端末に関連する認証モジュール内で、前記個人識別コードからおよび前記通信端末と前記サーバとの間で交換された前記セキュア・セッション確立プロトコル・メッセージから、鍵として前記サーバと共有される秘密を使用して、鍵付き暗号ダイジェスト値として生成され、前記方法が、さらに、前記サーバ内で、前記サーバに格納された個人識別コードを使用して鍵付き暗号ダイジェスト値を生成することを含み、前記トランザクション認証番号が、前記サーバ内で、前記通信端末から受信された前記鍵付き暗号ダイジェスト値と前記サーバ内で生成された前記鍵付き暗号ダイジェスト値との比較に基づいて検証される、請求項１に記載の方法。
【請求項６】
前記鍵として、前記個人識別コードおよび前記認証モジュールに関連する秘密トークン鍵のうちの１つを使用する、請求項５に記載の方法。
【請求項７】
前記方法が、さらに、前記データ・セットからルックアップ・インデックスを生成することを含み、前記方法が、さらに、前記ルックアップ・インデックスを使用して、選択されたコードをコード・テーブル内で判定することを含み、前記選択されたコードが、前記鍵として使用され、前記サーバが、前記サーバに格納されたコード・テーブルからの選択されたコードを前記鍵として使用して、前記鍵付き暗号ダイジェスト値を生成する、請求項５に記載の方法。
【請求項８】
前記サーバが、前記通信端末によって使用される選択されたコードを追跡し、選択されたコードが以前に前記通信端末によって使用されたと前記サーバが判定する場合に、前記サーバが、前記通信端末とのセッション確立を再開始する、請求項７に記載の方法。
【請求項９】
前記トランザクション認証番号が、前記通信端末に関連する認証モジュール内で、公開鍵を使用して前記データ・セット、前記個人識別コード、および少なくとも１つのナンスを暗号化することによって、暗号文として生成され、前記方法が、さらに、前記サーバ内で、秘密鍵を使用して前記暗号文を暗号化解除することによって、受信されたデータ・セットおよび受信された個人識別コードを判定することを含み、前記トランザクション認証コードが、前記サーバ内で、交換された前記セキュア・セッション確立プロトコル・メッセージから前記サーバ内で生成されたデータ・セットとの前記受信されたデータ・セットの比較および前記サーバに格納された個人識別コードとの前記受信された個人識別コードの比較に基づいて検証される、請求項１に記載の方法。
【請求項１０】
前記方法が、さらに、前記データ・セットからルックアップ・インデックスを生成することと、前記ルックアップ・インデックスを使用して、選択されたコードをコード・テーブル内で判定することとを含み、前記選択されたコードが、前記暗号文を生成するのに使用され、前記サーバが、前記秘密鍵を使用して、受信された選択されたコードを前記暗号文から判定し、前記トランザクション認証番号を検証することが、前記受信された選択されたコードを前記サーバに格納されたコード・テーブルから前記サーバによって判定された選択されたコードと比較することを含む、請求項９に記載の方法。
【請求項１１】
前記サーバが、前記通信端末によって使用される選択されたコードを追跡し、選択されたコードが前記通信端末によって以前に使用されたと前記サーバが判定する場合に、前記サーバが、前記通信端末とのセッション確立を再開始する、請求項１０に記載の方法。
【請求項１２】
前記トランザクション認証番号およびユーザ識別子が、前記通信端末から前記サーバに送信され、前記トランザクション認証番号が、前記ユーザ識別子に割り当てられた前記個人識別コードを使用して前記サーバ内で検証される、請求項１に記載の方法。
【請求項１３】
前記個人識別コードが、バイオメトリック識別子と一緒に前記ユーザから受け取られ、前記トランザクション認証番号が、前記サーバに格納されたバイオメトリック識別子を使用して前記サーバ内で検証される、請求項１２に記載の方法。
【請求項１４】
前記方法が、さらに、前記通信端末に関連する認証モジュール内で、前記認証モジュールに関連する鍵対の秘密鍵を使用して前記データ・セットからディジタル署名を生成することと、前記ディジタル署名を前記通信端末から前記サーバに送信することと、前記サーバ内で前記鍵対の公開鍵を使用して前記ディジタル署名を検証することとを含む、請求項１に記載の方法。
【請求項１５】
前記認証ベース番号が、前記通信端末に関連する認証モジュール内で、前記認証モジュールに関連する秘密トークン鍵を使用して前記データ・セットから生成され、前記認証ベース番号が、前記サーバ内で、前記秘密トークン鍵を使用して、交換された前記セキュア・セッション確立プロトコル・メッセージから生成される、請求項２に記載の方法。
【請求項１６】
前記データ・セットが、前記認証モジュールを前記通信端末に接続するデバイス・インターフェースを介して前記通信端末から前記認証モジュールに転送され、前記秘密トークンが、前記認証モジュールに格納される、請求項１５に記載の方法。
【請求項１７】
トークン識別子が、前記通信端末から前記サーバへ前記トランザクション認証番号と一緒に送信され、前記秘密トークン鍵が、前記トークン識別子に基づいて前記サーバ内で判定される、請求項１６に記載の方法。
【請求項１８】
マスタ鍵が、前記サーバに格納され、前記秘密トークン鍵が、前記サーバ内で、前記トークン識別子を暗号化するために前記マスタ鍵を使用して前記トークン識別子から生成される、請求項１７に記載の方法。
【請求項１９】
前記ユーザが、前記認証モジュールの複数の可能な機関スコープのうちの１つを選択し、前記ユーザによって選択された前記機関スコープが、前記認証モジュールに、前記認証ベース番号を生成するための複数の秘密トークン鍵の組のうちの１つの機関固有秘密トークン鍵を使用させ、前記サーバが、特定の機関に関連し、前記認証ベース番号を生成するのに前記機関固有秘密トークン鍵を使用し、前記サーバが、前記トランザクション認証番号を検証するのに機関固有個人識別コードを使用する、請求項１５に記載の方法。
【請求項２０】
前記認証ベース番号が、前記通信端末に関連する認証モジュールによって表示され、前記個人識別コードおよび前記認証モジュールによって表示された前記認証ベース番号によって前記ユーザによって生成された前記トランザクション認証番号が、前記通信端末内で前記ユーザから受け取られる、請求項２に記載の方法。
【請求項２１】
前記サーバ内での前記トランザクション認証番号の成功の検証の後に、サーバ認証コードが、前記サーバ内で、前記データ・セットに公開関数を適用し、暗号化に秘密トークン鍵を使用して、前記データ・セットから生成され、前記サーバ認証コードが、前記サーバから前記通信端末に送信され、前記サーバから受信された前記サーバ認証コードが、前記通信端末によって表示され、サーバ認証コードが、前記通信端末に関連する認証モジュール内で、前記データ・セットに前記公開関数を適用し、暗号化に前記秘密トークン鍵を使用して、前記データ・セットから生成され、前記認証モジュール内で生成された前記サーバ認証コードが、前記通信端末によって表示される前記サーバ認証コードを用いる視覚的検証のために前記認証モジュールによって表示される、請求項１に記載の方法。
【請求項２２】
通信端末が、
個人識別コードをユーザから受け取り、
前記通信端末とサーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージからデータ・セットを生成し、
前記データ・セットに基づいて、前記個人識別コードを使用してトランザクション認証番号を生成し、
前記トランザクション認証番号を検証のために前記サーバに送信する
ように前記通信端末の１つまたは複数のプロセッサを制御するコンピュータ・プログラム・コード手段を含むコンピュータ・プログラム製品。
【請求項２３】
前記通信端末が、前記データ・セットから認証ベース番号を生成し、前記個人識別コードを使用して前記認証ベース番号から前記トランザクション認証番号を生成するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２２に記載のコンピュータ・プログラム製品。
【請求項２４】
前記通信端末が、乱数を生成し、前記乱数の桁によって決定される選択された桁を前記データ・セットから選択し、前記選択された桁および前記乱数の前記桁から前記認証ベース番号を合成するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２３に記載のコンピュータ・プログラム製品。
【請求項２５】
前記通信端末が、鍵として前記サーバと共有される秘密を使用して、前記個人識別コードからおよび前記通信端末と前記サーバとの間で交換された前記セキュア・セッション確立プロトコル・メッセージから、鍵付き暗号ダイジェスト値として前記トランザクション認証番号を生成するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２２に記載のコンピュータ・プログラム製品。
【請求項２６】
前記通信端末が、前記鍵として、前記個人識別コードおよび秘密トークン鍵のうちの１つを使用するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２５に記載のコンピュータ・プログラム製品。
【請求項２７】
前記通信端末が、前記データ・セットからルックアップ・インデックスを生成することを実行し、前記ルックアップ・インデックスを使用して、選択されたコードをコード・テーブル内で判定し、前記選択されたコードを前記鍵として使用するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２５に記載のコンピュータ・プログラム製品。
【請求項２８】
前記通信端末が、公開鍵を使用して前記データ・セット、前記個人識別コード、および少なくとも１つのナンスを暗号化することによって、前記トランザクション認証番号を暗号文として生成するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２２に記載のコンピュータ・プログラム製品。
【請求項２９】
前記通信端末が、前記データ・セットからルックアップ・インデックスを生成することを実行し、前記ルックアップ・インデックスを使用して、選択されたコードをコード・テーブル内で判定し、前記暗号文を生成するのに前記選択されたコードを使用するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２８に記載のコンピュータ・プログラム製品。
【請求項３０】
前記通信端末が、前記通信端末のセンサを介してバイオメトリック識別子を前記ユーザから受け取り、前記通信端末が、前記個人識別コードとして前記バイオメトリック識別子を使用するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２２に記載のコンピュータ・プログラム製品。
【請求項３１】
前記通信端末が、複数の可能な機関スコープのうちの１つを選択する指示を受け取り、前記通信端末が、前記認証ベース番号を生成するための複数の秘密トークン鍵の組のうちの１つの機関固有秘密トークン鍵を使用するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２３に記載のコンピュータ・プログラム製品。
【請求項３２】
前記通信端末が、前記サーバからサーバ認証コードを受信し、前記通信端末が、前記データ・セットに公開関数を適用し、暗号化に秘密トークン鍵を使用して、前記データ・セットからサーバ認証コードを生成し、前記通信端末が、前記通信端末によって生成された前記サーバ認証コードに基づいて前記サーバから受信された前記サーバ認証コードを検証するように、前記プロセッサを制御するコンピュータ・プログラム・コード手段をさらに含む、請求項２２に記載のコンピュータ・プログラム製品。
【請求項３３】
遠隔通信ネットワークを介して通信端末とデータを構成するように構成されたコンピュータ化されたサーバであって、
前記通信端末のユーザから受け取られた個人識別コードと、前記通信端末と前記サーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージから生成されたデータ・セットとに基づくトランザクション認証番号を前記通信端末から受信し、
前記通信端末と交換された前記セキュア・セッション確立プロトコル・メッセージに基づいて、受信された前記トランザクション認証番号を検証する
ように構成されたユーザ認証モジュールを含む、サーバ。
【請求項３４】
前記ユーザ認証モジュールが、交換された前記セキュア・セッション確立プロトコル・メッセージから認証ベース番号を生成し、生成された前記認証ベース番号および前記個人識別コードを使用して、受信された前記トランザクション認証番号を検証するように構成される、請求項３３に記載のサーバ。
【請求項３５】
前記ユーザ認証モジュールが、乱数を生成することと、選択された桁を前記データ・セットから選択することであって、前記桁が、前記乱数の桁によって決定される、選択することと、前記選択された桁および前記乱数の前記桁から前記認証ベース番号を合成することとによって、前記認証ベース番号を生成するように構成される、請求項３４に記載のサーバ。
【請求項３６】
前記ユーザ認証モジュールが、前記個人識別コードからおよび前記通信端末と前記サーバとの間で交換された前記セキュア・セッション確立プロトコル・メッセージから、前記サーバに格納された個人識別コードを使用し、前記通信端末と共有される秘密を鍵として使用して、鍵付き暗号ダイジェスト値としてトランザクション認証番号を生成し、受信された前記トランザクション認証番号と前記サーバ内で生成された前記鍵付き暗号ダイジェスト値との比較に基づいて、受信された前記トランザクション認証番号を検証するように構成される、請求項３３に記載のサーバ。
【請求項３７】
前記ユーザ認証モジュールが、前記鍵付き暗号ダイジェスト値を生成するために、前記個人識別コードおよびユーザに関連する秘密トークン鍵のうちの１つを前記鍵として使用するように構成される、請求項３６に記載のサーバ。
【請求項３８】
前記ユーザ認証モジュールが、前記鍵付き暗号ダイジェスト値を生成するために、前記サーバに格納されたコード・テーブルからの選択されたコードを前記鍵として使用するように構成される、請求項３６に記載のサーバ。
【請求項３９】
前記ユーザ認証モジュールが、公開鍵を使用して前記データ・セット、前記個人識別コード、および少なくとも１つのナンスを暗号化することによって、暗号文としてトランザクション認証番号を生成し、秘密鍵を使用して、前記通信端末から受信された暗号文を暗号化解除することによって、受信されたデータ・セットおよび受信された個人識別コードを判定し、前記受信されたデータ・セットと交換された前記セキュア・セッション確立プロトコル・メッセージから前記サーバ内で生成されたデータ・セットとの比較、ならびに前記受信された個人識別コードの前記サーバに格納された個人識別コードとの比較に基づいて、受信された前記トランザクション認証番号を検証するように構成される、請求項３３に記載のサーバ。
【請求項４０】
前記ユーザ認証モジュールが、前記秘密鍵を使用して、前記通信端末から受信された前記暗号文から、受信された選択されたコードを判定し、前記トランザクション認証番号を検証する時に、前記受信された選択されたコードを、前記サーバに格納されたコード・テーブルから判定された選択されたコードと比較するように構成される、請求項３９に記載のサーバ。
【請求項４１】
前記ユーザ認証モジュールが、前記通信端末に関して使用される選択されたコードを追跡し、選択されたコードが前記通信端末によって以前に使用された場合に、前記通信端末とのセッション確立を再開始するように構成される、請求項３８または４０のいずれか１項に記載のサーバ。
【請求項４２】
前記ユーザ認証モジュールが、前記ユーザのバイオメトリック識別子を含む個人識別コードを受け取り、前記サーバに格納されたバイオメトリック識別子を使用して前記トランザクション認証番号を検証するように構成される、請求項３３に記載のサーバ。
【請求項４３】
前記ユーザ認証モジュールが、秘密トークン鍵を使用して、交換された前記セキュア・セッション確立プロトコル・メッセージから前記認証ベース番号を生成するように構成される、請求項３４に記載のサーバ。
【請求項４４】
前記ユーザ認証モジュールが、前記通信端末から前記トランザクション認証番号と共にトークン識別子を受信し、前記トークン識別子に基づいて前記秘密トークン鍵を判定するように構成される、請求項４３に記載のサーバ。
【請求項４５】
前記サーバが、さらに、格納されたマスタ鍵を含み、前記ユーザ認証モジュールが、前記トークン識別子を暗号化するための前記マスタ鍵を使用して前記トークン識別子から前記秘密トークン鍵を生成するように構成される、請求項４３に記載のサーバ。
【請求項４６】
前記ユーザ認証モジュールが、前記トランザクション認証番号の成功の検証の後に、前記データ・セットに公開関数を適用し、暗号化に前記秘密トークン鍵を使用して、前記データ・セットからサーバ認証コードを生成し、前記サーバ認証コードを前記通信端末に送信するように構成される、請求項３３に記載のサーバ。
【請求項４７】
遠隔通信ネットワークを介してサーバにアクセスするのに通信端末を使用するユーザによって個人識別コードを変更する方法であって、
古い個人識別コードを前記ユーザから受け取ることと、
新しい個人識別コードを前記ユーザから受け取ることと、
前記通信端末と前記サーバとの間で交換されたセキュア・セッション確立プロトコル・メッセージからデータ・セットを生成することと、
前記通信端末に関連する認証モジュール内で、前記認証モジュールに関連する秘密トークン鍵を使用して、前記データ・セットから認証ベース番号を生成することと、
前記認証ベース番号、前記古い個人識別コード、および前記新しい個人識別コードから識別変更コードを生成することと、
前記識別変更コードを前記通信端末から前記サーバに送信することと、
前記サーバ内で、前記秘密トークン鍵を使用して、交換された前記セキュア・セッション確立プロトコル・メッセージから認証ベース番号を生成することと、
前記サーバ内で、前記古い個人識別コードおよび前記サーバ内で生成された前記認証ベース番号を使用して、前記識別変更コードから前記新しい個人識別コードを導出することと
を含む方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公表番号】特表２００９−５１０９５５（Ｐ２００９−５１０９５５Ａ）
【公表日】平成２１年３月１２日（２００９．３．１２）
【国際特許分類】
【出願番号】特願２００８−５３３８４５（Ｐ２００８−５３３８４５）
【出願日】平成１８年１０月５日（２００６．１０．５）
【国際出願番号】ＰＣＴ／ＣＨ２００６／０００５４４
【国際公開番号】ＷＯ２００７／０３８８９６
【国際公開日】平成１９年４月１２日（２００７．４．１２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
２．ＪＡＶＡ
【出願人】（５０８１０４２３７）プリヴァスヒア アーゲー (1)
【Ｆターム（参考）】
【公表日】平成２１年３月１２日（２００９．３．１２）
【国際特許分類】
【出願日】平成１８年１０月５日（２００６．１０．５）
【国際出願番号】ＰＣＴ／ＣＨ２００６／０００５４４
【国際公開番号】ＷＯ２００７／０３８８９６
【国際公開日】平成１９年４月１２日（２００７．４．１２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
２．ＪＡＶＡ
【出願人】（５０８１０４２３７）プリヴァスヒア アーゲー (1)
【Ｆターム（参考）】
[ Back to top ]