JP2004056784A - セキュリティゲートウェイで実行する方法、記録媒体及びシステム - Google Patents

Abstract

【課題】セキュアな通信を可能とするオンラインコンソールベースのゲームのためのセキュリティゲートウェイを実現する。
【解決手段】オンラインのコンソールベースゲームのためのセキュリティゲートウェイ１５０の例示的な実施が、公衆ネットワーク（例えば、インターネット）と専用ネットワーク（例えば、内部データセンタネットワーク）の間のゲートウェイとして動作する。このセキュリティゲートウェイ１５０により、公衆ネットワークを介してゲームコンソール１０２とセキュアな通信チャネルを確立することが可能になり、また公衆ネットワーク上のゲームコンソールと専用ネットワーク上のサービスデバイスの間におけるセキュアな通信が可能になる。
【選択図】　　　　図２

Description

【０００１】
【発明の属する技術分野】
本発明は、ゲームコンソールおよびオンラインゲームのための、セキュリティゲートウェイで実行する方法、記録媒体及びシステムに関する。詳細には、オンラインコンソールベースのゲームのためのセキュリティゲートウェイを実現する、セキュリティゲートウェイで実行する方法、記録媒体及びシステムに関する。
【０００２】
【従来の技術】
従来、専用のコンソールを備えたゲームシステムは、限られた数のプレーヤ（例えば、２〜４名のプレーヤ）に対応する独立型のマシンであった。パーソナルコンピュータベースのゲームの人気が高まったのは、ある程度、多くの遠隔のプレーヤが参加してインターネットを介してゲームを行うことができることによる。したがって、専用ゲームシステムに関する１つの傾向は、インターネットベースのオンラインゲームなど、ネットワークを介するゲームを円滑にする能力を提供することである。
【０００３】
オンラインゲームは、集中サーバ手法、またはピアツーピア手法で実施することが可能である。集中サーバ手法では、複数のゲームシステムが、１つまたは複数の集中サーバに接続し、その集中サーバを介して互いに対話する。ピアツーピア手法では、複数のゲームシステムが、互いに接続し、直接に互いに対話する。ただし、ピアツーピア手法においてさえ、ゲームシステムが互いを見出すのを助ける初期マッチメーキング（ｍａｔｃｈ−ｍａｋｉｎｇ）サービスなどの通信を助けるのに集中サーバが使用される可能性がある。
【０００４】
そのような集中サーバを使用する際に遭遇する１つの問題は、サーバとゲームシステムの間のトラフィックを、ネットワーク上の他のデバイスによる改竄または観察に対して保護することである。ゲームを行う人々は、独創的ないかさまの仕組み（ｃｈｅａｔｉｎｇ　ｍｅｃｈａｎｉｓｍ）を開発することで悪名高く、ネットワークトラフィックが、そのようなユーザにとっての格好のターゲットとなっている。残念ながら、以前のコンソールベースのゲームシステムは、通常、集中サーバとのセキュアな通信を提供していなかった。
【０００５】
尚、本明細書では、読者は、暗号化、解読、認証、ハッシング（ｈａｓｈｉｎｇ）、およびデジタル署名などの基本的な暗号法の原理に精通しているものと想定する。いくつかの文献に暗号法の基本的な概説に関連した技術内容が開示されている（例えば、非特許文献１を参照）。
【０００６】
【非特許文献１】
Ｂｒｕｃｅ　Ｓｃｈｎｅｉｅｒ，　”Ａｐｐｌｉｅｄ　Ｃｒｙｐｔｏｇｒａｐｈｙ：　Ｐｒｏｔｏｃｏｌｓ，　Ａｌｇｏｒｉｔｈｍｓ，　ａｎｄ　Ｓｏｕｒｃｅ　Ｃｏｄｅ　ｉｎ　Ｃ，”　ｐｕｂｌｉｓｈｅｄ　ｂｙ　Ｊｏｈｎ　Ｗｉｌｅｙ　＆　Ｓｏｎｓ，　ｃｏｐｙｒｉｇｈｔ　１９９４　（ｓｅｃｏｎｄ　ｅｄｉｔｉｏｎ　１９９６）
【０００７】
【発明が解決しようとする課題】
従来のシステムには上述したような種々の問題があり、さらなる改善が望まれている。
【０００８】
本発明は、このような状況に鑑みてなされたもので、その目的とするところは、セキュアな通信を可能とするオンラインコンソールベースのゲームのためのセキュリティゲートウェイを実現する、セキュリティゲートウェイで実行する方法、記録媒体及びシステムを提供することにある。
【０００９】
【課題を解決するための手段】
オンラインコンソールベースのゲームのためのセキュリティゲートウェイを本明細書で説明する。
【００１０】
一態様によれば、セキュリティゲートウェイが、公衆ネットワーク（例えば、インターネット）と専用ネットワーク（例えば、内部データセンタネットワーク）の間のゲートウェイとして動作する。このセキュリティゲートウェイにより、公衆ネットワークを介してゲームコンソールとセキュアな通信チャネルを確立することが可能になり、また公衆ネットワーク上のゲームコンソールと専用ネットワーク上のサービスデバイスの間でセキュアな通信が可能になる。
【００１１】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を詳細に説明する。本明細書全体で、同様の構成要素および／または同様の特徴を指すのに同一の符号を使用する。
【００１２】
以下の解説は、コンソールベースのゲームシステムに関するオンラインサービスのためのセキュリティゲートウェイを対象とする。この解説では、読者は、暗号化、解読、認証、ハッシング（ｈａｓｈｉｎｇ）、およびデジタル署名などの基本的な暗号法の原理に精通しているものと想定する。
【００１３】
図１は、例示的なオンラインゲーム環境１００を示すブロック図である。複数のゲームコンソール１０２−１、１０２−２、．．．１０２−ｎが、ネットワーク１０６を介してセキュリティゲートウェイ１０４に結合されている。ネットワーク１０６は、様々な従来のデータ通信網の任意の１つまたは複数を表す。ネットワーク１０６は、通常、パケット交換網を含むが、回線交換網も含むことが可能である。ネットワーク１０６は、有線部分および／または無線部分を含むことが可能である。１つの例示的な実施では、ネットワーク１０６は、インターネットを含むが、オプションとして、１つまたは複数のローカルエリアネットワーク（ＬＡＮ）および／またはワイドエリアネットワーク（ＷＡＮ）を含むことが可能である。ネットワーク１０６の少なくとも一部分は、公衆ネットワークであり、これは、ネットワークが公共アクセス可能であることを指す。実質的に、誰でも公衆ネットワークにアクセスできる。
【００１４】
一部の状況では、ネットワーク１０６は、ゲームコンソール１０２−１〜１０２−ｎとセキュリティゲートウェイ１０４の間にルーティングデバイスが位置しているＬＡＮ（例えば、ホームネットワーク）を含む。このルーティングデバイスは、ネットワークアドレス変換（ＮＡＴ）を行うことができ、専用ネットワーク１０８（またはＬＡＮ）上の複数のデバイスが、インターネット上で同一のＩＰアドレスを共用することを可能にし、また、悪意のあるユーザ、または性悪な（ｍｉｓｃｈｉｅｖｏｕｓ）ユーザによるインターネットを介してのアクセスに対してデバイスを保護するファイアウォールとして動作する。
【００１５】
セキュリティゲートウェイ１０４は、公衆ネットワーク１０６と専用ネットワーク１０８の間のゲートウェイとして動作する。専用ネットワーク１０８は、ローカルエリアネットワークなどの多種多様な従来のネットワークの任意のものであることが可能である。専用ネットワーク１０８、ならびに以下にさらに詳述する他のデバイスは、セキュアゾーンとして動作するデータセンタ１１０の内部にある。データセンタ１１０は、信頼される通信を介して通信する信頼されるデバイスから構成される。したがって、セキュアゾーン１１０内における暗号化および認証は必要ない。ネットワーク１０８の専用性が指しているのは、ネットワーク１０８の限定されたアクセス可能性、すなわち、ネットワーク１０８に対するアクセスが、ある個人だけに限定されている（例えば、データセンタ１１０の所有者または運用者によって制限されている）ことである。
【００１６】
セキュリティゲートウェイ１０４は、１つまたは複数のセキュリティゲートウェイコンピューティングデバイスのクラスタである。このセキュリティゲートウェイコンピューティングデバイスは、集合としてセキュリティゲートウェイ１０４を実現する。セキュリティゲートウェイ１０４は、オプションとして、セキュリティゲートウェイコンピューティングデバイスによって扱われるべき要求が、そのコンピューティングデバイスの適切なものに向けられるように動作する１つまたは複数の従来のロードバランシングデバイス（ｌｏａｄ　ｂａｌａｎｃｉｎｇ　ｄｅｖｉｃｅ）を含むことが可能である。この誘導、つまりロードバランシングは、様々なセキュリティゲートウェイコンピューティングデバイスにかかる負荷をほぼ平等に平衡させようと試みる形で（あるいは、何らかの他の基準に従って）行われる。
【００１７】
またデータセンタ１１０内に、次のものが存在する。すなわち、１つまたは複数の監視サーバ１１２、１つまたは複数の存在−通知フロントドア（ｐｒｅｓｅｎｃｅ　ａｎｄ　ｎｏｔｉｆｉｃａｔｉｏｎ　ｆｒｏｎｔ　ｄｏｏｒｓ）１１４と、１つまたは複数の存在サーバ１１６と、１つまたは複数の通知サーバ１１８（集合として、存在−通知サービスを実施する）、１つまたは複数のマッチフロントドア１２０と、１つまたは複数のマッチサーバ１２２（集合として、マッチサービスを実施する）、ならびに１つまたは複数の統計フロントドア１２４と、１つまたは複数の統計サーバ１２６（集合として、統計サービスを実施する）である。サーバ１１６、１１８、１２２、および１２６は、ゲームコンソール１０２−１〜１０２−ｎにサービスを提供し、したがって、サービスデバイスと呼ぶことができる。サーバ１１６、１１８、１２２、および１２６に加えて、かつ／またはその代わりに、他のサービスデバイスも含まれることが可能である。さらに、図１では、１つのデータセンタだけを示しているが、別法では、ゲームコンソール１０２−１〜１０２−ｎが通信することができる複数のデータセンタが存在してもよい。これらのデータセンタ群は、独立に動作することが可能であり、あるいは、集合として（例えば、１つの大型のデータセンタをゲームコンソール１０２−１〜１０２−ｎに供与するように）動作することが可能である。
【００１８】
ゲームコンソール１０２−１〜１０２−ｎは、データセンタ１１０から遠隔に位置し、ネットワーク１０６を介してデータセンタ１１０にアクセスする。データセンタ内の１つまたは複数のデバイスと通信することを望むゲームコンソール１０２−１〜１０２−ｎは、コンソール１０２−１〜１０２−ｎとセキュリティゲートウェイ１０４の間でセキュアな通信を確立する。ゲームコンソール１０２−１〜１０２−ｎおよびセキュリティゲートウェイ１０４は、やり取りされるデータパケットの暗号化および認証を行い、これにより、暗号化を破ることなしにデータパケットをキャプチャすること、またはコピーすることができる何らかの他のデバイスによって理解されることなく、ゲームコンソール１０２−１〜１０２−ｎとセキュリティゲートウェイ１０４の間でデータパケットがセキュアに伝送されることが可能になる。ゲームコンソール１０２−１〜１０２−ｎからセキュリティゲートウェイ１０４に通信される、またはセキュリティゲートウェイ１０４からゲームコンソール１０２−１〜１０２−ｎに通信される各データパケットには、データが組み込まれていることが可能である。この組み込まれたデータは、パケットの内容、またはパケットのデータ内容と呼ばれる。また、追加の情報も、パケットタイプ（例えば、以下にさらに詳述するハートビートパケット、またはトラバーサル（ｔｒａｖｅｒｓａｌ）パケット）に基づき、本質的にパケットに含まれることが可能である。
【００１９】
コンソール１０２−１〜１０２−ｎとセキュリティゲートウェイ１０４の間のセキュアな通信チャネルは、セキュリティチケットに基づく。コンソール１０２−１〜１０２−ｎは、鍵配信センタ１２８に対してコンソール１０２−１〜１０２−ｎ自体、および現行のユーザを認証して、鍵配信センタ１２８からセキュリティチケットを獲得する。次に、コンソール１０２−１〜１０２−ｎは、このセキュリティチケットを使用してセキュリティゲートウェイ１０４とのセキュアな通信チャネルを確立する。セキュリティゲートウェイ１０４とセキュアな通信チャネルを確立する際、ゲームコンソール１０２−１〜１０２−ｎとセキュリティゲートウェイ１０４は、互いに対して自らを認証し、その特定のゲームコンソール１０２−１〜１０２−ｎおよびセキュリティゲートウェイ１０４だけに知られたセッションセキュリティ鍵を確立する。このセッションセキュリティ鍵は、ゲームコンソール１０２−１〜１０２−ｎとセキュリティゲートウェイ１０４のクラスタの間で転送されるデータを暗号化する根拠として使用され、したがって、その他のデバイス（他のゲームコンソール１０２−１〜１０２−ｎを含め）はどれも、そのデータを読み取ることができない。また、セッションセキュリティ鍵は、データパケットが、データパケットの起点とされるセキュリティゲートウェイ１０４、またはゲームコンソール１０２−１〜１０２−ｎからのものであることを認証する根拠としても使用される。したがって、そのようなセッションセキュリティ鍵を根拠として使用することにより、セキュリティゲートウェイ１０４と様々なゲームコンソール１０２−１〜１０２−ｎの間でセキュアな通信チャネルを確立することができる。
【００２０】
ゲームコンソール１０２−１〜１０２−ｎとセキュリティゲートウェイ１０４の間でセキュアな通信チャネルが確立されると、暗号化されたデータパケットをその２つの間でセキュアに伝送することができる。ゲームコンソール１０２−１〜１０２−ｎが、データをデータセンタ１１０内の特定のサービスデバイスに送信することを望むとき、ゲームコンソール１０２−１〜１０２−ｎは、そのデータを暗号化してセキュリティゲートウェイ１０４に送信し、そのデータが、データパケットによって目標とされる特定のサービスデバイスに転送されることを要求する。セキュリティゲートウェイ１０４は、そのデータパケットを受信して、そのデータパケットを認証し、解読した後、パケットのデータ内容を、専用ネットワーク１０８を介して適切なサービスに送信される別のメッセージの中にカプセル化する。セキュリティゲートウェイ１０４は、データパケットによって目標とされる要求されたサービスに基づき、そのメッセージに適切なサービスを決定する。
【００２１】
同様に、データセンタ１１０内のサービスデバイスが、ゲームコンソール１０２−１〜１０２−ｎにデータを通信することを望むとき、データセンタは、ゲームコンソール１０２−１〜１０２−ｎに送信されるべきデータ内容、ならびにそのデータ内容が送信されるべき先の特定のゲームコンソール１０２−１〜１０２−ｎの指示を含むメッセージを、専用ネットワーク１０８を介してセキュリティゲートウェイ１０４に送信する。セキュリティゲートウェイ１０４は、データ内容をデータパケットに組み込み、次に、データパケットを暗号化して、その特定のゲームコンソール１０２−１〜１０２−ｎだけしか解読することができないようにし、また、セキュリティゲートウェイ１０４を送信元とするものとしてデータパケットを認証する。
【００２２】
セキュリティゲートウェイ１０４とゲームコンソール１０２−１〜１０２−ｎの間で暗号化されたデータパケットが主に通信されるものとして本明細書では述べているが、別法では、一部のデータパケットは、部分的に暗号化されることが可能である（データパケットのある部分は暗号化され、他の部分は暗号化されない）。データパケットのどの部分が暗号化され、どの部分が暗号化されないかは、データセンタ１１０および／またはゲームコンソール１０２−１〜１０２−ｎの設計者の所望に基づいて異なる可能性がある。例えば、設計者は、コンソール１０２−１〜１０２−ｎのユーザが互いに話すことができるようにコンソール１０２−１〜１０２−ｎ間で音声データが通信されるのを許すことを選択することができ、設計者は、パケットの中のあらゆる他のデータは暗号化されているが、音声データは暗号化されていないのを許すことをさらに選択することができる。さらに、または別の代案として、一部のデータパケットが、暗号化された部分を全く有さない（すなわち、データパケット全体が暗号化されていない）ことが可能である。データパケットが暗号化されていない、または部分的にだけ暗号化されている場合でも、そのデータパケットは、認証されることに留意されたい。
【００２３】
セキュリティゲートウェイ１０４の中の各セキュリティゲートウェイデバイスは、通常、１つまたは複数のゲームコンソール１０２−１〜１０２−ｎとのセキュアな通信チャネルに責任を負い、したがって、各セキュリティゲートウェイデバイスは、１つまたは複数のゲームコンソールを管理すること、または扱うことに責任を負っているものと見なすことができる。種々のセキュリティゲートウェイデバイスは、２つが互いに通信中で、３つ以上が互いにメッセージを通信することが可能である。例えば、自らが管理することに責任を負っていないゲームコンソールにデータパケットを送信する必要があるセキュリティゲートウェイデバイスは、そのゲームコンソールに送信されるべきデータを伴うメッセージをすべての他のセキュリティゲートウェイデバイスに送信することができる。このメッセージが、そのゲームコンソールを管理することに責任を負うセキュリティゲートウェイデバイスによって受信され、適切なデータをそのゲームコンソールに送信する。あるいは、セキュリティゲートウェイデバイスが、どのゲームコンソールがどのセキュリティゲートウェイデバイスによって扱われているかを認知していることが可能であり、この認知は、各セキュリティゲートウェイデバイスが、その他のセキュリティゲートウェイデバイスによって扱われるゲームコンソールのテーブルを維持しているなど、明示的であることが可能であり、あるいは、ゲームコンソールの識別子に基づき、どのセキュリティゲートウェイデバイスが、ある特定のゲームコンソールに責任を負うかを判定するなど、暗黙的であることが可能である。
【００２４】
監視サーバ１１２は、データセンタ１１０内のデバイスに使用不可能なゲームコンソール１０２−１〜１０２−ｎ、またはセキュリティゲートウェイ１０４の使用不可能なセキュリティゲートウェイデバイスについて知らせるように動作する。ゲームコンソール１０２−１〜１０２−ｎは、ハードウェアまたはソフトウェアの障害、コンソールが、データセンタ１１０からログアウトすることなしに電源遮断されたこと、コンソール１０２−１〜１０２−ｎに対するネットワーク接続ケーブルが、コンソール１０２−１〜１０２−ｎから接続解除されたこと、その他のネットワーク問題（例えば、コンソール１０２−１〜１０２−ｎが配置されているＬＡＮに動作不良が起きていること）などの様々な異なる理由で使用不可能になる可能性がある。同様に、セキュリティゲートウェイ１０４のセキュリティゲートウェイデバイスも、ハードウェアまたはソフトウェアの障害、デバイスが電源遮断されていること、デバイスに対するネットワーク接続ケーブルが、デバイスから接続解除されていること、その他のネットワーク問題などの様々な異なる理由で使用不可能になる可能性がある。
【００２５】
セキュリティゲートウェイ１０４の中のセキュリティゲートウェイデバイスのそれぞれは、セキュリティゲートウェイデバイスのどれかが使用不可能になったときそれを検出する１つまたは複数の監視サーバ１１２によって監視される。あるセキュリティゲートウェイデバイスが利用不可になった場合、監視サーバ１１２は、データセンタ１１０内のその他のデバイスのそれぞれ（サーバ、フロントドア等）に、そのセキュリティゲートウェイデバイスをもはや使用不可能であるというメッセージを送信する。その他のデバイスのそれぞれは、この情報に基づき、適切と考えられる仕方で動作することができる（例えば、デバイスは、セキュリティゲートウェイデバイスによって管理されているその特定のゲームコンソールが、データセンタ１１０ともはや通信していないものと考え、それに応じて様々なクリーンアップ動作を行うことが可能である）。あるいは、あるデバイスだけ（例えば、セキュリティゲートウェイデバイスが応答可能であるかどうかに関心があるデバイスだけ）が、監視サーバ１１２からそのようなメッセージを受信することが可能である。
【００２６】
セキュリティゲートウェイ１０４は、個々のゲームコンソール１０２−１〜１０２−ｎを監視し、ゲームコンソール１０２−１〜１０２−ｎのどれかが使用不可能になったときそれを検出する。セキュリティゲートウェイ１０４は、ゲームコンソールがもはや使用不可能であることを検出したとき、使用不可能なゲームコンソールを特定する監視サーバ１１２にメッセージを送信する。これに応答して、監視サーバ１１２は、データセンタ１１０内のその他のデバイスのそれぞれに（あるいは、選択されたデバイスだけに）、そのゲームコンソールがもはや使用不可能であるというメッセージを送信する。次に、その他のデバイスのそれぞれは、この情報に基づき、適切であると考えられる仕方で動作することができる。
【００２７】
存在サーバ１１６が、オンラインゲームのためにデータセンタ１１０にログインした所与のユーザのステータスまたは存在に関するデータを維持し、処理する。通知サーバ１１８が、データセンタ１１０にログインしたプレーヤを宛先として発信されるメッセージの複数の待ち行列を維持する。存在−通知フロントドア１１４は、セキュリティゲートウェイ１０４とサーバ１１６および１１８の間の仲介役として動作する１つまたは複数のサーバデバイスである。１つまたは複数のロードバランシングデバイス（図示せず）が、フロントドア１１４として動作する複数のサーバデバイス間で負荷の平衡をとるように存在−通知フロントドア１１４内に含まれることが可能である。セキュリティゲートウェイ１０４は、サーバ１１６および１１８に向けられたメッセージをフロントドア１１４に通信し、フロントドア１１４は、サーバ１１６または１１８のどの特定のサーバにメッセージが通信されるべきかを特定する。フロントドア１１４を使用することにより、どちらのサーバが、どのユーザに関するデータを管理することに責任を負うかなどの、サーバ１１６および１１８の実際の実施が、セキュリティゲートウェイ１０４から抽出される。セキュリティゲートウェイ１０４は、単に、存在−通知サービスを目標とするメッセージを存在−通知フロントドア１１４に転送し、フロントドア１１４が、そのメッセージをサーバ１１６およびサーバ１１８の適切なものにルーティングすることに頼ることができる。
【００２８】
マッチサーバ１２２が、オンラインプレーヤの互いとのマッチングに関するデータを維持し、処理する。オンラインユーザは、行われる用意のあるゲーム、ならびにゲームの様々な特性（例えば、フットボールゲームが行われる場所、ゲームが日中におこなわれるか、または夜に行われるか、ユーザの技能レベル等）を公示することができる。以上の様々な特性を基準として使用して、一緒にゲームを行うように様々なオンラインユーザを組み合わせることができる。マッチフロントドア１２０は、１つまたは複数のサーバデバイス（および、オプションとして、ロードバランシングデバイス）を含み、フロントドア１１４が、サーバ１１６およびサーバ１１８を抽出するのと同じ仕方で、セキュリティゲートウェイ１０４からマッチサーバ１２２を抽出するように動作する。
【００２９】
統計サーバ１２６は、オンラインゲームに関する様々な統計に関するデータを維持し、処理する。使用される特定の統計は、ゲーム設計者の所望に基づき、様々である可能性がある（例えば、上位の第１０位までのスコアまたは時間、ゲームのすべてのオンラインプレーヤに関する世界ランキング、最も多くのアイテムを見出した、または最も多くの時間をゲームをして過ごしたユーザのリスト）。統計フロントドア１２６は、１つまたは複数のサーバデバイス（および、オプションとして、ロードバランシングデバイス）を含み、フロントドア１１４が、サーバ１１６およびサーバ１１８を抽出するのと同じような仕方でセキュリティゲートウェイ１０４から統計サーバ１２６を抽出するように動作する。
【００３０】
したがって、セキュリティゲートウェイ１０４が、信頼されない公衆ネットワーク１０６から、データセンタ１１０のセキュアゾーン内にデバイスを遮蔽するように動作するのを見て取ることができる。データセンタ１１０内の通信は、データセンタ１１０内のすべてのデバイスが信頼されるものであるので、暗号化される必要がない。しかし、データセンタ１１０内のデバイスからゲームコンソール１０２−１〜１０２−ｎに通信されるあらゆる情報は、セキュリティゲートウェイ１０４のクラスタを通過し、その情報によって目標とされるゲームコンソール１０２−１〜１０２−ｎだけが解読できるような仕方で暗号化される。
【００３１】
図２は、例示的なセキュリティゲートウェイデバイス１５０をより詳細に示すブロック図である。複数のセキュリティゲートウェイデバイス１５０が、セキュリティゲートウェイ１０４内に含まれることが可能である。セキュリティゲートウェイデバイス１５０は、公衆ネットワークインタフェース１５２、パケット解読モジュール１５４、パケット認証モジュール１５６、ゲームコンソール認証モジュール１５８、ネットワークアドレス変換（ＮＡＴ）トラバーサル（ｔｒａｖｅｒｓａｌ）モジュール１６０、認証情報生成モジュール１６２、パケット暗号化モジュール１６４、ハートビートモジュール１６６、ティクル（ｔｉｃｋｌｅ）モジュール１６８、セキュアゾーンインタフェース１７０、セキュリティ関係レコード１７２、ゲームコンソールアベイラビリティ（ａｖａｉｌａｂｉｌｉｔｙ）モジュール１７６、およびパケットルーティングモジュール１７８を含む。本明細書では、互いにデータを通信する、または互いにデータを使用可能とするセキュリティゲートウェイデバイス１５０のモジュールについて述べる。この通信、またはこの可用性は、データを含むデータ構造をあるモジュールから別のモジュールに送ること、データが記憶されている場所に対する（例えば、メモリロケーションに対する）ポインタをあるモジュールから別のモジュールに送ることなどの多種多様な異なる仕方で実施することができる。
【００３２】
公衆ネットワークインタフェース１５２は、公衆ネットワーク（例えば、図１のネットワーク）を介してゲームコンソール１０２と通信するインタフェースとして動作する。パケット解読モジュール１５４は、ゲームコンソール１０２から受信されたデータパケットを解読するように動作し、またパケット認証モジュール１５６は、ゲームコンソール１０２から受信されたパケットを認証するように動作する。ゲームコンソール認証モジュール１５８は、ゲームコンソール１０２を認証するように動作する。ＮＡＴトラバーサルモジュール１６０は、ゲームコンソール１０２からのパケットをデータセンタ１１０内のデバイスに転送するように、またはデータセンタ１１０内のデバイスからのパケットをゲームコンソール１０２に転送するように動作する。認証情報生成モジュール１６２は、ゲームコンソール１０２に送信されるパケットに関する認証情報を生成するように動作し、またパケット暗号化モジュール１６４は、ゲームコンソール１０２に送信されるパケットを暗号化するように動作する。ハートビートモジュール１６６は、ゲームコンソール１０２に送信されるハートビートパケットを生成するように動作し、またティクルモジュール１６８は、ゲームコンソール１０２に送信されるハートビートパケット上に含まれる（ピギーバックされる（ｐｉｇｇｙｂａｃｋｅｄ　ｏｎ））データを管理するように動作する。セキュアゾーンインタフェース１７０は、専用ネットワーク（例えば、図１のネットワーク１０８）を介してデータセンタ内の他のデバイスと通信するためのインタフェースとして動作する。セキュリティ関係レコード１７２は、セキュリティゲートウェイデバイス１５０から様々なゲームコンソール１０２へのセキュアな通信チャネルに関連するセキュリティ情報のレコードである。ゲームコンソールアベイラビリティモジュール１７６は、ゲームコンソールが使用不可能になったときそれを検出し、またパケットルーティングモジュール１７８は、様々なタイプのパケットを検出し、それに応じてパケットをルーティングする。
【００３３】
図３〜６を参照して、セキュリティゲートウェイデバイス１５０の動作について以下により詳細に述べる。
【００３４】
図３は、ゲームコンソールとセキュリティゲートウェイデバイスの間でセキュアな通信チャネルを確立するための例示的なプロセス２００を示す流れ図である。図３のプロセスは、セキュリティゲートウェイデバイス（例えば、図２のデバイス１５０）によって実施され、ソフトウェアで、ファームウェアで、ハードウェアで、または以上の組合せで行うことができる。図３のプロセスについて、図１および２の構成要素を参照して述べる。
【００３５】
最初、セキュリティチケットが、セキュリティゲートウェイデバイスにおいて受信される（動作２０２）。１つの例示的な実施形態では、セキュリティチケットは、図１の鍵配信センタ１２８から獲得されるケルベロス（Ｋｅｒｂｅｒｏｓ）チケットである。ケルベロスチケットは、単一のチケットの中で、特定のゲームコンソール１０２の識別、およびそのゲームコンソール１０２においてゲームを行っている１名または複数名のユーザの識別を認証するケルベロス様式の認証プロトコルを使用してゲームコンソール１０２によって獲得される。ゲームコンソール１０２は、ケルベロスチケットを以下のように獲得する。
【００３６】
解説のため、ゲームコンソール１０２の４名のユーザが存在するものと想定する。各ユーザには、識別Ｕ_１、Ｕ_２、Ｕ_３、およびＵ_４が与えられており、ユーザ鍵Ｋ_１、Ｋ_２、Ｋ_３、およびＫ_４が割り当てられている。またゲームコンソール１０２にも独自の識別Ｃ、およびゲームコンソール鍵Ｋ_Ｃが割り当てられている。さらに、ゲームディスクなどのゲームタイトルに、別個の識別Ｇが割り当てられている。同様に、図１のセキュリティゲートウェイ１０４に、独自の識別Ａ、および鍵Ｋ_Ａが割り当てられている。ユーザ、ゲームコンソール、およびセキュリティゲートウェイの認証は、ある程度、鍵Ｋ_１、Ｋ_２、Ｋ_３、Ｋ_４、Ｋ_Ｃ、および鍵Ｋ_Ａに依存することに留意されたい。したがって、以上の鍵を選択し、記憶する際、その鍵が割り当てられたエンティティだけがその鍵を使用することができるように注意が払われなければならない。
【００３７】
ゲームコンソール１０２は、ユーザ識別Ｕ_１、Ｕ_２、Ｕ_３、およびＵ_４、ならびにユーザ鍵Ｋ_１、Ｋ_２、Ｋ_３、Ｋ_４に基づき、検証されたユーザ識別を生成する。より具体的には、検証されたユーザ識別は、ユーザ鍵から導出されたユーザ識別、および値を含む。検証されたユーザ識別は、鍵配信センタに要求とともにサブミットされ、ゲームコンソールがユーザ鍵の知識を有することを鍵配信センタに実証するのに使用され、したがって、ユーザを暗黙的に認証する。
【００３８】
様々なメッセージおよび鍵が計算される仕方の説明を簡単にするため、以下の表記を導入する。
【００３９】
Ｈ＝Ｈ_Ｋｙ（Ｍ）：Ｈは、鍵Ｋ_Ｙを使用するメッセージＭの鍵付き一方向ハッシュ（ＭＡＣ（ｍｅｓｓａｇｅ　ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｃｏｄｅ））である。任意のＭＡＣアルゴリズムを使用することができる。そのようなＭＡＣの一例が、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ｔａｓｋ　Ｆｏｒｃｅ）ＲＦＣ（Ｒｅｑｕｅｓｔ　Ｆｏｒ　Ｃｏｍｍｅｎｔｓ）　２１０４に準拠するＨＭＡＣ（ｈａｓｈ　ｂａｓｅｄ　ＭＡＣ）アルゴリズムである。
【００４０】
ＥｎｃｒｙｐｔｅｄＭ＝Ｅ_Ｋｙ（Ｍ）：ＥｎｃｒｙｐｔｅｄＭは、鍵Ｋ_Ｙを使用して暗号化された形態のメッセージＭである。任意の暗号化アルゴリズムを使用することができる。そのような暗号化アルゴリズムの例には、ＤＥＳ（Ｄａｔａ　Ｅｎｃｒｙｐｔｉｏｎ　Ｓｔａｎｄａｒｄ）、トリプルＤＥＳ、およびＲＣ４−ＨＭＡＣが含まれる。
【００４１】
Ｍ＝Ｄ_Ｋｙ（ＥｎｃｒｙｐｔｅｄＭ）：Ｍは、同一の鍵Ｋ_Ｙを使用して暗号化される前のＥｎｃｒｙｐｔｅｄＭの元のメッセージである。
【００４２】
鍵導出値（ｋｅｙ　ｄｅｒｉｖａｔｉｖｅ　ｖａｌｕｅ）を生成する１つのやり方は、ゲームコンソールの鍵を使用してユーザ鍵の暗号ハッシュを計算することである。鍵Ｋ_１を有するユーザＵ_１の場合、ハッシュＨ_１は、以下のとおり計算される。
Ｈ_１＝Ｈ_Ｋｃ（Ｋ_１）
【００４３】
ハッシュＨ_１が鍵導出値を成す。別のやり方は、ユーザ鍵Ｋ_１を使用して現在時刻を暗号化することである。
Ｈ_１＝Ｅ_Ｋ１（Ｔ）
【００４４】
この場合も、もたらされる値Ｈ_１が鍵導出値を成す。検証されたユーザ識別は、以下のとおり、ユーザ識別Ｕ_１と対応する鍵導出値Ｈ_１の組合せである。
検証されたユーザ識別＝（Ｕ_１，Ｈ_１）
【００４５】
ゲームコンソール１０２は、ゲームコンソール識別Ｃ、ゲームタイトル識別Ｇ、セキュリティゲートウェイデバイス１５０のオンラインサービス識別Ａ（これは、図１のセキュリティゲートウェイ１０４の中のセキュリティゲートウェイデバイスのすべてに関して同一である）、および複数の検証されたユーザ識別（Ｕ_１，Ｈ_１）、（Ｕ_２，Ｈ_２）、（Ｕ_３，Ｈ_３）、および（Ｕ_４，Ｈ_４）を含む要求を構成する。要求は、以下の識別文字列を有する。
要求　＝　［Ｃ，　Ｇ，　Ａ，　（Ｕ_１，　Ｈ_１），　（Ｕ_２，　Ｈ_２），　（Ｕ_３，　Ｈ_３），　（Ｕ_４，　Ｈ_４）］
【００４６】
さらに、要求は、あるバージョンの認証プロトコル、およびゲームコンソールによって生成されたランダムなナンス（ｎｏｎｃｅ）を含み、リプライ攻撃に抗することが可能である。要求は、識別文字列全体の受信を検証するのに使用されるチェックサム値をさらに含むことが可能である。ゲームコンソール１０２は、ネットワーク（例えば、図１のネットワーク１０６）を介して要求を鍵配信センタにサブミットする。
【００４７】
鍵配信センタは、要求、ならびにその要求に含まれる識別を評価する。鍵配信センタは、セキュリティゲートウェイデバイス１５０のために使用されるランダムなセッション鍵を生成する。この例では、鍵配信センタは、セキュリティゲートウェイ１０４と通信する際にゲームコンソール１０２によって使用されるランダムなセッション鍵Ｋ_ＣＡを生成する（動作２０２において）。
【００４８】
鍵配信センタは、ゲームコンソール１０２によってセキュリティゲートウェイデバイス１５０に後に提示されるチケットを生成する。セキュリティゲートウェイデバイス１５０に関して発行される１つのチケットが存在するが、チケットは、複数のユーザに関して有効である。チケットは、要求の中でサブミットされた識別文字列を含む。また、チケットは、チケットが生成された時刻Ｔ_Ｇ、チケットの失効までの時間の長さを特定する時間Ｔ_Ｌ、セキュリティゲートウェイデバイス１５０に関するランダムに生成されたセッション鍵Ｋ_ＣＡ、およびゲームコンソール１０２のユーザがアクセスすることが許されたデータセンタ１１０内のサービスデバイスを特定するサービスマップＳ_ｍも含む。鍵配信センタは、どのユーザがどのサービスにアクセスすることが許されているか（例えば、どのユーザが、１つまたは複数の有料サービスにアクセスする料金を支払済みであるか）についてのレコードを維持するか、そのレコードを維持する別のデバイス、または別のセンタにアクセスする。チケット内容は、以下のとおり、セキュリティゲートウェイデバイスの鍵Ｋ_Ａを利用する対称鍵暗号（例えば、トリプルＤＥＳ）を介して暗号化される。
チケット　＝　Ｅ_ＫＡ　［Ｔ_Ｇ，　Ｔ_Ｌ，　Ｋ_ＣＡ，　Ｓ_ｍ，　Ｃ，　Ｇ，　Ａ，　Ｕ_１　，Ｕ_２　，Ｕ_３　，Ｕ_４］
【００４９】
チケットは、対応する鍵導出値Ｈ_ｉを担持しないことに注目されたい。鍵配信センタは、鍵導出値を読み取り、ゲームコンソールがユーザ鍵を知っていると確信すると、ユーザの識別を発行されるチケットの中に入れる。セキュリティゲートウェイデバイス１５０は、その後、チケットが知らせることはなんでも信頼し、したがって、鍵導出値Ｈ_ｉを見る必要がない。
【００５０】
鍵配信センタは、生成されたチケットをゲームコンソール１０２に戻す。ゲームコンソール１０２は、セキュリティゲートウェイデバイスの鍵Ｋ_Ａを知らないので、そのチケットを開くことができず、その内容を変更することができない。また、鍵配信センタは、添付された暗号化されたメッセージの中でセッションセキュリティ鍵も戻す。セッション鍵メッセージは、チケット生成時刻Ｔ_Ｇ、チケット失効までの期間Ｔ_Ｌ、およびセッションセキュリティ鍵Ｋ_ＣＡを含み、すべての内容は、以下のとおり、ゲームコンソールの鍵Ｋ_Ｃを使用して暗号化される。
セッション鍵メッセージ　＝　Ｅ_ＫＣ　［Ｔ_Ｇ，　Ｔ_Ｌ，　Ｋ_ＣＡ］
【００５１】
セッション鍵メッセージは、ゲームコンソールの鍵Ｋ_Ｃで暗号化されているので、ゲームコンソール１０２は、セッション鍵メッセージを開き、セッション時間パラメータおよびセッション鍵を回復することができる。
【００５２】
ゲームコンソール１０２（例えば、あるゲームコンソール）は、チケットを受け取ると、そのチケットを使用して、セキュリティゲートウェイデバイス１５０と相互認証を伴うセキュアな鍵交換を行うことができる（動作２０４）。セキュアな鍵交換に関するさらなる情報は、本明細書に組み込まれている米国特許出願１０／１７０、００２号で見ることができる。米国特許出願１０／１７０、００２号の内容は後述される。
【００５３】
鍵交換により、ゲームコンソール１０２およびセキュリティゲートウェイデバイス１５０が、コンソール１０２とデバイス１５０の間で共有されるが、２つのデバイス間で伝送されることなく、コンソール１０２とデバイス１５０の間で往復するトラフィックに基づいて第三者（例えば、コンソール１０２およびデバイス１５０と同じネットワーク上の別のデバイス）が推論することができない新しい秘密を導出することが可能になる。１つの例示的な実施では、２つのデバイスは、ディフィ−ヘルマン指数演算（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ　ｅｘｐｏｎｅｎｔｉａｔｉｏｎ　ｏｐｅｒａｔｉｏｎ）を使用して新しい秘密を導出する。ディフィ−ヘルマンに関するさらなる情報は、Ｗ．　Ｄｉｆｆｉｅ　ａｎｄ　Ｍ．　Ｅ．　Ｈｅｌｌｍａｎ，　”Ｎｅｗ　ｄｉｒｅｃｔｉｏｎｓ　ｉｎ　Ｃｒｙｐｔｏｇｒａｐｈｙ”，　ＩＥＥＥ　Ｔｒａｎｓａｃｔｉｏｎｓ　ｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔｈｅｏｒｙｖ．　ＩＴ−１２，　ｎ．　６，　Ｎｏｖ　１９７６，　ｐｐ．　６４４−６５４に見ることができる。
【００５４】
一般に、セキュアな鍵交換は、鍵交換イニシエータ（ｉｎｉｔｉａｔｏｒ）パケットを生成し、そのパケットをセキュリティゲートウェイデバイス１５０に送信するゲームコンソール１０２によって行われる。セキュリティゲートウェイデバイス１５０は、鍵交換イニシエータパケットを受信し、受信されたパケットを検証する。パケットが検証されると、セキュリティゲートウェイデバイス１５０は、ゲームコンソール１０２との通信をセキュアにするのに使用される暗号鍵を生成する。例示的な実施形態では、この暗号鍵は、２つのデバイス間のポイントツーポイント通信をセキュアにするのに使用されるセキュリティ関係鍵である。次に、セキュリティゲートウェイデバイス１５０は、鍵交換応答パケットを生成し、生成されたパケットをゲームコンソール１０２に送信する。ゲームコンソール１０２は、鍵交換応答パケットを受信し、その受信されたパケットを検証する。パケットが検証されると、ゲームコンソール１０２は、セキュリティゲートウェイデバイス１５０との通信をセキュアにするのに使用される暗号鍵を生成する。暗号鍵は、セキュリティゲートウェイデバイス１５０によって生成されるものと同じである。したがって、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０はともに、同じ暗号鍵を有することになるが、双方の間で鍵を実際に伝送することなしにそうなる。
【００５５】
ゲームコンソール１０２は、鍵交換イニシエータメッセージを最初に生成することによって鍵交換イニシエータパケットを生成し、送信する。鍵交換イニシエータメッセージは、以下のとおり、ＮｏｎｃｅＩｎｉｔと呼ばれるゲームコンソール１０２によって生成されたランダム（または擬似ランダム）値を含み、またＸがやはり、ゲームコンソール１０２によって生成されたランダムな（または擬似ランダムな）数であるディフィ−ヘルマン（ｇ^Ｘ　ｍｏｄ　Ｎ）値、ならびに鍵交換プロセスが完了した後、このコンソール／セキュリティデバイス通信チャネルを一意的に定義するのに使用されるセキュリティパラメータインデックス値（ＳＰＩ_１）を含む。
ＩｎｉｔＭｅｓｓ　＝　［ＮｏｎｃｅＩｎｉｔ，　ＳＰＩ_１，　（ｇ^Ｘ　ｍｏｄ　Ｎ）］
【００５６】
次に、ゲームコンソール１０２は、鍵配信センタから受信されたケルベロスセッション鍵Ｋ_ＣＡを使用して鍵交換イニシエータメッセージのダイジェストを計算する。ダイジェストは、次のとおり計算される。
【００５７】
【数１】

