JP5346107B2

JP5346107B2 - インターネットのための対称鍵配信フレームワーク

Info

Publication number: JP5346107B2
Application number: JP2012096711A
Authority: JP
Inventors: ナイドゥコラーサンダーディヴヤ; デワンプラシャント; ロンメン
Original assignee: インテルコーポレイション
Priority date: 2007-12-14
Filing date: 2012-04-20
Publication date: 2013-11-20
Anticipated expiration: 2028-12-02
Also published as: ES2376143T3; US9015484B2; US9654453B2; US20130311777A1; EP2073496B1; US20150304286A1; EP2073496A1; US8532303B2; ATE531177T1; US20090154708A1; JP2012182812A; CN101488950B; CN101488950A; JP2009147927A; JP4981782B2

Description

本発明は、インターネット上の各クライアントへの専用鍵配信サーバからの対称鍵の持続的及び動的な配信に関する。

ワールド・ワイド・ウェブは、基本的にインターネット上で実行されるクライアント／サーバアプリケーションである。インターネットにおけるセキュリティ脅威は、数年間で指数的に増大してきた。様々なセキュリティ脅威を分類する１つの方法は、脅威の場所、すなわち、ウェブサーバ、クライアントウェブブラウザ及びクライアントウェブブラウザとサーバとの間のトラフィックに関するものである。クライアントとサーバとの間のトラフィックを考えると、コストのかかる非対称鍵暗号化（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎなど）を利用したクライアントとサーバとの間のセッション鍵のやりとりに依存するＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）ＩＰＳｅｃ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌＳｅｃｕｒｉｔｙ）及びＴＬＳ（ＴｒａｎｓｐｏｒｔＬａｙｅｒＳｅｃｕｒｉｔｙ）ベースのネットワークセキュリティプロトコルを配設することが容易である。サーバは、セッション単位でやりとりされる数万の一時的な対称鍵を記録する必要がある。その結果、ハードウェアによりこれらのプロトコルのための暗号化処理を実行するためのセキュリティ関連付けのためのメモリフェッチは、維持される必要がある状態数によりかなりコストがかかるものとなる（鍵のやりとりのコストは述べない）。

本発明の課題は、上記問題点に鑑み、インターネット上の各クライアントへの専用鍵配信サーバからの対称鍵の持続的及び動的な配信を可能にする方法、装置及びシステムを提供することである。

上記課題を解決するため、本発明の一特徴は、鍵配信サーバが、クライアントから測定された健全性情報を受け付けるステップと、前記サーバが、前記測定された健全性情報を検証するステップと、前記サーバが、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信するステップと、前記クライアントは、前記セッション鍵を受け付けると、前記セッション鍵を用いてドメイン内のアプリケーションサーバとの暗号化及び認証された接続を開始するステップとを有する方法に関する。

本発明の他の特徴は、クライアントから測定された健全性情報を受け付け、前記測定された健全性情報を検証し、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信する鍵配信サーバロジックを有する装置に関する。

本発明のさらなる他の特徴は、クライアントと、クライアントから測定された健全性情報を受け付け、前記測定された健全性情報を検証し、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信する鍵配信サーバロジックと、前記クライアントから前記セッション鍵を用いて暗号化されたパケットを受け付け、前記セッション鍵を用いて前記パケットを解読し、前記解読されたパケットにサービスを提供するアプリケーションサーバロジックとを有するシステムに関する。

本発明によると、インターネット上の各クライアントへの専用鍵配信サーバからの対称鍵の持続的及び動的な配信が可能になる。

図１は、インターネット上の対称鍵配信装置及びシステムを示す。図２は、鍵配信サーバを用いて鍵情報を配信するプロセスの一実施例のフロー図である。

対称鍵をインターネットを介しサーバからクライアントに配信するための方法、装置及びシステムの実施例が説明される。以下の説明では、多数の具体的詳細が与えられる。しかしながら、各実施例はこれら具体的詳細なしに実現可能であることが理解される。他の例では、本発明を不明りょうにすることを避けるため、周知の要素、詳細及びプロトコルは詳細には説明されていない。

図１は、インターネットを介した対称鍵配信装置及びシステムを示す。多数の実施例において、クライアント１００はインターネット１０４を介しドメイン１０２に接続される。インターネットは、標準的なインターネットプロトコル（ＩＰ）などのプロトコルを用いてデータを送信する世界的に公衆に利用可能な相互接続されたコンピュータネットワーク群である。より詳細には、インターネットは、各種情報及びサービスを一緒になって伝送する数百万の小型の家庭用、学術用、企業用及び政府機関ネットワークから構成される“ネットワークのネットワーク”である。物理的には、インターネットは、情報を伝送する媒体からなる有線、光及び無線ネットワークバックボーンを含む。

