JP2010503320A - インターネットユーザに対して認証サービスを提供するための方法およびシステム - Google Patents

Abstract

公衆ネットワークを介して、クライアント、サーバおよびディレクトリサービスの間で伝達される情報を認証し、暗号化し、そして復号化するためのシステムおよび方法である。クライアントからアプリケーションによってセッションマスタ鍵を取得する方法は、セッションマスタ鍵のためのオープンリクエストをサーバに送信することと、セッションマスタ鍵の第２の部分を取得可能なディレクトリサーバを識別するセッションマスタ鍵の第１の部分と共に、サーバから第１の応答をアプリケーションによって受信することとを含む。アプリケーションは、セッションマスタ鍵の第２の部分のために、第１の応答でサーバによって指定されたディレクトリサーバにオープンリクエストを送信し、ディレクトリサーバからそれを受信する。セッションマスタ鍵は、セッションマスタ鍵の第１の部分および第２の部分を用いて、アプリケーションによって生成される。

Description

（関連出願）
本出願は、同一発明者によって２００６年９月６日に出願された、米国仮出願第６０／８４２，５９５号の利益を主張するものである。

（発明の分野）
本発明は、概して、インターネットトラフィックをウェブサイトに発生させて、ウェブサイトのための広告収入を提供するためのシステムおよび方法に関し、特に、ブラウザとサーバとの両方に対してサービスを提供するウェブサイトに、インターネットトラフィックを発生させるためのシステムおよび方法に関する。

（発明の背景）
インターネットウェブサイトの１つの収益モデルとして、ウェブサイトにトラフィックを発生させ、次にウェブサイト上での広告について広告主に料金を課すということがある。このモデルの真の秘訣は、広告主がウェブサイトに広告を出すことが魅力的に思える、十分なトラフィックを発生させるということである。加えて、ウェブサイトが発生させるトラフィックが多くなるほど、ウェブサイト運営者が広告主に課すことのできる料金は高くなる。

公衆ネットワークのセキュリティは大きく進歩したが、全く軽視されている一局面がある。それは、公開精査（ｐｕｂｌｉｃ ｓｃｒｕｔｉｎｙ）である。公衆ネットワークにおいては、公開アーキテクチャ内に非公開のセキュアなチャネルの作成手順が、明確に定義されている。この手順には、信頼できるサードパーティによって、一意の二者間に仲介される信頼の提供（ｐｒｏｖｉｓｉｏｎ ｏｆ ｔｒｕｓｔ）が含まれる。この信頼の提供のための技術および方法は、交換された情報の数学的定式（ｍａｔｈｅｍａｔｉｃ ｆｏｒｍｕｌａｔｉｏｎ）に完全に依存する。こうした方法は、現在、干渉が困難であると考えられている一方で、情報の提供を公的にチェックできる、というコンセプトが完全に欠けている。

電子的な「警察官」の「バッジ番号をチェック」して、それを示してくれる簡単かつ公的な方法は存在しない。また、電子的な交換情報を提供する信頼できるサードパーティを精査するか、または彼らがプロバイダになった時の条件を精査する方法は存在しない。基本的に、接続のセキュリティおよびプライバシーが作成時と同様であることを確認する、数学的な情報表現（ｍａｔｈｅｍａｔｉｃ ｉｎｆｏｒｍａｔｉｏｎ ｐｒｅｓｅｎｔａｔｉｏｎ）を検証および承認するためにリアルタイムで使用可能な、公的に実証可能な方法または技術が存在していない。

従って、本発明は、ウェブサイトに十分なトラフィックを発生させ、インターネットで利用可能な認証の実施を改善するための方法および装置を開発する問題に向けられる。

（発明の概要）
本発明は、新規の信頼モデル内の新規の数学的な交換技術および信頼できる仲介者（ｉｎｔｅｒｍｅｄｉａｒｙ）がサーバおよびブラウザの間で暗号鍵のセキュアな認証および伝達ができるようにするための方法を提供することにより、これらの問題およびその他の問題を解決する。

一局面によると、本発明は、数的な認証および暗号鍵のセキュアな交換ならびに任意の添付されたメッセージコンテンツの認証された暗号化のためのシステムおよび方法に関する。本方法の例示的な実施形態は、ネットワークのソケットレイヤに応用されており、セキュアソケットレイヤ（ＳＳＬ）およびトランスポートレイヤセキュリティ（ＴＬＳ）技術と一般に呼ばれるものの改良である。本発明者は、この新たな本発明の方法を、拡張セキュアソケットレイヤ（ＳＳＬＸ）と称し、この方法は、シングルパスハンドシェイクの配信や、伝送毎のセッション鍵の生成および使用よりも数百倍も高速である。

パフォーマンスの向上により、信頼できるサードパーティは、ネットワーク関係者への初期の認証情報の提供者としてだけでなく、セッション毎の関係者の間の新しい認証および暗号鍵情報のリアルタイムの提供者としても機能することが可能になっている。これにより、サードパーティ信頼の提供は、静的で長年変わっていない初期の認証情報およびその数学的表現に依存することから、現在ＳＳＬ／ＴＬＳによって提供されているように、関係者が接続の間に任意の時点で信頼のあるトークンをリアルタイムに承認し得るように、完全に再編成されている。公開精査は、グローバルな社会の要であり、電子的世界におけるその欠如は、新たな可能性の開拓への閉塞的な障害となっている。

本発明の一局面によると、コンピュータ上で実行しているアプリケーションによって、サーバからネットワークを介してセッションマスタ鍵を取得するための方法の例示的な実施形態は、セッションマスタ鍵のために、アプリケーションによってサーバにオープンリクエストを送信することと、セッションマスタ鍵の第１の部分と共に、サーバから第１の応答をアプリケーションによって受信することとを含む。第１の応答は、セッションマスタ鍵の第２の部分を取得可能なディレクトリサーバを識別する。アプリケーションは、セッションマスタ鍵の第２の部分のために、第１の応答でサーバによって指定されたディレクトリサーバにオープンリクエストを送信し、ディレクトリサーバからセッションマスタ鍵の第２の部分を受信する。アプリケーションからサーバへのオープンリクエストは、公開鍵を含み得、この場合には、サーバからアプリケーションへの第１の応答は、公開鍵によって暗号化されたセッションマスタ鍵の第１の部分を含む。アプリケーションからディレクトリサーバへのオープンリクエストはまた、公開鍵を含み得、この場合には、ディレクトリサーバから受信したセッションマスタ鍵の第２の部分は、公開鍵によって暗号化される。アプリケーションからディレクトリサーバへのオープンリクエストは、（ｉ）ディレクトリサーバからアプリケーションによって取得された、アプリケーションのディレクトリサーバ鍵を用いて、ＳＳＬＸ−ＥＡ交換においてセッションマスタ鍵の第２の部分をラップすることか、または（ｉｉ）アプリケーションによってオープンリクエストでディレクトリサーバに提供される公開鍵を用いて、セッションマスタ鍵の第２の部分を暗号化することのいずれかを行う指示を含み得る。アプリケーションは、サーバから受信したセッションマスタ鍵の第１の部分と、ディレクトリサーバから受信したセッションマスタ鍵の第２の部分とを用いて、セッションマスタ鍵を生成する。サーバは、サーバによってディレクトリサーバから取得されたサーバのディレクトリサーバ鍵を用いて、ＳＳＬＸ−ＥＡ交換においてラップされたセッションマスタ鍵の第２の部分と共に、第２の応答をディレクトリサーバに送信する。セッションマスタ鍵を用いて、ＳＳＬＸ−ＥＡ交換においてラップされたメッセージは、アプリケーションからサーバに送信され、サーバからアプリケーションへのメッセージもまた、セッションマスタ鍵を用いて、ＳＳＬＸ−ＥＡ交換においてラップされる。サーバのディレクトリサーバ鍵は、ディレクトリサーバとの検証されたセットアップ動作の間にサーバによって取得することができる。同様に、アプリケーションのディレクトリサーバ鍵は、ディレクトリサーバとの検証されたセットアップ動作の間にアプリケーションによって取得され得る。アプリケーションからサーバへのオープンリクエストは、アプリケーションが検証プロセスを実行した１つ以上のディレクトリサーバのリストを含み得る。同様に、サーバからアプリケーションへの第１の応答もまた、サーバが検証プロセスを実行した１つ以上のディレクトリサーバのリストを含み得る。

本発明の別の局面によると、ネットワークを介してサーバからコンピュータ上で実行しているアプリケーションにセッションマスタ鍵を伝送するための方法の例示的な実施形態は、セッションマスタ鍵のために、サーバによってアプリケーションからオープンリクエストを受信することと、セッションマスタ鍵の第１の部分と共に、第１の応答をアプリケーションに送信することと、サーバによってディレクトリサーバから取得されたサーバのディレクトリサーバ鍵を用いて、ＳＳＬＸ−ＥＡ交換においてラップされたセッションマスタ鍵の第２の部分と共に、第２の応答をディレクトリサーバに送信することとを含む。アプリケーションは、セッションマスタ鍵の第２の部分のために、第１の応答でサーバによって指定されたディレクトリサーバにオープンリクエストを送信する。ディレクトリサーバは、セッションマスタ鍵の第２の部分をアプリケーションに送信する。サーバから受信した第１の部分と、ディレクトリサーバから受信した第２の部分とを用いて、セッションマスタ鍵がアプリケーションによって生成される。アプリケーションからサーバへのオープンリクエストは、アプリケーションが検証プロセスを実行した１つ以上のディレクトリサーバのリストを含み得る。サーバからアプリケーションへの第１の応答もまた、サーバが検証プロセスを実行した１つ以上のディレクトリサーバのリストを含み得る。アプリケーションからサーバによって受信されたオープンリクエストは、公開鍵を含み得、その場合には、サーバからアプリケーションに送信された第１の応答は、公開鍵によって暗号化されるセッションマスタ鍵の第１の部分を含む。アプリケーションによってディレクトリサーバに送信されるオープンリクエストは、公開鍵を含み得、その場合には、ディレクトリサーバからアプリケーションに送信されるセッションマスタ鍵の第２の部分は、公開鍵によって暗号化される。アプリケーションによってディレクトリサーバに送信されるオープンリクエストは、（ｉ）ディレクトリサーバからアプリケーションによって取得されたアプリケーションのディレクトリサーバ鍵を用いて、ＳＳＬＸ−ＥＡ交換におけるセッションマスタ鍵の第２の部分をラップすることか、または（ｉｉ）アプリケーションによってオープンリクエストでディレクトリサーバに提供される公開鍵を用いて、セッションマスタ鍵の第２の部分を暗号化することのいずれかを行う指示を含み得る。サーバからアプリケーションへのメッセージは、セッションマスタ鍵を用いて、ＳＳＬＸ−ＥＡ交換においてラップされて送信され、アプリケーションから受信されるメッセージは、セッションマスタ鍵を用いて、ＳＳＬＸ−ＥＡ交換でラップされる。サーバのディレクトリサーバ鍵は、ディレクトリサーバとの検証されたセットアップ動作の間に、サーバによって取得される。アプリケーションのディレクトリサーバ鍵は、ディレクトリサーバとの検証されたセットアップ動作の間に、アプリケーションによって取得される。

本発明のさらに別の局面によると、ネットワーク上のコンピュータを検証する方法の例示的な実施形態は、ディレクトリサービス鍵のために、コンピュータからのリクエストが、認証リクエストの値を含むオープンリクエストをディレクトリサービスによって受信することと、認証リクエスト値が公開鍵オプションを指示する場合には、コンピュータによって送信されるオープンリクエストに含まれる公開鍵を用いて暗号化されるディレクトリサービス鍵と共に、単一の応答をディレクトリサービスによって送信することと、認証リクエスト値が帯域外（ｏｕｔ−ｏｆ−ｂａｎｄ）通信経路オプションを指示する場合には、コンピュータからリクエストで指定された帯域外通信経路を介して、ディレクトリサービス鍵を含む単一のメッセージをディレクトリサービスによって送信することと、認証リクエスト値が、公開鍵と帯域外通信経路オプションとの両方の組み合わせを指示する場合には、ディレクトリサービス鍵の第１の部分と共に、第１の応答をディレクトリサービスによってコンピュータに送り返し、ディレクトリサービス鍵の第２の部分と共に、第２の応答をコンピュータからリクエストで指定された帯域外通信経路を介して送信することとを含む。単一のメッセージは、コンピュータからディレクトリサービスへのリクエストに含まれた公開鍵を用いて暗号化されるディレクトリサービス鍵を含む。第２の応答は、コンピュータからディレクトリサービスへのリクエストに含まれた公開鍵を用いて暗号化されるディレクトリサービス鍵を含む。ディレクトリサーバによって、コンピュータから確認メッセージが受信され、ディレクトリサービス鍵を用いて、ＳＳＬＸ−ＥＡ交換において確認メッセージがラップされる。