【００５８】
あるいは、一般的な一方向ハッシュ（鍵付きでない）も、ＨａｓｈＩｎｉｔＭｅｓｓの計算において使用することが可能である。鍵のセキュリティは、このハッシュが鍵付きであるか否かに依拠しない。
【００５９】
次に、ゲームコンソール１０２は、ケルベロスオーセンティケータ（ａｕｔｈｅｎｔｉｃａｔｏｒ）を生成する。ケルベロスオーセンティケータは、タイムスタンプ（例えば、ゲームコンソール１０２の現在時刻）、およびＨａｓｈＩｎｉｔＭｅｓｓダイジェストを含む。タイムスタンプは、ゲームコンソール１０２がケルベロスオーセンティケータを生成するたびに毎回、そのデバイス１０２によって増分され、これにより、セキュリティゲートウェイデバイス１５０が、リプレイ攻撃をよりよく検出することが可能になる。ゲームコンソール１０２は、以下のとおり、ケルベロスセッション鍵Ｋ_ＣＡを使用してケルベロスオーセンティケータを暗号化する。
【００６０】
【数２】

【００６１】
次に、ゲームコンソール１０２は、鍵交換イニシエータパケットを生成する。鍵交換イニシエータパケットは、鍵交換イニシエータメッセージＩｎｉｔＭｅｓｓ、暗号化されたケルベロスオーセンティケータＡｕｔｈ_Ｔ、および鍵配信センタ（例えば、図１のセンタ１２８）から受信されたセキュリティゲートウェイデバイス１５０に関するケルベロスチケットを含む。前述したとおり、ケルベロスチケットは、少なくとも、ケルベロスセッション鍵（Ｋ_ＣＡ）、チケットが有効でありつづけるある範囲の時間、ゲームコンソール１０２を識別する一意的な番号を含み、以上のすべてが、鍵配信センタとセキュリティゲートウェイデバイス１５０によって共用される秘密の鍵を使用して暗号化される。ＳＰＩ値は、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間のセキュリティ関係、すなわち、通信チャネルを識別する。ＳＰＩ_１値は、セキュリティゲートウェイデバイス１５０からゲームコンソール１０２への通信に関連し、またＳＰＩ_２値は、ゲームコンソール１０２からセキュリティゲートウェイデバイス１５０への通信に関連する。したがって、鍵交換イニシエータパケットは、以下のとおりである。
ＩｎｉｔＰａｃｋｅｔ　＝　［ＩｎｉｔＭｅｓｓ，　Ａｕｔｈ_Ｔ，　Ｔｉｃｋｅｔ］
【００６２】
オーセンティケータとチケットの組合せは、ケルベロス用語においてＡＰ要求と呼ばれていることに留意されたい。次に、ゲームコンソール１０２は、鍵交換イニシエータパケットをセキュリティゲートウェイデバイス１５０に送信する。
【００６３】
セキュリティゲートウェイデバイス１５０は、鍵交換イニシエータパケットＩｎｉｔＰａｃｋｅｔを受信する。一実施では、セキュリティゲートウェイデバイス１５０は、すべての鍵交換イニシエータパケットが所定の形式になっており、かつ所定のサイズであることを予期している。その所定の形式でない、またはその所定のサイズでないあらゆる鍵交換イニシエータパケットは、セキュリティゲートウェイデバイス１５０によって無視される。あるいは、セキュリティゲートウェイデバイス１５０は、鍵交換イニシエータパケットが、様々な形式になっており、かつ／または様々なサイズになっていることを許すことが可能である。
【００６４】
鍵交換イニシエータパケットが受信されると、セキュリティゲートウェイデバイス１５０は、そのセキュリティゲートウェイデバイス１５０が鍵配信センタと共有する鍵を使用してケルベロスチケットを解読する。次に、セキュリティゲートウェイデバイス１５０は、解読されたチケットをチェックして、チケットが失効しているかどうかを判定する。現在時刻が、チケットが有効でありつづける時間の範囲（チケットの中で特定される）内に含まれる場合、そのチケットは、失効していない。しかし、現在時刻が、チケットが有効でありつづける時間の範囲内に含まれない場合、そのチケットは、失効している。ケルベロスチケットが失効している場合、鍵交換プロセスは失敗し、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間でセキュリティ関係が全く確立されないことがもたらされる。セキュリティゲートウェイデバイス１５０は、鍵交換プロセスが失敗したことをゲームコンソール１０２に通知することができ、あるいは、セキュリティゲートウェイデバイス１５０は、受信されたＩｎｉｔＰａｃｋｅｔを単に削除して、ゲームコンソール１０２に通知を行わないことが可能である。
【００６５】
しかし、ケルベロスチケットが失効していない場合、セキュリティゲートウェイデバイス１５０は、解読されたケルベロスチケットから回復されたケルベロスセッション鍵Ｋ_ＣＡを使用してケルベロスオーセンティケータＡｕｔｈ_Ｔを解読する。次に、セキュリティゲートウェイデバイス１５０は、ケルベロスオーセンティケータの中のタイムスタンプＴｉｍｅにアクセスし、そのタイムスタンプが受入れ可能であるかどうかをチェックする。タイムスタンプは、セキュリティゲートウェイデバイス１５０上の現在時刻との同期が離れすぎていない場合、受入れ可能である。例示的な実施では、タイムスタンプは、セキュリティゲートウェイデバイス１５０上の現在時間からある閾値時間（例えば、推奨されるケルベロス時間スキューである５分間）の範囲内にある場合、受入れ可能である。タイムスタンプが受入れ可能ではない場合、鍵交換プロセスは失敗である。
【００６６】
タイムスタンプが受入れ可能である場合、セキュリティゲートウェイデバイス１５０は、鍵交換メッセージＩｎｉｔＭｅｓｓのダイジェストを計算する。セキュリティゲートウェイデバイス１５０は、ゲームコンソール１０２がダイジェストＨａｓｈＩｎｉｔＭｅｓｓを計算したのと同じ仕方でダイジェストを計算する。次に、セキュリティゲートウェイデバイス１５０は、計算したダイジェスト値が、暗号化されたケルベロスオーセンティケータＡｕｔｈ_Ｔの一部としてゲームコンソール１０２から受け取られたダイジェスト値と一致する（等しい）かどうかをチェックする。２つのダイジェスト値が同じである場合、そのことは、鍵交換メッセージＩｎｉｔＭｅｓｓが、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間で変更されていない（例えば、鍵交換メッセージＩｎｉｔＭｅｓｓが不正変更されていない）ことを確認する役割をする。２つのダイジェスト値が一致しない場合（言い換えれば、２つのダイジェスト値が等しくない場合）、鍵交換プロセスは失敗である。
【００６７】
しかし、受け取られたダイジェスト値と計算されたダイジェスト値が一致する場合、セキュリティゲートウェイデバイス１５０は、ケルベロスオーセンティケータが再生されているかどうかをチェックする。セキュリティゲートウェイデバイス１５０は、各ゲームコンソールＣから受け取った各ケルベロスオーセンティケータからのタイムスタンプのレコード（これは、ケルベロスチケットの中で明らかにされる）を維持する。セキュリティゲートウェイデバイス１５０は、そのセキュリティゲートウェイデバイス１５０によって記録された最新のタイムスタンプより新しくないタイムスタンプＴｉｍｅを伴うケルベロスオーセンティケータを受け取った場合、そのケルベロスオーセンティケータが再生されていることを知る。ケルベロスオーセンティケータが再生されている場合、鍵交換イニシエータパケットは有効ではなく、鍵交換プロセスは失敗である。しかし、ケルベロスオーセンティケータが再生されていない場合、鍵交換イニシエータパケットは、セキュリティゲートウェイデバイス１５０によって検証されたことになる。以上すべての試験が満たされ、かつ鍵交換イニシエータパケットが検証された場合、セキュリティゲートウェイデバイス１５０は、ゲームコンソール１０２を、実際にゲームコンソール１０２による主張どおりのデバイスであるものとして認証した、すなわち、セキュリティゲートウェイデバイス１５０は、ゲームコンソール１０２がケルベロスセッション鍵Ｋ_ＣＡの知識を有すること検証したことになる。
【００６８】
最初、セキュリティゲートウェイデバイス１５０は、鍵交換イニシエータメッセージＩｎｉｔＭｅｓｓ、ケルベロスセッション鍵Ｋ_ＣＡ、ゲームコンソール１０２からのナンス（ＮｏｎｃｅＩｎｉｔ）、およびセキュリティゲートウェイデバイス１５０によって生成されたナンス（ＮｏｎｃｅＲｅｓｐ）に基づいて暗号鍵を生成する。セキュリティゲートウェイデバイス１５０は、ランダムな（または擬似ランダムな）数Ｙ、ならびにＮｏｎｃｅＲｅｓｐと呼ばれるランダム値を生成する。セキュリティゲートウェイデバイス１５０は、ディフィ−ヘルマン値（ｇ^ＸＹ　ｍｏｄ　Ｎ）、およびディフィ−ヘルマン値（ｇ^Ｙ　ｍｏｄ　Ｎ）をさらに計算する。この時点で、セキュリティゲートウェイデバイス１５０は、セキュリティ関係鍵を計算するのに十分なデータを有する。セキュリティ関係鍵は、２つのコンソール間のポイントツーポイント通信をセキュアにするのに使用される。例示的な実施では、セキュリティゲートウェイデバイス１５０は、２つのディフィ−ヘルマン値（（ｇ^Ｘ　ｍｏｄ　Ｎ）および（Ｙ））を使用して関数（ｇ^ＸＹ　ｍｏｄ　Ｎ）を計算する。次に、セキュリティゲートウェイデバイス１５０は、ＮｏｎｃｅＩｎｉｔ、ＮｏｎｃｅＲｅｓｐ、（ｇ^ＸＹ　ｍｏｄ　Ｎ）、およびケルベロスセッション鍵Ｋ_ＣＡに基づく様々なアルゴリズムを使用して様々なダイジェストを計算することができる。次に、そのダイジェストを使用してセキュリティ関係鍵を形成する。１つの例示的な実施では、セキュリティゲートウェイデバイス１５０は、ＮｏｎｃｅＩｎｉｔ、ＮｏｎｃｅＲｅｓｐ、および（ｇ^ＸＹ　ｍｏｄ　Ｎ）を入力として使用し、またケルベロスセッション鍵Ｋ_ＣＡも使用して、両方向ですべてのセキュアなパケットを認証し、かつ暗号化／解読するためのセキュリティ関係鍵として使用される４つの異なるダイジェストを計算する（認証のための１つの鍵、暗号化のための１つの鍵にそれぞれの方向として２を掛けて、合計で４になる）。あるいは、セッション鍵Ｋ_ＣＡ自体を両方向でセキュアなパケットを認証し、かつ／または暗号化／解読するために使用することができる。
【００６９】
次に、セキュリティゲートウェイデバイス１５０は、鍵交換応答メッセージを生成する。鍵交換応答メッセージは、以下のとおり、ＮｏｎｃｅＩｎｉｔ、ゲームコンソール１０２から受信されたタイムスタンプＴｉｍｅ、ＮｏｎｃｅＲｅｓｐ、ディフィ−ヘルマン値（ｇ^Ｙ　ｍｏｄ　Ｎ）、およびＳＰＩ_２値を含む。
ＲｅｓｐＭｅｓｓ　＝　［ＮｏｎｃｅＩｎｉｔ，　ＳＰＩ_２，　ＮｏｎｃｅＲｅｓｐ，　（ｇ^Ｙ　ｍｏｄ　Ｎ）］
【００７０】
ＳＰＩ_２値は、セキュリティゲートウェイデバイス１５０によって生成され、ゲームコンソール１０２からセキュリティゲートウェイデバイス１５０へのすべての通信に関連付けられる。次に、セキュリティゲートウェイデバイス１５０は、以下のとおり、ケルベロスセッション鍵およびハッシュ関数Ｈを使用して応答メッセージのダイジェストを計算する。
【００７１】
【数３】

