JP2004532468A - アクセス・デバイスによるコンピュータ・システムへのリプレイ攻撃を識別する方法およびシステム - Google Patents

Abstract

コンピュータ・システム（２５５）へのアクセスを要求しているユーザのデバイス（２０５）を認証する方法が提供される。この方法は、ユーザがそれを介してコンピュータ・システム（２４５）へのアクセスを要求するユーザのデバイス（１０５）の接続アプリケーションで、ユーザの要求ごとに変わる現行セッション・データを暗号化することを含む。次いで、暗号化された現行セッション・データが、次いで暗号解読される平文で通信されるアクセス要求のユーザ認証データに含められる。次いで、基準セッション・データが暗号解読された現行セッション・データと比較され、ユーザ要求は比較の結果に応じて分類される。

Description

【技術分野】
【０００１】
本発明は、一般に、コンピュータ・ネットワーク・セキュリティに関する。より詳細には、本発明は、コンピュータ・ネットワークを無認可のアクセスから保護することに関し、またアクセス・デバイスによるコンピュータ・ネットワークへのリプレイ攻撃を防止する方法およびシステムに関する。
【背景技術】
【０００２】
過去十年間に、インターネットのようなコンピュータ・ネットワークにアクセスするユーザの数は激増した。通常、ユーザはインターネット・サービス・プロバイダ（ＩＳＰ）を介してインターネットにアクセスする。インターネットまたは企業のローカル・エリア・ネットワーク（ＬＡＮ）にアクセスしようとしているネットワーク・ユーザは、一般にＩＤを検証するためにユーザ名とパスワードを入力する必要がある。この過程に関する問題は、多くの標準認証プロトコルを使用しているＩＳＰに送信される際にパスワードが一般的に安全ではないということである。
【０００３】
図１は従来技術のＩＳＰネットワーク構成１００を示す図であるが、ここではネットワーク・ユーザの信用証明書が安全でない方法で認証されている。ＩＳＰネットワーク１４５は、モデム・プール１１５に接続されており、またゲートウェイ１２５を介してインターネット１５０に接続されているネットワーク・アクセス・サーバ（ＮＡＳ）１２０を含む。ＩＳＰネットワーク１４５は、認証サーバ（ＡＡＡサーバ）１３５にも接続されている。ＡＡＡサーバ１３５は、ＩＳＰネットワーク１４５に局所的にあってもよく、あるいはＩＳＰネットワーク１４５から非常に離れた遠隔位置にあってもよい。
【０００４】
インターネット接続を確立するために、ネットワーク・ユーザは、通常、ネットワーク・アクセス・デバイス１０５でダイヤルアップ・ネットワーキング・アプリケーションを実行する。ダイヤルアップ・ネットワーキング・アプリケーションは、公衆交換電話網（ＰＳＴＮ）１４０を介してモデム・プール１１５とモデム・セッションを開始するために、ネットワーク・ユーザ名とネットワーク・パスワードを入力し、モデム１１０を操作するようユーザを促す。モデム・セッションが確立されると、ダイヤルアップ・ネットワーキング・アプリケーションは、データ接続を確立し、ネットワーク・ユーザを認証するためにＮＡＳ１２０との通信を開始する。
【０００５】
コンピュータ間で接続を確立するために使用されるさらに一般的なデータ通信プロトコルの１つはポイント・ツー・ポイント・プロトコル（ＰＰＰ）である。一般にＰＰＰと共に使用される１つの特に良く知られた認証プロトコルは、パスワード認証プロトコル（ＰＡＰ）である。ＰＡＰを使用するよう構成されたダイヤルアップ・ネットワーキング・アプリケーションは、認可確認応答信号が受信されるか、または接続が終了するまで、確立したデータ接続を介してユーザ名とパスワードの対を繰り返し送信する。ダイヤルアップ・ネットワーキング・アプリケーションは、ユーザ名とパスワードを送信する頻度とタイミングを制御するよう構成されている。
【０００６】
ＰＡＰに関する問題は、パスワードがデータ接続を介して送信される前に暗号化されず、平文として送信されるということである。つまり、パスワードがハッカーによる傍受を受けやすいということである。例えば、データ接続にアクセスするハッカーは、ネットワーク監視アプリケーションを使用して、データ接続全体で送信されているデータ・パケットを補足し表示することができる。このようなネットワーク監視アプリケーションは一般的であり、その使用が違法であるためにこれらはしばしばパケット・スニッフィング・アプリケーションまたはパケット・スヌーピング・アプリケーションと呼ばれている。
【０００７】
再度図１を参照すると、ＮＡＳ１２０でユーザ名とパスワードの対が一度受信されると、通常、別の標準認証プロトコルであるリモート認証ダイヤルイン・ユーザ・サービス（ＲＡＤＩＵＳ）が、ＩＳＰ認証システム１５５にネットワーク・ユーザ名とパスワードの対を送信するために使用される。ＲＡＤＩＵＳプロトコルは、パスワードがＩＳＰ認証システム１５５のＡＡＡサーバ１３５に送信される前にそのパスワードの対称暗号化を提供する。この暗号化方法は、ＮＡＳ１２０とＡＡＡサーバ１３５が暗号化アルゴリズムで使用される秘密鍵を共有するので対称と見なされる。ＮＡＳ１２０は、パスワードを「ロック」すなわち暗号化するために秘密鍵を使用し、ＡＡＡサーバ１３５は、当該パスワードを認証データベース１３０に記憶されているパスワードと照合する前に当該パスワードを「アンロック」すなわち暗号解読するために秘密鍵を使用する。
【０００８】
ＲＡＤＩＵＳ対称暗号化方法に関する問題は、「辞書」攻撃として知られている一形態の攻撃を受けやすいということである。辞書攻撃では、暗号化アルゴリズムの知識のあるハッカーは、暗号化されたパスワードをパケット・スニッフィング・アプリケーションによって傍受する。次いでハッカーは、可読文字を生じる鍵が見つかるまで一連の鍵を繰り返し試みる。さらに問題を深刻化させるのは、秘密鍵が一度漏洩すると、ＮＡＳ１２０とＡＡＡサーバ１３５の間で傍受したいかなるパスワードでもハッカーは容易に暗号解読することができるということである。
【０００９】
上述のＰＡＰ／ＲＡＤＩＵＳ認証方法に固有の弱点を受けて、チャレンジ・ハンドシェーク認証プロトコル（ＣＨＡＰ）が開発された。ＣＨＡＰを使用するように実装されたシステムで、ネットワーク・アクセス・デバイス１０５のダイヤルアップ・アプリケーションは、認証プロトコルとしてＰＡＰではなくＣＨＡＰを使用することをＮＡＳと交渉する。次にＮＡＳ１２０は乱数を生成し、それをネットワーク・アクセス・デバイス１０５に送信する。ネットワーク・アクセス・デバイス１０５で実行されているダイヤルアップ・ネットワーキング・アプリケーションは、乱数を使用してパスワードのノンリバーシブル・ハッシュを生成し、そのノンリバーシブル・ハッシュは次いでＮＡＳ１２０に送信される。次いでＮＡＳ１２０は、ＲＡＤＩＵＳプロトコルを使用して、ノンリバーシブル・ハッシュとそのハッシュを生成するために使用された乱数をＡＡＡサーバ１３５に送信する。ＡＡＡサーバ１３５は、認証データベース１３０から平文パスワードを取り出し、ＮＡＳ１２０から受信した乱数を使用してハッシュ・オペレーションを繰り返す。最後に、ＡＡＡサーバ１３５は、その生成されたハッシュ値をＮＡＳ１２０から受信したハッシュ値と比較する。ハッシュ値が同一である場合、認証は成功と見なされ、ＡＡＡサーバ１３５はネットワーク・アクセス・デバイス１０５に適切な確認応答信号を送信する。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
ユーザ認証のためのＣＨＡＰ／ＲＡＤＩＵＳ方法に関する問題は、これら３つのシステム、すなわちネットワーク・アクセス・デバイス１０５、ＮＡＳ１２０、およびＡＡＡサーバ１３５は、安全性が付加されたことを利用するためにＣＨＡＰを使用するよう構成しなければならないということである。これら３つのうちどれかがＣＨＡＰを使用するように構成されていない場合、ネットワーク・アクセス・デバイス１０５のダイヤルアップ・ネットワーキング・アプリケーションは、ＰＡＰを認証プロトコルとして使用することをＮＡＳ１２０と交渉するためにＰＰＰプロトコルを使用する。
【００１１】
ＣＨＡＰ／ＲＡＤＩＵＳ方法を使用することのもう１つの不利な点は、ＣＨＡＰを適切に実施するために、ＡＡＡサーバ１３５は平文パスワードにアクセスしなければならないということである。多くの認証システムは、システムに漏洩が発生しパスワードが盗まれた場合に安全性のリスクが増すので、パスワードは平文形式では記憶しない。
【００１２】
さらに最近では、認証システムは、拡張認証プロトコル（ＥＡＰ）と呼ばれる認証プロトコルを採用している。ＥＡＰは、パスワードをハッシュするためにネットワーク・アクセス・デバイス１０５が使用する乱数をＮＡＳ１２０ではなくＡＡＡサーバ１３５が生成するということを除いて、ＣＨＡＰと略同様に機能する。その結果、ＥＡＰはＣＨＡＰと同じ短所を有することになる。具体的には、認証チェーンのすべてのシステムがＥＡＰを採用している場合にだけＥＡＰは有効である。
【００１３】
ブロードバンド・アクセスの出現により、無線のアクセス・プロバイダと有線（イーサネット（登録商標））のアクセス・プロバイダはどちらも、ウェブ・ブラウザ・ベースの認証システムを採用する。ウェブ・ブラウザは、ユーザの信用証明書をアクセス・ポイントに送信するためにハイパーテキスト転送プロトコル（ＨＴＴＰ）またはセキュア・ソケット・レイヤを介したハイパーテキスト転送プロトコル（ＨＴＴＰＳ）を使用する。ＨＴＴＰに関する問題は、パスワードがデータ接続を介して送信される前に暗号化されず、平文として送信されるということである。つまり、パスワードがハッカーによる傍受を受けやすいということである。例えば、データ接続にアクセスするハッカーは、ネットワーク監視アプリケーションを使用して、データ接続全体で送信されているデータ・パケットを捕足し表示することができる。このようなネットワーク監視アプリケーションは一般的であり、その使用が違法であるためにこれらはしばしばパケット・スニッフィング・アプリケーションまたはパケット・スヌーピング・アプリケーションと呼ばれている。ＨＴＴＰＳに関する問題は、アクセス・ポイントが良く知られた認証局（ＣＡ）から信用証明書を取得する必要があるということである。これは、アクセス・ポイントを設定する費用を上昇させる。ＨＴＴＰＳによって使用される暗号化の強度は、政府の輸出規制の制限を受ける。ウェブ・ブラウザは、ディフォルトの場合は比較的脆弱な鍵を含み、ユーザには輸出規制に応じて暗号化の強度をアップグレードすることが求められる。本明細書の目的のために、用語「接続アプリケーション」は、限定はしないが、ピアツーピア認証アレンジメント、ダイヤラー、スマート・クライアント、ブラウザ、サプリカント、スマート・カード、トークン・カード、ＰＤＡ接続アプリケーション、無線接続、組み込み型認証クライアント、イーサネット接続などの、データを認証する機能を含むいかなるデバイス（ハードウェアとソフトウェアの両方）を含むものと解釈されるべきである。
【００１４】
しばしば発生するさらなる問題は、いわゆる「リプレイ攻撃」である。リプレイ攻撃は、一般に、無認可の人物またはデバイス、例えば認証されていないデバイスが、ネットワークの合法的ユーザのログインｉｄおよびパスワードを入手するためにネットワーク（例えば、インターネット）上で盗聴する場合に行われる。捕捉されたログインｉｄおよびパスワードは、後でいわゆるリプレイ攻撃でシステムにアクセスするために使用される。
【課題を解決するための手段】
【００１５】
本発明により、
ユーザがそれを介してコンピュータ・システムへのアクセスを要求するユーザのデバイスの接続アプリケーションで、ユーザの要求ごとに変わる現行セッション・データを暗号化するステップと、
暗号化された現行セッション・データを、平文で通信されるアクセス要求のユーザ認証データに含めるステップと、
アクセス要求を暗号解読し、基準セッション・データを暗号解読された現行セッション・データと比較するステップと、
比較の結果に応じてユーザの要求を選択的に分類するステップと
を含むコンピュータ・システムへのアクセスを要求しているユーザのデバイスを認証する方法が提供される。
【００１６】
さらに本発明により、
暗号化されたアクセス要求を平文でアクセス・デバイスから受信するステップと、
アクセス要求を暗号解読し、アクセス・デバイスによって生成された、アクセス要求内の現行セッション・データを識別するステップと、
暗号解読された現行セッション・データを基準セッション・データと比較するステップと、
比較の結果に応じてユーザの要求をリプレイ攻撃として選択的に分類するステップと
含むコンピュータ・システムへのアクセスを要求しているアクセス・デバイスによるリプレイ攻撃を識別する方法が提供される。
【００１７】
さらに本発明により、
ユーザがコンピュータへのアクセスを要求する、ユーザのデバイスの接続アプリケーションで、ユーザの要求ごとに変わる現行セッション・データを生成するセッション・データ・ジェネレータと、
平文で通信される暗号化されたアクセス要求を提供するために、現行セッション・データを暗号化し、これをユーザ認証データに含める暗号化モジュールと、
暗号化されたアクセス要求を暗号解読するプロセッサと、
基準セッション・データを暗号解読された現行セッション・データと比較するコンパレータであって、プロセッサが比較の結果に応じてユーザの要求を選択的に分類するコンパレータと
を含むコンピュータへのアクセスを要求しているユーザのデバイスを認証するシステムが提供される。
【００１８】
さらに本発明により、
平文である暗号化されたアクセス要求をアクセス・デバイスから受信するレシーバーと、
アクセス・デバイスによって生成された、アクセス要求内の現行セッション・データを暗号解読し、識別するプロセッサと、
暗号解読された現行セッション・データを基準セッション・データと比較するコンパレータであって、プロセッサが比較の結果に応じてユーザの要求をリプレイ攻撃として選択的に分類するコンパレータと
を含むコンピュータ・システムへのアクセスを要求しているアクセス・デバイスによるリプレイ攻撃を識別するコンピュータ・サーバが提供される。
【００１９】
本発明は、本明細書で記述された方法のどれでも実行するように一連の命令を組み込んだ機械可読媒体に拡張される。
【００２０】
本発明の他の特徴および利点は、図面および以下の詳細な説明から明らかになろう。
【００２１】
本発明は、一例として説明するものであり、添付の図面の各図によって限定されることを意図するものではない。尚、添付の図面では、同様の参照は同一または類似の要素を示している。
【発明を実施するための最良の形態】
【００２２】
ネットワーク・ユーザの信用証明書またはユーザを安全に認証する方法およびシステムが開示される。ネットワーク・アクセス・デバイスは、ネットワーク・ユーザによって入力されたパスワードのようなネットワーク・ユーザの信用証明書を暗号化する。ネットワーク・アクセス・デバイスは、強力な暗号化アルゴリズムによって生成された公開／秘密鍵対の一部である公開鍵によってネットワーク・ユーザの信用証明書を暗号化する。ネットワーク・アクセス・デバイスは、暗号化されたネットワーク・パスワードをネットワーク暗号解読サーバに送信する。ネットワーク暗号解読サーバは、公開／秘密鍵対の秘密鍵を使用してネットワーク・ユーザの信用証明書を暗号解読する。ネットワーク暗号解読サーバは、暗号解読されたパスワードを検証するために認証サーバ（ＡＡＡ）に送信する。パスワードがＡＡＡサーバで肯定的に検証された場合、ＡＡＡサーバは、パスワードが適切に検証されたこと、すなわち認証されたことを示す適切な確認応答信号をネットワーク・アクセス・デバイスに送信する。この確認応答信号に基づいて、ネットワーク・アクセス・デバイスは、インターネットまたは何らかの他のソースに対するアクセスを得る。
【００２３】
ネットワーク・アクセス・デバイスで強力なアルゴリズムに基づき非対称公開鍵を使用してネットワーク・パスワードを暗号化することにより、パスワードをネットワーク・アクセス・デバイスからネットワーク暗号解読サーバに安全に送信することができる。暗号化されたパスワードが、ネットワーク・アクセス・デバイスとネットワーク暗号解読サーバの間のある地点でスニッフィング・アプリケーションまたはスヌーピング・アプリケーションによって捕足される場合、暗号化されたパスワードは正確な秘密鍵の知識と暗号化アルゴリズムによってのみ暗号解読することができる。ユーザの信用証明書の暗号解読は、ユーザがアクセスすることを希望しているソースのできる限り近くで行われることが好ましい。
【００２４】
図示した本発明の実施形態は基礎となる認証プロトコルには依存せず、したがって様々な新しい認証プロトコルと既存の認証プロトコルと共に機能するよう実現することができる。さらに本発明の実施形態は、認証チェーンの機能を完全に標準化する必要性を解決しながら、安全な認証を提供する。例えば暗号化されたデータを標準ＰＰＰ／ＲＡＤＩＵＳ情報フィールドを通過させることによって、本発明は、ＣＨＡＰやＥＡＰのようなさらに複雑な認証プロトコルと共に機能するようネットワーク機器を実装し、構成する労力と費用を掛けずに安全な認証方法を提供する。しかし、本発明はＣＨＡＰ、ＥＡＰ、および他のプロトコルと共に使用することができ、ＰＡＰ／ＲＡＤＩＵＳ環境のアプリケーションに限定されるものではないということを理解されたい。
【００２５】
図２は、本発明の一実施形態と一致する、ＩＳＰネットワーク２５５、ネットワーク・アクセス・デバイス２０５、およびネットワーク暗号解読サーバ２４０を含むネットワーク構成２００を示す図である。ＩＳＰネットワーク２５５は、ＮＡＳ２２０、モデム・プール２１５、およびゲートウェイ２２５を含む。ＩＳＰネットワーク２５５はゲートウェイ２２５を介してインターネットに接続されており、ＮＡＳ２２０とネットワーク暗号解読サーバ２４０の間の接続を介してＩＳＰ認証システム２６５に接続されている。一実施形態では、ＩＳＰネットワーク２５５とＩＳＰ認証システム２６５は物理的に同じファシリティ内に配置されている。しかし代替形態では、ＩＳＰ認証システム２６５は１つのファシリティ内に配置されており、ワイド・エリア・ネットワーク（ＷＡＮ）を介してＩＳＰネットワーク２５５のような１つまたは複数のＩＳＰネットワークに接続されている。この種の構成は、個々のＩＳＰネットワークを異なる地理的領域内に戦略的に配置することを可能にし、したがって安全性を増すために認証システムを集中化しながら顧客はローカルな電話の呼によってネットワークにアクセスすることができる。
【００２６】
本発明の一実施形態では、インターネット２６０にアクセスするために、ネットワーク・ユーザはネットワーク・アクセス・デバイス２０５でダイヤルアップ接続アプリケーションを実行する。代替形態では、インターネットにアクセスするために他のタイプのネットワーク接続アプリケーションを利用することができる。ダイヤルアップ接続アプリケーションは、ネットワーク・ユーザ名とネットワーク・パスワードを入力し、モデム２１０を操作してモデム・プール２１５との音声通信セッションを確立するようネットワーク・ユーザを促す。図２ではモデム２１０は外部デバイスとして示してあるが、本発明の代替形態では、モデム２１０はネットワーク・アクセス・デバイス２０５に内蔵した内部デバイスであってよい。音声通信セッションが確立されると、ＮＡＳ２２０はネットワーク・ユーザを認証するためにネットワーク・アクセス・デバイス２０５との通信を開始する。
【００２７】
ネットワーク・アクセス・デバイス２０５がネットワーク・ユーザによって入力されたネットワーク信用証明書を送信する前に、ネットワーク・パスワードが暗号化される。パスワードは公開／秘密鍵対の公開鍵を使用して暗号化される。この暗号化技術は当技術分野では良く知られており、一般には非対称公開鍵暗号法と呼ばれている。非対称公開鍵暗号法では、人は１つの鍵を公的に使用可能とし、第２の秘密鍵を保持する。メッセージは公開鍵によって「ロック」すなわち暗号化され、送信され、次いで秘密鍵によって「アンロック」すなわち暗号解読される。
【００２８】
図示する本発明の本実施形態では、公開／秘密鍵対を生成するために強力な暗号化アルゴリズムが使用される。公開鍵と秘密鍵は楕円曲線に基づく数学的関係を有している。この暗号化技術は当技術分野では良く知られており、一般には楕円曲線暗号法またはＥＣＣと呼ばれている。公開鍵暗号化アルゴリズムは、秘密鍵から公開鍵を生成することは容易になるが、公開鍵が与えられて秘密鍵を推論することは困難な一方向性の数学的な問題に依存している。楕円曲線システムは、楕円曲線によって作成された母集団内の公開鍵と秘密鍵の間の関係を決定するために数式を使用する。楕円曲線暗号法は、他の強力な暗号技術と比べて鍵のサイズが小さいので有利である。これはパスワードを強力な暗号化方法で暗号化することを可能にしながら、暗号化されたパスワードは尚もＰＡＰ、ＣＨＡＰ、ＥＡＰ、およびＲＡＤＩＵＳのような普及している認証プロトコルによって定義されるパスワード・データ・フィールドに適合する。
【００２９】
再度図２を参照すると、秘密鍵は秘密鍵データベース２４５に記憶させておき、公開鍵はネットワーク・アクセス・デバイス２０５に知られている。ネットワーク・アクセス・デバイス２０５は、ネットワーク・ユーザ名と暗号化されたネットワーク・パスワードをＮＡＳ２２０に送信する前に公開鍵を使用してパスワードを暗号化する。ＮＡＳ２２０は、ネットワーク・ユーザ名と暗号化されたネットワーク・パスワードをネットワーク暗号解読サーバ２４０に転送する。ネットワーク暗号解読サーバ２４０は、秘密鍵データベース２４５へのインデックスとしてネットワーク・ユーザ名を使用し、ネットワーク・ユーザ名に関連付けられた秘密鍵を取り出す。次いでネットワーク暗号解読サーバ２４０は、秘密鍵を使用して、暗号化されたネットワーク・パスワードを暗号解読し、ネットワーク・ユーザによって入力されたオリジナルの平文パスワードを生成する。
【００３０】
最後に、ネットワーク暗号解読サーバ２４０は、ネットワーク・ユーザ名と平文ネットワーク・パスワードを検証するためにＡＡＡサーバ２３５に転送する。ＡＡＡサーバ２３５は、ネットワーク・ユーザ名に関連付けられた公式パスワードを取り出すために、認証データベース２３０へのインデックスとしてネットワーク・ユーザ名を使用する。公式パスワードがネットワーク・ユーザによって入力され、ネットワーク・アクセス・デバイス２０５によって送信されたパスワードと一致する場合、ＡＡＡサーバ２３５は適切な確認応答信号をＮＡＳ２２０に送信し、ＮＡＳ２２０はその信号をネットワーク・アクセス・デバイス２０５に転送し、これにより成功した検証の確認応答を行い、インターネットまたはある種の他のソースへのアクセスを認める。
【００３１】
本発明の一実施形態は、ネットワーク・アクセス・デバイス２０５からＮＡＳ２２０に、最終的にはＡＡＡサーバ２３５に信用証明書を送信するために使用される認証プロトコルには依存しない。例えば、本発明は、特にＰＡＰ、ＣＨＡＰ、ＥＡＰ、およびＲＡＤＩＵＳのような普及している認証プロトコルと共に機能するように実施することができる。
【００３２】
本発明の一実施形態に関して、ＮＡＳ２２０はネットワーク・ユーザの信用証明書を認証するためにＰＡＰおよびＲＡＤＩＵＳを使用するよう構成されている。ＰＡＰ／ＲＡＤＩＵＳ用に構成されている場合、ＮＡＳ２２０は、ＮＡＳ２２０とネットワーク・アクセス・デバイス２０５の間で通信セッションが開始される際に、ＰＡＰの使用についてネットワーク・アクセス・デバイス２０５と交渉する。ＮＡＳ２２０は、ＲＡＤＩＵＳサーバであるＡＡＡサーバ２３５のＲＡＤＩＵＳクライアントとして構成される。ネットワーク暗号解読サーバ２４０はＲＡＤＩＵＳサーバとしても構成されているが、ＡＡＡサーバ２３５に対してＲＡＤＩＵＳプロキシ・クライアントとして動作する。この構成では、ネットワーク・アクセス・デバイス２０５は、ネットワーク・ユーザによって入力された際にパスワードを暗号解読する。次いでネットワーク・アクセス・デバイス２０５はＰＡＰパケットを作成し、ネットワーク・ユーザ名と暗号化されたネットワーク・パスワードをパケット内の適切なフィールドに置く。次にネットワーク・アクセス・デバイス２０５はＰＡＰパケットをＮＡＳ２２０に送信する。ＮＡＳ２２０は、ＲＡＤＩＵＳパケットを使用してデータをネットワーク暗号解読サーバ２４０に転送する。ネットワーク暗号解読サーバ２４０はパスワードを暗号解読し、ＲＡＤＩＵＳを使用して検証のために平文パスワードをＡＡＡサーバ２３５に転送する。
【００３３】
代替形態では、ＮＡＳ２２０は、ネットワーク・ユーザの信用証明書を認証するためにＣＨＡＰとＲＡＤＩＵＳを使用するように構成される。ＣＨＡＰ／ＲＡＤＩＵＳを使用するように構成されているネットワークでは、ＮＡＳ２２０はＰＡＰではなくＣＨＡＰを認証プロトコルとして使用することをネットワーク・アクセス・デバイス２０５と交渉する。次にＮＡＳ２２０は乱数を生成し、それをネットワーク・アクセス・デバイス２０５に送信する。ネットワーク・アクセス・デバイス２０５上で実行されているダイヤルアップ接続アプリケーションは、事前設定された暗号化アルゴリズムを使用してパスワードのノンリバーシブル・ハッシュを生成するために乱数を使用する。実際のパスワードを暗号化するのではなく、ネットワーク・アクセス・デバイス２０５は、上記の本発明の本実施形態によりネットワーク・パスワードのノンリバーシブル・ハッシュを暗号化する。ネットワーク・アクセス・デバイス２０５はＣＨＡＰパケットを作成し、ネットワーク・ユーザ名と暗号化されたノンリバーシブル・ハッシュをＮＡＳ２２０に送信する。
【００３４】
ＮＡＳ２２０は、ネットワーク・ユーザ名、暗号化されたノンリバーシブル・ハッシュ、およびノンリバーシブル・ハッシュを生成するために使用されたオリジナルの乱数を含むデータを、ＲＡＤＩＵＳプロトコルを使用してネットワーク暗号解読サーバ２４０に送信する。ネットワーク暗号解読サーバ２４０はそのノンリバーシブル・ハッシュを暗号解読し、ＲＡＤＩＵＳパケット内のノンリバーシブル・ハッシュと置き換え、これがＡＡＡサーバ２３５に転送される。
【００３５】
ＡＡＡサーバ２３５はこのパケットを受信し、認証データベース２３０からネットワーク・ユーザ名に関連付けられたパスワードを取り出す。ＡＡＡサーバ２３５は、ＮＡＳ２２０で元々生成された乱数を使用して、認証データベース２３０から取り出されたオリジナルのパスワードに対してハッシュ・オペレーションを実行する。次にＡＡＡサーバ２３５は、それ自体が生成したハッシュを、ネットワーク・アクセス・デバイス２０５から受信したハッシュと比較する。２つのハッシュが一致する場合、検証は成功し、ＡＡＡサーバ２３５は、適切な確認応答信号をネットワーク・アクセス・デバイス２０５に送信し、インターネット２６０またはある種の他のソースへのアクセスを与える。
【００３６】
本発明の別の実施形態では、ＮＡＳ２２０はＥＡＰおよびＲＡＤＩＵＳを使用するように構成されている。ＥＡＰは、ネットワーク・アクセス・デバイス２０５に送信される乱数がＮＡＳ２２０ではなくＡＡＡサーバ２３５によって生成されることを除いて、ＣＨＡＰと略同様に機能する。本発明はいかなる認証プロトコルとでも共に機能するので、本発明は様々なネットワーク構成と共に機能するように容易に実現することができ、ＬＥＧＡＣＹシステムを使用した非常に強力な最低レベルの安全性を提供することができる。
【００３７】
図３は、本発明の一実施形態と調和する、遠隔ＩＳＰネットワーク３６５、ネットワーク・アクセス・デバイス３０５、およびネットワーク暗号解読サーバ３５０を含むネットワーク構成３００を示す図である。遠隔ＩＳＰネットワーク３６５は、ＮＡＳ３２０、モデム・プール３１５、およびゲートウェイ３２５を含む。遠隔ＩＳＰネットワーク３６５は、ゲートウェイ３２５を介してインターネット３７０に接続されており、ＮＡＳ３２０とＡＡＡサーバ３３５の間の接続を介して遠隔ＩＳＰ認証システム３７５に接続されている。遠隔ＩＳＰ認証システム３７５は、ＡＡＡサーバ３３５とネットワーク暗号解読サーバ３５０との間のＷＡＮ接続を介してローカルＩＳＰ認証システム３８０に接続されている。
【００３８】
構成３００は、ネットワーク・ユーザがネットワーク・アクセス・デバイス３０５を使用して遠隔ＩＳＰネットワーク３６５によってインターネット３７０にアクセスすることができる。ローカルＩＳＰ認証システム３８０を運営・維持管理するローカルＩＳＰは、ローカルＩＳＰのネットワーク・ユーザが、遠隔ＩＳＰによって維持管理・運営されている遠隔ＩＳＰネットワーク３６５を介してインターネットにアクセスすることができるように、遠隔ＩＳＰと協定を結ぶ。この種の業務協定は、遠隔ＩＳＰが遠隔の地理的領域またはローカルＩＳＰと異なる国家に配置されている場合に発生する場合がある。図３に示す本発明の実施形態は、ローカルＩＳＰの運営者が、遠隔ＩＳＰネットワーク３６５と遠隔ＩＳＰ認証システム３７５から構成される機器にアクセスした人物を制御することが不可能なので、この種の構成では特に有利である。さらに遠隔ＩＳＰネットワーク３６５は、パスワードの暗号化されたバージョンにだけアクセスし、これにより安全性は強化される。
【００３９】
図３に示す本発明の実施形態は、暗号化されたパスワードが遠隔ＩＳＰネットワーク３６５と遠隔ＩＳＰ認証システム３７５を通過することを除いて、図２に関して上述した方法と略同様の方法で機能する。図３を参照すると、インターネット３７０にアクセスするために、ネットワーク・ユーザは、ネットワーク・アクセス・デバイス３０５のダイヤルアップ接続アプリケーションを実行する。ダイヤルアップ接続アプリケーションは、ネットワーク・ユーザ名とネットワーク・パスワードを入力し、モデム３１０を操作してモデム・プール３１５と音声通信セッションを確立するようネットワーク・ユーザを促す。一度音声通信セッションが確立されると、ＮＡＳ３２０はネットワーク・ユーザを認証する目的でネットワーク・アクセス・デバイス３０５との通信を開始する。
【００４０】
ネットワーク・パスワードをＮＡＳ３２０に送信する前に、ネットワーク・アクセス・デバイス３０５は、上記のように公開鍵によってネットワーク・パスワードを暗号化する。次いでネットワーク・アクセス・デバイス３０５は、ローカルＩＳＰ認証システム３８０宛てのデータ・パケットを作成し、そのパケットを遠隔ＩＳＰ３６５のＮＡＳ３２０に転送する。ＮＡＳ３２０は、暗号化されたパスワードを含んでいるそのデータ・パケットを受信し、それを特に遠隔ＩＳＰ認証システム３７５とＡＡＡサーバ３３５に転送する。ＡＡＡサーバ３３５はそのデータ・パケットを検査し、それがローカルＩＳＰ認証システム３８０宛てであることを発見し、そのデータ・パケットをネットワーク暗号解読サーバ３５０に転送する。
【００４１】
ネットワーク暗号解読サーバ３５０はそのデータ・パケットを受信し、秘密鍵データベース３３５からネットワーク・ユーザ名に関連付けられた秘密鍵を取り出す。次いでネットワーク暗号解読サーバ３５０は、暗号化されたパスワードを暗号解読し、検証するためにそのデータ・パケットを平文パスワードと共にＡＡＡサーバ３４５に転送する。ＡＡＡサーバ３４５は、認証データベース３４０からユーザ名に関連付けられた平文パスワードを取り出すために、認証データベース３４０へのインデックスとしてネットワーク・ユーザ名を使用する。取り出されたパスワードが、ネットワーク・アクセス・デバイス３０５から受信したパスワードと一致する場合、ＡＡＡサーバ３４５は、適切な確認応答信号を遠隔ＩＳＰ３６５のＡＡＡサーバ３３５に送信する。ＡＡＡサーバ３３５は、その信号をＮＡＳ３２０に転送する。ＮＡＳ３２０は、その信号をネットワーク・アクセス・デバイス３０５に転送し、成功した検証を確認応答し、インターネットまたはある種の他のソースへのアクセスを認める。したがって、ユーザに関連付けられたローカルＩＳＰの近くで暗号解読が行われ、暗号化された認証データにアクセスするのは任意の１つまたは複数の中間ＩＳＰだけである。
【００４２】
図４は、本発明の一実施形態と調和する、ネットワーク・ユーザの信用証明書を安全に認証する方法の動作４００の流れ図である。この方法は動作４０５から開始される。動作４０５で、ネットワーク・アクセス・デバイスは、公開／秘密鍵対の一部である公開鍵を使用してパスワードのようなネットワーク信用証明書を暗号化する。公開／秘密鍵対は、楕円曲線暗号法のような強力な暗号化アルゴリズムに基づいて前もって生成されている。
【００４３】
動作４１０で、ネットワーク・アクセス・デバイスは暗号化されたネットワーク信用証明書をネットワーク暗号解読サーバに送信する。暗号化されたパスワードは、最終的にネットワーク暗号解読サーバに到達する前にネットワーク・アクセス・サーバとＡＡＡサーバを含む複数のネットワーク・ノードを介して転送される。
【００４４】
動作４１５で、ネットワーク暗号解読サーバは、上記の公開／秘密鍵対の秘密鍵を使用して暗号化されたネットワーク信用証明書を暗号解読する。ネットワーク暗号解読サーバは、ユーザ名を秘密鍵データベースへのインデックスとして使用して秘密鍵データベースから秘密鍵を取り出す。
【００４５】
最後に、動作４２０で、ネットワーク暗号解読サーバは、暗号解読されたネットワーク信用証明書を検証するためにＡＡＡサーバに送信する。最終的に検証のためＡＡＡサーバに到達する前に、ネットワーク・アクセス・サーバまたは他のＡＡＡサーバのようないくつかのネットワーク・ノードを介して暗号解読されたネットワーク信用証明書を転送することができる。
【００４６】
本発明の典型的な適用例はマルチパーティ・サービス・アクセス環境であるが、そのアプリケーションについては後述する。このような適用例は、通常、ローミング・ユーザ、複数のサービス・プロバイダ、および複数の顧客を含む。さらに、このような適用例は、通常は、ＰＡＰ、ＣＨＡＰ、ＥＡＰ、ＲＡＤＩＵＳ、またはユーザの信用証明書を安全でない方法で通信する類似のプロトコルを使用する。しかし、後述する実施形態は、ＬＥＧＡＣＹシステムでの安全な認証を可能にする。
【００４７】
用語
本明細書の目的で、「サービス・アクセス・トランザクション」という用語は、ユーザ・セッションに関するサービス顧客とサービス・プロバイダとの間のいかなるトランザクションをも含んでいる。このようなサービスの一例として、任意の媒体またはプロトコルを介した任意の通信ネットワークへのアクセスをあげることができる。例えば通信ネットワークは、パケット交換ネットワーク、回線交換ネットワーク、ケーブル・ネットワーク、衛星ネットワーク、地上ネットワーク、有線ネットワーク、または無線ネットワークを含むことができる。しかし「サービス・アクセス・トランザクション」という用語は、ネットワーク・アクセス・トランザクションに限定されるものではなく、コンテンツ・サービス、商取引サービス、および通信サービスのような多数の他のサービスの任意の１つへのアクセスに関するトランザクションを含むものである。
【００４８】
本発明の目的のために、「顧客」という用語は、サービス・アクセスが顧客によって行われるか否かに関わらず、サービス・アクセスの購入および／または消費に関与する任意のエンティティを含む。例えば「顧客」は、実際にサービス・アクセスを利用するエンド・ユーザ消費者、またはそのようなエンド・ユーザが属している企業体、インターネット・サービス・プロバイダ、インターネット通信事業者、再販業者、またはチャネルであってよい。
【００４９】
マルチパーティ・サービス・アクセス環境
本発明の本実施形態は、サービス・プロバイダ（例えばＩＳＰ、無線サービス・プロバイダ、ＶＰＮサービス・プロバイダ、コンテンツ配信サービス・プロバイダ、電子商取引サービス・プロバイダ、またはアプリケーション・サービス・プロバイダ）が標準通信プロトコル（例えばＰＰＰ、ＨＴＴＰ）および標準認証プロトコル（例えばＲＡＤＩＵＳ、ＰＡＰ、ＥＡＰなど）を使用してマルチパーティ・アクセス環境で比較的安全なサービス・アクセスを提供できるようにする、サービス・アクセス（例えばインターネット・アクセス、コンテンツ・アクセス、商取引アクセス、または通信アクセス）サービス用のマルチパーティ・アクセス・ブローカー／設定システムを開示する。このようなプロトコルは、通常、最大長のユーザ・フィールドを規定し、本発明の実施形態は、特に上記の最大長のフィールド内で安全な認証を提供する方法およびシステムを記述する。したがって、本発明はＬＥＧＡＣＹシステムに適用することができる。
【００５０】
概要
図５は、多数のサービス・プロバイダ４５２、アクセス・ブローカー・システム４５４、および複数の顧客（または消費者）４５６を含むネットワーク・アクセス環境の一形態であるマルチパーティ・サービス・アクセス環境例４５０のブロック図である。高レベルでは、サービス・プロバイダ４５２は、アクセス・ブローカー・システム４５４を介して複数の顧客４５６に販売されるサービス（例えばアクセス・サービス、コンテンツ・サービス、電子商取引サービスなどの）・キャパシティを有する。したがって、アクセス・ブローカー・システム４５４は、顧客４５６に転売されるサービス・キャパシティ（例えばサービス・アクセス）を購入すると見なすことができる。サービスへのアクセスはネットワーク・アクセスとして後述されているが、アクセスはサービスの一例として後述されており、本明細書の目的では上記のアクセスのどの形態でも含むものと見るべきであるということが理解されよう。本実施形態では、サービス・プロバイダ４５２は、ＩＳＰ４５８（例えばＵＵＮｅｔ技術、Ｇｅｎｕｉｔｙ、ＣｏｍｐｕＳｅｒｖｅ Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅｓ、ＥＱＵＡＮＴ、Ｈｏｎｇ Ｋｏｎｇ Ｔｅｌｅｃｏｍなど）、無線アクセス・プロバイダ４６０（例えばＶｅｒｉｚｏｎ、Ｓｐｒｉｎｔ、Ｐａｃｉｆｉｃ Ｂｅｌｌ）、コンテンツ配信プロバイダ４６２、および電子商取引プロバイダ４６４のような任意の通信ネットワーク・サービス・プロバイダを含むことができる。しかしサービス・プロバイダ４５２は、任意の数のサービス（数例をあげるならば、例えばアクセス・サービス、コンテンツ・サービス、通信サービス、または電子商取引サービス）を提供する任意の種類のサービス・プロバイダをいくつでも含むことができる。
【００５１】
アクセス・ブローカー・システム例４５４は多数の構成要素を含む。接続アプリケーションは、通常、ダイヤルアップ・アプリケーションまたは接続ダイヤラー４６６の形態で、通信ネットワークへの便利なアクセスに役立つ顧客４５６のサービスまたはネットワーク・アクセス・デバイス（例えば図２および３のアクセス・デバイス２０５、３０５のようなコンピュータ・システム）にインストールされているクライアント・アプリケーションである。一実施形態では、接続ダイヤラー４６６は、アクセス・ブローカー・システム４５４の世界規模の接続ネットワークへのダイヤリングのために簡単なポイント・アンド・クリック・インターフェースを提供することができる。この目的のために、接続ダイヤラー４６６は、潜在的に異なる設定とダイヤルアップ・スクリプト記述情報と共に世界中の複数のＩＳＰに対する複数の電話番号を記憶することができる。図１から４に関して上記で概説したように、ポイント・ツー・ポイント・プロトコル（ＰＰＰ）、パスワード認証プロトコル（ＰＡＰ）、チャレンジ・ハンドシェーク認証プロトコル（ＣＨＡＰ）、遠隔認証ダイヤルイン・ユーザ・サービス（ＲＡＤＩＵＳ）プロトコル、ターミナル・アクセス・コントローラ・アクセス制御システム（ＴＡＣＡＣＳ）プロトコル、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）、ＮＴドメイン認証プロトコル、Ｕｎｉｘ（登録商標）パスワード認証プロトコル、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュア・ソケット・レイヤを介したハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、拡張認証プロトコル（ＥＡＰ）、転送レイヤ・セキュリティ（ＴＬＳ）プロトコル、トークン・リング・プロトコルおよび／またはセキュア遠隔パスワード・プロトコル（ＳＲＰ）のような周知のプロトコルによって許可または可能とされるユーザ・ストリングにユーザ・データとカウンター・データを含むことができるような方法で接続ダイヤラー４６６はユーザ・データとカウンター・データを暗号化する。
【００５２】
環境４５０は、ユーザ識別情報、認証応答および使用法、およびアカウンティング情報を経路指定し、ロギングする信頼あるサードパーティの機能を提供する複数のトランザクション・サーバ４６８も含む。トランザクション・サーバ４６８は、暗号解読機能を含むので、暗号解読サーバを規定することができる。
【００５３】
接続ダイヤラー４６６がクライアントまたはユーザのネットワーク・アクセス・デバイス２０５、３０５にインストールされるのに対し、ネットサーバ４７０はローミング・ユーザにＰＯＰを利用することを許可している「遠隔」ＩＳＰにインストールされ、またローム・サーバ４７２は関連付けられたホーム・ネットワークにローム・ユーザがアクセスすることを許可するために「ホーム」ＩＳＰに常駐する。トランザクション・サーバ４６８は、ネットワークとローム・サーバ４７０と４７２の間でメッセージを経路指定するように動作するということに留意されたい。
【００５４】
柔軟な価格設定エンジン４７６を含む設定システム４７４は、サービス・プロバイダ４５２と顧客４５６の間でサービス・アクセス・トランザクションの金銭上の決済を実行する。アクセス・ブローカー・システム４５４は、顧客４５６に提供されるサービスに関するサービス品質（ＱｏＳ）情報の収集・分析に役立つサービス品質モニタ４７８（ＳＱＭ）と顧客４５６が使用する複数の接続ダイヤラー４６６の管理に役立つ電話帳管理システム４８０も含む。トランザクション・サーバ４６８は、トランザクション・データをロードするために設定システム４７４によってアクセスされる。環境４５０の様々な構成要素は、周知の機能の態様を含むことができ、本発明の特定の実施形態によってはある種の構成要素を省略することができる。
【００５５】
顧客
図示する実施形態で顧客４５６はマルチティア顧客構造で構成されており、これによってアクセス・ブローカー・システム４５４は様々な事業計画とニーズに従って運営する顧客４５６と対話することができる。この範囲の一端で、顧客４５６はアクセス・ブローカー・システム４５４を介してローミング・システムに加入している個々のエンド・ユーザを含むことができる。別法として、顧客４５６は、企業の従業員のためにローミング・インターネット・アクセスを購入する法人顧客４８２（例えば法人または企業）の形態であってよい。
【００５６】
各顧客４５６は、それ自体の顧客（例えばエンド・ユーザ４８６および法人顧客４８２）に転売するためにローミング・インターネット・アクセスを購入するＩＳＰ顧客４８４を含むこともできる。各顧客４５６は、ソリューション・パートナーまたはアクセス・ブローカー・システム４５４によって仲介されるローミング・インターネット・アクセスを市場に出しエンド・ユーザ４８６、法人顧客４８２、および／またはＩＳＰ顧客４８４に転売する再販業者４８８として運営することができる。
【００５７】
顧客４５６は、インターネット通信事業者４９０（例えばＩＸＣ、ＲＢＯ、ＣＬＥＣ、ＩＬＥＣ、およびＩＳＰ）と見なされる関係者を含むこともできる。したがって、マルチパーティ・アクセス環境４５０では、多数の異なるサービス・プロバイダが、ローミング・ユーザにアクセスを提供することに参加することができ、したがって顧客のセキュリティ問題と、特にユーザの安全な認証が重要な課題になるということが理解されよう。また、参加者数の増加に伴い、アカウンティングの問題はより複雑化する傾向がある。
【００５８】
ローミング・サービス・アクセス
特に図６を参照すると、参照番号５００は、アクセス・ブローカー・システム４５４が本発明の一実施形態によって比較的安全な方式でローミング・インターネット・アクセスを提供することができる方法の一例を全般的に示している。「ホーム」ＩＳＰ５０４の加入者として示されているローミング・ユーザ５０２が、特定の地理的領域５１０内のローカルＰＯＰ５０８を提供する遠隔ＩＳＰ５０６に接続すると、ローミング・ユーザ５０２は「ホーム」ＩＳＰ５０４のＰＯＰ５０９を介して接続している際に使用されるのと同じユーザ名５１２とパスワード５１４（すなわち、認証データまたはユーザの信用証明書）を入力する。しかし、標準またはＬＥＧＡＣＹマルチパーティ・アクセス環境は、通常、ダイヤルアップ認証にはＰＡＰを、有線および無線ブロードバンド認証にはＨＴＴＰ ＰＯＳＴベースの認証を使用する。この結果、パスワードは安全でない媒体を介して転送されることになり、そのパスワードの機密性は損なわれ、それ以後、アクセス・ブローカー・システム４５４および顧客４５６の両方のネットワークに不正にアクセスするために使用される可能性がある。この問題を改善するために、本発明の一実施形態により、上記で図１から４を参照して説明し、図５から１３を参照してマルチパーティ環境について説明したように、接続ダイヤラー４６６はユーザのデータをＰＯＰ５０８に通信する前にそれを暗号化する。
【００５９】
図示する実施形態では、顧客４５６は接続ダイヤラー４６６を要求するためにウェブ形式を使用する。このウェブ形式は、必要となるカスタマイゼーションを指定するために使用することができるフィールドを含む。例えば次のフィールドは、平文形式のセキュアード・パスワード認証（以下では「セキュアＰＡＰ」と称する）用のウェブ形式に含まれる。
セキュアＰＡＰ暗号化をイネーブルする：（Ｙ／Ｎ）
公開鍵：^＊＊＊＊
鍵ＩＤ：（０−９）
【００６０】
顧客４５６がローミング・ユーザ５０２に対するセキュアＰＡＰをイネーブルするよう希望する場合（図６を参照のこと）、かれらは自分たちの関連付けられたローム・サーバ４７２に含まれるＥＣＣユーティリティを使用する。ローム・サーバ４７２は、アクセス・ブローカー・システム４５４から顧客４５６に提供されたアプリケーションを実行し、公開／秘密鍵対を生成する。秘密鍵は通常、ｅｓｐ＿ｋｅｙ＿ｐａｉｒ．ｔｘｔファイルに追加される。公開鍵は通常、適切な形式を使用してアクセス・ブローカー・システム４５４のダイヤラー・サポート・チームに送信される。ダイヤラー・サポート・チームは、本発明の一実施形態により接続ダイヤラー４６６を構築するためにダイヤラー・カスタマイゼーション・ツール（ＤＣＴ）を使用する。ＤＣＴツールは、使用されるべき暗号化／暗号解読アルゴリズムとＥＣＣ公開／秘密鍵を指定するためのウェブ・ページを含む。
【００６１】
接続ダイヤラー４６６は、ユーザ・アクセス・セッションを一意に識別する一意のセッションｉｄ（ブロック５２２を参照のこと）を生成するために、ダイヤラーｉｄとカウンター（図７のブロック５２０を参照のこと）を維持する。接続ダイヤラー４６６は、例えばアクセス・ブローカー・システム４５４のウェブ・サーバからダイヤラーｉｄを取得し、使用時には、接続ダイヤラー４６６は各ユーザ・アクセス・セッションが一意に識別されるようダイヤル試行ごとにカウンターを増分する。ダイヤラーｉｄとカウンターの値は、一意のセッションｉｄプレフィックスを作成するために使用される。ダイヤラーｉｄとカウンターの値またはカウント（平文で送信される）の整合性を保証するために、これらのフィールドはチェックサム文字を生成するために使用される。このチェックサム文字を生成するために使用されるアルゴリズムは、以下で図１２を参照してより詳細に説明される。一意のセッションｉｄの実施形態については、本明細書でより詳細に後述される。
【００６２】
ネットサーバ４７０は、認証されたユーザｉｄとパスワードのキャッシュを限られた期間だけ維持し、したがってそれ以後の認証はそのキャッシュから実行することができる（ブロック５３８を参照のこと）。安全なＰＡＰはユーザｉｄとパスワードを認証ごとに変更するので、それはネットサーバ４７０でいかなるキャッシング機能をもブレークする。したがって、特定の実施形態では、標準化されたネットサーバのキャッシュとの整合性を維持するために、ダイヤラー４６６は限られた期間だけランダム・ポイントをローカルに記憶し、これを再利用することができる（ブロック５４０を参照のこと）。上記処理の後で、ネットサーバ４７０は認証データをトランザクション・サーバ４６８に通信する。
【００６３】
特に図８を参照すると、参照番号５５０は、トランザクション・サーバ４６８によって実行される機能例を全般的に示している。トランザクション・サーバ４６８は、ダイヤラーｉｄ、カウンターで最後に使用された値、およびテーブルでの最後のアクセス・タイムを維持する（ブロック５５２を参照のこと）。テーブルは、ネットワークをリプレイ攻撃から保護するために使用される。このテーブルは、通常、すべてのトランザクション・サーバ４６８全体で複製される。
【００６４】
ユーザの信用証明書または認証データをネットサーバ４７０から受信する際、本発明の一実施形態では、トランザクション・サーバ４６８はパスワードを暗号解読し、受信したカウンターの値をデータベースに記憶されている値と比較する（ブロック５５４を参照のこと）。ダイヤラー４６６によって送信されるカウントがデータベースに記憶されている最後のカウント値よりも大きい場合、それは本物の要求であると見なされる（ブロック５５６を参照のこと）。ダイヤラー４６６によって送信されたカウントがデータベースに記憶されている最後のカウント値と等しく、現在のシステム・タイムとデータベースに記憶されている最後のアクセス・タイムとの間のデルタすなわち時間差が許可されたタイム・ウィンドウよりも少ない場合、ここでもまた要求は本物と見なされる（ブロック５５８を参照のこと）。ダイヤラー４６６によって送信されたカウントがこれら２つの条件を満たさない場合、トランザクション・サーバ４６８は認証要求を起こりうるリプレイ攻撃として拒否する（ブロック５６０を参照のこと）。トランザクション・サーバ４６８は、平文パスワードと共に認証要求を図９のローム・サーバ４７２に送信する。
【００６５】
図８に示す実施形態では、トランザクション・サーバ４６８は顧客の秘密鍵の記録を維持し、したがって認証データの暗号解読は暗号解読サーバを規定することのできるトランザクション・サーバ４６８で行われる。しかし特定の顧客が、トランザクション・サーバ４６８のようないかなる仲介者にも自分の秘密鍵を提供することを希望しない場合がある。このような場合、顧客の秘密鍵はトランザクション・サーバ４６８には提供されないが、一般に企業内の位置にある顧客のローム・サーバ４７２には提供される。したがって、上記に加えて、または上記の代わりに、認証データの暗号解読は顧客のローム・サーバ４７２で上記の方法と同様の方法で行うことができる。暗号化機能を含むローム・サーバ４７２の一実施形態を図９に示す。
【００６６】
特に図９を参照すると、参照番号５７０は、ローム・サーバ４７２によって実行される機能例を全般的に示す。この機能は図８の機能５５０に略類似しているので、同一または類似の機能を示すためには類似の参照番号を使用した。トランザクション・サーバ４６８が特定の顧客の秘密鍵にアクセスしない場合、トランザクション・サーバ４６８は必須のＥＣＣ属性を認証要求パケットに追加し、それをローム・サーバ４７２に送信する（ブロック５７２を参照のこと）。ローム・サーバ４７２は、ローカルに記憶されているＥＣＣ情報と秘密鍵を使用してパスワードとチェックサム文字を暗号解読する（ブロック５５２を参照のこと）。次いでローム・サーバ４７２は、カウントが有効であるか否かを判定するために上記と同様の機能テストを実行する（ブロック５５４〜５６０を参照のこと）。トランザクション・サーバ４６８がそのデータベースをカウントの最新値で更新することができるように（ブロック５７６参照のこと）、ローム・サーバ４７２は、暗号解読されたカウントを認証返信パケットに追加する（ブロック５７４を参照のこと）。カウンター機能を実施するためのテーブルの一例を以下に示す。
【００６７】
ｄｉａｌｅｒ＿ｃｏｕｎｔｅｒ＿ｔｓテーブルは、通常は複製用に使用される。このテーブルは各トランザクション・サーバ４６８で作成される。
【００６８】
【表１】