本発明のさらに別の局面によると、セキュアな通信で利用するために信頼できるサードパーティから信頼できる鍵を取得するための方法の例示的な実施形態は、リクエストが認証リクエスト値を含み、該認証リクエスト値が、信頼できる鍵のために配信オプションを指示するオープンリクエストを、信頼できる鍵のために信頼できるサードパーティに送信することと、認証リクエスト値の指示に基づき、１つ以上の通信経路を介して信頼できるサードパーティから信頼できる鍵を受信することと、信頼できる鍵を用いて、ＳＳＬＸ−ＥＡ交換においてラップされた確認メッセージを信頼できるサードパーティに送信することとを含む。このプロセスの最初において、公開および非公開の鍵の対が作成される。オープンリクエストに公開鍵を含め得、この場合には、該１つ以上の通信経路上で信頼できる鍵を送信する際に、信頼できる鍵を暗号化するために公開鍵が用いられる。認証リクエスト値が公開鍵オプションを指示する場合には、信頼できるサードパーティは、オープンリクエストにおいて信頼できるサードパーティに送信された公開鍵を用いてラップされた信頼できる鍵と共に、単一の応答を送信する。認証リクエスト値が帯域外通信経路オプションを指示する場合には、信頼できるサードパーティは、認証リクエスト値に指定されたアドレスに対して、帯域外通信経路を介して送信された信頼できる鍵と共に、単一の応答を送信する。認証リクエスト値が公開鍵と帯域外通信経路との両方の組み合わせを指示する場合には、信頼できるサードパーティは、公開鍵を用いて暗号化された信頼できる鍵の第１の部分と共に第１の応答を送信し、そして信頼できる鍵の第２の部分と共に第２の応答を、認証リクエストに指定された帯域外通信経路およびアドレスを介して送信する。信頼できるサードパーティは確認メッセージを復号化する。確認メッセージが正しく復号化されない場合には、信頼できるサードパーティは、公開鍵によって暗号化された拒否メッセージを送信し、この拒否メッセージはコンピュータによって復号化され、信頼できるサードパーティが検証されたセットアップリストから削除される。信頼できる鍵を受信した後、コンピュータは、１つ以上の関連付けられた信頼できる鍵と共に、コンピュータが信頼できる鍵を受信した全ての信頼できるサードパーティのリストを維持し、認証プロセスの間に別のコンピュータと情報交換する際に、該別のコンピュータへのメッセージにこのリストを含める。

本発明のさらに別の局面によると、ネットワーク上でセキュアに通信するコンピュータ間において信頼できる仲介者の役割をするための装置の例示的な実施形態は、サーバと、任意の特定のディレクトリメンバーとセキュアに通信するための関連する情報を格納するために、サーバに連結されたデータベースとを含む。この関連する情報は、各特定のディレクトリメンバーに関連付けられたディレクトリサービス鍵を含む。また、公知の静的ＩＰアドレスがサーバに関連付けられる。サーバ上でアプリケーションが実行される。サーバは、ブラウザからウェブサーバにリアルタイムリクエストを経路指定し、ウェブサーバからブラウザに応答を経路指定する。リクエストおよび応答は、リクエスト実行者がサーバとの検証されたセットアップを実行した場合には、リクエスト実行者が生成した公開鍵またはＳＳＬＸ−ＥＡ交換の信頼できる鍵によって保障される。応答のそれぞれは、リクエスト実行者が組み合わせ、該応答のそれぞれとウェブ接続された場所とが同一であることを検証するための情報の一部分だけを含む。情報の残りの部分は、情報の残りの部分を暗号化するために、リクエスト実行者が生成した公開鍵を用いて、ウェブサイトからリクエスト実行者に直接提供される。

本発明のこれらおよびその他の特徴および利点は、添付の図面に示されるように、以下のその例示的な実施形態の記載から、より明らかとなる。

図１は、本発明の一局面に従った、ＳＳＬＸコンポーネントを有するコンピュータネットワークの図である。 図２は、本発明の別の局面に従った、ディレクトリサービス（ＤＳ）からの、サードパート信頼を仲介された後の通常のＳＳＬＸの信頼できる通信の図である。 図３は、本発明のさらに別の局面に従った、ＳＳＬＸ認証ハンドシェイクの図である。 図４は、本発明のさらに別の局面に従った、検証されたセットアップ（ＶＳＵ）の図である。 図５は、ＳＳＬセッションフローである。 図６は、本発明のさらに別の局面に従った、ＳＳＬＸセッションフローである。 図７は、新しいセッションのためのＳＳＬハンドシェイクフローである。 図８は、本発明の別の局面に従った、新しいセッションのためのＳＳＬＸハンドシェイクフローである。 図９は、再開されたセッションのためのＳＳＬハンドシェイクフローである。 図１０は、本発明のさらに別の局面に従った、新しいセッションのためのＳＳＬＸハンドシェイクフローである。

（詳細な説明）
本発明は、異なるコンピュータで実行されるアプリケーションプログラムの間で非公開の通信を確実にするための、コンピュータで読み取り可能および利用可能な媒体で具現化される、新規のプロセスおよび関連するコンピュータプログラムを含む。特定のアプリケーションは、実施例としてのみ説明される。本発明は、示されている実施形態および実施例のみに制限されることを意図したものではなく、本明細書で開示されている原理および特徴と矛盾しないもっとも広い範囲が認められるべきである。

本発明について記載する前に、共有鍵を使用した単純な復号化は、それだけで、認証を実行するのではないということに留意されたい。これは、（鍵スペースにおける強硬な手段を含む任意の手段によって）共有された鍵が見つかった場合に、鍵の知識により、その時点から各メッセージを復号化することができると共に、不正なメッセージを暗号化することによって鍵の所有者になりすますことができるという事実によるものである。ＳＳＬは任意のセッションの開始時における１回の認証しか行わないために、この復号化は単純であり脆弱である。

本発明は、暗号化プロセスにおいてＳＳＬＸ−ＥＡと呼ばれる埋め込み認証を提供し、帯域外で提供される認証された共有鍵を用いて開始される。こうして、単純な復号化に鍵を使用する（その脆弱性を有する）代わりに、ＳＳＬＸ−ＥＡは、共有鍵を復号化のために直接使用するのではなく、一方向のプロセスを通じて、各メッセージで一意のメッセージ鍵を生成するために使用するので、適切に復号化を行うための能力を確率的な認証として使用する。万一、敵がメッセージ鍵の１つを発見し、単一のメッセージを適切に復号化したとしても、これによって、その次のメッセージを復号化したり、送信者になりすまして適切なＳＳＬＸ−ＥＡ出力を生成したりすることができるわけではない。ＳＳＬＸ−ＥＡは、乱数（Ｒ）およびメッセージ鍵（Ｗ）を知っているからといって、用いられているアルファベット（Ａ）または元の共有された鍵（Ｋ１）が分かるようになっていないために、元の共有鍵（Ｋ１）の不可侵性を認証の印として保持するのである。さらに、任意のメッセージ鍵（Ｗ）を知っているからといって、次のまたは任意の未来のメッセージ鍵（Ｗ）が分かるわけではない。ＳＳＬＸ−ＥＡは、各通信に高速の認証メカニズムを追加することによって、ＳＳＬに存在する単純な復号化の脆弱性を補っている。

本明細書中で用いられるように、アプリケーションは、任意のソフトウェアプログラムまたはオペレーションシステムとすることができる。それに加えて、ウェブサーバまたはサーバは、ネットワーク上の別のデバイスまたはアプリケーションと通信することができる、ネットワークに接続される任意のデバイスとすることができる。

埋め込み認証およびデータ暗号のプロセスとしてのＳＳＬＸは、通信ネットワークの任意のレベルに配置してもよい。これはウェブブラウザおよびウェブサーバに配置されるアプリケーションレイヤで動作し、ＯＳ、ルータまたは任意のネットワークスイッチデバイスに配置した場合には、セッション、トランスポートおよびネットワークレイヤにある間、常に同様に動作できる。

高速、低消費電力および小さいコードサイズの特徴により、ＳＳＬＸは、任意のセンサまたはその他のリモートネットワーク通信プラットフォームと同様に、ワイヤレスアーキテクチャ（音声およびデータ）で動作することができる。ＳＳＬＸは、通信アーキテクチャから独立したプロトコルであり、ネットワーク関係者がセキュアな、非公開のメッセージングを必要とする任意の場所で動作することができる。

（Ａ．ワールドワイドウェブブラウザ−サーバモデル）
ＳＳＬＸは、ワールドワイドウェブのアーキテクチャで、認証されたセキュアな通信を提供するために利用可能である。配置後、ＳＳＬＸは、ウェブサーバおよびソフトウェアウェブブラウザアプリケーション内のソフトウェアコンポーネントとして動作してもよい。別のソフトウェアアプリケーションがサードパーティに常駐しており、これにより、信頼を仲介し、ブラウザおよびサーバの間のセキュアなチャネルを提供する、評判の高い、独立した公開パーティが構成される。このサードパーティは、ディレクトリサービス（ＤＳ）と呼ばれる。

後で示すように、ディレクトリサービスは、２つの異なる方法で動作可能である。公衆が利用可能なオープンエンティティ、または非公開のサーバとウェブブラウザの非公開のコミュニティとの間の信頼を仲介するために動作する非公開のエンティティとして動作可能である。非公開のサーバとウェブブラウザの非公開の通信との間の信頼を仲介するよう動作する非公開のエンティティは、非公開のディレクトリサービスと呼ばれる。ＳＳＬＸのウェブの実施例の最後のものは、ＳＳＰＸ公開アドミニストレータ（ＰＡ）であり、これは公開ディレクトリサービスを管理する責任を有する別の公的機関であり、ＰＡは、３つのその他のパーティの間の電子的なメカニズムを仲介するいずれの部分も提供することはない。

全てのパーティは図１で示されるように、信頼の輪１０を提供するように協力して動作する。ウェブブラウザ１１、サーバ１２、公開ディレクトリサービス１３、ＳＳＬＸ公開アドミニストレータ１４および非公開のディレクトリサービス１５は全て、以下により詳細に記載されるように、信頼の輪１０を実装および動作させるように協力して動作する。

（通常のＳＳＬＸ動作（信頼できる））
ブラウザおよびサーバの両方がＳＳＬＸ−ＥＡ（埋め込み認証）セッションマスタ鍵（ＳＭＫ）を共有する場合に、ＳＳＬＸの通常の通信フローが用いられる。以下にＳＳＬＸ−ＥＡについて説明する。ブラウザは、２つの方法のうちの１つによってＳＭＫを取得し、その２つの方法とは、
１．ＳＳＬＸ認証ハンドシェイクの実行、または
２．サーバ所有者にエンドユーザ認証を課し、ブラウザ所有者が鍵をブラウザアプリケーションに入力する一方で、サーバはこの特定のブラウザに関連付けられた鍵を作成および保存する、帯域外プロセスの実行
である。

（通常の動作）
図２を参照すると、ウェブブラウザ２１が各ＧＥＴおよびＰＯＳＴ要求を、ＳＳＬＸ−ＥＡ交換（Ｔ−ＢＲｌ）２３でラップされたウェブサーバ２２に送信すると、通常の動作２０が実行される。本明細書で用いられているように、「ＳＳＬＸ−ＥＡ交換でのラップ」は、リクエストを暗号化するためにメッセージ鍵を使用することを意味し、メッセージ鍵は、サーバへの暗号化されたリクエストと共に含まれる乱数と組み合わされたセッションマスタ鍵（ＳＭＫ）から生成される。このＳＳＬＸ−ＥＡ技術の細かい詳細を以下に記載する。このプロセスは、さらに、ワンパス鍵生成確率認証（ｏｎｅ ｐａｓｓ ｋｅｙ ｇｅｎｅｒａｔｉｏｎ ｐｒｏｂａｂｉｌｉｓｔｉｃ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）プロセスであるとも呼ばれる。要するに、ブラウザ２１は、これの暗号化と共に、あらゆるＧＥＴおよびＰＯＳＴリクエストを認証する。ウェブサーバ２２は、ＳＳＬＸ−ＥＡ交換（Ｔ−ＷＳ２）２４でラップされるコンテンツを有する同じ公知のＳＭＫを用いて応答する。ブラウザと同様に、サーバは、伝送されるコンテンツの暗号化と共に、ブラウザへのあらゆる応答を認証する。ウェブブラウザ２１は、次に、応答コンテンツをアンラップし、これをユーザ（Ｔ−ＢＲ３）２５に表示する。