【００７２】
ＨａｓｈＲｅｓｐＭｅｓｓを生成するのに使用されるハッシュ関数Ｈは、ＨａｓｈＩｎｉｔＭｅｓｓ（前述した）を生成するのに使用されるハッシュ関数Ｈと同一であること、あるいは異なるハッシュ関数であることが可能である。
【００７３】
次に、セキュリティゲートウェイデバイス１５０は、以下のとおり、計算されたハッシュダイジェストと、ケルベロスオーセンティケータからのタイムスタンプＴｉｍｅをともに含むケルベロス応答メッセージを生成する。
ＲｅｐｌｙＭｅｓｓ　＝　［ＨａｓｈＲｅｓｐＭｅｓｓ，　Ｔｉｍｅ］
【００７４】
次に、セキュリティゲートウェイデバイス１５０は、以下のとおり、暗号化アルゴリズムＥ（例えば、トリプルＤＥＳ）およびケルベロスセッション鍵Ｋ_ＣＡを使用してケルベロス応答メッセージＲｅｐｌｙＭｅｓｓを暗号化する。
【００７５】
【数４】

【００７６】
ＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓを生成するのに使用される暗号化アルゴリズムＥは、Ａｕｔｈ_Ｔ（前述した）を生成するのに使用されたのと同一の暗号化アルゴリズムであること、あるいは異なる暗号化アルゴリズムであることが可能である。
【００７７】
次に、セキュリティゲートウェイデバイス１５０は、以下のとおり、鍵交換応答メッセージＲｅｓｐＭｅｓｓ、および暗号化されたケルベロス応答メッセージＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓを含む鍵交換応答パケットを生成する。
ＲｅｓｐＰａｃｋｅｔ　＝　［ＲｅｓｐＭｅｓｓ，　ＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓ］
【００７８】
次に、セキュリティゲートウェイデバイス１５０は、鍵交換応答パケットＲｅｓｐＰａｃｋｅｔをゲームコンソール１０２に送信する。
【００７９】
ゲームコンソール１０２は、セキュリティゲートウェイデバイス１５０から鍵交換応答パケットＲｅｓｐＰａｃｋｅｔを受信する。ゲームコンソール１０２は、ケルベロスセッション鍵Ｋ_ＣＡを使用してケルベロス応答メッセージＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓを解読する。次に、ゲームコンソール１０２は、解読された応答メッセージの中のタイムスタンプＴｉｍｅが、ゲームコンソール１０２がセキュリティゲートウェイデバイス１５０に送信したタイムスタンプＴｉｍｅと一致するかどうかをチェックする。両タイムスタンプが一致する場合（言い換えれば、タイムスタンプが等しい場合）、その一致により、セキュリティゲートウェイデバイス１５０が、ケルベロスチケットおよびケルベロスオーセンティケータを解読する（したがって、ケルベロスセッション鍵Ｋ_ＣＡの知識を有する）ことができ、したがって、現実に、自ら主張するとおりのセキュリティゲートウェイデバイス１５０であることが確認される。したがって、セキュリティゲートウェイデバイス１５０は、以上のタイムスタンプ値が一致する場合、ゲームコンソール１０２に対して認証される。
【００８０】
タイムスタンプ値が一致しない場合、鍵交換プロセスは失敗であり、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間で全くセキュリティ関係が確立されないことがもたらされる（前述したのと同様に、ゲームコンソール１０２は、鍵交換プロセスが失敗したことをセキュリティゲートウェイデバイス１５０に通知することも、通知しないことも可能である）。ただし、タイムスタンプ値が一致した場合、セキュリティゲートウェイデバイス１５０は、ゲームコンソール１０２に対して認証され、ゲームコンソール１０２は、ケルベロスセッション鍵Ｋ_ＣＡを使用して鍵交換応答メッセージＲｅｓｐＭｅｓｓのダイジェストを計算することにとりかかる。ゲームコンソール１０２は、セキュリティゲートウェイデバイス１５０がＨａｓｈＲｅｓｐＭｅｓｓ（前述した）を計算したのと同じやり方でダイジェストを計算する。次に、ゲームコンソール１０２は、自らが計算したダイジェスト値が、暗号化されたケルベロス応答メッセージＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓの一部としてセキュリティゲートウェイデバイス１５０から受け取られたダイジェスト値と一致する（等しい）かどうかをチェックする。２つのダイジェスト値が同じである場合、そのことは、鍵交換応答メッセージＲｅｓｐＭｅｓｓが、セキュリティゲートウェイデバイス１５０とゲームコンソール１０２の間で変更されていない（例えば、鍵交換応答メッセージＲｅｓｐＭｅｓｓが不正変更されていない）ことを確認する役割をする。２つのダイジェスト値が一致しない場合（言い換えれば、２つのダイジェスト値が等しくない場合）、鍵交換プロセスは、失敗である。
【００８１】
ただし、２つのダイジェスト値が一致した場合、ゲームコンソール１０２は、ケルベロスセッション鍵Ｋ_ＣＡ、ＮｏｎｃｅＩｎｉｔ、ＮｏｎｃｅＲｅｓｐ、およびｇ^ＸＹ　ｍｏｄ　Ｎに基づいて暗号鍵を生成する。セキュリティゲートウェイデバイス１５０が暗号鍵を生成することに関して前述したのと同様に、この時点で、ゲームコンソール１０２は、ディフィ−ヘルマン値（ｇ^ＸＹ　ｍｏｄ　Ｎ）を計算し、またセキュリティ関係鍵を計算するのに十分なデータを有している。ゲームコンソール１０２によって計算されるセキュリティ関係鍵は、セキュリティゲートウェイデバイス１５０によって生成されるものと同じであり、同じやり方で計算される。ｇ^ＸＹ　ｍｏｄ　Ｎは、ゲームコンソール上のｇ^Ｙ　ｍｏｄＮ、およびＸから計算されることに留意されたい。また、前述したのと同様に、別法として、セッション鍵Ｋ_ＣＡ自体を両方向でセキュアなパケットを認証し、かつ／または暗号化／解読するために使用できることにも留意されたい。
【００８２】
ゲームコンソール１０２は、セッション関連鍵を有すると、鍵交換が完了するのを待っていたあらゆるパケットを自由に伝送することができる。ただし、セキュリティゲートウェイデバイス１５０は、同一のセットの鍵を有していても、それを自由に行うことができない。というのは、自らの応答メッセージＲｅｓｐＭｅｓｓが失われていないと確信することができないからである。セキュリティゲートウェイデバイス１５０は、ゲームコンソール１０２からの計算されたセキュリティ関係鍵で認証されたパケットを受信するまで待つか、またはオプションとして、ゲームコンソール１０２から肯定応答パケット（ＡｃｋＰａｃｋ）を受信するまで待つ。
【００８３】
一般的なケースでは、ゲームコンソール１０２は、パケットをセキュリティゲートウェイデバイス１５０に送信し、したがって、鍵交換プロセスは、２つのパケットだけから、すなわち、ＩｎｉｔＰａｃｋｅｔおよびＲｅｓｐＰａｃｋｅｔだけから成る。あるいは、ゲームコンソール１０２が、送信するパケットを有さない場合、ゲームコンソール１０２は、擬似の肯定応答パケット（「ＡｃｋＰａｃｋ」として表される）を送信する。ＡｃｋＰａｃｋは、ケルベロスセッション鍵Ｋ_ＣＡではなく、計算されたセキュリティ関係鍵を使用してハッシングされることで、このパケットは、他の２つの鍵交換パケットと異なる。
【００８４】
以降、ゲームコンソール１０２およびセキュリティゲートウェイデバイス１５０は、セキュリティ関係鍵を使用して通信をセキュアにする。相手側に伝送される必要のあるすべてのネットワークパケットは、オプションとして、暗号化された後、認証され、受信側のデバイスが、認証データを検証してから、パケット内容を解読する。コンソール１０２とデバイス１５０のどちらも、同じＮｏｎｃｅを含む相手側からの鍵交換パケットを無視することができる。
【００８５】
セキュリティゲートウェイデバイス１５０は、ゲームコンソール１０２に関するセキュリティ関係情報のレコード１７２を維持する（動作２０６）。このレコードは、ゲームコンソール１０２に送信されるデータパケットを暗号化する際、およびゲームコンソール１０２から受信されたデータパケットを解読する際に使用されるセキュリティ鍵（セキュリティ関係鍵、および／またはセッション鍵Ｋ_ＣＡ）、データセンタ１１０内のどのサービスデバイスにゲームコンソール１０２がアクセスすることが許可されているかを特定するサービスマッピング、完全に適格な（ｆｕｌｌｙ　ｑｕａｌｉｆｉｅｄ）ゲームコンソールアドレス（ＸＮＡＤＤＲとも呼ばれる）、およびセキュリティパラメータインデックス（ＳＰＩ）値を含む。
【００８６】
動作２０４の相互認証の一環として、ゲームコンソール１０２は、自らがセキュリティゲートウェイデバイス１５０に送信する鍵交換パケットの中に含める、ＳＰＩ_１と呼ばれるＳＰＩ値を生成する。同様に、セキュリティゲートウェイデバイス１５０は、自らが、ゲームコンソール１０２に送信される鍵交換応答パケットの中に含める値ＳＰＩ_２を生成する。ＳＰＩ_１値により、ゲームコンソール１０２が、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間のセキュアな通信チャネルを、ゲートウェイデバイス１５０によって送信されるデータパケットが対応する特定のチャネルとして特定することが可能になる。ゲートウェイデバイス１５０からゲームコンソール１０２へのすべてのセキュアなチャネルのパケット（鍵交換後の）は、そのチャネルを特定するＳＰＩ_１値を含む。同様に、ＳＰＩ_２値により、セキュリティゲートウェイデバイス１５０が、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間のセキュアな通信チャネルを、セキュリティゲームコンソール１０２によって送信されるデータパケットが対応する特定のチャネルとして特定することが可能になる。ゲームコンソール１０２からゲートウェイデバイス１５０へのすべてのセキュアなチャネルのパケット（鍵交換後の）は、そのチャネルを特定するＳＰＩ_２値を含む。それぞれのセキュアな通信チャネルは、同一のゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間であっても、通常、２つの異なるＳＰＩ値（各方向で１つ）を有する。
【００８７】
一実施では、セキュリティゲートウェイデバイス１５０へのすべてのパケット、およびセキュリティゲートウェイデバイス１５０からのすべてのパケットが、常に、パケットの先頭にＳＰＩ値を含み、どのセキュリティチャネルにそのパケットが向けられているかを指定している（セキュリティゲートウェイデバイス１５０またはゲームコンソール１０２がこの値を使用して、パケットを解読する対応する鍵をルックアップすることができるように）。鍵交換イニシエータパケット、および鍵交換応答パケットの場合、この先頭のＳＰＩは、ゼロの値に設定されて、パケットが、対応するＳＰＩ番号がまだ確立されていない鍵交換パケットであることを示す。ただし、鍵交換パケット自体の内部には、鍵交換が完了した後に使用される新しい提案のＳＰＩ値（ゼロではない）が含まれる。したがって、鍵交換パケットは、実際には、２つのＳＰＩ値、つまり外部のＳＰＩ値（ゼロである）、および内部のＳＰＩ値（ゼロではない）を含む。
【００８８】
ゲームコンソール１０２に関する完全に適格なアドレスは、次のものを含む。すなわち、ゲームコンソール１０２に関するイーサネット（登録商標）ＭＡＣ（ｍｅｄｉａ　ａｃｃｅｓｓ　ｃｏｎｔｒｏｌ）アドレス、ゲームコンソール１０２のローカルＩＰアドレス（これは、ゲームコンソール１０２が自ら有すると信じるＩＰアドレスであり、セキュリティゲートウェイ１５０がデータパケットをゲームコンソール１０２から受信する送信元のＩＰアドレスとは異なる可能性がある（例えば、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間に位置する、ルータなどのＮＡＴデバイスに起因して））、セキュリティゲートウェイデバイス１５０がデータパケットをゲームコンソール１０２から受信する送信元のＩＰアドレスおよびポート（これは、ゲームコンソール１０２のローカルＩＰアドレスと同じであることが可能であり、あるいは異なることが可能である（例えば、ＮＡＴデバイスのアドレス））、論理上のセキュリティゲートウェイデバイス番号（セキュリティゲートウェイクラスタの中のセキュリティゲートウェイデバイスを一意的に識別するようにセキュリティゲートウェイデバイスに割り当てられた識別子）、ＳＰＩ値（例えば、ＳＰＩ_１および／またはＳＰＩ_２）、およびゲームコンソールｉｄ（前述したゲームコンソール識別Ｃ）である。完全に適格なアドレスの内容は、ゲームコンソール１０２から受け取られたセキュリティチケットに基づき、またゲームコンソール１０２から受信されたデータパケットに組み込まれた情報に基づいて判定することができる。
【００８９】
動作２０４における認証の一環として、固有データセンタ可視ＩＰアドレス（データセンタ（専用ネットワーク１０８上の）によって内部で使用されるアドレス））が、セキュリティゲートウェイデバイスに利用可能なアドレスのプールから、ゲームコンソールに割り当てられる。固有データセンタ可視ＩＰアドレスは、公共／専用ネットワーク境界を越えてパケットを転送する際、セキュリティゲートウェイデバイス１５０（例えば、ＮＡＴトラバーサルモジュール１６０）によって使用される。パケットが、図１のネットワーク１０６から受信されて、専用ネットワーク内部で転送され、送信元ＩＰアドレスが、上記のデータセンタ可視ＩＰアドレスとしてリストされる。データセンタ内のサーバがこのトラフィックに応答する際、応答は、その応答の目標ＩＰアドレスを含むアドレス範囲が割り当てられたセキュリティゲートウェイデバイスに戻るようにルーティングされる。セキュリティゲートウェイデバイスは、目標ＩＰアドレスが割り当てられたゲームコンソールに関するセキュリティ関係をルックアップすることによってＮＡＴプロセスを逆転し、応答が指定されたゲームコンソールに戻るように転送し、応答の送信元アドレスは、セキュリティゲートウェイのインターネットアドレスであるように変更される。
【００９０】
セキュリティゲートウェイデバイス１５０は、ゲームコンソールがもはや使用不可能になるまで（ゲームコンソール１０２が、データセンタ１１０から自発的にログアウトしたか、または別の形で使用不可能になったかに関わらず）、ゲームコンソール１０２に関するセキュリティ関係情報を維持し、使用不可能になった時点で、セキュリティゲートウェイデバイス１５０は、ゲームコンソール１０２に関するセキュリティ関係情報を削除する（動作２０８）。セキュリティゲートウェイデバイス１５０は、以下により詳細に述べるとおり、ゲームコンソール１０２と通信する際に、この維持されたセキュリティ関係情報を使用する。したがって、セッションセキュリティ鍵および／またはセキュリティ関係鍵を含むセキュリティ関係情報は、各セッションの間にだけ維持される。すなわち、ゲームコンソール１０２がデータセンタにログインするたびに毎回、新しいセキュリティ関係が生成される。
【００９１】
さらに、動作２０４の相互認証の一環として、様々なセッションパラメータが、ゲームコンソール１０２およびセキュリティゲートウェイデバイス１５０によって取り決めることが可能である。このセッションパラメータは、ある程度、コンソール１０２とデバイス１５０の間の通信がどのように行われるべきかを記述する。そのようなパラメータの例には、ハートビートパケットが送信されるべき間隔、使用されるデータ暗号化アルゴリズムおよび／または暗号化強度、データパケットが、完全に暗号化されるべきか、または部分的に暗号化されるべきか、ゲームコンソール１０２に提供されるサービス品質等が含まれる。それぞれのそのようなセッションパラメータが、ゲームコンソール１０２によって送信され、オプションとして、セキュリティゲートウェイデバイス１５０によって取り消されることが可能であり、あるいは、セキュリティゲートウェイデバイス１５０によって設定され、オプションとして、ゲームコンソール１０２によって取り消されることが可能である。
【００９２】
図３のプロセス２００は、ゲームコンソールとセキュリティゲートウェイデバイスの間で相互に認証されたセキュアな通信チャネルを確立する、ケルベロスチケットなどのセキュリティチケットの使用について述べている。あるいは、他のプロセスを使用してセキュアな通信チャネルを確立することができる。セキュアな通信チャネルの目的は、特定のゲームコンソール、およびセキュリティゲートウェイクラスタの特定のゲートウェイデバイスが、チャネル内で通信されているデータを他のデバイスが解釈する、または変更するのを防止する仕方で互いに通信することを可能にすることである。
【００９３】
図２に戻ると、データセンタ１１０内の特定のサービスが、セキュリティゲートウェイデバイス１５０の特定のＩＰポートを使用するゲームコンソール１０２によって目標とされている。セキュリティゲートウェイデバイス１５０は、特定のサービスにそれぞれが関連付けられた（セキュリティゲートウェイデバイス１５０によって）複数のＩＰポートをゲームコンソールに公示する。したがって、例えば、存在−通知サービスデバイスが、ポート１として公示されたとすると、ゲームコンソール１０２上で実行されるゲームタイトルが、ＩＰＡ：１にＴＣＰ／ＩＰパケットを送信できることになり、ここで、ＩＰＡは、セキュリティゲートウェイデバイス１５０のＩＰアドレスを表す。
【００９４】
ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間の通信は、ユーザデータグラムプロトコル（ＵＤＰ）に準拠するデータパケットとして行われる。インターネット上のゲームコンソール１０２に対するオンラインＵＤＰデータパケットに特定のポートが割り振られ、したがって、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間のすべての通信は、この特定のＵＤＰポートを使用する。１つの例示的な実施では、Ｘｂｏｘ（商標）ビデオゲームシステムに関して、この特定のＵＤＰポートは、３０７４である。セキュリティゲートウェイデバイス１５０によって受信されるあらゆるＵＤＰでないパケット、またはポート３０７４に送信されないあらゆるＵＤＰパケットは、セキュリティゲートウェイデバイス１５０によって単に無視される。
【００９５】
ゲームコンソール１０２からセキュリティゲートウェイデバイス１５０に送信されるあらゆるデータは、ゲームコンソール１０２の公衆ネットワークインタフェース１７４によってＵＤＰパケットに組み込まれる。これは、ゲームコンソール１０２から送信されるデータが、何らかの別のプロトコルに従って送信される場合でも行われる。例えば、ゲームコンソール１０２上で実行されるゲームタイトルが、データセンタ１１０内のサービスに対するＴＣＰ／ＩＰ接続を開くことを望むものと想定する。ゲームタイトルは、ソケットを開き、ポート１０２４が割り当てられる（例えば、Ｗｉｎｓｏｃｋにより）。ゲームタイトルは、１つまたは複数のデータパケットを生成し、そのデータパケットをＴＣＰ／ＩＰポート１０２４を介して、ゲームタイトルによって所望されるサービスデバイスに関してセキュリティゲートウェイデバイス１５０によって公示される適切なポートに送信する。公衆ネットワークインタフェース１７４が、そのＴＣＰ／ＩＰパケットを代行受信し、そのパケットを暗号化し、その暗号化されたパケットを、セキュリティゲートウェイデバイス１５０のインターネットアドレスおよびポート３０７４を特定するＵＤＰパケットに組み込み、そのＵＤＰパケットをセキュリティゲートウェイデバイス１５０に送信する。ＵＤＰパケットが受信された後、そのパケットが認証されたものと想定すると、そのＵＤＰパケットは、解読されて、そこからＴＣＰ／ＩＰパケットが抽出される。セキュリティゲートウェイデバイス１５０が、ＴＣＰ／ＩＰパケットの中のセキュリティゲートウェイデバイスによって公示されたポートに基づいて適切なサービスデバイスを特定し、そのＴＣＰ／ＩＰパケットを特定されたサービスデバイスに転送する。
【００９６】
図４ａおよび４ｂは、ゲームコンソールから受信されたデータパケットを管理するための例示的なプロセス２４０を示す流れ図である。図４ａおよび４ｂのプロセスは、セキュリティゲートウェイデバイス（例えば、図２のデバイス１５０）によって実施され、ソフトウェアで、ファームウェアで、ハードウェアで、または以上の組合せで行われることが可能である。図４ａおよび４ｂのプロセスについて、図１および２の構成要素を参照して述べる。
【００９７】
最初、パケットが、ゲームコンソールから受信される（動作２４２）。ゲームコンソール１０２からセキュリティゲートウェイデバイス１５０に送信されるパケットは、ゲームコンソール１０２によって暗号化され、その暗号化されたパケットに関して、セッション鍵に基づいてゲームコンソール１０２によって認証情報が生成される。あるいは、この順序を逆にして、認証情報が最初に生成され、次に、パケットが暗号化されることも可能である。ただし、暗号化されたパケットに関して認証情報を生成することにより、パケットを認証するためにパケットを解読することの負担が、セキュリティゲートウェイデバイス１５０から取り除かれる。１つの例示的な実施では、暗号化アルゴリズムは、トリプルＤＥＳ（データ暗号化標準（Ｄａｔａ　Ｅｎｃｒｙｐｔｉｏｎ　Ｓｔａｎｄａｒｄ））である。あるいは、他の公開された暗号化アルゴリズム、および／または専有の暗号化アルゴリズムを使用することができる。さらに、様々な異なるやり方でパケットに関する認証情報を生成することができる。１つの例示的な実施では、認証情報は、セッション鍵に基づいて暗号化されたパケットに対して暗号ハッシュアルゴリズム（ＨＭＡＣ−ＳＨＡ−１（Ｈａｓｈｅｄ　Ｍｅｓｓａｇｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｃｏｄｅ−Ｓｅｃｕｒｅ　Ｈａｓｈ　Ａｌｇｏｒｉｔｈｍ
１）のような）を実行することによって生成される。
【００９８】
パケットが受信されると、公衆ネットワークインタフェース１５２は、そのパケットをパケット認証モジュール１５６に供与する。パケット認証モジュール１５６は、ゲームコンソール１０２によって使用されたのと同じ暗号ハッシュアルゴリズムを実行し、モジュール１５６によって計算された結果の値が、認証情報として受信されたものと同じであるかどうかをチェックすることにより、そのパケットを認証する。値が同じである場合、パケットは認証され、他方、値が異なる場合、パケットは、認証されない。
【００９９】
パケットは、認証されなかった場合、ドロップされる（動作２４６）。セキュリティゲートウェイデバイス１５０は、ドロップされたパケットを単に無視する。しかし、パケットは、認証された場合、そのパケットを解読するようにパケット解読モジュール１５４に提供される（動作２４８）。この解読は、パケットを暗号化する際にゲームコンソール１０２によって使用される暗号化アルゴリズムに対応する解読アルゴリズムを使用して行われる。
【０１００】
解読されると、パケットルーティングモジュール１７８は、パケットのタイプをチェックする（動作２５０）。１つの例示的な実施では、３つの異なるタイプのパケットが、セキュリティゲートウェイデバイス１５０によって受信されることが可能であり、そのタイプのそれぞれが、異なる仕方で扱われる。この３つのタイプは、次のとおりである。すなわち、ハートビートパケット（ゲームコンソールから受信されるハートビート）、ＮＡＴトラバーサルパケット（別のゲームコンソールを目標とするゲームコンソールから受信されるパケット）、およびサービスを目標とするパケット（データセンタ内のサービスを目標とするゲームコンソールから受信されるパケット）である。パケットのタイプは、ＵＤＰパケットのヘッダの中で、またはＵＤＰパケットの本体（例えば、組み込まれたＴＣＰ／ＩＰパケットとは別個である、またはその一部である（例えば、ヘッダである））の中で特定されることが可能である。
【０１０１】
ハートビートパケットは、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間のセキュアな通信チャネルを開いた状態に保つ目的でゲームコンソール１０２から受信される。ホームネットワーク上のルータなどの中間デバイスが、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間に配置されている状況では、中間デバイスは、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間で通信されているデータパケットのタイプの知識を全く有する必要はなく、通常、その知識を有していない。中間デバイスに分かるのは、そのデータパケットがＵＤＰパケットであることだけである。ただし、そのような中間デバイスは、通常、ある期間（例えば、通常、３０秒間から５分間までの範囲内であるが、他の期間を使用してもよい）中だけ、ルーティング情報（例えば、ゲームコンソール１０２とセキュリティゲートウェイデバイス１５０の間のルーティング情報を含む）を維持するように構成される。中間デバイスが、その期間内に以上の２つのデバイス間で全くパケットを見なかった場合、中間デバイスは、ルーティング情報を削除し、デバイス間で次のパケットが受信されると、新しいルーティング情報を確立する。セキュアな通信チャネルの性質のため、この新しいルーティング情報は、前に使用されたルーティング情報とは異なる可能性があり（また、通常、異なり）、したがって、新しいセッション鍵が、ゲームコンソール１０２およびセキュリティゲートウェイデバイス１５０によって生成される必要がある。
【０１０２】
この問題を解決するため、ゲームコンソール１０２は、様々な間隔で（例えば、ゲームコンソール１０２が、セキュリティゲートウェイデバイス１５０にパケットを最後に送信してから２０秒で、またはセキュリティゲートウェイデバイス１５０にいつ最後のパケットが送信されたかに関わらず、２０秒ごとに）ハートビート信号を送信する。時間の間隔は、様々であることが可能であるが、ルーティング情報をいつ削除するかを決定する際に中間デバイスによって通常、使用される期間より短くなるように構成されなければならない。１つの例示的な実施形態では、このハートビート信号は、セキュリティゲートウェイデバイス１５０に通信される特定のタイプのＵＤＰパケットである。別の例示的な実施では、このハートビート信号は、セキュリティゲートウェイデバイス１５０に通信するのに先立ってＵＤＰパケットに組み込まれた特定のタイプのＴＣＰ／ＩＰパケットである（例えば、ＴＣＰ／ＩＰパケットのヘッダ、または本体に含まれるタイプ情報で、異なるタイプのパケットから区別される）。ハートビート信号は、さらに、パケットによって特定されたゲームコンソールが、まだ応答可能である（まだ存命中であるとも言う）ことをゲームコンソールアベイラビリティモジュール１７６に示すものとしての役割をする。特定のゲームコンソールからハートビート信号が受信されることなく、ある閾値時間（例えば、ハートビート信号がゲームコンソールによって送信されるべき間隔の３倍または４倍）が経過した場合、ゲームコンソールアベイラビリティモジュール１７６は、そのゲームコンソールがもはや応答可能ではないものと考え、そのゲームコンソールがもはや応答可能ではないことを示すメッセージを図１の監視サーバ１１２に通信する。
【０１０３】
ハートビート信号が、少なくともある程度、規則的にゲームコンソール１０２からセキュリティゲートウェイデバイス１５０に通信されることから、追加のステータス情報を、ハートビート信号を含む上記のハートビートパケットに組み込むことが可能である。例えば、あるタイプのゲームステータス情報（例えば、ユーザがゲームを行っているか、またはゲームを休止しているか、ユーザの現在のスコア、どれだけの活力（ｈｅａｌｔｈ）または時間がユーザに残されているか等）が、ゲームタイトルから、ゲームコンソール１０２の公衆ネットワークインタフェース１７４に通信される。インタフェース１７４は、次回に、自らがハートビート信号をセキュリティゲートウェイデバイス１５０に送信するまで待ち、そのステータス情報をハートビートパケットに組み込み、これにより、ステータス情報のために別個のデータパケットを送信する必要性を解消する。
【０１０４】
パケットがハートビートパケットである場合、ゲームコンソールアベイラビリティモジュール１７６は、そのゲームコンソールに関するハートビートタイマをリセットして、そのゲームコンソールからの最後のハートビート信号からゼロ時間が経過したことを示す（動作２５２）。さらに、パケットルーティングモジュール１７８が、何らかの状態情報がハートビートパケットの中に含まれているかどうかをチェックする（動作２５４）。パケットの中に全く動作情報が存在しない場合、そのパケットに関するプロセスは終了する（動作２５６）。しかし、状態情報が存在する場合、パケットルーティングモジュール１７８は、その状態情報をハートビートパケットから抽出し（動作２５８）、その状態情報を存在−通知フロントドアに転送する（動作２６０）。
【０１０５】
セキュリティゲートウェイデバイス１５０には、データセンタ内のネットワーク（例えば、図１のネットワーク１０８）上でデバイス１５０が識別されるようにある範囲のデータセンタＩＰアドレスが割り当てられる。フロントドア１１４、１２０、および１２４のそれぞれ、ならびに各監視サーバ１１２にも、データセンタ内で（ネットワーク１０８上で）フロントドア、および監視サーバが識別されるように特定のデータセンタＩＰアドレスおよびポートが割り当てられる。さらに、フロントドア１１４、１２０、および１２４の１つまたは複数、および監視サーバ１１２には、オプションとして、複数のデータセンタＩＰアドレスおよび／またはポートが割り当てられることが可能である。
【０１０６】
セキュリティゲートウェイデバイス１５０が、専用ネットワーク１０８を介してパケットをサーバまたはフロントドアに送信する必要があるとき、セキュアゾーンインタフェース１７０が、メッセージが、受信されるパケットの送信元であるゲームコンソール１０２に割り当てられた固有データセンタ可視ＩＰアドレス、ならびに特定のポートからのものであることを特定するデータをメッセージヘッダの中に含める。セキュアゾーンインタフェース１７０によって特定されるポートは、パケットをセキュリティゲートウェイデバイス１５０に送信する際にゲームコンソール１０２上で実行されるゲームタイトルによって使用されるのと同じポートである（例えば、ゲームタイトルにＴＣＰ／ＩＰポート１０２４が割り当てられている場合、ポート１０２４が、セキュアゾーンインタフェース１７０によって使用されるポートである）。これは、ゲームコンソール１０２上で実行されるゲームタイトルによって特定されたＴＣＰ／ＩＰポートであり、セキュリティゲートウェイデバイス１５０によってインターネット上で公示されたサービスポートの１つではないことに留意されたい。パケットを送信する際に、ゲームタイトルによってポートが全く使用されなかった場合、セキュアゾーンインタフェース１７０が、使用するポートを選択する（例えば、ランダムに、何らかの所定の基準または順序に従って等）。セキュリティゲートウェイデバイス１５０は、パケットの宛先として、目標とされるサービスデバイスに関するデータセンタＩＰアドレスおよびポートを含む（動作２６０において、これは、存在−通知フロントドア１１４に関するデータセンタＩＰアドレスおよびポートである）。専用ネットワーク１０８を介して送信されるデータパケットは、データセンタのセキュアゾーン内にあるので、暗号化する必要がないことに留意されたい。
【０１０７】
データパケットが、セキュリティゲートウェイデバイス１５０からデータセンタ１１０のサービスデバイスに通信される仕方のため、データパケットが受信されたとき、受信側のデバイスは、パケットを元々、送信したゲームコンソールについてほとんど何も知らない可能性がある（というのは、サービスデバイスは、特定のゲームコンソールからではなく、セキュリティゲートウェイデバイス１５０から来るものとしてパケットを見るからである）。したがって、セキュリティゲートウェイデバイス１５０により、サービスデバイスが、特定のゲームコンソールについての情報に関してデバイス１５０にクエリを行うことが可能になる。サービスデバイスは、セキュリティゲートウェイデバイス１５０と直接に（ネットワーク１０８を介して）、あるいはサービスデバイスに対応するフロントドアを介して通信することができる。例えば、ネットワーク１０８上のセキュリティゲートウェイデバイス１５０に関する特定のポート（例えば、ポート０）が、その情報に関してクエリを行うパケットをデバイス１５０に送信するようにサービスデバイスに確保されることが可能である。サービスデバイスは、要求の中に、自らが情報を要求しているデータセンタＩＰアドレスおよびポートを含める。デバイス１５０は、どのデータセンタＩＰアドレスとポートの組合せが、どのゲームコンソールに割り当てられているかのマッピング（例えば、図２のレコード１７２）を維持し、またデバイス１５０は、対応するゲームコンソールに関して自らが有するすべての情報（例えば、完全に適格なアドレス）をルックアップし、その情報を要求側のサービスデバイスに戻すことによってクエリに応答する。これにより、例えば、サービスデバイスが、特定のユーザおよび／または特定のゲームコンソールの識別を検証することが可能になる（例えば、あるユーザのスコアを削除する要求が、実際にそのユーザから来ていることを確実にするため）。
【０１０８】
図４ａの動作２５０に戻ると、パケットのタイプが、サービスを目標とするパケットである場合、パケットルーティングモジュール１７８が、そのパケットによって目標とされるサービスを特定する（動作２６２）。この特定は、ゲームコンソール１０２により、セキュリティゲートウェイデバイス１５０のどの公示されたポートにパケットが送信されたかをチェックすることによって行われる。次に、パケットルーティングモジュール１７８は、要求側のゲームコンソールが、目標とされるサービスにアクセスすることが許されているかどうかをチェックする（動作２６４）。このチェックは、目標とされるサービスを許可マッピング（レコード１７２の中の）と比較して、目標とされるサービスが、ゲームコンソールに対して許されたサービスとして特定されているかどうかを調べることによって行われる。ゲームコンソールが、目標とされるサービスを使用することが許されていない場合、そのパケットはドロップされ（動作２６６）、単にセキュリティゲートウェイデバイス１５０によって無視される。
【０１０９】
しかし、ゲームコンソールが、そのデバイスを使用することが許されている場合、セキュアゾーンインタフェース１７０が、そのパケットによって目標とされるサービスのデータセンタＩＰアドレスおよびポートを特定し（動作２６８）、そのパケットのデータ内容を含むメッセージを目標とされるサービスに送信する（動作２７０）。
【０１１０】
動作２５０に戻ると、パケットのタイプがＮＡＴトラバーサルパケットである場合、ＮＡＴトラバーサルモジュール１６０が、解読されたパケットの内容に基づき、他のどのゲームコンソールに、そのパケットが転送されるべきかを特定する（図４ｂの動作２７２）。ＮＡＴトラバーサルパケットは、ゲームコンソールが、１つまたは複数のＮＡＴデバイス（例えば、１つまたは複数のホームネットワーク上のルータ）を介して別のゲームコンソールと直接通信を確立しようと試みているときに、そのゲームコンソールによって送信されることが可能である。ＮＡＴトラバーサルパケットにより、セキュリティゲートウェイ１０４が、ゲームコンソール間で直接通信を確立するのを容易にすることが可能になる。
【０１１１】
次に、パケットは、パケット暗号化モジュール１６４に転送され、モジュール１６４は、別のゲームコンソールに向けられたパケットを、別のゲームコンソールに関するセッション鍵を使用することによって暗号化する（動作２７４）。ゲームコンソールがデータパケットを暗号化することに関して前述したのと同様に、パケット暗号化モジュール１６４は、様々な暗号化アルゴリズムの任意のものを使用してデータパケットを暗号化することができる。次に、暗号化されたパケットは、認証情報生成モジュール１６２に提供され、モジュール１６２は、別のゲームコンソールに関するセッション鍵に基づき、そのパケットに関する認証情報を生成する（動作２７６）。ゲームコンソールが認証情報を生成することに関して前述したのと同様に、この認証情報は、様々な異なるやり方で生成することができる。次に、暗号化されたパケット、および認証情報は、公衆ネットワークインタフェース１５２によって別のゲームコンソールに送信される（動作２７８）。
【０１１２】
動作２７２〜２７８に関して、セキュリティゲートウェイクラスタが、複数のセキュリティゲートウェイデバイスを含み、かつクラスタ内の異なるセキュリティゲートウェイデバイスが、前述した２つのゲームコンソール（受信されたパケットの送信元のコンソール、および動作２７２で特定された別のコンソール）を扱うことに責任を負う状況が生じる可能性があることに留意されたい。その状況では、パケットを受信したセキュリティゲートウェイデバイスが、別のゲームコンソールを扱うことに責任を負うセキュリティゲートウェイデバイスを特定し、解読されたパケットをそのセキュリティゲートウェイデバイスに送信する。次に、他方のセキュリティゲートウェイデバイスが、別のゲームコンソールにそのパケットを転送することに責任を負う（動作２７４〜２７８を行って）。
【０１１３】
したがって、図１のデータセンタ１１０内の個々のサービスデバイスは、セキュリティゲートウェイ１０４が、公衆ネットワーク１０６を介してゲームコンソールから受信されたパケットの真正性を検証し、そのパケットに解読サービスを提供するのを頼りにすることができる。個々のサービスデバイスは、セキュリティゲートウェイ１０４と通信することができ、またデバイスが望む場合、ユーザおよび／またはゲームコンソールの何らかの検証を行う、または単にセキュリティゲートウェイ１０４を頼りにすることができる。
【０１１４】
また、専用ネットワーク１０８を介してデータセンタ１１０内の様々なサービスデバイス間で通信を行うことにより、様々なデバイスが、多種多様なデバイスの任意のものであることが可能であり、また互いに通信するためにネットワークプロトコル（例えば、ＴＣＰ／ＩＰ）が使用されていることを理解しているだけでよいことを理解することができる。例えば、異なるサービスデバイスが、異なるオペレーティングシステムを実行していること、大幅に異なるハードウェアアーキテクチャを使用していること（例えば、異なるマイクロプロセッサアーキテクチャに基づいて）等が可能である。
【０１１５】
図５は、ゲームコンソールに送信されるデータパケットを扱うための例示的なプロセス３００を示す流れ図である。図５のプロセスは、セキュリティゲートウェイデバイス（例えば、図２のデバイス１５０）によって実施され、ソフトウェアで、ファームウェアで、ハードウェアで、または以上の組合せで行われることが可能である。図５のプロセスについて、図１および２の構成要素を参照して述べる。
【０１１６】
最初に、データが、データセンタのセキュアゾーン内のサービスから受信される（動作３０２）。サービスは、データをあるゲームコンソールに送信することを、そのゲームコンソールによる要求に応答して行う、別のゲームコンソールによる要求に応答して行う、自発的に行うなど、様々な理由のいずれかで行うことを望むことが可能である。理由に関わらず、データは、セキュリティゲートウェイデバイス１５０（メッセージを送信する際にサービスによって特定された）によって受信され、データが送信される先のゲームコンソールが特定される（動作３０４）。セキュリティゲートウェイデバイス１５０がゲームコンソールを特定する仕方は、どのような識別情報をサービスがセキュリティゲートウェイデバイス１５０に提供するかに基づいて様々である可能性がある。一実施では、ゲームコンソールは、サービスによって提供される情報によって特定されることが可能である（例えば、サービスが、ゲームコンソールの完全に適格なアドレスを送信することが可能である）。別の実施形態では、サービスは、デバイスに関して自らが認知しているデータセンタＩＰアドレスおよびポート（例えば、セキュリティゲートウェイデバイス１５０によって割り当てられたデータセンタ可視ＩＰアドレス、およびネットワーク１０８を介してゲームコンソールからサービスにメッセージを送信する際にセキュリティゲートウェイデバイス１５０によって使用されるポート）だけを伝え、それに応答して、セキュリティゲートウェイデバイスは、対応するゲームコンソールの完全に適格なアドレスをルックアップする（例えば、レコード１７２に基づいて）。
【０１１７】
受信されたデータは、次に、目標とされるゲームコンソールのために暗号化され（動作３０６）、データパケットに組み込まれる（動作３０８）。目標とされるゲームコンソールに関するセキュリティ関係鍵が、レコード１７２から獲得され、データをパケットのために暗号化するためにパケット暗号化モジュール１６４によって使用される。ゲームコンソールがデータパケットを暗号化することに関して前述したのと同様に、パケット暗号化モジュール１６４は、様々な暗号化アルゴリズムの任意のものを使用してデータパケットを暗号化することができる。暗号化されたパケットは、次に、目標とされるゲームコンソールに関するセッション鍵に基づいてパケットに関する認証情報を生成する認証情報生成モジュール１６２に提供される（動作３１０）。ゲームコンソールが認証情報を生成することに関して前述したのと同様に、この認証情報は、様々な異なる仕方で生成することができる。暗号化されたパケット、および認証情報は、次に、公衆ネットワークインタフェース１５２によって別のゲームコンソールに送信される（動作３１２）。
【０１１８】
セキュリティゲートウェイデバイス１５０によって行われる別の機能は、ハートビート信号がゲームコンソール１０２からセキュリティゲートウェイデバイス１５０に送信されるのと同様に、ハートビート信号をゲームコンソール１０２に送信することである。このハートビート信号は、あらゆる中間ルーティングデバイスにおいてルーティング情報を存命状態に保つのに役立ち、さらに、セキュリティゲートウェイデバイス１５０がまだ応答可能であることをゲームコンソール１０２に知らせる役割をする。
【０１１９】
セキュリティゲートウェイデバイス１５０は、様々な間隔で（例えば、セキュリティゲートウェイデバイス１５０が、ゲームコンソール１０２にパケットを最後に送信してから２０秒で、またはゲームコンソール１０２にいつ最後のパケットが送信されたかに関わらず、２０秒ごとに）ハートビート信号を送信する。時間の間隔は、様々である可能性があるが、ルーティング情報をいつ削除するかを決定する際に中間デバイスによって通常、使用される期間より短くなるように構成されなければならない。特定のセキュリティゲートウェイデバイスからハートビート信号が受信されることなく、ある十分な量の時間（例えば、セキュリティゲートウェイデバイスによってハートビート信号が送信される間隔の３倍、または４倍）が経過した場合、ゲームコンソールは、そのセキュリティゲートウェイデバイスがもはや応答可能ではないものと考え、それに応じて対処する（例えば、セキュリティゲートウェイクラスタと新しいセキュアな通信チャネルを確立しようと試みる）。
【０１２０】
図６は、ゲームコンソールに送信されるハートビートパケットを扱うための例示的なプロセス３４０を示す流れ図である。図６のプロセスは、セキュリティゲートウェイデバイス（例えば、図２のデバイス１５０）によって実施され、ソフトウェアで、ファームウェアで、ハードウェアで、または以上の組合せで行われることが可能である。図６のプロセスについて図１および２の構成要素を参照して述べる。
【０１２１】
セキュリティゲートウェイデバイス１５０のハートビートモジュール１６６は、ハートビートパケットをゲームコンソールに送信すべき時点まで待つ（動作３４２）。ハートビートパケットを送信すべき時点になったとき、ハートビートモジュール１６６は、ハートビートパケットの中に含められるべき何らかのデータが存在するかどうかをチェックする（ハートビート信号上にピギーバックされる）（動作３４４）。ゲームコンソールが、セキュリティゲートウェイデバイス１５０に送信されるハートビートパケットの中に他のデータを含めることに関して前述したのと同様に、セキュリティゲートウェイデバイス１５０も、ゲームコンソール１０２に送信されるハートビートパケットの中に他のデータを含めることが可能である。１つの例示的な実施形態では、あるサービス（例えば、存在−通知サービス）からのデータだけが、ハートビートパケットの中に含められる。別の例示的な実施形態では、サービスは、データをセキュリティゲートウェイデバイス１５０に送信する際、データをハートビート信号の中に含めることが可能であるかどうかを示す。
【０１２２】
一実施では、ティクルモジュール１６８が、コンソールに送信される次のハートビート信号の中に含められるべきデータを有する特定のゲームコンソールを特定することに責任を負う。ハートビートモジュール１６６は、ティクルモジュール１６８と通信して、自らが送信する用意をしているハートビート信号上に重畳されるべき何らかのデータが存在するかどうかを判定する。ハートビートパケットの中に含められるべきデータが存在する場合、そのデータが内部に組み込まれてデータパケットが生成され（動作３４６）、存在しない場合、全くそのようなデータなしにデータパケットが生成される（動作３４８）。１つの例示的な実施では、動作３４６および３４８で生成されたデータパケットは、ハートビートパケットとして識別され（例えば、パケットタイプ情報を使用して）、受信側のゲームコンソールが、そのパケットをそれに応じて処理することが可能になる（例えば、何らかの追加のデータが内部に組み込まれていないかチェックする）。
【０１２３】
動作３４６または３４８でパケットが生成されると、そのパケットの中のデータは、目標とされるゲームコンソールのためにパケット暗号化モジュール１６４によって暗号化される（動作３５０）。この暗号化プロセスは、前述した図５の動作３０８と同様である。次に、暗号化されたパケットに関する認証情報が、図５の動作３１０と同様に生成され（動作３５２）、暗号化されたパケット、およびその認証情報が、図５の動作３１２と同様にゲームコンソールに送信される（動作３５４）。次に、プロセスは、動作３４２に戻り、別のハートビート信号を送信すべき時点まで待つ。
【０１２４】
プロセス３４０の複数のインスタンスが同時に生じる可能性があることに留意されたい。例えば、動作３４６または３４８であるゲームコンソール向けにハートビートパケットが生成されており、一方、同時に、別のゲームコンソール向けのパケットが、動作３５８で暗号化されており、同時に、さらに別のゲームコンソール向けのパケットが、動作３５４で送信されていることが可能である。
【０１２５】
図２に戻ると、セキュリティゲートウェイデバイス１５０の様々なモジュールおよびインタフェースは、同一のハードウェア構成要素、または異なるハードウェア構成要素に実装すること、あるいは同一のハードウェア構成要素、または異なるハードウェア構成要素を利用することが可能であることに留意されたい。例えば、公衆ネットワークインタフェース１５２は、通常、デバイス１５０を公衆ネットワークに結合するネットワークインタフェースカード（ＮＩＣ）、つまりハードウェアを使用して実装され、一方、セキュアゾーンインタフェース１７０は、通常、デバイス１５０を専用ネットワークに結合する別のＮＩＣ、つまりハードウェアを使用して実装される。さらに、一実施では、パケット解読モジュール１５４およびパケット暗号化モジュール１６４、ならびにオプションとして、パケット認証モジュール１５６および認証情報生成モジュール１６２が、特別の暗号プロセッサまたは暗号コプロセッサを使用して実装される。そのような暗号プロセッサまたは暗号コプロセッサは、暗号演算（暗号化、解読、およびハッシングなどの）を行い、デバイス１５０内の他のプロセッサが、計算リソースを多く消費する（ｃｏｍｐｕｔａｔｉｏｎａｌｌｙ−ｅｘｐｅｎｓｉｖｅ）暗号演算の負担を他のプロセッサ（例えば、汎用プロセッサ）から除くように設計されている。
【０１２６】
図７は、本明細書で説明する技術を実施するのに使用することができる一般的なコンピュータ環境４００を示している。コンピュータ環境４００は、計算環境の一例に過ぎず、コンピュータアーキテクチャおよびネットワークアーキテクチャの使用または機能の範囲に関する何らかの限定を示唆するものではない。また、コンピュータ環境４００が、例示的なコンピュータ環境４００に図示した構成要素のいずれか１つ、または組合せに関連する何らかの依存性または要件を有するものと解釈すべきでもない。
【０１２７】
コンピュータ環境４００は、コンピュータ４０２の形態で汎用コンピューティングデバイスを含む。コンピュータ４０２は、例えば、図２のセキュリティゲートウェイデバイス１５０、図１のサーバ１１２、１１６、１１８、１２２、および／または１２６、または図１のフロントドア１１４、１２０、または１２４であることが可能である。コンピュータ４０２の構成要素には、１つまたは複数のプロセッサまたはプロセッサ４０４（オプションとして、暗号プロセッサまたは暗号コプロセッサを含む）、システムメモリ４０６、ならびにプロセッサ４０４からシステムメモリ４０６までを含む様々なシステム構成要素を結合するシステムバス４０８が含まれることが可能であるが、以上には限定されない。
【０１２８】
システムバス４０８は、様々なバスアーキテクチャの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート（ａｃｃｅｌｅｒａｔｅｄ　ｇｒａｐｈｉｃｓ　ｐｏｒｔ）、およびプロセッサバスまたはローカルバスを含むいくつかのタイプのバス構造の任意のものの１つまたは複数を表す。例として、そのようなアーキテクチャには、インダストリスタンダードアーキテクチャ（Ｉｎｄｕｓｔｒｙ　Ｓｔａｎｄａｒｄ　Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Ｍｉｃｒｏ　Ｃｈａｎｎｅｌ　Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＭＣＡ）バス、エンハンストＩＳＡ（Ｅｎｈａｎｃｅｄ　ＩＳＡ）（ＥＩＳＡ）バス、ビデオエレクトロニクススタンダーズアソシエーション（Ｖｉｄｅｏ　Ｅｌｅｃｔｒｏｎｉｃｓ　Ｓｔａｎｄａｒｄｓ　Ａｓｓｏｃｉａｔｉｏｎ）（ＶＥＳＡ）ローカルバス、およびメザニン（Ｍｅｚｚａｎｉｎｅ）バスとしても知られるペリフェラルコンポーネントインターコネクツ（Ｐｅｒｉｐｈｅｒａｌ　Ｃｏｍｐｏｎｅｎｔ　Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）（ＰＣＩ）バスが含まれることが可能である。
【０１２９】
コンピュータ４０２は、通常、様々なコンピュータ可読媒体を含む。この媒体は、コンピュータ４０２によってアクセス可能な任意の利用可能な媒体であることが可能であり、揮発性の媒体と不揮発性の媒体、取外し可能な媒体と取外し不可能な媒体がともに含まれる。
【０１３０】
システムメモリ４０６は、ランダムアクセスメモリ（ＲＡＭ）４１０などの揮発性メモリ、および／または読取り専用メモリ（ＲＯＭ）４１２などの不揮発性メモリの形態でコンピュータ可読媒体を含む。始動中など、コンピュータ４０２内部の要素間で情報を転送するのを助ける基本ルーチンを含む基本入力／出力システム（ＢＩＯＳ）４１４が、ＲＯＭ４１２の中に記憶される。ＲＡＭ４１０は、通常、プロセッサ４０４が即時にアクセスすることができ、かつ／または現在、演算を行っているデータ、および／またはプログラムモジュールを含む。
【０１３１】
また、コンピュータ４０２は、その他の取外し可能な／取外し不可能な、揮発性／不揮発性のコンピュータ記憶媒体も含む。例として、図７が、取外し不可能な不揮発性の磁気媒体（図示せず）に対して読取りおよび書込みを行うためのハードディスクドライブ４１６、取外し可能な不揮発性の磁気ディスク４２０（例えば、「フロッピー（登録商標）ディスク」）に対して読取りおよび書込みを行うための磁気ディスクドライブ４１８、およびＣＤ（ｃｏｍｐａｃｔ　ｄｉｓｃ　［ｄｉｓｋ］）−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ　ｖｅｒｓａｔｉｌｅ　ｄｉｓｋ）−ＲＯＭ、またはその他の光媒体などの取外し可能な不揮発性の光ディスク４２４に対して読取りおよび／または書込みを行うための光ディスクドライブ４２２を示している。ハードディスクドライブ４１６、磁気ディスクドライブ４１８、および光ディスクドライブ４２２はそれぞれ、１つまたは複数のデータ媒体インタフェース４２５でシステムバス４０８に接続される。あるいは、ハードディスクドライブ４１６、磁気ディスクドライブ４１８、および光ディスクドライブ４２２は、１つまたは複数のインタフェース（図示せず）でシステムバス４０８に接続することも可能である。
【０１３２】
以上のディスクドライブおよび関連するコンピュータ可読媒体により、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性ストーレッジがコンピュータ４０２に提供される。この例は、ハードディスク４１６、取外し可能な磁気ディスク４２０、および取外し可能な光ディスク４２４を示しているが、磁気カセットまたはその他の磁気記憶デバイス、フラッシュメモリカード、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）またはその他の光ストーレッジ、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ　ｅｒａｓａｂｌｅ　ｐｒｏｇｒａｍｍａｂｌｅ　ｒｅａｄ−ｏｎｌｙ　ｍｅｍｏｒｙ）などの、コンピュータによってアクセス可能なデータを記憶することができる他のタイプのコンピュータ可読媒体を利用して例示的な計算システムおよび計算環境を実施することも可能であることを理解されたい。
【０１３３】
例として、オペレーティングシステム４２６ａ、４２６ｂ、１つまたは複数のアプリケーションプログラム４２８ａ、４２８ｂ、その他のプログラムモジュール４３０ａ、４３０ｂ、およびプログラムデータ４３２ａ、４３２ｂを含む任意の数のプログラムモジュールをハードディスク４１６、磁気ディスク４２０、光ディスク４２４、ＲＯＭ４１２、および／またはＲＡＭ４１０に記憶することができる。そのようなオペレーティングシステム４２６ａ、４２６ｂ、１つまたは複数のアプリケーションプログラム４２８ａ、４２８ｂ、その他のプログラムモジュール４３０ａ、４３０ｂ、およびプログラムデータ４３２ａ、４３２ｂのそれぞれが（または何らかの組合せが）、分散されたファイルシステムをサポートする常駐の構成要素のすべて、または一部を実施することができる。
【０１３４】
ユーザは、キーボード４３４やポインティングデバイス４３６（例えば、「マウス」）などの入力デバイスを介してコマンドおよび情報をコンピュータ４０２に入力することができる。その他の入力デバイス４３８（特に示さず）には、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、シリアルポート、スキャナ、および／または以上に類するものが含まれることが可能である。以上の入力デバイス、およびその他の入力デバイスは、システムバス４０８に結合された入力／出力インタフェース４４０を介してプロセッサ４０４に接続されているが、パラレルポート、ゲームポート、またはＵＳＢ（ｕｎｉｖｅｒｓａｌ　ｓｅｒｉａｌ　ｂｕｓ）などのその他のインタフェースおよびバス構造で接続してもよい。
【０１３５】
また、モニタ４４２、またはその他のタイプの表示デバイスも、ビデオアダプタ４４４などのインタフェースを介してシステムバス４０８に接続することができる。モニタ４４２に加え、その他の出力周辺デバイスには、入力／出力インタフェース４４０を介してコンピュータ４０２に接続することができるスピーカ（図示せず）やプリンタ４４６などの構成要素が含まれることが可能である。
【０１３６】
コンピュータ４０２は、リモートコンピューティングデバイスコンピューティングデバイス４４８などの１つまたは複数の遠隔コンピュータに対する論理接続を使用するネットワーク化された環境において動作することが可能である。例として、リモートコンピューティングデバイス４４８は、パーソナルコンピュータ、可搬コンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイスまたはその他の一般的なネットワークノード、ゲームコンソール等であることが可能である。リモートコンピューティングデバイス４４８は、コンピュータ４０２に関連して本明細書で説明した要素および特徴の多く、またはすべてを含むことが可能な可搬コンピュータとして示されている。
【０１３７】
コンピュータ４０２と遠隔コンピュータ４４８の間の論理接続は、ローカルエリアネットワーク（ＬＡＮ）４５０、および一般的なワイドエリアネットワーク（ＷＡＮ）４５２として描かれている。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータ網、イントラネット、およびインターネットにおいて一般的である。
【０１３８】
ＬＡＮネットワーキング環境において実施されるとき、コンピュータ４０２は、ネットワークインタフェースまたはネットワークアダプタ４５４を介してローカルネットワーク４５０に接続される。ＷＡＮネットワーキング環境において実施されるとき、コンピュータ４０２は、通常、ワイドネットワーク４５２を介して通信を確立するためのモデム４５６、またはその他の手段を含む。コンピュータ４０２の内部にあることも、外部にあることも可能なモデム４５６は、入力／出力インタフェース４４０、またはその他の適切な機構を介してシステムバス４０８に接続することができる。図示したネットワーク接続は、例示的なものであり、コンピュータ４０２と４４８の間で通信リンクを確立する他の手段も使用できることを理解されたい。
【０１３９】
計算環境４００で例示するようなネットワーク化された環境では、コンピュータ４０２に関連して描いたプログラムモジュール、またはプログラムモジュールの部分が、リモートメモリ記憶デバイスの中に記憶されることが可能である。例として、リモートアプリケーションプログラム４５８が、遠隔コンピュータ４４８のメモリデバイス上に常駐する。例示のため、オペレーティングシステムなどのアプリケーションプログラムおよびその他の実行可能プログラム構成要素は、本明細書では別々のブロックとして示されているが、そのようなプログラムおよび構成要素は、様々な時点で、コンピューティングデバイス４０２の異なる記憶構成要素の中に存在し、コンピュータのデータプロセッサによって実行されることが認識されている。
【０１４０】
本明細書では、様々なモジュールおよび技術は、１つまたは複数のコンピュータまたは他のデバイスによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な状況で説明することができる。一般に、プログラムモジュールには、特定のタスクを行う、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造等が含まれる。通常、プログラムモジュールの機能は、様々な実施形態において、所望に応じて結合する、または分散させることが可能である。
【０１４１】
以上のモジュールおよび技術の実施を何らかの形態のコンピュータ可読媒体に記憶する、またはコンピュータ可読媒体を介して伝送することが可能である。コンピュータ可読媒体は、コンピュータがアクセスすることができる任意の利用可能な媒体であることが可能である。例として、限定としてではなく、コンピュータ可読媒体は、「コンピュータ記憶媒体」および「通信媒体」を含むことが可能である。
【０１４２】
「コンピュータ記憶媒体」には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶するための任意の方法または技術で実装された揮発性の媒体および不揮発性の媒体、取外し可能な媒体および取外し不可能な媒体が含まれる。コンピュータ記憶媒体には、限定するものとしてではなく、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）またはその他の光ストーレッジ、磁気カセット、磁気テープ、磁気ディスクストーレッジまたはその他の磁気記憶デバイス、あるいは所望の情報を記憶するのに使用することができ、コンピュータがアクセスすることができる任意の他の媒体が含まれる。
【０１４３】
「通信媒体」は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを、搬送波またはその他のトランスポート機構などの変調されたデータ信号として実現する。また、通信媒体には、あらゆる情報デリバリ媒体が含まれる。「変調されたデータ信号」という用語は、情報を信号の中に符号化するような仕方で特定の１つまたは複数が設定されている、または変更されている信号を意味する。例として、限定としてではなく、通信媒体には、有線ネットワークまたは直接配線ネットワークなどの有線媒体、および音響媒体、ＲＦ（ｒａｄｉｏ　ｆｒｅｑｕｅｎｃｉｅｓ）媒体、赤外線媒体、およびその他の無線媒体などの無線媒体が含まれる。以上の媒体の任意のものの組合せも、コンピュータ可読媒体の範囲に含まれる。
【０１４４】
図８は、ゲームコンソールの機能構成要素をより詳細に示している。ゲームコンソール１０２は、中央処理装置（ＣＰＵ）５００、ならびにフラッシュＲＯＭ（読取り専用メモリ）５０４、ＲＡＭ（ランダムアクセスメモリ）５０６、ハードディスクドライブ５０８、およびポータブルメディアドライブ５０９を含む様々なタイプのメモリに対するプロセッサアクセスを円滑にするメモリコントローラ５０２を有する。ＣＰＵ５００は、データを一時的に記憶し、したがって、メモリアクセスサイクルの回数を減らすレベル１キャッシュ５１０およびレベル２キャッシュ５１２を備え、これにより、処理速度およびスループットが向上する。
【０１４５】
ＣＰＵ５００、メモリコントローラ５０２、および様々なメモリデバイスは、様々なバスアーキテクチャの任意のものを使用するシリアルバスおよびパラレルバス、メモリバス、周辺バス、およびプロセッサバスまたはローカルバスを含む１つまたは複数のバスを介して互いに接続される。例として、そのようなアーキテクチャには、インダストリスタンダードアーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、エンハンストＩＳＡ（ＥＩＳＡ）バス、ビデオエレクトロニクススタンダーズアソシエーション（ＶＥＳＡ）ローカルバス、およびメザニンバスとしても知られるペリフェラルコンポーネントインターコネクツ（ＰＣＩ）バスが含まれることが可能である。
【０１４６】
１つの適切な実施として、ＣＰＵ５００、メモリコントローラ５０２、ＲＯＭ５０４、およびＲＡＭ５０６が、共通モジュール５１４上に統合される。この実施では、ＲＯＭ５０４は、ＰＣＩ（ペリフェラルコンポーネントインターコネクツ）バスおよびＲＯＭバス（どちらも図示せず）を介してメモリコントローラ５０２に接続されたフラッシュＲＯＭとして構成される。ＲＡＭ５０６は、別個のバス（図示せず）を介してメモリコントローラ５０２によって独立に制御される複数のＤＤＲ　ＳＤＲＡＭ（Ｄｏｕｂｌｅ　Ｄａｔａ　Ｒａｔｅ　Ｓｙｎｃｈｒｏｎｏｕｓ　Ｄｙｎａｍｉｃ　ＲＡＭ）として構成される。ハードディスクドライブ５０８およびポータブルメディアドライブ５０９は、ＰＣＩバスおよびＡＴＡ（ＡＴアタッチメント）バス５１６を介してメモリコントローラに接続される。
【０１４７】
３Ｄグラフィックスプロセッサ５２０およびビデオエンコーダ５２２が、高速かつ高解像度のグラフィックス処理のためのビデオ処理パイプラインを形成する。データは、デジタルビデオバス（図示せず）を介してグラフィックスプロセッサ５２０からビデオエンコーダ５２２に搬送される。オーディオプロセッサ５２４およびオーディオコーデック（エンコーダ／復号器）５２６が、高忠実度、かつステレオの処理を備えた対応するオーディオ処理パイプラインを形成する。オーディオデータは、通信リンク（図示せず）を介してオーディオプロセッサ５２４とオーディオコーデック５２６の間で搬送される。ビデオ処理パイプラインおよびオーディオ処理パイプラインは、テレビジョンまたはその他のディスプレイに伝送するためにデータをＡ／Ｖ（オーディオ／ビデオ）ポート５２８に出力する。図示した実施形態では、ビデオ処理構成要素およびオーディオ処理構成要素５２０〜５２８は、モジュール５１４上に実装される。
【０１４８】
やはりモジュール５１４上に実装されるのが、ＵＳＢホストコントローラ５３０およびネットワークインタフェース５３２である。ＵＳＢホストコントローラ５３０は、バス（例えば、ＰＣＩバス）を介してＣＰＵ５００およびメモリコントローラ５０２に結合され、周辺コントローラ５３６−１〜５３６−４に対するホストの役割をする。ネットワークインタフェース２３２は、ネットワーク（例えば、インターネット、ホームネットワーク等）に対するアクセスを提供し、イーサネット（登録商標）カード、モデム、ブルートゥース（登録商標）モジュール、ケーブルモデム等を含む多種多様な有線または無線のインタフェース構成要素の任意のものであることが可能である。
【０１４９】
ゲームコンソール１０２は、２つのゲームコントローラ５３６−１〜５３６−４）をそれぞれがサポートする２つのデュアルコントローラサポートサブアセンブリ５４０−１および５４０−２を有する。フロントパネルＩ／Ｏサブアセンブリ５４２が、電源ボタン５３１および媒体ドライブ取出しボタン５３３の機能、ならびにゲームコンソールの外面上に露出したあらゆるＬＥＤ（発光ダイオード）またはその他のインディケータをサポートする。サブアセンブリ５４０−１、５４０−２、および５４２は、１つまたは複数のケーブルアセンブリ５４４を介してモジュール５１４に結合される。
【０１５０】
８つのメモリユニット５３４−１〜５３４−８が、４つのコントローラ５３６−１〜５３６−４に、すなわち、各コントローラに対して２つのメモリユニットが、接続可能であるものとして示されている。各メモリユニット５３４は、ゲーム、ゲームパラメータ、およびその他のデータを記憶することができるさらなるストーレッジを提供する。コントローラに挿入されたとき、メモリユニット５３４−１〜５３４−８は、そのメモリコントローラ５０２によってアクセスされることが可能である。
【０１５１】
システム電源モジュール５５０が、ゲームコンソール１０２の構成要素に電力を供給する。ファン５５２が、ゲームコンソール１０２内部の回路を冷却する。
【０１５２】
コンソールユーザインタフェース（ＵＩ）アプリケーション５６０が、ハードディスクドライブ５０８に記憶される。ゲームコンソールに電源が投入されたとき、コンソールアプリケーション５６０の様々な部分が、ＲＡＭ５０６および／またはキャッシュ５１０、５１２にロードされ、ＣＰＵ５００上で実行される。コンソールアプリケーション５６０は、ゲームコンソール上で利用可能な異なる媒体タイプにナビゲートする際に、整合性を有するユーザ体験を提供するグラフィカルユーザインタフェースを提示する。
【０１５３】
ゲームコンソール１０２は、暗号化、解読、認証、デジタル署名、ハッシングなどの一般的な暗号機能を行う暗号エンジンを実装する。暗号エンジンは、ＣＰＵ５００の一部として、またはＣＰＵ上で実行されるハードディスクドライブ５０８に記憶されたソフトウェアとして実装され、したがって、ＣＰＵが、暗号化機能を行うように構成されることが可能である。あるいは、暗号機能を行うように設計された暗号プロセッサまたは暗号コプロセッサが、ゲームコンソール１０２内に含まれることが可能である。
【０１５４】
ゲームコンソール１０２は、単にシステムをテレビジョンまたはその他のディスプレイに接続することにより、独立型システムとして動作させることが可能である。この独立型モードでは、ゲームコンソール１０２により、１名または複数名のプレーヤが、ゲームを行うこと、映画を観ること、または音楽を聴くことが可能になる。ただし、ネットワークインタフェース５３２を介して利用可能になるブロードバンド接続が統合されることで、ゲームコンソール１０２を、さらに、前述したとおり、オンラインゲームの参加者として動作させることが可能である。
【０１５５】
本明細書で解説したゲームコンソールは、専用のゲームコンソール（コンピュータゲームを実行する汎用ＰＣ（ｐｅｒｓｏｎａｌ　ｃｏｍｐｕｔｅｒ）ではなく）として説明したが、ゲームコンソールは、さらなる機能を組み込むことも可能である。例えば、ゲームコンソールは、デジタルＶＣＲ（ｖｉｄｅｏ　ｃａｒｔｒｉｄｇｅ　［ｃａｓｓｅｔｔｅ］　ｒｅｃｏｒｄｅｒ）として動作することができるようにビデオ録画機能を含むことが可能であり、テレビジョン信号（ブロードキャスト信号であるか、ケーブル信号であるか、サテライト信号であるかに関わらず）に同調して復号化することができるようにチャネル同調機能を含むこと等が可能である。
【０１５６】
また、以下に、米国特許出願１０／１７０、００２号の内容を説明する。
【０１５７】
以下の解説は、ネットワーク化されたデバイスに関する相互認証を使用したセキュアな鍵交換メカニズムを対象とするものである。この解説では、読者が暗号化、解読、認証、ハッシング、およびデジタル署名などの基本的な暗号法に精通しているものと想定される。
【０１５８】
図９は、相互認証を使用したセキュアな鍵交換が使用可能な例示的環境９１００を示す構成図である。クライアント装置９１０２は、鍵配布センタ９１０４およびサーバ装置９１０６に結合される。デバイス９１０２と鍵配布センタ９１０４との結合は、デバイス９１０２とセンタ９１０４との間の通信を可能にする任意の様々な結合が可能である。同様に、デバイス９１０２と９１０６の間の結合も、デバイス９１０２とデバイス９１０６との間の通信を可能にする任意の様々な結合が可能である。一実施では、結合はインターネットを含み、任意選択として１つまたは複数の他のネットワーク（たとえばローカルエリアネットワーク（ＬＡＮ）および／またはワイドエリアネットワーク（ＷＡＮ））を含むこともできる。
【０１５９】
図９には単一のクライアント装置９１０２、単一のセンタ９１０４、および単一のサーバ装置９１０６が示されているが、環境９１００はこうしたデバイスおよびセンタを複数含むことができる。たとえば、複数のクライアント装置９１０２が、１つまたは複数の鍵配布センタ９１０４および１つまたは複数のサーバ装置と通信することができる。
【０１６０】
クライアント装置９１０２とサーバ装置９１０６との間の通信、ならびにクライアント装置９１０２と鍵配布センタ９１０４との間の通信は、任意の様々な異なるパケット形式が可能である。一実施例では、通信はユーザデータグラムプロトコル（ＵＤＰ／Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）形式である。
【０１６１】
鍵配布センタ９１０４は鍵およびセキュリティチケットをクライアント装置９１０２に配布し、これをサーバ装置９１０６とのセキュアな鍵交換で使用することができる。サーバ装置９１０６はクライアント装置９１０２にサービスを提供するか、またはクライアント装置９１０２にサービスを提供する他のデバイス（図９には図示せず）へのゲートウェイとして動作する。
【０１６２】
クライアント装置９１０２は、任意の多種多様なデバイスであってよい。本明細書の解説の中には、クライアント装置９１０２をゲームコンソールと呼ぶものもある。こうしたゲームコンソールは、専用ゲームコンソールであるかまたは追加の機能を含むものであってよい。たとえばゲームコンソールは、デジタルＶＣＲとして動作できるようにデジタルビデオレコーディング機能を含むこと、テレビジョン信号（同報通信信号、ケーブル信号、衛星放送信号などのいずれか）を同調およびデコードできるようにチャネル同調機能を含むこと、などが可能である。クライアント装置９１０２は、デスクトップＰＣ、ポータブルコンピュータ、セルラー式電話、インターネット機器、サーバコンピュータなどの、他のタイプのコンピュータデバイスであってもよい。
【０１６３】
環境９１００では、クライアント装置９１０２とサーバ装置９１０６との間の相互認証を使用したセキュアな鍵交換が望ましい。これにより、デバイス９１０２および９１０６が互いに認証し合うことが可能になり、さらに１つまたは複数の暗号鍵を確立し、セキュアでないネットワーク（たとえばインターネット）を介して相互にセキュアに通信するためにデバイス９１０２および９１０６の基礎として使用することが可能になる。
【０１６４】
相互認証を使用したセキュアな鍵交換を実行するために、鍵配布センタ９１０４からセキュリティチケットが取得される。一実施例では、セキュリティチケットは、単一チケットで、特定のクライアント装置９１０２の識別およびクライアント装置９１０２の１つまたは複数のユーザのユーザ識別を認証する、ケルベロスのような認証プロトコルを使用して、クライアント装置９１０２によって取得されるケルベロスチケットである。クライアント装置９１０２は、ケルベロスチケットを以下のように取得する。
【０１６５】
解説上、クライアント装置９１０２はゲームコンソールであると想定し、さらに４人のゲームコンソールユーザがいると想定する。それぞれのユーザには識別Ｕ_１、Ｕ_２、Ｕ_３、およびＵ_４が与えられ、ユーザ鍵Ｋ_１、Ｋ_２、Ｋ_３、およびＫ_４が割り当てられる。ゲームコンソールには、それ自体の識別Ｃおよびゲームコンソール鍵Ｋ_Ｃも割り当てられる。さらに、ゲームディスクなどのゲームコンソール上でプレイされるゲームタイトルには、別の識別Ｇが割り当てられる。同様の方法で、サーバ装置９１０６にはそれ自体の識別Ａおよび鍵Ｋ_Ａが割り当てられる。本明細書に記載された認証は、ある程度、鍵Ｋ_１、Ｋ_２、Ｋ_３、およびＫ_４、Ｋ_Ｃ、ならびに鍵Ｋ_Ａに依存するものであることに留意されたい。したがって、これらの鍵を選択および格納する際には、それらの鍵を割り当てられたエンティティのみがそれらを使用できることに注意を払わなければならない。
【０１６６】
ゲームコンソールは、ユーザ識別Ｕ_１、Ｕ_２、Ｕ_３、およびＵ_４ならびにユーザ鍵Ｋ_１、Ｋ_２、Ｋ_３、およびＫ_４に基づいて、検証されたユーザ識別を生成する。より具体的に言えば、検証されたユーザ識別には、ユーザ鍵から導出されたユーザ識別および値が含まれる。検証されたユーザ識別は要求と共に鍵配布センタ９１０４にサブミットされ、ゲームコンソールがユーザ鍵の知識を持っていることを、鍵配布センタに実証するために使用され、暗黙的にユーザを認証する。
【０１６７】
様々なメッセージおよび鍵が算出される方法を簡単に説明するために、次の表記法を導入する。
【０１６８】
Ｈ＝Ｈ_Ｋｘ（Ｍ）：Ｈとは、鍵Ｋ_ｘを使用するメッセージＭの鍵付き一方向ハッシュ（ＭＡＣ）である。どんなＭＡＣアルゴリズムも使用できる。こうしたＭＡＣアルゴリズムの一例が、ＩＥＴＦ　ＲＦＣ２９１０４に従ったＨＭＡＣアルゴリズムである。
【０１６９】
ＥｎｃｒｙｐｔｅｄＭ＝Ｅ_Ｋｘ（Ｍ）：ＥｎｃｒｙｐｔｅｄＭとは、鍵Ｋ_ｘを使用するメッセージＭの暗号化形式である。どんな暗号化アルゴリズムも使用できる。こうした暗号化アルゴリズムの例に、ＤＥＳ、トリプルＤＥＳ、およびＲＣ４−ＨＭＡＣが含まれる。
【０１７０】
鍵導出値を生成する方法の１つが、ゲームコンソールの鍵を使用して、ユーザ鍵の暗号ハッシュを算出することである。鍵Ｋ_１を持つユーザＵ_１の場合、ハッシュＨ_１は次のように算出される。
Ｈ_１＝Ｈ_Ｋｃ（Ｋ_１）
【０１７１】
ハッシュＨ_１が鍵導出値を形成する。他の方法は、ユーザ鍵Ｋ_１を使用して次のように現在時刻を暗号化することである。
Ｈ_１＝Ｅ_Ｋ１（Ｔ）
【０１７２】
結果として生じる値Ｈ_１が、鍵導出値を再度形成する。検証されたユーザ識別は、次のように、ユーザ識別Ｕ_１および対応する鍵導出値Ｈ_１の組合せである。
検証されたユーザ識別＝（Ｕ_１，Ｈ_１）
【０１７３】
ゲームコンソールは、ゲームコンソール識別Ｃ、ゲームタイトル識別Ｇ、サーバ装置９１０６のサーバ識別Ａ、ならびに複数の検証されたユーザ識別（Ｕ_１，Ｈ_１）、（Ｕ_２，Ｈ_２）、（Ｕ_３，Ｈ_３）、および（Ｕ_４，Ｈ_４）を含む要求を構築する。要求は、次のような識別文字列を有する。
要求＝［Ｃ，Ｇ，Ａ，（Ｕ_１，Ｈ_１），（Ｕ_２，Ｈ_２），（Ｕ_３，Ｈ_３），（Ｕ_４，Ｈ_４）］
【０１７４】
さらに要求は、あるバージョンの認証プロトコル、およびゲームコンソールによって生成されるランダムナンス（ｎｏｎｃｅ）を含みリプレイ攻撃を阻止することができる。要求は、識別文字列全体の受取りを検証するために使用される、チェックサム値も含むことができる。ゲームコンソールは、鍵配布センタ９１０４への結合を介して要求をサブミットする。
【０１７５】
鍵配布センタ９１０４は、要求ならびに要求に含まれる識別を評価する。鍵配布センタ９１０４は、サーバ装置９１０６用に使用されるランダムセッション鍵を生成する。この例では、鍵配布センタは、ゲームコンソール９１０２がサーバ装置９１０６と通信しながら使用するためのランダムセッション鍵Ｋ_ＣＡを生成する。本明細書ではこのランダムセッション鍵Ｋ_ＣＡをケルベロスセッション鍵とも呼ぶ。
【０１７６】
鍵配布センタがチケットを生成し、その後そのチケットがゲームコンソールによってサーバ装置９１０６に提示されることになる。サーバ装置９１０６向けに発行されるチケットは１つであるが、このチケットは複数のユーザに対して有効である。チケットには、要求で提出された識別文字列が含まれる。さらに、チケットが生成された時間Ｔ_Ｇ、チケットが満了するまでの時間長さを識別する時間Ｔ_Ｌ、およびサーバ装置９１０６向けにランダムに生成されたケルベロスセッション鍵Ｋ_ＣＡも含まれる。チケットは、任意選択で、ゲームコンソールのユーザがアクセスを許可されているサーバ装置９１０６を介して使用可能なサービスおよび／またはサービスデバイスを識別する、サービスマップＳ_ｍを含むこともできる。鍵配布センタは、どのユーザがどのサービスへのアクセスを許可されているか（たとえばどのユーザが、１つまたは複数の割増料金（ｐｒｅｍｉｕｍ）サービスにアクセスするための割増料金を払ったか）についての記録を維持するか、あるいは記録を維持する他のデバイスまたはセンタにアクセスする。チケットの内容は、サーバ装置の鍵Ｋ_Ａを以下のように使用する対称鍵暗号（たとえばトリプルＤＥＳ）を介して暗号化される。
【０１７７】
【数５】

