JP5602165B2 - ネットワーク通信を保護する方法および装置 - Google Patents

Description

本発明は、ネットワーク通信を保護する方法および装置に関する。特に、本発明は、それに限られるものではないが、コンピュータネットワークまたは相互ネットワークを使用する通信に関するものである。

ネットワーク要素（例えば、インターネットサーバ等のようなサーバ）への安全なネットワークアクセスを提供する最も一般的な方法の一つは、“認証”によるものである。これは、所与のネットワーク要素へのアクセスを特定のユーザ（人またはネットワーク要素／アプリケーション）のみに提供することを目的としている。簡単な例は、ユーザのログインおよびパスワードの要求である。この方法は、パスワードが発行されたユーザのみがパスワードを使用することができ、そのような使用が正真正銘であるに違いないという前提に基づくものである。パスワードを違法に取得または使用することは簡単なことであるので、この方法は、低レベルのセキュリティしか提供することができない。

代替的な方法としては、例えば、ユーザのウェブブラウザ等にインストールされたクライアント証明書を使用してユーザの認証を行うクライアント認証がある。正しい証明書の認証情報を持つユーザのみが、クライアント認証方法を用いて、ネットワーク要素へのアクセスの許可を受けることができる。

クライアント証明書は、一般に、認証機関として知られている信頼できる第三者機関（ＴＴＰ）により発行され、この第三者機関が、証明書の申請者が信頼できるかどうかを確認する。信頼できる場合には、証明書が申請者に発行される。このため、認証機関は、ユーザに証明書を発行する前に十分にユーザの認証を行うことが期待されている。これは、クライアント認証に頼るネットワーク要素が、証明書の所有者（クライアント）を認証するために、それらに提示された証明書の有効性を検査するだけでよく、所有者自身を認証する必要がないことを意味している。

このため、証明書は、アクセスの付与前にクライアント認証が必要なネットワーク要素を探すときに、ユーザがそうであると主張する人／ものであることを検証するために、クライアントによって使用される。しかしながら、証明書は他の人の手に入る可能性もあるし、あるいは何らかの方法で違法に変更される可能性もある。

ネットワークシステムは、一般的には、安全なチャネルを確立して、ネットワーク要素がユーザに送信または要求される情報の保護を可能にするために、私的および公的証明書を維持する必要がある。このため、ネットワーク要素は、任意のユーザとのセキュリティ関係を管理して、典型的には、発行者（publisher）に接続するブラウザの種類（またはクライアントソフトウェア）、公的セキュリティ証明書の詳細情報、証明書承認の詳細情報およびクライアントがサポートできるセキュリティレベルを含む、ユーザ機器に関する詳細情報を知っていないければならない。

ユーザ／クライアントは、多くの場合、アクセスを希望するネットワーク要素との関係を確立しなればならず、また多くのシステムが、この関係を確立するために、ユーザがネットワーク要素に‘ログイン’することを要求する。モバイルインターネットシステムにおいては、例えば、不要なステップの導入が、多くの場合、発行者の潜在的な顧客の損失に繋がる。

本発明は、これら問題の１またはそれ以上に対処するために使用できる手段および方法を提供することを目的とする。

最も一般的には、提案する発明は、通信の発信源から直接（例えば、対象とする受信者に対して発信源によって提供される証明書）ではなく、むしろ別個の信頼できる第三者機関（ＴＴＰ）からのように独立および個別に、ネットワーク通信の受取人または受信者に対する真正性の検証（verification of authenticity）を提供する手段および方法である。最も好ましくは、真正性の検証は、発信源が対象とする受信者と通信することができない通信ルート／パスを経由して、例えば、ＴＴＰから、ネットワーク通信の受取人または受信者に伝達されるか、あるいはその伝達のための手段が設けられる。発信源および／または受信者／受取人は、ＴＴＰに、発信源により（例えば、前もって、同時期に、同時に、またはその後に送信されるように）受信者／受取人に送信される通信の真正性の検証を発するようにリクエストを送信することができる。最も好ましくは、通信は、ネットワーク通信の発信源の検証に基づいて、例えば、ＴＴＰにより対象とする受信者に発行された情報を使用するだけで、対象とする受信者のみによって復号できるように暗号化することができる。

このように、本発明は、通信の真正性または通信ネットワーク要素の正体を能動的および同時に証明する認証装置（verifier）を提供することができる。本発明は、公証人が物理的な署名を検証する際に実行する機能と同等のデジタルの機能を提供することができる。

第１態様において、本発明は、第１ネットワーク要素から第２ネットワーク要素に通信ネットワークを介して送信される通信の真正性を検証する認証装置であって、第１ネットワーク要素から暗号化通信を通信ネットワークを介して受信するように構成された入力手段と、第１ネットワーク要素と関連する鍵を用いて復号される暗号化通信を当該認証装置が検証したという条件で、前記鍵を第２ネットワーク要素に発行して、当該認証装置とは無関係に送信された第１ネットワーク要素からの暗号化通信を第２ネットワーク要素が復号することを可能にするように機能する鍵手段（key means）とを含む認証装置を提供することができる。

好ましくは、認証装置は、第１ネットワーク要素に関連しているものとして鍵を識別する識別子を第２ネットワーク要素に伝達するように機能する。

好ましくは、第１ネットワーク要素からの暗号化通信は、第２ネットワーク要素とは無関係に認証装置によって受信される。好ましくは、第２ネットワーク要素は、第１要素から受信した通信（例えば、暗号化された）に応答して、第１要素から受信した通信の真正性の検証のリクエストを認証装置に送信する。このように、最も好ましくは、第１および第２要素は、相前後して認証装置に通信を送信することができる。代替的には、第２ネットワーク要素は、すぐに応答するものではなく、認証装置からの検証の受信を、それを探すことなく、待つことができる。

このように、第１ネットワーク要素が、認証を与えて第１ネットワーク要素とは無関係に（例えば、第１ネットワーク要素に関連しないネットワークパス／チャネルを介して）認証を与えてその認証を第２ネットワーク要素に伝えるように、独立要素（認証装置、例えばＴＴＰ）を起動すること、または独立要素に要求することにより、高度のセキュリティを実現することができる。

第２要素は、第１ネットワーク要素からの暗号化通信の受信に応答して、暗号化された形式で通信を保持、記憶または維持して（例えば、復号を延期するか、またはそのときに試みて）、通信の復号に必要な鍵の認証装置からの受信を待つことができる。第２要素は、認証装置からの鍵の受信に応答して、第１ネットワーク要素から受信した記憶された暗号化メッセージを復号することができる。

ウェブセキュリティマネージャは、望ましくは、ネットワーク要素識別子を含む認証装置から鍵を受け取る。