【００６９】
最後に使用された値は、通常、例えば「ＳＥＳＳＩＯＮ」マシン上のデータベース・インスタンスに記憶される。ＳＥＳＳＩＯＮマシンは、通常、トランザクション・サーバ４６８のｄｉａｌｅｒ＿ｃｏｕｎｔｅｒ＿ｔｓテーブルからエントリをプルし、それらを単一テーブルに蓄積するために使用される。ＳＥＳＳＩＯＮマシンは、トランザクション・サーバ４６８内のすべてのｄｉａｌｅｒ＿ｃｏｕｎｔｅｒ＿ｔｓテーブルに対応する一意のスナップショットの作成もする。これらのスナップショットは、通常、ｄｉａｌｅｒ＿ｃｏｕｎｔｅｒ＿ｔｓ＜ＳｅｒｖｅｒＩｄ＞と呼ばれる。ここでＳｅｒｖｅｒＩｄは、特定のトランザクション・サーバ４６８のｉｄである。データベース・インスタンスの一例であるＳＥＳＳＩＯＮは、故障耐性を強化するために両方の沿岸で２つの同一マシンにより作成される。
【００７０】
【表２】

【００７１】
各トランザクション・サーバ４６８は、通常、Ｏｒａｃｌｅのスナップショットを使用してｄｉａｌｅｒ＿ｃｏｕｎｔｅｒテーブルを複製する。本発明の本実施形態に適応するように標準システムがアップグレードされる場合、一般に以下の変更例が作成される。
【００７２】
【表３】