【０１７８】
チケットは対応する鍵導出値Ｈ_ｉを搬送するものでないことに留意されたい。鍵配布センタが鍵導出値を読み取り、ゲームコンソールがユーザ鍵を認識していると確信すると、鍵配布センタはユーザの識別を発行済のチケット内に配置する。その後サーバ装置９１０６はチケットが伝えるすべての内容を信頼することになるため、鍵導出値Ｈ_ｉを確認する必要はない。
【０１７９】
鍵配布センタは、生成されたチケットをゲームコンソールに戻す。ゲームコンソールはサーバ装置の鍵Ｋ_Ａを知らないため、ゲームコンソールがチケットを開いて内容を変更することはできない。鍵配布センタは、添付の暗号化メッセージでセッションセキュリティ鍵も戻す。セッション鍵メッセージには、チケット生成時間Ｔ_Ｇ、チケット満了長さＴ_Ｌ、およびセッションセキュリティ鍵Ｋ_ＣＡが含まれ、すべての内容は以下のようにゲームコンソールの鍵Ｋ_Ｃを使用して暗号化される。
【０１８０】
【数６】

【０１８１】
セッション鍵メッセージはゲームコンソールの鍵Ｋ_Ｃで暗号化されるため、ゲームコンソールはセッション鍵メッセージを開いて、セッション時間パラメータおよびセッション鍵を回復することができる。
【０１８２】
さらに図９を参照すると、いったんクライアント装置９１０２（たとえばゲームコンソール）が鍵配布センタ９１０４からチケットを受け取ると、クライアント装置９１０２はこのチケットを使用してサーバ装置９１０６との相互認証を使用したセキュア鍵交換を実行することができる。相互認証を使用したセキュア鍵交換は、クライアント装置９１０２およびサーバ装置９１０６にお互いを認証させることが可能であり、すなわちクライアント装置９１０２はサーバ装置９１０６が自分の要求するサーバ装置であることを検証可能であり、サーバ装置９１０６はクライアント装置９１０２が自分の要求するクライアント装置であることを検証可能である。さらにデバイス９１０２および９１０６は、他方が特定鍵の知識を有することを検証可能である。
【０１８３】
鍵交換により、２つのデバイス９１０２および９１０６が、これら２つのデバイス間で共用されるが２つのデバイス間で伝送されることはなく、第三者（たとえばデバイス９１０２および９１０６と同じネットワーク上にある他のデバイス）がデバイス間の往復するトラフィックに基づいて推定することのできない新しい秘密を、導出できるようにすることも可能である。一実施例では、２つのデバイスは新しい秘密を導出するためにディフィ−ヘルマン指数演算（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ　ｅｘｐｏｎｅｎｔｉａｔｉｏｎ　ｏｐｅｒａｔｉｏｎ）を使用する。ディフィ−ヘルマンに関するさらなる情報は、Ｗ．　Ｄｉｆｆｉｅ　ａｎｄ　Ｍ．　Ｅ．　Ｈｅｌｌｍａｎ，　”Ｎｅｗ　ｄｉｒｅｃｔｉｏｎｓ　ｉｎ　Ｃｒｙｐｔｏｇｒａｐｈｙ”，　ＩＥＥＥ　Ｔｒａｎｓａｃｔｉｏｎｓ　ｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔｈｅｏｒｙ　ｖ．　ＩＴ−１２，　ｎ．　６，　Ｎｏｖ　１９７６，　ｐｐ．　６４４−６５４に見ることができる。デバイス９１０２と９１０６との間の通信は、通信を暗号化することによって保護可能であるか、あるいは暗号化なしに実行することができる。
【０１８４】
図１０は、クライアント装置とサーバ装置との間で相互認証を使用してセキュアな鍵交換を実行するための、例示的なプロセス１０１５０を示す流れ図である。図１０のプロセスは、図１０の左側に示されたクライアント装置によって実行されるオペレーションと、図１０の右側に示されたサーバ装置によって実行されるオペレーションにより、クライアント装置とサーバ装置の両方によって実施される。図１０のプロセスは、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組合せで実行可能である。図１０のプロセスは、図９の構成要素を参照して論じられる。さらにプロセスは、クライアント装置とサーバ装置との間のプロセスとして示されているが、互いの間にセキュアな通信チャネルを確立することが望ましい任意の２つのデバイスによって実行することもできる（たとえば、プロセスは２つのクライアント装置または２つのサーバ装置によって実行することができる）。
【０１８５】
初めに、クライアント装置９１０２は鍵交換イニシエータパケットを生成し、このパケットをサーバ装置９１０６に送信する（動作１０１５２）。サーバ装置９１０６は鍵交換イニシエータパケットを受け取り、受け取ったパケットの妥当性を検査する（動作１０１５４）。パケットの妥当性が検査されると、サーバ装置９１０６は、クライアント装置９１０２との通信をセキュアにするために使用される暗号鍵を生成する（動作１０１５６）。一実施例では、これらの暗号鍵は、２つのデバイス間で２地点間通信をセキュアにするために使用されるセキュリティアソシエーション（ｓｅｃｕｒｉｔｙ　ａｓｓｏｃｉａｔｉｏｎ）鍵である。
【０１８６】
次いでサーバ装置９１０６は鍵交換応答パケットを生成し、生成されたパケットをクライアント装置９１０２に送信する（動作１０１５８）。クライアント装置９１０２は鍵交換応答パケットを受け取り、受け取ったパケットの妥当性を検査する（動作１０１６０）。パケットの妥当性が検査されると、クライアント装置９１０２は、サーバ装置９１０６との通信をセキュアにするために使用される暗号鍵を生成する（動作１０１６２）。暗号鍵は、動作１０１５６でサーバ装置９１０６によって生成されたものと同じである。したがって、クライアント装置９１０２とサーバ装置９１０６はどちらも同じ暗号鍵で終わるが、それらの間で実際に鍵を伝送しなくても終わる。
【０１８７】
プロセス１０１５０は、パーフェクトフォワードシークレシ（ｓｅｃｒｅｃｙ）を維持することに留意されたい。パーフェクトフォワードシークレシとは、たとえ第三者に以前の秘密の知識がある可能性があっても、その第三者は新しい秘密を推定できないことを言う。したがって、たとえば第三者（たとえば他のデバイス）がセッション鍵、またはクライアント装置９１０２とサーバ装置９１０６との間で以前に確立された鍵を発見しても、その第三者はセキュアな鍵交換プロセス１０１５０から生成される新しい鍵を推定できないことになる。これは、たとえば第三者に、プロセス１０１５０で使用されるＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ値（以下でより詳細に論じる）の知識がないためである。
【０１８８】
さらに、クライアント装置９１０２とサーバ装置９１０６との間では、２つのパケット、すなわち鍵交換イニシエータパケットおよび鍵交換応答パケットだけを通信すればよいことがわかる。したがって、相互認証を使用したセキュアな鍵交換を実行するために必要となるのは、単一の往復（クライアント装置９１０２からサーバ装置９１０６へのパケット、およびサーバ装置９１０６からクライアント装置９１０２への戻りパケット）のみである。この単一の往復は、使用されるパケット数を減らすことによって、待ち時間を減らし、鍵の確立およびデバイスの相互認証において帯域幅オーバヘッドを減らす働きをする。
【０１８９】
プロセス１０１５０について、図１１〜１４を参照しながら以下でより詳細に論じる。図１１は動作１０１５２をより詳細に示し、図１２は動作１０１５４をより詳細に示し、図１３は動作１０１５６および１０１５８をより詳細に示し、図１４は動作１０１６０および１０１６２をより詳細に示す。
【０１９０】
図１１は、鍵交換イニシエータパケットを生成および送信するための、例示的なプロセス１１２００を示す流れ図である。図１１は、図１０の動作１０１５２をより詳細に示す図である。図１１のプロセスはクライアント装置によって実施され、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組合せで実行可能である。図１１のプロセスは、図９の構成要素を参照して論じられる。
【０１９１】
初めに、クライアント装置９１０２が鍵交換イニシエータメッセージを生成する（動作１１２０２）。鍵交換イニシエータメッセージは、以下のように、ＮｏｎｃｅＩｎｉｔと呼ばれるクライアント装置９１０２によって生成されるランダム（または擬似ランダム）値を含み、さらにＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ（ｇ^Ｘ　ｍｏｄ　Ｎ）値も含み、この式のＸもクライアント装置９１０２によって生成されるランダム（または擬似ランダム）値であって、さらに鍵交換プロセスが完了するとこのクライアント／サーバ通信チャネルを一意に定義する際に使用されることになる、セキュリティパラメータインデックス値（ＳＰＩ_１）も含む。ＩｎｉｔＭｅｓｓ＝［ＮｏｎｃｅＩｎｉｔ，ＳＰＩ_１，（ｇ^Ｘ　ｍｏｄ　Ｎ）］
【０１９２】
次いでクライアント装置９１０２は、鍵配布センタ９１０４から受け取ったケルベロスセッション鍵Ｋ_ＣＡを使用して、鍵交換イニシエータメッセージのダイジェストを算出する（動作１１２０４）。ダイジェストは以下のように生成される。
【０１９３】
【数７】