第２ネットワーク要素は、例えば、ウェブセキュリティマネージャ、ネットワークマネージャ要素またはノード等である場合がある。第１ネットワーク要素は、ネットワークを介して、第２要素と通信すること、または第２要素との通信チャネルを要求するように機能するネットワーク／ウェブブラウザ・アプリケーションを含む要素である場合がある。認証装置は、第１要素から暗号化通信を受信し、記憶した鍵を使用して、そのような通信を復号することができることを検証する認証部またはユニットと、鍵を発行するようにとの認証ユニットからのコマンドに応答して、それを実行するセキュリティサーバ手段とを備えることができる。セキュリティサーバ手段は、別個であるか、あるいはそれとの間の通信チャネルにより認証部から分離することができる。認証装置とセキュリティサーバとの間の通信／コマンドは、暗号化するようにしてもよい。通信チャネルは、第１態様における本発明に係る第２認証装置を含むことができ、この第２認証装置は、認証装置からセキュリティサーバへの通信を当該第２認証装置により独立に検証しなければならないように、構成されている。この後の実施例では、認証装置が第１ネットワーク要素を示し、セキュリティサーバが第２ネットワーク要素を示している。

第１要素から第２要素までの暗号化通信は、ウェブ／ネットワーク・データマネージャまたはウェブ／ネットワーク・サービスプロバイダのような第３ネットワーク要素を対象とする通信／メッセージなどを含むことができる。第２ネットワーク要素は、暗号化された形式で、第１ネットワーク要素から受信したメッセージのその先への通信を可能にする／提供するように構成されており、上記メッセージは、ネットワークを介してメッセージの意図する宛先に、認証装置により与えられた鍵を使用して、復号される。

認証装置は、暗号化通信の受信前に記憶された１またはそれ以上の鍵を使用して、受信した暗号化通信の復号を試みて、１またはそれ以上の記憶された鍵の中から発行する鍵を選択するように、構成することができる。

認証装置は、第１ネットワーク要素からの暗号化通信の真正性を検証するために、第２ネットワーク要素からのリクエストに応じて、第２ネットワーク要素に鍵を条件付きで発行する機能または追加機能を果たすものであってもよい。さらに、認証装置は、第１ネットワーク要素を識別する第１識別データを暗号化通信で受信し、検証リクエストの対象であるネットワーク要素を識別する第２識別データを第２ネットワーク要素から受信し、第１識別データを第２識別データと比較し、その比較が識別データの一致を見せることを条件に鍵を発行するように構成されている。

認証装置は、第１ネットワーク要素に関連するように、第２ネットワーク要素に発行される鍵を、第２ネットワーク要素により識別可能とするように構成することができる。例えば、ブラウザ識別子などのようなネットワーク要素識別子の使用は、この目的を達成するために採用することができる。

鍵手段は、第２ネットワーク要素および第１ネットワーク要素によりその後の両者間の暗号化通信で使用するための第２鍵を第２ネットワーク要素に発行するように構成することができる。第２ネットワーク要素は、第１ネットワーク要素に第２鍵を伝送するように構成することができる。

鍵手段は、認証装置に伝送するその後の通信の暗号化に使用するための、第１ネットワーク要素に関連する第３鍵を第２ネットワーク要素に発行するように構成することができる。第２ネットワーク要素は、第１ネットワーク要素に第３鍵を伝送するように構成することができる。

認証装置は、第１ネットワーク要素からの鍵リクエストに応じて鍵を生成し、認証装置および第２ネットワーク要素への通信を暗号化する際に使用するための要求された鍵を第１ネットワーク要素に伝送するように構成することができる。

認証装置は、鍵リクエストが与えられた第１ネットワーク要素と関連する認証情報に基づいて鍵を生成するように構成することができる。例えば、より高レベルの暗号化（例えば、ビット数）または様々な種類の暗号化は、ネットワーク要素ＩＤ、ブラウザＩＤ、ユーザＩＤ、およびネットワーク要素の位置（例えば、ネットワーク位置）の中から選択される１またはそれ以上の認証情報に基づいて、鍵を生成するために用いることができる。

第２態様において、本発明は、第１態様における本発明に関連して上述した認証装置を含む通信ネットワークを提供することができる。

通信ネットワークは、第１識別データを生成するように構成された第１ネットワーク要素を含むことができる。

第１ネットワーク要素は、鍵を含むことができ、認証装置および第２ネットワーク要素との通信を暗号化するように構成することができる。

通信ネットワークは、第１ネットワーク要素からの暗号化された通信に応答して、暗号化通信の真正性を検証するようにリクエストを認証装置に発行するように構成された第２ネットワーク要素を含むことができる。

第１ネットワーク要素は、第１ネットワーク要素を識別する第１識別データを前述した暗号化通信で発行するように構成することができる。

第２ネットワーク要素は、検証リクエストの対象であるネットワーク要素を識別する第２識別データを検証リクエストで発行するように構成することができる。

第２ネットワーク要素は、第１ネットワーク要素との暗号化通信において第２ネットワーク要素により使用される第２鍵を、認証装置から受信するように構成することができる。

第２ネットワーク要素は、第１ネットワーク要素から認証装置に送信するその後の通信を暗号化する際に使用するための、第１ネットワーク要素と関連する第３鍵を、認証装置から受信して、第１ネットワーク要素に発行するように構成することができる。

第１ネットワーク要素は、認証装置および第２ネットワーク要素への通信を暗号化する際に使用するための鍵を生成するようにリクエストを認証装置に発行するように機能することができる。

第１ネットワーク要素は、第１ネットワーク要素に関連する１またはそれ以上の認証情報を鍵生成リクエストで発行するように構成することができる。

第３態様において、本発明は、第１ネットワーク要素から第２ネットワーク要素に通信ネットワークを介して送信される通信の真正性を検証する方法であって、通信ネットワークを介して第１ネットワーク要素から送信される暗号化通信を認証装置で受信するステップと、第１ネットワーク要素に関連する鍵を使用して、暗号化通信が復号可能であることを認証装置で検証するステップと、第２ネットワーク要素に前記鍵を発行して、認証装置とは無関係に送信された第１ネットワーク要素からの暗号化通信を第２ネットワーク要素が復号することを可能にするステップとを含む方法を提供することができる。

この方法は、認証装置で１またはそれ以上の鍵を記憶して、受信した暗号化通信の復号を試みるステップと、１またはそれ以上の鍵の中から発行された鍵を選択するステップとを含むことができる。

この方法は、第２ネットワーク要素からのリクエストに応じて第２ネットワーク要素に鍵を条件付きで発行し、第１ネットワーク要素からの暗号化通信の真正性を検証するステップを含むことができる。

この方法は、第１ネットワーク要素を識別する第１識別データを暗号化通信で受信するステップと、検証リクエストの対象であるネットワーク要素を識別する第２識別データを第２ネットワーク要素から認証装置で受信するステップと、第１識別データを認証装置で第２識別データと比較するステップと、その比較の結果として識別データが一致した場合に鍵を発行するステップとを含むことができる。

この方法は、第１ネットワーク要素に関連するように、第２ネットワーク要素に発行される鍵を識別可能とするステップを含むことができる。

この方法は、認証装置からの第２鍵を第２ネットワーク要素に発行するステップと、その後の第２ネットワーク要素および第１ネットワーク要素間の暗号化通信において、第２ネットワーク要素および第１ネットワーク要素で第２鍵を使用するステップとを含むことができる。