異なる実施例では、クライアントは、デスクトップコンピュータ、ラップトップコンピュータ、モバイル無線装置、携帯電話、テレビ用セットトップボックス、又はインターネットに接続可能な他の何れかのタイプの計算装置であるかもしれない。インターネットへのクライアントの接続は、個別の装置をインターネットに接続する他の装置のうち、ルータ、スイッチ、アクセスポイントなどの機構を介したものであるかもしれない。

異なる実施例では、ドメインは、特に企業、科学機関、大学、政府オフィス、個人のネットワークなどのためのドメインであるかもしれない。ドメインは、当該ドメイン及びインターネット内のユーザとコンピュータとの間で情報がやりとりされるのを可能にするいくつかの機能を実行する１以上のコンピュータシステムサーバから構成される。各ドメインは、特定のＩＰアドレスにマップされるドメイン名を有する。

図１は、ドメイン内の不可欠な機能を実行するいくつかのサーバの一例を示す。異なる実施例では、これらのサーバは物理的に分離したマシーンであるかもしれず、又は１つのマシーン上で実行されるアプリケーション（マシーン上の各パーティションなどにおいて）であるかもしれない。

クライアントは、サービス用のドメイン１０２へのアクセスをリクエストするかもしれない。多くの実施例では、ドメイン内にあるアプリケーションサーバ１０６は、クライアント１００が所望するこれらのサービス（情報記憶サービス、ニュース抽出サービス、電子メールサービスなど）の１以上を提供する。

多くの実施例では、ドメイン１０２はファイアウォール１０８を有する。ファイアウォール１０８は、悪意のあるユーザ及びプログラムがインターネット１０４から当該ドメインに侵入することを防ぐためのセキュリティの一形態である。ファイアウォール１０８は、独立したサーバ（図示される）であってもよく、又は図１のその他のサーバの１つの一部であってもよい（図示せず）。

ドメインはまた、ＤＨＣＰ（ＤｙｎａｍｉｃＨｏｓｔＣｏｎｆｉｇｕｒａｔｉｏｎＰｒｏｔｏｃｏｌ）サーバ１１０を含む。クライアント１００がＤＨＣＰ設定されていることが前提とされているため、クライアント１００がドメイン１０２に接続すると、クライアント１００のＤＨＣＰクライアントプログラムは、ＤＨＣＰサーバ１１０から必要な情報をリクエストするブロードキャストクエリを送信する。ＤＨＣＰサーバ１１０は、ＩＰアドレスと、ドメイン名やデフォルトゲートウェイなどのクライアント設定パラメータに関する情報とのプールを管理する。さらに、ＤＨＣＰサーバ１１０は、ドメイン１０２にあるＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバ１１２の有無及びアドレスに関する情報を有する。クライアント１００から有効なリクエストを受信すると、ＤＨＣＰサーバ１１０は、クライアント１００にＩＰアドレスと他のパラメータとを割り当てる。

この時点でＤＨＣＰサーバ１１０から受信したＩＰアドレスとＤＮＳサーバ１１２のアドレスとによって設定されたクライアント１００は、ＤＮＳサーバ１１２とやりとりすることができる。ＤＮＳサーバ１１２は、ドメイン１０２内のサーバ及び他の装置のＩＰアドレスを提供する。

アプリケーションサーバ１０６に戻って、１以上のプロセッサ１１４がアプリケーションサーバ１０６上に存在する。異なる実施例では、これらのプロセッサのそれぞれはシングル又はマルチコアであるかもしれない。いくつかの実施例では、アプリケーションサーバは、マルチプロセッサマルチコアサーバであり、他の実施例では、アプリケーションサーバは、シングルプロセッサシングルコアサーバであり、さらなる他の実施例では、アプリケーションサーバは、上述したシングル／マルチプロセッサシングル／マルチコアシステムの組み合わせの派生である。さらなる実施例では、追加的なサービスについて複数のアプリケーションサーバが存在してもよく、又は同一のサービスが、クライアントの不可をバランスさせるため、複数のアプリケーションサーバに分散されてもよい。図１では、上述したプロセッサ及びサーバコンフィギュレーションの多くは示されていない。これは、単一のサーバ上の単一のプロセッサが、クライアント／サーバ状況を説明するため適切な実施例を提供するためである。

さらに、アプリケーションサーバ１０６はまた、オペレーティングシステム（ＯＳ）１１８などの１以上のオペレーティングシステムの現在のインスタンスを格納するためのシステムメモリ１１６を有する。通常処理では、アプリケーションサーバ１０６のプロセッサ１１４は、クライアント１００などのインターネット１０４上のクライアントから複数のリクエストについてサービスを提供するかもしれない。ＤＨＣＰサーバ１１０とＤＮＳサーバ１１２によるルーティング手順の実行後、クライアントは通常、アプリケーションサーバのサービスにアクセスするため、アプリケーションサーバ１０６とやりとりする。