【０１９４】
あるいは、ＨａｓｈＩｎｉｔＭｅｓｓの計算で、総称的一方向ハッシュ（鍵付きではない）を使用することもできる。鍵交換のセキュリティは、このハッシュが鍵付きであるか否かに依拠しない。
【０１９５】
次いでクライアント装置９１０２は、ケルベロス認証符号（ａｕｔｈｅｎｔｉｃａｔｏｒ）を生成する（動作１１２０６）。ケルベロス認証符号は、タイムスタンプ（たとえばクライアント装置９１０２の現在時刻）と、動作１１２０４で算出されたＨａｓｈＩｎｉｔＭｅｓｓダイジェストを含む。タイムスタンプは、クライアント装置９１０２がケルベロス認証符号を生成するごとにクライアント装置９１０２によって増分され、これにより、サーバ装置９１０６にリプレイ攻撃をより良く検出させることができる。クライアント装置９１０２は、以下のように、ケルベロスセッション鍵Ｋ_ＣＡを使用してケルベロス認証符号を暗号化する（動作１１２０８）。
【０１９６】
【数８】

【０１９７】
次いでクライアント装置９１０２は、鍵交換イニシエータパケットを生成する（動作１１２１０）。鍵交換イニシエータパケットは、鍵交換イニシエータメッセージＩｎｉｔＭｅｓｓ、暗号化されたケルベロス認証符号Ａｕｔｈ_Ｔ、および鍵配布センタ９１０４から受け取ったサーバ装置９１０６用のケルベロスチケットを含む。前述のように、ケルベロスチケットは、少なくともケルベロスセッション鍵（Ｋ_ＣＡ）、チケットが有効な期間、およびクライアント装置９１０２を識別する一意の番号を含み、これらはすべて、鍵配布センタ９１０４およびサーバ装置９１０６が共用する秘密鍵を使用して暗号化される。ＳＰＩ値は、クライアント装置９１０２とサーバ装置９１０６との間のセキュリティアソシエーションまたは通信チャネルを識別する。ＳＰＩ_１値はサーバ装置９１０６からクライアント装置９１０２への通信に関連付けられ、ＳＰＩ_２値はクライアント装置９１０２からサーバ装置９１０６への通信に関連付けられる。したがって、鍵交換イニシエータパケットは以下のようになる。
ＩｎｉｔＰａｃｋｅｔ＝［ＩｎｉｔＭｅｓｓ，Ａｕｔｈ_Ｔ，Ｔｉｃｋｅｔ］
【０１９８】
認証符号とチケットの組合せは、ケルベロス用語でＡＰ　Ｒｅｑｕｅｓｔと呼ばれることに留意されたい。次いでクライアント装置９１０２は、鍵交換イニシエータパケットをサーバ装置９１０６に送信する（動作１１２１２）。
【０１９９】
図１２は、鍵交換イニシエータパケットを受信および妥当性を検査するための、例示的なプロセス１２２５０を示す流れ図である。図１２は、図１０の動作１０１５４をより詳細に示す図である。図１２のプロセスはサーバ装置によって実施され、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組合せで実行可能である。図１２のプロセスは、図９の構成要素を参照して論じられる。
【０２００】
初めに、サーバ装置９１０６は鍵交換イニシエータパケットＩｎｉｔＰａｃｋｅｔを受信する（動作１２２５２）。一実施では、サーバ装置９１０６はすべての鍵交換イニシエータパケットが所定の形式および所定のサイズであることを予測する。サーバ装置９１０６は、この所定の形式および所定のサイズに当てはまらないいずれの鍵交換イニシエータパケットも無視する。あるいは、サーバ装置９１０６は、様々な形式および／または様々なサイズの鍵交換イニシエータパケットを可能にすることができる。
【０２０１】
いったん鍵交換イニシエータパケットが受信されると、サーバ装置９１０６は、サーバ装置９１０６が鍵配布センタ９１０４と共用する鍵を使用して、ケルベロスチケットを解読する（動作１２２５４）。次いでサーバ装置９１０６は、解読されたチケットをチェックして、チケットが失効（ｓｔａｌｅ）していないかどうかを判別する（動作１２２５６）。現在時刻が（チケットで識別された）チケットの有効な期間内に含まれる場合、チケットは失効していない。ただし、現在時刻がチケットの有効な期間内に含まれない場合、チケットは失効している。ケルベロスチケットが失効している場合、鍵交換プロセスは失敗し（動作１２２５８）、その結果、クライアント装置９１０２とサーバ装置９１０６との間にセキュリティアソシエーションは確立されない。動作１２２５８の一部として、サーバ装置９１０６は、鍵交換プロセスが失敗したことをクライアント装置９１０２に通知するか、あるいはサーバ装置９１０６は、受信したＩｎｉｔＰａｃｋｅｔを削除するだけでクライアント装置９１０２に通知しないことができる。
【０２０２】
ただし、ケルベロスチケットが失効していない場合、サーバ装置９１０６は、解読されたケルベロスチケットから回復されたケルベロスセッション鍵Ｋ_ＣＡを使用して、ケルベロス認証符号Ａｕｔｈ_Ｔを解読する（動作１２２６０）。次いでサーバ装置９１０６は、ケルベロス認証符号中のタイムスタンプＴｉｍｅにアクセスし、タイムスタンプが受入れ可能であるかどうかを調べる（動作１２２６２）。タイムスタンプは、サーバ装置９１０６の現在時刻とそれほど同期が外れていなければ、受入れ可能である。一実施例では、タイムスタンプがサーバ装置９１０６の現在時刻からの時間しきい値（たとえば、推奨されるケルベロス時間スキュー（ｓｋｅｗ）である５分）の範囲内であれば、タイムスタンプは受入れ可能である。タイムスタンプが受入れ可能でなければ、鍵交換プロセスは失敗する（動作１２２５８）。
【０２０３】
タイムスタンプが受入れ可能な場合、サーバ装置９１０６は鍵交換メッセージＩｎｉｔＭｅｓｓのダイジェストを算出する（動作１２２６４）。サーバ装置９１０６は、図１１の動作１１２０４でクライアント装置９１０２がダイジェストを算出したのと同じ方法で、ダイジェストを算出する。次いでサーバ装置９１０６は、動作１２２６４で算出したダイジェスト値が、暗号化されたケルベロス認証符号Ａｕｔｈ_Ｔの一部としてクライアント装置９１０２から受信したダイジェスト値に一致する（等しい）かどうかを調べる（動作１２２６６）。２つのダイジェスト値が同じであれば、クライアント装置９１０２とサーバ装置９１０６との間の鍵交換メッセージＩｎｉｔＭｅｓｓが変更されていない（たとえば、鍵交換メッセージＩｎｉｔＭｅｓｓが不正変更されていない）ことを確認する働きをする。２つのダイジェスト値が一致しない場合（言い換えれば、２つのダイジェスト値が等しくない場合）、鍵交換プロセスは失敗する（動作１２２５８）。
【０２０４】
ただし、受信したダイジェスト値と算出されたダイジェスト値が一致した場合、サーバ装置９１０６はケルベロス認証符号が再実行（ｒｅｐｌａｙ）されたかどうかを調べる（動作１２２６８）。サーバ装置９１０６は、各クライアント装置Ｃから受信したそれぞれのケルベロス認証符号（ケルベロスチケットに示されている）からのタイムスタンプの記録を維持する。サーバ装置９１０６が、サーバ装置９１０６によって記録された最後のタイプスタンプよりも新しくないタイムスタンプＴｉｍｅの付いたケルベロス認証符号を受信すると、サーバ装置９１０６はケルベロス認証符号が再実行されたものであることを知る。ケルベロス認証符号が再実行されたものであれば、鍵交換イニシエータパケットは無効であり、鍵交換プロセスは失敗する（動作１２２５８）。ただし、ケルベロス認証符号が再実行されたものでなければ、鍵交換イニシエータパケットはサーバ装置９１０６によって妥当性検査されている（動作１２２７０）。これらの試験すべてに適合し、動作１２２７０で鍵交換イニシエータパケットの妥当性が検査されると、サーバ装置９１０６はクライアント装置９１０２が実際に自分の要求したデバイスであると認証し、サーバ装置９１０６は、クライアント装置９１０２にケルベロスセッション鍵Ｋ_ＣＡの知識があることを検証し、クライアントにＫ_Ｃの知識があることも（鍵配布センタの信用を通じて間接的に）検証する。
【０２０５】
図１３は、暗号鍵を生成するため、ならびに鍵交換応答パケットを生成および送信するための例示的プロセス１３３００を示す流れ図である。図１３は、図１０の動作１０１５６および１０１５８をさらに詳細に示す図である。図１３のプロセスはサーバ装置によって実施され、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組合せで実行可能である。図１３のプロセスは、図９の構成要素を参照して論じられる。
【０２０６】
初めに、サーバ装置９１０６は、鍵交換イニシエータメッセージＩｎｉｔＭｅｓｓ、ケルベロスセッション鍵Ｋ_ＣＡ、クライアント装置９１０２からのナンス（ＮｏｎｃｅＩｎｉｔ）、およびサーバ装置９１０６によって生成されたナンス（ＮｏｎｃｅＲｅｓｐ）に基づいて暗号鍵を生成する（動作１３３０２）。サーバ装置９１０６は、ランダム（または擬似ランダム）数Ｙ、ならびにＮｏｎｃｅＲｅｓｐと呼ばれるランダム値を生成する。さらにサーバ装置９１０６は、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ値（ｇ^ＸＹ　ｍｏｄ　Ｎ）ならびにＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ値（ｇ^Ｙ　ｍｏｄ　Ｎ）を算出する。この時点で、サーバ装置９１０６はセキュリティアソシエーション鍵を算出するのに十分なデータを有する。セキュリティアソシエーション鍵は、２つのコンソール間での２地点間通信をセキュアにするために使用される。一実施例では、サーバ装置９１０６は２つのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ値（（ｇ^Ｘ　ｍｏｄ　Ｎ）および（Ｙ））を使用して関数（ｇ^ＸＹ　ｍｏｄ　Ｎ）を算出する。次いでサーバ装置９１０６は、値ＮｏｎｃｅＩｎｉｔ、ＮｏｎｃｅＲｅｓｐ、（ｇ^ＸＹ　ｍｏｄ　Ｎ）、およびケルベロスセッション鍵Ｋ_ＣＡに基づいて、様々なアルゴリズムを使用して様々なダイジェストを算出する。次いでこれらのダイジェストは、セキュリティアソシエーション鍵を形成するために使用される。一実施例では、サーバ装置９１０６が、ＮｏｎｃｅＩｎｉｔ、ＮｏｎｃｅＲｅｓｐ、（ｇ^ＸＹ　ｍｏｄ　Ｎ）を入力として使用し、ケルベロスセッション鍵Ｋ_ＣＡを双方向ですべてのセキュアパケットを認証および暗号化／解読するためのセキュリティ鍵として使用して、４つの異なるダイジェスト（１つの鍵を認証用、１つの鍵を暗号用に、それぞれの方向用に２倍して合計４つ）を算出する。
【０２０７】
次いでサーバ装置９１０６は、鍵交換応答メッセージを生成する（動作１３３０４）。鍵交換応答メッセージは、以下のように、ＮｏｎｃｅＩｎｉｔ、クライアント装置９１０２から受信したタイムスタンプＴｉｍｅ、ＮｏｎｃｅＲｅｓｐ、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ値（ｇ^Ｙ　ｍｏｄ　Ｎ）、およびＳＰＩ_２値を含む。
ＲｅｓｐＭｅｓｓ＝［ＮｏｎｃｅＩｎｉｔ，ＳＰＩ_２，ＮｏｎｃｅＲｅｓｐ，（ｇ^Ｙ　ｍｏｄ　Ｎ）］
【０２０８】
ＳＰＩ_２値はサーバ装置９１０６によって生成され、クライアント装置９１０２からサーバ装置９１０６へのすべての通信に関連付けられる。次いでサーバ装置９１０６は、以下のように、ケルベロスセッション鍵を使用して応答メッセージのダイジェストおよびハッシュ関数Ｈを算出する（動作１３３０６）。
【０２０９】
【数９】