この方法は、第１ネットワーク要素に関連する第３鍵を認証装置から第２ネットワーク要素に発行するステップと、認証装置に伝送するその後の通信の暗号化に第３鍵を使用するステップとを含むことができる。

この方法は、第１ネットワーク要素からの鍵リクエストに応答して認証装置で鍵を生成するステップと、認証装置および第２ネットワーク要素への通信を暗号化する際に使用するための鍵を第１ネットワーク要素に伝送するステップとを含むことができる。

この方法は、鍵リクエストが与えられた第１ネットワーク要素と関連する認証情報に基づいて鍵を生成するステップを含むことができる。

本発明の例示的で非限定的な実施形態を、次の厳選された図面を参照して以下に説明する。それら図面において、同様の符号は同様の構成を指している。
図１は、ウェブサービスプロバイダと、ネットワークセキュリティシステムを介してそれに接続されるユーザとを概略的に示している。 図２は、ブラウザ、ウェブセキュリティマネージャおよびウェブデータマネージャが通信しているところを概略的に示している。 図３は、認証装置主導の登録ステップを概略的に示している。 図４は、図３に示す装置のトポロジを概略的に示している。 図５は、プラグイン構造を概略的に示している。 図６は、顧客登録プロセスを示している。

図１は、本発明の実施形態の図表示を示している。情報発行者（１０００）は、ユーザ（２０００）に公開情報（１）を、直接的にまたはネットワーク化されたセキュリティシステムを介したユーザリクエスト（２）の結果として、提供する。ネットワーク化されたセキュリティシステムは、公開情報（１）をユーザ（２０００）による消費に適した形式の情報（３）に変換する。これに関連して、“ユーザ”という用語は、発行者により提供される情報を使用する可能性のある個人またはシステムを含む。

後でより詳細に説明するように、本発明の実施形態は、インターネットユーザがブラウザを使用して安全な‘フロントエンド’サーバの背後に存在する保護されたリソースにアクセスするようなインターネット通信を保護するように構成することができる。広範な実施においては、本発明の実施形態は、２つの同時ネットワーク接続を生成することができる任意の構成要素であって、例えば、後述する２層構造のセキュリティモデルにおけるような通信データを暗号化および復号するのに十分な処理能力を有する任意の構成要素に適用することができる。

図２は、証明書の必要性を完全に取り除く本発明の実施形態の一例を示している。

認証装置（認証ユニット２０およびセキュリティサーバ４０）が示されており、この認証装置は、第１ネットワーク要素（ブラウザ１０）から第２ネットワーク要素（ウェブセキュリティマネージャ３０）に通信ネットワークを介して送信される通信の真正性を検証するためのもので、通信ネットワークを介して、第１ネットワーク要素（ブラウザ１０）から暗号化された通信（１１０）を受信するように構成された認証ユニット（２０）の形態の入力手段を含む。認証装置のセキュリティサーバは、認証ユニットが鍵を使用して復号可能である暗号化通信（１１０）を検証したという条件で、第１ネットワーク要素（ブラウザ１０）に関連する鍵を第２ネットワーク要素（ウェブセキュリティマネージャ３０）に発行し、それにより認証装置とは無関係に送信される第１ネットワーク要素（ブラウザ）からの暗号化通信を第２ネットワーク要素（ウェブセキュリティマネージャ）が復号することを可能にする鍵手段を提供する。

ウェブまたはネットワークブラウザ装置（１０）は、データコンテナ５００を介して２つの同時の暗号化通信のリクエスト（１００が１１０および１２０になる）を発するように構成され、その一方はウェブまたはネットワークセキュリティマネージャ装置（３０）に、他方は認証装置ユニット（２０）にそれぞれ発せられ、各々がウェブおよび／またはネットワーク接続を介してブラウザにリンクされている。

ウェブセキュリティマネージャは、暗号化されたリクエスト（１２０）に応答して、最初に、ロックリクエスト（１３０）をロックコードストア（５２０）に格納することにより、リクエストを単に記憶する。それは、入力したリクエストを復号する情報が不十分であるからである。

認証ユニット（２０）は、暗号化通信リクエストに応答して、ブラウザ（１０）に関連する予め記憶した鍵を使用して入力リクエスト（１１０）を復号することにより、ブラウザ（１０）およびユーザ（２０００）の身元を確認するように構成されている。

認証ユニット（２０）は、任意には、リクエスト（１１０）を認証リクエスト（２５０）として発行者（１０００）に引き渡すことにより、入力リクエスト（１１０）に一連のビジネスルールを適用することができる。この場合、認証ユニットは、発行者（１０００）から承認（２６０）を得ることができる。これにより、例えば、新規ユーザまたはブラウザの登録が可能になる。

認証ユニット（２０）が認証リクエスト（１１０）の有効性を確認したら、認証ユニット（２０）は、ブラウザ（１０）とウェブセキュリティマネージャ（３０）との間の継続中の通信の暗号化／復号に使用する適当な第１‘新規鍵’を生成するように構成されている。また、認証ユニットは、ブラウザ（１０）が認証ユニット（２０）への接続を確立するように要求される次のときにブラウザが使用する、ブラウザと認証装置との間の通信の暗号化／復号のための第２‘新規鍵’を生成する。認証ユニットは、セキュリティサーバ（４０）に、許可ストア（５１０）を介してこれらの新規鍵を送信するように構成されている。これに加えて、第１および第２‘新規鍵’とともに、認証ユニットは、ブラウザ（１０）からウェブセキュリティマネージャ（３０）に前もって送信された暗号通信リクエストを復号する更なる鍵を、許可ストア（５１０）を介してセキュリティサーバに発行する。

ある場合には、認証ユニット（２０）が、新たに生成された更なる鍵であって、認証装置とブラウザ間の通信を暗号化するために以前に使用された鍵を使用して暗号化された鍵を、ブラウザに（ブラウザ（１０）に直接）送信することができる。

このとき、セキュリティサーバ（４０）は、ユーザリクエスト（２）が既知のユーザ（２０００）および既知のブラウザ（１０）からもたらされたものであり、かつ認証ユニット（２０）がユーザ（２０００）から要求されたリソースへのアクセス権限を有することについて、検証を発することができる。ウェブセキュリティマネージャは、ユーザリクエスト（２）および検証信号の両方またはその一部に付随する共通ブラウザ（１０）ＩＤを使用して、ユーザリクエスト（２）に関連するものとして、認証装置から受信した検証を識別、結合またはリンクさせるように機能する。リクエスト１１０は、ブラウザがウェブセキュリティマネージャと通信することを望んでいることを認証装置に示すが、好ましくは、ウェブセキュリティマネージャに送信されたリクエスト（１００，１２０）の内容に関する情報を含んでいない。後者はブラウザ（１０）ＩＤを含む。認証装置およびウェブセキュリティマネージャへのリクエストはともに、暗号化されていない形態（例えば、プレーンテキスト）のブラウザＩＤを含む。アイテム１３０は、認証装置（２０）から鍵を得るために、ウェブセキュリティマネージャへのリクエスト（１２０）のコピーおよびセキュリティサーバ（４０）へのリクエストを含む。