あらゆる交換は、一意に暗号化および配信することができるか、または各ラウンドトリップ（リクエストおよび応答を含む）を一意に暗号化することができる。ＳＳＬＸ−ＥＡセッション長を定義するサーバ上の設定が提供される。ウェブアーキテクチャにおけるＳＳＬＸセッション長のための設定の例示的な実施形態は、そのページ上の全てのオブジェクトのリクエストおよび応答を含むために、各ページが一意のＳＭＫ交換およびメッセージ鍵を有するように１つのＨＴＭＬページを含む。

各セッションにおいて、ＳＳＬＸ通信トラフィックは非常に単純である。ウェブブラウザ２１は、（セッションが開始する場合）ＳＳＬＸ−ＥＡ鍵交換および暗号文または（セッション内の場合）暗号文のみにおける各リクエストをラップし、これを信頼できるウェブサーバ２２に送信する。サーバ２２は、ＳＳＬＸ−ＥＡ鍵交換をアンラップしてリクエストを復号化するか、リクエストを単に復号化して、コンテンツを取得するためにリクエストを処理し、次に、セッション鍵を用いてＳＳＬＸ−ＥＡ鍵交換（セッション長が各通信で設定されている場合）または暗号文の応答をラップし、これをブラウザ２１に戻す。ブラウザ２１は、次に、コンテンツをアンラップし、ＳＳＬＸ−ＥＡ鍵交換の復号化または暗号の復号化のみを実行し、これを処理する。ＳＳＬＸは、暗号文を暗号化および復号化するために、任意の標準的な電子的暗号を利用する。

（ＳＳＬＸ認証ハンドシェイク（ＡＨ））
ＳＳＬＸ認証ハンドシェイクのプロセスは、サーバのみが、開始するべきＳＳＬＸ−ＥＡ鍵を有している場合に用いられる。ＳＳＬＸ認証ハンドシェイクは、取り扱いに注意の必要な／非公開／セキュアな情報が交換され、かつ、サーファ（ｓｕｒｆｅｒ）に対し、接続するウェブサイトは、実際に、情報の意図された受信者であることの証拠が示される場合の、匿名のウェブサーファ接続開始時におけるウェブサイトページへの動作である。これは、ブラウザおよびサーバの間のセキュアな通信の初期設定（ｉｎｉｔｉａｌｉｚａｔｉｏｎ）である。

認証ハンドシェイクは、サーバが、所望のサーバであるかどうかのチェックを含む。これを実行するための論理的な方法は、２つのみ存在し、
１．以前の知識、または
２．サードパーティ、好適には、信頼できるサードパーティに問い合わせること
の２つである。

第１の方法は、以前の関係を示唆するものである。すなわち、これは、両者が以前の遭遇（帯域外の鍵の確立）を通して証拠を提供する、信頼できる動作モードである。

ディレクトリサービス／サーバ（ＤＳ）と呼ばれるものによって、「サードパーティに尋ねること」のサードパーティのＳＳＬＸ実装が行われる。ＳＳＬＸ ＤＳは、任意の特定のディレクトリメンバーと（セキュアに）通信するために関連情報を保持する、公開された、公知のエンティティとして機能する。ウェブインフラストラクチャ内のＳＳＬＸ ＤＳは、リアルタイムのリクエストおよび応答をルート指定するために単純なＳＳＬＸアプリケーションおよびデータベースを動作させる、公知の静的ＩＰアドレスを有する。リクエストは、ブラウザが検証されたセットアップ（ＶＳＵ）を実行した場合には、リクエスト実行者が生成した公開鍵、あるいは、ＤＳ ＳＳＬＸ−ＥＡ鍵で保護されている。応答は同様に保護されており、リクエスト実行者が、結合し、応答およびウェブ接続された位置が１つであり、同じであることを検証するために、必要な情報の半分となっている。情報の別の半分は、リクエスト実行者が生成した公開鍵においてウェブサイトからリクエスト実行者へ直接提供される。

オープン公開（ｏｐｅｎ ｐｕｂｌｉｃ）ＤＳ（における信頼）の保証は、以下の、
・ ＤＳ位置の帯域外検証を行うことができることと、
・ リアルタイムのなりすまし／ブラウザへ、またはブラウザからのサイト位置およびＤＳ位置の両方の操作を行うことは困難であり、検証されたサーバセットアッププロセスを最初に「壊す」ことが必要（成し遂げるためには、内部の信頼できる人間の悪意が必要）であることと、
・ ＤＳに提供される情報は、事前登録したＳＳＬＸサーバだけから提供され得る。ＤＳによって提供された情報は、事前登録された脆弱でない（ＳＳＬＸ−ＥＡ）または登録されていない脆弱性が最小限の方法（公開鍵）で、セキュアに配信できることと、
・ 通信情報全体を同化することのできる唯一の場所は、リクエスト実行者である。ＤＳは、リクエスト実行者、またはサイトのリクエストについての情報は保存しないことと、
・ 特定のサイトコンテンツをチェックすることによって、さらなる信頼のアクティビティが実行可能となるまでセッション情報が交換されないように、任意のセキュリティ要件をともなわずに、あるページ位置でＤＳ接続性を実行することができることと
に基づいている。

これらの全てによって、サーバ／ウェブサイトに関与する任意のＳＳＬＸを認証するために、匿名のウェブサーファのための堅牢でセキュアな手段を形成する。

ディレクトリサービス／サーバ（ＤＳ）は、ＳＳＬ／ＴＬＳの認証機関（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ；ＣＡ）よりも、よりスケーラブルで排他性の低い、異なる方法で実装されるサードパーティ信頼の重要なコンポーネントである。これらはさらに、登録およびレポジトリの「機関」とは反対に、ただ信頼できるスイッチであるにすぎない、より基本的で形式性の低い機能を形成する。ＤＳネットワークとは、セキュリティオフィスの保存に類似したＣＡの階層的なオーソリティネットワークではなく、その特定の建物およびメンバーについて誰もが知っている一連の情報デスクのようなものである。ＩＤ交換における電子商取引の信頼は、ウェブサイトに表示されているように、特定の建物の三階のリアルストアから物を買うということの検証にすぎないため、セキュリティオフィサーを探しにいくよりも、インフォメーションデスクで相談にのってくれる係員に尋ねるほうがずっと容易であり、また有効である。

ＳＳＬＸのＤＳネットワークには、ＤＳオペレータの相互接続性は必要ではない。ＤＳが信頼できる方法で動作していることを確かめるために、外部の信頼できるＳＳＬＸ公開アドミニストレータ（ＰＡ）が存在する。ＰＡとは、
・ ワールドワイド公開ディレクトリサービスのガバナンスを提供する、評判の高い、独立したサードパーティであり、
・ ＤＳのための動作ライセンスを割り当て、ＤＳの公開保証（ｐｕｂｌｉｃ ａｓｓｕｒａｎｃｅ）が検証可能であるように、コントロールを維持し、
・ ＤＳのために標準のクオリティコントロールおよび準拠基準を提供し、そして
・ ユーザのためにＤＳの検証を行う、ＤＳ検索の機関
である。

ＤＳの目的は、ウェブサーバを検証することである。認証ハンドシェイクにおけるその存在の直接の結果は、ＤＳのネットワークが切り替えられ、次に、エンドユーザに対して複数のセキュリティレベルが可能になるということである。公知および未知のＤＳとの異なる通信手段を取り扱うために、ＡＨのリストアップされたオプションが含められる。これにより、ＳＳＬＸは、異なるセキュリティレベルを提供することができる。ＡＨオプションによって提供される最も低いレベルのセキュリティに関連付けられるリスクでさえも、明確に定義および制限されている。最も高いレベルのリスクは存在しないに等しく、脆弱性のみのバックアップとして帯域外オプションがある。

レベルは、エンドユーザのブラウザの観点から、３つの異なる利用モデルに基づく。サーバは、常に、少なくとも１つのディレクトリサービスの検証されたセットアップに関連することになるため、常時、最も高いレベルで実行可能である。より多くのおよび複数のＤＳによるセットアップにおけるアクティブなサーバ管理によって、サーバは、エンドユーザによってサーバがＤＳを通して応答する方法が選択できるので、ブラウザとより完全に関与し、ブラウザのセキュリティ期待度（設定）を下げないようにすることが可能になる。

全てのサーバは、少なくとも１つの検証されたセットアップを実行しなければならないため、最低でも１つの公開ＤＳが存在する必要がある。いずれかのアーキテクチャに１つしかない場合には、ＤＳは、共通ディレクトリサービス（ＣＤＳ）と呼ばれる。

ＳＳＬＸセキュリティレベルとは、
１．高−共通する少なくとも１つにより、種々のディレクトリサービスのために、サーバとブラウザの両方が一度のみの検証されたセットアップを実行する。そして、
２．中−中程度のセキュリティには、２つの考えられる状況があり、
ａ．サーバが検証されていない特定のＤＳを利用するようにブラウザが依頼されたため、サーバのＤＳは、ブラウザ公開鍵通信と共に用いられるか、または、
ｂ．ブラウザは任意のＤＳで検証されていないが、このレベルに設定されているため、公開鍵を用いて任意の特定のＤＳと通信する。そして、
低−ブラウザおよびサーバは、公開鍵（マンインザミドル（ＭＩＴＭ）攻撃に対して弱い）を用いて、任意のＤＳ仲介なしで直接通信する。（このレベルのセキュリティは通常のハウスロックのセキュリティと似ており、不法侵入は稀であるが起きることもある）
である。

非公開のＤＳは、検証されたセットアップ（ＶＳＵ）を実行するようエンドユーザが勧められている場合に確立可能であり、これらは、ＰＡのリストを持たない。これらのために、ウェブコンテンツ所有者は、いずれ分散する情報のみが、任意の通信のために高セキュリティレベルを使用することを提供しており、この場合には、サーバは、非公開のＤＳと共にＶＳＵを実行していない任意のブラウザへ応答しないよう設定される。

（動作）
図３を参照し、次に、認証ハンドシェイク３０について説明する。認証ハンドシェイク（ＡＨ）３０は、ウェブブラウザ３１が最初に公開および非公開鍵ペアを作成し、信頼できるＳＳＬＸ−ＥＡセッションマスタ鍵（ＳＭＫ）が公開鍵（Ａ−ＢＲ１）３３でラップされるよう、ウェブサーバ３２にオープンリクエストを送信する場合に実行される。リクエスト３３は、以下のうちのいずれか、およびどのエレメントを実行するかを決定する認証リクエスト値を有する。ウェブサーバ３２は、このブラウザのＳＭＫを生成した後で２回の応答を行う。１回は、ブラウザの送信された公開鍵（Ａ−ＷＳ２）３４を用いてラップされるＳＭＫの前半と共に、ブラウザに対して直接、返され、もう１回は、ウェブサーバのＤＳ鍵（検証されたセットアップ時に受信）（Ａ−ＷＳ３）３５を用いてラップされるＳＭＫの後半と共に、ＤＳ３９へ返される。ブラウザ３１は、次に、ブラウザのＤＳ鍵（検証されたセットアップ中に受信された場合）でラップされるＳＭＫのもう半分のためにウェブサーバ３２によって指定されたディレクトリサービス（サーバ）（ＤＳ）３９へオープンリクエストを、または公開鍵（ブラウザがこのＤＳで検証されていない場合には、またはブラウザがＤＳで検証されておらず、これがデフォルトでサーバのＤＳである場合）（Ａ−ＢＲ４）３６を送信する。ＤＳ３９は、ブラウザのＤＳまたは公開鍵（Ａ−ＤＳ５）３７を使って、ブラウザ３１へＳＭＫの後半を再びリレーする。ブラウザ３１は、通常の動作（信頼できる）（Ａ−ＢＲ６）３８を用いて、ウェブサーバ３２によって、セキュアな通信を開始するようにＳＭＫを復号化する。

プロセスを高速化し（つまり、サーバとブラウザの間の通常の通信時において、ＤＳ３９では暗号化または復号化は行われないが、当然ながら、ＳＭＫの一部分の交換時において暗号化／復号化が実行される）、ＤＳ３９は、実際のＳＭＫのそのリレーされた半分を「認識」していないことをサーバ所有者およびブラウザ所有者に保証する、という両方のために、ＤＳ３９を通じたＳＭＫのスイッチベースのリレーが行われる。交換を保存し復号化を実行することは可能であるが、これが行われたとしても、それは鍵の半分にすぎず、無価値である。交換を保存しないことを示すためには、任意の動作ＤＳ３９が必要となる。