【０２１０】
動作１３３０６のハッシュ関数Ｈは、動作１１２０４のハッシュ関数Ｈと同じであるか、または異なるハッシュ関数Ｈであってよい。
【０２１１】
次いでサーバ装置９１０６は、以下のように、算出されたハッシュダイジェストおよびケルベロス認証符号からのタイムスタンプＴｉｍｅの両方を含む、ケルベロス回答メッセージを生成する（動作１３３０８）。
ＲｅｐｌｙＭｅｓｓ＝［ＨａｓｈＲｅｓｐＭｅｓｓ，Ｔｉｍｅ］
【０２１２】
次いでサーバ装置９１０６は、以下のように、暗号化アルゴリズムＥ（たとえばトリプルＤＥＳ）およびケルベロスセッション鍵Ｋ_ＣＡを使用してケルベロス回答メッセージＲｅｐｌｙＭｅｓｓを暗号化する（動作１３３１０）。
【０２１３】
【数１０】

【０２１４】
動作１３３０８の暗号化アルゴリズムＥは、図１１の動作１１２０６で使用される暗号化アルゴリズムと同じであるか、または異なる暗号化アルゴリズムであってよい。
【０２１５】
次いでサーバ装置９１０６は、以下のように、鍵交換応答メッセージＲｅｓｐＭｅｓｓおよび暗号化されたケルベロス回答メッセージＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓを含む、鍵交換応答パケットを生成する。
ＲｅｓｐＰａｃｋｅｔ＝［ＲｅｓｐＭｅｓｓ，ＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓ］
【０２１６】
次いでサーバ装置９１０６は、鍵交換応答パケットＲｅｓｐＰａｃｋｅｔをクライアント装置９１０２に送信する（動作１３３１４）。
【０２１７】
図１４は、鍵交換応答パケットを受信および妥当性評価するため、および暗号鍵を生成するための、例示的なプロセスを示す流れ図である。図１４は、図１０の動作１０１６０および１０１６２をより詳細に示す図である。図１４のプロセスはクライアント装置によって実施され、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組合せで実行可能である。図１４のプロセスは、図９の構成要素を参照して論じられる。
【０２１８】
初めに、クライアント装置９１０２は、サーバ装置９１０６から鍵交換応答パケットＲｅｓｐＰａｃｋｅｔを受信する（動作１４３５２）。クライアント装置９１０２は、ケルベロスセッション鍵Ｋ_ＣＡを使用して、ケルベロス回答メッセージＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓを解読する（動作１４３５４）。次いでクライアント装置９１０２は、解読された回答メッセージ中のタイムスタンプＴｉｍｅが、クライアント装置９１０２がサーバ装置９１０６に送信したタイムスタンプＴｉｍｅと一致するかどうかを調べる（動作１４３５６）。タイムスタンプが一致する場合（言い換えれば、タイムスタンプが等しい場合）、その一致により、サーバ装置９１０６がケルベロスチケット（Ｋ_Ａの知識を証明する）およびケルベロス認証符号（したがってケルベロスセッション鍵Ｋ_ＣＡの知識を有する）を解読できたことが確認され、実際にサーバ装置９１０６が自分の要求したものであることが確認される。したがってこれらのタイムスタンプ値が一致すれば、サーバ装置９１０６はクライアント装置９１０２に対して認証され、この時点で、完全な相互認証が達成された（サーバはクライアントに対してＫ_Ａの知識を証明し、クライアントはサーバに対してＫ_Ｃの知識を証明した）。
【０２１９】
タイムスタンプ値が一致しなければ、図１２の動作１２２５８と同様に、鍵交換プロセスは失敗する（動作１４３５８）。ただし、タイムスタンプ値が一致する場合、サーバ装置９１０６はクライアント装置９１０２に対して認証され、続いてクライアント装置９１０２は、ケルベロスセッション鍵Ｋ_ＣＡを使用して鍵交換応答メッセージＲｅｓｐＭｅｓｓのダイジェストを算出する（動作１４３６０）。クライアント装置９１０２は、図１３の動作１３３０６でサーバ装置９１０６がダイジェストを算出したのと同じ方法で、ダイジェストを算出する。次いでクライアント装置９１０２は、自分が動作１４３６０で算出したダイジェスト値が、暗号化されたケルベロス回答メッセージＥｎｃｒｙｐｔｅｄＲｅｐｌｙＭｅｓｓの一部としてサーバ装置９１０６から受信したダイジェスト値と一致する（等しい）かどうかを調べる（動作１４３６２）。２つのダイジェスト値が同じであれば、サーバ装置９１０６とクライアント装置９１０２との間の鍵交換応答メッセージＲｅｓｐＭｅｓｓが変更されていない（たとえば、鍵交換応答メッセージＲｅｓｐＭｅｓｓが不正変更されていない）ことを確認する働きをする。２つのダイジェスト値が一致しない場合（言い換えれば、２つのダイジェスト値が等しくない場合）、鍵交換プロセスは失敗する（動作１４３５８）。
【０２２０】
ただし、２つのダイジェスト値が一致すれば、クライアント装置９１０２は、ケルベロスセッション鍵Ｋ_ＣＡ、ＮｏｎｃｅＩｎｉｔ、ＮｏｎｃｅＲｅｓｐ、およびｇ^ＸＹ　ｍｏｄ　Ｎに基づいて暗号鍵を生成する（動作１４３６４）。図１３の動作１３３０２に関して上記で解説したのと同様に、この時点でクライアント装置９１０２には、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ値（ｇ^ＸＹ　ｍｏｄ　Ｎ）を算出し、セキュリティアソシエーション鍵を算出するのに十分なデータがある。動作１４３６４でクライアント装置９１０２によって算出されるセキュリティアソシエーション鍵は、図１３の動作１３３０２でサーバ装置９１０６によって算出されるものと同じであり、同じ方法で算出される。ｇ^ＸＹ　ｍｏｄ　Ｎは、クライアント装置のｇ^Ｙ　ｍｏｄ　ＮおよびＸから算出されることに留意されたい。
【０２２１】
いったんクライアント装置９１０２がセキュリティアソシエーション鍵を持てば、デバイス９１０２は、鍵交換の完了を待っていたどんなパケットも自由に伝送することができる。ただしサーバ装置９１０６は、たとえ同じ鍵セットを持っていてもその応答メッセージＲｅｓｐＭｅｓｓが失われたことを確認できないため、自由に伝送することはできない。サーバ装置９１０６は、算出されたセキュリティアソシエーション鍵で認証されたパケットをクライアント装置９１０２から受信するまで、あるいは任意選択でクライアント装置９１０２から肯定応答パケット（ＡｃｋＰａｃｋ）を受信するまで、待機する。
【０２２２】
一般には、クライアント装置９１０２がサーバ装置９１０６にパケットを送信するため、鍵交換プロセスは２つのパケット、すなわちＩｎｉｔＰａｃｋｅｔおよびＲｅｓｐＰａｃｋｅｔのみで構成される。あるいは、クライアント装置９１０２がまだパケットを送信していなければ、クライアント装置９１０２は人工の肯定応答パケット（「ＡｃｋＰａｃｋ」と表記される）を送信することになる。このパケットは他の２つの鍵交換パケットとは異なり、ケルベロスセッション鍵Ｋ_ＣＡの代わりに算出されたセキュリティアソシエーション鍵を使用してＡｃｋＰａｃｋがハッシュされる。
【０２２３】
これ以降、２つのデバイス９１０２および９１０４はセキュリティアソシエーション鍵を使用して通信をセキュアにする。他方のデバイスに伝送する必要のあるすべてのネットワークパケットは、任意選択で暗号化された後、受信側デバイスがパケットのコンテンツを解読する前に認証データを検証することによって認証される。デバイス９１０２および９１０４はいずれも、同じナンスを含む他方側からの鍵交換パケットを無視することができる。
【０２２４】
本明細書で論じた相互認証を使用したセキュア鍵交換は、秘密を導出するためのＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ指数演算を参照しながら論じられた。別法として、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎの代わりに他の暗号オペレーションまたは方法を使用することもできる。
【０２２５】
（結び）
以上の説明は、構造上の特徴および／または方法上の動作に特有の言い回しを使用したが、特許請求の範囲で定義される本発明は、説明した特定の特徴または動作に限定されないことを理解されたい。むしろ、以上の特定の特徴および動作は、本発明を実施する例示的な形態として開示している。
【０２２６】
【発明の効果】
以上説明したように本発明によれば、セキュアな通信を可能とするオンラインコンソールベースのゲームのためのセキュリティゲートウェイを実現できる。
【図面の簡単な説明】
【図１】本発明の実施形態の例示的なオンラインゲーム環境を示すブロック図である。
【図２】本発明の実施形態の例示的なセキュリティゲートウェイデバイスをさらなる詳細で示すブロック図である。
【図３】本発明の実施形態のゲームコンソールとセキュリティゲートウェイデバイスの間でセキュアな通信を確立するための例示的なプロセスを示すフローチャートの図である。
【図４ａ】本発明の実施形態のゲームコンソールから受信されたデータパケットを管理するための例示的なプロセスを示すフローチャートの図である。
【図４ｂ】本発明の実施形態のゲームコンソールから受信されたデータパケットを管理するための例示的なプロセスを示すフローチャートの図である。
【図５】本発明の実施形態のゲームコンソールに送信されるデータパケットを扱うための例示的なプロセスを示すフローチャートの図である。
【図６】本発明の実施形態のゲームコンソールに送信されるハートビートパケットを扱うための例示的なプロセスを示すフローチャートの図である。
【図７】本発明の実施形態の一般的なコンピュータ環境を示す図である。
【図８】本発明の実施形態のゲームコンソールの機能上の構成要素をより詳細に示す図である。
【図９】本発明の実施形態の相互認証を使用したセキュアな鍵交換が使用可能な例示的環境を示す構成図である。
【図１０】本発明の実施形態のクライアント装置とサーバ装置との間で相互認証を使用してセキュアな鍵交換を実行するための、例示的なプロセスを示すフローチャートの図である。
【図１１】本発明の実施形態の鍵交換イニシエータパケットを生成および送信するための、例示的なプロセスを示すフローチャートの図である。
【図１２】本発明の実施形態の鍵交換イニシエータパケットを受信および妥当性を検査するための、例示的なプロセスを示すフローチャートの図である。
【図１３】本発明の実施形態の暗号鍵を生成し、さらに鍵交換応答パケットを生成および送信するための、例示的なプロセスを示すフローチャートの図である。
【図１４】本発明の実施形態の鍵交換応答パケットを受信および妥当性を検査するため、および暗号鍵を生成するための、例示的なプロセスを示すフローチャートの図である。
【符号の説明】
１０２−１〜１０２−ｎ　ゲームコンソール
１０４　セキュリティゲートウェイ
１０６　公衆ネットワーク
１０８　専用ネットワーク
１１０　データセンタ
１１２　監視サーバ
１１４　存在−通知フロントドア
１１６　存在サーバ
１１８　通知サーバ
１２０　マッチフロントドア
１２２　マッチサーバ
１２４　統計フロントドア
１２６　統計サーバ
１２８　鍵配信センタ
１５０　セキュリティゲートウェイデバイス
１５２、１７４　公衆ネットワークインタフェース
１５４　パケット解読モジュール
１５６　パケット認証モジュール
１５８　ゲームコンソール認証モジュール
１６０　ＮＡＴトラバーサルモジュール
１６２　認証情報生成モジュール
１６４　パケット暗号化モジュール
１６６　ハートビートモジュール
１６８　ティクルモジュール
１７０　セキュアゾーンインタフェース
１７２　セキュリティ関係レコード
１７６　ゲームコンソールアベイラビリティモジュール
１７８　パケットルーティングモジュール
９１０２　クライアント装置
９１０４　鍵配布センタ
９１０６　サーバ装置
１０１５０　　鍵交換プロセス