多くの実施例では、アプリケーションサーバ１０６は、それがやりとりするクライアントについて要求する１以上の健全性ポリシーを有するかもしれない。例えば、クライアントがアプリケーションサーバ１０６とやりとりするためのアクセスが与えられる前に、クライアントが超える必要がある最小限に要求される健全性レベルが存在するかもしれない。これらの健全性レベルは、予め決定されてもよく、又は環境に応じて動的に決定されてもよい。健全性レベルがクライアントに満たされていない場合、ネットワークインタフェースコントローラ（ＮＩＣ）１２０は、当該クライアントからのパケットを破棄する。ＮＩＣ１２０は、アプリケーションサーバ１０６がドメイン内の内部コンピュータネットワークにアクセスすることを許可及び処理するハードウェアインタフェースである。

クライアント健全性を安全に決定するため、多くの実施例では、インテル（登録商標）のＡＭＴ（ＡｃｔｉｖｅＭａｎａｇｅｍｅｎｔＴｅｃｈｎｏｌｏｇｙ）装置１２２又はＡＭＴと同様に実行される他の独立したセキュリティ測定装置がクライアント１００内に存在する。いくつかの実施例では、ＡＭＴ１２２はクライアントシステムの健全性を測定するかもしれない。この測定は、クライアントにインストールされたソフトウェア、クライアントにインストールされたオペレーティングシステム、クライアントにインストールされたアンチウイルスソフトウェアのバージョン、どの程度最近いくつの攻撃がクライアントシステムが処理したかなどの情報を含むかもしれない。ＡＭＴ１２２内のロジックがこの情報を取得するか、又はクライアント１００内の何れかのロジックが健全性情報を取得し、ＡＭＴ１２２が健全性情報を真正性を検証するかもしれない。この健全性情報が取得されると、ＡＭＴ１２２はセキュアなデジタル証明書により健全性情報を署名するかもしれない。クライアント１００は、セキュアな健全性情報をインターネット１０４を介しドメイン１０２に送信するかもしれない。

多くの実施例では、クライアント１００は、何れの要求がアプリケーションサーバ１０６とやりとりするのに必要であるか確認するため、アプリケーションサーバ１０６から健全性ポリシー要求をリクエストする。多くの実施例では、クライアント１００上で実行されるリゾルバプログラム（ｒｅｓｏｌｖｅｒｐｒｏｇｒａｍ）が、アプリケーションサーバ１０６に関する要求されるクライアント健全性ポリシーを調べる。このリクエストは、ＮＩＣ１２０により直接処理されるかもしれない。ＮＩＣ１２０は、それが常駐するアプリケーションサーバ１０６に係る健全性ポリシー情報を格納し、何れかのクライアントからの健全性ポリシーリクエストについてサービスを提供することが可能であり、このため、何れの初期的なリクエストロードもプロセッサ１１４、メモリ１１６又はＯＳ１１８との直接的なやりとりを要求しない。

クライアントに対する健全性ポリシー要求に加えて、リゾルバプログラムは、アプリケーションサーバに対するクライアント健全性ポリシールックアップの実行後、要求元のクライアントにドメイン１０２が１以上の鍵配信サーバ（ＫＤＳ）１２４を含むことを通知するかもしれない。この情報は、検索中にリゾルバプログラムにより取得される。ＫＤＳ１２４は、クライアントから受信した健全性情報を検証することができる。検証されると、ＫＤＳ１２４は、アプリケーションサーバ１０６とのセキュアなやりとりのため、クライアントに固有のセッション鍵をクライアントに提供することができる。ドメイン１０２のＫＤＳ１２４がアプリケーションサーバ１０６により信頼されていることが前提とされる。

アプリケーションサーバのＮＩＣ１２０には、セッション鍵を生成するためのマスタ鍵がＫＤＳ１２４により与えられるかもしれない。例えば、ＫＤＳ１２４がクライアントの健全性を認証すると、ＫＤＳは、クライアント１００とアプリケーションサーバ１０６との間のセッションのためのマスタ鍵を生成することができる。ＫＤＳ１２４は、クライアントＩＤ情報とマスタ鍵とから生成されたセッション鍵をクライアント１００に送信する。

いくつかの実施例では、セッション鍵は、ＳＳＬ（ＳｅｃｕｒｅＳｏｃｋｅｔｓＬａｙｅｒ）プロトコルを用いてクライアントに送信される。他の実施例では、セッション鍵は、ＴＬＳ（ＴｒａｎｓｐｏｒｔＬａｙｅｒＳｅｃｕｒｉｔｙ）プロトコルを用いてクライアントに送信される。ＴＬＳ及びＳＳＬプロトコルは、盗聴、改ざん及びメッセージ偽造を防ぐよう設計された方法によるネットワーク上のプライベート通信を可能にする。これらのプロトコルは、暗号化を利用してインターネット上のエンドポイント認証及び通信プライバシを提供する。