セキュリティサーバ（４０）が上述するようなユーザリクエストの完全性を検証すると、セキュリティサーバ（４０）は、暗号化通信リクエストを復号するのに必要な鍵を、ロックコードストア（５２０）を介して、ウェブセキュリティマネージャ（３０）に引き渡すように構成されている。暗号化は任意の暗号化方法に基づくものであってもよく、公開鍵暗号または秘密鍵暗号を使用することができる。

ウェブセキュリティマネージャは、ウェブサービスに対するリクエストを伴う従来のウェブベースのトランザクションのようにウェブデータ（５３０）を提供することとなる権限を与えられたデータのリクエスト（２３０，２４０）と、対応するレスポンス（２１０，２２０）として、ウェブデータマネージャ（５０）にユーザリクエスト（２）を後で転送するように機能する。

ウェブデータマネージャ（５０）がそのデータ（５３０）を提供したとき、ウェブセキュリティマネージャ（３０）は、継続中のサービスレベルの暗号化通信のための新規鍵を生成するように機能し、その後、ロックコード（５３０）ストアから取り出した鍵データを使用してこのすべての情報を暗号化する。

ウェブセキュリティマネージャ（３０）は、次に、ユーザ（２０００）に対して情報（３）として提示するための保護されたレスポンスとしてブラウザで復号可能な、ウェブデータマネージャのここで保護（暗号化）されたレスポンス（１９０）を、ブラウザ（１０）に送信するように構成されている。

その後、ブラウザ（１０）は、保護されたレスポンス（２００）を復号して、すべてのデータ（サービスレベルの鍵を含む）を抽出することができる。

ブラウザ（１０）は、認証装置（２０）との通信の確立に使用した元の鍵を、ブラウザ（１０）とウェブセキュリティマネージャ（３０）間の継続中の通信の暗号化および復号に使用するための‘サービスレベル’の鍵に交換することができる。

そのような継続中の通信は、上述したような検証プロセスを経由する必要無しに、ブラウザ（１０）とウェブセキュリティマネージャ（３０）間ですぐに生じさせることができる。

ブラウザまたはセキュリティマネージャは、どの時点であっても、新しい検証リクエストを送信するか、あるいは新規鍵が古いものに取って代わるように暗号化サービスデータ内に新規鍵を送信することにより、継続中のサービス管理に使用される鍵を変更することができる。

ウェブサービスマネージャは、検証プロセス中に規定されたルールを施行することができ、それにより、ビジネスルールまたはタイマーベースの接続管理のようなことが可能になる。

この種のセキュリティモデルの実行により、サービスは、完全に透過的なままの（ユーザの視点から）高レベルのセキュリティを提供することができる。異なるサービスは、異なるレベルのセキュリティを使用することができ、発行者は、セキュリティプロファイルの動的管理を可能にする（例えば、通商停止期間の後に情報またはサービスを自動的に公のものとする）ルールを規定することができる。また、モデルは、セキュリティモデルが最も適切なデータマネージャへのトラフィックを送ることを可能にすることにより、インフラストラクチャマネージャが情報のフローを制御することを可能にする。

上述したシステムに特有の特徴は、例えば、‘ブラウザレベル’の鍵を使用してともに暗号化された２つの独立したリクエストを形成することにある。最初のユーザリクエスト（ログイン詳細を含む）（図２の符号２）は、一旦、認証装置（２０）がユーザの認証情報および接続リクエストの有効性を確認することができたら、新規鍵に後で交換される予め定義された鍵を使用して暗号化される。これは、現在の‘平文’サービス登録におけるセキュリティ脆弱性を取り除く。

このシステムの顕著な特徴は、ブラウザに知られていない独立サービスに対してそのレスポンスを送信する外部検証手段にある。これにより、ブラウザが有効なウェブセキュリティマネージャに接続することが可能になる。ブラウザは、認証装置（２０）とセキュリティサーバ（４０）間のトラフィックを暗号化するのに使用される、あるいはセキュリティサーバ（４０）とウェブセキュリティマネージャ（３０）間で使用される、セキュリティサーバのアドレスまたは鍵の情報を有していないことが望ましい。このため、ブラウザは、望ましくは、ウェブセキュリティマネージャに対するリクエストを‘なりすます’ことはできず、偽の認証装置は、望ましくは、ブラウザ接続を‘なりすます’ことはできない。

システムは、内部要素の通信を保護することもできる。この場合、システムは、例えば、再帰検出方法を利用して無限再帰を防止する認証装置により、それぞれの要素間のすべての通信に適用することができる。これにより、すべての内部通信データの保護が可能になるであろう。

ユーザからのまだ初期のリクエストまたはすべてのリクエストの何れかは、このシステムおよび方法を用いることができる。

事実上、システムは、初期のセキュリティセットアップ（継続中の通信用にサービスレベルの暗号化鍵を提供する、ブラウザレベルの鍵を使用して）、または初期と継続中の両方の接続検証プロセス（ブラウザと継続中の通信の両方が、各リクエストについて鍵を変更する）を可能にする。

ブラウザサービスは、保護チャネルと、ブラウザが理解するフォーマットとの間で、データを変換することができる。上述した実施例は、ブラウザを描いている。しかしながら、本発明の望ましい実施形態は、保護されたデータをブラウザが‘理解する’フォーマットに変換する手段を採用することができる。最も単純な形式では、コンピュータは、必要に応じて安全対策の施された移送ストリームと施されていない移送ストリーム（例えば、標準的なインターネット接続）との間の切替を自動的に行うローカルのプロキシサーバとして、これを使用することができる。

セキュリティモデルは、ビジネスルールを含むことができる。現在のモデルとは異なり、本発明の好ましい実施形態は、セキュリティモデル全体の一部としてビジネスルールを導入する方法を提供する。これにより、例えば、その他のシステムまたはソフトウェアを修正する必要無しに、システムがセキュリティプロファイルを動的に変更することが可能になる。また、これにより、認証装置が、通信の経路を切り替えたり、あるいは個々の発行者により規定されるルールに従ってネットワークアクセスを防止する（例えば、英国のサーバ負荷がある閾値を越える場合に、代わりの米国のウェブデータマネージャにトラフィックを送る）ことも可能になる。これにより、アプリケーションからセキュリティモデルを分離することができ、要素間で暗号化アルゴリズムすらも変更することができる完全にフレキシブルなセキュリティコンテキストを可能にする。

システム／方法を使用するために、ユーザは、保護ネットワークに接続するのに使用されるプロトコル管理要素をシステムにインストールすることができる。この要素は、最も好ましくは、任意のウェブサーバマネージャと通信するために、認証装置に登録することが必要とされる。

登録は、以下の少なくとも３のシナリオの要求を満たす。
（１）ちょうど１の装置を使用して、ちょうど１のユーザが保護ネットワーク１へのアクセスを必要とする場合の個人コンテキストにおける利用（例えば、会社のネットワークに接続するために企業のラップトップを用いる従業員による利用）
（２）個人がサービスにアクセスすることが必要であるが、共有コンピュータを経由する場合の公共利用
（３）ユーザの交流は生じないが、サービスが、内在するネットワークにより運ばれるすべてのデータを暗号化しなければならない場合の機械どうしの通信