【００７３】
【表４】

【００７４】
【表５】

【００７５】
暗号化／暗号解読機能
図７から９を参照して上記で説明した本実施形態では、ダイヤラー４６６、トランザクション・サーバ４６８、およびローム・サーバ４７２は、ＥＣＣアルゴリズムを実施し、パスワードの暗号化と暗号解読のためにＡＰＩを提供するＥＣＣ ＡＰＩを含む。通常、ＥＣＣ実施態様は、暗号化／暗号解読のために最適な正規基底の数学を使用する。ある種の実施形態では、数学的反転の回数を１回の乗算の犠牲に縮小するように、多項式基底の数学と最適な正規基底の数学が組み合わされる。
【００７６】
特に図１０を参照すると、参照番号５８０は、ダイヤラー４６６の暗号化機能の一例を全般的に示す。ブロック５８２で示すように、暗号化アルゴリズムはＥＣＣ曲線上にランダムな点を生成する。次いでこのランダムな点は、ＥＣＣストリングの一部＜暗号化されたパスワード＞を作るためにパスワードとチェックサム文字（ブロック５８４を参照のこと）を暗号化するために使用される。ダイヤラー４６６はランダムな点を暗号化し、それをネットサーバ４７０に送信する（ブロック５８６および５８７を参照のこと）。通常、この暗号化には後述するように記号変換方式が使用される。
【００７７】
既存のプロトコル、例えばＰＰＰ、ＰＡＰ、ＲＡＤＩＵＳなどに対応するために、パスワード・フィールドは印刷可能なＵＳ−ＡＳＣＩＩ文字を有する。ある種の実施形態では、文字はＲＦＣ２４８６標準に準拠するような方法で生成される。これらの実施形態では、パスワードおよびチェックサム・フィールドが暗号化される際、標準プロトコルを使用しているネットワークに適用することができるようにストリングを許容可能な文字で生成するよう配慮がなされる（ブロック５８８を参照のこと）。したがって、この符号化を実行するために以下の文字変換方式を使用することができる。符号化されるべき各文字は、まず以下に示すテーブルに従う値にマッピングされる。
【００７８】
【表６】