ＫＤＳ１２４はまた、アプリケーションサーバ１０６のＮＩＣ１２０にマスタ鍵を送信する。ＫＤＳ１２４から受信したセッション鍵を利用して、クライアントは、アプリケーションサーバとの暗号化及び認証された接続を確立することができる。その後、クライアントは、ＩＰＳｅｃ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌＳｅｃｕｒｉｔｙ）パケットフォーマットを用いて、暗号化されたパケットをアプリケーションサーバ１０６に送信可能である。ＩＰＳｅｃパケットヘッダフォーマットは、クライアントのＩＤ情報を有するＳＰＩ（ＳｅｃｕｒｉｔｙＰａｒａｍｅｔｅｒＩｎｄｅｘ）フィールドを含む。

ＮＩＣ１２０がクライアント１００からＩＰＳｅｃパケットを受信すると、ＮＩＣ１２０内のロジックがＳＰＩ内でクライアントＩＤを検証し、ＫＤＳ１２４から受信したマスタ鍵を用いて、対称鍵のサーバサイドを、
セッション鍵＝ｆ（マスタ鍵，クライアントＳＰＩ）
などの鍵関数を利用して生成する。

ＮＩＣ１２０のバージョンのセッション鍵が生成されると、ＮＩＣ１２０は、クライアント１００からのパケットを解読し、解読されたパケットをアプリケーションサーバ１０６内のネットワークソフトウェアスタックに送信し、これにより、プロセッサ１１４とＯＳ１１８はパケットをサービスすることが可能となる。

いくつかの実施例では、パケットの解読が不成功であった場合、ＮＩＣ１２０はパケットを破棄することができる。これは、プロセッサ１１４が当該パケットを確認することがないため、プロセッサ１１４により実行されるオーバヘッドを解消することとなる。

上述したようなシステム及びＫＤＳ装置を利用して、ＫＤＳは、暗号鍵配信処理のすべてではないが大部分を実行し、これにより、アプリケーションサーバ１０６からかなりの負担を取り除くこととなる。さらに、ＮＩＣ１２０が独立に入力パケットを解読し、アプリケーションサーバ１０６のソフトウェアに常駐するネットワークスタックに解読されたパケットを送信することが可能であるため、アプリケーションサーバ１０６上に常駐するプロセッサ１１４とＯＳ１１８がさらに解読処理から取り除かれる。

多くの実施例では、ドメイン１０２に複数の分散されたＫＤＳが存在する。複数のＫＤＳが、多数のクライアントへの鍵配信のロードをバランスさせるなどと共に、ＫＤＳの機能を分散化することによってセキュリティを追加するなどの利益を提供し、何れかのサーバへの攻撃が鍵配信システムを回避することを不可能にする。複数のＫＤＳの間のロードをバランス指せるため、何れか一般的な分散化されたサーバのロードバランシングアルゴリズムが利用されてもよい。例えば、クライアント１００内のリゾルバプログラムは、ＤＮＳサーバ１１２とやりとりすることによりＫＤＳに対するＤＮＳ検索を実行した後、ＫＤＳの返されたＩＰアドレスをロードバランシングアルゴリズムに適用することができる。これは、クライアント鍵リクエストをドメインに存在する多数のＫＤＳの何れか１つに送信するかもしれない。

さらに、多数の実施例では、ＮＩＣ１２０は、入力されるクライアントパケットによって１以上の異常な状況が発生するとＫＤＳ１２４に通知するかもしれない。ＫＤＳ１２４は、ＫＤＳ１２４は、この異常行動がＮＩＣ１２０から通知されると、１以上のクライアントに関する適切なアクションをとるかもしれない。例えば、ＫＤＳ１２４は、鍵及び／又はクライアントについて取消リストを保存しているかもしれない。このため、ＮＩＣ１２０が、同一のクライアントＩＤであるが異なるＩＰアドレスを含むパケットを確認したことをＫＤＳ１２４に通知した場合、ＫＤＳ１２４は、クライアントＩＤに係る鍵を取消リストに加え、当該クライアントに新たな鍵を配信する。ＮＩＣ１２０がＫＤＳ１２４にこの新たな鍵が再び複数のクライアントにより使用されていることを通知した場合、鍵をリクエストしたクライアントは、取消リストに加えられ、ネットワーク上の任意のサーバとの当該クライアントのさらなる通信を永久に拒絶するかもしれない。

多数の実施例では、ＫＤＳ１２４がクライアントから受信する健全性情報はまた、クライアントの能力と潜在的な役割（すなわち、ポスチャ情報（ｐｏｓｔｕｒｅｉｎｆｏｒｍａｔｉｏｎ））を含む他のクライアント情報によりピギーバック（ｐｉｇｇｙｂａｃｋ）されるかもしれない。ＫＤＳ１２４は、この付加情報を利用して、クライアントが通信することが許可されるドメイン１０２内のサーバを決定するかもしれない。これにより、ＫＤＳ１２４は、この決定されたサーバ群と通信するのに利用される鍵を送信するかもしれない。

