インターネットのための対称鍵配信フレームワーク
【課題】インターネット上の各クライアントへの専用鍵配信サーバからの対称鍵の持続的及び動的な配信を可能にする方法、装置及びシステムを提供する。
【解決手段】方法は、鍵配信サーバが、クライアントから測定された健全性情報を受け付けるステップと、前記サーバが、前記測定された健全性情報を検証するステップと、前記サーバが、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信するステップと、前記クライアントは、前記セッション鍵を受け付けると、前記セッション鍵を用いてドメイン内のアプリケーションサーバとの暗号化及び認証された接続を開始するステップとを有する。
【解決手段】方法は、鍵配信サーバが、クライアントから測定された健全性情報を受け付けるステップと、前記サーバが、前記測定された健全性情報を検証するステップと、前記サーバが、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信するステップと、前記クライアントは、前記セッション鍵を受け付けると、前記セッション鍵を用いてドメイン内のアプリケーションサーバとの暗号化及び認証された接続を開始するステップとを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット上の各クライアントへの専用鍵配信サーバからの対称鍵の持続的及び動的な配信に関する。
【背景技術】
【０００２】
ワールド・ワイド・ウェブは、基本的にインターネット上で実行されるクライアント／サーバアプリケーションである。インターネットにおけるセキュリティ脅威は、数年間で指数的に増大してきた。様々なセキュリティ脅威を分類する１つの方法は、脅威の場所、すなわち、ウェブサーバ、クライアントウェブブラウザ及びクライアントウェブブラウザとサーバとの間のトラフィックに関するものである。クライアントとサーバとの間のトラフィックを考えると、コストのかかる非対称鍵暗号化（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎなど）を利用したクライアントとサーバとの間のセッション鍵のやりとりに依存するＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）ＩＰＳｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）及びＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）ベースのネットワークセキュリティプロトコルを配設することが容易である。サーバは、セッション単位でやりとりされる数万の一時的な対称鍵を記録する必要がある。その結果、ハードウェアによりこれらのプロトコルのための暗号化処理を実行するためのセキュリティ関連付けのためのメモリフェッチは、維持される必要がある状態数によりかなりコストがかかるものとなる（鍵のやりとりのコストは述べない）。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明の課題は、上記問題点に鑑み、インターネット上の各クライアントへの専用鍵配信サーバからの対称鍵の持続的及び動的な配信を可能にする方法、装置及びシステムを提供することである。
【課題を解決するための手段】
【０００４】
上記課題を解決するため、本発明の一特徴は、鍵配信サーバが、クライアントから測定された健全性情報を受け付けるステップと、前記サーバが、前記測定された健全性情報を検証するステップと、前記サーバが、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信するステップと、前記クライアントは、前記セッション鍵を受け付けると、前記セッション鍵を用いてドメイン内のアプリケーションサーバとの暗号化及び認証された接続を開始するステップとを有する方法に関する。
【０００５】
本発明の他の特徴は、クライアントから測定された健全性情報を受け付け、前記測定された健全性情報を検証し、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信する鍵配信サーバロジックを有する装置に関する。
【０００６】
本発明のさらなる他の特徴は、クライアントと、クライアントから測定された健全性情報を受け付け、前記測定された健全性情報を検証し、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信する鍵配信サーバロジックと、前記クライアントから前記セッション鍵を用いて暗号化されたパケットを受け付け、前記セッション鍵を用いて前記パケットを解読し、前記解読されたパケットにサービスを提供するアプリケーションサーバロジックとを有するシステムに関する。
【発明の効果】
【０００７】
本発明によると、インターネット上の各クライアントへの専用鍵配信サーバからの対称鍵の持続的及び動的な配信が可能になる。
【発明を実施するための最良の形態】
【０００８】
対称鍵をインターネットを介しサーバからクライアントに配信するための方法、装置及びシステムの実施例が説明される。以下の説明では、多数の具体的詳細が与えられる。しかしながら、各実施例はこれら具体的詳細なしに実現可能であることが理解される。他の例では、本発明を不明りょうにすることを避けるため、周知の要素、詳細及びプロトコルは詳細には説明されていない。
【０００９】
図１は、インターネットを介した対称鍵配信装置及びシステムを示す。多数の実施例において、クライアント１００はインターネット１０４を介しドメイン１０２に接続される。インターネットは、標準的なインターネットプロトコル（ＩＰ）などのプロトコルを用いてデータを送信する世界的に公衆に利用可能な相互接続されたコンピュータネットワーク群である。より詳細には、インターネットは、各種情報及びサービスを一緒になって伝送する数百万の小型の家庭用、学術用、企業用及び政府機関ネットワークから構成される“ネットワークのネットワーク”である。物理的には、インターネットは、情報を伝送する媒体からなる有線、光及び無線ネットワークバックボーンを含む。
【００１０】
異なる実施例では、クライアントは、デスクトップコンピュータ、ラップトップコンピュータ、モバイル無線装置、携帯電話、テレビ用セットトップボックス、又はインターネットに接続可能な他の何れかのタイプの計算装置であるかもしれない。インターネットへのクライアントの接続は、個別の装置をインターネットに接続する他の装置のうち、ルータ、スイッチ、アクセスポイントなどの機構を介したものであるかもしれない。
【００１１】
異なる実施例では、ドメインは、特に企業、科学機関、大学、政府オフィス、個人のネットワークなどのためのドメインであるかもしれない。ドメインは、当該ドメイン及びインターネット内のユーザとコンピュータとの間で情報がやりとりされるのを可能にするいくつかの機能を実行する１以上のコンピュータシステムサーバから構成される。各ドメインは、特定のＩＰアドレスにマップされるドメイン名を有する。
【００１２】
図１は、ドメイン内の不可欠な機能を実行するいくつかのサーバの一例を示す。異なる実施例では、これらのサーバは物理的に分離したマシーンであるかもしれず、又は１つのマシーン上で実行されるアプリケーション（マシーン上の各パーティションなどにおいて）であるかもしれない。
【００１３】
クライアントは、サービス用のドメイン１０２へのアクセスをリクエストするかもしれない。多くの実施例では、ドメイン内にあるアプリケーションサーバ１０６は、クライアント１００が所望するこれらのサービス（情報記憶サービス、ニュース抽出サービス、電子メールサービスなど）の１以上を提供する。
【００１４】
多くの実施例では、ドメイン１０２はファイアウォール１０８を有する。ファイアウォール１０８は、悪意のあるユーザ及びプログラムがインターネット１０４から当該ドメインに侵入することを防ぐためのセキュリティの一形態である。ファイアウォール１０８は、独立したサーバ（図示される）であってもよく、又は図１のその他のサーバの１つの一部であってもよい（図示せず）。
【００１５】
ドメインはまた、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバ１１０を含む。クライアント１００がＤＨＣＰ設定されていることが前提とされているため、クライアント１００がドメイン１０２に接続すると、クライアント１００のＤＨＣＰクライアントプログラムは、ＤＨＣＰサーバ１１０から必要な情報をリクエストするブロードキャストクエリを送信する。ＤＨＣＰサーバ１１０は、ＩＰアドレスと、ドメイン名やデフォルトゲートウェイなどのクライアント設定パラメータに関する情報とのプールを管理する。さらに、ＤＨＣＰサーバ１１０は、ドメイン１０２にあるＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバ１１２の有無及びアドレスに関する情報を有する。クライアント１００から有効なリクエストを受信すると、ＤＨＣＰサーバ１１０は、クライアント１００にＩＰアドレスと他のパラメータとを割り当てる。
【００１６】
この時点でＤＨＣＰサーバ１１０から受信したＩＰアドレスとＤＮＳサーバ１１２のアドレスとによって設定されたクライアント１００は、ＤＮＳサーバ１１２とやりとりすることができる。ＤＮＳサーバ１１２は、ドメイン１０２内のサーバ及び他の装置のＩＰアドレスを提供する。
【００１７】
アプリケーションサーバ１０６に戻って、１以上のプロセッサ１１４がアプリケーションサーバ１０６上に存在する。異なる実施例では、これらのプロセッサのそれぞれはシングル又はマルチコアであるかもしれない。いくつかの実施例では、アプリケーションサーバは、マルチプロセッサマルチコアサーバであり、他の実施例では、アプリケーションサーバは、シングルプロセッサシングルコアサーバであり、さらなる他の実施例では、アプリケーションサーバは、上述したシングル／マルチプロセッサシングル／マルチコアシステムの組み合わせの派生である。さらなる実施例では、追加的なサービスについて複数のアプリケーションサーバが存在してもよく、又は同一のサービスが、クライアントの不可をバランスさせるため、複数のアプリケーションサーバに分散されてもよい。図１では、上述したプロセッサ及びサーバコンフィギュレーションの多くは示されていない。これは、単一のサーバ上の単一のプロセッサが、クライアント／サーバ状況を説明するため適切な実施例を提供するためである。
【００１８】
さらに、アプリケーションサーバ１０６はまた、オペレーティングシステム（ＯＳ）１１８などの１以上のオペレーティングシステムの現在のインスタンスを格納するためのシステムメモリ１１６を有する。通常処理では、アプリケーションサーバ１０６のプロセッサ１１４は、クライアント１００などのインターネット１０４上のクライアントから複数のリクエストについてサービスを提供するかもしれない。ＤＨＣＰサーバ１１０とＤＮＳサーバ１１２によるルーティング手順の実行後、クライアントは通常、アプリケーションサーバのサービスにアクセスするため、アプリケーションサーバ１０６とやりとりする。
【００１９】
多くの実施例では、アプリケーションサーバ１０６は、それがやりとりするクライアントについて要求する１以上の健全性ポリシーを有するかもしれない。例えば、クライアントがアプリケーションサーバ１０６とやりとりするためのアクセスが与えられる前に、クライアントが超える必要がある最小限に要求される健全性レベルが存在するかもしれない。これらの健全性レベルは、予め決定されてもよく、又は環境に応じて動的に決定されてもよい。健全性レベルがクライアントに満たされていない場合、ネットワークインタフェースコントローラ（ＮＩＣ）１２０は、当該クライアントからのパケットを破棄する。ＮＩＣ１２０は、アプリケーションサーバ１０６がドメイン内の内部コンピュータネットワークにアクセスすることを許可及び処理するハードウェアインタフェースである。
【００２０】
クライアント健全性を安全に決定するため、多くの実施例では、インテル（登録商標）のＡＭＴ（Ａｃｔｉｖｅ Ｍａｎａｇｅｍｅｎｔ Ｔｅｃｈｎｏｌｏｇｙ）装置１２２又はＡＭＴと同様に実行される他の独立したセキュリティ測定装置がクライアント１００内に存在する。いくつかの実施例では、ＡＭＴ１２２はクライアントシステムの健全性を測定するかもしれない。この測定は、クライアントにインストールされたソフトウェア、クライアントにインストールされたオペレーティングシステム、クライアントにインストールされたアンチウイルスソフトウェアのバージョン、どの程度最近いくつの攻撃がクライアントシステムが処理したかなどの情報を含むかもしれない。ＡＭＴ１２２内のロジックがこの情報を取得するか、又はクライアント１００内の何れかのロジックが健全性情報を取得し、ＡＭＴ１２２が健全性情報を真正性を検証するかもしれない。この健全性情報が取得されると、ＡＭＴ１２２はセキュアなデジタル証明書により健全性情報を署名するかもしれない。クライアント１００は、セキュアな健全性情報をインターネット１０４を介しドメイン１０２に送信するかもしれない。
【００２１】
多くの実施例では、クライアント１００は、何れの要求がアプリケーションサーバ１０６とやりとりするのに必要であるか確認するため、アプリケーションサーバ１０６から健全性ポリシー要求をリクエストする。多くの実施例では、クライアント１００上で実行されるリゾルバプログラム（ｒｅｓｏｌｖｅｒ ｐｒｏｇｒａｍ）が、アプリケーションサーバ１０６に関する要求されるクライアント健全性ポリシーを調べる。このリクエストは、ＮＩＣ１２０により直接処理されるかもしれない。ＮＩＣ１２０は、それが常駐するアプリケーションサーバ１０６に係る健全性ポリシー情報を格納し、何れかのクライアントからの健全性ポリシーリクエストについてサービスを提供することが可能であり、このため、何れの初期的なリクエストロードもプロセッサ１１４、メモリ１１６又はＯＳ１１８との直接的なやりとりを要求しない。
【００２２】
クライアントに対する健全性ポリシー要求に加えて、リゾルバプログラムは、アプリケーションサーバに対するクライアント健全性ポリシールックアップの実行後、要求元のクライアントにドメイン１０２が１以上の鍵配信サーバ（ＫＤＳ）１２４を含むことを通知するかもしれない。この情報は、検索中にリゾルバプログラムにより取得される。ＫＤＳ１２４は、クライアントから受信した健全性情報を検証することができる。検証されると、ＫＤＳ１２４は、アプリケーションサーバ１０６とのセキュアなやりとりのため、クライアントに固有のセッション鍵をクライアントに提供することができる。ドメイン１０２のＫＤＳ１２４がアプリケーションサーバ１０６により信頼されていることが前提とされる。
【００２３】
アプリケーションサーバのＮＩＣ１２０には、セッション鍵を生成するためのマスタ鍵がＫＤＳ１２４により与えられるかもしれない。例えば、ＫＤＳ１２４がクライアントの健全性を認証すると、ＫＤＳは、クライアント１００とアプリケーションサーバ１０６との間のセッションのためのマスタ鍵を生成することができる。ＫＤＳ１２４は、クライアントＩＤ情報とマスタ鍵とから生成されたセッション鍵をクライアント１００に送信する。
【００２４】
いくつかの実施例では、セッション鍵は、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）プロトコルを用いてクライアントに送信される。他の実施例では、セッション鍵は、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）プロトコルを用いてクライアントに送信される。ＴＬＳ及びＳＳＬプロトコルは、盗聴、改ざん及びメッセージ偽造を防ぐよう設計された方法によるネットワーク上のプライベート通信を可能にする。これらのプロトコルは、暗号化を利用してインターネット上のエンドポイント認証及び通信プライバシを提供する。
【００２５】
ＫＤＳ１２４はまた、アプリケーションサーバ１０６のＮＩＣ１２０にマスタ鍵を送信する。ＫＤＳ１２４から受信したセッション鍵を利用して、クライアントは、アプリケーションサーバとの暗号化及び認証された接続を確立することができる。その後、クライアントは、ＩＰＳｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）パケットフォーマットを用いて、暗号化されたパケットをアプリケーションサーバ１０６に送信可能である。ＩＰＳｅｃパケットヘッダフォーマットは、クライアントのＩＤ情報を有するＳＰＩ（Ｓｅｃｕｒｉｔｙ Ｐａｒａｍｅｔｅｒ Ｉｎｄｅｘ）フィールドを含む。
【００２６】
ＮＩＣ１２０がクライアント１００からＩＰＳｅｃパケットを受信すると、ＮＩＣ１２０内のロジックがＳＰＩ内でクライアントＩＤを検証し、ＫＤＳ１２４から受信したマスタ鍵を用いて、対称鍵のサーバサイドを、
セッション鍵＝ｆ（マスタ鍵，クライアントＳＰＩ）
などの鍵関数を利用して生成する。
【００２７】
ＮＩＣ１２０のバージョンのセッション鍵が生成されると、ＮＩＣ１２０は、クライアント１００からのパケットを解読し、解読されたパケットをアプリケーションサーバ１０６内のネットワークソフトウェアスタックに送信し、これにより、プロセッサ１１４とＯＳ１１８はパケットをサービスすることが可能となる。
【００２８】
いくつかの実施例では、パケットの解読が不成功であった場合、ＮＩＣ１２０はパケットを破棄することができる。これは、プロセッサ１１４が当該パケットを確認することがないため、プロセッサ１１４により実行されるオーバヘッドを解消することとなる。
【００２９】
上述したようなシステム及びＫＤＳ装置を利用して、ＫＤＳは、暗号鍵配信処理のすべてではないが大部分を実行し、これにより、アプリケーションサーバ１０６からかなりの負担を取り除くこととなる。さらに、ＮＩＣ１２０が独立に入力パケットを解読し、アプリケーションサーバ１０６のソフトウェアに常駐するネットワークスタックに解読されたパケットを送信することが可能であるため、アプリケーションサーバ１０６上に常駐するプロセッサ１１４とＯＳ１１８がさらに解読処理から取り除かれる。
【００３０】
多くの実施例では、ドメイン１０２に複数の分散されたＫＤＳが存在する。複数のＫＤＳが、多数のクライアントへの鍵配信のロードをバランスさせるなどと共に、ＫＤＳの機能を分散化することによってセキュリティを追加するなどの利益を提供し、何れかのサーバへの攻撃が鍵配信システムを回避することを不可能にする。複数のＫＤＳの間のロードをバランス指せるため、何れか一般的な分散化されたサーバのロードバランシングアルゴリズムが利用されてもよい。例えば、クライアント１００内のリゾルバプログラムは、ＤＮＳサーバ１１２とやりとりすることによりＫＤＳに対するＤＮＳ検索を実行した後、ＫＤＳの返されたＩＰアドレスをロードバランシングアルゴリズムに適用することができる。これは、クライアント鍵リクエストをドメインに存在する多数のＫＤＳの何れか１つに送信するかもしれない。
【００３１】
さらに、多数の実施例では、ＮＩＣ１２０は、入力されるクライアントパケットによって１以上の異常な状況が発生するとＫＤＳ１２４に通知するかもしれない。ＫＤＳ１２４は、ＫＤＳ１２４は、この異常行動がＮＩＣ１２０から通知されると、１以上のクライアントに関する適切なアクションをとるかもしれない。例えば、ＫＤＳ１２４は、鍵及び／又はクライアントについて取消リストを保存しているかもしれない。このため、ＮＩＣ１２０が、同一のクライアントＩＤであるが異なるＩＰアドレスを含むパケットを確認したことをＫＤＳ１２４に通知した場合、ＫＤＳ１２４は、クライアントＩＤに係る鍵を取消リストに加え、当該クライアントに新たな鍵を配信する。ＮＩＣ１２０がＫＤＳ１２４にこの新たな鍵が再び複数のクライアントにより使用されていることを通知した場合、鍵をリクエストしたクライアントは、取消リストに加えられ、ネットワーク上の任意のサーバとの当該クライアントのさらなる通信を永久に拒絶するかもしれない。
【００３２】
多数の実施例では、ＫＤＳ１２４がクライアントから受信する健全性情報はまた、クライアントの能力と潜在的な役割（すなわち、ポスチャ情報（ｐｏｓｔｕｒｅ ｉｎｆｏｒｍａｔｉｏｎ））を含む他のクライアント情報によりピギーバック（ｐｉｇｇｙｂａｃｋ）されるかもしれない。ＫＤＳ１２４は、この付加情報を利用して、クライアントが通信することが許可されるドメイン１０２内のサーバを決定するかもしれない。これにより、ＫＤＳ１２４は、この決定されたサーバ群と通信するのに利用される鍵を送信するかもしれない。
【００３３】
図２は、鍵配信サーバを用いて鍵情報を配信するプロセスの一実施例のフロー図である。当該プロセスは、ハードウェア、ソフトウェア又はこれらの組み合わせにより実行されるかもしれない。当該プロセスは、ドメインのＤＨＣＰサーバにドメインのＤＮＳサーバのＩＰアドレスとクライアントのＩＰアドレスとを提供するようリクエストするクライアントマシーンの処理ロジックにより開始される（処理ブロック２００）。その後、ＤＨＣＰサーバ内の処理ロジックは、ＤＮＳサーバとクライアントのＩＰアドレスにより応答する（処理ブロック２０２）。
【００３４】
当該処理は、クライアント内の処理ロジックがＤＮＳサーバがドメインのアプリケーションサーバのＩＰアドレスを検索するようリクエストすることにより継続される（処理ブロック２０４）。その後、ＤＮＳサーバ内の処理ロジックは、アプリケーションサーバのＩＰアドレスにより応答する（処理ブロック２０６）。クライアントリゾルバプログラム内の処理ロジックは、アプリケーションサーバのＩＰアドレスを用いて、アプリケーションサーバの健全性検証と認証ポリシーを検索するため、アプリケーションサーバをポーリングする（処理ブロック２０８）。
【００３５】
その後、アプリケーションサーバにおけるクライアントリゾルバポリシー検索の結果が、処理ロジックにより決定される（処理ブロック２１０）。アプリケーションサーバがポリシーを有していない場合、クライアント内の処理ロジックは、アプリケーションサーバに対する通常のＨＴＴＰリクエストに移行する（処理ブロック２１２）。
【００３６】
他方、健全性検証／認証ポリシーが存在する場合、処理ロジックは、ＫＤＳサーバがドメインに存在することを知る。クライアントの処理ロジックは、ＤＮＳサーバからのＫＤＳサーバのＩＰアドレスをリクエストする（処理ブロック２１４）。次に、ＤＮＳサーバは、ＫＤＳサーバのＩＰアドレスによりクライアントに応答する（処理ブロック２１６）。その後、クライアント内の処理ロジックは、クライアント健全性を測定する（処理ブロック２１８）。健全性の測定は、ＡＭＴ装置、又はクライアントマシーンが健全であり、危険でないことを検証するのに利用される他の装置を用いて実行されるかもしれない。その後、クライアント内の処理ロジックは、健全性情報と潜在的な他のポスチャ情報とをＫＤＳサーバに提供する（処理ブロック２２０）。
【００３７】
その後、ＫＤＳサーバ内の処理ロジックは、クライアントにより測定された健全性情報に対する検証手順を実行する（処理ブロック２２２）。この検証手順は、いくつかの健全性ポリシーの何れか１つとすることができる。これは、ドメインにおけるアプリケーションサーバへのクライアントアクセスに要求されるセキュリティレベルに基づき、サーバ毎に決定される。
【００３８】
この時点において、処理ロジックはクライアントの健全性を決定している（処理ブロック２２４）。クライアントがＫＤＳサーバにより健全でないとみなされた場合、ＫＤＳサーバは、クライアントにセッション鍵を送信しない（処理ブロック２２６）。他方、クライアントがＫＤＳサーバにより健全であるとみなされた場合、ＫＤＳサーバは、クライアントに一意的なセッション鍵（すなわち、派生鍵）を送信する（処理ブロック２２８）。クライアントがこの鍵を受信すると、クライアント内の処理ロジックは、この一意的なセッション鍵を用いてアプリケーションサーバへのセキュアなリクエストに移行する（処理ブロック２３０）。最後に、アプリケーションサーバのＮＩＣ内の処理ロジックは、クライアントからセキュアなリクエストを受信し、クライアントＩＤから導出されたセッション鍵とＫＤＳから提供されたマスタ鍵とを用いてパケットを解読する（処理ブロック２３２）。パケットが解読されると、パケットはアプリケーションサーバ内のさらなる処理のためネットワークソフトウェアスタックに送信可能であり、当該処理は終了する。
【００３９】
異常、サーバからクライアントにインターネットを介し対称鍵を配信する方法、装置及びシステムが説明された。これらの実施例は、具体的な実施例を参照して説明された。この開示の利益を有する者にとって、ここに記載された実施例の広範な趣旨及び範囲から逸脱することなくこれらの実施例に各種改良及び変更が可能であることは明らかであろう。明細書及び図面は、限定的なものでなく例示的なものとしてみなされるべきである。
【図面の簡単な説明】
【００４０】
【図１】図１は、インターネット上の対称鍵配信装置及びシステムを示す。
【図２】図２は、鍵配信サーバを用いて鍵情報を配信するプロセスの一実施例のフロー図である。
【符号の説明】
【００４１】
１００ クライアント
１０２ ドメイン
１０４ インターネット
１０６ アプリケーションサーバ
１０８ ファイアウォール
１１０ ＤＨＣＰサーバ
１１２ ＤＮＳサーバ
１１４ プロセッサ
１２０ ＮＩＣ
１２２ ＡＭＴ装置
【技術分野】
【０００１】
本発明は、インターネット上の各クライアントへの専用鍵配信サーバからの対称鍵の持続的及び動的な配信に関する。
【背景技術】
【０００２】
ワールド・ワイド・ウェブは、基本的にインターネット上で実行されるクライアント／サーバアプリケーションである。インターネットにおけるセキュリティ脅威は、数年間で指数的に増大してきた。様々なセキュリティ脅威を分類する１つの方法は、脅威の場所、すなわち、ウェブサーバ、クライアントウェブブラウザ及びクライアントウェブブラウザとサーバとの間のトラフィックに関するものである。クライアントとサーバとの間のトラフィックを考えると、コストのかかる非対称鍵暗号化（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎなど）を利用したクライアントとサーバとの間のセッション鍵のやりとりに依存するＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）ＩＰＳｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）及びＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）ベースのネットワークセキュリティプロトコルを配設することが容易である。サーバは、セッション単位でやりとりされる数万の一時的な対称鍵を記録する必要がある。その結果、ハードウェアによりこれらのプロトコルのための暗号化処理を実行するためのセキュリティ関連付けのためのメモリフェッチは、維持される必要がある状態数によりかなりコストがかかるものとなる（鍵のやりとりのコストは述べない）。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明の課題は、上記問題点に鑑み、インターネット上の各クライアントへの専用鍵配信サーバからの対称鍵の持続的及び動的な配信を可能にする方法、装置及びシステムを提供することである。
【課題を解決するための手段】
【０００４】
上記課題を解決するため、本発明の一特徴は、鍵配信サーバが、クライアントから測定された健全性情報を受け付けるステップと、前記サーバが、前記測定された健全性情報を検証するステップと、前記サーバが、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信するステップと、前記クライアントは、前記セッション鍵を受け付けると、前記セッション鍵を用いてドメイン内のアプリケーションサーバとの暗号化及び認証された接続を開始するステップとを有する方法に関する。
【０００５】
本発明の他の特徴は、クライアントから測定された健全性情報を受け付け、前記測定された健全性情報を検証し、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信する鍵配信サーバロジックを有する装置に関する。
【０００６】
本発明のさらなる他の特徴は、クライアントと、クライアントから測定された健全性情報を受け付け、前記測定された健全性情報を検証し、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信する鍵配信サーバロジックと、前記クライアントから前記セッション鍵を用いて暗号化されたパケットを受け付け、前記セッション鍵を用いて前記パケットを解読し、前記解読されたパケットにサービスを提供するアプリケーションサーバロジックとを有するシステムに関する。
【発明の効果】
【０００７】
本発明によると、インターネット上の各クライアントへの専用鍵配信サーバからの対称鍵の持続的及び動的な配信が可能になる。
【発明を実施するための最良の形態】
【０００８】
対称鍵をインターネットを介しサーバからクライアントに配信するための方法、装置及びシステムの実施例が説明される。以下の説明では、多数の具体的詳細が与えられる。しかしながら、各実施例はこれら具体的詳細なしに実現可能であることが理解される。他の例では、本発明を不明りょうにすることを避けるため、周知の要素、詳細及びプロトコルは詳細には説明されていない。
【０００９】
図１は、インターネットを介した対称鍵配信装置及びシステムを示す。多数の実施例において、クライアント１００はインターネット１０４を介しドメイン１０２に接続される。インターネットは、標準的なインターネットプロトコル（ＩＰ）などのプロトコルを用いてデータを送信する世界的に公衆に利用可能な相互接続されたコンピュータネットワーク群である。より詳細には、インターネットは、各種情報及びサービスを一緒になって伝送する数百万の小型の家庭用、学術用、企業用及び政府機関ネットワークから構成される“ネットワークのネットワーク”である。物理的には、インターネットは、情報を伝送する媒体からなる有線、光及び無線ネットワークバックボーンを含む。
【００１０】
異なる実施例では、クライアントは、デスクトップコンピュータ、ラップトップコンピュータ、モバイル無線装置、携帯電話、テレビ用セットトップボックス、又はインターネットに接続可能な他の何れかのタイプの計算装置であるかもしれない。インターネットへのクライアントの接続は、個別の装置をインターネットに接続する他の装置のうち、ルータ、スイッチ、アクセスポイントなどの機構を介したものであるかもしれない。
【００１１】
異なる実施例では、ドメインは、特に企業、科学機関、大学、政府オフィス、個人のネットワークなどのためのドメインであるかもしれない。ドメインは、当該ドメイン及びインターネット内のユーザとコンピュータとの間で情報がやりとりされるのを可能にするいくつかの機能を実行する１以上のコンピュータシステムサーバから構成される。各ドメインは、特定のＩＰアドレスにマップされるドメイン名を有する。
【００１２】
図１は、ドメイン内の不可欠な機能を実行するいくつかのサーバの一例を示す。異なる実施例では、これらのサーバは物理的に分離したマシーンであるかもしれず、又は１つのマシーン上で実行されるアプリケーション（マシーン上の各パーティションなどにおいて）であるかもしれない。
【００１３】
クライアントは、サービス用のドメイン１０２へのアクセスをリクエストするかもしれない。多くの実施例では、ドメイン内にあるアプリケーションサーバ１０６は、クライアント１００が所望するこれらのサービス（情報記憶サービス、ニュース抽出サービス、電子メールサービスなど）の１以上を提供する。
【００１４】
多くの実施例では、ドメイン１０２はファイアウォール１０８を有する。ファイアウォール１０８は、悪意のあるユーザ及びプログラムがインターネット１０４から当該ドメインに侵入することを防ぐためのセキュリティの一形態である。ファイアウォール１０８は、独立したサーバ（図示される）であってもよく、又は図１のその他のサーバの１つの一部であってもよい（図示せず）。
【００１５】
ドメインはまた、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバ１１０を含む。クライアント１００がＤＨＣＰ設定されていることが前提とされているため、クライアント１００がドメイン１０２に接続すると、クライアント１００のＤＨＣＰクライアントプログラムは、ＤＨＣＰサーバ１１０から必要な情報をリクエストするブロードキャストクエリを送信する。ＤＨＣＰサーバ１１０は、ＩＰアドレスと、ドメイン名やデフォルトゲートウェイなどのクライアント設定パラメータに関する情報とのプールを管理する。さらに、ＤＨＣＰサーバ１１０は、ドメイン１０２にあるＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバ１１２の有無及びアドレスに関する情報を有する。クライアント１００から有効なリクエストを受信すると、ＤＨＣＰサーバ１１０は、クライアント１００にＩＰアドレスと他のパラメータとを割り当てる。
【００１６】
この時点でＤＨＣＰサーバ１１０から受信したＩＰアドレスとＤＮＳサーバ１１２のアドレスとによって設定されたクライアント１００は、ＤＮＳサーバ１１２とやりとりすることができる。ＤＮＳサーバ１１２は、ドメイン１０２内のサーバ及び他の装置のＩＰアドレスを提供する。
【００１７】
アプリケーションサーバ１０６に戻って、１以上のプロセッサ１１４がアプリケーションサーバ１０６上に存在する。異なる実施例では、これらのプロセッサのそれぞれはシングル又はマルチコアであるかもしれない。いくつかの実施例では、アプリケーションサーバは、マルチプロセッサマルチコアサーバであり、他の実施例では、アプリケーションサーバは、シングルプロセッサシングルコアサーバであり、さらなる他の実施例では、アプリケーションサーバは、上述したシングル／マルチプロセッサシングル／マルチコアシステムの組み合わせの派生である。さらなる実施例では、追加的なサービスについて複数のアプリケーションサーバが存在してもよく、又は同一のサービスが、クライアントの不可をバランスさせるため、複数のアプリケーションサーバに分散されてもよい。図１では、上述したプロセッサ及びサーバコンフィギュレーションの多くは示されていない。これは、単一のサーバ上の単一のプロセッサが、クライアント／サーバ状況を説明するため適切な実施例を提供するためである。
【００１８】
さらに、アプリケーションサーバ１０６はまた、オペレーティングシステム（ＯＳ）１１８などの１以上のオペレーティングシステムの現在のインスタンスを格納するためのシステムメモリ１１６を有する。通常処理では、アプリケーションサーバ１０６のプロセッサ１１４は、クライアント１００などのインターネット１０４上のクライアントから複数のリクエストについてサービスを提供するかもしれない。ＤＨＣＰサーバ１１０とＤＮＳサーバ１１２によるルーティング手順の実行後、クライアントは通常、アプリケーションサーバのサービスにアクセスするため、アプリケーションサーバ１０６とやりとりする。
【００１９】
多くの実施例では、アプリケーションサーバ１０６は、それがやりとりするクライアントについて要求する１以上の健全性ポリシーを有するかもしれない。例えば、クライアントがアプリケーションサーバ１０６とやりとりするためのアクセスが与えられる前に、クライアントが超える必要がある最小限に要求される健全性レベルが存在するかもしれない。これらの健全性レベルは、予め決定されてもよく、又は環境に応じて動的に決定されてもよい。健全性レベルがクライアントに満たされていない場合、ネットワークインタフェースコントローラ（ＮＩＣ）１２０は、当該クライアントからのパケットを破棄する。ＮＩＣ１２０は、アプリケーションサーバ１０６がドメイン内の内部コンピュータネットワークにアクセスすることを許可及び処理するハードウェアインタフェースである。
【００２０】
クライアント健全性を安全に決定するため、多くの実施例では、インテル（登録商標）のＡＭＴ（Ａｃｔｉｖｅ Ｍａｎａｇｅｍｅｎｔ Ｔｅｃｈｎｏｌｏｇｙ）装置１２２又はＡＭＴと同様に実行される他の独立したセキュリティ測定装置がクライアント１００内に存在する。いくつかの実施例では、ＡＭＴ１２２はクライアントシステムの健全性を測定するかもしれない。この測定は、クライアントにインストールされたソフトウェア、クライアントにインストールされたオペレーティングシステム、クライアントにインストールされたアンチウイルスソフトウェアのバージョン、どの程度最近いくつの攻撃がクライアントシステムが処理したかなどの情報を含むかもしれない。ＡＭＴ１２２内のロジックがこの情報を取得するか、又はクライアント１００内の何れかのロジックが健全性情報を取得し、ＡＭＴ１２２が健全性情報を真正性を検証するかもしれない。この健全性情報が取得されると、ＡＭＴ１２２はセキュアなデジタル証明書により健全性情報を署名するかもしれない。クライアント１００は、セキュアな健全性情報をインターネット１０４を介しドメイン１０２に送信するかもしれない。
【００２１】
多くの実施例では、クライアント１００は、何れの要求がアプリケーションサーバ１０６とやりとりするのに必要であるか確認するため、アプリケーションサーバ１０６から健全性ポリシー要求をリクエストする。多くの実施例では、クライアント１００上で実行されるリゾルバプログラム（ｒｅｓｏｌｖｅｒ ｐｒｏｇｒａｍ）が、アプリケーションサーバ１０６に関する要求されるクライアント健全性ポリシーを調べる。このリクエストは、ＮＩＣ１２０により直接処理されるかもしれない。ＮＩＣ１２０は、それが常駐するアプリケーションサーバ１０６に係る健全性ポリシー情報を格納し、何れかのクライアントからの健全性ポリシーリクエストについてサービスを提供することが可能であり、このため、何れの初期的なリクエストロードもプロセッサ１１４、メモリ１１６又はＯＳ１１８との直接的なやりとりを要求しない。
【００２２】
クライアントに対する健全性ポリシー要求に加えて、リゾルバプログラムは、アプリケーションサーバに対するクライアント健全性ポリシールックアップの実行後、要求元のクライアントにドメイン１０２が１以上の鍵配信サーバ（ＫＤＳ）１２４を含むことを通知するかもしれない。この情報は、検索中にリゾルバプログラムにより取得される。ＫＤＳ１２４は、クライアントから受信した健全性情報を検証することができる。検証されると、ＫＤＳ１２４は、アプリケーションサーバ１０６とのセキュアなやりとりのため、クライアントに固有のセッション鍵をクライアントに提供することができる。ドメイン１０２のＫＤＳ１２４がアプリケーションサーバ１０６により信頼されていることが前提とされる。
【００２３】
アプリケーションサーバのＮＩＣ１２０には、セッション鍵を生成するためのマスタ鍵がＫＤＳ１２４により与えられるかもしれない。例えば、ＫＤＳ１２４がクライアントの健全性を認証すると、ＫＤＳは、クライアント１００とアプリケーションサーバ１０６との間のセッションのためのマスタ鍵を生成することができる。ＫＤＳ１２４は、クライアントＩＤ情報とマスタ鍵とから生成されたセッション鍵をクライアント１００に送信する。
【００２４】
いくつかの実施例では、セッション鍵は、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）プロトコルを用いてクライアントに送信される。他の実施例では、セッション鍵は、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）プロトコルを用いてクライアントに送信される。ＴＬＳ及びＳＳＬプロトコルは、盗聴、改ざん及びメッセージ偽造を防ぐよう設計された方法によるネットワーク上のプライベート通信を可能にする。これらのプロトコルは、暗号化を利用してインターネット上のエンドポイント認証及び通信プライバシを提供する。
【００２５】
ＫＤＳ１２４はまた、アプリケーションサーバ１０６のＮＩＣ１２０にマスタ鍵を送信する。ＫＤＳ１２４から受信したセッション鍵を利用して、クライアントは、アプリケーションサーバとの暗号化及び認証された接続を確立することができる。その後、クライアントは、ＩＰＳｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）パケットフォーマットを用いて、暗号化されたパケットをアプリケーションサーバ１０６に送信可能である。ＩＰＳｅｃパケットヘッダフォーマットは、クライアントのＩＤ情報を有するＳＰＩ（Ｓｅｃｕｒｉｔｙ Ｐａｒａｍｅｔｅｒ Ｉｎｄｅｘ）フィールドを含む。
【００２６】
ＮＩＣ１２０がクライアント１００からＩＰＳｅｃパケットを受信すると、ＮＩＣ１２０内のロジックがＳＰＩ内でクライアントＩＤを検証し、ＫＤＳ１２４から受信したマスタ鍵を用いて、対称鍵のサーバサイドを、
セッション鍵＝ｆ（マスタ鍵，クライアントＳＰＩ）
などの鍵関数を利用して生成する。
【００２７】
ＮＩＣ１２０のバージョンのセッション鍵が生成されると、ＮＩＣ１２０は、クライアント１００からのパケットを解読し、解読されたパケットをアプリケーションサーバ１０６内のネットワークソフトウェアスタックに送信し、これにより、プロセッサ１１４とＯＳ１１８はパケットをサービスすることが可能となる。
【００２８】
いくつかの実施例では、パケットの解読が不成功であった場合、ＮＩＣ１２０はパケットを破棄することができる。これは、プロセッサ１１４が当該パケットを確認することがないため、プロセッサ１１４により実行されるオーバヘッドを解消することとなる。
【００２９】
上述したようなシステム及びＫＤＳ装置を利用して、ＫＤＳは、暗号鍵配信処理のすべてではないが大部分を実行し、これにより、アプリケーションサーバ１０６からかなりの負担を取り除くこととなる。さらに、ＮＩＣ１２０が独立に入力パケットを解読し、アプリケーションサーバ１０６のソフトウェアに常駐するネットワークスタックに解読されたパケットを送信することが可能であるため、アプリケーションサーバ１０６上に常駐するプロセッサ１１４とＯＳ１１８がさらに解読処理から取り除かれる。
【００３０】
多くの実施例では、ドメイン１０２に複数の分散されたＫＤＳが存在する。複数のＫＤＳが、多数のクライアントへの鍵配信のロードをバランスさせるなどと共に、ＫＤＳの機能を分散化することによってセキュリティを追加するなどの利益を提供し、何れかのサーバへの攻撃が鍵配信システムを回避することを不可能にする。複数のＫＤＳの間のロードをバランス指せるため、何れか一般的な分散化されたサーバのロードバランシングアルゴリズムが利用されてもよい。例えば、クライアント１００内のリゾルバプログラムは、ＤＮＳサーバ１１２とやりとりすることによりＫＤＳに対するＤＮＳ検索を実行した後、ＫＤＳの返されたＩＰアドレスをロードバランシングアルゴリズムに適用することができる。これは、クライアント鍵リクエストをドメインに存在する多数のＫＤＳの何れか１つに送信するかもしれない。
【００３１】
さらに、多数の実施例では、ＮＩＣ１２０は、入力されるクライアントパケットによって１以上の異常な状況が発生するとＫＤＳ１２４に通知するかもしれない。ＫＤＳ１２４は、ＫＤＳ１２４は、この異常行動がＮＩＣ１２０から通知されると、１以上のクライアントに関する適切なアクションをとるかもしれない。例えば、ＫＤＳ１２４は、鍵及び／又はクライアントについて取消リストを保存しているかもしれない。このため、ＮＩＣ１２０が、同一のクライアントＩＤであるが異なるＩＰアドレスを含むパケットを確認したことをＫＤＳ１２４に通知した場合、ＫＤＳ１２４は、クライアントＩＤに係る鍵を取消リストに加え、当該クライアントに新たな鍵を配信する。ＮＩＣ１２０がＫＤＳ１２４にこの新たな鍵が再び複数のクライアントにより使用されていることを通知した場合、鍵をリクエストしたクライアントは、取消リストに加えられ、ネットワーク上の任意のサーバとの当該クライアントのさらなる通信を永久に拒絶するかもしれない。
【００３２】
多数の実施例では、ＫＤＳ１２４がクライアントから受信する健全性情報はまた、クライアントの能力と潜在的な役割（すなわち、ポスチャ情報（ｐｏｓｔｕｒｅ ｉｎｆｏｒｍａｔｉｏｎ））を含む他のクライアント情報によりピギーバック（ｐｉｇｇｙｂａｃｋ）されるかもしれない。ＫＤＳ１２４は、この付加情報を利用して、クライアントが通信することが許可されるドメイン１０２内のサーバを決定するかもしれない。これにより、ＫＤＳ１２４は、この決定されたサーバ群と通信するのに利用される鍵を送信するかもしれない。
【００３３】
図２は、鍵配信サーバを用いて鍵情報を配信するプロセスの一実施例のフロー図である。当該プロセスは、ハードウェア、ソフトウェア又はこれらの組み合わせにより実行されるかもしれない。当該プロセスは、ドメインのＤＨＣＰサーバにドメインのＤＮＳサーバのＩＰアドレスとクライアントのＩＰアドレスとを提供するようリクエストするクライアントマシーンの処理ロジックにより開始される（処理ブロック２００）。その後、ＤＨＣＰサーバ内の処理ロジックは、ＤＮＳサーバとクライアントのＩＰアドレスにより応答する（処理ブロック２０２）。
【００３４】
当該処理は、クライアント内の処理ロジックがＤＮＳサーバがドメインのアプリケーションサーバのＩＰアドレスを検索するようリクエストすることにより継続される（処理ブロック２０４）。その後、ＤＮＳサーバ内の処理ロジックは、アプリケーションサーバのＩＰアドレスにより応答する（処理ブロック２０６）。クライアントリゾルバプログラム内の処理ロジックは、アプリケーションサーバのＩＰアドレスを用いて、アプリケーションサーバの健全性検証と認証ポリシーを検索するため、アプリケーションサーバをポーリングする（処理ブロック２０８）。
【００３５】
その後、アプリケーションサーバにおけるクライアントリゾルバポリシー検索の結果が、処理ロジックにより決定される（処理ブロック２１０）。アプリケーションサーバがポリシーを有していない場合、クライアント内の処理ロジックは、アプリケーションサーバに対する通常のＨＴＴＰリクエストに移行する（処理ブロック２１２）。
【００３６】
他方、健全性検証／認証ポリシーが存在する場合、処理ロジックは、ＫＤＳサーバがドメインに存在することを知る。クライアントの処理ロジックは、ＤＮＳサーバからのＫＤＳサーバのＩＰアドレスをリクエストする（処理ブロック２１４）。次に、ＤＮＳサーバは、ＫＤＳサーバのＩＰアドレスによりクライアントに応答する（処理ブロック２１６）。その後、クライアント内の処理ロジックは、クライアント健全性を測定する（処理ブロック２１８）。健全性の測定は、ＡＭＴ装置、又はクライアントマシーンが健全であり、危険でないことを検証するのに利用される他の装置を用いて実行されるかもしれない。その後、クライアント内の処理ロジックは、健全性情報と潜在的な他のポスチャ情報とをＫＤＳサーバに提供する（処理ブロック２２０）。
【００３７】
その後、ＫＤＳサーバ内の処理ロジックは、クライアントにより測定された健全性情報に対する検証手順を実行する（処理ブロック２２２）。この検証手順は、いくつかの健全性ポリシーの何れか１つとすることができる。これは、ドメインにおけるアプリケーションサーバへのクライアントアクセスに要求されるセキュリティレベルに基づき、サーバ毎に決定される。
【００３８】
この時点において、処理ロジックはクライアントの健全性を決定している（処理ブロック２２４）。クライアントがＫＤＳサーバにより健全でないとみなされた場合、ＫＤＳサーバは、クライアントにセッション鍵を送信しない（処理ブロック２２６）。他方、クライアントがＫＤＳサーバにより健全であるとみなされた場合、ＫＤＳサーバは、クライアントに一意的なセッション鍵（すなわち、派生鍵）を送信する（処理ブロック２２８）。クライアントがこの鍵を受信すると、クライアント内の処理ロジックは、この一意的なセッション鍵を用いてアプリケーションサーバへのセキュアなリクエストに移行する（処理ブロック２３０）。最後に、アプリケーションサーバのＮＩＣ内の処理ロジックは、クライアントからセキュアなリクエストを受信し、クライアントＩＤから導出されたセッション鍵とＫＤＳから提供されたマスタ鍵とを用いてパケットを解読する（処理ブロック２３２）。パケットが解読されると、パケットはアプリケーションサーバ内のさらなる処理のためネットワークソフトウェアスタックに送信可能であり、当該処理は終了する。
【００３９】
異常、サーバからクライアントにインターネットを介し対称鍵を配信する方法、装置及びシステムが説明された。これらの実施例は、具体的な実施例を参照して説明された。この開示の利益を有する者にとって、ここに記載された実施例の広範な趣旨及び範囲から逸脱することなくこれらの実施例に各種改良及び変更が可能であることは明らかであろう。明細書及び図面は、限定的なものでなく例示的なものとしてみなされるべきである。
【図面の簡単な説明】
【００４０】
【図１】図１は、インターネット上の対称鍵配信装置及びシステムを示す。
【図２】図２は、鍵配信サーバを用いて鍵情報を配信するプロセスの一実施例のフロー図である。
【符号の説明】
【００４１】
１００ クライアント
１０２ ドメイン
１０４ インターネット
１０６ アプリケーションサーバ
１０８ ファイアウォール
１１０ ＤＨＣＰサーバ
１１２ ＤＮＳサーバ
１１４ プロセッサ
１２０ ＮＩＣ
１２２ ＡＭＴ装置
【特許請求の範囲】
【請求項１】
鍵配信サーバが、クライアントから測定された健全性情報を受け付けるステップと、
前記サーバが、前記測定された健全性情報を検証するステップと、
前記サーバが、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信するステップと、
前記クライアントは、前記セッション鍵を受け付けると、前記セッション鍵を用いてドメイン内のアプリケーションサーバとの暗号化及び認証された接続を開始するステップと、
を有する方法。
【請求項２】
前記アプリケーションサーバ内のＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）が、前記認証された接続を介し前記クライアントから１以上の暗号化されたパケットを受け付けるステップと、
前記ＮＩＣが、前記セッション鍵を用いて前記１以上の暗号化されたパケットを解読するステップと、
前記アプリケーションサーバが、前記１以上の解読されたパケットにサービスを提供するステップと、
をさらに有する、請求項１記載の方法。
【請求項３】
前記ＮＩＣは、前記解読が不成功であった場合、前記１以上のパケットを破棄するステップをさらに有する、請求項２記載の方法。
【請求項４】
前記鍵配信サーバは、インターネットドメイン内でアドレス指定可能である、請求項１記載の方法。
【請求項５】
前記クライアントは、前記鍵配信サーバ上のクライアントポリシーを検索するステップと、
前記鍵配信サーバのクライアントポリシーに基づき、前記クライアントが、前記クライアントの健全性情報を測定するステップと、
前記クライアントが、前記クライアントの測定された健全性情報を署名するステップと、
をさらに有する、請求項４記載の方法。
【請求項６】
前記１以上の暗号化されたパケットは、ＩＰＳｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）パケットである、請求項２記載の方法。
【請求項７】
クライアントから測定された健全性情報を受け付け、
前記測定された健全性情報を検証し、
前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信する鍵配信サーバロジックを有する装置。
【請求項８】
前記クライアントから前記セッション鍵を用いて暗号化されたパケットを受け付け、
前記セッション鍵を用いて前記パケットを解読し、
前記解読されたパケットにサービスを提供するアプリケーションサーバロジックをさらに有する、請求項７記載の装置。
【請求項９】
前記アプリケーションサーバロジックはさらに、前記解読が不成功であった場合、前記パケットを破棄するよう動作可能である、請求項８記載の装置。
【請求項１０】
当該装置は、インターネットドメイン内でアドレス指定可能である、請求項８記載の装置。
【請求項１１】
当該装置はさらに、当該装置とやりとりするのに必要な１以上の要求に従って前記クライアントに維持するためのクラインとポリシーを格納するよう動作可能である、請求項８記載の装置。
【請求項１２】
前記アプリケーションサーバロジックはさらに、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）を有する、請求項８記載の装置。
【請求項１３】
クライアントと、
クライアントから測定された健全性情報を受け付け、前記測定された健全性情報を検証し、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信する鍵配信サーバロジックと、
前記クライアントから前記セッション鍵を用いて暗号化されたパケットを受け付け、前記セッション鍵を用いて前記パケットを解読し、前記解読されたパケットにサービスを提供するアプリケーションサーバロジックと、
を有するシステム。
【請求項１４】
前記アプリケーションサーバロジックはさらに、前記解読が不成功であった場合、前記パケットを破棄するよう動作可能である、請求項１３記載のシステム。
【請求項１５】
前記鍵配信サーバのアドレスを前記クライアントに提供するドメイン名サーバをさらに有する、請求項１３記載のシステム。
【請求項１６】
前記クライアントは、前記クライアントの装置の健全性を測定し、測定結果に基づきクライアントの健全性情報を生成し、前記測定されたクライアントの健全性情報を所望するよう動作可能なセキュリティ管理コンポーネントを有する、請求項１３記載のシステム。
【請求項１７】
前記アプリケーションサーバはさらに、
オペレーティングシステムを格納するメモリと、
前記オペレーティングシステムからの命令を実行するプロセッサと、
前記セッション鍵とマスタ鍵とを用いて解読鍵を生成し、前記解読鍵により前記パケットを解読し、前記プロセッサによるサービス提供のため、前記解読されたパケットを前記オペレーティングシステムに送信するよう動作可能なＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）と、
をさらに有する、請求項１３記載のシステム。
【請求項１８】
前記ＮＩＣはさらに、前記解読が不成功であった場合、前記パケットを破棄するよう動作可能である、請求項１７記載のシステム。
【請求項１９】
前記プロセッサは、前記ＮＩＣが前記パケットを破棄すると、前記パケットに対して何れの処理も実行しない、請求項１８記載のシステム。
【請求項１】
鍵配信サーバが、クライアントから測定された健全性情報を受け付けるステップと、
前記サーバが、前記測定された健全性情報を検証するステップと、
前記サーバが、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信するステップと、
前記クライアントは、前記セッション鍵を受け付けると、前記セッション鍵を用いてドメイン内のアプリケーションサーバとの暗号化及び認証された接続を開始するステップと、
を有する方法。
【請求項２】
前記アプリケーションサーバ内のＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）が、前記認証された接続を介し前記クライアントから１以上の暗号化されたパケットを受け付けるステップと、
前記ＮＩＣが、前記セッション鍵を用いて前記１以上の暗号化されたパケットを解読するステップと、
前記アプリケーションサーバが、前記１以上の解読されたパケットにサービスを提供するステップと、
をさらに有する、請求項１記載の方法。
【請求項３】
前記ＮＩＣは、前記解読が不成功であった場合、前記１以上のパケットを破棄するステップをさらに有する、請求項２記載の方法。
【請求項４】
前記鍵配信サーバは、インターネットドメイン内でアドレス指定可能である、請求項１記載の方法。
【請求項５】
前記クライアントは、前記鍵配信サーバ上のクライアントポリシーを検索するステップと、
前記鍵配信サーバのクライアントポリシーに基づき、前記クライアントが、前記クライアントの健全性情報を測定するステップと、
前記クライアントが、前記クライアントの測定された健全性情報を署名するステップと、
をさらに有する、請求項４記載の方法。
【請求項６】
前記１以上の暗号化されたパケットは、ＩＰＳｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）パケットである、請求項２記載の方法。
【請求項７】
クライアントから測定された健全性情報を受け付け、
前記測定された健全性情報を検証し、
前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信する鍵配信サーバロジックを有する装置。
【請求項８】
前記クライアントから前記セッション鍵を用いて暗号化されたパケットを受け付け、
前記セッション鍵を用いて前記パケットを解読し、
前記解読されたパケットにサービスを提供するアプリケーションサーバロジックをさらに有する、請求項７記載の装置。
【請求項９】
前記アプリケーションサーバロジックはさらに、前記解読が不成功であった場合、前記パケットを破棄するよう動作可能である、請求項８記載の装置。
【請求項１０】
当該装置は、インターネットドメイン内でアドレス指定可能である、請求項８記載の装置。
【請求項１１】
当該装置はさらに、当該装置とやりとりするのに必要な１以上の要求に従って前記クライアントに維持するためのクラインとポリシーを格納するよう動作可能である、請求項８記載の装置。
【請求項１２】
前記アプリケーションサーバロジックはさらに、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）を有する、請求項８記載の装置。
【請求項１３】
クライアントと、
クライアントから測定された健全性情報を受け付け、前記測定された健全性情報を検証し、前記測定された健全性情報が検証されると、前記クライアントにセッション鍵を送信する鍵配信サーバロジックと、
前記クライアントから前記セッション鍵を用いて暗号化されたパケットを受け付け、前記セッション鍵を用いて前記パケットを解読し、前記解読されたパケットにサービスを提供するアプリケーションサーバロジックと、
を有するシステム。
【請求項１４】
前記アプリケーションサーバロジックはさらに、前記解読が不成功であった場合、前記パケットを破棄するよう動作可能である、請求項１３記載のシステム。
【請求項１５】
前記鍵配信サーバのアドレスを前記クライアントに提供するドメイン名サーバをさらに有する、請求項１３記載のシステム。
【請求項１６】
前記クライアントは、前記クライアントの装置の健全性を測定し、測定結果に基づきクライアントの健全性情報を生成し、前記測定されたクライアントの健全性情報を所望するよう動作可能なセキュリティ管理コンポーネントを有する、請求項１３記載のシステム。
【請求項１７】
前記アプリケーションサーバはさらに、
オペレーティングシステムを格納するメモリと、
前記オペレーティングシステムからの命令を実行するプロセッサと、
前記セッション鍵とマスタ鍵とを用いて解読鍵を生成し、前記解読鍵により前記パケットを解読し、前記プロセッサによるサービス提供のため、前記解読されたパケットを前記オペレーティングシステムに送信するよう動作可能なＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）と、
をさらに有する、請求項１３記載のシステム。
【請求項１８】
前記ＮＩＣはさらに、前記解読が不成功であった場合、前記パケットを破棄するよう動作可能である、請求項１７記載のシステム。
【請求項１９】
前記プロセッサは、前記ＮＩＣが前記パケットを破棄すると、前記パケットに対して何れの処理も実行しない、請求項１８記載のシステム。
【図１】
【図２】
【図２】
【公開番号】特開２００９−１４７９２７（Ｐ２００９−１４７９２７Ａ）
【公開日】平成２１年７月２日（２００９．７．２）
【国際特許分類】
【出願番号】特願２００８−３０７４５８（Ｐ２００８−３０７４５８）
【出願日】平成２０年１２月２日（２００８．１２．２）
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
【公開日】平成２１年７月２日（２００９．７．２）
【国際特許分類】
【出願日】平成２０年１２月２日（２００８．１２．２）
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
[ Back to top ]