【００７９】
マッピングされた値は次いでランダムな点の対応するバイトに加えられ、モデュラス９５が計算される（ブロック５９０を参照のこと）。この結果、文字は上記テーブルの別の文字にマッピングされる。暗号解読サーバで文字を暗号解読するには、符号化された文字からランダムな点の対応するバイトが引かれ（図１１のブロック５８１を参照のこと）、結果のモデュラス９５が計算される（ブロック５８３を参照のこと）。結果が負の数である場合、オリジナルの文字を得るためにその結果に値９５が加えられる（ブロック５８５を参照のこと）。一例として、「ｒ」を符号化に使用されるランダムな点のバイトとし、「ｘ」をオリジナルの文字として、
符号化：ｙ＝（ｘ＋ｒ）％９５
復号：ｘ＝（ｙ−ｒ）％９５
（ｘ＜０）の場合、
ｘ＝ｘ＋９５である。
【００８０】
ダイヤラー４６６での暗号化プロセス中に、パスワード・フィールドとチェックサム文字はランダムな点で暗号化される。これらのフィールドのそれぞれは、符号化のためにランダムな点の異なるバイトの組を使用する。パスワード・フィールドは、その符号化のために第１のバイトの組を使用し、チェックサム・フィールドはその符号化のためにバイト１０を使用する。
【００８１】
ダイヤラーｉｄとカウンター値の整合性を確認するためにチェックサム文字が使用される。ダイヤラーｉｄとカウンター値が平文で送信される場合、悪意のある人物は、これらの値を変更して、リプレイ攻撃に対する保護を破ることができる。この問題に対処するため、チェックサム文字がダイヤラーｉｄとカウンター値から生成され、その後、それはランダムな点を使用して符号化される（図１２のブロック５９２を参照のこと）。暗号化されたチェクサム文字は次いで、ユーザｉｄストリングの一部として送信される。
【００８２】
チェックサム文字は、カウント値、ダイヤラーｉｄ、およびランダムな点のＭＤ５ハッシュによって生成される（図１２のブロック５９２および５９４を参照のこと）。次いで７ビットがハッシュから選択され、上記の符号化方法を使用してランダムな点からの単一バイトによって符号化される（バイト＃１０）（ブロック５９６を参照のこと）。符号化されたビットは次いで、暗号化された点の最後の７バイトに分散され（ブロック５９８を参照のこと）、ユーザのストリングの一部として送信される（ブロック５９９を参照のこと）。ダイヤラー４６６が符号化されたデータをトランザクション・サーバ４６８またはローム・サーバ４７２に送信する際、場合によっては、これらはチェックサムを独立して生成することによって（図８および９のブロック５８８を参照のこと）ダイヤラーｉｄとカウンター値を検証し、それをダイヤラー４６６から送信されたチェックサムと比較し（ブロック５９０を参照のこと）、それらが一致しない場合には拒絶する。
【００８３】
図１０のダイヤラー４６６に戻ると、符号化されたストリングは次いで以下のように連結されてＥＣＣストリングを形成する。
＜符号化されたパスワード＞＜最後の７バイトにおける符号化されたチェックサム・ビットを有するランダムな点の暗号化され符合化されたｘ座標＞
【００８４】
その後、ダイヤラー４６６はＥＣＣストリングをダイヤラーｉｄとカウンター値に連結し、それをＰＡＰなどのプロトコルのユーザｉｄとパスワード・フィールドで送信する。例えば＜符号化されたパスワード＞＜最後の７バイトにおける符号化されたチェックサム・ビットを有するランダムな点の暗号化され符号化されたｘ座標＞＜ダイヤラーｉｄ＞＜カウンター値＞。
【００８５】
図１０で説明した方法は、そのようなストリング長を有する暗号化されたストリングを作り、暗号化されたストリングをＬＥＧＡＣＹシステムを使用して通信することができるような性質を特徴として含むということに留意されたい。
【００８６】
暗号化論理は、通常、以下の署名によってｉｐ＿ｓｐａｐ＿暗号（）メソッドにカプセル化される。
ｃｈａｒ^＊ｉｐ＿ｓｐａｐ＿ｅｎｃｒｙｐｔ（ｃｏｎｓｔ ｃｈａｒ^＊ａｌｇｏｒｉｔｈｍ、ｃｏｎｓｔ ｃｈａｒ ｐｕｂｌｉｃ＿ｋｅｙ、ｃｏｎｓｔ ｃｈａｒ ｐａｓｓｗｏｒｄ、ｃｏｎｓｔ ｃｈａｒ^＊ｄｉａｌａｒ＿ｉｄ、ｃｏｎｓｔ ｃｈａｒ^＊ｃｏｕｎｔｅｒ、ｃｈａｒ^＊＊ｐｌａｉｎ＿ｐｏｉｎｔ、ｃｈａｒ^＊＊ｅｎｃｒｙｐｔｅｄ＿ｐｏｉｎｔ、ｉｎｔ^＊ｒｅｔｕｒｎＣｏｄｅ）
ここで、
ａｌｇｏｒｉｔｈｍは使用されるべきアルゴリズムである。ＳｅｃｕｒｅＰＡＰ ｐｕｂｌｉｃ＿ｋｅｙの「Ｓ」はＥＣＣ公開鍵（ｃｏｎｆｉｇ．ｉｎｉより）であり、
ｐａｓｓｗｏｒｄは平文パスワードであり、
ｄｉａｌｅｒ＿ｉｄはダイヤラーのｉｄであり（ダイヤラーｉｄサーブレットから取得）、
ｃｏｕｔｎｅｒはダイヤル試行カウント（ダイヤル試行ごとにダイヤラーによって増分される）であり、
ｐｌａｉｎ＿ｐｏｉｎｔ−このフィールドが空のままである場合は、新しいランダムな点が生成される。このフィールドは、戻る際に符号化するために使用されるランダムな点を指し示す。
ｅｎｃｒｙｐｔｅｄ＿ｐｏｉｎｔ−このフィールドが空のままである場合は、暗号化された点を生成するためにプレーンな点と公開鍵が使用される。このフィールドは、戻る際にメソッドが使用する暗号化された点を指し示す。
戻りコード０−呼が成功した場合、非ゼロ・コードが提供される。このメソッドは、成功の場合にはＥＣＣストリングを戻し、そうでない場合にはヌルを戻す。
【００８７】
暗号解読論理はｉｐ＿ｓｐａｐ＿暗号解読（）メソッドにカプセル化される。この方法は以下の署名を有する。
ｃｈａｒ^＊ｉｐ＿ｓｐａｐ＿ｄｅｃｒｙｐｔ（ｃｏｎｓｔ ｃｈａｒ^＊ａｌｇｏｒｉｔｈｍ、ｃｏｎｓｔ ｃｈａｒ ｐｒｉｖａｔｅ＿ｋｅｙ、ｃｏｎｓｔ ｃｈａｒ ｅｃｃ＿ｓｔｒｉｎｇ、ｃｏｎｓｔ ｃｈａｒ^＊ｄｉａｌａｒ＿ｉｄ、ｃｏｎｓｔ ｃｈａｒ^＊ｃｏｕｎｔｅｒ、ｉｎｔ^＊ｒｅｔｕｒｎＣｏｄｅ）、ここで、
ａｌｇｏｒｉｔｈｍは使用されるべきアルゴリズムである。ＳｅｃｕｒｅＰＡＰ ｐｒｉｖａｔｅ＿ｋｅｙの「Ｓ」はＥＣＣ秘密鍵（ｓｅｃｕｒｅｐａｐテーブルまたはｅｓｐ＿ｋｅｙ＿ｐａｉｒ．ｔｘｔファイルより）であり、
ｅｃｃ＿ｓｔｒｉｎｇは暗号（）メソッドによって戻されるストリングであり、
ｄｉａｌｅｒ＿ｉｄはダイヤラーのｉｄ（ダイヤラーｉｄサーブレットから取得）であり、
ｃｏｕｎｔｅｒはダイヤル試行カウント（ダイヤル試行ごとにダイヤラーによって増分される）であり、
戻りコード０−呼が成功した場合であり、そうでない場合は非ゼロ・コードである。
この方法は、成功の場合には平文パスワードを戻し、そうでない場合にはヌルを戻す。
【００８８】
ダイヤラーのカスタマイゼーション形式
上述のように、顧客４５６は、ＳｅｃｕｒｅＰＡＰを使用して通信するよう構成されたカスタマイズされたダイヤラーを要求するためにウェブ形式を使用する。このウェブ形式は、通常、必要なカスタマイゼーションを指定するために使用することのできるフィールドを含んでいる。このウェブ形式は、以下のフィールドの例を含むことができる。
ＳｅｃｕｒｅＰＡＰ暗号化をイネーブルする：（Ｙ／Ｎ）
公開鍵：
鍵Ｉｄ：（０−９）
【００８９】
ダイヤラーのカスタマイゼーション・ツール
カスタマイゼーションプロセス中、アクセス・ブローカー・システム４５４の管理者は、ＳｅｃｕｒｅＰＡＰを使用するダイヤラー４６６を生成するという選択肢を有している。イネーブルされた場合、以下のフィールドの例を、通常はダイヤラー４６６にパッケージされているｃｏｎｆｉｇ．ｉｎｉに設定することができる。
［ｉＰａｓｓなどの処理機能ＩＤ］
暗号化フラグ＝ｙｅｓ
アルゴリズム＝Ｓ
鍵のバージョン＝０
公開鍵＝ＢｗＡＡＡＭＧｄｑＹｘ２１ｘｈＷｔＥＱＭｄＤＨｈｗｖＵ＝＆ＡＱＡＡＡＦｄｄ４０ｕＬＱＭＤ１ＵＴｔｙＢｑＤＨＹ＝
【００９０】
特定の顧客４５６の対応するダイヤラー４６６から送信されたパスワードをトランザクション・サーバ４６８が暗号解読できるように、これらの値はトランザクション・データベースにも記憶されている。本実施形態では、このファイルには公開鍵しか記憶されておらず、秘密鍵は暗号化の安全のために秘密にされる。
【００９１】
ＳｅｃｕｒｅＰＡＰをイネーブルすることに加えて、カスタマイゼーション・ツールは、使用されるアルゴリズムと鍵のバージョンを設定するという選択肢も提供する。例えば、以下の暗号化アルゴリズムをサポートすることができる。
暗号化しない場合にはＡ
楕円曲線暗号化の場合にはＥ
一意のセッションＩＤに適合するＥＣＣの場合にはＳ
一意のセッションＩＤの場合にはＵ
【００９２】
実際には、Ａは主としてテストおよびデバッグのためのものである。Ｅは、ダイヤラーがダイヤラーｉｄを有しない場合にパスワードを暗号化するために使用される。Ｕは、暗号化アルゴリズムではないが、後で詳述するように一意のセッションｉｄを識別するために使用される。鍵のバージョンは０から開始されるが、既存のダイヤラー・プロファイルに新しい鍵対が求められるたびに増分される。ダイヤラー４６６は、ｓｅｃｕｒｅ＿ｐａｐテーブルにＥＣＣ鍵および他の情報を記憶する。次いでこのテーブルはＯｒａｃｌｅのスナップショットを介してトランザクション・サーバ４６８に複製される。秘密鍵が漏洩すると、新しい鍵対が生成される。秘密鍵の安全性が損なわれると、ダイヤラー・サポート・チームは以下の行動を取るべきである。
１．漏洩した鍵に対して適切な失効期日を設定する。漏洩した鍵を使用しているすべてのダイヤラー４６６がその鍵をもう１回だけ使用することができるよう保証するにはこれで十分であるはずである。ダイヤラー４６６は古い鍵を使用してインターネットに接続し、アップデート・サーバから新しい鍵を有するｃｏｎｆｉｇ．ｉｎｉファイルを取り出す。顧客４５６がパスワードを暗号解読するためにローム・サーバ４７２を使用している場合、顧客４５６は、通常、失効期日以後はｅｓｐ＿ｋｅｙ＿ｐａｉｒ．ｔｘｔファイルから漏洩した鍵を手動で除去する。
２．新しい鍵対を生成するか、または新しい鍵対を生成するよう顧客４５６に要求し、公開鍵をアクセス・ブローカー・システム４５４に送信する。
３．ＤＣＴツールを使用し、公開鍵を置き換える（新しい鍵ｉｄを使用して）。ダイヤラーを構築する。
【００９３】
ダイヤラー
ダイヤラー４６６は、パスワードを暗号化すべきか否かを判定するためにｃｏｎｆｉｇ．ｉｎｉファイルをチェックする。ＳｅｃｕｒｅＰＡＰがイネーブルされている場合、ダイヤラー４６６はｃｏｎｆｉｇ．ｉｎｉファイルの公開鍵を使用し、ｉｐ＿ｓｐａｐ＿暗号化（）メソッドを呼び出すことによってパスワードを暗号化する。このメソッドはＥＣＣストリングを作成し、これを戻す。ダイヤラー４６６はＥＣＣストリングをダイヤラーｉｄとカウンター値に連結する。ＥＣＣストリングの最初の１６文字がパスワード・フィールドに置かれ、ストリング内の残りの文字はプレフィックス・フィールド（０Ｓまたは０Ｅプレフィックスと共に）に置かれる。ダイヤラー４６６はダイヤラーｉｄを取得するまではアルゴリズム「Ｅ」を使用する。このプレフィックスは、すべてのシステムおよび経路指定プレフィックスの後、顧客のプレフィックスの前に含まれる。ダイヤルされているＰＯＰが電話帳内のＰＡＰプレフィックスに適合しないプレフィックスを有している場合、ダイヤラー４６６はパスワードを暗号化せず、ＳｅｃｕｒｅＰＡＰプレフィックスを作成しない。暗号化プレフィックスを含むサンプルのユーザ名を以下に示す。
ユーザＩＤ：ＩＰＡＳＳ／０Ｓ Ａｘｒｔ５０ｚＴｘｃａ５４６ｈｊｄｇｋｂｘｃｊｃ?＿ｄ０ｗｅ／ｊｏｅ＠ｉｐａｓｓ．ｃｏｍ
パスワード：ｘ３５〜！４Ｑｕ｛ｘｙ７１］Ｄ８
ここで、鍵のバージョン＝０でありアルゴリズム＝Ｓである。
【００９４】
アクセス・ブローカー・システム４５４は、暗号化が必要ないと判定した場合、ダイヤラー・カウントから一意のセッションｉｄを作成し、それをプレフィックス・フィールドに置く。一意のセッションｉｄプレフィックスを含むサンプルのユーザ名を以下に示す。
ユーザＩＤ：ＩＰＡＳＳ／０ＵＡｘｒｔ５ＡＢ２／ｊｏｅ＠ｉｐａｓｓ．ｃｏｍ
パスワード：ｔｈｉｓｉｓａｂｉｇｓｅｃｒｅｔ
ここで、鍵のバージョン＝０であり、アルゴリズム＝Ｕである。
ダイヤラー４６６はそのローカル・ストレージにｐｌａｉｎ＿ｐｏｉｎｔと暗号化された点を記憶する。
【００９５】
リダイヤルが試行された場合、ダイヤラー４６６はカウンターを増分し、プレーンな点と暗号化された点を使用してｉｐ＿ｓｐｓｐ＿暗号化（）メソッドを呼び出す。
【００９６】
顧客ソリューション
顧客ソリューション・プロセスは［０−９］［Ａ−Ｚ］^＊／形式のプレフィックスの有無をチェックする。そのようなプレフィックスが発見されず、顧客４５６がパスワードの暗号解読を要求しない場合、顧客ソリューションは正常に動作する。プレフィックスが発見された場合、最初のスラッシュ（／）までの後ろから８バイトが取り除かれ、一意のセッションｉｄフィールドとして記憶される。顧客ソリューションコードは、０Ｓ＜ｄｉａｌｅｒ＿ｉｄ＞＜ｃｏｕｔｅｒ＞というコンテンツを有する一意のセッションｉｄフィールドを作成することができる。整数が取り除かれ、鍵識別フィールドとして記憶される。アルゴリズムが取り除かれ、別個のフィールドとして記憶される。
【００９７】
ダイヤラー・カウンターの複製
図示する安全なＰＡＰの実施形態は、リプレイ攻撃に対する保護のためにｄｉａｌｅｒ＿ｃｏｕｎｔｅｒテーブルを使用する。各トランザクション・サーバ・データベースは、ｄｉａｌｅｒ＿ｃｏｕｎｅｒ＿ｔｓテーブルを含んでいる。トランザクション・サーバ４６８は、ＳｅｃｕｒｅＰＡＰプレフィックスを有する正常な認証要求を受信するか否かに関わらず、新しい行をこのテーブルに挿入する。この行の内容は、ｓｅｒｖｅｒ＿ｉｄ、ｄｉａｌｅｒ＿ｉｄ、カウンターおよびシステム・タイム（ＧＭＴで）を含む。
【００９８】
ＳＥＳＳＩＯＮデータベースは、すべてのトランザクション・サーバ４６８でのｄｉａｌｅｒ＿ｃｏｕｎｔｅｒ＿ｔｓテーブルに対するスナップショットを含んでいる。これらのスナップショットは、通常、ｄｉａｌｅｒ＿ｃｏｕｎｔｅｒ＿ｔｓ＜ＳＥＲＶＥＲ＿ＩＤ＞と呼ばれる。ここで、＜ＳＥＲＶＥＲ＿ＩＤ＞は特定のトランザクション・サーバ４６８のｉｄである。
【００９９】
トランザクション・サーバ４６８からのスナップショットをリフレッシュするために「リフレッシュ」ツールが提供される。ｄｉａｌｅｒ＿ｃｏｕｎｔｅｒ＿ｔｓ＿＜ＳＥＲＶＥＲ＿ＩＤ＞は、挿入されているカウンターの値がｄｉａｌｅｒ＿ｃｏｕｎｔｅｒテーブルのカウンターの値と等しいかまたはそれよりも大きい場合、挿入される行のｄｉａｌｅｒ＿ｉｄ、カウンター、およびａｃｃｅｓｓ＿ｔｉｍｅをｄｉａｌｅｒ＿ｃｏｕｎｔｅｒテーブルに更新／挿入する「ＯＮ ＩＮＳＥＲＴ」ＰＬ／ＳＱＬトリガーを有する。トランザクション・サーバ４６８は、ＳＥＳＳＩＯＮデータベースのｄｉａｌｅｒ＿ｃｏｕｎｔｅｒスナップショットをリフレッシュするためにリフレッシュ・ツールを使用する。次いでｄｉａｌｅｒ＿ｃｏｕｎｔｅｒテーブルは、より高速なアクセスのためにトランザクション・サーバ４６８によりキャッシュされる。実行中にｄｉａｌｅｒ＿ｃｏｕｎｔｅｒテーブルの記録に何らかの変更が加えられた場合、その影響は即座に現れる。これは、データベース・トリガーとｃｈａｃｈｅ＿ｕｐｄａｔｅテーブルを使用するアクセス・ブローカー・システム４５４の他の構成要素で使用されているのと同じ機構を使用することによって達成される。
【０１００】
トランザクション・サーバ
起動時、効率的なルックアップのためにアクセス・ブローカー・システム４５４は、データベースのすべての秘密鍵をローカル・キャッシュに読み込む。これは、特定の顧客４５６がパスワードの暗号化を要求しているか否かを示すために顧客のキャッシュに追加の属性も有する。トランザクション・サーバ４６８は、ｄｉａｌｅｒ＿ｃｏｕｎｔｅｒテーブルもキャッシュする。実行中にこれらのテーブルに何らかの変更が加えられた場合、その影響は即座に現れる。これは、データベース・トリガーとｃｈａｃｈｅ＿ｕｐｄａｔｅテーブルを使用するアクセス・ブローカー・システム４５４の他の構成要素で使用されているのと同じ機構を使用することによって達成される。
【０１０１】
暗号化されたプレフィックス・フィールドが「Ｓ」アルゴリズムを指定する場合、トランザクション・サーバ４６８はパスワード・フィールドの内容を、顧客ソリューション・プロセスによって構築された暗号化されたプレフィックス・フィールドに連結し、「ＥＣＣフィールド」を作成する。ＥＣＣフィールドは以下を含んでいる。
＜符号化されたパスワード＞＜ランダムな点の暗号化され符号化されたｘ座標＞＜符号化されたチェックサム文字＞
【０１０２】
トランザクション・サーバ４６８は、鍵インデックスを使用して適切な顧客４５６に対する秘密鍵を探し出す。秘密鍵がデータベースで発見された場合、パスワードを暗号解読し復号するためにトランザクション・サーバ４６８はｉｐ＿ｓｐａｐ＿暗号解読（）メソッドを呼び出す。次いでパスワード・フィールドはローム・サーバ４７２に送信される前に平文パスワードによって上書きされる。
【０１０３】
秘密鍵がキャッシュで発見されない場合、トランザクション・サーバ４６８は、通常、認証要求パケットに以下のフィールドを付加し、それをローム・サーバ４７２に送信する。そのフィールドとはすなわち、アルゴリズム、鍵インデックス、ＥＣＣフィールド（パスワードとして）、ダイヤラーｉｄ、カウンター、最後に使用されたカウンターの値およびアクセス・タイム（データベースから）、および「ｙｅｓ」に設定された「ｄｅｃｒｐｔ＿ａｔ＿ｒｏａｍＳｅｒｖｅｒ」フラグである。
【０１０４】
次いでトランザクション・サーバ４６８は、認証の細目をｉｐ＿ａｕｔｈ＿ｔｒａｎｓテーブルに、ｄｉａｌｅｒ＿ｃｏｕｎｔｅｒの細目をｄｉａｌｅｒ＿ｃｏｕｎｔｅｒ＿ｔｓテーブルに記憶する。トランザクション・サーバ４６８は、通常、挿入が更新よりも一般に高速の場合にはいつでも新しいｄｉａｌｅｒ＿ｃｏｕｎｔｅｒ＿ｔｓ記録を挿入する。
【０１０５】
トランザクション・サーバ４６８は、アカウント要求を受信すると、一意のセッションｉｄを作成するために顧客ソリューション・プロセスを使用し、それをパケットに「ｉｐａｓｓ＿ｓｅｓｓｉｏｎ＿ｉｄ」として付加する。ｔｒ＿ｕｓｅｒｉｄフィールドは、ｒａｗ＿ｕｓｅｒｉｄを含んでいる。
【０１０６】
ＥＳＰツール
公開／秘密鍵対を生成し、暗号化アルゴリズムと暗号解読アルゴリズムをテストするために、顧客４５６はそのローム・サーバ４７２、ＤＣＴチーム、およびＱＡチームと共にＥＳＰコマンド行ツールを使用する。
ｅｓｐ＿ｇｅｎｋｅｙ（ローム・サーバ４７２を有する顧客４５６の場合）
【０１０７】
このツールは、ｅｓｐ＿ｋｅｙ＿ｐａｉｒ．ｔｘｔと呼ばれるファイルに公開／秘密ＥＳＰ鍵対をプリントする。このファイルは、Ｕｎｉｘの／ｕｓｒ／ｉｐａｓｓ／ｋｅｙｓディレクトリとＷｉｎｄｏｗｓ（登録商標）用のＩＰＡＳＳ＿ＨＯＭＥ／ｋｅｙｓディレクトリに常駐する。ダイヤラー４６６を公開鍵で構築することができるように、鍵はアクセス・ブローカー・システム４５４に、例えば安全なウェブサイトを介しても提出される。通常、秘密鍵の安全なバックアップも維持される。
ｅｓｐ＿ｇｅｎｋｅｙ＿ｄｃｔ：
【０１０８】
このツールは、公開／秘密ＥＳＰ鍵対を標準出力にプリントする。これはＤＣＴの要件を満たす形式でプリントされる。出力例を以下に示す。
１
公開
鍵：ＢｇＡＹＶＫ１ａｚＵｔ８ｃｏｍｋ４１ＧｚＬｗ＝＆ＡＤＩｋＧｆＭｇＮＣｈＭ４ｖＹ６＋ｎＬｇＴｑｏ＝
秘密鍵：ＡＱＡＡＡＡＺＯＳＮＨ１３ＰａＧ３ＮｕｑＧｂＵ７ＴＹ０＝
【０１０９】
最初の行は、鍵の生成が成功したことを示す「１」を含んでいる。エラーが発生した場合、出力は「０」の値を有する。
ｅｓｐ＿ｑａ：
このツールは、ＥＣＣ ＡＰＩをテストするために使用可能な複数のコマンド行の選択肢を有している。サポートされる選択肢のサンプルの一例を以下に示す。
ｅｓｐ＿ｑａ ｇｅｎｋｅｙ
ｅｓｐ＿ｑａ ｅｎｃｒｙｐｔ［−ａ＜ａｌｇｏｒｉｔｈｍ＞−ｄ＜ｄｉａｌｅｒ＿ｉｄ＞−ｃ＜ｃｏｕｎｔｅｒ＞］−ｋ＜ｐｕｂｌｉｃ＿ｋｅｙ＞−ｔ＜ｔｅｘｔ＞
ｅｓｐ＿ｑａ ｄｅｃｒｙｐｔ［−ａ＜ａｌｇｏｒｉｔｈｍ＞−ｄ＜ｄｉａｌｅｒ＿ｉｄ＞−ｃ＜ｃｏｕｎｔｅｒ＞］−ｋ＜ｐｒｉｖａｔｅ＿ｋｅｙ＞−ｔ＜ｔｅｘｔ＞
ｅｓｐ＿ｑａ ｔｅｓｔｉｐｇ［−ａ＜ａｌｇｏｒｉｔｈｍ＞−ｄ＜ｄｉａｌｅｒ＿ｉｄ＞−ｃ＜ｃｏｕｎｔｅｒ＞］−ｋ＜ｐｕｂｌｉｃ＿ｋｅｙ＞−ｔ＜ｔｅｘｔ＞−ｕ＜ｕｉｄ
＠ｄｏｍａｉｎ＞
ｅｓｐ＿ｑａ ｔｅｓｔ −ｔ＜ｔｅｘｔ＞
括弧［］内の選択肢は任意選択である。各ｅｓｐ＿ｑａコマンドは以下のように記述される。
ｇｅｎｋｅｙ−公開／秘密鍵対を生成する。
ｅｎｃｒｙｐｔ−所与のｐｕｂｌｉｃ＿ｋｅｙによってテキスト（パスワード）を暗号化する。
ｄｅｃｒｙｐｔ−所与の秘密鍵によってテキスト（パスワード）を暗号解読する。
ｔｅｓｔｉｐｇ−「暗号化」を実行し、次いで所与のユーザに対してｃｈｅｃｋ−ｉｐｅｎコマンドを実行する。
ｔｅｓｔ−基本的なＥＣＣ ＡＰＩテスト。アルゴリズムＳに対してｇｅｎｋｅｙ、ｅｎｃｒｙｐｔ、およびｄｅｃｒｙｐｔを実行する。
【０１１０】
ローム・サーバ
ローム・サーバ４７２は、通常、トランザクション・サーバ４６８から受信したパケットの「ｄｅｃｒｙｐｔ＿ａｔ＿ｒｏａｍｓｅｒｖｅｒ」フィールドの有無をチェックする。このフィールドがある場合、ローム・サーバはパケットの「鍵インデックス」フィールドを使用し、ｅｓｐ＿ｋｅｙ＿ｐａｉｒ．ｔｘｔファイルの秘密鍵をフェッチする。秘密鍵、ダイヤラーｉｄ、およびカウンター値を有するＥＣＣストリングが、ｉｐ＿ｓｐａｐ＿暗号解読（）メソッドに送られる。ｉｐ＿ｓｐａｐ＿暗号解読（）メソッドは、このパスワードを復号し暗号解読する。次いでユーザを認証するためにローム・サーバ４７２によって平文パスワードが使用される。
【０１１１】
図６に戻り、ダイヤラー４６６が一度上記の方法を実行すると、認証データは、遠隔ＩＳＰ５０６の認証サーバ６００に送信された後でＮＡＳ５３２に通信される。動作の正規のコースでは、遠隔ＩＳＰ５０６のＮＡＳ５３２は提供された認証情報を拒絶する。しかし図６に示すように、ネットサーバ４７０は、この認証情報を正規のユーザ要求ではなくローミング・ユーザの認証要求として認識することを容易にするために認証情報を代行受信する。
【０１１２】
認証サーバ６００は、ネットサーバ４７０と共に、ローミング・ユーザ５０２に関連付けられたローミング・ドメイン名または経路指定プレフィックスを決定するために、受信した認証情報を構文解析する。そのようなドメイン名またはプレフィックスが存在する場合、ユーザの認証情報は上記のように暗号化され、ネットサーバ４７０からセキュア・ソケット・レイヤ（ＳＳＬ）を介してトランザクション・サーバ４６８に送信される。
【０１１３】
トランザクション・サーバ４６８は、要求を経路指定するためにセッションＩＤの顧客経路指定プレフィックスを使用することができる。代わりに、トランザクション・サーバ４６８は、インターネット・プロトコル（ＩＰ）ルックアップを実行することができ、認証要求を適切なホームＩＳＰ５０４に経路指定する。より具体的には、トランザクション・サーバ４６８は、遠隔ＩＳＰ５０２のネットサーバ４７０から暗号化された認証要求を受信し、この要求を図７から９を参照して上記で説明したように暗号解読する。次いでトランザクション・サーバ４６８は、所望のホームＩＳＰ５０４のローミング・ドメイン名または経路指定プレフィックスを参加者ドメイン名およびＩＰアドレスの現行リストと照合することによって「ホーム」ＩＳＰ５０４を決定する。照合が成功した場合、認証要求は暗号化され、ホームＩＳＰ５０４に常駐しているローム・サーバ４７２にＳＳＬを介して送信される。識別されたローム・サーバ４７２が指定期間内に応答しない場合、トランザクション・サーバ４６８は、関連ドメインのＩＳＰの代替ローム・サーバ４７２に接触するよう試みる。
【０１１４】
次いでホームＩＳＰ５０４のローム・サーバ４７２は、上記のようにトランザクション・サーバ４６８から送信された認証要求を暗号解読し、その認証要求をホームＩＳＰの正規の認証サーバ６０２に、あたかもそれが顧客プレフィックスを使用するホームＩＳＰ５０４の所有するターミナル・サーバまたはＮＡＳ５３２であるかのように提出する。ホームＩＳＰ５０４の認証サーバ６０２は、その要求に応えて、認証要求に含まれるユーザ名およびパスワードの有効性に基づいて「アクセス許可」または「アクセス拒否」応答を提供する（図８を参照のこと）。ホームＩＳＰの認証サーバ６０２からの応答は、ローム・サーバ４７２によって受信され、暗号化され、トランザクション・サーバ４６８に送信されて戻される。
【０１１５】
一意のセッションＩＤ
複数のトランザクション・データ記録を関連付ける方法およびシステムの一例を以下に示す。この方法およびシステムは、通常上記の暗号化／暗号解読方法と共に使用される一意のセッションｉｄの生成および使用を記載する。
【０１１６】
上記のように、ポイント・ツー・ポイント（ＰＰＰ）、パスワード認証プロトコル（ＰＡＰ）、チャレンジ・ハンドシェーク認証プロトコル（ＣＨＡＰ）、遠隔認証ダイヤルイン・ユーザ・サービス（ＲＡＤＩＵＳ）プロトコル、ターミナル・アクセス・コントローラ・アクセス制御システム（ＴＡＣＡＣＳ）プロトコル、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）、ＮＴドメイン認証プロトコル、Ｕｎｉｘパスワード認証プロトコル、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュア・ソケット・レイヤを介したハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、拡張認証プロトコル（ＥＡＰ）、転送レイヤ・セキュリティ（ＴＬＳ）プロトコル、トークン・リング・プロトコル、およびセキュア遠隔パスワード・プロトコル（ＳＲＰ）などのような通信プロトコルは、ユーザＩＤストリングに備える。それぞれの異なるプロトコルが許可する文字のサイズまたは長さは異なる場合があるが、上記に列挙したプロトコル例がサポートするサイズの最小共通分母は通常は約６３文字である。この場合、一意のユーザ・セッションＩＤを提供することによって、認証、アカウンティング、およびＳＱＭ処理が強化される。
【０１１７】
例示のマルチパーティ・サービス・アクセス環境４５０に対する上記プロトコルの適用にはユーザＩＤストリングが含まれおり、したがってこれは様々な参加者が生成したすべての関連するトランザクション・データ記録、例えばトランザクション・サーバ４６８、サービス・プロバイダ４５２、および顧客４５６に共通している。しかしある種の環境では、それらのプロトコルで使用されている従来技術のユーザＩＤストリングはマルチパーティ・サービス・アクセス環境４５０の特定のユーザに一意に関連付けることができるが、特定の単一ユーザ・セッションには一意に関連付けられない。例えばネットワーク・タイムアウトおよびパケット再試行アルゴリズムが原因で、単一トランザクション・データ記録がトランザクション・サーバ４６８に複数回送信され、それらの記録のどれか１つまたは複数が不良である場合、同一の単一ユーザ・セッションに関連する記録の複数のインスタンスが設定システム４７４に存在する場合がしばしばある。さらに、認知された失敗した通信の試行を再送する試みにおいて、ある種のＮＡＳ４７０（図６を参照のこと）は実際にユーザ・セッションＩＤストリングを変更し、その結果、同一の単一ユーザ・セッションに対して異なるトランザクション・データ記録が生じることになる。上記説明は、不十分なアカウンティング記録の２つの例にすぎないが、多数の他の状況があるということが理解されよう。
【０１１８】
本発明の別の実施形態によれば、単一ユーザ・セッションに応答して生成された関連トランザクション・データ記録は、共通の一意のセッションＩＤを含む。場合によっては、このセッションＩＤは、個々のユーザの使用情報の強力だが必ずしも絶対的ではないＩＤを提供する場合があり、この一意のユーザ・セッションＩＤは少なくともある種のパラメータ内では一意であるべきである。例えば、所与の期間中に生成されたすべての記録を、一意のユーザ・セッションＩＤを使用して関連付け、処理することができるように、一意のユーザＩＤはその所与の期間だけは一意であってよい。
【０１１９】
通常、上記のプロトコル例の場合、ユーザＩＤストリングは、ネットワークにアクセスしているユーザのユーザ名とパスワードだけでなく、顧客領域を含む経路指定情報を含む。例示のマルチパーティ・サービス・アクセス環境４５０で使用されるユーザＩＤまたはＩＤストリングは、通常は以下に示す通りである。
＜ＦａｃｉｌｉｔｙＲｏｕｔｉｎｇＰｒｅｆｉｘ＞／［＜ＦａｃｉｌｉｔｙＬｏｃａｔｉｏｎＰｒｅｆｉｘ＞］／［＜ＣｕｓｔｏｍｅｒＲｏｕｔｉｎｇＰｒｅｆｉｘ＞］／［ＣｕｓｔｏｒｍｅｒＰｒｅｆｉｘ（ｓ）］／＜ＥｎｄＵｓｅｒＮａｍｅ＞＠［＜ＮｏｎＲｏｕｔｉｎｇＣｕｓｔｏｍｅｒＤｏｍａｉｎ＞］｜［＜ＣｕｓｔｏｍｅｒＲｏｕｔｉｎｇＤｏｍａｉｎ＞］
ここで、
＜ＦａｃｌｉｔｙＲｏｕｔｉｎｇＰｒｅｆｉｘ＞は、トラフィックをアクセス・ブローカー・システムまたはファシリティ４５４のネットワークに経路指定するためにＩＳＰ４５８、無線アクセス・プロバイダ４６０、コンテンツ配信プロバイダ４６２、電子商取引プロバイダ４６４など（アクセス・プロバイダ）が使用する独自開発のプレフィックスである。
＜ＦａｃｉｌｉｔｙＬｏｃａｔｉｏｎＰｒｅｆｉｘ＞は、ファシリティ４５４にアクセスを提供する点またはノードの位置を決定するためにファシリティが使用するプレフィックスである。
＜ＣｕｓｔｏｍｅｒＲｏｕｔｉｎｇＰｒｅｆｉｘ＞は、トラフィックを顧客のサイトに経路指定するためにアクセスまたはサービス・プロバイダ４５２が使用するプレフィックスである。
＜ＣｕｓｔｏｒｍｅｒＰｒｅｆｉｘ（ｓ）＞は、内部経路指定のために顧客４５６が使用するプレフィックスである。
＜ＥｎｄＵｓｅｒＮａｍｅ＞は、ファシリティ４５４を使用しているエンド・ユーザ５０２のログイン・ユーザ名である。
＜ＣｕｓｔｏｍｅｒＲｏｕｔｉｎｇＤｏｍａｉｎ＞は、トラフィックを顧客のサイトに経路指定するためにシステム４５４が使用するドメインである。ユーザＩＤストリングは＜ＣｕｓｔｏｍｅｒＲｏｕｔｉｎｇＰｒｅｆｉｘ＞または＜ＣｕｓｔｏｍｅｒＲｏｕｔｉｎｇＤｏｍａｉｎ＞を含む。
＜ＮｏｎＲｏｕｔｉｎｇＣｕｓｔｏｍｅｒＤｏｍａｉｎ＞は、内部経路指定のために顧客４５６が使用するドメインである。
【０１２０】
次に、一意のセッションＩＤを上記プロトコルの１つのプロトコルのユーザＩＤフィールドに適合させる実現可能な方法の一例を説明する。しかし一意のセッションＩＤを含めることを他の方法で実施することができるということが理解されよう。ダイヤラーがパスワードの暗号化にＥタイプのアルゴリズムを使用する場合、代わりの解決法の例が実施される。Ｅタイプのアルゴリズムは、ユーザ名の暗号化されたランダムな点を含む。暗号化されたランダムな点は、個々のユーザ・セッションの強力だが必ずしも絶対的ではないＩＤを提供し、したがって一意のセッションｉｄとして使用される。
【０１２１】
上記のように、例示のプロトコルがサポートする独自開発の情報に対する最小共通分母の使用可能なストリング長は、通常、約６３文字である。一意のセッションｉｄはユーザ名フィールドが科す制限内に適合すべきである。
【０１２２】
一意のセッションＩＤを生成するために（図２０のブロック８０２を参照のこと）、各サービス・プロバイダ４５２に常駐する接続ダイヤラーの一形態である接続アプリケーション４６６は、アクセス・ブローカー・システム４５４のウェブ・サーバ８０６のサーブレットから接続アプリケーション４６６を識別するダイヤラーＩＤを取得する（図１５を参照のこと）。ダイヤラーＩＤは、通常、一意のダイヤラーＩＤでもある。ダイヤラーＩＤは、ユーザ優先ファイルに記憶されており、ダイヤラーが最初にインストールされた際には、ユーザ優先ファイルのダイヤラーＩＤは通常は空である。ダイヤラー４６６が最初に、例えばインターネットに接続した時点では、ダイヤラー４６６は、通常、ウェブ・サーバ８０６に新しいダイヤラーＩＤを要求する（ブロック８００を参照のこと）。図示する実施形態では、ダイヤラーは、ウェブ・サーバ８０６から一意のダイヤラーＩＤを取得するまでは一意のセッションＩＤを作成しない。したがって、ダイヤラーＩＤが一意のセッションＩＤの一部を構成している本実施形態では、ダイヤラー４６６からの最初の正常なセッションは一意のセッションＩＤを含んでいない。しかしダイヤラー４６６は、いかなる後続の試行に対してもそのダイヤラーＩＤを有する。
【０１２３】
ダイヤラー４６６は、固有のダイヤラーＩＤに加え、内部的に維持され、ユーザ優先ファイルに記憶されているカウンター４６７も含む。カウンター４６７はダイヤル試行のたびに増分される（ブロック８０２を参照のこと）。ダイヤラー４６６は、ダイヤラーＩＤとカウンターを使用して本実施形態では１１文字で定義される（図１８を参照のこと）セッションＩＤインジケーターを後続のダイヤル試行のたびに生成する。カウンター４６７がダイヤル試行のたびに増分されるので、ダイヤラーは大域的に一意のセッションＩＤである＜ｄｉａｌｅｒ ｉｄ＞＜ｃｏｕｎｔｅｒ＞を生成する（ブロック８０２を参照のこと）。本実施形態では、セッションＩＤには、識別子、例えばユーザＩＤストリングがローミング・サーバ４７２に渡される前にトランザクション・サーバ４６８によって取り除かれた、ファシリティまたはアクセス・ブローカー・システム４５４に関連付けられた「ＯＵ」などの３文字によってプレフィックスが付けられる（図５を参照のこと）。したがって、一意のセッションＩＤに１１文字が含まれる場合、８文字はダイヤラーＩＤとカウンター用に使用可能であるということになる。
【０１２４】
例示のダイヤラーＩＤとカウンターの両方が基数６４を有する数を使用する。この番号付け方式に使用される記号はＡ〜Ｚ、ａ〜ｚ、０〜９、＆および？を含む。カウンター４６７は、各ダイヤルの試行以前に増分され、ダイヤラーＩＤは０で事前充填され、本実施形態では５桁の入力によって定義される。したがって、カウンター４６７用には３桁が残っている。したがって、ダイヤラーＩＤ用に使用される５桁は１０７３７４１８２４（十億以上）の一意のダイヤラーのインストールを可能にし、３桁のカウンターは２６２１４４のダイヤル試行を可能にする（一日あたり２０の試行と仮定して、カウンターは２３年後にリセットされることになっている）。したがってこの期間中、セッションＩＤは各ユーザ・セッションを一意に定義することになる。しかし、一意のセッションＩＤに割り振られ、または使用される文字数は、システムが対応するプロトコルの１つまたは複数のタイプによってシステムごとに異なる場合があるということを理解されたい。
【０１２５】
トランザクション記録の処理
図１４は、アクセス・ブローカー・システム４５４が役立つ場合がある、本発明の一実施形態によるアカウンティングおよび設定手順を示すブロック図である。
【０１２６】
ローミング・ユーザ５０２が遠隔ＩＳＰ５０６に接続する際、セッションを管理しているターミナル・サーバ（またはＮＡＳ）４７０は、ユーザＩＤストリングを含むトランザクション・データ記録、つまり１１文字の一意のセッションＩＤを生成し、この情報を認証サーバ６００に送信する。認証サーバ６００は、ネットサーバ４７０と共にローミング・ユーザに関連付けられたローミング・ドメイン名とプレフィックスを決定するためにアカウンティング情報を構文解析する。そのようなドメイン名またはプレフィックスがある場合、ユーザのアカウンティング情報はＲＳＡデータ・セキュリティーズからのアルゴリズムを使用して暗号化され、ネットサーバ４７０からセキュア・ソケット・レイヤ（ＳＳＬ）を介してトランザクション・サーバ４６８に送信される。
【０１２７】
ローミング・ユーザ５０２が遠隔ＩＳＰ５０６から切断する際、セッションを管理しているターミナル・サーバ（またはＮＡＳ）４７０は、ユーザＩＤストリングを含むトランザクション・データ記録、つまり１１文字の一意のセッションＩＤを生成し、この情報を認証サーバ６００に送信する。認証サーバ６００は、ネットサーバ４７０と共にローミング・ユーザに関連付けられたローミング・ドメイン名とプレフィックスを決定するためにアカウンティング情報を構文解析する。そのようなドメイン名とプレフィックスがある場合、ユーザのアカウンティング情報はＲＳＡデータ・セキュリティーズからのアルゴリズムを使用して暗号化され、ネットサーバ４７０からセキュア・ソケット・レイヤ（ＳＳＬ）を介してトランザクション・サーバ４６８に送信される。
【０１２８】
トランザクション・データまたはアカウンティング記録は、アカウンティング情報がデータベースに記憶されている場合に、ＳＳＬを利用しているトランザクション・サーバ４６８に略リアルタイムで通信される。マルチパーティ・サービス・アクセス環境４５０のすべての様々な構成要素または参加者は、ユーザＩＤストリング、つまり一意のセッションＩＤを受信するが、これはトランザクション・データ記録が設定システム４７６に送信される際に、単一ユーザ・セッションに関連付けられたトランザクション・データ記録に付随する。したがって、様々な異なる参加者から送信されたトランザクション・データ記録は、それら自体が発生する元になった単一ユーザ・セッションを識別する識別子を含む。
【０１２９】
これらのアカウンティング情報は、通話詳細記録（ＣＤＲ）を作るために設定システム４７６によってさらに処理される。各通話詳細記録は、関連サービス・アクセスが行われた場合にローミング・ユーザ５０２の識別に関する詳細な使用報告と、サービス・アクセスの位置と、各サービス・アクセス・セッションの長さおよびコストと、サービス・アクセスの時間（例えばローカル時間またはＧＭＴ時間）とを提供する。
【０１３０】
複数のトランザクション・サーバ４６８は、アカウンティングまたはトランザクション・データ記録を設定システム４７６に提供し、設定システム４７６はこれらの記録を利用して顧客４５６に対する請求書（またはインボイス）を作成し、サービス・プロバイダ５０４への支払いを行う。しかし、トランザクション・サーバ４６８に送信されたアカウンティング情報は、様々な理由から、不完全であり、あるＩＳＰと次のＩＳＰでは異なり、複数回送信される、などの可能性があるということを理解されたい。したがって、同一の単一ユーザ・セッションに関する様々な異なる、また不完全である可能性のある記録が、トランザクション・サーバ４６８によって受信される場合がある。
【０１３１】
当然ながら、特定のユーザ・セッションから発生するすべてのトランザクション・データ記録を識別または関連付けることは、設定システム４７４が請求書を作成し、それらを顧客４５６に分配し、その結果、顧客４５６が設定システム４７４に支払うことができ、同様に自身の顧客に対しても適宜請求書を作成することができるという点で有利である。同様に、設定システム４７４は、ローミング・ユーザが使用する利益を生むアクセス・タイムに関して遠隔（またはビジター）ＩＳＰまたは他のサービス・プロバイダ４５２に対して支払いを行う。設定システム４７４は、ローミング・ユーザが認可した使用に対する支払いもさらに保証することができる。したがって設定システム４７６の運営者は、複数の関係者間でサービス・アクセス・トランザクションの金銭上の決済を容易にするための機構を提供する安全で信頼性のあるエンティティとして動作する。設定システム４７６は、タイムリーで自動的かつ便利な方法で設定を可能にするために多数の自動機能および動作を実現する。そのような設定またはサービス・アクセス・トランザクションを容易にする設定システムの動作に関するさらなる詳細について以下で説明する。
【０１３２】
物理的アーキテクチャ
図１５は、本発明の一実施形態によるアクセス・ブローカー・システム４５４の物理的アーキテクチャを示す図である。複数のトランザクション・サーバ４６８は、それぞれが関連するデータベース８１２にアクセスする１つまたは複数のサーバ・マシン８１０に常駐しているように示されている。サーバ・マシン８０６に常駐しているウェブ・サーバと電話帳サーバは、遠隔内部ユーザ８１４および顧客４５６によってアクセス可能である。ウェブ・サーバは、ウェブ・ページ（例えばＨＴＭＬ文書）を生成し、遠隔内部ユーザ８１４と顧客４５６の両方に配信するように動作する。上記のように、本発明の一実施形態では、マシン８０６に常駐しているウェブ・サーバ上のサーブレットは、一意の接続アプリケーションＩＤをダイヤラーＩＤの一例である形態で、サービス・プロバイダ４５２に常駐している各ダイヤラーまたは接続アプリケーション４６６に提供する。電話帳サーバ（電話帳管理システム４８０の一部）は、顧客４５２の電子電話帳を維持・更新するように動作し、したがってサービス・プロバイダ４５２への／からの更新を受信／発行し、そのような更新を顧客４５６に発行する。
【０１３３】
設定システム４７６および内部ユーザ８１６の集合は、ファイヤーウォール８１８の背後に常駐しているように示されている。具体的には、設定システム４７４は、中央データベース８２２にアクセスする１つまたは複数のサーバ・マシン８２０上のホストとなる。
【０１３４】
概要−設定システム
図１６は、本発明の一実施形態による設定システム４７４のアーキテクチャを示すブロック図である。設定システム４７４は、バックエンド・アプリケーション８２４、フロントエンド・アプリケーション８２６、データ蓄積／報告アプリケーション８２８、およびシステム・インターフェース８３０を含んでいる。
【０１３５】
バックエンド（またはサーバ側）・アプリケーション８２４は、トランザクションの価格を設定し、１つのトランザクションに関与するすべての関係者の残高を更新し、信用限度を検証する設定アプリケーション８３２と、アカウンティング・サイクルを終了し、定期料金を適用し、インボイスおよび通話詳細記録（ＣＤＲ）を含む請求書報告を生成し、請求書報告をウェブに発行する請求書作成アプリケーション８３４と、ビジネス・ルールと中央データベース８２２の構造上の保全性とを検証する監査アプリケーション８３６とを含むように示されている。設定アプリケーション８３２は、柔軟な価格設定エンジン４７６を実施するように示されている。
【０１３６】
本実施形態では、設定アプリケーション８３２は、正規化機能、集計機能、および検証機能を担当する。正規化機能には、複数のトランザクション・サーバ４６８から受信したアカウンティング・データを請求書作成のために使用される単一形式ＣＤＲに変換すること、サービス・アクセス・トランザクションに関与する関係者を識別すること、および特定のサービス・アクセス・トランザクションに関してアクセス・ブローカー・システム４５４がプロバイダ４５２に対して支払い義務のある価格と顧客４５６がアクセス・ブローカー・システム４５４に対して支払い義務のある価格とを定義することが含まれる。集計機能には、サービス・アクセス・トランザクションに関与するすべての関係者について購入価格と販売価格を残高に記入すること、および適切な残高を更新することを必要とする。検証機能には、信用限度の検証が含まれる。
【０１３７】
設定システム４７４は、プロバイダ４５２と顧客４５６の両方による略リアルタイムの収入／勘定追跡を可能にするサービス・アクセス・トランザクションの略リアルタイムの設定を提供するよう動作する。
【０１３８】
本発明のある種の実施形態では、設定システム４７４は、以下の特徴を有する柔軟な価格設定モデルをサポートする柔軟な価格設定エンジン４７６を含む。
１．顧客４５６、サービス・プロバイダ４５２、サービス・アクセスの位置、サービス・アクセスの種類（例えばダイヤルアップ・モデム、ＩＳＤＮ、ＤＳＬ）、または特定の顧客４５６について特定周期中に蓄積された使用量などによって異なる多彩なデータ構造。
２．（ａ）使用量による（例えば速度およびセッションの長さに応じた）価格設定、（ｂ）トランザクションによる（トランザクションあたりいくらという）価格設定、および（ｃ）加入ベースの、すなわち均一な価格設定（例えば顧客４５６に対する１回の請求書作成周期中の全使用量に対する１つの価格、または請求書作成周期中の顧客に対するユーザごとの１つまたは複数の価格）。
３．申し込まれた割引および販売促進。
４．開業料金、月次料金、および最低月次手数料のような様々な料金。
５．マルチティアの価格設定方式、または内部プロバイダ・ローミング。ここで特定の位置に関する買い相場と売り相場はプロバイダ４５２によって異なり、またサービス・アクセスのサービス・ユーザ／顧客４５６がさらに別の顧客４５６、その提携者、またはそれらの顧客に属しているか否かによって異なる。
【０１３９】
この柔軟な価格設定エンジン４７６はデータベース主導によるものであり、したがって適切な計画を中央データベース８２２内で維持されている価格設定テーブル（図示せず）にロードすることによって新しい価格設定モデルの実施を可能にしている。より具体的には、柔軟な価格設定エンジン４７６は、マルチティアの価格設定モデルに役立ち、それによって単一サービス・アクセス・トランザクションに対する相場は、複数の基準によって消費者（または顧客）の複数のティア(tier)全体に適用することができる。これらの基準には、特に、使用量（例えば蓄積された使用時間または値の合計）による価格設定、およびトランザクション（例えば蓄積されたトランザクションの合計数）による価格設定の任意の組み合わせを含めることができる。
【０１４０】
図１６およびフロントエンド・アプリケーション８２６に戻ると、データ管理アプリケーション８３８は、ビジネス・プロセスを実行し、情報目的でデータを閲覧するためにアクセス・ブローカーの様々な機能ユニットによって使用される。この目的で、データ管理アプリケーション８３８は、顧客４５６およびアクセス・ポイントに関する情報を管理し、アカウンティング機能および経営管理機能を実行するために様々なユーザ・インターフェースを提供することができる。
【０１４１】
注文処理アプリケーション８４０は、新しい法人顧客に注文を出すために顧客４５６（例えばソリューション・パートナー４８８または再販業者）にユーザ・インターフェースを提供する。
【０１４２】
データ蓄積／報告アプリケーション８２８は、運営報告、機能報告、およびネットワーク・ロード報告を可能にするように日毎、または月毎にデータを集計する複数の処理を含む。
【０１４３】
システム・インターフェース８３０は、トランザクション・サーバ・ローダー８４２、プロバイダ・ローダー８４４、およびアカウンティング・システム・インターフェース（図示せず）を含むローダー・アプリケーションを有する。まずトランザクション・サーバ・ローダー８４２を扱うことによって、「データ・ローダー」構成要素は、それぞれのトランザクション・サーバ４６８のデータベース８１２から中央データベース８２２に、一意のセッションＩＤを含めてトランザクション・データ記録の形式でアカウンティング記録を処理するためにプルする。複数のトランザクション・サーバまたはバッチ・ローダー８４２は、分散型データベース・リンクとして実施することができ、アカウンティングまたはトランザクション・データ記録は略リアルタイムでローダー８４２を介してプルされる。
【０１４４】
概要−データ・モデル
図１７Ａは、顧客テーブル８４６、アクセス・ポイント・テーブル８４８、価格設定テーブル８５０、ＣＤＲテーブル８５２、アカウンティング・テーブル８５４、認証トランザクション記憶領域またはテーブル８５６、バッチ履歴記憶領域またはテーブル８５８、およびＳＱＭ記憶領域またはテーブル８６０を含むデータ・モデル例８４５を示すブロック図である。
【０１４５】
アクセス・ブローカー・システム４５４のネットワーク構成要素は、ある種の実施形態では、トランザクション・データ記録から経路指定プレフィックスを取り除くことができる。これらの構成要素のいくつかは、ユーザＩＤストリングの末尾を切り捨てることもできる。一意のセッションｉｄプレフィックスは、経路指定プレフィックスではなく、またユーザ名の末尾にあるわけでもないので、取り除かれることも末尾が切り捨てられることもない。したがってユーザＩＤストリングは、それがユーザ・セッションを一意に定義するよう使用される前にこれらの欠点を除去するために処理される。変更されたユーザ・セッションＩＤは、使用可能な以下の構成要素の多くを使用して構築される。
＜ＡｕｔｈＣｕｓｔｏｍｅｒＩｄ＞／＜ＵｎｉｑｕｅＩＤ＞／［ＣｕｓｔｏｍｅｒＰｒｅｆｉｘ（ｓ）］／＜ＥｎｄＵｓｅｒＮａｍｅ＞＠＜ＮｏｎＲｏｕｔｉｎｇＣｕｓｔｏｍｅｒ Ｄｏｍａｉｎ＞
ここで、
＜ＡｕｔｈＣｕｓｔｏｍｅｒＩｄ＞は、顧客ソリューション・プロセスによって作られた認証顧客ＩＤである。
＜ＵｎｉｑｕｅＩＤ＞は、上記のような接続アプリケーション４６６によって生成された一意のセッションＩＤコード、０Ｕｘｘｘｘｘｘｘｘ／、プレフィックスである。
＜ＣｕｓｔｏｍｅｒＰｒｅｆｉｘ（ｓ）＞は、上記のような内部経路指定のために顧客が使用するプレフィックスである。
＜ＥｎｄＵｓｅｒＮａｍｅ＞は、上記のようなアクセス・ブローカー・システム４５４に接続しているエンド・ユーザのユーザＩＤである。
＜ＮｏｎＲｏｕｔｉｎｇＣｕｓｔｏｍｅｒＤｏｍａｉｎ＞は、上記のような内部経路指定のために顧客が使用するドメインである。
【０１４６】
特に図１７Ｂを参照すると、プロバイダ・ローダー８４４は、一意のセッションＩＤを含む通話詳細記録（ＣＤＲ）またはトランザクション・データ記録をプロバイダ４５２からバッチ形式で受信する。ＣＤＲデータはプロバイダ・ローダー８４４によって処理される。プロバイダ・ローダー８４４は適切なＦＴＰサイトからデータを取り出し、それをトランザクション・サーバ４６８から受信したデータと同じ形式に変換することができる。具体的には、トランザクション・サーバ４６８は、ユーザ・アクセス・セッションが上記のように認証されるたびに変更されたユーザ・セッションＩＤを構築し、それを認証トランザクション・テーブル８５６のｓｅｓｓｉｏｎ＿ｉｄフィールドに、またアカウント・トランザクション・テーブル８５４のｓｅｓｓｉｏｎ＿ｉｄフィールドに記憶する（図１７Ａを参照のこと）。認証トランザクション・テーブル８５６に記憶されている変更されたセッションＩＤごとに、対応するトランザクション・データ記録は、処理するために設定システム４７４によって受信されるべきであるということが理解されよう。トランザクション・サーバ４６８と類似の仕方で、バッチ・ローダー８４２、８４４はそれぞれに、サービス・プロバイダ４５２のトランザクション・サーバ４６８から受信した各トランザクション・データ記録から変更されたトランザクション・データ記録を組み立て、または構築する（図５および１７Ｂを参照のこと）。ローダー８４２、８４４からの変更されたセッションＩＤは、バッチ履歴テーブルのｓｅｓｓｉｏｎ＿ｉｄフィールドに記憶される。同様にして、ＳＱＭプロセスは、変更されたセッションＩＤを構築し、それをＳＱＭテーブル８６０のｓｅｓｓｉｏｎ＿ｉｄフィールドに記憶する。
【０１４７】
一意のコードを含めて一意のセッションＩＤの使用は、以下の問題に対処する際に使用することができる。
【０１４８】
欠落したアカウンティング記録
欠落したアカウンティング／トランザクション・データ記録（図１９のブロック８６２を参照のこと）は、配信の失敗、変形した記録、誤った経路指定など様々な理由で発生する可能性がある。配信の失敗は、ＩＳＰからのインターネット接続（例えば図６のネットサーバ４７０）が中断され、したがって設定システム４７６へのトランザクション・データ記録の配信がブロックされた場合に発生する可能性がある。数分以上の長期にわたって続く接続の停止は、通常、最低限の送信再試行機能が原因でネットサーバ４７６にトランザクション・データ記録を破棄させることになる。ＲＡＤＩＵＳプロトコルを使用する際、変形した記録は、通常、サービス・プロバイダの認証サーバを含めて複数の中間点のどこでも破棄される（例えば認証／認可サーバ６０２またはネットサーバ４７０（図６を参照のこと））。誤って経路指定された記録は、偶然または不正な目的でＩＳＰ認証サーバ６０２の構成が不適切であるために送信されない記録である。
【０１４９】
ユーザによるすべてのアクセス・セッションは最初に認証を必要とするので、認証トランザクション・テーブル８５６の各ｓｅｓｓｉｏｎ＿ｉｄフィールドはａｃｃｔ＿ｔｒａｎｓテーブルに対応するｓｅｓｓｉｏｎ＿ｉｄフィールドを含むべきである。したがって、ｓｅｓｓｉｏｎ＿ｉｄフィールドを関連付け、照合し、相関関係を証明し、精査することにより、欠落したアカウンティング／トランザクション・データ記録を決定することができる。図示する実施形態では、欠落したアカウンティング／トランザクション・データ記録は、通常、認証トランザクションすなわちａｕｔｈ＿ｔｒａｎｓテーブル８５６に認証要求記録を有するが、アカウンティングすなわちａｃｃｔ＿ｔｒａｎｓテーブル８５４には一致するアカウンティング開始および／またはアカウンティング停止記録は有しない。したがって、ａｕｔｈ＿ｔｒａｎｓテーブルの各ｓｅｓｓｉｏｎ＿ｉｄフィールドに対応するａｃｃｔ＿ｔｒａｎｓテーブルのすべてのｓｅｓｓｉｏｎ＿ｉｄフィールドを検索することによって、欠落したアカウンティング／トランザクション・データ記録を発見することができる（ブロック８６４〜８７２を参照のこと）。
【０１５０】
不適切なアカウンティング記録
不適切なアカウンティング／トランザクション・データ記録は、一般に図６のサーバ６００などのプロバイダの認証サーバ（ＡＡＡサーバ）の不適切な構成が原因で設定システム４７４（図６を参照のこと）によって受信される場合がある。不適切な構成により、通常、プロバイダの認証サーバ６００は、すべてのアカウンティング／トランザクション・データ記録をユーザ・アクセス・セッションの認証を担当するプロキシだけにではなく、すべてのプロキシに送信することになる。この場合、不正確な受信者のａｕｔｈ＿ｔｒａｎｓテーブルにはｓｅｓｓｉｏｎ＿ｉｄフィールドがまったくない。これらのアカウンティング／トランザクション・データ記録は、通常、対応する認証記録を有していないので、これらは比較的容易に識別することができ、また例えば顧客サポート・チームは、プロバイダの構成上の問題を解決することができ、そのような不正確な伝送の再発を防止することができる。これらの場合、図１９に示す方法を使用することができる。ただし、ａｃｃｔ＿ｔｒａｎｓテーブルのエントリに対応する一意のセッションＩＤを見つけるためにａｕｔｈ＿ｔｒａｎｓテーブルが検索される。
【０１５１】
重複したアカウンティング記録
重複したアカウンティング記録は、同一の単一アクセス・セッションを記述する複数のトランザクション・データ記録である。図示する実施形態では、重複したトランザクション・データ記録は、各リアルタイムのアカウンティング／トランザクション・データ記録の６個の「鍵」フィールドを過去３０日以内に受信したすべての他のリアルタイム・アカウンティング／トランザクション・データ記録と照合する比較的単純なアルゴリズムを使用して設定システム４７４によってアクティブにフィルタリングされる。使用されるフィールドの例としては、ＲＡＤＩＵＳセッションＩＤ、プロバイダＩＤ、ＮＡＳ ＩＰアドレス、ユーザ、ドメイン（ユーザａｕｔｈ領域）およびセッション・タイムがある。
【０１５２】
ある種の実施形態では、すべての６個のフィールドがＣＤＲテーブルの格付け済み記録内のフィールドと一致した場合、現行の記録は重複とマーク付けされ、破棄される。
【０１５３】
重複したアカウンティング記録は、以下の様々な理由から生じる可能性がある。
【０１５４】
アカウンティング／トランザクション・データ記録は、送信者に対してアカウンティング−応答メッセージを適宜送信することによって確認応答する必要がある。残念ながら、「適宜」はＲＡＤＩＵＳの仕様によっては定義されず、数秒後、数時間後、または数日後に異なるベンダーおよび構成が確認応答していないアカウンティング・トランザクションを再送する場合がある。アカウンティング要求は設定システムによって実際に受信されたが、確認応答が消失または変形した場合、発信者はアカウンティング記録の複数のコピーを再送する場合がある。そのような記録はすべて、受信側トランザクション・サーバ４６８によって補足され、最終的には処理するために設定システム４７４によって取り出される。このクラス特有の変形が発生する場合があるが、これは設定重複フィルタリング・アルゴリズムを逃れるものであり、送信側ＮＡＳ５３２は再送のたびに更新された（例えば増分されて長くなった）セッション・タイムを送信するか、またはＲＡＤＩＵＳセッションＩｄが再送と再送の間で変更される。場合により、ＮＡＳ５３２は一定したＮＡＳ ＩＰアドレスを送信せず、その場合、アクセス・セッションをサービス・プロバイダすなわちＩＳＰに関連付けるために別の属性（例えばコールド・セッションＩｄまたはプロバイダＩｄ）が使用される。このような場合、重複した検出のためにＮＡＳ ＩＰの有用性が低減される。
【０１５５】
重複したアカウンティング記録は「バッチ」プロバイダによって送信することができるが、この「バッチ」プロバイダのアカウンティング供給は重複のないものと仮定される。上記理由の１つにより、リアルタイム・アカウンティング・プロバイダがアカウンティング記録を配信することに失敗した場合、そのアカウンティングの責任を全うするためにそのリアルタイム・アカウンティング・プロバイダによって記録のバッチが送信された場合、重複したアカウンティング記録を設定システム４７４に手動で挿入することができる。これらの場合、サービス・プロバイダ４５２は任意のデータセットを送信することができるが、この任意のデータセットはデータ正規化プロセスへの提出に備えてアクセス・ブローカー・システム４５４の要員が特別に処理する必要がある。このようなデータセットは、以前に報告されたセッションと、訂正が試行されている欠落したセッションの両方を記述するデータを含むことができる。これらの記録バッチは通常は単発で事前処理されるので、重複した挿入を防止するための管理はほとんどない。このプロセスは、一意のセッションＩＤに鑑みて自動化することができるということが理解されよう。
【０１５６】
いくつかのサービス・プロバイダは、鍵重複フィールドを不規則に使用することを原因に重複したトランザクション・データ記録をアクセス・ブローカー・システム４５４に入れることを許可する場合がある。例えばある種の状況では、サービス・プロバイダはＮＡＳ ＩＰ属性をランダムなデータで充填し、したがって重複フィルタリング基準が悪影響を受ける。矛盾したセッションｉｄの生成またはユーザ切断時におけるセッション期間の調整失敗のような他の変則事項により、別個のセッションに対応するように見える重複が生成される場合がある。ここでもまた、一意のセッションＩＤはこれらの問題を解決する際に役立つ場合がある。
【０１５７】
本明細書で例示するように、重複アカウンティング／トランザクション記録は、各リアルタイム・アカウンティング／トランザクション・データ記録の６個の「鍵」フィールドを過去３０日以内に受信されたすべての他のリアルタイム・アカウンティング／トランザクション・データ記録と照合するアルゴリズムを使用して設定システム４７４によってアクティブにフィルタリングされる。それぞれの承認された単一セッションを一意に識別する一意のｓｅｓｓｉｏｎ＿ｉｄフィールドを使用することによって、精度を高めることができる。
【０１５８】
重複エイリアス記録
重複を検出するアルゴリズムがある記録を重複であると不適切に識別した場合、重複エイリアス記録が発生する。例えばサービス・プロバイダのＮＡＳ（例えば図６のＩＳＰ ５１０のＮＡＳ５３２）が短期間にセッションＩＤデータ値を生成または再利用しない場合、このようなケースが生じる可能性がある。信頼性のないサービス・プロバイダによって生成されたいかなるセッションＩＤに加えて、またはこれの代わりに、各単一アクセス・セッションを一意に定義する本発明の実施形態の一意のセッションＩＤは、重複したエイリアス記録の発生を低減させるために重複検出アルゴリズムによって使用することができる。具体的には、各セッションが一意に識別される際に重複エイリアス記録を少なくとも実質的に低減するためにｓｅｓｓｉｏｎ＿ｉｄテーブル内の変更された一意のセッションＩＤを使用することができる。
【０１５９】
無効セッション−長さ記録
アクセス・セッションの期間に関する設定システム４７４によって受信されたすべてのアカウンティング／トランザクション・データ記録は、いつも完全であるとは限らないということが理解されよう。例えばアカウンティング／トランザクション・データ記録は、セッション期間データ（例えばＡｃｃｔ−Ｓｅｓｓｉｏｎ−Ｔｉｍｅ属性）が欠落しており、０値を含んでおり、セッションに対する不正確な値（例えばあるセッションは実際には３分の長さなのに４分の長さであると報告すること）を含んでおり、ＲＦＣ ２１３９、セクション５．７で規定されるような過度に大きな値を含んでいるか、または無効であるなどの場合がある。無効アクセス期間は、例えばサービス・プロバイダのモデム・バンクがユーザによる切断を報告せず、別のセッションが同じ物理的なモデム・ポートで開始されるか、または何らかの他の理由からタイムアウトが発生するまでＮＡＳ５３２がセッション・タイムを蓄積し続ける場合に発生する可能性がある。
【０１６０】
重複した無効セッションの長さを有するアカウンティング／トランザクション・データ記録は、例えば以下のような様々な理由から生じる場合がある。
【０１６１】
欠落したＡｃｃｔ−Ｓｅｓｓｉｏｎ−Ｔｉｍｅ
アカウンティング／トランザクション・データ記録がネットサーバ４７０によって受信され、Ａｃｃｔ−Ｓｅｓｓｉｏｎ−Ｔｉｍｅ属性が欠落している場合、ネットサーバ４７０は、通常、０セッション長を有するアカウンティング／トランザクション・データ記録を転送する。
【０１６２】
不正確なＡｃｃｔ−Ｓｅｓｓｉｏｎ−Ｔｉｍｅ
ＮＡＳ５３２による不正確な時間のアカウンティング、またはサービス・プロバイダによる意図的な不正行為によって、不正確なセッション期間を有するアカウンティング／トランザクション・データ記録が生成される場合がある。
【０１６３】
Ａｃｃｔ−Ｓｅｓｓｉｏｎ−Ｔｉｍｅ０
０値のＳｅｓｓｉｏｎ−Ｔｉｍｅ属性を有するアカウンティング／トランザクション・データ記録がネットサーバ４７０によって受信されると、ネットサーバ４７０は、通常、０セッション長を有するアカウンティング／トランザクション・データ記録を転送する。
【０１６４】
長いＡｃｃｔ−Ｓｅｓｓｉｏｎ−Ｔｉｍｅ
不正行為、誤作動、または不適切な構成が原因でセッション・タイム・アカウンティングは法外な長さのセッションを識別する場合がある。
【０１６５】
切断検出の失敗
「長い」セッションまたは同一期間を有する複数のセッションは、サービス・プロバイダのモデム・バンクの誤動作および／またはユーザが長期間切断されていることを検出することができないその不適切な構成が原因で発生する場合がよくある。
【０１６６】
不正アクセス
長期のセッション・タイムは、悪意のあるユーザによる連続した使用が原因で発生する場合もある。
【０１６７】
破損したＡｃｃｔ−Ｓｅｓｓｉｏｎ−Ｔｉｍｅ
ＮＡＳ５３２、サービス・プロバイダの認可／認証サーバ６００、またはサービス・プロバイダのネットサーバ４７０によるフィールド処理でのエラーは、アカウンティング／トランザクション・データ記録のセッション・タイム属性を破損する可能性がある。実際のサンプルに基づき、何らかの先行ＲＡＤＩＵＳパケットに長い、ベンダー特有のデータがある場合に発生することが多い。
【０１６８】
本物の長いセッション
長いセッションのフィルタリングの精度は、フィルター閾値（通常は約１００時間）によって異なる。
【０１６９】
ＳＱＭ記録に提供されたセッション長をアカウンティング記録に提供されたセッション長に対して相関関係を証明し、関連付けるなどによって精度を強化することができる。各トランザクション・データ記録はその一意のセッションＩＤを有しているので、セッション長はａｃｃｔ＿ｔｒｎｓテーブルのｓｅｓｓｉｏｎ＿ｉｄフィールドとＳＱＭテーブル８６０のｓｅｓｓｉｏｎ＿ｉｄフィールドを使用して関連付けられた記録から取得することができる。したがって、あるトランザクション・データ記録で欠落しているデータは、一意のセッションＩＤを有する別のトランザクション・データ記録から取得することができる。
【０１７０】
アカウンティング記録のオーバーラッピング
ある場合には、トランザクション・データ記録は、時間的にオーバーラップしている同じユーザの信用証明書（例えば同じユーザ名およびパスワード）を含むサービス・プロバイダから受信される。本発明の本実施形態では、各アクセス・セッションは一意のセッションＩＤを含むので、オーバーラップしているトランザクション・データ記録の分析が容易になる場合がある。具体的には、それらの記録のセッションの詳細を決定するためにａｃｃｔ＿ｔｒａｎｓテーブル８５４のｓｅｓｓｉｏｎ＿ｉｄフィールドとＳＱＭテーブル８６０のｓｅｓｓｉｏｎ＿ｉｄフィールドを使用することができる。例えば、一意のセッションＩＤを使用することによって、そのようなセッションが２つの本物の別個のセッションであるか否か、あるいはそのセッションが異常なＮＡＳ５３２が原因で生成されたものか否かを判定することができる。
【０１７１】
真偽が問われる記録
セッションＩＤは各単一のセッションを一意に識別し、一意のセッションＩＤを含むセッションに関するデータはシステム内の様々な異なるサーバに送信されるので、真偽問題の解決が容易になる場合がある。具体的には、顧客サポート・チームは、認証または認可されたトランザクション、アカウンティングおよびＳＱＭテーブル８５６、８５４、および８６０のセッション詳細をそれぞれに比較することができ、これによって単一ユーザ・アクセス・セッションに一意に関連付けられたトランザクション・データの３つの異なるソースが提供される。これらテーブルのｓｅｓｓｉｏｎ＿ｉｄフィールドは、特定ユーザのアクセス・セッションの詳細を裏付けるために関連付けまたは相関関係の証明などに役立つ。
【０１７２】
チャレンジ・プロバイダ記録の記録品質
各セッションは一意に識別され、様々な異なるサーバはトランザクション・データ記録を設定システム４７４に独立して通信するので、特定のサービス・プロバイダから受信したトランザクション・データ記録の品質は、その特定のサービス・プロバイダからのトランザクション・データ記録を他のソースからの記録と比較することによって評価することができる。これは、そのようなアカウンティング機能に関する問題、またはサービス・プロバイダの技術問題に関する問題を分離する際にネットワーク・アクセス・チームに役立つ場合がある。
【０１７３】
複数人員による合法的Ｉｄの使用
一意のセッションＩＤが各単一のユーザ・セッションを一意に識別するので、単一ユーザＩＤデータの合法的使用法が複数のユーザによって使用される別個のユーザ・アクセスの発生を識別するために使用することができる。したがって、４５６顧客は、例えば組織が小規模であり、かつ／またはそのような仕方で動作することを選択するという理由で、同一のログイン名を共有する場合がある。このような場合、開始時が同時でセッション長が同じ複数の位置からのログインがある場合がある。一意のセッションＩＤの内包は、それらの状態を高度な精度をもって精査するために使用される。
【０１７４】
ダイヤラーのポリシー管理バージョニング
ＳＱＭ記録をアカウンティング記録に関連付け、相関関係を証明するなどのために一意のセッションＩＤを使用することができる。これにより、ＳＱＭ記録なしに作成されたアカウンティング記録を、アクセス・ブローカー・システム４５４によって関連付けられない、あるいは提供されない、接続アプリケーション（例えば接続アプリケーション４６６）の使用、またはそのサポートされていないバージョンの使用を明らかにするために使用することができる。通常、接続アプリケーション４６６のサポートされていないバージョン（例えば接続ダイヤラー技術）を使用している顧客および個別ユーザに関して報告が作成される。これは、そのようなユーザをより最新のバージョンに移動させるために役立つ。このような状況では、顧客４５６が不適切な接続アプリケーション４６６を使用している場合、その顧客に関連付けられたアカウントを自動的にディセーブルすることができる。したがって、その問題を識別するために、アクセス・ブローカー・システム４５４に連絡を取り、その結果バージョンの移動を強制することを顧客４５６に強制することができる。
【０１７５】
全体的な請求書作成プロセスの品質の改善
したがって、単一ユーザ・セッションに関連付けられたすべてのトランザクション・データ記録を一意に識別する一意のセッションＩＤを包含することによって、トランザクション記録の処理の精度が高められるということが理解されよう。したがって、請求書作成の真偽の問題が生じることは少なくなり、発生する可能性のあるいかなる真偽の問題の解決法もより迅速に確定することができる。
【０１７６】
図１３は、２０５、３０５、または４０５のようなネットワーク・アクセス・デバイス、ネットワーク・ダイヤラー４６６、または２４０、３５０、４６８、または４７２のようなネットサーバとして構成することができるコンピュータ・システム７００を示す図である。コンピュータ・システム７００は、システム・バス７４５を介してランダム・アクセス・メモリ（ＲＡＭ）７３５および読み出し専用メモリ（ＲＯＭ）７４０に動作可能に接続されているプロセッサ７５０を含む。プロセッサ７５０は、入出力バス７３０を介して、光ディスクまたは他の記憶媒体であってよい固定ディスク７２０にも接続されている。あるいは、プロセッサ７５０は、入出力バス７３０を介して複数の記憶デバイスに接続することができる。プロセッサ７５０は、システム・バス７４５および入出力バス７３０を使用してデータを通信する。
【０１７７】
システム・バス７４５と入出力バス７３０は、キーパッド７２５または入力デバイス７１０からの入力を受信することもできる。システム・バス７４５と入出力バス７３０は、ディスプレイ７０５、固定ディスク７２０、および／または出力デバイス７１５に出力を提供することができる。メモリおよび記憶媒体７３５、７４０は、フラッシュ・メモリ、ＥＥＰＲＯＭ、または上記のいかなる組み合わせも含むことができる。
【０１７８】
コンピュータ・システム７００は、オペレーティング・システム・ソフトウェアの一部であるディスク・オペレーティング・システムのようなファイル管理システムを含むオペレーティング・システム・ソフトウェアによって制御することができる。ファイル管理システムは、ＲＯＭ７４０のような不揮発性記憶デバイスに記憶することができ、データを入力および出力し、そのデータをＲＡＭ７３５およびＲＯＭ７４０上に記憶するためにオペレーティング・システムによって要求される様々な機能をプロセッサ７５０に実行させるよう構成することができる。コンピュータ・システム７００の一実施形態では、プロセッサ７５０に、ネットワーク・アクセス・デバイス２０５または３０５のようなネットワーク・アクセス・デバイスの機能を実行させる命令を固定ディスク７２０またはＲＯＭ７４０に記憶することができる。代替形態では、プロセッサ７５０に、ネットサーバ２４０、３５０、４７２、または４６８のようなネットワーク暗号解読サーバの機能を実行させる命令を固定ディスク７２０またはＲＯＭ７４０に記憶することができる。
【０１７９】
以上、コンピュータ・システムへのアクセスを要求しているユーザのデバイスを認証する方法およびシステムを開示した。上記の詳細な説明では、本発明はその特定の実施形態を参照して説明した。しかし、首記の特許請求の範囲に示す本発明のより広範な範囲および趣旨を逸脱せずに、本発明に様々な修正形態および変更を行うことができることが明らかになろう。したがって本明細書および図面は、限定の意味ではなく説明の意味でみなされたい。
【図面の簡単な説明】
【０１８０】
【図１】安全でない方法を使用してネットワーク・ユーザの信用証明書が認証される従来技術のＩＳＰネットワーク構成を示す図である。
【図２】本発明の一実施形態と調和する、ＩＳＰネットワーク、ネットワーク・アクセス・デバイス、およびネットワーク暗号解読サーバ含むネットワーク構成を示す図である。
【図３】本発明の一実施形態と調和する、遠隔ＩＳＰネットワーク、ネットワーク・アクセス・デバイス、およびネットワーク暗号解読サーバを含むネットワーク構成を示す図である。
【図４】ネットワーク・ユーザの信用証明書を安全に認証する方法の一例としての動作の流れ図である。
【図５】多数のサービス・プロバイダ、アクセス・ブローカー・システム、および複数の顧客を含む、本発明の一実施形態によるマルチパーティ・サービス・アクセス環境を示すブロック図である。
【図６】ローミング・インターネット・アクセスを提供するための、本発明の一実施形態によるアクセス・ブローカー・システムの動作を示す概略図である。
【図７】本発明の一実施形態による接続ダイヤラーの概略的な機能ブロック図である。
【図８】暗号解読機能を含む、本発明の一実施形態によるトランザクション・サーバの概略的な機能ブロック図である。
【図９】暗号解読機能を含む、本発明の別の一実施形態による顧客またはローム・サーバの概略的な機能ブロック図である。
【図１０】接続ダイヤラーによって実行される暗号化メソッドの一例の概略的な流れ図である。
【図１１】トランザクション・サーバまたは顧客サーバによって実行される暗号解読方法の一例の概略的な流れ図である。
【図１２】チェックサム・データの暗号化メソッドの一例の概略的な流れ図である。
【図１３】ネットワーク・アクセス・デバイスまたはネットワーク暗号解読サーバとして構成することができるコンピュータ・システムの概略図である。
【図１４】本発明の一実施形態による、ローミング・インターネット・アクセスを提供するアクセス・ブローカー・システムの動作を示す概略的なブロック図である。
【図１５】図１４のアクセス・ブローカー・システムの物理的アーキテクチャ例の概略的なブロック図である。
【図１６】設定システム例の概略的なブロック図である。
【図１７Ａ】アクセス・ブローカー・システムで使用されるデータ・モデル例を示す図である。
【図１７Ｂ】本発明による一意のセッションＩＤを使用した、同様に本発明による処理を示す概略図である。
【図１８】本発明の一実施形態による一意のセッションＩＤ例を示す図である。
【図１９】一意のセッションＩＤを使用して欠損しているトランザクション・データ記録を識別する方法の概略的な流れ図である。
【図２０】同様に本発明の一実施形態による接続アプリケーションでの一意のセッション識別方法の概略的な流れ図である。