Claims (74)

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. 第１のＮＡＴデバイスが、前記ゲームコンソールと前記セキュリティゲートウェイの間に配置され、かつ第２のＮＡＴデバイスが、前記別のゲームコンソールと前記セキュリティゲートウェイの間に配置されることを特徴とする請求項３０に記載の方法。
32. 前記パケットがネットワークアドレス変換（ＮＡＴ）トラバーサルパケットである場合、前記パケットを扱うステップは、
    前記パケットが転送される先の別のゲームコンソールを特定するステップと、前記別のゲームコンソールを扱うことに責任を負う前記セキュリティゲートウェイのセキュリティゲートウェイデバイスを特定するステップと、
    前記別のゲームコンソールに送信するために前記パケットを前記セキュリティゲートウェイデバイスに転送するステップと
    を含むことを特徴とする請求項１６に記載の方法。
33. 前記データパケットは、部分的に暗号化され、かつ前記データパケットの中のデータを解読するステップは、前記パケットの中の前記データの一部分を解読するステップを含むことを特徴とする請求項１６に記載の方法。
34. １つまたは複数のプロセッサによって実行されたとき、該１つまたは複数のプロセッサに、
    ゲームコンソールからデータパケットを受信するステップと、
    前記ゲームコンソールに対応するセキュリティ関係を特定するステップと、
    前記データパケットを前記ゲームコンソールからのものとして認証するために前記セキュリティ関係のセキュリティ鍵を使用するステップと、
    前記データパケットの内容を解読するために前記セキュリティ鍵を使用するステップと、
    前記データパケットのタイプをチェックするステップと、
    前記データパケットの前記タイプに基づいて前記データパケットの解読された前記内容を転送するステップと
    を行わせる複数の命令を記憶していることを特徴とする１つまたは複数のコンピュータ読み取り可能な記録媒体。