図２は、鍵配信サーバを用いて鍵情報を配信するプロセスの一実施例のフロー図である。当該プロセスは、ハードウェア、ソフトウェア又はこれらの組み合わせにより実行されるかもしれない。当該プロセスは、ドメインのＤＨＣＰサーバにドメインのＤＮＳサーバのＩＰアドレスとクライアントのＩＰアドレスとを提供するようリクエストするクライアントマシーンの処理ロジックにより開始される（処理ブロック２００）。その後、ＤＨＣＰサーバ内の処理ロジックは、ＤＮＳサーバとクライアントのＩＰアドレスにより応答する（処理ブロック２０２）。

当該処理は、クライアント内の処理ロジックがＤＮＳサーバがドメインのアプリケーションサーバのＩＰアドレスを検索するようリクエストすることにより継続される（処理ブロック２０４）。その後、ＤＮＳサーバ内の処理ロジックは、アプリケーションサーバのＩＰアドレスにより応答する（処理ブロック２０６）。クライアントリゾルバプログラム内の処理ロジックは、アプリケーションサーバのＩＰアドレスを用いて、アプリケーションサーバの健全性検証と認証ポリシーを検索するため、アプリケーションサーバをポーリングする（処理ブロック２０８）。

その後、アプリケーションサーバにおけるクライアントリゾルバポリシー検索の結果が、処理ロジックにより決定される（処理ブロック２１０）。アプリケーションサーバがポリシーを有していない場合、クライアント内の処理ロジックは、アプリケーションサーバに対する通常のＨＴＴＰリクエストに移行する（処理ブロック２１２）。

他方、健全性検証／認証ポリシーが存在する場合、処理ロジックは、ＫＤＳサーバがドメインに存在することを知る。クライアントの処理ロジックは、ＤＮＳサーバからのＫＤＳサーバのＩＰアドレスをリクエストする（処理ブロック２１４）。次に、ＤＮＳサーバは、ＫＤＳサーバのＩＰアドレスによりクライアントに応答する（処理ブロック２１６）。その後、クライアント内の処理ロジックは、クライアント健全性を測定する（処理ブロック２１８）。健全性の測定は、ＡＭＴ装置、又はクライアントマシーンが健全であり、危険でないことを検証するのに利用される他の装置を用いて実行されるかもしれない。その後、クライアント内の処理ロジックは、健全性情報と潜在的な他のポスチャ情報とをＫＤＳサーバに提供する（処理ブロック２２０）。

その後、ＫＤＳサーバ内の処理ロジックは、クライアントにより測定された健全性情報に対する検証手順を実行する（処理ブロック２２２）。この検証手順は、いくつかの健全性ポリシーの何れか１つとすることができる。これは、ドメインにおけるアプリケーションサーバへのクライアントアクセスに要求されるセキュリティレベルに基づき、サーバ毎に決定される。

この時点において、処理ロジックはクライアントの健全性を決定している（処理ブロック２２４）。クライアントがＫＤＳサーバにより健全でないとみなされた場合、ＫＤＳサーバは、クライアントにセッション鍵を送信しない（処理ブロック２２６）。他方、クライアントがＫＤＳサーバにより健全であるとみなされた場合、ＫＤＳサーバは、クライアントに一意的なセッション鍵（すなわち、派生鍵）を送信する（処理ブロック２２８）。クライアントがこの鍵を受信すると、クライアント内の処理ロジックは、この一意的なセッション鍵を用いてアプリケーションサーバへのセキュアなリクエストに移行する（処理ブロック２３０）。最後に、アプリケーションサーバのＮＩＣ内の処理ロジックは、クライアントからセキュアなリクエストを受信し、クライアントＩＤから導出されたセッション鍵とＫＤＳから提供されたマスタ鍵とを用いてパケットを解読する（処理ブロック２３２）。パケットが解読されると、パケットはアプリケーションサーバ内のさらなる処理のためネットワークソフトウェアスタックに送信可能であり、当該処理は終了する。

異常、サーバからクライアントにインターネットを介し対称鍵を配信する方法、装置及びシステムが説明された。これらの実施例は、具体的な実施例を参照して説明された。この開示の利益を有する者にとって、ここに記載された実施例の広範な趣旨及び範囲から逸脱することなくこれらの実施例に各種改良及び変更が可能であることは明らかであろう。明細書及び図面は、限定的なものでなく例示的なものとしてみなされるべきである。

１００クライアント
１０２ドメイン
１０４インターネット
１０６アプリケーションサーバ
１０８ファイアウォール
１１０ＤＨＣＰサーバ
１１２ＤＮＳサーバ
１１４プロセッサ
１２０ＮＩＣ
１２２ＡＭＴ装置

Claims