Claims (34)

1. コンピュータ・システムへのアクセスを要求しているユーザのデバイスを認証する方法において、
   ユーザがコンピュータ・システムへのアクセスを要求するユーザのデバイスの接続アプリケーションで、ユーザの要求ごとに変わる現行セッション・データを暗号化するステップと、
   暗号化された現行セッション・データを、平文で通信されるアクセス要求のユーザ認証データに含めるステップと、
   アクセス要求を暗号解読し、基準セッション・データを暗号解読された現行セッション・データと比較するステップと、
   比較の結果に応じてユーザの要求を選択的に分類するステップと
   を含む方法。
2. ユーザの要求が有効なユーザの要求として分類された場合、暗号解読された現行セッション・データを基準セッション・データとして記憶するステップを含む請求項１に記載の方法。
3. セッション・データが、ユーザ・セッションごとに変更される番号を含む請求項２に記載の方法。
4. 番号がユーザの要求ごとに増分され、番号が基準番号よりも大きくない場合、ユーザの要求がリプレイ攻撃として分類される請求項３に記載の方法。
5. 現行セッション・データが基準セッション・データとして記憶されている場合、基準の日付および時刻を記憶するステップと、
   現行セッション・データに関連付けられた現行の日付および時刻を基準の日付および時刻と比較するステップと、
   基準の日付および時刻の現行の日付および時刻の間の差が所定のウィンドウ期間内である時に現行セッション・データが基準セッション・データと同一である場合、ユーザの要求を有効な要求として分類するステップと
   を含む請求項２に記載の方法。