ＡＨ３０においてセキュリティレベルオプションが選択される方法は、次の通りである。初期のブラウザリクエストにおいて、セキュリティ設定によって、ブラウザがＶＳＵを実行したＤＳのリストは、応答のために公開鍵と共にサーバに送信される。設定が高の場合には、ブラウザは、ＶＳＵ ＤＳのそのリストを送信し、設定が中の場合には、（存在する場合）リストまたは空白リストを送信する。設定が低の場合には、ブラウザはフラグを設定し、サーバに対して、ＤＳを用いて完全に破棄し、認証の応答全体を戻すよう送信するように指示する。サーバがリストを受信すると、ＶＳＵを実行した場所のリストにおいてそれが有するものを選択し、または、ブラウザリストが空白の場合には、サーバは、そのＤＳの使用をデフォルトにする。フラグがセキュリティレベル低に設定される場合には、サーバは、ブラウザに対して完全に、直接応答する。

中または高の設定の場合には、サーバは、そのＤＳリストがブラウザＤＳリストにあるもののいずれかと一致しない場合には、そのＤＳをデフォルトにする。サーバがブラウザに応答する準備ができているため、まず、このＡＨのためにＤＳ ＩＤを生成する。次に、サーバは（ブラウザ公開鍵を用いて）ブラウザに応答し、セッションマスタ鍵（ＳＭＫ）の関連する前半と共に、この伝送のＤＳ ＩＤと同様に選択としてＤＳを含める。サーバはさらに、ＳＭＫの後半と共にそのＤＳ鍵を用いてＤＳに応答し、サーバは、常に、最低でも、ＣＤＳに対してＤＳ鍵を有するため、サーバからＤＳへの応答は、常に、ＳＳＬＸ−ＥＡで暗号化される。

ブラウザがサーバ応答を受信すると、これは、公開鍵で暗号化されたコンテンツをアンラップする。低の設定において、ブラウザは全てのコンテンツを処理し、ＳＭＫは共有されており、ブラウザおよびサーバは通常の動作の準備ができている。中または高の設定の場合には、応答には、サーバで選択したＤＳが含まれる。このＤＳがブラウザの予期したものではなく（リストになく）、ブラウザのセキュリティレベルが高に設定されている場合には、警告が表示される。リストにない場合には、ＤＳへのリクエストおよび応答は、ブラウザのＤＳ ＳＳＬＸ−ＥＡ鍵（高および中の場合）を使用する。設定が中である場合および（送信されたリストにないかまたはリストが存在しないので）ＤＳがリストにない場合には、ブラウザは、ＤＳリクエストおよび応答の通信のために、その公開鍵を使用する。

セキュリティ設定およびそれによるオプションの概要を示す表を、以下の表１に示す。

認証ハンドシェイクと、ウェブサーバとブラウザとの間のブラウザのＳＭＫの対称認識の後、通常動作が全てのコンテンツリクエストおよび応答を処理する。

（検証されたサーバ（オプションのブラウザ）セットアップ）
検証されたセットアップの目的は、２つのパーティ間の公知の関連を確立することである。ＳＳＬＸにおいて、これは、サーバとＤＳとの間、または、ブラウザとＤＳとの間である。少なくとも、各サーバは、少なくとも１つのディレクトリサービス／サーバ（ＤＳ）と共に検証されたセットアップ（ＶＳＵ）を実行する必要がある。これにより、上述したようにエンドユーザが中となるように関与しなくても、ＳＳＬＸシステムの最低限のセキュリティが確立される。少なくとも１つのＤＳへのＶＳＵにおけるオプションのブラウザの関与によって、高のセキュリティで通信する能力が確立される。

電子通信における２つのパーティの初期の信頼性を検証するためには、明らかに、ある種類の人的なやりとりを有することが最適である。ＳＳＬＸでは３つの手段が提供されており、１つは最小限の人的なやりとりを、２つ目は自動のプロセスを必要とする。ＶＳＵの全体の起動力（ｅｎｔｉｒｅ ｉｍｐｅｔｕｓ）は、検証という行為である。いずれのＳＳＬＸ方法においても、電話、メールまたはサーバ所有者およびＤＳオペレータの間のさらなる個人的な相互のやりとり等の、ここで説明したもの以外のいくつかのその他の帯域外の方法で「二重にチェック」することにより、さらに信頼性を検証するための機会は常に存在する。

３つのＳＳＬＸの方法は、
１．ＳＳＬＸ−ＥＡ鍵のサーバ（またはブラウザ）とＤＳとの間の公開鍵の交換（低）、
２．ＳＳＬＸ−ＥＡ鍵の電子メールの交換（中）、および
３．ＳＳＬＸ−ＥＡ鍵の２つの半分の公開鍵交換および電子メールの組み合わせ（高）
である。

ＳＳＬＸサーバおよびブラウザの動作コードは、自動的でない場合には、人による対話的動作（カットアンドペースト、鍵のタイプによる入力等）で、これらの方法のいずれかを処理するために設定される。電子メールおよび公開鍵の対話的動作の両方がマンインザミドル（ＭＩＴＭ）攻撃を受けやすいと言われているが、個別に使用するにせよ、共に使用するにせよ、検証されたセットアップについて留意すべき最も重要な点は、任意の種類の任意のＳＳＬＸトラフィックの前に、セットアップの信頼性に関してさらなる帯域外チェックを実行可能であるということである。セキュリティシステムに対し積極的関心を有するこうしたウェブサイトおよびその顧客の認知および期待は、そのセットアップをチェックするある種の帯域外スポットを一般的に使用すると仮定される。

（動作）
図４を参照し、以下に、ブラウザ４１とサーバの両方の検証されたセットアップ４０の標準的な動作を説明する。サーバ（またはブラウザ）４１は、まず、公開および非公開鍵の対を作成し、信頼できるＳＳＬＸ−ＥＡ ＤＳ鍵（ＤＳＫ）が公開鍵（Ｖ−ＷＳＢ１）４３でラップされるように、ディレクトリサービス４２にオープンリクエストを送信する。リクエストは、以下のいずれか、およびどのエレメントが実行されるかを決定する認証リクエスト（ＡＲ）値を有し、
・ ＡＲ値が公開鍵オプションのものである場合には、ＤＳは、送信された公開鍵（Ｖ−ＤＳ２）４４を用いてラップされたＤＳＫ全体と共に、単一の応答のみを行い、
・ ＡＲ値が電子メールオプションのものである場合には、ＤＳは、ＡＲ（Ｖ−ＤＳ２）４４で指定される電子メールアドレスへ、電子メールで送信されるＤＳＫ全体と共に、単一の応答を行い、
・ ＡＲ値が公開鍵と電子メールの両方の組み合わせのものである場合には、ＤＳは、このサーバまたはブラウザのためにＤＳＫを生成した後で２回の応答を行う。１回は、送信した公開鍵（Ｖ−ＤＳ２）４４を用いてラップされたＤＳＫの前半と共に、サーバ／ブラウザへ直接再び応答し、もう１回は、前半（Ｖ−ＤＳ３）４５によってオフセットされるＤＳＫの後半と共に、ＡＲで指定される電子メールアドレスへ、電子メールによって応答する。

サーバまたはブラウザ４１によって、ＤＳＫの最大２つの半分の入力が可能になり、ＶＳＵ ＤＳのリストにＤＳ ＤＳＫが保存される。また、検証セットアップを完結させるために、確認ＴＣＰメッセージが、新しいＤＳＫ（Ｖ−ＷＳＢ４）４６でラップされて、ＤＳ４２に送信される。ＤＳ４２は、確認メッセージ（Ｖ−ＷＳＢ５）４７を復号化するために、ＤＳＫを使用する。これが確認されず、送信された値が計算された値と等しくない場合には、ＤＳ４２は、公開鍵（Ｖ−ＤＳ６）４８でラップされた「拒否された」メッセージを、ブラウザまたはサーバ４１に返信する。ブラウザまたはサーバ４１は、次に、拒否メッセージを復号化し、ユーザに通知を送信し、ＶＳＵリスト（Ｖ−ＤＳ７）４９からＤＳを削除する。

検証されたセットアップの後、サーバおよびブラウザの両方は、関連付けられたＤＳＫと共にＤＳのリストを維持し、ＳＳＬＸでサポートされるウェブサイトにおける認証リクエストにこれらを含む。

上記の実施形態は、１つのパスによってＤＳＫの前半を、その他のパスによって後半を伝送することを示しているが、本発明は正確な半分を２通りで送信することに制限されているわけではなく、前半を１つのパスで、後半を別のパスで送信してもよいが、両方の合計がＤＳＫの全体と等しい限り、各部分のサイズは異なってもよい。それに加えて、必要以上の部分を送信してもよい。さらに、３つ以上のパスを利用可能であり、この場合には、ＤＳＫの複数部分を複数のパス上に送信可能である。さらに、ＳＭＳ、インスタントメッセージング、通常の郵便の手紙、速達、手渡しの配達、電話による通話等、任意の通信パスを利用可能である。

（ＳＳＬＸの相互作用の詳細）
以下は、各ＳＳＬＸ動作モードおよびプロセスの設計仕様である。

（通常の動作（信頼できる））
● ブラウザＳＳＬＸ−ＥＡのセッションマスタ鍵（ＳＭＫ）−認証ハンドシェイクから取得された場合。

○ ＯｐｅｎＩＤ（このサーバにおけるこのセッションの一意の識別子）との関連付け。

● ブラウザＳＳＬＸ−ＥＡ ＳＭＫ−特定のドメインへのセキュアなアクセスのためにデータ所有者から取得される場合。

○ 信頼できるサーバ所有者への帯域外認証されたプロセスによって取得（例：関連する認証情報（社員番号等）を有するアドミニストレータおよび鍵および永続的なＯｐｅｎＩＤによって電子メールに応答するアドミニストレータへ、電子メールを送信する社員等）。

・ 認証および承認された各ユーザのために、サーバはＫ１値を無作為に作成。

・ サーバの鍵配信センター（ＫＤＣ）における割り当てられたＯｐｅｎＩＤと共に、Ｋ１値を保存する。

・ Ｋ１、ＯｐｅｎＩＤおよびドメインが、所望の帯域外の方法においてブラウザ所有者へ返される。

○ ブラウザに挿入。