アプリケーションサーバとのセキュア通信に対するセッションキーを生成する鍵配信サーバであって、
アプリケーションサーバへのアクセスを要求したクライアント装置により生成される健全性情報であって、前記アプリケーションサーバにアクセスするため要求されるクライアント健全性ポリシーに応じて測定される前記クライアント装置のクライアント健全性レベルを示す前記健全性情報を受信し、
前記クライアント装置から受信した前記健全性情報を検証し、
前記クライアント装置のクライアント健全性レベルが前記アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを充足するか判断し、
前記クライアント装置のクライアント健全性レベルが前記アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを充足していることに応答して、前記クライアント装置と前記アプリケーションサーバとの間の通信セッションのためのマスタキーを生成し、
前記マスタキーと前記クライアント装置のクライアント識別子とに応じてクライアント
に固有のセッションキーを生成し、
前記マスタキーと前記クライアント装置のクライアント識別子とに応じて対応するセッションキーを生成するため、前記マスタキーを前記アプリケーションサーバに送信し、
前記アプリケーションサーバとの通信を暗号化及び解読するため、前記クライアントに固有のセッションキーを前記クライアント装置に送信する鍵配信サーバロジックを有する鍵配信サーバ。
前記鍵配信サーバロジックはさらに、
前記クライアント装置による異常な通信を示す情報を受信し、
前記クライアント装置に対応するクライアントに固有のセッションキーを鍵取消リストに追加し、
新たなクライアントに固有のセッションキーを生成し、
前記アプリケーションサーバとの通信を暗号化及び解読するため、前記新たなクライアントに固有のセッションキーを前記クライアント装置に送信する、請求項１記載の鍵配信サーバ。
前記鍵配信サーバロジックはさらに、
前記クライアント装置による異常な通信を示す情報を受信し、
前記クライアント装置を取消リストに追加し、
前記クライアント装置が前記アプリケーションサーバとさらに通信することを阻止する、請求項１記載の鍵配信サーバ。
前記クライアント装置による異常な通信を示す情報の受信は、前記アプリケーションサーバから前記クライアント装置による異常な通信を示す情報を受信することを有する、請求項２又は３記載の鍵配信サーバ。
前記クライアント装置により生成される健全性情報はさらに、前記クライアント装置の１以上の能力を示す情報を有し、
前記鍵配信サーバロジックはさらに、
複数のアプリケーションサーバの第１アプリケーションサーバグループが前記クライアント装置にアクセス可能であると判断し、
前記クライアント装置のクライアント健全性レベルが前記第１アプリケーションサーバグループの各アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを充足しているか判断し、
前記クライアント装置のクライアント健全性レベルが前記第１アプリケーションサーバグループの各アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを充足していることに応答して、前記第１アプリケーションサーバグループについて、各マスタキーが異なるアプリケーションサーバに対応する複数のマスタキーを生成し、
各クライアントに固有のセッションキーが前記クライアント装置のクライアント識別子と前記複数のマスタキーの異なるマスタキーとに対応する複数のクライアントに固有のセッションキーを生成し、
前記複数のマスタキーの第１マスタキーと前記クライアント装置のクライアント識別子とに応じて一致するセッションキーを生成するため、前記第１マスタキーを第１アプリケーションサーバに送信し、
前記第１アプリケーションサーバとの通信を暗号化及び解読するため、対応する前記クライアントに固有のセッションキーを前記クライアント装置に送信する、請求項１記載の鍵配信サーバ。
アプリケーションサーバとのセキュア通信に対するセッションキーを配信するシステムであって、
アプリケーションサーバへのアクセスを要求したクライアント装置により生成される健全性情報であって、前記アプリケーションサーバにアクセスするため要求されるクライアント健全性ポリシーに応じて測定される前記クライアント装置のクライアント健全性レベルを示す前記健全性情報を受信し、
前記クライアント装置から受信した前記健全性情報を検証し、
前記クライアント装置のクライアント健全性レベルが前記アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを充足するか判断し、
前記クライアント装置のクライアント健全性レベルが前記アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを充足していることに応答して、前記クライアント装置と前記アプリケーションサーバとの間の通信セッションのためのマスタキーを生成し、
前記マスタキーと前記クライアント装置のクライアント識別子とに応じてクライアント
に固有のセッションキーを生成し、
前記マスタキーと前記クライアント装置のクライアント識別子とに応じて対応するセッションキーを生成するため、前記マスタキーを前記アプリケーションサーバに送信し、
前記アプリケーションサーバとの通信を暗号化及び解読するため、前記クライアントに固有のセッションキーを前記クライアント装置に送信する鍵配信サーバを有するシステム。
前記鍵配信サーバはさらに、
前記クライアント装置による異常な通信を示す情報を受信し、
前記クライアント装置に対応するクライアントに固有のセッションキーを鍵取消リストに追加し、
新たなクライアントに固有のセッションキーを生成し、
前記アプリケーションサーバとの通信を暗号化及び解読するため、前記新たなクライアントに固有のセッションキーを前記クライアント装置に送信する、請求項６記載のシステム。
前記鍵配信サーバはさらに、
前記クライアント装置による異常な通信を示す情報を受信し、
前記クライアント装置を取消リストに追加し、
前記クライアント装置が前記アプリケーションサーバとさらに通信することを阻止する、請求項６記載のシステム。
前記クライアント装置により生成される健全性情報はさらに、前記クライアント装置の１以上の能力を示す情報を有し、
前記鍵配信サーバはさらに、
複数のアプリケーションサーバの第１アプリケーションサーバグループが前記クライアント装置にアクセス可能であると判断し、
前記クライアント装置のクライアント健全性レベルが前記第１アプリケーションサーバグループの各アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを充足しているか判断し、
前記クライアント装置のクライアント健全性レベルが前記第１アプリケーションサーバグループの各アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを充足していることに応答して、前記第１アプリケーションサーバグループについて、各マスタキーが異なるアプリケーションサーバに対応する複数のマスタキーを生成し、
各クライアントに固有のセッションキーが前記クライアント装置のクライアント識別子と前記複数のマスタキーの異なるマスタキーとに対応する複数のクライアントに固有のセッションキーを生成し、
前記複数のマスタキーの第１マスタキーと前記クライアント装置のクライアント識別子とに応じて一致するセッションキーを生成するため、前記第１マスタキーを第１アプリケーションサーバに送信し、
前記第１アプリケーションサーバとの通信を暗号化及び解読するため、対応する前記クライアントに固有のセッションキーを前記クライアント装置に送信する、請求項６記載のシステム。
前記クライアント装置は、
前記アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーに応じて前記クライアント装置の前記クライアント健全性レベルを測定し、
前記測定に基づき前記健全性情報を生成し、
前記生成された健全性情報をセキュアなデジタル証明書により署名し、
前記健全性情報をネットワークを介し前記鍵配信サーバに送信する、
セキュリティ管理コンポーネントを有する、請求項６記載のシステム。
前記クライアント装置はさらに、
前記アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを前記アプリケーションサーバから要求し、
前記アプリケーションサーバから前記クライアント健全性ポリシーを受信し、
前記鍵配信サーバから前記クライアントに固有のセッションキーを受信し、
前記クライアントに固有のセッションキーを用いてパケットを暗号化し、
前記暗号化されたパケットと前記クライアント装置のクライアント識別子とを有するＩＰＳｅｃ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌＳｅｃｕｒｉｔｙ）パケットを用いて、前記暗号化されたパケットを前記アプリケーションサーバに送信する、請求項６乃至１０何れか一項記載のシステム。
前記アプリケーションサーバは、
オペレーティングシステムを格納するメモリと、
前記オペレーティングシステムからの命令を実行するプロセッサと、
前記クライアント装置から前記暗号化されたパケットと前記クライアント装置のクライアント識別子とを有するＩＰＳｅｃパケットを受信し、前記受信したＩＰＳｅｃパケットからの前記クライアント装置のクライアント識別子を検証し、前記受信したＩＰＳｅｃパケットからの前記クライアント識別子と前記鍵配信サーバから受信したマスタキーとを用いて、対応する前記セッションキーを生成し、前記受信したＩＰＳｅｃパケットから前記対応するセッションキーにより前記暗号化されたパケットを解読し、前記プロセッサによりサービス提供のため、前記解読されたパケットを前記オペレーティングシステムに送信するネットワークインタフェースコントローラと、
を有する、請求項１１記載のシステム。
前記アプリケーションサーバはさらに、前記解読が不成功であった場合、前記パケットを破棄する、請求項１２記載のシステム。
前記鍵配信サーバのアドレスを前記クライアント装置に提供するドメインネームサーバをさらに有する、請求項６記載のシステム。
アプリケーションサーバとのセキュア通信に対するセッションキーを配信する方法であって、
鍵配信サーバが、アプリケーションサーバへのアクセスを要求したクライアント装置により生成される健全性情報であって、前記アプリケーションサーバにアクセスするため要求されるクライアント健全性ポリシーに応じて測定される前記クライアント装置のクライアント健全性レベルを示す前記健全性情報を受信するステップと、
前記鍵配信サーバが、前記クライアント装置から受信した前記健全性情報を検証するステップと、
前記鍵配信サーバが、前記クライアント装置のクライアント健全性レベルが前記アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを充足するか判断するステップと、
前記鍵配信サーバが、前記クライアント装置のクライアント健全性レベルが前記アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを充足していることに応答して、前記クライアント装置と前記アプリケーションサーバとの間の通信セッションのためのマスタキーを生成するステップと、
前記鍵配信サーバが、前記マスタキーと前記クライアント装置のクライアント識別子とに応じてクライアントに固有のセッションキーを生成するステップと、
前記鍵配信サーバが、前記マスタキーと前記クライアント装置のクライアント識別子とに応じて対応するセッションキーを生成するため、前記マスタキーを前記アプリケーションサーバに送信するステップと、
前記鍵配信サーバが、前記アプリケーションサーバとの通信を暗号化及び解読するため、前記クライアントに固有のセッションキーを前記クライアント装置に送信するステップと、
を有する方法。
前記鍵配信サーバが、前記クライアント装置による異常な通信を示す情報を受信するステップと、
前記鍵配信サーバが、前記クライアント装置に対応するクライアントに固有のセッションキーを鍵取消リストに追加するステップと、
前記鍵配信サーバが、新たなクライアントに固有のセッションキーを生成するステップと、
前記鍵配信サーバが、前記アプリケーションサーバとの通信を暗号化及び解読するため、前記新たなクライアントに固有のセッションキーを前記クライアント装置に送信するステップと、
をさらに有する、請求項１５記載の方法。
前記鍵配信サーバが、前記クライアント装置による異常な通信を示す情報を受信するステップと、
前記鍵配信サーバが、前記クライアント装置を取消リストに追加するステップと、
前記鍵配信サーバが、前記クライアント装置が前記アプリケーションサーバとさらに通信することを阻止するステップと、
をさらに有する、請求項１５記載の方法。
前記クライアント装置により生成される健全性情報はさらに、前記クライアント装置の１以上の能力を示す情報を有し、
当該方法はさらに、
前記鍵配信サーバが、複数のアプリケーションサーバの第１アプリケーションサーバグループが前記クライアント装置にアクセス可能であると判断するステップと、
前記鍵配信サーバが、前記クライアント装置のクライアント健全性レベルが前記第１アプリケーションサーバグループの各アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを充足しているか判断するステップと、
前記鍵配信サーバが、前記クライアント装置のクライアント健全性レベルが前記第１アプリケーションサーバグループの各アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを充足していることに応答して、前記第１アプリケーションサーバグループについて、各マスタキーが異なるアプリケーションサーバに対応する複数のマスタキーを生成するステップと、
前記鍵配信サーバが、各クライアントに固有のセッションキーが前記クライアント装置のクライアント識別子と前記複数のマスタキーの異なるマスタキーとに対応する複数のクライアントに固有のセッションキーを生成するステップと、
前記鍵配信サーバが、前記複数のマスタキーの第１マスタキーと前記クライアント装置のクライアント識別子とに応じて一致するセッションキーを生成するため、前記第１マスタキーを第１アプリケーションサーバに送信するステップと、
前記鍵配信サーバが、前記第１アプリケーションサーバとの通信を暗号化及び解読するため、対応する前記クライアントに固有のセッションキーを前記クライアント装置に送信するステップと、
を有する、請求項１５記載の方法。
前記クライアント装置が、前記アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーを要求するステップと、
前記クライアント装置が、前記アプリケーションサーバから前記クライアント健全性ポリシーを受信するステップと、
前記クライアント装置が、前記アプリケーションサーバにアクセスするため要求される前記クライアント健全性ポリシーに応じて前記クライアント装置のクライアント健全性レベルを測定するステップと、
前記クライアント装置が、前記測定に基づき前記健全性情報を生成するステップと、
前記クライアント装置が、前記生成された健全性情報をセキュアなデジタル証明書により署名するステップと、
前記クライアント装置が、前記健全性情報を前記鍵配信サーバに送信するステップと、
前記クライアント装置が、前記鍵配信サーバから前記クライアントに固有のセッションキーを受信するステップと、
前記クライアント装置が、前記クライアントに固有のセッションキーを用いてパケットを暗号化するステップと、
前記クライアント装置が、前記暗号化されたパケットと前記クライアント装置のクライアント識別子とを有するＩＰＳｅｃ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌＳｅｃｕｒｉｔｙ）パケットを用いて、前記暗号化されたパケットを前記アプリケーションサーバに送信するステップと、
をさらに有する、請求項１５記載の方法。
前記アプリケーションサーバが、前記クライアント装置により送信された前記クライアント識別子と前記暗号化されたパケットとを有するＩＰＳｅｃパケットを受信するステップと、
前記アプリケーションサーバが、前記受信したＩＰＳｅｃパケットからの前記クライアント装置のクライアント識別子を検証するステップと、
前記アプリケーションサーバが、前記受信したＩＰＳｅｃパケットからの前記クライアント識別子と前記鍵配信サーバから受信した前記マスタキーとを用いて、前記対応するセッションキーを生成するステップと、
前記アプリケーションサーバが、前記受信したＩＰＳｅｃパケットからの前記暗号化されたパケットを前記対応するセッションキーにより解読するステップと、
前記アプリケーションサーバが、前記解読が成功であった場合、前記アプリケーションサーバのプロセッサによるサービス提供のため、前記解読されたパケットを前記アプリケーションサーバのオペレーティングシステムに送信するステップと、
前記アプリケーションサーバが、前記解読が不成功であった場合、前記暗号化されたパケットを破棄するステップと、
をさらに有する、請求項１９記載の方法。