6. ポイント・ツー・ポイント・プロトコル（ＰＰＰ）、パスワード認証プロトコル（ＰＡＰ）、チャレンジ・ハンドシェーク認証プロトコル（ＣＨＡＰ）、遠隔認証ダイヤルイン・ユーザ・サービス（ＲＡＤＩＵＳ）プロトコル、ターミナル・アクセス・コントローラ・アクセス制御システム（ＴＡＣＡＣＳ）プロトコル、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）、ＮＴドメイン認証プロトコル、Ｕｎｉｘパスワード認証プロトコル、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュア・ソケット・レイヤを介したハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、拡張認証プロトコル（ＥＡＰ）、転送レイヤ・セキュリティ（ＴＬＳ）プロトコル、トークン・リング・プロトコルおよびセキュア遠隔パスワード・プロトコル（ＳＲＰ）のうちの１つのプロトコルを使用して通信に適した形式で暗号化セッション・データを提供するステップを含む請求項１に記載の方法。
7. 楕円曲線暗号法と共に使用するのに適した公開／秘密鍵対を使用してセッション・データを暗号化するステップを含む請求項１に記載の方法。
8. セッション・データが、単一のユーザ・セッションに一意に関連付けられた一意のセッションＩＤを含む請求項１に記載の方法。
9. 暗号解読された現行セッション・データと基準セッション・データを比較するステップが、複数のサービス・プロバイダを含むサービス・アクセス・システムのネットワーク・アクセス・サーバ、トランザクション・サーバ、および認証サーバの少なくとも１つで実行される請求項１に記載の方法。
10. コンピュータ・システムへのアクセスを要求しているアクセス・デバイスによるリプレイ攻撃を識別する方法において、
    暗号化されたアクセス要求を平文でアクセス・デバイスから受信するステップと、
    アクセス要求を暗号解読し、アクセス・デバイスによって生成された、アクセス要求内の現行セッション・データを識別するステップと、
    暗号解読された現行セッション・データを基準セッション・データと比較するステップと、
    比較の結果に応じてユーザの要求をリプレイ攻撃として選択的に分類するステップと
    含む方法。
