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

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

符号の説明

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

Claims (8)

1. クライアントに統合されたセキュリティ測定ハードウェア装置が、要求されたクライアント健全性ポリシーをアプリケーションサーバから要求するステップと、
   前記アプリケーションサーバに統合されたネットワークインタフェースコントローラが、前記要求されたクライアントヘルスポリシーと鍵配信サーバのアドレスとを前記セキュリティ測定ハードウェア装置に送信又は格納するステップと、
   前記セキュリティ測定ハードウェア装置が、前記ネットワークインタフェースコントローラから受信した要求されたクライアント健全性ポリシーを利用して、前記クライアントの健全性を記述した健全性情報を生成する前記クライアントの健全性チェックを実行するステップとであって、前記セキュリティ測定ハードウェア装置が前記クライアント上で実行されるオペレーティングシステムの制御外で動作し、前記オペレーティングシステムの健全性を少なくともチェックする、前記健全性チェックを実行するステップと、
   前記セキュリティ測定ハードウェア装置が、前記健全性情報を鍵配信サーバに送信するステップと、
   前記鍵配信サーバが、前記受信した健全性情報を介し前記クライアントの健全性を検証するステップと、
   前記鍵配信サーバが、前記クライアントの健全性が検証されると、前記アプリケーションサーバとのセキュアなやりとりのためのセッションキーを前記クライアントに提供するステップと、
   前記クライアントが、前記セッションキーを利用して前記アプリケーションサーバとやりとりするためのリクエストを送信するステップと、
   前記ネットワークインタフェースコントローラが、前記クライアントのセッションキーの検証後、前記クライアントが前記アプリケーションサーバとやりとりすることを許可するステップと、
   を有する方法。
2. 前記アプリケーションサーバに統合されたリゾルバロジックが、前記アプリケーションサーバの要求されたクライアント健全性ポリシーを決定するステップと、
   前記リゾルバロジックが、格納のため前記要求されたクライアント健全性ポリシーを前記ネットワークインタフェースコントローラに送信するステップと、
   をさらに有する、請求項１記載の方法。
3. 前記鍵配信サーバが、前記ネットワークインタフェースコントローラに前記セッションキーに係るマスタキーを提供するステップをさらに有し、
   前記ネットワークインタフェースコントローラは、前記マスタキーにより前記セッションキーを検証可能である、請求項１記載の方法。
4. 前記マスタキーは、各マスタキーが各セッションキーについて提供される、複数の一意的なマスタキーの１つである、請求項３記載の方法。
5. 要求されたクライアント健全性ポリシーをアプリケーションサーバから要求し、前記要求されたクライアント健全性ポリシーを利用して、クライアントの健全性を記述する健全性情報を生成する前記クライアントの健全性チェックを実行し、前記健全性情報を鍵配信サーバに送信するセキュリティ測定ハードウェア装置を有する前記クライアントと、
   前記受信した健全性情報を介し前記クライアントの健全性を検証し、前記クライアントの健全性が検証されると、前記アプリケーションサーバとのセキュアなやりとりのためのセッションキーを前記クライアントに提供する前記鍵配信サーバと、
   前記要求されたクライアント健全性ポリシーと前記鍵配信サーバのアドレストとを前記セキュリティ測定ハードウェア装置に送信し、前記クライアントのセッションキーの検証後、前記クライアントが前記アプリケーションサーバとやりとりすることを許可するネットワークインタフェースコントローラを有する前記アプリケーションサーバと、
   を有するシステムであって、
   前記クライアントは、前記セッションキーを利用して前記アプリケーションサーバとやりとりするためのリクエストを送信するシステム。
6. 前記アプリケーションサーバはさらに、前記アプリケーションサーバの前記要求されたクライアント健全性ポリシーを決定し、格納のため前記要求されたクライアント健全性ポリシーを前記ネットワークインタフェースコントローラに送信するリゾルバロジックを有する、請求項５記載のシステム。
7. 前記鍵配信サーバはさらに、前記ネットワークインタフェースコントローラに前記セッションキーに係るマスタキーを提供するよう動作可能であり、
   前記ネットワークインタフェースコントローラは、前記マスタキーにより前記セッションキーを検証可能である、請求項５記載のシステム。
8. 前記マスタキーは、各マスタキーが各セッションキーについて提供される、複数の一意的なマスタキーの１つである、請求項７記載のシステム。

Images