トラフィック可視性を備えたエンドツーエンド・ネットワークのセキュリティのための効率的な鍵の導出
【課題】エンドツーエンド・セキュリティおよびトラフィック可視性の両方を実現するシステムを構築する。
【解決手段】導出鍵および各データ・パケットで伝送されるクライアント識別子に基づいて各クライアントに対して異なる暗号鍵を導出する制御装置を使用するシステムにより達成する。制御装置は、トラフィック可視性を提供するために情報技術モニタ装置に導出鍵およびサーバに配分する。さらに、エンドツーエンド・セキュリティが達成されるように、クライアント鍵およびクライアント識別子が使用されてもよい。
【解決手段】導出鍵および各データ・パケットで伝送されるクライアント識別子に基づいて各クライアントに対して異なる暗号鍵を導出する制御装置を使用するシステムにより達成する。制御装置は、トラフィック可視性を提供するために情報技術モニタ装置に導出鍵およびサーバに配分する。さらに、エンドツーエンド・セキュリティが達成されるように、クライアント鍵およびクライアント識別子が使用されてもよい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、トラフィック可視性を備えたエンドツーエンド・ネットワークのセキュリティのための効率的な鍵の導出に関する。
【背景技術】
【０００２】
多くのネットワーク・セキュリティ・プロトコルは、費用のかかる非対称な暗号を使用して、クライアントとサーバとの間のセッション鍵の交渉に基づき、さらに、各クライアント・セッションのために極めて多くの対称な鍵を追跡（トラッキング）することを要求する。エンドツーエンド・セキュリティは、ネットワークにおける通信の一方端から全ての方向への他方端、つまり、クライアントからサーバ、および、サーバからクライアントにデータ認証および／またはデータの機密性があることを意味する。トラフィックの可視性は、装置をモニタするサーバおよび情報技術（ＩＴ）がセキュアなトラフィックを見ることができることを意味する。これら２つのゴールは、ある程度、互いに相反するものではあるが、両方ともネットワーク・セキュリティにとって重要である。
【０００３】
エンドツーエンド・セキュリティは、クライアントとサーバとの間のトラフィックを改ざんする第三者を除外するために、クライアントとサーバの双方にとって重要であるが、クライアントは、直接的な操りあるいは改ざんに最も危険に晒される。このように、クライアントの秘密の一意性は、一方のクライアントの妥協が他方のクライアントのトラフィックへのアクセス増加を防止するために重要である。トラフィックの可視性は、ＩＴ管理に不可欠で、異常現象を検出するためにＩＴ管理にトラフィック観察を要求する。現在の多くの主要なセキュリティ・プロトコルは、トラフィックの可視性に対する懸念なしにエンドツーエンド・セキュリティを単に提供している。
【０００４】
近年、産業界は、効率性のために、パケット暗号化および認証の両方のために単一鍵の結合モード暗号（ｓｉｎｇｌｅ−ｋｅｙ ｃｏｍｂｉｎｅｄ ｍｏｄｅ ｃｉｐｅｒ）に進展している。米国ＮＩＳＴによって指定されたＡｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（ＡＥＳ）は、ほとんどのネットワーク・セキュリティ・プロトコルにとってデファクト方法となっている。例えば、ＡＥＳ−ＧＣＭ（ガロア域カウンタ・モード）がＩＰｓｅｃプロトコルのスキームに推奨されている。米国ＮＩＳＴおよびＮＳＡは、鍵サイズの選択に対するガイダンスを提供している。今日の大多数の適用では、ＡＥＳ１２８を備える１２８ビット鍵のオペレーションが使用される。しかしながら、今後、より高いセキュリティ・レベルの適用のために、ＡＥＳ２５６を備える２５６ビット鍵のオペレーションが必要となるかもしれない。今日の方法では、ＡＥＳ２５６を備える２５６ビット鍵のオペレーションに対する鍵導出のレイテンシは、ＡＥＳ１２８を備える１２８ビット鍵のオペレーションに対する鍵導出よりはるかに長い。鍵導出の伝統的な方法は、一方向のハッシュ関数の反復によるシリアルな動作であるが、それはハードウェアにおいてもより遅い。
【図面の簡単な説明】
【０００５】
本発明の実施例は、添付図面に示された代表的な実施例によって記述されているが、制限的なものではなく、類似の参照番号は類似の要素を表示する。
【図１】本発明の様々な実施例に従う企業ネットワークのセキュリティ図である。
【図２】様々な実施例に従うクライアント・プラットフォーム上のシーケンス図である。
【図３】様々な実施例に従う別のクライアント・プラットフォーム・シーケンスである。
【図４】様々な実施例に従うサーバ・シーケンスである。
【図５】様々な実施例に従う別のシーケンスである。
【図６】様々な実施例に従うハードウェア図である。
【図７】ＮＩＳＴの仕様に基づいたＡＥＳ１２８とＡＥＳ２５６オペレーションを表す。
【発明を実施するための形態】
【０００６】
本発明の実施例は、認可されたＩＴ装置によるトラフィックの可視性を具備するエンドツーエンド・ネットワーク・セキュリティのための効率的な鍵導出を提供する。ハードウェアに基づいた、ワイヤ速度のエンドツーエンド暗号化および認証は、異なるセキュリティ組織に対処するためにスモールおよびラージ鍵サイズ双方のための効率的な鍵導出メカニズムを使用して、フレームベースで達成される。以下詳細に記述されるように、スモール鍵（例えば、１２８ビットの鍵）に対して、本発明の実施例は、鍵を導出するためにＡＥＳ１２８オペレーションを使用し、それは、ＡＥＳ１２８ではわずか１０ラウンド（回）のオペレーションによるより短いレイテンシを有するという長所を具備する。よりラージな鍵に対して、本発明の実施例は、ＡＥＳ１２８オペレーションを使用して並行実行による鍵導出を可能にする導出式を提案し、それはラージ鍵（例えば、２５６ビットの鍵）の鍵導出を著しくスピードアップさせる。
【０００７】
クライアントとサーバは、導出鍵およびその関連する導出情報を認証されたクライアントに、また導出鍵を認証されたサーバに与えるドメイン・コントローラと通信する。特定のクライアントからフレームを受け取ると、サーバ・ハードウェアは、そのフレームから鍵の導出情報を抽出し、その導出鍵をこの情報に適用し、このようにして、セッション鍵を照合しかつ交渉する必要性なしにフレームに使用された暗号鍵を引き出す。あるクライアントに与えられた導出鍵は、他のクライアントに知られることはないであろうし、演算による推測が行われることもないであろう。サーバだけがその関連するクライアント鍵を引き出すことができる。トラフィックの可視性問題を解決するために、ドメイン・コントローラは、さらに、導出鍵を、例えばＩＴモニタ装置／ホストのように、権限の付与されたＩＴネットワーク機器へ送ってもよい。権限の付与されたＩＴネットワーク機器がサーバと同じ導出鍵メカニズムを有するので、権限の付与されたＩＴネットワーク機器は、十分なワイヤ速度で暗号化された通過トラフィックを解読し、その権限の付与されたＩＴネットワーク機器によってトラフィックの可視性を可能にすることができる。
【０００８】
研究開発の成果を他の当業者へ伝えるために、実証された実施例の様々な側面が当業者によって普通に使用される用語を用いて記述されるであろう。しかしながら、代替の実施例が記述された側面のうちのいくつかにのみ実施されてもよいことは、当業者には明白であろう。特定の数、材料、および配置は、実証された実施例についての完全な理解を提供するために、説明をする目的のために述べられる。代替の実施例が特定の詳細な事項がなくても実施できることを当業者には明らかであろう。他の例では、周知の特徴は、実証された実施例を不明瞭にしないために、省略されるか単純化される。
【０００９】
さらに、実証された実施例を理解する際に最も有効な方法で、様々な動作を複数の個別の動作として記述するが、その記述の順序は、これらの動作が必ずその順序に依存するものであることを暗示するものとして解釈されるべきでない。特に、これらの動作が提示された順序で実行する必要はない。本出願の目的のために、その内容が明らかに他のことを示していない限り、用語「フレーム」および「パケット」は交換可能であると考えられる。
【００１０】
図１は、本発明の様々な実施例に従って、エンタープライズ（企業）ネットワーク・セキュリティ図１０を示す。図１を参照して、企業ネットワーク１４は、多くのクライアント１２を１またはそれ以上のサーバ１６と通信するために導入される。企業ドメイン・コントローラ２０は、全企業に対するエンドツーエンド・セキュリティを維持するため、およびサーバ１６およびＩＴモニタ装置１８に対するトラフィックの可視性を維持のための両方に責任を有している。ドメイン・コントローラ２０は、少しの例を挙げれば、例えば、認証、認可、および監査（ＡＡＡ）サーバ、鍵配分サーバ、あるいはポリシー・サーバである。
【００１１】
企業ドメイン・コントローラ２０は、導出鍵（矢印２２によって示される）をクライアント１２に配分するとともに、それらの導出鍵をサーバ１６およびＩＴネットワーク・モニタリング・ホスト１８へ送る。上述のように、本発明の実施例は、異なるセキュリティ組織に対処するためにスモールおよびラージ鍵サイズ双方のための効率的な鍵導出メカニズムを提供する。クライアント鍵あるいは導出鍵は、鍵サイズに基づいて引き出される。
【００１２】
実施例において、ネットワーク・セキュリティ・プロトコルがパケット上でＡＥＳ１２８オペレーションを使用する場合、本発明の実施例は、次の導出式を使用する、すなわち、ｃｌｉｅｎｔ＿ｋｅｙ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ，ｃｌｉｅｎｔ＿ＩＤ）、ここで、ｂａｓｅ＿ｋｅｙは、１２８ビットのサイズであり、ｃｌｉｅｎｔ＿ＩＤは、１２８ビットのサイズであり、また、ｃｌｉｅｎｔ＿ｋｅｙは、１２８ビットのサイズである。ここで、パケット・ペイロードは、ｃｌｉｅｎｔ＿ｋｅｙによって１２８ビットのＡＥＳオペレーション（つまり１０ラウンドのＡＥＳオペレーション）を受けるであろう。実施例では、ｃｌｉｅｎｔ＿ＩＤは、クライアントのインターネット・プロトコル・アドレス、あるいは企業ドメイン・コントローラ２０によって指定された他の識別子、あるいはパケット中の異なる属性の結合のようなクライアントの識別子である。このユニークな（唯一の）ｃｌｉｅｎｔ＿ＩＤは、個々のセキュア（安全）なパケットで通信され、安全なセッション識別子として使用される。したがって、各クライアント１２は、異なりかつ独立した鍵および識別子を有する。実施例では、ｂａｓｅ＿ｋｅｙは、ハードウェアに格納される。
【００１３】
実施例において、ネットワーク・セキュリティ・プロトコルがパケット上でＡＥＳ２５６オペレーションを使用する場合、本発明の実施例は、次の選択的な導出式を使用する。
【００１４】
オプション１：
ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ） （１）
ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ） （２）
ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ、
ここで、ｂａｓｅ＿ｋｅｙ＿１は、１２８ビットのサイズであり、ｂａｓｅ＿ｋｅｙ＿２は、１２８ビットのサイズであり、ｃｌｉｅｎｔ＿ＩＤは、１２８ビットのサイズである。また、「‖」は、連結オペレーションを示し、そしてｃｌｉｅｎｔ＿ｋｅｙは、長さが２５６ビットのサイズである。ここで、２５６ビットのｃｌｉｅｎｔ＿ｋｅｙは、パケット・ペイロード上の暗号処理を行なうために使用されるであろう。
【００１５】
オプション２：
ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ） （１）
ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ＋ｐａｄ） （２）
ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ、
ここで、ｂａｓｅ＿ｋｅｙ＿１は、１２８ビットのサイズであり、ｂａｓｅ＿ｋｅｙ＿２は、１２８ビットのサイズであり、ｃｌｉｅｎｔ＿ＩＤは、１２８ビットのサイズであり、ｐａｄは、固定値（つまり、カウンタあるいは特定のストリング）である。また、「‖」は、連結オペレーションを示し、そしてｃｌｉｅｎｔ＿ｋｅｙは、長さが２５６ビットのサイズである。ここで、オプション１でのように、２５６ビットのｃｌｉｅｎｔ＿ｋｅｙは、パケット・ペイロード上の暗号処理を行なうために使用されるであろう。オプション２のｐａｄ値は、入力でカウンタを使用する鍵導出機能のよく確立した実施での考えを借用する方法である。
【００１６】
よりスモールな鍵に関して上述されるように、ネットワーク・セキュリティ・プロトコルがパケット上でＡＥＳ１２８オペレーションを使用する場合、オプション１および２を備えたｃｌｉｅｎｔ＿ＩＤは、クライアントのインターネット・プロトコル・アドレス、あるいは企業ドメイン・コントローラ２０によって指定された他の識別子、あるいはパケット中の異なる属性の結合のようなクライアント識別子である。このユニークなｃｌｉｅｎｔ＿ＩＤは、個々の安全なパケットで通信され、安全なセッション識別子として使用される。したがって、各クライアント１２は、異なりかつ独立した鍵および識別子を有する。実施例では、ｂａｓｅ＿ｋｅｙ＿１およびｂａｓｅ＿ｋｅｙ＿２は、ハードウェアに格納される。
【００１７】
上述のように、本発明の実施例は、異なるセキュリティ組織に対処するためにスモールおよびラージ鍵サイズ双方のための効率的な鍵導出メカニズムを提供する（例えば、セッションがセッションのための鍵を導出するためにシードを含んでいる伝統的な鍵導出モデルの使用に対立するものとして）。スモール鍵（例えば、１２８ビットの鍵）に対して、本発明の実施例は、鍵を導出するためにＡＥＳ１２８オペレーションを使用し、それは、ＡＥＳ１２８中で１０ラウンドの動作だけで済むより短いレイテンシをもたらすという効果を具備する。ラージ鍵について、本発明の実施例は、ＡＥＳ１２８オペレーションを使用する並行実行を可能にする導出式を提案し、それはラージ鍵（例えば、２５６ビットの鍵）の鍵導出を著しくスピードアップさせることができる。
【００１８】
実施例では、２５６ビットの強力な暗号鍵を有することを仮定する。理論的には、その鍵は２つの半分へ分割され、その後、同じ値に戻すためにともに結合される。従って、２５６ビットのエントロピーのセキュリティは、保存されている。上記オプション１および２は、この同じ推論に基づく。ここで、実施例では、２５６ビットの鍵は２つの半分へ分割され、その後、適切な擬似ランダム機能（例えば、ＡＥＳ１２８）が２つの適切な導出鍵を得るために適用される。例えば、ｂａｓｅ＿ｋｅｙ＿１とｂａｓｅ＿ｋｅｙ＿２は、１２８ビットのエントロピーをそれぞれ有する。その後、その２つは、２５６ビットの強力な鍵を得るためにともに結合される。
【００１９】
実施例では、上記オプション１と２は、オプション１と２中のステップ（１）と（２）がハードウェア・シリコン上で並行して実行することができるので、ラージ鍵サイズでさえ効率的である。このように、鍵導出のレイテンシは１０ラウンドのＡＥＳ１２８オペレーションですむ。例えば、１ラウンドのオペレーションがハードウェア実行で１クロック・サイクルを消費するとすると、レイテンシは１０サイクルになるだろう。これは、最もよく知られている方法である。このように、実施例では、スモール・サイズあるいはラージ・サイズの鍵のいずれであっても、その導出のための時間消費は、同じである。加えて、本発明の実施例が単に２ラウンドのＡＥＳオペレーションの回路を必要とするだけなので、シリコンのエリアを増加させることは、ラージ・サイズの鍵導出に適している。
【００２０】
ラージ・サイズの鍵のために、より長いレイテンシをもたらすハッシュ関数や暗号化の基本を使用することにまさる少なくとも４サイクルの削減がある。これは、図７に示されている。図７を参照して、図７は、ＮＩＳＴの仕様に基づいたＡＥＳ１２８とＡＥＳ２５６オペレーションのためのブロック図を示す。ここで、ＡＥＳ２５６は、オペレーションのためのより多くのラウンドと同様にラージ鍵のサイズも要求する。図中のＷ［・・・］は、１２８ビットの各ラウンド鍵を指定する。このように、本発明の実施例は、ＡＥＳ２５６オペレーションと比較して、鍵導出で４サイクルをセーブするＡＥＳ１２８オペレーションを使用する。
【００２１】
図２を参照して、ドメイン・コントローラ２０（図１）によって配分された１以上のｃｌｉｅｎｔ＿ｋｅｙｓを格納するおよび適用するシーケンスが実施例に従って示される。企業サーバへの出力フレームのすべては、ｃｌｉｅｎｔ＿ｋｅｙによって暗号化されかつ認証される。最初に、ブロック２４で示されるようにアプリケーション・データが送信制御プロトコル（ＴＣＰ）／ユーザ・データ・プロトコル（ＵＤＰ）／インターネット・プロトコル（ＩＰ）スタックに入る。インターネット・プロトコルのパケットは、スタックによってサーバに配布される。その後、ブロック２６で示されるように、リンク層ドライバは、層２のフレームを形成する。判断ブロック２８での判断は、宛先インターネット・プロトコルのアドレスが企業サーバに属しているかどうかを決める。もしＮＯである場合、そのフレームは、ブロック３４で示されるように、ネットワーク・インターフェイス・カードを通して送信される。もしＹＥＳである場合、ブロック３０で示されるように、ハードウェアに格納された適切なｃｌｉｅｎｔ＿ｋｅｙを使用して、そのフレームは、暗号化され認証される。その後、暗号化されたフレームは、ブロック３２で示されるように、ネットワーク・インターフェイス・カードを通して送信される。
【００２２】
図３に、本発明の実施例がさらに示される。クライアントのプラットフォームがフレームを受け取ると、パケットがネットワーク・インターフェイス・カードに到着していると示されて、図３の判断ブロック３０２で、そのフレームがここに記述されたプロトコルによって処理されるかどうかの判断が決められる。もしＮＯである場合、ブロック３０４に示されるように、そのフレームは、上位のプロトコル層へ送られる。そのフレームが判断ブロック３０２でそのプロトコルによって処理される場合、ブロック３０６で示されるように、そのパケットは認証され、またそのパケットは、ハードウェアに格納された適切なｃｌｉｅｎｔ＿ｋｅｙを使用して解読される。正しい鍵の選択は、セッションＩＤ、および／または、他のユニークな識別子あるいはパケット内のアドレスによって行なうことができる。その後、そのフレームは、ブロック３０８で示されるように、上位のプロトコル層へ送られる。
【００２３】
図４に本発明の実施例がさらに示される。図４を参照して、サーバ１６（図１）がフレームを受け取ると、パケットがネットワーク・インターフェイス・カードに到着したことを示し、判断ブロック４０２で、そのフレームがここに記述されたプロトコルによって処理されるかどうかの判断が決められる。もしＮＯである場合、ブロック４０４で示されるように、そのフレームは、上位のプロトコル層へ送られる。もしＹＥＳである場合、ブロック４０６において、ｃｌｉｅｎｔ＿ＩＤがフレームから抽出され、１を越える導出鍵が存在する場合、適切な導出鍵を選択するために使用される。
【００２４】
パケットにＡＥＳ１２８オペレーションが施されている場合、ブロック４０８で、ｃｌｉｅｎｔ＿ｋｅｙ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ，ｃｌｉｅｎｔ＿ＩＤ）とする。ブロック４１０で、そのｃｌｉｅｎｔ＿ｋｅｙは、そのフレームを認証し解読するために、そのパケット・ペイロードにＡＥＳ１２８の暗号解読処理を行なうために使用される。最後に、ブロック４１８で、そのフレームは、上位のプロトコル層へ送られる。本実施例では、ｃｌｉｅｎｔ＿ＩＤは、与えられたセッションにおいて安全な組織に対する識別子である。
【００２５】
パケットにＡＥＳ２５６オペレーションが施されている場合、ブロック４１２で、ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ）、および、ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ＋ｐａｄ）とする。上述のとおり、これらの２つの導出オペレーションは、ＡＥＳ１２８オペレーションを使用して並行して実行され、ラージ鍵（例えば、２５６ビットの鍵）の鍵導出を著しくスピードアップさせる。上述のように、ブロック４１２はオプション１およびオプション２の両方を表わしていることに注意すること。例えば、ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢを計算するための「ｐａｄ」値は、ヌル（オプション１）、単純な整数カウンタ（オプション２）、あるいは規定されたストリング（オプション２）である。
【００２６】
４１４で、ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢとする。ブロック４１６で、そのｃｌｉｅｎｔ＿ｋｅｙは、フレームを認証し解読するために、そのパケット・ペイロードにＡＥＳ２５６の暗号解読処理を行なうために使用される。最後に、ブロック４１８で、そのフレームは、上位のプロトコル層へ送られる。実施例では、ｃｌｉｅｎｔ＿ＩＤは、与えられたセッションにおいて安全な組織に対する識別子である。
【００２７】
実施例に従って、サーバ１６（図１）は、図５に示されるシーケンスを使用してフレームを送信してもよい。図５を参照して、ブロック５０２で、アプリケーション・データがインターネット・プロトコル・スタックで受け取られる。ブロック５０４で、そのパケットは様々なクライアントに配布され、また、ｃｌｉｅｎｔ＿ＩＤは各フレームに添付される。その後、ブロック５０５で、リンク層ドライバは、フレームを受け取る。ブロック５０６で、ｃｌｉｅｎｔ＿ＩＤは、そのフレームから抽出される。
【００２８】
図４に関する上述のように、パケットにＡＥＳ１２８オペレーションが施される場合、５０８で、ｃｌｉｅｎｔ＿ｋｅｙ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ，ｃｌｉｅｎｔ＿ＩＤ）とする。ブロック５１０で、そのｃｌｉｅｎｔ＿ｋｅｙは、そのフレームを認証し暗号化するために、そのパケット・ペイロードにＡＥＳ１２８の暗号化処理を行なうために使用される。最後に、ブロック５１８で、そのフレームは、ネットワークへ送られる。実施例では、ｃｌｉｅｎｔ＿ＩＤは、与えられたセッションにおいて安全な組織に対する識別子である。
【００２９】
パケットにＡＥＳ２５６オペレーションが施される場合、ブロック５１２で、ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ）、および、ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ＋ｐａｄ）とする。上述のとおり、これらの２つの導出オペレーションは、ＡＥＳ１２８オペレーションを使用して並行して実行され、ラージ鍵（例えば、２５６ビットの鍵）の鍵導出を著しくスピードアップさせる。上述のように、ブロック５１２はオプション１およびオプション２の両方を表わしていることに注意すること。例えば、ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢを計算するための「ｐａｄ」値は、ヌル（オプション１）、単純な整数カウンタ（オプション２）、あるいは規定されたストリング（オプション２）である。
【００３０】
ブロック５１４で、ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢとする。ブロック５１６で、そのｃｌｉｅｎｔ＿ｋｅｙは、フレームを認証し暗号化するために、そのパケット・ペイロードにＡＥＳ２５６の暗号処理を行なうために使用される。最後に、ブロック５１８で、そのフレームは、ネットワークへ送られる。実施例では、ｃｌｉｅｎｔ＿ＩＤは、与えられたセッションにおいて安全な組織に対する識別子である。
【００３１】
ＩＴネットワーク・モニタ装置１８（図１）は、サーバ１６に類似して動作する。サーバ１６およびモニタリング・ホスト１８は、クライアントからの様々なセキュリティ組織を扱うための少数の鍵を単に維持する必要がある。別個のクライアント／セッション用の鍵は異なり独立しているので、１人のクライアント・ホストを危険にさらす敵対者は別のクライアントに扮することができない。ドメイン・コントローラ２０、サーバ１６、およびモニタ装置１８のための鍵の数は比較的少ないが、改ざん妨害に対し依然として適切な保護を提供する。
【００３２】
一実施例では、フレームのフォーマットは、インターネット・プロトコル・セキュリティ（ＩＰＳＥＣ）フレームに便乗してもよい。ｃｌｉｅｎｔ＿ＩＤは、ＩＰＳＥＣヘッダのセキュリティ・パラメータ・インデックス（ＳＰＩ）の領域に便乗する。シーケンス番号もＩＰＳＥＣヘッダ中に便乗してもよい。そうでない場合、フレームは、標準ＩＰＳＥＣフレームと同じであってもよい。
【００３３】
ｃｌｉｅｎｔ＿ＩＤは、ドメイン・コントローラによって割り当てられ、メディア・アクセス制御（ＭＡＣ）あるいはＩＰアドレスから独立している。あるいは、ｃｌｉｅｎｔ＿ＩＤのすべてあるいは一部分もクライアントによって提供されてもよい。例えば、ｃｌｉｅｎｔ＿ＩＤは、ホストおよびユーザ情報を収容しており、それは、関連するアクセス・コントロール・ポリシーにマップされ得る。したがって、ｃｌｉｅｎｔ＿ＩＤによって、ＩＴ管理者は、パケットがどこで発したかをよりよく知ることができる。
【００３４】
実施例では、企業ネットワークのためのエンドツーエンド・セキュリティおよびトラフィック可視性の両方が提供される。そのメカニズムは、いくつかの実施例では、完全にハードウェア中に実装できるが、それはある場合にはより低コストで十分なワイヤ速度を達成する。
【００３５】
別の実施例では、ｃｌｉｅｎｔ＿ＩＤとｃｌｉｅｎｔ＿ｋｅｙの生成は、直接あるいは間接的に役割と呼ばれる所定の管理ポリシーに準拠した装置の先行評価へ関連付けられる。この評価は、様々な形式を採ってもよいし、一般に装置の既知の構成／状態に言及するものである。これによって、データの受取人は、装置の最新の既知／現在の状態に基づいて、きめの細かいネットワーク・アクセス・コントロール決定をすることを可能にする。例えば、ｃｌｉｅｎｔ＿ＩＤは、クライアントの役割を定義し、またクライアントが何にアクセスする権限を有するかを示すセキュリティ・レベルにリンクされてもよい。一度、鍵と識別子とが関連付けられると、追加のアクセス・コントロールおよびセキュリティ機能が可能になるように、ｃｌｉｅｎｔ＿ＩＤをクライアントの役割にリンクする。
【００３６】
図６を参照して、実施例に従って、ハードウェア・ソリューション１００は、ブリッジ７２に結合された暗号エンジン７０を含む。ブリッジ７２は、メモリ・アクセスモジュール７４に直接結合され、次に、ＭＡＣ処理ユニット７６に結合される。処理装置７６は、バッファ７８を通って入来および送出パケット８０と通信する。パケット８０は、ｃｌｉｅｎｔ＿ＩＤ（ＣＩＤ）８２を含んでいてもよい。導出鍵を用いると、セッション鍵格納のためのオンチップＲＡＭの必要を除去する。
【００３７】
一実施例では、ハードウェア・ソリューション１００は、ネットワーク・インターフェイス・カードの一部あるいはプロセッサ／チップセット内の統合ＭＡＣの一部であってもよい。このように、エンドツーエンド・セキュリティの負担は、サーバ１６から取り除かれ、いくつかの実施例におけるネットワーク１４の規模を可能な限り拡大させることができる。これによって、ある場合には、上位層のプロトコル／アプリケーションに影響せずに、ソリューションのシームレスな利用を許可する。
【００３８】
実施例は、ハードウェア、ソフトウェア、ファームウェア、マイクロコードあるいはそれらの任意の組み合わせによって実装することができる。ソフトウェア、ファームウェアあるいはマイクロコード中で実装された場合、実施例の要素は、必要なタスクを実行するプログラム・コードであり、あるいはコード・セグメントである。そのコードは、オペレーションを実行する実際のコード、あるいはオペレーションをエミュレートするかシミュレートするコードであってもよい。コード・セグメントは、手続き、機能、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェア・パッケージ、クラス、または、命令、データ構造あるいはプログラム文の任意の組み合わせを表わす。コード・セグメントは、情報、データ、引き数、パラメータ、またはメモリ内容を通過および／または受け取ることにより、別のコード・セグメントあるいはハードウェア回路に結合される。情報、引き数、パラメータ、データなどは、任意の適切な手段を含むメモリ共有、メッセージ・パス、トークン・パス、ネットワーク送信などを含む適切な手段を介して渡され、転送され、送信される。プログラムまたはコード・セグメントは、プロセッサ読取り可能な媒体に格納されるか、あるいは搬送波に重畳されたコンピュータ・データ信号、あるいは搬送波によって変調された信号を送信媒体を通して送信される。「プロセッサ読取り可能なあるいはアクセス可能な媒体」あるいは「機械読取り可能なあるいはアクセス可能な媒体」は、情報を格納し、送信し、または転送することができるすべての媒体を含む。プロセッサあるいは機械読取り可能なあるいはアクセス可能な媒体の例は、電子回路、半導体記憶装置、リード・オンリ・メモリ（ＲＯＭ）、フラッシュ・メモリ、消去可能ＲＯＭ（ＥＲＯＭ）、フレキシブル・ディスク、コンパクト・ディスク（ＣＤ−ＲＯＭ）、光ディスク、ハードディスク、光ファイバ媒体、無線周波数（ＲＦ）リンクなどを含む。コンピュータ・データ信号は、電子ネットワーク・チャンネル、光ファイバ、空間電磁気、ＲＦリンクなどのような伝送媒体上で伝搬することのできるあらゆる信号を含む。コード・セグメントは、インターネット、イントラネットなどのコンピュータ・ネットワークによってダウンロードされてもよい。機械アクセス可能な媒体は、製造物中に搭載されていてもよい。機械アクセス可能な媒体は、機械によってアクセスされたとき、機械に次の動作を実行させるデータを含む。用語「データ」は、機械読取り可能な目的のために符号化されたあらゆるタイプの情報を指す。したがって、それはプログラム、コード、データ、ファイルなどを含む。
【００３９】
本明細書の全体に亘る「一実施例」あるいは「実施例」へ参照は、実施例に関して記述された特定の特徴、構造あるいは特性が本発明を射程範囲とする少なくとも１つの実施内に包含されることを意味する。このように、語句「一実施例」あるいは「実施例中」は、必ずしも同じ実施例を参照するものではない。さらに、特定の特徴、構造あるいは特性は、例示された特定の実施例以外の他の適切な形式で形成されてもよく、また、そのような形式はすべて本願の請求項の射程範囲内に包含される。
【００４０】
本発明は、限られた数の実施例に関して記述されているが、当業者は、本発明から多くの修正および変更を認識するであろう。
【００４１】
添付された請求項は、本発明の思想および範囲内に置かれるものとして、このような修正および変更を全て包含すると意図される。
【符号の説明】
【００４２】
１２ クライアント
１４ 企業ネットワーク
１６ サーバ
１８ ＩＴモニタ装置
２０ 企業ドメイン・コントローラ
７０ 暗号エンジン
７２ ブリッジ
７４ メモリ・アクセスモジュール
７６ ＭＡＣ処理ユニット
７８ バッファ
８０ パケット
【技術分野】
【０００１】
本発明は、トラフィック可視性を備えたエンドツーエンド・ネットワークのセキュリティのための効率的な鍵の導出に関する。
【背景技術】
【０００２】
多くのネットワーク・セキュリティ・プロトコルは、費用のかかる非対称な暗号を使用して、クライアントとサーバとの間のセッション鍵の交渉に基づき、さらに、各クライアント・セッションのために極めて多くの対称な鍵を追跡（トラッキング）することを要求する。エンドツーエンド・セキュリティは、ネットワークにおける通信の一方端から全ての方向への他方端、つまり、クライアントからサーバ、および、サーバからクライアントにデータ認証および／またはデータの機密性があることを意味する。トラフィックの可視性は、装置をモニタするサーバおよび情報技術（ＩＴ）がセキュアなトラフィックを見ることができることを意味する。これら２つのゴールは、ある程度、互いに相反するものではあるが、両方ともネットワーク・セキュリティにとって重要である。
【０００３】
エンドツーエンド・セキュリティは、クライアントとサーバとの間のトラフィックを改ざんする第三者を除外するために、クライアントとサーバの双方にとって重要であるが、クライアントは、直接的な操りあるいは改ざんに最も危険に晒される。このように、クライアントの秘密の一意性は、一方のクライアントの妥協が他方のクライアントのトラフィックへのアクセス増加を防止するために重要である。トラフィックの可視性は、ＩＴ管理に不可欠で、異常現象を検出するためにＩＴ管理にトラフィック観察を要求する。現在の多くの主要なセキュリティ・プロトコルは、トラフィックの可視性に対する懸念なしにエンドツーエンド・セキュリティを単に提供している。
【０００４】
近年、産業界は、効率性のために、パケット暗号化および認証の両方のために単一鍵の結合モード暗号（ｓｉｎｇｌｅ−ｋｅｙ ｃｏｍｂｉｎｅｄ ｍｏｄｅ ｃｉｐｅｒ）に進展している。米国ＮＩＳＴによって指定されたＡｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（ＡＥＳ）は、ほとんどのネットワーク・セキュリティ・プロトコルにとってデファクト方法となっている。例えば、ＡＥＳ−ＧＣＭ（ガロア域カウンタ・モード）がＩＰｓｅｃプロトコルのスキームに推奨されている。米国ＮＩＳＴおよびＮＳＡは、鍵サイズの選択に対するガイダンスを提供している。今日の大多数の適用では、ＡＥＳ１２８を備える１２８ビット鍵のオペレーションが使用される。しかしながら、今後、より高いセキュリティ・レベルの適用のために、ＡＥＳ２５６を備える２５６ビット鍵のオペレーションが必要となるかもしれない。今日の方法では、ＡＥＳ２５６を備える２５６ビット鍵のオペレーションに対する鍵導出のレイテンシは、ＡＥＳ１２８を備える１２８ビット鍵のオペレーションに対する鍵導出よりはるかに長い。鍵導出の伝統的な方法は、一方向のハッシュ関数の反復によるシリアルな動作であるが、それはハードウェアにおいてもより遅い。
【図面の簡単な説明】
【０００５】
本発明の実施例は、添付図面に示された代表的な実施例によって記述されているが、制限的なものではなく、類似の参照番号は類似の要素を表示する。
【図１】本発明の様々な実施例に従う企業ネットワークのセキュリティ図である。
【図２】様々な実施例に従うクライアント・プラットフォーム上のシーケンス図である。
【図３】様々な実施例に従う別のクライアント・プラットフォーム・シーケンスである。
【図４】様々な実施例に従うサーバ・シーケンスである。
【図５】様々な実施例に従う別のシーケンスである。
【図６】様々な実施例に従うハードウェア図である。
【図７】ＮＩＳＴの仕様に基づいたＡＥＳ１２８とＡＥＳ２５６オペレーションを表す。
【発明を実施するための形態】
【０００６】
本発明の実施例は、認可されたＩＴ装置によるトラフィックの可視性を具備するエンドツーエンド・ネットワーク・セキュリティのための効率的な鍵導出を提供する。ハードウェアに基づいた、ワイヤ速度のエンドツーエンド暗号化および認証は、異なるセキュリティ組織に対処するためにスモールおよびラージ鍵サイズ双方のための効率的な鍵導出メカニズムを使用して、フレームベースで達成される。以下詳細に記述されるように、スモール鍵（例えば、１２８ビットの鍵）に対して、本発明の実施例は、鍵を導出するためにＡＥＳ１２８オペレーションを使用し、それは、ＡＥＳ１２８ではわずか１０ラウンド（回）のオペレーションによるより短いレイテンシを有するという長所を具備する。よりラージな鍵に対して、本発明の実施例は、ＡＥＳ１２８オペレーションを使用して並行実行による鍵導出を可能にする導出式を提案し、それはラージ鍵（例えば、２５６ビットの鍵）の鍵導出を著しくスピードアップさせる。
【０００７】
クライアントとサーバは、導出鍵およびその関連する導出情報を認証されたクライアントに、また導出鍵を認証されたサーバに与えるドメイン・コントローラと通信する。特定のクライアントからフレームを受け取ると、サーバ・ハードウェアは、そのフレームから鍵の導出情報を抽出し、その導出鍵をこの情報に適用し、このようにして、セッション鍵を照合しかつ交渉する必要性なしにフレームに使用された暗号鍵を引き出す。あるクライアントに与えられた導出鍵は、他のクライアントに知られることはないであろうし、演算による推測が行われることもないであろう。サーバだけがその関連するクライアント鍵を引き出すことができる。トラフィックの可視性問題を解決するために、ドメイン・コントローラは、さらに、導出鍵を、例えばＩＴモニタ装置／ホストのように、権限の付与されたＩＴネットワーク機器へ送ってもよい。権限の付与されたＩＴネットワーク機器がサーバと同じ導出鍵メカニズムを有するので、権限の付与されたＩＴネットワーク機器は、十分なワイヤ速度で暗号化された通過トラフィックを解読し、その権限の付与されたＩＴネットワーク機器によってトラフィックの可視性を可能にすることができる。
【０００８】
研究開発の成果を他の当業者へ伝えるために、実証された実施例の様々な側面が当業者によって普通に使用される用語を用いて記述されるであろう。しかしながら、代替の実施例が記述された側面のうちのいくつかにのみ実施されてもよいことは、当業者には明白であろう。特定の数、材料、および配置は、実証された実施例についての完全な理解を提供するために、説明をする目的のために述べられる。代替の実施例が特定の詳細な事項がなくても実施できることを当業者には明らかであろう。他の例では、周知の特徴は、実証された実施例を不明瞭にしないために、省略されるか単純化される。
【０００９】
さらに、実証された実施例を理解する際に最も有効な方法で、様々な動作を複数の個別の動作として記述するが、その記述の順序は、これらの動作が必ずその順序に依存するものであることを暗示するものとして解釈されるべきでない。特に、これらの動作が提示された順序で実行する必要はない。本出願の目的のために、その内容が明らかに他のことを示していない限り、用語「フレーム」および「パケット」は交換可能であると考えられる。
【００１０】
図１は、本発明の様々な実施例に従って、エンタープライズ（企業）ネットワーク・セキュリティ図１０を示す。図１を参照して、企業ネットワーク１４は、多くのクライアント１２を１またはそれ以上のサーバ１６と通信するために導入される。企業ドメイン・コントローラ２０は、全企業に対するエンドツーエンド・セキュリティを維持するため、およびサーバ１６およびＩＴモニタ装置１８に対するトラフィックの可視性を維持のための両方に責任を有している。ドメイン・コントローラ２０は、少しの例を挙げれば、例えば、認証、認可、および監査（ＡＡＡ）サーバ、鍵配分サーバ、あるいはポリシー・サーバである。
【００１１】
企業ドメイン・コントローラ２０は、導出鍵（矢印２２によって示される）をクライアント１２に配分するとともに、それらの導出鍵をサーバ１６およびＩＴネットワーク・モニタリング・ホスト１８へ送る。上述のように、本発明の実施例は、異なるセキュリティ組織に対処するためにスモールおよびラージ鍵サイズ双方のための効率的な鍵導出メカニズムを提供する。クライアント鍵あるいは導出鍵は、鍵サイズに基づいて引き出される。
【００１２】
実施例において、ネットワーク・セキュリティ・プロトコルがパケット上でＡＥＳ１２８オペレーションを使用する場合、本発明の実施例は、次の導出式を使用する、すなわち、ｃｌｉｅｎｔ＿ｋｅｙ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ，ｃｌｉｅｎｔ＿ＩＤ）、ここで、ｂａｓｅ＿ｋｅｙは、１２８ビットのサイズであり、ｃｌｉｅｎｔ＿ＩＤは、１２８ビットのサイズであり、また、ｃｌｉｅｎｔ＿ｋｅｙは、１２８ビットのサイズである。ここで、パケット・ペイロードは、ｃｌｉｅｎｔ＿ｋｅｙによって１２８ビットのＡＥＳオペレーション（つまり１０ラウンドのＡＥＳオペレーション）を受けるであろう。実施例では、ｃｌｉｅｎｔ＿ＩＤは、クライアントのインターネット・プロトコル・アドレス、あるいは企業ドメイン・コントローラ２０によって指定された他の識別子、あるいはパケット中の異なる属性の結合のようなクライアントの識別子である。このユニークな（唯一の）ｃｌｉｅｎｔ＿ＩＤは、個々のセキュア（安全）なパケットで通信され、安全なセッション識別子として使用される。したがって、各クライアント１２は、異なりかつ独立した鍵および識別子を有する。実施例では、ｂａｓｅ＿ｋｅｙは、ハードウェアに格納される。
【００１３】
実施例において、ネットワーク・セキュリティ・プロトコルがパケット上でＡＥＳ２５６オペレーションを使用する場合、本発明の実施例は、次の選択的な導出式を使用する。
【００１４】
オプション１：
ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ） （１）
ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ） （２）
ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ、
ここで、ｂａｓｅ＿ｋｅｙ＿１は、１２８ビットのサイズであり、ｂａｓｅ＿ｋｅｙ＿２は、１２８ビットのサイズであり、ｃｌｉｅｎｔ＿ＩＤは、１２８ビットのサイズである。また、「‖」は、連結オペレーションを示し、そしてｃｌｉｅｎｔ＿ｋｅｙは、長さが２５６ビットのサイズである。ここで、２５６ビットのｃｌｉｅｎｔ＿ｋｅｙは、パケット・ペイロード上の暗号処理を行なうために使用されるであろう。
【００１５】
オプション２：
ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ） （１）
ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ＋ｐａｄ） （２）
ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ、
ここで、ｂａｓｅ＿ｋｅｙ＿１は、１２８ビットのサイズであり、ｂａｓｅ＿ｋｅｙ＿２は、１２８ビットのサイズであり、ｃｌｉｅｎｔ＿ＩＤは、１２８ビットのサイズであり、ｐａｄは、固定値（つまり、カウンタあるいは特定のストリング）である。また、「‖」は、連結オペレーションを示し、そしてｃｌｉｅｎｔ＿ｋｅｙは、長さが２５６ビットのサイズである。ここで、オプション１でのように、２５６ビットのｃｌｉｅｎｔ＿ｋｅｙは、パケット・ペイロード上の暗号処理を行なうために使用されるであろう。オプション２のｐａｄ値は、入力でカウンタを使用する鍵導出機能のよく確立した実施での考えを借用する方法である。
【００１６】
よりスモールな鍵に関して上述されるように、ネットワーク・セキュリティ・プロトコルがパケット上でＡＥＳ１２８オペレーションを使用する場合、オプション１および２を備えたｃｌｉｅｎｔ＿ＩＤは、クライアントのインターネット・プロトコル・アドレス、あるいは企業ドメイン・コントローラ２０によって指定された他の識別子、あるいはパケット中の異なる属性の結合のようなクライアント識別子である。このユニークなｃｌｉｅｎｔ＿ＩＤは、個々の安全なパケットで通信され、安全なセッション識別子として使用される。したがって、各クライアント１２は、異なりかつ独立した鍵および識別子を有する。実施例では、ｂａｓｅ＿ｋｅｙ＿１およびｂａｓｅ＿ｋｅｙ＿２は、ハードウェアに格納される。
【００１７】
上述のように、本発明の実施例は、異なるセキュリティ組織に対処するためにスモールおよびラージ鍵サイズ双方のための効率的な鍵導出メカニズムを提供する（例えば、セッションがセッションのための鍵を導出するためにシードを含んでいる伝統的な鍵導出モデルの使用に対立するものとして）。スモール鍵（例えば、１２８ビットの鍵）に対して、本発明の実施例は、鍵を導出するためにＡＥＳ１２８オペレーションを使用し、それは、ＡＥＳ１２８中で１０ラウンドの動作だけで済むより短いレイテンシをもたらすという効果を具備する。ラージ鍵について、本発明の実施例は、ＡＥＳ１２８オペレーションを使用する並行実行を可能にする導出式を提案し、それはラージ鍵（例えば、２５６ビットの鍵）の鍵導出を著しくスピードアップさせることができる。
【００１８】
実施例では、２５６ビットの強力な暗号鍵を有することを仮定する。理論的には、その鍵は２つの半分へ分割され、その後、同じ値に戻すためにともに結合される。従って、２５６ビットのエントロピーのセキュリティは、保存されている。上記オプション１および２は、この同じ推論に基づく。ここで、実施例では、２５６ビットの鍵は２つの半分へ分割され、その後、適切な擬似ランダム機能（例えば、ＡＥＳ１２８）が２つの適切な導出鍵を得るために適用される。例えば、ｂａｓｅ＿ｋｅｙ＿１とｂａｓｅ＿ｋｅｙ＿２は、１２８ビットのエントロピーをそれぞれ有する。その後、その２つは、２５６ビットの強力な鍵を得るためにともに結合される。
【００１９】
実施例では、上記オプション１と２は、オプション１と２中のステップ（１）と（２）がハードウェア・シリコン上で並行して実行することができるので、ラージ鍵サイズでさえ効率的である。このように、鍵導出のレイテンシは１０ラウンドのＡＥＳ１２８オペレーションですむ。例えば、１ラウンドのオペレーションがハードウェア実行で１クロック・サイクルを消費するとすると、レイテンシは１０サイクルになるだろう。これは、最もよく知られている方法である。このように、実施例では、スモール・サイズあるいはラージ・サイズの鍵のいずれであっても、その導出のための時間消費は、同じである。加えて、本発明の実施例が単に２ラウンドのＡＥＳオペレーションの回路を必要とするだけなので、シリコンのエリアを増加させることは、ラージ・サイズの鍵導出に適している。
【００２０】
ラージ・サイズの鍵のために、より長いレイテンシをもたらすハッシュ関数や暗号化の基本を使用することにまさる少なくとも４サイクルの削減がある。これは、図７に示されている。図７を参照して、図７は、ＮＩＳＴの仕様に基づいたＡＥＳ１２８とＡＥＳ２５６オペレーションのためのブロック図を示す。ここで、ＡＥＳ２５６は、オペレーションのためのより多くのラウンドと同様にラージ鍵のサイズも要求する。図中のＷ［・・・］は、１２８ビットの各ラウンド鍵を指定する。このように、本発明の実施例は、ＡＥＳ２５６オペレーションと比較して、鍵導出で４サイクルをセーブするＡＥＳ１２８オペレーションを使用する。
【００２１】
図２を参照して、ドメイン・コントローラ２０（図１）によって配分された１以上のｃｌｉｅｎｔ＿ｋｅｙｓを格納するおよび適用するシーケンスが実施例に従って示される。企業サーバへの出力フレームのすべては、ｃｌｉｅｎｔ＿ｋｅｙによって暗号化されかつ認証される。最初に、ブロック２４で示されるようにアプリケーション・データが送信制御プロトコル（ＴＣＰ）／ユーザ・データ・プロトコル（ＵＤＰ）／インターネット・プロトコル（ＩＰ）スタックに入る。インターネット・プロトコルのパケットは、スタックによってサーバに配布される。その後、ブロック２６で示されるように、リンク層ドライバは、層２のフレームを形成する。判断ブロック２８での判断は、宛先インターネット・プロトコルのアドレスが企業サーバに属しているかどうかを決める。もしＮＯである場合、そのフレームは、ブロック３４で示されるように、ネットワーク・インターフェイス・カードを通して送信される。もしＹＥＳである場合、ブロック３０で示されるように、ハードウェアに格納された適切なｃｌｉｅｎｔ＿ｋｅｙを使用して、そのフレームは、暗号化され認証される。その後、暗号化されたフレームは、ブロック３２で示されるように、ネットワーク・インターフェイス・カードを通して送信される。
【００２２】
図３に、本発明の実施例がさらに示される。クライアントのプラットフォームがフレームを受け取ると、パケットがネットワーク・インターフェイス・カードに到着していると示されて、図３の判断ブロック３０２で、そのフレームがここに記述されたプロトコルによって処理されるかどうかの判断が決められる。もしＮＯである場合、ブロック３０４に示されるように、そのフレームは、上位のプロトコル層へ送られる。そのフレームが判断ブロック３０２でそのプロトコルによって処理される場合、ブロック３０６で示されるように、そのパケットは認証され、またそのパケットは、ハードウェアに格納された適切なｃｌｉｅｎｔ＿ｋｅｙを使用して解読される。正しい鍵の選択は、セッションＩＤ、および／または、他のユニークな識別子あるいはパケット内のアドレスによって行なうことができる。その後、そのフレームは、ブロック３０８で示されるように、上位のプロトコル層へ送られる。
【００２３】
図４に本発明の実施例がさらに示される。図４を参照して、サーバ１６（図１）がフレームを受け取ると、パケットがネットワーク・インターフェイス・カードに到着したことを示し、判断ブロック４０２で、そのフレームがここに記述されたプロトコルによって処理されるかどうかの判断が決められる。もしＮＯである場合、ブロック４０４で示されるように、そのフレームは、上位のプロトコル層へ送られる。もしＹＥＳである場合、ブロック４０６において、ｃｌｉｅｎｔ＿ＩＤがフレームから抽出され、１を越える導出鍵が存在する場合、適切な導出鍵を選択するために使用される。
【００２４】
パケットにＡＥＳ１２８オペレーションが施されている場合、ブロック４０８で、ｃｌｉｅｎｔ＿ｋｅｙ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ，ｃｌｉｅｎｔ＿ＩＤ）とする。ブロック４１０で、そのｃｌｉｅｎｔ＿ｋｅｙは、そのフレームを認証し解読するために、そのパケット・ペイロードにＡＥＳ１２８の暗号解読処理を行なうために使用される。最後に、ブロック４１８で、そのフレームは、上位のプロトコル層へ送られる。本実施例では、ｃｌｉｅｎｔ＿ＩＤは、与えられたセッションにおいて安全な組織に対する識別子である。
【００２５】
パケットにＡＥＳ２５６オペレーションが施されている場合、ブロック４１２で、ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ）、および、ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ＋ｐａｄ）とする。上述のとおり、これらの２つの導出オペレーションは、ＡＥＳ１２８オペレーションを使用して並行して実行され、ラージ鍵（例えば、２５６ビットの鍵）の鍵導出を著しくスピードアップさせる。上述のように、ブロック４１２はオプション１およびオプション２の両方を表わしていることに注意すること。例えば、ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢを計算するための「ｐａｄ」値は、ヌル（オプション１）、単純な整数カウンタ（オプション２）、あるいは規定されたストリング（オプション２）である。
【００２６】
４１４で、ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢとする。ブロック４１６で、そのｃｌｉｅｎｔ＿ｋｅｙは、フレームを認証し解読するために、そのパケット・ペイロードにＡＥＳ２５６の暗号解読処理を行なうために使用される。最後に、ブロック４１８で、そのフレームは、上位のプロトコル層へ送られる。実施例では、ｃｌｉｅｎｔ＿ＩＤは、与えられたセッションにおいて安全な組織に対する識別子である。
【００２７】
実施例に従って、サーバ１６（図１）は、図５に示されるシーケンスを使用してフレームを送信してもよい。図５を参照して、ブロック５０２で、アプリケーション・データがインターネット・プロトコル・スタックで受け取られる。ブロック５０４で、そのパケットは様々なクライアントに配布され、また、ｃｌｉｅｎｔ＿ＩＤは各フレームに添付される。その後、ブロック５０５で、リンク層ドライバは、フレームを受け取る。ブロック５０６で、ｃｌｉｅｎｔ＿ＩＤは、そのフレームから抽出される。
【００２８】
図４に関する上述のように、パケットにＡＥＳ１２８オペレーションが施される場合、５０８で、ｃｌｉｅｎｔ＿ｋｅｙ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ，ｃｌｉｅｎｔ＿ＩＤ）とする。ブロック５１０で、そのｃｌｉｅｎｔ＿ｋｅｙは、そのフレームを認証し暗号化するために、そのパケット・ペイロードにＡＥＳ１２８の暗号化処理を行なうために使用される。最後に、ブロック５１８で、そのフレームは、ネットワークへ送られる。実施例では、ｃｌｉｅｎｔ＿ＩＤは、与えられたセッションにおいて安全な組織に対する識別子である。
【００２９】
パケットにＡＥＳ２５６オペレーションが施される場合、ブロック５１２で、ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ）、および、ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ＋ｐａｄ）とする。上述のとおり、これらの２つの導出オペレーションは、ＡＥＳ１２８オペレーションを使用して並行して実行され、ラージ鍵（例えば、２５６ビットの鍵）の鍵導出を著しくスピードアップさせる。上述のように、ブロック５１２はオプション１およびオプション２の両方を表わしていることに注意すること。例えば、ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢを計算するための「ｐａｄ」値は、ヌル（オプション１）、単純な整数カウンタ（オプション２）、あるいは規定されたストリング（オプション２）である。
【００３０】
ブロック５１４で、ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢとする。ブロック５１６で、そのｃｌｉｅｎｔ＿ｋｅｙは、フレームを認証し暗号化するために、そのパケット・ペイロードにＡＥＳ２５６の暗号処理を行なうために使用される。最後に、ブロック５１８で、そのフレームは、ネットワークへ送られる。実施例では、ｃｌｉｅｎｔ＿ＩＤは、与えられたセッションにおいて安全な組織に対する識別子である。
【００３１】
ＩＴネットワーク・モニタ装置１８（図１）は、サーバ１６に類似して動作する。サーバ１６およびモニタリング・ホスト１８は、クライアントからの様々なセキュリティ組織を扱うための少数の鍵を単に維持する必要がある。別個のクライアント／セッション用の鍵は異なり独立しているので、１人のクライアント・ホストを危険にさらす敵対者は別のクライアントに扮することができない。ドメイン・コントローラ２０、サーバ１６、およびモニタ装置１８のための鍵の数は比較的少ないが、改ざん妨害に対し依然として適切な保護を提供する。
【００３２】
一実施例では、フレームのフォーマットは、インターネット・プロトコル・セキュリティ（ＩＰＳＥＣ）フレームに便乗してもよい。ｃｌｉｅｎｔ＿ＩＤは、ＩＰＳＥＣヘッダのセキュリティ・パラメータ・インデックス（ＳＰＩ）の領域に便乗する。シーケンス番号もＩＰＳＥＣヘッダ中に便乗してもよい。そうでない場合、フレームは、標準ＩＰＳＥＣフレームと同じであってもよい。
【００３３】
ｃｌｉｅｎｔ＿ＩＤは、ドメイン・コントローラによって割り当てられ、メディア・アクセス制御（ＭＡＣ）あるいはＩＰアドレスから独立している。あるいは、ｃｌｉｅｎｔ＿ＩＤのすべてあるいは一部分もクライアントによって提供されてもよい。例えば、ｃｌｉｅｎｔ＿ＩＤは、ホストおよびユーザ情報を収容しており、それは、関連するアクセス・コントロール・ポリシーにマップされ得る。したがって、ｃｌｉｅｎｔ＿ＩＤによって、ＩＴ管理者は、パケットがどこで発したかをよりよく知ることができる。
【００３４】
実施例では、企業ネットワークのためのエンドツーエンド・セキュリティおよびトラフィック可視性の両方が提供される。そのメカニズムは、いくつかの実施例では、完全にハードウェア中に実装できるが、それはある場合にはより低コストで十分なワイヤ速度を達成する。
【００３５】
別の実施例では、ｃｌｉｅｎｔ＿ＩＤとｃｌｉｅｎｔ＿ｋｅｙの生成は、直接あるいは間接的に役割と呼ばれる所定の管理ポリシーに準拠した装置の先行評価へ関連付けられる。この評価は、様々な形式を採ってもよいし、一般に装置の既知の構成／状態に言及するものである。これによって、データの受取人は、装置の最新の既知／現在の状態に基づいて、きめの細かいネットワーク・アクセス・コントロール決定をすることを可能にする。例えば、ｃｌｉｅｎｔ＿ＩＤは、クライアントの役割を定義し、またクライアントが何にアクセスする権限を有するかを示すセキュリティ・レベルにリンクされてもよい。一度、鍵と識別子とが関連付けられると、追加のアクセス・コントロールおよびセキュリティ機能が可能になるように、ｃｌｉｅｎｔ＿ＩＤをクライアントの役割にリンクする。
【００３６】
図６を参照して、実施例に従って、ハードウェア・ソリューション１００は、ブリッジ７２に結合された暗号エンジン７０を含む。ブリッジ７２は、メモリ・アクセスモジュール７４に直接結合され、次に、ＭＡＣ処理ユニット７６に結合される。処理装置７６は、バッファ７８を通って入来および送出パケット８０と通信する。パケット８０は、ｃｌｉｅｎｔ＿ＩＤ（ＣＩＤ）８２を含んでいてもよい。導出鍵を用いると、セッション鍵格納のためのオンチップＲＡＭの必要を除去する。
【００３７】
一実施例では、ハードウェア・ソリューション１００は、ネットワーク・インターフェイス・カードの一部あるいはプロセッサ／チップセット内の統合ＭＡＣの一部であってもよい。このように、エンドツーエンド・セキュリティの負担は、サーバ１６から取り除かれ、いくつかの実施例におけるネットワーク１４の規模を可能な限り拡大させることができる。これによって、ある場合には、上位層のプロトコル／アプリケーションに影響せずに、ソリューションのシームレスな利用を許可する。
【００３８】
実施例は、ハードウェア、ソフトウェア、ファームウェア、マイクロコードあるいはそれらの任意の組み合わせによって実装することができる。ソフトウェア、ファームウェアあるいはマイクロコード中で実装された場合、実施例の要素は、必要なタスクを実行するプログラム・コードであり、あるいはコード・セグメントである。そのコードは、オペレーションを実行する実際のコード、あるいはオペレーションをエミュレートするかシミュレートするコードであってもよい。コード・セグメントは、手続き、機能、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェア・パッケージ、クラス、または、命令、データ構造あるいはプログラム文の任意の組み合わせを表わす。コード・セグメントは、情報、データ、引き数、パラメータ、またはメモリ内容を通過および／または受け取ることにより、別のコード・セグメントあるいはハードウェア回路に結合される。情報、引き数、パラメータ、データなどは、任意の適切な手段を含むメモリ共有、メッセージ・パス、トークン・パス、ネットワーク送信などを含む適切な手段を介して渡され、転送され、送信される。プログラムまたはコード・セグメントは、プロセッサ読取り可能な媒体に格納されるか、あるいは搬送波に重畳されたコンピュータ・データ信号、あるいは搬送波によって変調された信号を送信媒体を通して送信される。「プロセッサ読取り可能なあるいはアクセス可能な媒体」あるいは「機械読取り可能なあるいはアクセス可能な媒体」は、情報を格納し、送信し、または転送することができるすべての媒体を含む。プロセッサあるいは機械読取り可能なあるいはアクセス可能な媒体の例は、電子回路、半導体記憶装置、リード・オンリ・メモリ（ＲＯＭ）、フラッシュ・メモリ、消去可能ＲＯＭ（ＥＲＯＭ）、フレキシブル・ディスク、コンパクト・ディスク（ＣＤ−ＲＯＭ）、光ディスク、ハードディスク、光ファイバ媒体、無線周波数（ＲＦ）リンクなどを含む。コンピュータ・データ信号は、電子ネットワーク・チャンネル、光ファイバ、空間電磁気、ＲＦリンクなどのような伝送媒体上で伝搬することのできるあらゆる信号を含む。コード・セグメントは、インターネット、イントラネットなどのコンピュータ・ネットワークによってダウンロードされてもよい。機械アクセス可能な媒体は、製造物中に搭載されていてもよい。機械アクセス可能な媒体は、機械によってアクセスされたとき、機械に次の動作を実行させるデータを含む。用語「データ」は、機械読取り可能な目的のために符号化されたあらゆるタイプの情報を指す。したがって、それはプログラム、コード、データ、ファイルなどを含む。
【００３９】
本明細書の全体に亘る「一実施例」あるいは「実施例」へ参照は、実施例に関して記述された特定の特徴、構造あるいは特性が本発明を射程範囲とする少なくとも１つの実施内に包含されることを意味する。このように、語句「一実施例」あるいは「実施例中」は、必ずしも同じ実施例を参照するものではない。さらに、特定の特徴、構造あるいは特性は、例示された特定の実施例以外の他の適切な形式で形成されてもよく、また、そのような形式はすべて本願の請求項の射程範囲内に包含される。
【００４０】
本発明は、限られた数の実施例に関して記述されているが、当業者は、本発明から多くの修正および変更を認識するであろう。
【００４１】
添付された請求項は、本発明の思想および範囲内に置かれるものとして、このような修正および変更を全て包含すると意図される。
【符号の説明】
【００４２】
１２ クライアント
１４ 企業ネットワーク
１６ サーバ
１８ ＩＴモニタ装置
２０ 企業ドメイン・コントローラ
７０ 暗号エンジン
７２ ブリッジ
７４ メモリ・アクセスモジュール
７６ ＭＡＣ処理ユニット
７８ バッファ
８０ パケット
【特許請求の範囲】
【請求項１】
導出式を用いて、複数のクライアントの各々に対して暗号鍵を導出する暗号エンジンであって、前記導出式は、
ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ） （１）、
ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ＋ｐａｄ） （２）、および
ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ、であり、
ここで、式（１）および式（２）は、並行して実行される、暗号エンジンと、
前記暗号エンジンに結合されたＭＡＣ処理ユニットと、
を含むことを特徴とするシステム。
【請求項２】
前記ｐａｄは、ヌル値、整数カウンタ、および規定されたストリングのうちの１つであることを特徴とする請求項１記載のシステム。
【請求項３】
前記ｃｌｉｅｎｔ＿ＩＤは、クライアントから受け取られたフレームから抽出されることを特徴とする請求項１記載のシステム。
【請求項４】
暗号化されたトラフィックを解読することのできる情報技術モニタ装置へ前記ｃｌｉｅｎｔ＿ｋｅｙを送り、エンドツーエンド・セキュリティを維持する間、トラフィックの可視性を提供することができるドメイン・コントローラを含むことを特徴とする請求項１記載のシステム。
【請求項５】
前記システムは、ネットワーク・インターフェイス・カードの一部であることを特徴とする請求項１記載のシステム。
【請求項６】
導出式を用いて、複数のクライアントの各々に対して暗号鍵を導出する暗号エンジンであって、前記導出式は、
ｃｌｉｅｎｔ＿ｋｅｙ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ，ｃｌｉｅｎｔ＿ＩＤ）である、暗号エンジンと、
前記暗号エンジンに結合されたＭＡＣ処理ユニットと、
を含むことを特徴とするシステム。
【請求項７】
前記ｃｌｉｅｎｔ＿ＩＤは、クライアントから受け取られたフレームから抽出されることを特徴とする請求項６記載のシステム。
【請求項８】
暗号化されたトラフィックを解読することのできる情報技術モニタ装置へ前記ｃｌｉｅｎｔ＿ｋｅｙを送り、エンドツーエンド・セキュリティを維持する間、トラフィックの可視性を提供するドメイン・コントローラを含むことを特徴とする請求項６記載のシステム。
【請求項９】
前記システムは、ネットワーク・インターフェイス・カードの一部であることを特徴とする請求項６記載のシステム。
【請求項１０】
導出式を用いて、各クライアントに対して１またはそれ以上の暗号セッション鍵を導出するためのドメイン・コントローラを使用し、クライアントとサーバとの間のネットワーク・セキュリティを提供する段階であって、前記導出式は、
ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ） （１）、
ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ＋ｐａｄ） （２）、
ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ、であり、
ここで、式（１）および式（２）は、並行して実行される、段階と、
情報技術モニタ装置および前記サーバの少なくとも１つへ導出鍵を配分している間、前記ドメイン・コントローラが前記クライアント・セッション鍵をクライアントに配分することができる、段階と、
を含むことを特徴とする方法。
【請求項１１】
前記ｐａｄは、ヌル値、整数カウンタ、および規定されたストリングのうちの１つであることを特徴とする請求項１０記載の方法。
【請求項１２】
クライアントから受け取られたフレームから前記ｃｌｉｅｎｔ＿ＩＤを抽出する段階をさらに含むことを特徴とする請求項１１記載の方法。
【請求項１３】
エンドツーエンド・セキュリティを維持する間トラフィックの可視性を提供するために、暗号化されたトラフィックを解読することのできる情報技術モニタ装置へ前記ｃｌｉｅｎｔ＿ｋｅｙを送る段階をさらに含むことを特徴とする請求項１２記載の方法。
【請求項１４】
ネットワーク・アクセスを制御するために、与えられたセッション鍵の前記ｃｌｉｅｎｔ＿ＩＤを使用する段階をさらに含むことを特徴とする請求項１３記載の方法。
【請求項１５】
ネットワーク・アクセス制御のために、前記ｃｌｉｅｎｔ＿ＩＤをセキュリティ測定に関連付ける段階をさらに含むことを特徴とする請求項１０記載の方法。
【請求項１６】
命令を収容する機械読取り可能な媒体において、前記命令が処理システムによって実行されるとき、前記処理システムは、
導出式を用いて、各クライアントに対して１またはそれ以上の暗号セッション鍵を導出するためのドメイン・コントローラを使用し、クライアントとサーバとの間のネットワーク・セキュリティを提供する段階であって、前記導出式は、
ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ） （１）、
ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ＋ｐａｄ） （２）、
ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ、であり、
ここで、式（１）および式（２）は、並行して実行される、段階と、
情報技術モニタ装置および前記サーバの少なくとも１つへ導出鍵を配分している間、前記ドメイン・コントローラが前記クライアント・セッション鍵をクライアントに配分することができる、段階と、
を実行することを特徴とする機械読取り可能な媒体。
【請求項１７】
前記ｐａｄは、ヌル値、整数カウンタ、および規定されたストリングのうちの１つであることを特徴とする請求項１６記載の機械可読媒体。
【請求項１８】
クライアントから受け取られたフレームから前記ｃｌｉｅｎｔ＿ＩＤを抽出するための命令を格納する段階をさらに含むことを特徴とする請求項１７記載の機械読取り可能な媒体。
【請求項１９】
エンドツーエンド・セキュリティを維持する間トラフィックの可視性を提供するために、暗号化されたトラフィックを解読することのできる情報技術モニタ装置へ前記ｃｌｉｅｎｔ＿ｋｅｙを送る命令を格納する段階をさらに含むことを特徴とする請求項１８記載の機械読取り可能な媒体。
【請求項２０】
ネットワーク・アクセスを制御するために、与えられたセッション鍵の前記ｃｌｉｅｎｔ＿ＩＤを使用する命令を格納する段階をさらに含むことを特徴とする請求項１６記載の機械読取り可能な媒体。
【請求項１】
導出式を用いて、複数のクライアントの各々に対して暗号鍵を導出する暗号エンジンであって、前記導出式は、
ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ） （１）、
ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ＋ｐａｄ） （２）、および
ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ、であり、
ここで、式（１）および式（２）は、並行して実行される、暗号エンジンと、
前記暗号エンジンに結合されたＭＡＣ処理ユニットと、
を含むことを特徴とするシステム。
【請求項２】
前記ｐａｄは、ヌル値、整数カウンタ、および規定されたストリングのうちの１つであることを特徴とする請求項１記載のシステム。
【請求項３】
前記ｃｌｉｅｎｔ＿ＩＤは、クライアントから受け取られたフレームから抽出されることを特徴とする請求項１記載のシステム。
【請求項４】
暗号化されたトラフィックを解読することのできる情報技術モニタ装置へ前記ｃｌｉｅｎｔ＿ｋｅｙを送り、エンドツーエンド・セキュリティを維持する間、トラフィックの可視性を提供することができるドメイン・コントローラを含むことを特徴とする請求項１記載のシステム。
【請求項５】
前記システムは、ネットワーク・インターフェイス・カードの一部であることを特徴とする請求項１記載のシステム。
【請求項６】
導出式を用いて、複数のクライアントの各々に対して暗号鍵を導出する暗号エンジンであって、前記導出式は、
ｃｌｉｅｎｔ＿ｋｅｙ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ，ｃｌｉｅｎｔ＿ＩＤ）である、暗号エンジンと、
前記暗号エンジンに結合されたＭＡＣ処理ユニットと、
を含むことを特徴とするシステム。
【請求項７】
前記ｃｌｉｅｎｔ＿ＩＤは、クライアントから受け取られたフレームから抽出されることを特徴とする請求項６記載のシステム。
【請求項８】
暗号化されたトラフィックを解読することのできる情報技術モニタ装置へ前記ｃｌｉｅｎｔ＿ｋｅｙを送り、エンドツーエンド・セキュリティを維持する間、トラフィックの可視性を提供するドメイン・コントローラを含むことを特徴とする請求項６記載のシステム。
【請求項９】
前記システムは、ネットワーク・インターフェイス・カードの一部であることを特徴とする請求項６記載のシステム。
【請求項１０】
導出式を用いて、各クライアントに対して１またはそれ以上の暗号セッション鍵を導出するためのドメイン・コントローラを使用し、クライアントとサーバとの間のネットワーク・セキュリティを提供する段階であって、前記導出式は、
ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ） （１）、
ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ＋ｐａｄ） （２）、
ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ、であり、
ここで、式（１）および式（２）は、並行して実行される、段階と、
情報技術モニタ装置および前記サーバの少なくとも１つへ導出鍵を配分している間、前記ドメイン・コントローラが前記クライアント・セッション鍵をクライアントに配分することができる、段階と、
を含むことを特徴とする方法。
【請求項１１】
前記ｐａｄは、ヌル値、整数カウンタ、および規定されたストリングのうちの１つであることを特徴とする請求項１０記載の方法。
【請求項１２】
クライアントから受け取られたフレームから前記ｃｌｉｅｎｔ＿ＩＤを抽出する段階をさらに含むことを特徴とする請求項１１記載の方法。
【請求項１３】
エンドツーエンド・セキュリティを維持する間トラフィックの可視性を提供するために、暗号化されたトラフィックを解読することのできる情報技術モニタ装置へ前記ｃｌｉｅｎｔ＿ｋｅｙを送る段階をさらに含むことを特徴とする請求項１２記載の方法。
【請求項１４】
ネットワーク・アクセスを制御するために、与えられたセッション鍵の前記ｃｌｉｅｎｔ＿ＩＤを使用する段階をさらに含むことを特徴とする請求項１３記載の方法。
【請求項１５】
ネットワーク・アクセス制御のために、前記ｃｌｉｅｎｔ＿ＩＤをセキュリティ測定に関連付ける段階をさらに含むことを特徴とする請求項１０記載の方法。
【請求項１６】
命令を収容する機械読取り可能な媒体において、前記命令が処理システムによって実行されるとき、前記処理システムは、
導出式を用いて、各クライアントに対して１またはそれ以上の暗号セッション鍵を導出するためのドメイン・コントローラを使用し、クライアントとサーバとの間のネットワーク・セキュリティを提供する段階であって、前記導出式は、
ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿１，ｃｌｉｅｎｔ＿ＩＤ） （１）、
ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ＝ＡＥＳ１２８（ｂａｓｅ＿ｋｅｙ＿２，ｃｌｉｅｎｔ＿ＩＤ＋ｐａｄ） （２）、
ｃｌｉｅｎｔ＿ｋｅｙ＝ｃｌｉｅｎｔ＿ｋｅｙ＿ＭＳＢ‖ｃｌｉｅｎｔ＿ｋｅｙ＿ＬＳＢ、であり、
ここで、式（１）および式（２）は、並行して実行される、段階と、
情報技術モニタ装置および前記サーバの少なくとも１つへ導出鍵を配分している間、前記ドメイン・コントローラが前記クライアント・セッション鍵をクライアントに配分することができる、段階と、
を実行することを特徴とする機械読取り可能な媒体。
【請求項１７】
前記ｐａｄは、ヌル値、整数カウンタ、および規定されたストリングのうちの１つであることを特徴とする請求項１６記載の機械可読媒体。
【請求項１８】
クライアントから受け取られたフレームから前記ｃｌｉｅｎｔ＿ＩＤを抽出するための命令を格納する段階をさらに含むことを特徴とする請求項１７記載の機械読取り可能な媒体。
【請求項１９】
エンドツーエンド・セキュリティを維持する間トラフィックの可視性を提供するために、暗号化されたトラフィックを解読することのできる情報技術モニタ装置へ前記ｃｌｉｅｎｔ＿ｋｅｙを送る命令を格納する段階をさらに含むことを特徴とする請求項１８記載の機械読取り可能な媒体。
【請求項２０】
ネットワーク・アクセスを制御するために、与えられたセッション鍵の前記ｃｌｉｅｎｔ＿ＩＤを使用する命令を格納する段階をさらに含むことを特徴とする請求項１６記載の機械読取り可能な媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１０−１５７９９８（Ｐ２０１０−１５７９９８Ａ）
【公開日】平成２２年７月１５日（２０１０．７．１５）
【国際特許分類】
【外国語出願】
【出願番号】特願２００９−２７１２４９（Ｐ２００９−２７１２４９）
【出願日】平成２１年１１月３０日（２００９．１１．３０）
【出願人】（５９１００３９４３）インテル・コーポレーション (1,101)
【Ｆターム（参考）】
【公開日】平成２２年７月１５日（２０１０．７．１５）
【国際特許分類】
【出願番号】特願２００９−２７１２４９（Ｐ２００９−２７１２４９）
【出願日】平成２１年１１月３０日（２００９．１１．３０）
【出願人】（５９１００３９４３）インテル・コーポレーション (1,101)
【Ｆターム（参考）】
[ Back to top ]