・ 追加するメニューオプション
・ 追加／編集フォーム
□ カットアンドペーストまたは鍵の入力およびＯｐｅｎＩＤおよびドメイン
□ ＰＩＮプロテクトのオプション（クッキーの最初の桁における０／１の入力またはいくつかの方法）
○ ＰＩＮの入力、ＰＩＮの再入力
○ ＭＯＤ１６（ＰＩＮ、鍵）
○ テキストファイル内に保存（クッキー−形式のＴＢＤ）
● セッション長
○ セッション長を定義するためのサーバ設定
・ ０（デフォルト）＝１つのＨＴＭＬページ
・ １＝リクエスト毎
・ ２＝リクエスト／応答ラウンドトリップ毎
・ ３＝最初のページ（サーバへの初期のリクエスト）
・ ４＝５リクエスト毎
・ ５＝１０リクエスト毎
・ ６＝ｎリクエスト毎
● ＨＴＴＰＸ：／／ウェブアドレスの、ＧＥＴ／ＰＯＳＴのブラウザリクエスト（ブラウザ、図２、ステップ１、Ｔ−ＢＲｌ）
○ ＳＳＬＸ−ＥＡ ＳＭＫおよびＯｐｅｎＩＤの取得
・ 保存されたブラウザＳＭＫの検索
・ 鍵が存在する場合には、ＰＩＮが保護されているか（クッキーの最初の桁が１＝Ｙｅｓ、０＝Ｎｏ）
□ Ｙｅｓの場合には、ＰＩＮを入力するフォーム
○ ＰＩＮ入力の際に、鍵ファイルを開き、鍵およびＭＯＤ１６Ｄ（ＰＩＮ、鍵で暗号化された）を読み込み、結果をメモリに読み込む
□ Ｎｏの場合には、鍵ファイルを開き、鍵をメモリに読み込む
・ 鍵が存在しない場合には、認証ハンドシェイクを実行し、生成されたＳＭＫを利用する
○ リクエストテキストを取得
○ ＳＳＬＸ−ＥＡセッションの開始の場合
・ ＳＳＬＸ−ＥＡを実行
・ サーバへＨＴＴＰＸのＳＳＬＸ−ＥＡ出力を送信
○ ＳＳＬＸ−ＥＡセッション内でない場合
・ リクエスト平文上のセッションＳＳＬＸ−ＥＡメッセージ鍵を用いて、暗号の暗号化を実行
・ ＯｐｅｎＩＤ、ＨＴＴＰＸの暗号文をサーバに送信
● ＨＴＴＰＸの応答（サーバ、図２、ステップ２、Ｔ−ＷＳ２）
○ リクエストＯｐｅｎＩＤに基づいてブラウザのＳＭＫを取得
・ 認証ハンドシェイク中に生成された場合には、ローカルメモリ／近傍エリアに保存される
・ ＯｐｅｎＩＤが認証ハンドシェイクで生成されなかった場合には、これは、ファイルベースのＫＤＣのファイル検索、またはＤＢ ＫＤＣのデータベース検索のいずれかである
○ ＳＳＬＸ−ＥＡセッションの開始の場合には、
・ ＳＳＬＸ−ＥＡ復号化の実行
・ 復号化されたブラウザリクエストを処理し、リクエストされたコンテンツの取得
・ コンテンツが平文である場合には、ＳＳＬＸ−ＥＡ暗号化を実行
・ ＨＴＴＰＸのＳＳＬＸ−ＥＡ出力をブラウザに返信
○ ＳＳＬＸ−ＥＡセッション内でない場合
・ ＳＳＬＸ−ＥＡメッセージ鍵を用いて暗号の復号化を実行
・ 復号化されたブラウザリクエストを処理し、リクエストされたコンテンツを取得
・ コンテンツ上でＳＳＬＸ−ＥＡメッセージ鍵を使用した、暗号の暗号化の実行
・ ブラウザへのＯｐｅｎＩＤ、ＨＴＴＰＸの暗号文の送信
● コンテンツのブラウザ受信（ブラウザ、図２、ステップ３、Ｔ−ＢＲ３）
○ これが新たに開始されたＳＳＬＸ−ＥＡセッション（セッション長＝１）の受信である場合
・ ＳＳＬＸ−ＥＡ復号化を実行
○ ＳＳＬＸ−ＥＡセッション（セッション長＜＞１）内でない場合
・ 現在のＳＳＬＸ−ＥＡメッセージ鍵を用いて、暗号の復号化を実行
○ 復号化されたサーバコンテンツを処理し、ＨＴＭＬテキスト／グラフィック／データを取得
○ ブラウザにおけるＨＴＭＬの処理、ユーザへの表示
●鍵の更新（永続的な信頼できるモードのための、ブラウザおよびサーバのバージョン、非ＡＨ動作）
○ ＳＳＬＸは、ＨＴＴＰの処理状態を把握していないこと（ｓｔａｔｅｌｅｓｓｎｅｓｓ）を活用するためのものであるため、各セッションは、ＫＤＣからの鍵の再取得を必要とするが、この動作条件は、サーバ上に不必要な負荷（遅延）を生じさせる可能性がある。このため、サーバは、ＯｐｅｎＩＤのおよびそれらの関連付けられた一連のＳＳＬＸ−ＥＡ鍵をメモリに保持するよう構成することができる。さらに、アプリケーションがクローズする際に、またはアドレスバーがサーバメモリから鍵をリリースするためにサーバのドメイン外にリクエストする際に、ブラウザからサーバに送信される「ログアウト」または「セッション終了」のメッセージが存在することがある。

○ ＳＳＬＸは、静的鍵によってＳＳＬＸ−ＥＡの方法を使用するため、一定の間隔でＫ１を更新するためにセキュリティモデルに関連している。

・ Ｋ１の更新のためにサーバの構成設定と等しい測定基準（ｍｅｔｒｉｃ）に達すると（例：多数のメッセージ、ランダムな時間値等）、新しいＫ１を平文として使用し、鍵更新の交換を実行する
・ サーバおよびブラウザの両方が、新しいＫ１値を有していることを確認するまでこの値を保持し、次に、（選択する場合には、ＰＩＮを用いて）ブラウザで鍵を更新し、サーバＫＤＣを更新する
（認証ハンドシェイク（ＡＨ））
ＡＨの場合には、最初の関連する項目はブラウザ構成である。上述したように、ブラウザは、そのＳＳＬＸ接続のセキュリティレベルを設定可能である。セキュリティ設定と共に、ユーザが設定可能な２つのその他の構成項目があり、
● ハンドシェイク全体を送信するために好適な特定のＤＳを使用するオプションと、
● サーバが設定に適合できない（例：同じディレクトリサービスを認識していない）ため、所望のセキュリティレベルを下げることを認めるオプションと
である。

表２に、ユーザが選択可能な、考えられる設定の組み合わせの全てのリストを示す。

高が選択されている場合には、ブラウザユーザは、設定を保持するためにＤＳ ＶＳＵを実行するよう求められる（まだ実行していない場合）。

● ウェブサーバへのブラウザ起動（ブラウザ、図３、ステップ１、Ａ−ＢＲｌ）
○ その方法による、公開／非公開鍵の対の作成
・ 公開／非公開鍵ペア生成の最短／最速／最もセキュアな方法の選択、および鍵ペアの生成（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ Ｃｒｙｐｔｏｇｒａｐｈｙ−ＥＣＣ、最も可能性の高い選択）
・ 最高のセキュリティの実施のために、ＡＨによって生成−保存／再利用しない
・ ＨＴＴＰＸ：／／呼び出しにおけるウェブサーバへの認証リクエスト（ＡＲ）の送信
・ セキュリティ設定フラグコード、オプションの公開鍵、オプションのＶＳＵ ＤＳリスト（ＤＳ名、ＤＳ ＩＰアドレス等）をウェブサーバに送信（セキュリティ設定フラグコードはブラウザ設定の設定であり、ブラウザセットアップ上で最初に中（＃３）のデフォルトに設定）
○ セキュリティ設定フラグ（ＳＳＦ）コードの設定
● ０（高）＝鍵の半分が、ＢＲへ、検証されたセットアップ（ＶＳＵ）ＤＳによって送信される
○ ＶＳＵリスト（おそらくＣＤＳを含み、少なくとも１つを有する）、ＯｐｅｎＩＤ、ＤＳ ＩＤ、公開鍵が含まれる
● １（高）＝ＤＳのみ。鍵全体がＶＳＵ ＤＳによって送信される（＃３まで低くなった場合に公開鍵が含まれる、事前登録されたＤＳ鍵が特定のＶＳＵに存在する）
○ 少なくとも１つのＤＳ、ＯｐｅｎＩＤ、ＤＳ ＩＤ、公開鍵が含まれるリスト
● ２（中）＝ＤＳのみ。鍵全体がＤＳによって送信される（オプションのＶＳＵ ＤＳリストまたはＤＳリストのみ、またはリストなし）
○ オプションのＶＳＵ ＤＳリスト、ＯｐｅｎＩＤ、公開鍵が含まれる、ＤＳ ＩＤ
● ３（中）＝（デフォルト）、鍵の半分がＢＲへ、ＤＳによって送信される
○ 公開鍵が含まれる。オプションのＶＳＵ ＤＳリスト、またはＤＳリストのみ、またはリストなし）、ＯｐｅｎＩＤ、ＤＳ ＩＤ
● ４（低）＝ ＢＲのみ。鍵全体がブラウザに再び送信される（ＤＳなし）
○ 公開鍵が含まれる、ＯｐｅｎＩＤ
○ ＯｐｅｎＩＤは、（このＡＨおよびブラウザの実施例のための）このブラウザを識別する１６桁のランダムな１６進数の数
○ ＤＳ ＩＤは、ＤＳＤＳ ＩＰに存在し、応答されるリクエストＩＤを識別する３２桁のランダムな１６進数の数であり、ブラウザのディレクトリサービス（ＶＳＵ）の１つの公開ＩＰアドレスである。