11. ユーザの要求が有効なユーザの要求として分類された場合、暗号解読された現行セッション・データを基準セッション・データとして記憶するステップを含む請求項１０に記載の方法。
12. セッション・データがユーザ・セッションごとに変更される番号を含み、現行の番号を基準の番号と比較するステップと、現行の番号が基準の番号よりも小さい場合、ユーザの要求をリプレイ攻撃として分類するステップとを含む請求項１１に記載の方法。
13. 現行セッション・データが基準セッション・データとして記憶されている場合、基準の日付および時刻を記憶するステップと、
    現行セッション・データに関連付けられた現行の日付および時刻を基準の日付および時刻と比較するステップと、
    基準の日付および時刻の現行の日付および時刻の間の差が所定のウィンドウ期間外である時に現行セッション・データが基準セッション・データと同一である場合、ユーザの要求をリプレイ攻撃として分類するステップと
    を含む請求項１１に記載の方法。
14. ポイント・ツー・ポイント・プロトコル（ＰＰＰ）、パスワード認証プロトコル（ＰＡＰ）、チャレンジ・ハンドシェーク認証プロトコル（ＣＨＡＰ）、遠隔認証ダイヤルイン・ユーザ・サービス（ＲＡＤＩＵＳ）プロトコル、ターミナル・アクセス・コントローラ・アクセス制御システム（ＴＡＣＡＣＳ）プロトコル、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）、ＮＴドメイン認証プロトコル、Ｕｎｉｘパスワード認証プロトコル、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュア・ソケット・レイヤを介したハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、拡張認証プロトコル（ＥＡＰ）、転送レイヤ・セキュリティ（ＴＬＳ）プロトコル、トークン・リング・プロトコルおよびセキュア遠隔パスワード・プロトコル（ＳＲＰ）のうちの１つのプロトコルを使用して、アクセス要求を受信するステップと、
    プロトコルのユーザ・ストリングから現在セッション・データを取り出すステップとを含む、請求項１０に記載の方法。