上記リストの１番目は、検証プロセスにより、接続装置、ユーザおよび特定サービス間の関係の確立が可能になるため、最高レベルのセキュリティを提供する。これは、接続を確立するのに使用される認証情報が暗号化鍵の一部としてパスワードまたはＰＩＮの使用に依存することができる（ユーザ入力のＰＩＮまたはパスワードと組み合わせて予め記憶された鍵を使用して、認証装置への初期接続を暗号化する）ため、高レベルのセキュリティを提供するものとなる。

２番目は、初期の接続が接続する装置内の予め記憶された鍵に依存して認証装置への初期の接続を確立するため、やや低いセキュリティ基準を提供する。この場合、サービスレベル通信は、データを保護するために、サービスレベルの鍵と組み合わせてユーザ名およびＰＩＮまたはパスワードを使用することができる。

実施例は、登録の３番目の方法のためのセキュリティのレベルを規定することができる。サービスは、例えば、要素間の初期通信を確立するために、アドミニストレータに認証情報を指示することができ、あるいは埋め込まれた構成アイテムを使用して登録認証情報を供給することができる。

上記リストの３つの場合の各々において、認証装置は、ビジネスルールのセット（典型的には発行者により規定される）において、または外部サービス（通常は、発行者または信頼できる第三者機関により操作される、例えば、年齢確認）により、任意のリクエストの承認を基礎として用いることもできる。これにより、認証装置が、必要に応じて要素レベルまたは大域的サイトレベルでルールを構築することが可能になる。この手法により、認証装置が、セキュリティの特定の態様を専門に扱う信頼できる既知の第三者機関との接続を確立して、各登録および任意の後の許可リクエストが発行者により規定されるセキュリティ要件に一致するようにすることが可能になる。

図３は、登録方法の典型的な実施例を示している。本発明の好ましい実施形態の一態様は、発行者が、１またはそれ以上の認証情報をアップロードすることを可能とし、それにより、現存するセキュリティシステムからの容易な移動が可能になる。しかしながら、図３では、ユーザが検証サーバへのリクエストのインスタンスを作成する。この場合、ユーザは、既にインストールされた要素へのアクセスを有し、この要素の伝送に、既存の送信およびインストール方法を利用することができる。

インストーラは、保護された要素のインストール中に、典型的には内在するハードウェア（ディスクドライブ容量識別子またはシリアル番号のような）から集めた詳細情報に基づいて、要素について固有の識別子を生成するように構成されている。インストールされた要素は、例えば、初期の登録データを送信するだけに使用される、１回使用の鍵を含む。

ユーザの認証情報のセット（典型的には、ユーザ名およびパスワード）を提供した後に、インストールされた要素は、信頼できる検証サービスにリクエストを送信する（典型的には、インストールされた要素が、どの検証サービスに接続するのかを規定する構成記録も送信する）ように機能する。要素は、望ましくは、平文で要素固有の識別子を送信するとともに、その他のすべてのデータを暗号化し、要素は、好ましくは、パスワードの‘一方向ハッシュ’を使用して、暗号化された登録ペイロード内で、完全なパスワードよりもむしろ、そのハッシュを送信すべきである。

このとき、認証装置は、ユーザがサービスにアクセスする権限を有しているかどうかをはっきりさせる。典型的には、これは、外部のビジネスルール（例えば、サービスがステップ２で提供される認証情報を認識するか）およびローカル（認証装置に対して）ルールのセットを適用することにより、二段階で生じる。これにより、サービスへの加入および登録を制御するフレキシブルな方法が可能になる。しかしながら、本発明のその他の実施形態では、様々なローカルおよび遠隔ルールを任意の順序で適用することができる。

登録リクエストが適用されるルールのすべてを満たす場合に、認証装置は、新規鍵および登録トークンを生成する。認証装置は、ユーザのインストールされたセキュリティ要素に暗号化されたデータを送信する前に、将来の使用のためにこれを記憶して、このデータを（‘１回使用’の鍵を使用して）暗号化する。

失敗したリクエストはいずれも、セキュリティ例外を生成することができ、その後に、更なるビジネスルールを適用することができる（例えば、不正検出サービスまたは報告システムに例外を伝える）。

個人コンテキスト（１のユーザが毎回、同一装置からサービスにアクセスする）については、認証装置は、ユーザのＰＩＮまたはパスワードの一方向ハッシュバージョンを記憶し、認証装置により生成される鍵の拡張としてこれを使用する（このため、完全鍵が、生成された鍵および一方向ハッシュＰＩＮまたはパスワードの集合体からなる）。

このとき、インストールされたセキュリティ要素は、認証装置サービスとの関係を確立して、将来の通信用の鍵を交換している。登録中に適用されたルールは追加的なセキュリティ検証ステップを実行することができるが、登録プロセスは、ユーザがサービスに接続することを試みるまでサービスとユーザが確立した関係を有しているとはみなさない。この‘１回’の登録プロセスは、セキュリティ要素を、認証装置に関連させるに過ぎないが、必ずしも、認証装置を使用することができる任意のサービスに関連させるわけではない。ビジネスルールは、認証装置が、ユーザ、要素、認証装置および要素の間のそのような関連性を形成すべきであるかどうかを決定するために使用することができる。

なお、図面は、初期の認証情報を確立するためのユーザ入力を前提としていることに留意されたい。本発明の幾つかの実施形態は、この要求を除去するために、予め構成された認証情報を利用することができる。

また、幾つかの実施例では、認証装置にまかせるのではなく、発行者に要素の鍵を提供させるように、構成することができる（これにより、閉鎖または個人サービス以外の公的サービスが初期接続を形成して、検証を実行および管理することが可能になる）。

初期登録にこの手法を採ることにより、情報発行者は、システムであって、アプリケーションからセキュリティを分離して、セキュリティの粒度の細かい制御をサポートすることができる共通のセキュリティフレームワークを提供するシステムに対するアクセスを得ることができる。また、この方法は、信頼できる第三者機関が複数のセキュリティサービスの代理をすることができる‘セキュリティファーム’の概念を導入する（例えば、単一の機関が、教育機関の代わりに学校システムにアクセスすることを望む子供達のためにセキュリティを提供し、数多くの個々のシステムに対して各ユーザを検査および保護するのに必要な手間を各機関から省くことができる）。

また、外部ルールは、自身のデータセキュリティレベルを制御することができる各発行者により、（複数のサービスへの単一ログインを可能にするために）サービスがユーザ認証情報をまとめることを可能にする（例えば、警察環境では、単一ログインは、全国データベースにアクセスするのに十分であるが、各データベース発行者が、特定のシステムからデータを取得するのに必要なアクセスレベルを制御することができる）。

インストールされたセキュリティ要素をユーザが登録すると、その要素は特定サービスへの接続を要求することができる。

セキュリティコンテキストにサービスを関連させるために、発行者は、任意のリクエストをサービスするのに使用されるセキュリティサーバへのルートおよびサービス識別子を登録することができる。任意には、発行者は、アクセスまたはユーザ登録に対する制限を課すビジネスルール（あるいはルールを施行することができるコンピュータへのリンク）を提供することができる。