○ ドメイン名は、公開ＨＴＴＰの名称である。例えば、「ｗｗｗ．ｓｓｌｎｅｘｔ．ｃｏｍ」
● ウェブサーバは、ＡＲ、ＳＳＦに基づくブラウザに応答する（サーバ、図３、ステップ２、Ａ−ＷＳ２）
○ ＳＳＦ＝０の場合
・ ブラウザＳＭＫ（Ｋ１、２５６ビット）を生成
・ ブラウザリストから一致するＶＳＵを選択、ＤＳ鍵（ＤＳＫ）を取得
● 一致しない場合には、ＳＳＬＸエラー＃「ＶＳＵの一致がありません。オプションを低くしない場合には、高のセキュリティを処理できません。コード０」で応答（公開鍵を用いてラップ）
○ ブラウザのエラーメッセージによって、現在の設定でこのサーバに接続したい場合には、構成オプションを参照し変更するよう指示される
○ ＤＳ情報（ＤＳ ＩＰ）のログテキストファイル入力の生成（ファイルが存在しない場合には、作成し、存在する場合には付け加える）
・ 公開鍵（公開鍵暗号方法）でラップされたＳＭＫの前半（３２桁、１２８ビット）、ＤＳ ＩＰ、ドメイン名による応答
・ ＤＳ ＤＳＫを使用し、ブラウザのＯｐｅｎＩＤ、ＤＳ ＩＤおよびＳＭＫの後半を送信して、選択したＤＳへステップ３を実行
○ ＳＳＦ＝１の場合
・ ブラウザＳＭＫの生成
・ ブラウザからのＶＳＵ ＤＳの選択、ＤＳ鍵（ＤＳＫ）の取得
● 一致しない場合には、（セキュリティレベルの低下は認められないため）フラグＳＳＦ設定が「３」であると仮定して応答し、以下の作業を続ける
○ ＤＳ情報（ＤＳ ＩＰ）のログテキストファイル入力の生成（ファイルが存在しない場合には、作成し、存在する場合には、付け加える）
・ 公開鍵においてラップしたＤＳ ＩＰ、ドメイン名で応答（そのため、ブラウザは、どのＤＳが選択されたかを認識している）
・ ＤＳ ＤＳＫを使用し、ブラウザのＯｐｅｎＩＤ、ＤＳ ＩＤおよびＳＭＫ全体を送信して、特定のＤＳへステップ３を実行
○ ＳＳＦ＝２の場合
・ ブラウザＳＭＫの生成
・ （リストの場合）ブラウザリストから一致するＶＳＵ ＤＳまたは（リストの場合）任意のＤＳを選択するか、リストがない場合にはＣＤＳを使用し、ＤＳ鍵（ＤＳＫ）を取得する（少なくともＣＤＳ ＤＳＫとなる）
● ＣＤＳの最も低い共通の基準（ｄｅｎｏｍｉｎａｔｏｒ）を使用できるため、エラーとはならない
● サーバのＶＳＵリストにはない、ＤＳ情報（ＤＳ ＩＰ）のログテキストファイル入力を生成（ファイルがない場合には、生成し、存在する場合には付け加える）
・ 公開鍵でラップされたＤＳ ＩＰ、ドメイン名で応答
・ ＤＳ ＤＳＫを使用し、ブラウザのＯｐｅｎＩＤ、ＤＳ ＩＤおよびＳＭＫ全体を送信して、選択したＤＳにステップ３を実行する
○ ＳＳＦ＝３（デフォルト）の場合
・ ブラウザＳＭＫの生成
・ （リストの場合）ブラウザリストから一致するＶＳＵ ＤＳまたは（リストの場合）任意のＤＳを選択するか、リストがない場合にはＣＤＳを使用し、ＤＳ鍵（ＤＳＫ）を取得する（少なくともＣＤＳ ＤＳＫとなる）
● ＣＤＳの最も低い共通の基準（ｄｅｎｏｍｉｎａｔｏｒ）を使用可能であるため、エラーとはならない
● サーバのＶＳＵリストにない、ＤＳ情報（ＤＳ ＩＰ）のログテキストファイル入力（ファイルがない場合には、作成し、存在する場合には、付け加える）を生成
・ 公開鍵でラップされたＳＭＫの前半（３２桁、１２８ビット）、ＤＳ ＩＰ、ドメイン名で応答
・ ＤＳ ＤＳＫを使用し、ブラウザのＯｐｅｎＩＤ、ＤＳ ＩＤおよびＳＭＫの後半を送信して、選択したＤＳにステップ３を実行
○ ＳＳＦ＝４の場合
・ ブラウザＳＭＫを生成
・ 公開鍵でラップされたブラウザへ、ＳＭＫ全体、ドメインＩＰアドレス、ドメイン名を再び送信するステップ５を実行
● ［オプション］ディレクトリサービス／サーバ（サーバ、図３、ステップ３、Ａ−ＷＳ３）に対するサーバ応答
○ サーバは検証されたセットアップを実行して、少なくともＣＤＳとなったはずであるため、ＤＳ鍵（ＤＳＫ）が存在する
○ このステップは、（ＳＳＦのリターンから）パラメータとしてのＤＳ ＩＤおよびＤＳ ＩＰ、少なくともＣＤＳと共に呼び出される
・ ＳＳＦ＝０の場合
● ＯｐｅｎＩＤ、ＤＳ ＩＤおよびＳＭＫの後半を送信
・ ＤＳＫを用いてＳＳＬＸ−ＥＡ鍵交換を実行、新しいメッセージ鍵を作成
・ ブラウザのＯｐｅｎＩＤ、ＤＳ ＩＤ、およびＳＭＫの後半を暗号化するために、ＡＥＳでメッセージ鍵を使用
・ ＤＳにおいてＤＳのＩＰｗ／ＷＳのＯｐｅｎＩＤにＳＳＬＸ−ＥＡ出力（ＲおよびＷ１）を、およびＳＭＫの暗号文、ＤＳ ＩＤを応答
・ ＳＳＦ＝１の場合
● ＯｐｅｎＩＤ、ＤＳ ＩＤおよびＳＭＫ全体を送信
・ ＤＳＫを用いてＳＳＬＸ−ＥＡ鍵交換を実行、新しいメッセージ鍵を作成
・ ブラウザのＯｐｅｎＩＤ、ＤＳ ＩＤ、およびＳＭＫ全体を暗号化するために、ＡＥＳでメッセージ鍵を使用
・ ＳＳＬＸ−ＥＡ出力と共にＤＳのＩＰ、ブラウザのＯｐｅｎＩＤおよびＳＭＫの暗号文、ＤＳ ＩＤを応答
・ ＳＳＦ＝２の場合
● ＯｐｅｎＩＤ、ＤＳ ＩＤおよびＳＭＫ全体を送信
・ ＤＳＫを用いてＳＳＬＸ−ＥＡ鍵交換を実行、新しいメッセージ鍵を作成
・ ブラウザのＯｐｅｎＩＤ、ＤＳ ＩＤ、およびＳＭＫ全体を暗号化するために、ＡＥＳでメッセージ鍵を使用
・ ＳＳＬＸ−ＥＡ出力と共にＤＳのＩＰ、ブラウザのＯｐｅｎＩＤおよびＳＭＫの暗号文、ＤＳ ＩＤを応答
・ ＳＳＦ＝３の場合
● ＯｐｅｎＩＤ、ＤＳ ＩＤおよびＳＭＫの後半を送信
・ ＤＳＫを用いてＳＳＬＸ−ＥＡ鍵交換を実行、新しいメッセージ鍵を作成
・ ブラウザのＯｐｅｎＩＤ、ＤＳ ＩＤ、およびＳＭＫの後半を暗号化するために、ＡＥＳでメッセージ鍵を使用
・ ＳＳＬＸ−ＥＡ出力と共にＤＳのＩＰ、ブラウザのＯｐｅｎＩＤおよびＳＭＫの暗号文、ＤＳ ＩＤへ応答
・ ＳＳＦ＝４の場合には、このステップを省略
● ［オプション］ディレクトリサービス／サーバへのブラウザリクエスト（ブラウザ、図３、ステップ４、Ａ−ＢＲ４）
○ ブラウザが検証されたセットアップを終了し、ＤＳ ＤＳＫを有している、またはＤＳは、応答のためにブラウザの公開鍵が付与される
○ このステップは、パラメータとして、（ＳＳＦリターンから）ＤＳ ＩＤおよびＤＳ ＩＰ、または少なくとも、ＣＤＳと共に呼び出される
・ ＳＳＦ＝０の場合
● ＯｐｅｎＩＤ、ＤＳ ＩＤを暗号化する指定されたＤＳ ＩＰへ、ＤＳＫを使用し、ＳＭＫの後半、ドメイン名、ＩＰアドレスを求めて、ＤＳリクエスト（ＤＳＲ）を送信
・ ＳＳＦ＝１の場合
● ＯｐｅｎＩＤおよびＤＳ ＩＤが暗号化されている場合には、ＤＳＫを使用し、ＳＭＫ全体、ドメイン名、ＩＰアドレスを求めて、指定されたＤＳ ＩＰにＤＳＲを送信
・ ＳＳＦ＝２の場合
● （リストが存在した場合およびＤＳＫが存在する場合）ＤＳＫを用いて、ＯｐｅｎＩＤ、ＤＳ ＩＤを暗号化し、ＳＭＫ全体、ドメイン名、ＩＰアドレスを求めて、指定されたＤＳ ＩＰにＤＳＲを送信
・ ＤＳＫがない場合には、指定されたＤＳ ＩＰにＤＳＲを送信し、ここでＯｐｅｎＩＤ、ＤＳ ＩＤおよび公開鍵がオープンに送信され、ＳＭＫ全体、ドメイン名およびＩＰアドレスがリクエストされる
・ ＳＳＦ＝３の場合
● （リストが存在した場合およびＤＳＫが存在する場合）ＤＳＫを用いて、ＯｐｅｎＩＤ、ＤＳ ＩＤを暗号化し、ＳＭＫの後半、ドメイン名、ＩＰアドレスを求めて、指定されたＤＳ ＩＰにＤＳＲを送信
・ ＤＳＫがない場合には、ＤＳＲを指定したＤＳ ＩＰに送信し、ここでＯｐｅｎＩＤ、ＤＳ ＩＤおよび公開鍵がオープンに送信され、ＳＭＫの後半、ドメイン名およびＩＰアドレスがリクエストされる
・ ＳＳＦ＝４の場合には、このステップを省略
● ［オプション］ブラウザ（ＤＳ、図３、ステップ５、Ａ−ＤＳ５）に対するディレクトリサービス／サーバ応答
○ ＳＳＦ ＝４の場合には、このステップは実行されない
○ ブラウザが、応答のためにＤＳＫまたは公開鍵を用いて、ＤＳリクエスト（ＤＳＲ）を送信した
・ ＤＳＫを用いてＤＳＲが送信された場合には、ＯｐｅｎＩＤが存在する
● このブラウザの正しいＤＳＫを取得するためにＯｐｅｎＩＤを使用
● ＤＳ ＩＤが提供されている場合には、このブラウザセッションの正しいＳＭＫを得るためにこれを使用し、提供されていない場合には、正しいＳＭＫを得るためにＯｐｅｎＩＤを使用する
● ＤＳＫを用いてＳＳＬＸ−ＥＡ鍵交換を実行し、メッセージ鍵を現す。生成されたＷ１と共に送信されたＷ１をチェック。一致の場合には継続する（その他の場合は、エラー）
● リクエストを示すためにＡＥＳ復号化でメッセージ鍵を使用（ブラウザを認証）
・ ＳＳＦ＝０の場合
○ ＡＥＳメッセージ鍵がブラウザリクエストから既に公知
○ ＳＭＫの後半、ドメイン名およびＩＰアドレスの暗号化にメッセージ鍵を使用
○ ＳＳＬＸ−ＥＡ出力、暗号文によって、ブラウザのＩＰに応答
・ ＳＳＦ＝１の場合
○ ＡＥＳメッセージ鍵がブラウザリクエストから既に公知
○ ＳＭＫ全体、ドメイン名およびＩＰアドレスにメッセージ鍵暗号化を使用
○ ＳＳＬＸ−ＥＡ出力、暗号文によって、ブラウザのＩＰへ応答
・ ＳＳＦ＝２の場合
○ ＡＥＳメッセージ鍵がブラウザリクエストから既に公知
○ メッセージ鍵暗号化をＳＭＫ全体、ドメイン名およびＩＰアドレスに使用
○ ＳＳＬＸ−ＥＡ出力、暗号文によって、ブラウザのＩＰに応答
・ ＳＳＦ＝３の場合
○ ＡＥＳメッセージ鍵がブラウザリクエストから既に公知
○ＳＭＫの後半、ドメイン名およびＩＰアドレスにメッセージ鍵暗号化を使用
○ ＳＳＬＸ−ＥＡ出力、暗号文によって、ブラウザのＩＰへ応答
・ ブラウザの公開鍵を用いてＤＳＲが送信された場合には、ＤＳ ＩＤ（およびＯｐｅｎＩＤ）が存在する
● このブラウザセッションの正しいＳＭＫを取得するためにＤＳ ＩＤを使用
・ ＳＳＦ＝２の場合
○ 公開鍵がブラウザリクエストから既に公知
○ ＳＭＫ全体、ドメイン名およびＩＰアドレスを暗号化するために、公開鍵を使用
○ 暗号文出力によって、ブラウザのＩＰに応答
・ ＳＳＦ＝３の場合
○ 公開鍵がブラウザリクエストから既に公知
○ ＳＭＫ後半、ドメイン名およびＩＰアドレスを暗号化するために公開鍵を使用
○ 暗号文出力による、ブラウザのＩＰへの応答
● コンテンツのブラウザ復号化（ブラウザ、図３、ステップ６、Ａ−ＢＲ５）
○ ＳＳＦ＝０の場合
・ ＡＥＳメッセージ鍵が保存されているため、ＳＭＫ後半、ドメイン名およびＩＰアドレスを示すためにこれを使用
・ サーバからのドメイン名／ＩＰアドレスを、ＤＳからのドメイン名に対してチェックし、同じ場合には、継続し、その他の場合には、停止してユーザに警告！
・ ＳＭＫの前半および後半を結合させ、全体を完成させる
・ 通常の動作でＳＭＫを使用
○ ＳＳＦ＝１の場合
・ ＡＥＳメッセージ鍵が保存されているため、ＳＭＫ、ドメイン名およびＩＰアドレスを示すためにこれを使用
・ サーバからのドメイン名／ＩＰアドレスを、ＤＳからのドメイン名に対してチェックし、同じ状況が続く場合には、停止してユーザに警告！
・ 通常の動作でＳＭＫを使用
○ ＳＳＦ＝２の場合
・ ＤＳＲがＤＳＫを用いて送信される場合
● ＡＥＳメッセージ鍵が保存されるため、ＳＭＫ、ドメイン名およびＩＰアドレスを示すためにこれを使用
・ 公開鍵を用いてＤＳＲが送信されたのでない場合
● ＳＭＫ全体、ドメイン名およびＩＰアドレスを示すために、公開鍵を用いて復号化を実行
・ サーバからのドメイン名を、ＤＳからのドメイン名に対してチェックし、同じ状況が続く場合には、停止してユーザに警告！
・ 通常の動作でＳＭＫを使用
○ ＳＳＦ＝３の場合
・ ＤＳＫを用いてＤＳＲが送信される場合
● ＡＥＳメッセージ鍵が保存されるため、ＳＭＫ、ドメイン名およびＩＰアドレスを示すためにこれを使用
・ 公開鍵を用いてＤＳＲが送信されたのではない場合
● ＳＭＫ全体、ドメイン名およびＩＰアドレスを示すために、公開鍵を用いて復号化を実行
・ サーバからのドメイン名／ＩＰアドレスを、ＤＳからのドメイン名に対してチェックし、同じ状況が続く場合には、停止してユーザに警告！
・ ＳＭＫの前半および後半を結合させ、全体を完成させる
・ 通常の動作でＳＭＫを使用
○ ＳＳＦ＝４の場合
・ サーバ応答が公開鍵を用いて送信される
● ＳＭＫ全体、ドメイン名を示すために、公開鍵を用いて復号化を実行
● サーバからのドメイン名を、アドレスバーのドメインに対してチェックし、同じ状況が続く場合には、停止してユーザに警告
● 通常の動作でＳＭＫを使用
（検証されたサーバ（オプションのブラウザ）セットアップ（ＶＳＵ））
● ブラウザでは、ディレクトリサービス／サーバへ、メニューオプション上のＶＳＵを起動する（ブラウザ、図４、ステップ１、Ｖ−ＷＳＢ１）
● サーバの場合には、アプレット／拡張の実行時にＶＳＵを起動する（サーバ、図４、ステップ１、Ｖ−ＷＳＢ１）
● 残りのフロー（全てのステップ）は、ブラウザおよびサーバの両方のためのものであり、記載において詳細に説明する
○ 方法による公開／非公開鍵ペアの作成
・ 公開／非公開鍵ペア生成の最短／最速／最もセキュアな方法を選択し、鍵ペアを生成（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ Ｃｒｙｐｔｏｇｒａｐｈｙ−ＥＣＣ、最も可能性の高い選択肢）
・ 最高のセキュリティ実施のために、ＶＳＵによって生成し、保存／再利用しない
○ ＴＣＰ呼び出しにおけるＶＳＵリクエスト（ＶＳＵＲ）のＤＳへの送信
・ ＤＳフラグコード、ドメイン名（サーバのみ）、オプションの公開鍵、オプションの電子メールアドレスをＤＳに送信
・ ブラウザ：ＤＳフラグコードはブラウザ設定の設定である。最初、ブラウザセットアップで高（＃０）、デフォルトに設定する。ブラウザにはドメイン名は不要
・ サーバ：唯一の動作方法は高であり、少なくとも、ＣＤＳと接続するためにサーバの最初の開始の際にＶＳＵが実行される。ドメイン名は必要である。