15. 楕円曲線暗号法と共に使用するのに適した公開／秘密鍵対の秘密鍵を使用してセッション・データを暗号解読するステップを含む請求項１０に記載の方法。
16. 現行セッション・データと基準セッション・データを比較するステップが、複数のサービス・プロバイダを含むサービス・アクセス・システムのネットワーク・アクセス・サーバ、トランザクション・サーバ、および認証サーバの少なくとも１つで実行される請求項１０に記載の方法。
17. コンピュータへのアクセスを要求しているユーザのデバイスを認証するシステムにおいて、
    ユーザがそれを介してコンピュータへのアクセスを要求するユーザのデバイスの接続アプリケーションで、ユーザの要求ごとに変わる現行セッション・データを生成するセッション・データ・ジェネレータと、
    平文で通信される暗号化されたアクセス要求を提供するために、現行セッション・データを暗号化し、これをユーザ認証データに含める暗号化モジュールと、
    暗号化されたアクセス要求を暗号解読するプロセッサと、
    基準セッション・データを暗号解読された現行セッション・データと比較するコンパレータであって、プロセッサが比較の結果に応じてユーザの要求を選択的に分類するコンパレータと
    を含むシステム。
18. ユーザの要求が有効なユーザの要求として分類された場合、現行セッション・データを基準セッション・データとして記憶するメモリを含む請求項１７に記載のシステム。
19. セッション・データ・ジェネレータがユーザ・セッションごとに変更される番号として現行セッション・データを生成する請求項１８に記載のシステム。
20. セッション・データ・ジェネレータがユーザの要求ごとに番号を増分し、番号が基準セッション・データよりも大きくない場合、ユーザの要求がリプレイ攻撃として分類される請求項１９に記載のシステム。
21. 現行セッション・データが基準セッション・データとして記憶されている場合、基準の日付および時刻が記憶され、コンパレータが、現行セッション・データに関連付けられた現行の日付および時刻を基準の日付および時刻と比較し、プロセッサが、基準の日付および時刻の現行の日付および時刻の間の差が所定のウィンドウ期間内である時に現行セッション・データが基準セッション・データと同一である場合、ユーザの要求を有効な要求として分類する請求項１８に記載のシステム。
22. コンピュータ・システムへのアクセスを要求しているアクセス・デバイスによるリプレイ攻撃を識別するコンピュータ・サーバにおいて、
    平文である暗号化されたアクセス要求をアクセス・デバイスから受信するレシーバーと、
    アクセス・デバイスによって生成された、アクセス要求内の現行セッション・データを暗号解読し、識別するプロセッサと、
    暗号解読された現行セッション・データを基準セッション・データと比較するコンパレータであって、プロセッサが比較の結果に応じてユーザの要求をリプレイ攻撃として選択的に分類するコンパレータと
    を含むコンピュータ・サーバ。
23. ユーザの要求が有効なユーザの要求として分類された場合、現行セッション・データを基準セッション・データとして記憶するメモリを含む請求項２２に記載のコンピュータ・サーバ。
24. セッション・データがユーザ・セッションごとに変更される番号であり、コンパレータが現行の番号を基準の番号と比較し、プロセッサが、現行の番号が基準の番号よりも小さい場合、ユーザの要求をリプレイ攻撃として分類する請求項２３に記載のコンピュータ・サーバ。
25. 現行セッション・データが基準セッション・データとして記憶されている場合、基準の日付および時刻がメモリに記憶され、コンパレータが現行セッション・データに関連付けられた現行の日付および時刻を基準の日付および時刻と比較し、プロセッサが、基準の日付および時刻の現行の日付および時刻の間の差が所定のウィンドウ期間外である時に現行セッション・データが基準セッション・データと同一である場合、ユーザの要求をリプレイ攻撃として分類する請求項２４に記載のコンピュータ・サーバ。
26. レシーバーが、ポイント・ツー・ポイント・プロトコル（ＰＰＰ）、パスワード認証プロトコル（ＰＡＰ）、チャレンジ・ハンドシェーク認証プロトコル（ＣＨＡＰ）、遠隔認証ダイヤルイン・ユーザ・サービス（ＲＡＤＩＵＳ）プロトコル、ターミナル・アクセス・コントローラ・アクセス制御システム（ＴＡＣＡＣＳ）プロトコル、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）、ＮＴドメイン認証プロトコル、Ｕｎｉｘパスワード認証プロトコル、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュア・ソケット・レイヤを介したハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、拡張認証プロトコル（ＥＡＰ）、転送レイヤ・セキュリティ（ＴＬＳ）プロトコル、トークン・リング・プロトコルおよびセキュア遠隔パスワード・プロトコル（ＳＲＰ）のうちの１つのプロトコルを使用してアクセス要求を受信するように構成されており、プロセッサが、プロトコルのユーザ・ストリングからセッション・データを抽出する請求項２２に記載のコンピュータ・サーバ。
27. 楕円曲線暗号法を使用してセッション・データを暗号解読するのに適した暗号解読構成要素を含む請求項２２に記載のコンピュータ・サーバ。
28. 複数のサービス・プロバイダを含むサービス・アクセス・システムのネットワーク・アクセス・サーバ、トランザクション・サーバ、および認証サーバの１つを定義する請求項２２に記載のコンピュータ・サーバ。
29. コンピュータ・システムへのアクセスを要求しているアクセス・デバイスによるリプレイ攻撃を識別するコンピュータ・サーバにおいて、
    アクセス要求をアクセス・デバイスから受信する手段と、
    アクセス・デバイスによって生成された、アクセス要求内の現行セッション・データを識別する手段と、
    現行セッション・データを基準データと比較し、比較の結果に応じてユーザの要求をリプレイ攻撃として選択的に分類する手段と
    を含むコンピュータ・サーバ。
30. コンピュータ・システムへのアクセスを要求しているアクセス・デバイスによるリプレイ攻撃を識別する一連の命令を組み込んだ機械可読媒体において、命令は、機械によって実行されると、機械に、
    暗号化されたアクセス要求を平文でアクセス・デバイスから受信させ、
    アクセス・デバイスによって生成された、アクセス要求内の現行セッション・データを暗号解読、識別させ、
    現行セッション・データを基準データと比較させ、
    比較の結果に応じてユーザの要求をリプレイ攻撃として選択的に分類させる
    機械可読媒体。
31. ユーザの要求が有効なユーザの要求として分類された場合、現行セッション・データを基準セッション・データとして記憶させる請求項３０に記載の機械可読媒体。
32. セッション・データがユーザ・セッションごとに変更される番号であり、命令が、現行の番号を基準の番号と比較させ、現行の番号が基準の番号よりも小さい場合、ユーザの要求をリプレイ攻撃として分類させる請求項３０に記載の機械可読媒体。
33. 命令が、
    現行セッション・データが基準セッション・データとして記憶されている場合、基準の日付および時刻を記憶させ、
    現行セッション・データに関連付けられた現行の日付および時刻を基準の日付および時刻と比較させ、
    基準の日付および時刻の現行の日付および時刻の間の差が所定のウィンドウ期間外である時に現行セッション・データが基準セッション・データと同一である場合、ユーザの要求をリプレイ攻撃として分類させる
    請求項３２に記載の機械可読媒体。
34. ポイント・ツー・ポイント・プロトコル（ＰＰＰ）、パスワード認証プロトコル（ＰＡＰ）、チャレンジ・ハンドシェーク認証プロトコル（ＣＨＡＰ）、遠隔認証ダイヤルイン・ユーザ・サービス（ＲＡＤＩＵＳ）プロトコル、ターミナル・アクセス・コントローラ・アクセス制御システム（ＴＡＣＡＣＳ）プロトコル、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）、ＮＴドメイン認証プロトコル、Ｕｎｉｘパスワード認証プロトコル、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュア・ソケット・レイヤを介したハイパーテキスト転送プロトコル（ＨＴＴＰＳ）、拡張認証プロトコル（ＥＡＰ）、転送レイヤ・セキュリティ（ＴＬＳ）プロトコル、トークン・リング・プロトコルおよびセキュア遠隔パスワード・プロトコル（ＳＲＰ）のうちの１つのプロトコルを使用してアクセス要求を受信させ、セッション・データをプロトコルのユーザ・ストリングから抽出させる請求項３２に記載の機械可読媒体。

Images