本発明の好ましい実施形態を使用するときに、ユーザは、商業的に利用可能なその他のセキュリティシステムとの違いを殆ど分かることはない。しかしながら、内在する方法／システムは、初期接続を保護するセキュリティと、内部サービス通信を扱う高レベルのセキュリティとを有するような、２層構造のセキュリティモデルを使用することが望ましい。

図４は、ブラウザ内の保護要素の典型的な実施例を示すものであるが、その他の実施形態は、この方法を実行する様々な方法を使用することができる。図４では、ブラウザは２つの接続を確立しており、その一方が認証装置、他方がウェブセキュリティマネージャとなっている。

ウェブセキュリティマネージャおよび認証装置はともに、セキュリティサーバと通信することができるが、ブラウザは、これには、あるいはウェブセキュリティマネージャが通信することができるウェブデータマネージャには関係がない。図４は、２つの別個の装置として、セキュリティサーバおよびウェブセキュリティマネージャを示しているが、幾つかの実施形態は、単一の装置または複数の装置を使用してそれら機能を実行することができる。

例えば、ウェブデータマネージャを介して（現在の方法におけるように）、単一のリクエストを単一のウェブサーバに送信する代わりに、本発明のこの実施形態は、ウェブセキュリティマネージャへの初期の接続の双方について暗号化を導入するとともに、ブラウザが独立した認証装置に送信する第２暗号化リクエストを導入する。独立したセキュリティサーバがユーザの完全性を検証して、ウェブセキュリティマネージャへの適合するリクエストをブラウザが形成するように決定／確保するまで、ウェブデータマネージャは、（企業サーバに対する潜在的なサービス妨害攻撃を除去する）ブラウザ接続リクエストが存在することに気が付かないままである。本発明の別の実施形態では、ウェブセキュリティマネージャは追加のビジネスルール処理能力を提供することができる（これにより、例えば、セキュリティルールが指示する場合に、代わりのウェブデータマネージャにリクエストの経路を自動的に変えることが可能になり、あるいは、あるウェブデータ管理サイトから別のウェブデータ管理サイトへのシームレスなフェイルオーバを容易にする）。

本発明のこの実施形態は、以下の３つの主要なセキュリティプロセスを規定する。
（１）好ましくは通信に関与するすべての装置（および任意にはユーザ）の正当性を立証する信頼できる独立の第三者機関を介した安全な通信チャネルの確立
（２）第１チャネル（上記ステップ（１）に規定される）を使用してセキュリティ認証情報を交換するとともにデータへのアクセスを制御する、第２の‘サービス専用’の通信チャネルの確立
（３）例えば、幾つかのまたはすべての単一の継続中の情報リクエストを粒度の細かいレベルで制御することができ、あるいは情報発行者またはブラウザのユーザにより規定されるビジネスルールに基づいて、公開情報についてのセキュリティコンテキストを動的に変化させることができる一連のルールの提供（例えば、子供に適当ではないデータを自動的に禁止するが、それ以外のすべてのデータの通過を可能にする、セキュリティコンテキストを親が設定することを可能にする。）

これに続く議論は次のことを仮定する。
（１）ユーザ（またはコンピュータシステム）が認証装置で要素を登録している。
（２）情報発行者が認証装置で発行サービスを登録している。
（３）‘ブラウザ要素’が自身の登録に成功しており、初期接続鍵を有している。

ここで、保護チャネルの生成について述べる。

本明細書は、明瞭にするために、インターネットの閲覧を保護することに言及しているが、ここに記載の方法は、その他のネットワークシステムに同等に適用することができ、インターネットまたは関連技術に依存するものではない。

図５は、本発明の好ましい実施形態の可能性のある一実施例を表すセキュリティ要素を示している。この図においては、保護要素の実施形態は、“ｓｅｃｕｒｅ：”のようなＭＩＭＥ形式のプロトコル識別子によって作動される、インターネットブラウザへのプラグインとして機能する。これは、ブラウザがセキュリティプロトコルハンドラの１またはそれ以上のインスタンスを備えることができることを示唆している。

セキュリティプロトコルハンドラは、ウェブセキュリティマネージャ内で提供されるサービスと認証サービスとの間の初期通信チャネルを確立することについての責任を負うことが好ましい。このとき、この実施形態は、サービス専用のハンドラ（図５におけるサービスマネージャ）がその後に必要な数の保護チャネルを生成することとなる。認証装置は、各‘ブラウザレベル’のリクエストの真正性を確認し、その後、サービスを行うことができるように、適当な認証情報をセキュリティサーバに引き渡す。

この手法を採ることにより、ブラウザが多数の安全な接続を確立することが可能になり、各々が様々な暗号化アルゴリズムまたは検証サービスを潜在的に使用することが可能になる。各ブラウザは、特定のサービスに関する情報も記憶することができ、それにより、セキュリティマネージャが、特定の認証装置またはユーザにブラウザを‘ロックダウン’することが可能になる。

ここで、サービスプロバイダ登録について説明することとする。

別の実施形態では、サービスプロバイダが、顧客へのアクセスを許可する前に、検証タスクの実行を望む場合がある。図６はそのような例を示している。

この場合、顧客（１０１）は、サービスに登録するか、または制限された情報にアクセスするために、サービスプロバイダ（１０２）に連絡を取る。顧客（１０１）は、当該顧客（１０１）がサービスプロバイダのデータへのアクセスを取得すべきであるかどうかを判定するためにサービスプロバイダ（１０２）がビジネスルールのセット（３４０）を適用することができるように、サービスプロバイダ（１０２）に任意の必要なデータを提供する。

顧客（１０１）がサービスプロバイダのルール（３４０，３５０）に規定されるすべてのテストに合格した場合、サービスプロバイダ（１０２）は、関連する顧客データ（３８０）すべてを記憶し、検証サービス（１０３）により後で保持される顧客データの特定のインスタンスに顧客（１０１）を関連付けるために使用される固有のトークンを含む認証リクエストを生成する。顧客は、この固有のトークンに対するアクセスを決して得ることはなく、よって、検証サービスからの顧客‘なりすまし’リクエストを防止することができる。

このとき、検証サービス（１０３）は、将来の使用のためにユーザトークンを記憶する前に、ユーザデータの正当性をさらに検証するために、ルールの追加セットを実行することができる。その後、検証サービス（１０３）は、認証ルールプロセス中に生成される、ルール検査および任意のユーザのステータスデータの双方の結果を送信する。サービスプロバイダ（１０２）と検証サービス（１０３）間の通信は、悪意のある第三者による登録結果の盗聴または改竄を防止するために、（恐らくは本発明の実施形態に係る方法を使用して確立される）独自の暗号化層を有している。