● ＤＳフラグ（ＤＳＦ）コードの設定
・ ０（高）＝電子メールおよびＤＳによって送信された鍵の半分
□ 公開鍵、電子メールアドレス、ドメイン名が含まれる
・ １（中）＝電子メールのみ−鍵全体が電子メールによって送信
□ 電子メールアドレス、ドメイン名が含まれる
・ ２（低）＝ＤＳのみ−鍵全体がＤＳによって送信（電子メールなし）
□ 公開鍵、ドメイン名が含まれる
● 電子メールアドレスは公開ＰＯＰアドレス
● ブラウザまたはサーバへのディレクトリサービス／サーバの応答（ＤＳ、図４、ステップ２、Ｖ−ＤＳ２）
○ ＤＳＦ＝１の場合には、このステップは実行されない
○ ブラウザまたはサーバは、応答のために公開鍵を用いて、ＶＳＵＲを送信した
・ エンティティのためにＯｐｅｎＩＤ、ＤＳＫを生成（ブラウザまたはサーバ）
● ＤＳＦ＝０の場合
・ 公開鍵でラップされた、ＤＳＫの前半（３２桁、１２８ビット）、ＯｐｅｎＩＤで応答
・ 公開鍵を使用し、ＤＳＫオフセットの後半を（ＭＯＤ１６で暗号化された）前半によって送信し、電子メールアドレスへステップ３を実行
● ＤＳＦ＝２の場合
・ 公開鍵でラップされた、ＤＳＫ全体、ＯｐｅｎＩＤで応答
● ブラウザまたはサーバへのディレクトリサービス／サーバの応答（ＤＳ、図４、ステップ３、Ｖ−ＤＳ３）
○ ＤＳＦ＝２の場合には、このステップは実行されない
○ ブラウザまたはサーバが応答のために電子メールアドレスを用いて、ＶＳＵＲを送信した
・ エンティティ（ブラウザまたはサーバ）のためにＯｐｅｎＩＤ、ＤＳＫを生成（ステップ２で既に行われているのではない場合）
● ＤＳＦ＝０の場合
・ 前半と共に暗号化されたＤＳＫ Ｍｏｄ１６の後半（３２桁、１２８ビット）、ＯｐｅｎＩＤによって、電子メールアドレスへ応答
● ＤＳＦ＝１の場合
・ 電子メールアドレスへ、メッセージにおいてＤＳＫ全体、ＯｐｅｎＩＤと共に応答
● 応答および確認のブラウザ／サーバの復号化（ブラウザ／サーバ、図４、ステップ４、Ｖ−ＷＳＢ４）
○ ＤＳＦ＝０の場合
・ ＤＳＫの前半を示すために、公開鍵を用いて復号化を実行
・ ＤＳＫの後半を示すために、電子メールメッセージを開く
・ 鍵入力のためにアプレットを開く
● 両方の半分、およびＯｐｅｎＩＤを、アプレットフィールドに入力（ＯｐｅｎＩＤ、ＤＳＫの前半、ＤＳＫの後半、ＤＳＫ全体の入力のためのフォームであり、フォームの表示の際、ＤＳＦ方法に適用可能なもののみ表示（前半および後半がアクティブになるか、ＤＳＫ全体がアクティブになる）
● 「プラグイン鍵」のボタンをクリックする（またはいくつかの該当する、関連ＵＩテキスト）
・ アプレットが後半を取り、適切な後半が示されるように前半を用いてＭＯＤ１６Ｄを実行する
・ ＤＳＫの前半および後半を結合させ、全体を完成させる
・ 使用のため挿入（クッキー、ファイル、データベース内にＤＳＫ、ＯｐｅｎＩＤを保存−方法？これらは、ＡＨのリスト送信のためのＶＳＵ ＤＳ）
○ ＤＳＦ＝１の場合
・ 指定された電子メールメールボックスで電子メールメッセージを開く
・ 鍵入力のためにアプレットを開く
● ＤＳＫ全体およびＯｐｅｎＩＤをアプレットフィールドに入力（カットアンドペーストを利用可能）
● 「プラグイン鍵」のボタンをクリックする（またはいくつかのＵＩの文字）
● アプレットが、使用のため挿入される（クッキー、ファイル、データベース内にＤＳＫ、ＯｐｅｎＩＤを保存−方法？これらは、ＡＨのリスト送信のためのＶＳＵ ＤＳである）
○ ＤＳＦ＝２の場合
・ ＤＳＫ全体を示すために、公開鍵を用いて復号化を実行
・ 鍵入力のためのアプレットを開く
● 両方の半分、およびＯｐｅｎＩＤを、アプレットフィールドに入力（ＯｐｅｎＩＤ、ＤＳＫの前半、ＤＳＫの後半、ＤＳＫ全体の入力のためのフォームであり、フォームの表示の際、ＤＳＦ方法に適用可能なもののみ表示（前半および後半がアクティブになるか、ＤＳＫ全体がアクティブになる）
● 「プラグイン鍵」のボタンをクリックする（またはいくつかの該当する、関連ＵＩの文字）
・ アプレットが後半を取り、適切な後半が示されるように前半を用いてＭＯＤ１６Ｄを実行する
・ＤＳＫの前半および後半の結合により、全体が完成
・ 使用のために挿入（クッキー、ファイル、データベースにＤＳＫ、ＯｐｅｎＩＤを保存−方法？これらは、ＡＨのリスト送信ではＶＳＵ ＤＳ）
○ 確認メッセージによって、ＴＣＰでＤＳに応答
・ ＤＳＫを用いてＳＳＬＸ−ＥＡ鍵交換を実行し、メッセージ鍵を取得
・ 確認メッセージを暗号化するために、ＡＥＳでメッセージ鍵を使用
● メッセージ形式：「［ＯｐｅｎＩＤ］ ＤＳ ＶＳＵが準備完了！」
・ ＳＳＬＸ−ＥＡ出力（ＯｐｅｎＩＤ、Ｒ）および暗号文をＤＳに送信
● 確認メッセージのＤＳ復号化（ＤＳ、図４、ステップ５、Ｖ−ＷＳＢ５）
○ 全てのＤＳＦ値（０、１、２）
・ ＤＳＫ（送信されたＯｐｅｎＩＤによって表示される）を用いてＳＳＬＸ−ＥＡ鍵交換を実行、メッセージ鍵を示す
・ 確認を復号化するためにＡＥＳでメッセージ鍵を使用
・ メッセージのＯｐｅｎＩＤがヘッダーのＯｐｅｎＩＤと一致する場合には、確認
● 一致しない場合には、拒否メッセージを送信し、拒否された場合にはブラウザ／サーバのみが受信
● Ｙｅｓの場合には、ドメイン名、ＩＰアドレス、ＯｐｅｎＩＤ、ＤＳＫ、電子メールアドレスを保存
● ［オプション］ＤＳ拒否メッセージ（ＤＳ、図４、ステップ６、Ｖ−ＤＳ６）
○ ブラウザまたはサーバがＤＳ拒否メッセージを受信する場合には、ＤＳＫは正しくなく、ＶＳＵプロセスは失敗した
○ ＤＳ拒否メッセージは公開鍵でラップして送信される
・ メッセージ形式：「［ＯｐｅｎＩＤ］ ＤＳ ＶＳＵが失敗しました！」
・ メッセージを示すために、公開鍵ＤＳ拒否メッセージを復号化
● ［オプション］ウェブサーバ／ブラウザは、保存されたＤＳＫおよびＯｐｅｎＩＤ情報を削除（ブラウザ／サーバ、図４、ステップ７、Ｖ−ＤＳ７）
・ 保存されたＤＳＫ、ＯｐｅｎＩＤを削除（クッキー、ファイル、データベース入力において−方法？）
・ ユーザにＶＳＵの失敗を通知
（ＳＳＬＸ埋め込み認証の説明）
ＳＳＬＸは、関係者の間に認証されかつセキュアなチャネルを作成するために、従来の通信アーキテクチャおよびプロセスを使用する。ＳＳＬＸ通信ルーティングのための全体的な基本は各セキュアな通信のスピードおよびタイミングであるため、認証および暗号化の方法が任意の公開ネットワークユーザのためにリアルタイムで実行可能であることが必須である。容認可能な電子的暗号には、リアルタイムで暗号化可能な、高度な暗号標準（ＡＥＳ）を含む。現在、必要なリアルタイムスピードで実行できる認証メカニズムは存在しない。ＳＳＬＸを実現させるために、以下のような新しい埋め込み認証技術が用いられる。

ＳＳＬＸ埋め込み認証（ＳＳＬＸ−ＥＡ）アルゴリズムは、２つの部分、すなわち、認証のための部分および暗号のための部分から成る。認証は２つの新しい高速かつ単純な低レベルの機能（結合および抽出）を用いて実行され、非明示的に実行される（埋め込み）。受信者が暗号文を有効な平文（ウェブページまたはファイル伝送等のｈｔｔｐトラフィック通信）に復号化する場合には、受信者は、正しい送信者からメッセージが来たと安全に想定することができる。典型的な暗号機能は、抽出の低レベルの機能によってメッセージ鍵として作成された子鍵を用いて、ストリームモードのＡＥＳ−ｎビットを含んでおり、ここで、ｎビットは開始する共有鍵、Ｋ_１の定義された長さである。

以下のプロセスは、ＳＳＬＸ−ＥＡについて説明するものであり、
０．一度のみのセットアップ： 共有されたｎビット鍵、Ｋ_１を確立する。［ＳＳＬＸは、公開鍵方法および帯域外配信を含む、上記に述べているように、種々の手段によってこれを実行する。秘密は、関係者（ブラウザおよびサーバ）および信頼できるサードパーティ（ＤＳ）の間で確立された鍵である。この鍵は、ディレクトリサービス鍵（ＤＳＫ）と呼ばれる］。
１．ｎビットのランダムの１６進数（１２８ビットのための３２ ４ビットの番号）、Ｒを生成する。
● Ｒは業界標準の乱数生成器／生成技術／プロセスによって生じる。
２．ＲとＫ_１を結合させると、ｎビットの「アルファベット」Ａが生成される。
３．Ｋ_１を用いて、Ａからｎビットのメッセージ鍵Ｗを抽出する。
４．平文メッセージｍの暗号化： 送信者は暗号文Ｃ＝Ｅ（ｗ_ｉ，ｍ）を計算し、ここでＥはストリームモードにおけるＡＥＳ−ｎビットであり、以下のメッセージ、
● ＯｐｅｎＩＤＳｅｎｄｅｒ，Ｒ，Ｃ，［オプションでＴ］
を、受信者に送信する。ＯｐｅｎＩＤＳｅｎｄｅｒは送信者の公的に公知の識別子であり、Ｔは、メッセージ全体の復号化の前の、迅速な復号化認証チェックの目的で、暗号文の開始におけるオプションのｎビットトークンである（静的な事前割り当てされたトークン、ＡからのＷの全体的または部分的な抽出、またはいくつかのその他の共有された値）。

ＳＳＬＸ−ＥＡは、ＳＳＬＸ関係者の間に単純および高速な認証および暗号を提供する。これによって、無作為性（ステップ０および１）、組み合わせおよび抽出機能における情報の大きなおよび十分な損失（ステップ２および３）、および最良実施例の業界標準暗号化（ステップ４）が組み合わせられる。

ＳＳＬＸ−ＥＡの代替とすることが可能な、多くの異なる利用可能なアルゴリズムが存在するが、より高速、目的にかなっている、または簡単で計算能力的にコストのかからないものはない。

（ＳＳＬＸ−ＥＡの低レベルの暗号化機能）
結合機能（ステップ２）の詳細は、
２．結合機能の詳細： ＲおよびＫ_１を組み合わせることにより、ｎビットの「アルファベット」Ａが生じる。そのステップは、
２．１ １番目の桁位置で開始されるＲへ、Ｋ_１の１番目の桁をポインタとして使用し、Ｒの開始位置が０番目の値位置である場合に、桁位置のＫ_１の値を、Ｒの右側に移動させることにより、Ｒの桁を選択し、
２．２ １番目の桁位置で始まるＫ_１へ、Ｒの１番目の桁をポインタとして使用し、Ｋ_１の開始位置が０番目の値位置である場合に、桁位置のＲの値をＫ_１の右側に移動させて、Ｋ_１の桁を選択し、
２．３ １６進数はステップ２．１から選択したＲ桁およびステップ２．２からのＫ_１桁を桁上げせずに加算すると、この和は、結果の数、Ａの第１の桁であり、
２．４ ステップの開始桁が以前選択した桁の右側の位置（０番目の値位置）である場合に、次の桁をＲおよびＫ_１の右側に使用して、２．１、２．２および２．３を繰り返す。結果ＡがＲおよびＫ_１と同じ長さになるまで続ける（ｎビット、１２８ビットでは３２個の４ビット１６進数の数）。