35. 前記データパケットの前記タイプは、ハートビートパケット、サービスを目標とするパケット、およびネットワークアドレス変換（ＮＡＴ）トラバーサルパケットのどれかを含むことを特徴とする請求項３４に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
36. 前記データパケットがハートビートパケットである場合、前記複数の命令は、前記１つまたは複数のプロセッサに、
    前記ゲームコンソール上で実行されるゲームタイトルに関するステータス情報が前記ハートビートパケットの中に含まれているかどうかをチェックするステップと、
    前記ステータス情報が前記ハートビートパケットの中に含まれている場合、前記ハートビートパケットから前記ステータス情報を抽出し、前記ステータス情報を複数のゲームコンソールに関するステータス情報を管理する存在サーバに転送するステップと
    をさらに行わせることを特徴とする請求項３４に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
37. 前記データパケットがサービスを目標とするパケットである場合、前記複数の命令は、前記１つまたは複数のプロセッサに、
    前記データパケットによって目標とされるサービスを特定するステップと、
    前記ゲームコンソールが前記サービスを使用することが許されているかどうかをチェックするステップと、
    前記ゲームコンソールが前記サービスを使用することが許されている場合にだけ、前記サービスのアドレスを特定し、前記内容を前記アドレスで前記サービスに転送するステップと
    をさらに行わせることを特徴とする請求項３４に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
38. 前記１つまたは複数のプロセッサに、前記パケットによって目標とされるサービスを特定するステップを行わせる前記命令は、前記１つまたは複数のプロセッサに、前記データパケットが受信されたポートを前記サービスのネットワークアドレスにマップすることを行わせる命令を含むことを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
39. 前記１つまたは複数のプロセッサに、前記ゲームコンソールが前記サービスを使用することが許されているかどうかをチェックするステップを行わせる前記命令は、前記１つまたは複数のプロセッサに、前記ゲームコンソールに関連するセキュアな通信チャネルに対応する許可マッピングにアクセスして、前記許可マッピングが、前記サービスへのアクセスが許可されていることを示すかどうかをチェックすることを行わせる命令を含むことを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
40. 前記サービスは、存在−通知サービスを含むことを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
41. 前記サービスは、マッチサービスを含むことを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
42. 前記サービスは、統計サービスを含むことを特徴とする請求項３７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
43. 前記パケットがネットワークアドレス変換（ＮＡＴ）トラバーサルパケットである場合、前記複数の命令は、前記１つまたは複数のプロセッサに、
    前記データパケットが転送される先の別のゲームコンソールを特定するステップと、
    前記別のゲームコンソールに対応する別のセキュリティ鍵を特定するステップと、
    解読された前記データパケットを暗号化するために前記別のセキュリティ鍵を使用するステップと、
    暗号化された前記データパケットを前記セキュリティゲートウェイからのものとして認証するために暗号化された前記データパケットに関する認証情報を生成するステップと、
    暗号化された前記データパケットおよび前記認証情報を前記別のゲームコンソールに送信するステップと
    をさらに行わせることを特徴とする請求項３４に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
44. 前記１つまたは複数のプロセッサは、セキュリティゲートウェイの一部であり、かつ第１のＮＡＴデバイスは、前記ゲームコンソールと前記セキュリティゲートウェイの間に配置され、かつ第２のＮＡＴデバイスは、前記別のゲームコンソールと前記セキュリティゲートウェイの間に配置されることを特徴とする請求項４３に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
45. 前記データパケットは部分的に暗号化され、かつ前記１つまたは複数のプロセッサに、前記セキュリティ鍵を使用して前記データパケットの内容を解読することを行わせる前記命令は、前記１つまたは複数のプロセッサに、前記データパケットの前記内容の一部分を解読することを行わせる命令を含むことを特徴とする請求項３４に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
46. 前記命令は、前記１つまたは複数のプロセッサに、
    デバイスから、前記ゲームコンソールに関する追加の情報の要求を受け取るステップと、
    前記デバイスに、前記ゲームコンソールに関する追加の情報を転送するステップと
    をさらに行わせることを特徴とする請求項３４に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
47. セキュリティゲートウェイで実行する方法であって、
    サービスデバイスから、暗号化されていないデータを受信するステップと、
    前記データが通信されるべきゲームコンソールを特定するステップと、
    前記ゲームコンソールに対応するセキュリティ鍵を特定するステップと、
    前記セキュリティ鍵を使用して前記データを暗号化するステップと、
    暗号化された前記データをデータパケットに組み込むステップと、
    前記データパケットに関する認証情報を生成するステップと、
    前記データパケットおよび前記認証情報を前記ゲームコンソールに送信するステップと
    を備えたことを特徴とする方法。
48. 暗号化されていないデータを受信するステップは、データセンタセキュアゾーン内のサービスデバイスから暗号化されていないデータを受信するステップを含むことを特徴とする請求項４７に記載の方法。
49. 前記ゲームコンソールを特定するステップは、前記サービスデバイスから受信された情報に基づき、前記ゲームコンソールのアドレスを特定するセキュリティ関係情報のレコードにアクセスするステップを含むことを特徴とする請求項４７に記載の方法。
50. 前記ゲームコンソールに対応する前記セキュリティ鍵を特定するステップは、前記サービスデバイスから受信された情報に基づき、セキュリティ関係情報のレコードにアクセスして前記セキュリティ鍵を特定するステップを含むことを特徴とする請求項４７に記載の方法。
51. 前記サービスデバイスは、通知サービスデバイスを含むことを特徴とする請求項４７に記載の方法。
52. 前記サービスデバイスは、マッチサービスデバイスを含むことを特徴とする請求項４７に記載の方法。
53. 前記サービスデバイスは、統計サービスデバイスを含むことを特徴とする請求項４７に記載の方法。
54. 公衆ネットワークと専用ネットワークとの間でゲートウェイとして動作するセキュリティゲートウェイの１つまたは複数のプロセッサによって実行されたとき、前記１つまたは複数のプロセッサに、
    前記専用ネットワーク上のデバイスから、前記公衆ネットワーク上のゲームコンソールに通信されるべきデータを受信するステップと、
    前記ゲームコンソールに関連するセキュアな通信チャネルを特定するステップと、
    前記セキュアな通信チャネルに関係する情報からセキュリティ鍵を獲得するステップと、
    前記セキュリティ鍵を使用して前記データを暗号化するステップと、
    前記セキュリティ鍵を使用して、暗号化された前記データを前記セキュリティゲートウェイからのものとして認証するのに使用することができる認証情報を生成するステップと、
    暗号化された前記データおよび前記認証情報を前記ゲームコンソールに送信するステップと
    を行わせる複数の命令を記憶していることを特徴とする１つまたは複数のコンピュータ読み取り可能な記録媒体。
55. 前記命令は、前記１つまたは複数のプロセッサに、前記セキュアな通信チャネルに関係する前記情報から、暗号化された前記データおよび前記認証情報が送信されるべき先の前記ゲームコンソールに関連するアドレスを獲得することをさらに行わせることを特徴とする請求項５４に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
56. 前記ゲームコンソールに関連する前記アドレスは、中間ネットワークアドレス変換（ＮＡＴ）デバイスのアドレスであることを特徴とする請求項５５に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
57. 前記１つまたは複数のプロセッサは、暗号プロセッサおよび汎用プロセッサを含むことを特徴とする請求項５４に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
58. 前記１つまたは複数のプロセッサに、前記データを暗号化するステップを行わせる前記命令は、前記１つまたは複数のプロセッサに、前記セキュリティ鍵を使用して前記データの一部分を暗号化することを行わせる命令を含むことを特徴とする請求項５４に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
59. セキュリティゲートウェイで実行する方法であって、
    ハートビートパケットがゲームコンソールに送信されるべき時点であることを判定するステップと、
    サービスデバイスから受信された、前記ゲームコンソールに送信されるべき追加のデータが存在するかどうかをチェックするステップと、
    ハートビートパケットを生成し、前記ゲームコンソールに送信されるべき追加のデータが存在する場合、前記追加のデータを前記ハートビートパケットに組み込むステップと、
    前記ゲームコンソールに対応するセキュリティ鍵を特定するステップと、
    前記追加のデータが存在する場合、該データを含め、前記ハートビートパケットのデータ内容を前記セキュリティ鍵を使用して暗号化するステップと、
    暗号化された前記ハートビートパケットに関する認証情報を生成するステップと、
    暗号化された前記ハートビートパケットおよび前記認証情報を前記ゲームコンソールに送信するステップと
    を備えたことを特徴とする方法。
60. 前記セキュリティゲートウェイは、公衆ネットワークと専用ネットワークとの間のゲートウェイとして動作し、前記ゲームコンソールは、前記公衆ネットワークを介して前記セキュリティゲートウェイと通信し、かつ前記サービスデバイスは、前記専用ネットワークを介して前記セキュリティゲートウェイと通信することを特徴とする請求項５９に記載の方法。
61. 暗号化された前記ハートビートパケットおよび前記認証情報が送信されるべき先の前記ゲームコンソールに関連するアドレスを特定するステップをさらに含むことを特徴とする請求項５９に記載の方法。
62. 前記ゲームコンソールに関連する前記アドレスは、中間ネットワークアドレス変換（ＮＡＴ）デバイスのアドレスであることを特徴とする請求項６１に記載の方法。
63. 公衆ネットワークと専用ネットワークとの間でゲートウェイとして動作するセキュリティゲートウェイの１つまたは複数のプロセッサによって実行されたとき、前記１つまたは複数のプロセッサに、
    前記公衆ネットワーク上のゲームコンソールに送信されるべき、前記専用ネットワーク上のサービスデバイスから受信された追加のデータを特定するステップと、
    前記ゲームコンソールに送信されるべきハートビートパケットを生成するステップと、
    前記追加のデータを前記ハートビートパケットに追加するステップと、
    前記ゲームコンソールに関連するセキュリティ鍵を特定するステップと、
    前記セキュリティ鍵を使用して前記ハートビートパケットを暗号化するステップと、
    暗号化された前記パケットを前記ゲームコンソールに送信するステップと
    を行わせる複数の命令を記憶していることを特徴とする１つまたは複数のコンピュータ読み取り可能な記録媒体。
64. 前記セキュリティ鍵は、前記ゲームコンソールと前記セキュリティゲートウェイとの間のセキュリティ関係に対応することを特徴とする請求項６３に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
65. 前記命令は、前記１つまたは複数のプロセッサに、暗号化された前記パケットが送信されるべき先の前記ゲームコンソールに関連するアドレスを特定するステップをさらに行わせることを特徴とする請求項６３に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
66. 前記ゲームコンソールに関連する前記アドレスは、中間ネットワークアドレス変換（ＮＡＴ）デバイスのアドレスであることを特徴とする請求項６５に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
67. 前記１つまたは複数のプロセッサは、暗号コプロセッサおよび汎用プロセッサを含むことを特徴とする請求項６３に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
68. 前記サービスデバイスは、通知サービスデバイスを含むことを特徴とする請求項６３に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
69. 前記サービスデバイスは、マッチサービスデバイスを含むことを特徴とする請求項６３に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
70. 前記サービスデバイスは、統計サービスデバイスを含むことを特徴とする請求項６３に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
71. システムが、公衆ネットワークを介して複数のゲームコンソールとセキュアに通信することを可能にするように構成された第１のインタフェースと、
    前記システムが、専用ネットワークを介して複数のサービスデバイスと通信することを可能にするように構成された第２のインタフェースと、
    前記第１のインタフェースおよび前記第２のインタフェースに結合された１つまたは複数のモジュールであって、前記複数のゲームコンソールの中のゲームコンソールから受信されたデータパケットを認証し、解読して、前記データパケットが自らの目標として特定するサービスデバイス、ならびに前記データパケットの送信元である前記ゲームコンソールが、前記サービスデバイスにアクセスすることが許されているかどうかに基づき、前記データパケットの内容を前記複数のサービスデバイスの中の適切なデバイスに転送するように構成された１つまたは複数のモジュールと
    を備えたことを特徴とするシステム。
72. 公衆ネットワークは、インターネットを含むことを特徴とする請求項７１に記載のシステム。
73. 前記専用ネットワークは、データセンタセキュアゾーン内のネットワークを含むことを特徴とする請求項７１に記載のシステム。
74. システムが、インターネットを介して複数のゲームコンソールと通信することを可能にするように構成されたインタフェースと、
    システムが、専用ネットワークを介して複数のサービスデバイスと通信することを可能にするように構成された別のインタフェースと、
    前記複数のゲームコンソールのそれぞれに関して、システムと前記ゲームコンソールとの間のセキュリティ関係に関する情報を記憶するデバイスと、
    １つまたは複数のモジュールであって、
    前記ゲームコンソールとの前記セキュリティ関係を確立し、
    前記ゲームコンソールからデータパケットを受信して、各パケットのタイプに従って前記データパケットを扱い、
    前記サービスデバイスからデータを受信し、前記データを暗号化して、前記データを前記サービスデバイスによって特定されたゲームコンソールに転送し、ハートビートパケットを前記ゲームコンソールに送信し、前記ハートビートパケットの１つまたは複数が、前記サービスデバイスの１つから受信された追加の情報を含む
    ように構成された１つまたは複数のモジュールと
    を備えたことを特徴とするシステム。

Images