サービスプロバイダおよび検証サービスがともに登録リクエスト（４２０）を承認した場合には、サービスプロバイダは、特にこのサービス（アイテム４５０）とともに使用する固有のトークンおよび暗号化鍵を生成する。サービスは、好ましい実施形態においては、次のタイプのブラウザインスタンスのうちの１つからのサービスにユーザがアクセスを有するかどうかを定義することもできる。
（１）サービスとともに使用する単一のコンピュータを登録する単一のユーザ（これは、ユーザ、特定のコンピュータのブラウザインスタンスおよびサービスの間の関連性を生成するため、最も安全なレベル）、または
（２）既知のコンピュータのグループから登録する単一のユーザ（例えば、作業デスクトップおよびラップトップ、よって、ユーザ、機械のグループおよび特定のサービスの間の関連性を与える）、または
（３）サービスがユーザとサービスプロバイダ間の関連性を単に検証することができる、公共または共同コンピュータシステムに登録する単一のユーザ、または
（４）専用コンピュータまたは公衆コンピュータの何れかからサービスにアクセスする一群のユーザ。

接続の種類（および関連するセキュリティレベル）を確立したら、サービスプロバイダは顧客のブラウザに適切なブラウザ認証情報（４６０）を送ることができる。登録プロセスが順調に完了したら、顧客のブラウザは、サービスプロバイダ（４７０）との安全な接続を確立するためにセキュリティ認証情報を処理する。

登録プロセスのステータスを確立したら、ブラウザは、サービス登録ステータス（４８０）を表示することができ、登録された場合には、ブラウザは、サービスプロバイダとの後の通信のための暗号化されたチャネルを確立するのに十分なデータを有する。

ここで、商用的な利用について説明することとする。

安全な接続を確立するために、ブラウザは、任意には、生成された‘トランザクションリファレンス’ユーザ名およびパスワードとともに、リソースロケータ（例えば、“ｉｓｅｃ：／／ｍｙｓｅｒｖｉｃｅ．ｃｏｍ”）を要求することができる。ブラウザは、サービスプロバイダによって要求されるデータの残りを暗号化するために、（ブラウザ登録中に提供される）ブラウザ内に記憶された鍵に加えてパスワードを使用することができる。なお、これは望ましくはリクエストペイロードを暗号化する鍵の一部として使用されるため、ブラウザがパスワードを送信する必要がないことに留意されたい。例えば、チェックサムまたは巡回冗長コード（あるいは同様の方法）を使用することにより、サービスプロバイダおよび認証装置は、ペイロードの完全性を検証するとともに、供給されたパスワードおよびブラウザ鍵によりブラウザがデータを正確に暗号化することが可能になったかどうかを判定するのに十分な情報を有する。

ブラウザは、（登録プロセス中に提供される）固有のブラウザ識別子とともに、この暗号化されたデータをサービスプロバイダに送信する（これにより、この方法が、現在の証明書交換方式とは異なり、すべての初期リクエストを保護するものとなる）。また、ブラウザは、その固有の識別子および暗号化されたユーザ名を認証装置に送信する。

このとき、サービスプロバイダは、ブラウザから受け取ったリクエストデータを復号するのに必要な鍵を有していない。したがって、それは、好ましくはセキュリティサーバにリクエストを送信して、正当性の確認を待つ。これは、任意の追加処理オーバーヘッドからフロントエンドサーバを解放する。

認証装置は、ブラウザ識別子および予め記憶された（登録中に記憶された）ハッシュバージョンのブラウザレベルパスワードを使用して、ユーザ名を復号する。その後、認証装置は、ブラウザによって要求されたサービスプロバイダリソースとの関連性をユーザが有することを確認するように機能する。

サービスプロバイダが特定のユーザ（および任意にはブラウザ）を登録して、要求されたリソースへのアクセスを許可したら、認証装置は、任意の追加ビジネスルールを実行して、その結果を、（恐らくこの方法を用いて）安全が確保されたネットワークを介してセキュリティサーバに引き渡すことができる。

このとき、セキュリティサーバは、送信されたオリジナルデータを復号するのに十分なデータを有している。セキュリティサーバは、データを復号し、（恐らく、巡回冗長または同様の方法を使用して）データの完全性を検証する。これらの検査が成功した場合、セキュリティサーバは、任意にはウェブセキュリティマネージャを介して、ウェブデータマネージャに暗号化されていないデータを送信し、認証装置およびウェブセキュリティマネージャの両方に成功ステータス指標を送信する。

その後、認証装置は、ブラウザのために最初に格納された同じ認証情報を使用して、ブラウザとの後の通信で使用される新しい鍵を暗号化する。新しい検証リクエストを確立するときに、ブラウザと認証装置はともに、この新しい鍵を使用するために記憶する。これは、すべてのリクエストの一意性を保証する。

ウェブセキュリティマネージャは、復号されたリクエストをウェブデータマネージャに引き渡して、レスポンスを待つ。ウェブセキュリティマネージャは、レスポンスを受け取ると、次のリクエストで使用するための新しい鍵とともにセキュリティマネージャにより提供された鍵を使用して、レスポンスを暗号化する。

その後、完全な検証を必要としない後のリクエストは、この新しく生成された鍵を使用してトラフィックを暗号化し、各レスポンスは、次のリクエストで使用するための新しい鍵を提供する。

幾つかの実施形態は、サービスレベルデータを暗号化するために、第２パスワードを使用することができる（第１パスワードは、ブラウザの認証を行ってサービスへの接続を開始するために使用される）。この第２のパスワードは、公衆位置で使用する任意の隠されたブラウザパスワードで動作することができる（ブラウザは、初期のリクエストのための独自の安全なチャネルを確立するが、サービスレベルメッセージを復号するのに十分なデータを有していない）。

この実施形態は、“ｓｅｃｕｒｅ：”および“ｉｓｅｃ：”のような２のプロトコル識別子を使用して、ブラウザに、（完全な認証プロセスを通過して）完全に‘検証された’サービスを要求するか、または、‘連続する’保護コンテキストを使用するかどうかを通知することを提案している。‘連続する’保護コンテキストでは、初期の検証リクエストに続いて、すべての後のリクエストがウェブセキュリティマネージャを単に通過するだけであり、結果として、初期接続を確立するために用いられるデュアル法の影響を低減するものとなっている。この手法は、発行者がリソース毎にセキュリティのレベルを規定することを可能にする。

例えば、“ｉｓｅｃ：／ｍｙｓｅｒｖｉｃｅ．ｃｏｍ”が既に確立されたチャネルを使用して、（チャネルが既に存在しない場合に、ブラウザに完全な検証を実行させるとともに）保護されていないデータについて標準的な‘ｈｔｔｐ’方式のリソースロケータのままとするが、形式“ｓｅｃｕｒｅ：／／ｍｙｓｅｒｖｉｃｅ．ｃｏｍ”で始まるリクエストは、完全な検証プロセスを要求することとなる。

なお、‘ｓｅｃｕｒｅ：’および‘ｉｓｅｃ：’のフォーマットの使用は、例示的な目的に過ぎないことに留意されたい。その他の実施形態は、安全な通信に必要な様々なセキュリティレベルを特徴付けるその他の名称または方法を使用することができる。

また、以下の説明では、‘ブラウザのプラグイン’について言及するが、その他の実施形態は、異なる技術または実施方法を利用することができる。