実施例：
Ｒ_１＝０１２３４５６７８９ Ｋ_１＝９８７６５４３２１０
２．１： ９、Ｋ_１からの９を使用、Ｒで９を選択
２．２： ９、Ｒからの０を使用、Ｋ_１で９を選択
２．３： （９＋９）Ｍｏｄ１６＝２から、最初の桁は２
２．１： ８を取り、Ｋ_１からの８を使い、以前選択した最後の桁（９）の右側の第１の桁位置である、１番目の位置で開始したＲに８を選択することを繰り返す
２．２： ７、Ｒからの１を使い、以前選択した第１の桁（９）の右側の第１の桁位置である、２番目の位置で開始したＫ_１に７を選択することを繰り返す
２．３： 第２の桁は、（８＋７）Ｍｏｄ１６＝ＦからのＦ
Ｋ_１の最後に達するまでこれを継続すると、
（９＋９）ＭＯＤ１６＝２
（８＋７）ＭＯＤ１６＝Ｆ
（６＋４）ＭＯＤ１６＝Ａ
（３＋０）ＭＯＤ１６＝３
（９＋５）ＭＯＤ１６＝Ｅ
（４＋９）ＭＯＤ１６＝Ｄ
（８＋２）ＭＯＤ１６＝Ａ
（１＋４）ＭＯＤ１６＝５
（３＋５）ＭＯＤ１６＝８
（４＋５）ＭＯＤ１６＝９
から
Ａ＝２ＦＡ３ＥＤＡ５８９
となる。

抽出機能（ステップ３）の詳細は、
３．抽出機能の詳細： ｎビットの鍵Ｗを、ＡからＫ_１を用いて抽出する。そのステップは、
３．１ １番目の桁の位置で始まるＡへ、Ｋ_１の１番目の桁をポインタとして使用し、Ａの開始位置が０番目の値の位置である場合に、Ａの右側の桁位置にＫ_１の値を移動させることによって、Ａの桁を選択し、
３．２ 選択したＡの桁を結果番号、Ｗの最初の桁として使用し、
３．３ Ｋ_１の右側の次の桁、および、以前選択した桁の右側のある位置（およびこれは０番目の値位置である）としてＡの開始桁を用いて、３．１および３．２を繰り返す。結果ＷがＫ_１およびＡと同じ長さになるまで続ける（ｎビット、１２８ビットでは３２個の４ビット１６進数の数）。

実施例：
Ａ＝２ＦＡ３ＥＤＡ５８９およびＫ_１＝９８７６５４３２１０を使用すると、Ｗ＝９８Ａ３９Ｅ８Ｆ３Ｅとなる。
注： 全てゼロ（０）の公知の脆弱な鍵（Ｋ_１）は、ＡおよびＷがＲと同じになるため避けるべきである。

（基準の実装）
以下の記載は、２つのＳＳＬＸ−ＥＡ機能、および暗号化または復号化モードのいずれかでＳＳＬＸ−ＥＡを実行する単一の呼び出し機能全体のための、Ｖｉｓｕａｌ Ｂａｓｉｃのコードである。それは、

である。

（セキュアソケットレイヤ／トランスポートレイヤのセキュリティ（ＳＳＬ／ＴＬＳ）との比較）
ＳＳＬＸは、ＳＳＬ／ＴＬＳと同じ目標を達成する。インターネット等と同じ実施例のアーキテクチャのいくつかを含む、認証およびデータセキュリティである。ＳＳＬＸを利用する利点の１つは、ＳＳＬＸは同じ目的を達成するが、より少ないステップでこれを行うということであり、このより単純なステップではデータおよび計算の要求事項が低い。以下に、ＳＳＬ／ＴＬＳおよびＳＳＬＸの間の明確な違いを示す。

ＳＳＬＸセッションフローの後には一般的なＴＣＰセッションフローが続き、ＳＳＬＸは、異なる呼び出し構文を使用する。例えば、図５および図６を参照されたい。ＳＳＬＸにおいて、証明書は存在せず、ＡＥＳは暗号モジュールとなっている。従って、ＳＳＬフローのステップ２、９および１０は不要である。

ステップ５および６はＳＳＬの「通常の動作」であり、これはＳＳＬＸにおいてはステップ３および４で置換えられ、セッション鍵（メッセージ鍵）を定義するためにハンドシェイクを使用し、次に、ブラウザおよびサーバの間を両方向で送信するためにコンテンツを暗号化する。主な相違は、ＳＳＬにおいて、認証はハンドシェイクにおいて一度のみ実行されるということである。ＳＳＬＸセッションにおいて、ステップ４は、各セッションに一回、認証されたＳＳＬＸ−ＥＡ鍵交換を含み、これは各伝達と同じ長さに定義可能である。

ＳＳＬおよびＳＳＬＸハンドシェイク図７および８を比較すると、ＳＳＬＸバージョンは、より少ないステップおよびより低い計算要件を有する。ＳＳＬでは、ブラウザ証明書を含み、既に複雑なハンドシェイクをより複雑にするハンドシェイクのバージョンが存在する。

ＳＳＬハンドシェイクのステップ３は、計算面でいうと非常にコストがかさむものである。Ｈｅｌｌｏシーケンスのサインされたメッセージのダイジェストは、ブラウザ送信されたダイジェストと比較するために計算される。これらのダイジェストおよび証明書において通過する情報量も大量である（３ＫＢ以上）。比較すると、ＳＳＬＸの計算は、計算能力および帯域幅の要件（２５６ビット）の１０パーセント未満である。

最後のＳＳＬセッションフローは、再開されたセッションハンドシェイク、図９である。ＳＳＬにおいて、これは、最後のＳＳＬ情報をキャッシュするブラウザおよびサーバの両方が相互作用を短縮することを必要とする。その理由は、新しいハンドシェイクがあまりに高い計算能力を必要とするからである。再開されたセッションＳＳＬハンドシェイクでさえ、単純な新しいＳＳＬＸ認証ハンドシェイクよりも多くの労力を必要とするため、ＳＳＬＸはこのフローを複製する必要はなく、２つのセキュリティを比較できない（図１０を参照）。ＳＳＬで再開されたセッションハンドシェイクのキャッシュは非常に深刻なセキュリティ上の不利益であるが、新しいＳＳＬＸ認証ハンドシェイクはそうでない。

（データエレメントの定義および用語解説）
ＳＳＬＸ−ＥＡ セッションマスタ鍵（ＳＭＫ）−ブラウザおよびサーバの間で用いられるＳＳＬＸ−ＥＡの２５６ビットＫ１鍵値（詳細についてはＳＳＬＸ−ＥＡを参照）。

ＯｐｅｎＩＤ−セッションＩＤと類似している。セッション毎または長期に割り当てられたオープンランダム１６桁の１６進数の数（ブラウザおよびサーバコンポーネントを識別するために使用）。

鍵配信センター（ＫＤＣ）−少なくともＯｐｅｎＩＤおよび関連付けられたＳＳＬＸ−ＥＡ ＳＭＫを保持するために定義された、ＳＳＬＸ−ＥＡ鍵のデータストア。

ＨＴＴＰＸ：／／−ＳＳＬＸプロトコル。

認証ハンドシェイク（ＡＨ）−ウェブサイト（サーバ）の識別子をチェックおよび検証（点検）できる方法である。このプロセスは、互いに「不明」であるブラウザおよびサーバのセキュアな通信チャネルを確立する。

通常の動作（信頼できる）−（ＡＨまたはＳＳＬＸ鍵の帯域外配信のいずれかによって）信頼できる、鍵をかけられた関係を確立後に、ブラウザおよびサーバがセキュアに通信するプロセス。

認証リクエスト（ＡＲ）−ブラウザからウェブサイトサーバに送信される認証ハンドシェイクの開始。これは、ＳＳＦ、ブラウザ生成された公開鍵、ディレクトリサービス／サーバのＩＤ等を含む、いくつかのオプションの情報を含む。

セキュリティ設定フラグ（ＳＳＦ）−認証ハンドシェイク（高、中、低）のブラウザの構成セットのセキュリティレベルを示すＡＲ内に送信されるコード値。各ＳＳＦコードで異なるオプションが存在し、サーバおよびＤＳの両方からの応答方法を示す。

検証されたセットアップ（ＶＳＵ）−信頼できるサードパーティ検証のために、ディレクトリサービス／サーバ（ＤＳ）に対して、ブラウザおよびサーバが電子的ＩＤを検証（点検）するプロセス。これは一度のみのアクションであり、既に検証されている任意のＤＳにおけるリセットと同様、複数のＤＳで実行可能である。各サーバは、任意の公開ＤＳまたはＣＤＳに対して少なくとも１つのＶＳＵを実行する必要があり、ブラウザは、所望の場合には、このプロセスを実行可能である。

検証されたセットアップリクエスト（ＶＳＵＲ）−特定のＤＳへのＶＳＵプロセスを開始するブラウザまたはウェブサーバからの初期のＴＣＰリクエスト。

ディレクトリサービス／サーバ（ＤＳ）−ブラウザがウェブサーバを検証および識別（従って、信頼）できる、信頼できるスイッチとして機能する公開エンティティ。ＳＳＬＸ公開アドミニストレータによって保守および割り当てられた任意の数のＤＳが存在してもよい。

ＤＳリクエスト（ＤＳＲ）−ブラウザによってＤＳに送信される、認証ハンドシェイク（ＡＨ）を完了させる初期のＴＣＰリクエスト。

ＤＳフラグコード（ＤＳＦ）−ＶＳＵの処理（高、中、低）のために、ブラウザの構成セットのセキュリティレベルを示すＶＳＵＲ内に送信されるコード値。各ＤＳＦコードで異なるオプションが存在し、ＤＳからの応答方法を示す。

ＤＳ鍵（ＤＳＫ）−ブラウザまたはサーバおよび（ＶＳＵ中に取得された）ＤＳの間で用いられる、ＳＳＬＸ−ＥＡの２５６ビットのＫ１鍵の値。

ＳＳＬＸ公開アドミニストレータ（ＰＡ）−全てのＤＳから独立した管理者であり、ＤＳの順守のためのポリシーおよび手続きと同様に、公開ＤＳのリストの保守を行う。

Claims (36)

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. 前記確認メッセージを前記信頼できるサードパーティによって復号化するステップであって、
    該確認メッセージが適正に復号化されない場合には、該信頼できるサードパーティは、前記公開鍵によって暗号化された拒否メッセージを送信し、
    該拒否メッセージを前記コンピュータによって復号化し、検証されたセットアップリストから該信頼できるサードパーティを削除する、
    ステップをさらに包含する、請求項２８に記載の方法。
35. 前記信頼できる鍵を受信した後、前記コンピュータは、１つ以上の関連付けられた信頼できる鍵と共に、該コンピュータが信頼できる鍵を受信した全ての信頼できるサードパーティのリストを維持し、認証プロセスの間に別のコンピュータとの情報交換の際に、該別のコンピュータへのメッセージに該リストを含める、請求項２８に記載の方法。
36. ネットワークを介してセキュアに通信するコンピュータの間の信頼できる仲介者として機能するための装置であって、
    サーバと、
    該サーバに連結されて、関連する情報を格納し、任意の特定のディレクトリメンバーとセキュアに通信するデータベースであって、該関連する情報は、各特定のディレクトリメンバーに関連付けられたディレクトリサービス鍵を含む、データベースと、
    該サーバに関連付けられた公知の静的ＩＰアドレスと、
    該サーバ上で実行されるアプリケーションと
    を備え、
    該サーバは、リアルタイムリクエストをブラウザからウェブサーバに経路指定し、かつ応答をウェブサーバからブラウザに経路指定し、
    該リクエストおよび応答は、リクエスト実行者が、該サーバとの検証されたセットアップを実行した場合には、該リクエスト実行者が生成した公開鍵またはＳＳＬＸ−ＥＡ交換において信頼できる鍵によって保障されており、
    該応答のそれぞれは、該リクエスト実行者が組み合わせ、そして該応答のそれぞれとウェブ接続された場所とが同一であることを検証するための情報の一部分だけを含み、
    情報の残りの部分は、該情報の残りの部分を暗号化するために、リクエスト実行者が生成した公開鍵を用いて、該ウェブサイトから該リクエスト実行者に直接提供される、
    装置。

Images