各ブラウザの‘プラグイン’について固有の識別子を確立するために、その使用が、（恐らくは要素インストール装置の構成または専用ハードウェア識別子に基づいて）ソフトウェアまたはハードウェアレベルの‘グローバル一意識別子’（ＧＵＩＤ）、または初期登録時に認証サービスにより生成されるＧＵＩＤの何れかから構成することができる。

ハードウェアベースのＧＵＩＤ（ハードウェア装置において生成または提供される）とともに使用するとき、本発明の望ましい実施形態に係るブラウザのプラグインは、認証装置に送信される初期の暗号化ペイロードの一部としてこの情報を含むことができる。これは、必要に応じて、ハードウェア、ブラウザおよびユーザを識別する機能を提供する。

また、ブラウザのプラグインは、独自のセキュリティルールを有することができ、それは恐らくプラグイン要素データストア内に、理想的には暗号化形式で記憶される。これにより、例えば、親が、安全な‘チャット’環境において交流の‘安全なリスト’を設定するか、あるいは認証装置または発行者内に規定されるルールとは無関係にインターネット要素へのアクセスを制限することが可能になる。

ローカルセキュリティルール‘エンジン’を有することによって、‘ブラウザルール’のローカルセットルールは、共有セキュリティポリシーに基づくものとすることもでき、それにより、（学校または企業環境のような）組織が特定のブラウザ用に安全リストを生成することが可能になり、その結果、不適当なインターネットリソースへの偶発的なアクセスを防止することができる。

以下に、ブラウザのインスタンスの再設定について説明する。

この方法は、幾つかの通信機関に依存してサービスを保護することとなるため、鍵がアライメントから漏れるか、またはメッセージが応答できない場合に、ブラウザを再設定しなければならないことがある。ブラウザと認証サービスの双方のルールエンジンは、ブラウザのプラグインが‘リセット’リクエストを発したときに、従うべき‘ビジネスルール’を提供することができる。

ブラウザを再設定する標準的な方法は、ユーザが‘ブラウザプラグイン・リセット’リクエストを引き起こすことが必要とされる。このとき、認証装置は、好ましくは、新規のブラウザＧＵＩＤを発行するか、あるいは（予め許可された接続についてのルールに応じて）ブラウザプラグインから新規のＧＵＩＤを要求する。

その後、ブラウザプラグインおよび認証装置はともに、好ましくは、すべての既知のサイトまたは前に許可されたサイトに対してルールのセットを実行して、それらが新規のブラウザ識別子を使用することを再び可能にするか、あるいは前に‘古い’ブラウザプラグインＧＵＩＤを使用していた各サービスに再登録リクエストを送信することを可能にする。

同時に、認証装置は、‘古い’ＧＵＩＤを‘期限切れ’としてマークを付けることが望ましく、‘古い’ブラウザプラグインＧＵＩＤから来るリクエストが何れも、セキュリティ例外を引き起こし、これにより、なりすましや、ブラウザプラグインをその他のデバイスにコピーする試みに関連するリスクを取り除くことができる。また、この方法は、認証装置が確実に登録リクエストおよびブラウザリセットの正確な追跡記録を維持することができるようにする。

ルールがそのように指令する場合、認証装置は、リセットリクエストを発行者に差し向けて、それらが任意のサービスユーザの完全性を再確立することを可能にする。

ここで、発行者送信について説明する。

安全な内容をブラウザに‘勧める’か、ブラウザ要素自体を更新するために、サービスプロバイダまたは認証装置は、通常のリクエストサイクルを反転させる（警告を暗号化するのに認証鍵を必要とする暗号化‘警告’をそれに送信することにより、メッセージをブラウザに勧める）ことにより、更新情報を発行することができる。その後、ブラウザは、通常の方法で安全な接続を確立して更新情報を得ることができる。

この実施例では、発行者が、（安全なチャネルを使用して）認証装置に鍵を要求し、これを、ブラウザプラグインへの‘お勧め’または警告メッセージを暗号化するために使用する。警告を受信すると、ブラウザは、予め規定された方法を使用して、認証装置に復号鍵を要求する。

本明細書に記載の本発明の実施形態は、デジタル証明書またはその他の複雑な条件を必要とすることなく、コンピュータシステムのネットワークを介して送信される情報を保護する方法を提示する。本明細書内に述べられている方法により制御される通信の完全性およびリクエストまたはレスポンスの真正性を検証するために、任意のネットワーク通信においてすべての機関を識別する方法が提供される。

これまでの殆どのセキュリティモデルは、機関が検証サービスプロバイダから証明書を取得および管理することに基づく方法を利用する。これらの証明書は、実際のソフトウェアユーザを保護するよりもむしろ、サービスに接続するソフトウェアを保護するセキュリティレベルを維持するために、多くの場合、期限切れとなるか、多大な管理努力を必要とする。

本明細書に記載の方法は、（それらのサービスにより使用されるセキュリティシステムを会社が‘所有’することを可能にする）企業のデータセンタ内で完全に、あるいは信頼できる第三者機関が主催するより大きな共有サービスの一部として、操作することができるセキュリティフレームワークを提供する。本発明の実施形態によれば、各要素がその他の要素またはデータとは異なるレベルのセキュリティレベルを有することが可能になり、それにより、安全性が確保されたアイテムおよび確保されていないアイテムを同じネットワーク伝送チャネルを介して同時伝送することが可能になる。また、提案された方法は、ソフトウェアサービスが別のものとは独立に動作することも可能にする。これにより、単独であるが同時に動作するセキュリティコンテキストが可能になり、すべてが、例えば、単一ネットワーク接続を使用するものとなる。

複数のセキュリティコンテキストを提供することにより、公衆コンピュータアクセス（複数の人により使用されるそれら装置）および個人コンテキスト（例えば、一のユーザのみをサポートするためにロックダウンされたシステム、企業ラップトップコンピュータのための）をサポートする方法が提供される。記載の方法は、ユーザのインタラクション無しにシステム間のセキュリティを提供するために、適用することができる。

所与の期間内に特定の装置の特定のユーザにコンテンツを伝送する機構も提供され、それにより、例えば、許可を受けた装置の許可を受けたユーザのみが公開情報にアクセスすることができるような保護環境において、メディアまたはその他のストリーミングコンテンツの伝送が可能になる。この手法は、従来の暗号化サービスによって要求される計算オーバーヘッドを低減し、よって、セキュリティ境界を維持するのに必要な装置の潜在的な数量および電力消費を低減することができる。

本明細書の開示はインターネット通信に言及しているが、記載の方法をその他の通信システムに適用することも可能である。

上記記載は例示的な実施形態を提供するものである。当業者にすぐに明らかとなるであろうそれら実施形態の変形および変更は、例えば、特許請求の範囲に規定されるような本発明の範囲内に包含されるものである。

Claims (31)

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. コンピュータネットワークであって、実行時に、請求項２０乃至２７の何れか一項に記載の方法を実施するように構成された命令を含むコンピュータプログラム手段により、プログラム化されていることを特徴とするコンピュータネットワーク。

Images