(57)【要約】セキュアブート手順および完全な不揮発性メモリ暗号化プロセスを用いて、組み込みデバイスの認証および機密保護を行う方法およびシステムが提供される。組み込みデバイスは、個人用ＢＩＯＳおよびマスターブートレコードにおけるメッセージ回復を有する楕円曲線ピンストフ−バンストーン（ＥＣＰＶ）署名方式を行う。署名に含まれるコードを回復した結果、解除されたキーを順に用いて不揮発性メモリを復号化する。ＥＣＰＶＳを用いることによって、ハードウェアがＢＩＯＳにバインドされる暗黙的な検証が行われる。これは、暗号化されたメモリが、適切なキーによって適切に復号化されない限りは使用不能であるためである。
2009544084.tif 000002
【特許請求の範囲】
【請求項１】
デバイスによって用いられるコンテンツの機密保護を行う方法であって、
暗号化されたイメージを、キーを用いて復号化することによって上記コンテンツの少なくとも一部分を回復できるように、当該部分を暗号化することによって、上記暗号化されたイメージを準備する工程と、
上記デバイスに特有の情報を用いて第１の署名要素から上記キーを回復できるように、上記第１の署名要素内の上記キーを暗号化する工程と、
上記デバイスが、上記デバイスに特有の情報を用いて上記第１の署名要素から上記キーを回復して、上記部分を復号化できるように、上記第１の署名要素を含む署名を上記デバイスに対し使用できるようにする工程とを含んでいる、方法。
【請求項２】
上記署名は、可視メッセージである、上記デバイスに特有の情報を有する楕円曲線ピンストフ−バンストーン（ＥＣＰＶ）署名であり、
上記キーは、上記第１の署名要素および上記デバイスに特有の上記情報を用いて、上記第１の署名要素を復号化する復号化キーを生成することによって回復可能である、請求項１に記載の方法。
【請求項３】
上記デバイスは、上記コンテンツを記憶するハードウェアボードを含んでおり、
当該ハードウェアボードは、基本入出力システム（ＢＩＯＳ）を含んでおり、
上記コンテンツは、ブート部分、アプリケーション部分、およびデータ部分を含んでおり、
上記署名は、上記ＢＩＯＳ上に記憶され、上記ブート部分のブートアップ手順中にアクセスされて上記キーが回復される、請求項１に記載の方法。
【請求項４】
上記デバイスに特有の上記情報は、上記署名を上記ハードウェアボードにバインドするためのハードウェアシリアルナンバーを少なくとも１つ含んでいる、請求項３に記載の方法。
【請求項５】
上記暗号化されたイメージおよび上記署名は、上記ハードウェアボードに対するバインディング動作中にバインディング装置によって上記ハードウェアボードに加えられ、
上記バインディング装置は、上記デバイスに特有の上記情報を取得し、上記情報を第三者機関に提供して、当該第三者機関が上記署名を準備できるようにし、
上記バインディング装置は、上記署名を受け取り、上記暗号化されたイメージを準備し、上記暗号化されたイメージを上記ハードウェアボードへ書き込み、そして上記ＢＩＯＳをフラッシュして上記署名を含ませる、請求項３に記載の方法。
【請求項６】
上記デバイスはゲーム機である、請求項１に記載の方法。
【請求項７】
デバイスによって用いられるコンテンツを認証する方法であって、
第１の署名要素から回復可能なキーが暗号化された第１の署名要素を含んだ署名を取得する工程と、
上記デバイスに特有の情報を取得する工程と、
上記デバイスに特有の上記情報を用いて、上記第１の署名要素から上記キーを回復する工程と、
上記キーを用いて、上記コンテンツの少なくとも一部分の暗号化されたイメージを復号化して、当該部分を回復する工程とを含んでおり、
上記部分が上記デバイス上において動作可能である場合には、上記コンテンツは暗黙的に認証される、方法。
【請求項８】
上記署名は、可視メッセージである、上記デバイスに特有の上記情報を有するＥＣＰＶ署名であり、
上記キーは、上記第１の署名要素および上記デバイスに特有の情報を用いて、復号化キーを生成し、該復号化キーを用いて上記第１の署名要素を復号化することにより回復される、請求項７に記載の方法。
【請求項９】
上記デバイスは、上記コンテンツを記憶するハードウェアボードを含んでおり、
当該ハードウェアボードは、ＢＩＯＳを含んでおり、
上記コンテンツは、ブート部分、アプリケーション部分、およびデータ部分を含んでおり、
上記署名は、上記ＢＩＯＳ内に記憶され、上記ＢＩＯＳから取得され、そして上記ブート部分のブートアップ手順中にアクセスされて上記キーを回復する、請求項７に記載の方法。
【請求項１０】
上記デバイスに特有の上記情報は、上記署名を上記ハードウェアボードにバインドするためのハードウェアシリアルナンバーを少なくとも１つ含んでいる、請求項９に記載の方法。
【請求項１１】
上記デバイスはゲーム機である、請求項７に記載の方法。
【請求項１２】
デバイスによって用いられるコンテンツの機密保護を行う方法であって、
上記コンテンツにおける平文の第１の部分および上記コンテンツにおける平文の第２の部分を指定する工程と、
上記平文の第１の部分を暗号化して、暗号化された第１の部分を生成する工程と、
上記暗号化された第１の部分および上記平文の第２の部分を上記デバイスに記憶する工程と、
上記暗号化された第１の部分と上記平文の第２の部分とを要素として含む署名であって、上記デバイスが上記平文の第１の部分を用いることを可能にするために上記暗号化された第１の部分から上記平文の第１の部分を回復するために用いることのできる署名を生成する工程とを含んでいる、方法。
【請求項１３】
上記署名は、可視メッセージである上記平文の第２の部分を有するＥＣＰＶ署名であり、
上記平文の第２の部分は、上記暗号化された第１の要素および上記平文の第２の部分を用いて復号化キーを生成し、当該復号化キーを用いて上記暗号化された第１の部分を復号化することによって回復可能である、請求項１２に記載の方法。
【請求項１４】
上記暗号化された第１の部分を生成する前に、上記平文の第１の部分に冗長を付加する工程を含んでおり、
上記コンテンツは、上記平文の第１の部分が回復される時に上記冗長をチェックすることによって認証することができる、請求項１３に記載の方法。
【請求項１５】
上記デバイスは、ハードウェアボードを備えており、
当該ハードウェアボードは、ＢＩＯＳと、上記コンテンツを含むハードディスクとを有しており、
上記コンテンツは、ブートローダと、オペレーティングシステムと、アプリケーション部分とを含んでいる、請求項１２に記載の方法。
【請求項１６】
上記平文の第１の部分を回復する際に用いられる公開キーを上記ＢＩＯＳ内に記憶する工程を含んでいる、請求項１５に記載の方法。
【請求項１７】
上記平文の第１の部分は、上記ブートローダおよび上記オペレーティングシステムを含んでおり、上記平文の第２の部分は、上記アプリケーション部分を含んでいる、請求項１５に記載の方法。
【請求項１８】
上記平文の第１の部分は、上記ブートローダを含んでおり、上記平文の第２の部分は、上記オペレーティングシステムおよび上記アプリケーション部分を含んでいる、請求項１５に記載の方法。
【請求項１９】
上記平文の第１の部分は、上記アプリケーション部分を含んでおり、上記平文の第２の部分は、上記ブートローダおよび上記オペレーティングシステムを含んでいる、請求項１５に記載の方法。
【請求項２０】
上記デバイスはゲーム機である、請求項１２に記載の方法。
【請求項２１】
デバイスによって用いられるコンテンツを認証する方法であって、
上記コンテンツにおける暗号化された第１の部分と上記コンテンツにおける平文の第２の部分とを要素として含む署名を取得する工程と、
上記署名を用いて、上記暗号化された第１の部分から平文の第１の部分を回復する工程と、
上記署名から回復された上記平文の第１の部分に従って上記コンテンツを認証する工程とを含んでいる、方法。
【請求項２２】
上記署名は、可視メッセージである上記平文の第２の部分を有するＥＣＰＶ署名であり、
上記平文の第２の部分は、上記暗号化された第１の要素および上記平文の第２の部分を用いて、復号化キーを生成し、当該復号化キーを用いて、上記暗号化された第１の部分を復号化することによって回復する、請求項２１に記載の方法。
【請求項２３】
上記暗号化された第１の部分を生成する前に、上記平文の第１の部分内に冗長が含まれ、上記コンテンツは、上記平文の第１の部分が回復される時に上記冗長をチェックすることによって認証される、請求項２２に記載の方法。
【請求項２４】
上記コンテンツは、上記平文の第１の部分が、回復された場合に動作可能であるか否かに応じて、暗黙的に認証される、請求項２１に記載の方法。
【請求項２５】
上記デバイスは、ハードウェアボードを備えており、
当該ハードウェアボードは、ＢＩＯＳと、上記コンテンツを含むハードディスクとを有しており、
上記コンテンツは、ブートローダと、オペレーティングシステムと、アプリケーション部分とを有している、請求項２１に記載の方法。
【請求項２６】
上記ＢＩＯＳ内に記憶された公開キーを用いて、上記平文の第１の部分を回復する工程を含んでいる、請求項２５に記載の方法。
【請求項２７】
上記平文の第１の部分は、上記ブートローダおよび上記オペレーティングシステムを含んでおり、上記平文の第２の部分は、上記アプリケーション部分を含んでいる、請求項２５に記載の方法。
【請求項２８】
上記平文の第１の部分は、上記ブートローダを含んでおり、上記平文の第２の部分は、上記オペレーティングシステムおよび上記アプリケーション部分を含んでいる、請求項２５に記載の方法。
【請求項２９】
上記平文の第１の部分は、上記アプリケーション部分を含んでおり、上記平文の第２の部分は、上記ブートローダおよび上記オペレーティングシステムを含んでいる、請求項２５に記載の方法。
【請求項３０】
上記デバイスはゲーム機である、請求項２１に記載の方法。
【請求項３１】
デバイスによって用いられるコンテンツの機密保護を行う方法であって、
上記コンテンツにおける複数の部分を指定する工程と、
上記デバイスに第１の値を記憶する工程と、
上記第１の値を用いて回復できるような第２の値を暗号化する要素を含む第１の署名を、上記コンテンツの第１の部分に生成する工程と、
上記第２の値を用いて回復できるような第３の値を暗号化する要素を含む第２の署名を、上記コンテンツの第２の部分に生成する工程と、
上記部分が３つ以上の場合、次の部分によって用いられる次の値を、前の部分の署名から回復された前の値を用いて回復できるように、上記次の値を暗号化する要素をそれぞれ含む他の署名を生成する工程とを含んでおり、
上記第１の値を用いて、上記第１の署名から上記第２の値を回復することができ、上記第２の値を用いて、上記第２の署名から上記第３の値を回復することができ、必要であれば、上記前の値を用いて上記次の値を回復可能であり、その結果、上記部分の最後において各署名から回復された最終値を上記第１の値と比較して、上記複数の部分を同時に認証することができる、方法。
【請求項３２】
上記各署名は、可視メッセージである、上記コンテンツの上記各部分を有するＥＣＰＶ署名であり、
上記各値は、上記コンテンツにおける上記各値および上記各部分を用いて、上記各要素を復号化する復号化キーを生成することによって回復可能である、請求項２９に記載の方法。
【請求項３３】
上記デバイスは、ハードウェアボードを含んでおり、当該ハードウェアボードは、ＢＩＯＳと、上記コンテンツの上記複数の部分を含むハードディスクとを有する、請求項３１に記載の方法。
【請求項３４】
上記第１の値を上記ＢＩＯＳ内に記憶する工程を含んでいる、請求項３３に記載の方法。
【請求項３５】
上記複数の部分のうち少なくとも１つは、署名をそれぞれ含む複数のモジュールを含んでおり、
上記複数のモジュールの１つはエントリモジュールであり、
上記複数のモジュールの１つはエンドモジュールであり、
上記エントリモジュールの署名は、上記前の値を用いて、あるいは上記前の部分が上記第１の部分である場合の上記第１の値を用いて回復可能であるような中間値を暗号化する要素を含んでおり、
上記エンドモジュールの署名は、上記次の値、あるいは上記少なくとも１つの部分が最後の部分である場合の上記最終値を、上記中間値を用いて回復可能であるような上記次の値または上記最終値を暗号化する要素を含んでおり、
上記少なくとも１つの部分が３つ以上のモジュールを含む場合、上記エントリモジュールと上記エンドモジュールとの間の他のモジュールが有する署名は、前のモジュールの各署名から回復された上記中間値を用いて回復可能であるような上記中間値を暗号化する要素を含んでいる、請求項３１に記載の方法。
【請求項３６】
上記デバイスはゲーム機である、請求項３１に記載の方法。
【請求項３７】
デバイスによって用いられるコンテンツを認証する方法であって、
上記デバイスに記憶された第１の値を取得する工程と、
上記コンテンツの複数の部分のうち第１の部分における第１の署名であって、第２の値を暗号化する要素を含んでいる第１の署名を取得する工程と、
上記第１の値を用いて上記第２の値を回復する工程と、
上記コンテンツの上記複数の部分のうち第２の部分における第２の署名であって、第３の値を暗号化する要素を含んでいる第２の署名を取得する工程と、
上記第１の署名から回復された上記第２の値を用いて上記第３の値を回復する工程と、
上記部分が３つ以上の場合、次の値を暗号化する要素をそれぞれ含む他の署名を取得して、前の部分の署名から回復された前の値を用いて上記次の値を回復する工程と、
上記複数の部分のうち最後の部分における署名から回復された最終値を上記第１の値と比較して、上記複数の部分の全てを同時に認証する工程とを含んでいる、方法。
【請求項３８】
上記各署名は、可視メッセージである、上記コンテンツの各部分を有するＥＣＰＶ署名であり、
上記各値は、上記コンテンツにおける上記各値および上記各部分を用いて、上記各要素を復号化する復号化キーを生成することによって回復可能である、請求項３７に記載の方法。
【請求項３９】
上記デバイスは、ハードウェアボードを含んでおり、当該ハードウェアボードは、ＢＩＯＳと、上記コンテンツの上記複数の部分を含むハードディスクとを有している、請求項３７に記載の方法。
【請求項４０】
上記第１の値を上記ＢＩＯＳから取得する、請求項３９に記載の方法。
【請求項４１】
上記複数の部分のうち少なくとも１つは、署名をそれぞれ含む複数のモジュールを含んでおり、
上記複数のモジュールの１つはエントリモジュールであり、
上記複数のモジュールの１つはエンドモジュールであり、
上記エントリモジュールの署名は、上記前の値を用いて、あるいは上記前の部分が上記第１の部分である場合の上記第１の値を用いて回復可能であるような中間値を暗号化する要素を含んでおり、
上記エンドモジュールの署名は、上記次の値、あるいは上記少なくとも１つの部分が上記最後の部分である場合の上記最終値を、上記中間値を用いて回復可能であるような上記次の値または上記最終値を暗号化する要素を含んでおり、
上記部分の上記１つが３つ以上のモジュールを含む場合、上記エントリモジュールと上記エンドモジュールとの間の他のモジュールが有する署名は、前のモジュールの各署名から回復された上記中間値を用いて回復可能であるような上記中間値を暗号化する要素を含んでいる、請求項３７に記載の方法。
【請求項４２】
上記値のうち選択された１つの値を用いて、鍵付きハッシュ関数のためのキーを得る工程と、
上記ハッシュ関数を上記複数の要素の１つに適用して、後に上記複数の要素の上記１つを認証するために用いられる認証コードを取得する工程とを含んでいる、請求項４１に記載の方法。
【請求項４３】
上記複数の要素の１つに関して新しいモジュールをダウンロードすると、上記各エントリモジュールの署名から上記中間値を回復し、当該中間値を用いて上記新しいモジュールの署名から上記中間値を回復し、上記新しいモジュールから回復された上記中間値を用いて上記次の値を回復し、上記次の値を用いて上記値のうち上記選択された１つの値を回復し、上記値のうち上記選択された１つの値および上記複数の要素の上記１つを用いて新しい認証コードを生成し、当該新しい認証コードを、先に取得された上記認証コードと比較して、上記コンテンツを再認証する工程を含んでいる、請求項４２に記載の方法。
【請求項４４】
上記値のうち、選択された１つを用いて、鍵付きハッシュ関数のためのキーを得る工程と、
上記ハッシュ関数を上記複数の要素の１つに適用して、後に上記複数の要素の上記１つを認証するために用いる認証コードを取得する工程とを含んでいる、請求項３７に記載の方法。
【請求項４５】
上記デバイスはゲーム機である、請求項３７に記載の方法。
【請求項４６】
デバイスによって用いられるコンテンツに関して新しいモジュールをダウンロードする方法であって、
上記コンテンツの要素に関してエントリモジュールの署名を取得する工程、
上記要素は、署名をそれぞれ含む複数のモジュールを含んでおり、
上記複数のモジュールの１つは、上記エントリモジュールであり、
上記複数のモジュールの１つは、エンドモジュールであり、
上記エントリモジュールの上記署名は、上記デバイスに記憶されている値を用いて回復できるような中間値を暗号化する署名要素を含んでおり、
上記エンドモジュールの上記署名は、上記中間値を用いて回復できるような次の値を暗号化する署名要素を含んでおり、
上記エントリモジュールおよびエンドモジュールに加えて３つ以上のモジュールが存在している場合、上記要素の他のモジュールが有する署名は、前のモジュールの各署名から回復された上記中間値を用いて回復できるような上記中間値を暗号化する署名要素を含んでおり；
上記エントリモジュールの上記署名から上記中間値を回復する工程；
上記新しいモジュールの署名を取得する工程、
上記新しいモジュールの上記署名は、上記中間値を用いて回復できるような上記中間値を暗号化する署名要素を含んでおり；
上記エントリモジュールの上記署名から回復された上記中間値を用いて、上記新しいモジュールの上記署名から上記中間値を回復する工程；
上記エンドモジュールの上記署名を取得し、上記新しいモジュールの上記署名から回復された上記中間値を用いて上記次の値を取得する工程；
上記次の値を鍵付きハッシュ関数のためのキーとして用い、当該鍵付きハッシュ関数を上記コンテンツの別の要素に適用して認証コードを取得する工程；および
上記認証コードと、上記別の要素において先に生成されて記憶された認証コードとを比較して、上記新しいモジュールおよび上記コンテンツを認証する工程を含んでいる、方法。
【請求項４７】
上記デバイスはゲーム機である、請求項４６に記載の方法。
【請求項４８】
ゲーム機上のデータの機密保護を行う方法であって、
上記データの一部分を暗号化する工程と、
上記ゲーム機にＥＣＰＶ署名を記憶する工程とを含んでおり、
上記ＥＣＰＶ署名を検証することによって、上記部分を復号化して、上記ゲーム機によって用いることができる、方法。
【請求項４９】
デバイスによって用いられるデータの機密保護を行う方法であって、
当該データの複数の要素のそれぞれに署名して、可視部分と隠された部分とを有する複数のＥＣＰＶ署名を生成する工程を含んでおり、
上記可視部分は、上記データの上記各要素であり、
上記隠された部分は、回復される時に、次の署名における各値を回復するために用いられる値であり、
上記複数の要素の最後の要素において上記各署名から回復された最終値を、上記複数の要素の第１の要素から上記各値を回復するために用いられた入力値と比較して、上記データを認証することができる、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デバイスに記憶されたデータを認証する（authenticating）システムおよび方法に関し、本発明は特に、そのようなコンテンツを実行時間（run time）に認証する際のユーティリティを有する。
【背景技術】
【０００２】
ソフトウェアプログラムを実行する、および／または、様々なタイプのマルチメディアコンテンツを受信、再生および／または配信する、パーソナルコンピュータ（ＰＣ）ベースのデバイスを開発、製造（manufacture）、および販売する企業は、デバイスの使用中のみならずデバイスの全ライフサイクルを通じて、重大なセキュリティ問題に直面する場合がある。これは、デバイスの物理的制限によるものであり、および／または、ブート時やウェイクアップ時などにおいて用いられるパスワードの強化をユーザに強制できないことによる。
【０００３】
これらのデバイスは、多くの場合、専門家または素人の様々な攻撃者からハッキングされ易い消費者市場へ向かうことになる。企業は、一般的にはセキュリティに高く配慮しているが、十分なセキュリティと利便性およびコスト要件とのバランスを保つことが困難である場合がある。例えば、使用中における、ユーザには見えない高いセキュリティ対策によって、利便性に支障がもたらされる場合がある。また、製造段階における高いセキュリティ対策（例えば、全製造を社内で行うこと）は、製品を生産する（produce）コスト全体に悪影響を及ぼす場合がある。
【０００４】
一般的に、セキュリティに最大の配慮をするべきデバイスの一生には３つの段階がある。これらはすなわち、ｉ）製造プロセス、ｉｉ）デバイス所有者によるデバイスの通常動作、ｉｉｉ）技術者によるデバイスの保守整備および修理である。デバイスのユーザは、当該デバイスが処理するコンテンツ（例えば、衛星ラジオプレーヤーによって再生される音楽ファイル）の所有者では必ずしもないことに留意されたい。
【０００５】
デバイスの生産は、１つ以上のサードパーティによって行われることが多い。例えば、ある企業によって設計されたマザーボード／マイクロプロセッサモジュールは、サードパーティであるサプライヤーによって製造および事前プログラミングされる。このマザーボードを用いて生産された完成品は、上記企業の施設またはさらに別のサードパーティである請負業者の施設においてアセンブリされる場合がある。通常は、最終テスト前のこのアセンブリプロセスにおいて、オペレーティングシステム、ソフトウェアアプリケーション、およびコンフィギュレーションデータが、デバイス内にプログラムされる。そして、上記アセンブリプロセスは、クローニングその他のセキュリティ侵害を受け易い。
【０００６】
特に注意が必要なデータは、製造後、デバイス使用中において、コンテンツのセキュリティポリシーを実行するために用いられるコンテンツのセキュリティミドルウェア（例えば、デジタル著作権管理（ＤＲＭ））である。セキュリティミドルウェアおよびデバイス自身は、常に攻撃を受け易いが、特にデバイスの製造中、配備されているが電源がオフである間、および博識な技術者によって補修サービスを受けている間に攻撃を受け易い。コンテンツのセキュリティミドルウェアは、多くの場合、このような時に変更または改変され、その結果、コンテンツを保護する防衛手段が巧みに回避され易く、これによってデバイスのコンテンツおよび／またはソフトウェアアプリケーションがセキュリティの危機に曝される。
【０００７】
一部のセキュリティ手段およびアプリケーションは、デバイスをそのブート中に保護し、ユーザ認証およびディスク暗号化を行う。しかしこれらの手段は、認証プロセスの所定の時点におけるユーザとの対話に依存するため、通常は上述のアプリケーションには適していない。さらに、これらセキュリティ手段の多くはスマートカードの使用を必要とするか、あるいはこれに依存している。しかしスマートカードを内蔵させることは、企業のコスト負担が非常に高くなる場合が多い。このように、前述したように、セキュリティと利便性という２つの目的が対立する。量産される家庭用電子デバイスにおいて成功する重要な要素は、使い易さである。これらデバイスの供給元は、デバイス内に採用するセキュリティ対策をユーザに見えなくすることを所望している。
【０００８】
実施の問題（implementation issue）は、今日に至るまで企業の懸念事項の１つである。ブート中にデバイスを保護し、ファイルシステムを暗号化し、またＤＲＭポリシーエンジンを実施することによって、デバイスおよび当該デバイスが使用するコンテンツを保護することが知られている。しかし従来の技術は、デバイス、ＢＩＯＳ、Ｏ／Ｓカーネル、Ｏ／Ｓ、ドライバ、およびアプリケーション層の複数の層において共存および相互運用する必要のある、複数の複雑なソフトウェア層の使用に依存している場合が多い。複数の層における動作は、実施が困難である場合があり、デバイスが誤作動する可能性が高くなり、また追加的なコードが大量に必要となる場合がある。さらに、これらのセキュリティ対策を用いる企業にとって、単一のデバイスが危険にさらされても、システム全体が不具合による影響を受けにくいことが最重要である。
【０００９】
これらの不利な点は、特にゲーム産業において一般的である。スロットマシンなどのゲーム機は、ゲームの実行、勝者の決定、および支払いの制御を行うためのハードウェアおよびソフトウェアを備えている。このようなソフトウェアおよびハードウェアは攻撃を受け易く、これによって、攻撃者に有利に動作するようにソフトウェアまたはハードウェアが交換または変更される。従って、機器の正真性（integrity）を維持し、その動作を保護することが重要である。
【００１０】
従って以下は、上記不利な点を回避または緩和することを目的としている。
【発明の概要】
【００１１】
デバイス内のコンテンツの機密保護を行い（securing）、当該コンテンツを実行時間において認証するシステムおよび方法が提供される。
【００１２】
一形態では、デバイスによって用いられるコンテンツの機密保護を行う方法であって、暗号化されたイメージを、キーを用いて復号化（decrypt）することによって上記コンテンツの少なくとも一部分を回復できるように、当該部分を暗号化することによって、上記暗号化されたイメージを準備する工程と、上記デバイスに特有の情報を用いて第１の署名要素から上記キーを回復できるように、上記第１の署名要素内の上記キーを暗号化する工程と、上記デバイスが、上記デバイスに特有の情報を用いて上記第１の署名要素から上記キーを回復して、上記部分を復号化できるように、上記第１の署名要素を含む署名を上記デバイスに対し使用できるようにする工程とを含んでいる、方法が提供される。
【００１３】
別の形態では、デバイスによって用いられるコンテンツを認証する方法であって、第１の署名要素から回復可能なキーが暗号化された第１の署名要素を含んだ署名を取得する工程と、上記デバイスに特有の情報を取得する工程と、上記デバイスに特有の上記情報を用いて、上記第１の署名要素から上記キーを回復する工程と、上記キーを用いて、上記コンテンツの少なくとも一部分の暗号化されたイメージを復号化して、当該部分を回復する工程とを含んでおり、上記部分が上記デバイス上において動作可能である場合には、上記コンテンツは暗黙的に（implicitly）認証される、方法が提供される。
【００１４】
さらに別の形態では、デバイスによって用いられるコンテンツの機密保護を行う方法であって、上記コンテンツにおける平文の第１の部分および上記コンテンツにおける平文の第２の部分を指定する工程と、上記平文の第１の部分を暗号化して、暗号化された第１の部分を生成する工程と、上記暗号化された第１の部分および上記平文の第２の部分を上記デバイスに記憶する工程と、上記暗号化された第１の部分と上記平文の第２の部分とを要素として含む署名であって、上記デバイスが上記平文の第１の部分を用いることを可能にするために上記暗号化された第１の部分から上記平文の第１の部分を回復するために用いることのできる署名を生成する工程とを含んでいる、方法が提供される。
【００１５】
さらに別の形態では、デバイスによって用いられるコンテンツを認証する方法であって、上記コンテンツにおける暗号化された第１の部分と上記コンテンツにおける平文の第２の部分とを要素として含む署名を取得する工程と、上記署名を用いて、上記暗号化された第１の部分から平文の第１の部分を回復する工程と、上記署名から回復された上記平文の第１の部分に従って上記コンテンツを認証する工程とを含んでいる、方法が提供される。
【００１６】
さらに別の形態では、デバイスによって用いられるコンテンツの機密保護を行う方法であって、上記コンテンツにおける複数の部分を指定する工程と、上記デバイスに第１の値を記憶する工程と、上記第１の値を用いて回復できるような第２の値を暗号化する要素を含む第１の署名を、上記コンテンツの第１の部分に生成する工程と、上記第２の値を用いて回復できるような第３の値を暗号化する要素を含む第２の署名を、上記コンテンツの第２の部分に生成する工程と、上記部分が３つ以上の場合、次の部分によって用いられる次の値を、前の部分の署名から回復された前の値を用いて回復できるように、上記次の値を暗号化する要素をそれぞれ含む他の署名を生成する工程とを含んでおり、上記第１の値を用いて、上記第１の署名から上記第２の値を回復することができ、上記第２の値を用いて、上記第２の署名から上記第３の値を回復することができ、必要であれば、上記前の値を用いて上記次の値を回復可能であり、その結果、上記部分の最後において各署名から回復された最終値を上記第１の値と比較して、上記複数の部分を同時に認証することができる、方法が提供される。
【００１７】
さらに別の形態では、デバイスによって用いられるコンテンツを認証する方法であって、上記デバイスに記憶された第１の値を取得する工程と、上記コンテンツの複数の部分のうち第１の部分における第１の署名であって、第２の値を暗号化する要素を含んでいる第１の署名を取得する工程と、上記第１の値を用いて上記第２の値を回復する工程と、上記コンテンツの上記複数の部分のうち第２の部分における第２の署名であって、第３の値を暗号化する要素を含んでいる第２の署名を取得する工程と、上記第１の署名から回復された上記第２の値を用いて上記第３の値を回復する工程と、上記部分が３つ以上の場合、次の値を暗号化する要素をそれぞれ含む他の署名を取得して、前の部分の署名から回復された前の値を用いて上記次の値を回復する工程と、上記複数の部分のうち最後の部分における署名から回復された最終値を上記第１の値と比較して、上記複数の部分の全てを同時に認証する工程とを含んでいる、方法が提供される。
【００１８】
さらに別の形態では、デバイスによって用いられるコンテンツに関して新しいモジュールをダウンロードする方法であって、上記コンテンツの要素に関してエントリモジュールの署名を取得する工程、上記要素は、署名をそれぞれ含む複数のモジュールを含んでおり、上記複数のモジュールの１つは、上記エントリモジュールであり、上記複数のモジュールの１つは、エンドモジュールであり、上記エントリモジュールの上記署名は、上記デバイスに記憶されている値を用いて回復できるような中間値を暗号化する署名要素を含んでおり、上記エンドモジュールの上記署名は、上記中間値を用いて回復できるような次の値を暗号化する署名要素を含んでおり、上記エントリモジュールおよびエンドモジュールに加えて３つ以上のモジュールが存在している場合、上記要素の他のモジュールが有する署名は、前のモジュールの各署名から回復された上記中間値を用いて回復できるような上記中間値を暗号化する署名要素を含んでおり；上記エントリモジュールの上記署名から上記中間値を回復する工程；上記新しいモジュールの署名を取得する工程、上記新しいモジュールの上記署名は、上記中間値を用いて回復できるような上記中間値を暗号化する署名要素を含んでおり；上記エントリモジュールの上記署名から回復された上記中間値を用いて、上記新しいモジュールの上記署名から上記中間値を回復する工程；上記エンドモジュールの上記署名を取得し、上記新しいモジュールの上記署名から回復された上記中間値を用いて上記次の値を取得する工程；上記次の値を鍵付きハッシュ（hash）関数のためのキーとして用い、当該鍵付きハッシュ関数を上記コンテンツの別の要素に適用して認証コードを取得する工程；および上記認証コードと、上記別の要素において先に生成されて記憶された認証コードとを比較して、上記新しいモジュールおよび上記コンテンツを認証する工程を含んでいる、方法が提供される。
【００１９】
さらに別の形態では、ゲーム機上のデータの機密保護を行う方法であって、上記データの一部分を暗号化する工程と、上記ゲーム機にＥＣＰＶ署名を記憶する工程とを含んでおり、上記ＥＣＰＶ署名を検証（verification）することによって、上記部分を復号化して、上記ゲーム機によって用いることができる、方法が提供される。
【００２０】
さらに別の形態では、デバイスによって用いられるデータの機密保護を行う方法であって、当該データの複数の要素のそれぞれに署名して、可視部分と隠された部分とを有する複数のＥＣＰＶ署名を生成する工程を含んでおり、上記可視部分は、上記データの上記各要素であり、上記隠された部分は、回復される時に、次の署名における各値を回復するために用いられる値であり、上記複数の要素の最後の要素において上記各署名から回復された最終値を、上記複数の要素の第１の要素から上記各値を回復するために用いられた入力値と比較して、上記データを認証することができる、方法が提供される。
【００２１】
これらの方法は、デバイスがゲーム機である場合に特に適している。
【００２２】
本発明の一実施形態について、添付図面のみを参照しながら例として説明する。添付図面は以下の通りである。
【図面の簡単な説明】
【００２３】
【図１】保護されたハードウェアボードを含んだゲーム機の斜視図である。
【図２】図１のハードウェアボードを含んだセキュアバインディングシステムの概略図である。
【図３】セキュアバインディング手順を示すフロー図である。
【図４】ＢＩＯＳのロード手順を示すフロー図である。
【図５】楕円曲線ピンストフ−バンストーン署名方式を用いたセキュアブート信任証の生成を示すフロー図である。
【図６】楕円曲線ピンストフ−バンストーン署名方式を用いたセキュアブート信任証の検証を示すフロー図である。
【図７】ユーザ認証手順を示すフロー図である。
【図８】ユーザＰＩＮ入力プロセスを示すフロー図である。
【図９ａ】バインドされていないハードウェアボードの概略ブロック図である。
【図９ｂ】バインドされたハードウェアボードの概略ブロック図である。
【図１０】保守技術者の認証手順を示すフロー図である。
【図１１】セキュアソフトウェアアップグレードプロセスを示すフロー図である。
【図１２】セキュアブート認証プロセスを示すフロー図である。
【図１３】認証されたゲーム装置のシステムレイアウトの概略ブロック図である。
【図１４】楕円曲線ピンストフ−バンストーン署名方式を用いた図１３のハードディスクの検証を示すフロー図である。
【図１５】認証されたゲーム装置の別のシステムレイアウトの概略ブロック図である。
【図１６】認証されたゲーム装置のさらに別のシステムレイアウトの概略ブロック図である。
【図１７】図１３の実施形態における楕円曲線ピンストフ−バンストーン署名の生成を示す概略図である。
【図１８】保護されたハードウェアボードと、ゲームファイルをダウンロードするためのネットワーク接続とを有するゲーム機の概略図である。
【図１９】連鎖的な署名検証手順を示す、図１８のハードウェアボードの概略図である。
【図２０】新しいゲームファイルをダウンロードする際の検証手順を示す、図１９のハードウェアボードの概略図である。
【図２１】（ａ）〜（ｃ）は、図１９のゲームコンポーネントモジュールのための署名生成を示すフロー図である。
【図２２】図１９の権限モジュール（jurisdiction module）に対する署名生成を示すフロー図である。
【図２３】（ａ）〜（ｃ）は、図１９のプラットフォームコンポーネントモジュールに対する署名生成を示すフロー図である。
【図２４】ゲームコンポーネントモジュールに対する署名検証を示すフロー図である。
【図２５】権限コンポーネントモジュールに対する署名検証、および鍵付きハッシュを検証するための権限コンポーネントモジュールからの出力の使用を示すフロー図である。
【図２６】プラットフォームコンポーネントモジュールに対する署名検証を示すフロー図である。
【図２７】新しくダウンロードされたゲームファイルに対する署名検証を示すフロー図である。
【図２８】任意のファイルシステムに対する連鎖的な署名検証手順を示すフロー図である。
【発明の詳細な説明】
【００２４】
図１を参照すると、ゲーム機１０は、アプリケーション１５を用いたゲームプレイを表示するディスプレイ１１を有している。ゲーム機１０はまた、表示内容に応じてゲームプレイと対話するための入力部１３を有している。ハードウェア（Ｈ／Ｗ）ボード１２は、入力部１３を用いたユーザとの対話に従って、ディスプレイ１１上のゲームプレイを制御する。
【００２５】
価値あるコンテンツ（例えばＨ／Ｗボード１２上のゲームコード）は、これを保護するために、特定のＨ／Ｗボード１２に製造時においてバインドされる（bound）。
【００２６】
バインドされていないＨ／Ｗボード１２は、図９ａに示されている。Ｈ／Ｗボード１２は、基本入出力システム（ＢＩＯＳ）１４を有している。ＢＩＯＳ１４は、バインドされていないバージョンのカスタマイズされたＢＩＯＳコード（ＵＢＩ）１６で最初にフラッシュされる（flashed）。これは、任意のコードを実行するために用いられるバインドされていないボードの、特に修理中における盗難を防ぐためである。Ｈ／Ｗボード１２は、プリブートバインディングアプリケーション（pre-boot binding application；ＰＢＢＡ）の事前計算されたハッシュ（ＰＢＢＡＨ）を領域１７内に記憶する。ＰＢＢＡは、ハードディスクドライブ（ＨＤＤ）２０のプリブート区域（section）２３内に事前に記憶されている。図９ａの破線は、バインディングプロセス中に再書き込みされるＨ／Ｗボード１２の部分を示している。これについては、以下に詳しく説明する。
【００２７】
ＨＤＤ２０は、３つの基本的な区域に分割される。これらはすなわち、プリブート区域２３、アプリケーション区画（partition）２７（例えばＣドライブ）、およびデータ区画３４（例えばＤドライブ）である。データ区画３４は、データを記憶するためのデータ部分３６を有している。プリブート区域２３は、領域２５内にＰＢＢＡを記憶する。ＰＢＢＡは、Ｈ／Ｗボード１２のバインディングを行う。アプリケーション区画２７は、Ｈ／Ｗテスト用オペレーティングシステム（ＯＳ）およびシステムファイル２８と、Ｈ／Ｗテスト用アプリケーション３２とを記憶する。また、ＨＤＤ２０は、平文のマスターブートレコード（ＭＢＲ）２２を有している。ＭＢＲ２２は、標準的ではないことが好ましく、この場合、ＨＤＤ２０がいかなる標準的なＰＣプラットフォームにおいても標準的なＢＩＯＳイメージ１４を用いて実行することを防止する。ＭＢＲ２２は、変更の無い区画テーブル２１を有している。これは、通常、ＨＤＤ２０からテーブル２１を読み出す際に、上記テーブル２１が認識可能な形式にあることを上記ＯＳが要求するためである。このため、区画テーブル２１は暗号化されていない。ＭＢＲ２２内に位置するブートローダ（図示せず）は、区画テーブル２１を読み出して、ＨＤＤ２０内における第１のブート可能な位置にジャンプする。ブートローダは、標準的なＢＩＯＳイメージ１４によって実行されることを防止するように改変することもできる。
【００２８】
これら３つの区域が分離していることによって、バインディング動作を迅速に行うのに役立つ。これは、ＨＤＤ２０上において区域２３および２７が必要とする空間がデータ区画３４よりも遥かに小さいため、区域２３および２７のイメージ生成が、ＨＤＤ２０全体のイメージ生成よりも一般的に速いためである。また、区域２３、２７、および３４が分離していることによって、データ回復動作を簡略化するのに役立つ。これは、アプリケーション区画２７内においてデータ３６とアプリケーション３２とが混ざるおそれなく、データ区画３４からデータを直接的に抽出することができるためである。
【００２９】
図９ｂには、バインドされたＨ／Ｗボード１２が示されている。図９ｂにおいて改変されている構成要素には、図９ａと同様の参照番号で、末尾に「ａ」を付している。バインディングプロセス後、Ｈ／Ｗボード１２は、バインドされたＢＩＯＳイメージ（ＢＢＩ）１４ａおよび十分に保護されたＨＤＤ２０ａを含んでいる。
【００３０】
バインドされたＨＤＤ２０ａは、図９ａと同様に暗号化されていないＭＢＲ２２および区画テーブル２１を有しており、また、暗号化されたプリブート区域２３ａを有している。暗号化されたプリブート区域２３ａは、暗号化されたセキュアブート認証子（ＳＢＡ）、楕円曲線公開キー（ＥＣＰＫ）、およびイメージキーファイル（ＩＫＦ）を有している。暗号化されたＳＢＡは、それが見つかる場所を、カスタマイズされたＢＩＯＳコード１６ａが分かるように、全システム上の既知（および固定）の位置に記憶されていることが好ましい。ＥＣＰＫおよびＩＫＦを用いて、ＳＢＡがＢＩＯＳ信任証を検証してＯＳを実行する。ＩＫＦは、セキュアブートプロセス中に回復されるイメージキー（ＩＫ）を格納するファイルである。上記セキュアブートプロセスについては後述する。また、ＨＤＤ２０ａは、既知の固定位置２５ａに回復ＰＢＢＡ（recovery PBBA）コードを記憶する、暗号化されていないプリブート区域２３ｂを有している。ＲＰＢＢＡは、システムが、バインドされたＨＤＤイメージ２４ａを新しいハードウェアボードに再バインドさせることを可能にする平文のコードである。ＲＰＢＢＡは、システムを危険に曝し得るいかなる機密情報も含んでいないため、保護する必要はない。
【００３１】
アプリケーション区画２７ａは、Ｈ／Ｗボード１２がバインドされる際に暗号化される。また、アプリケーション区画２７ａは、ＯＳおよびシステムファイル２８ａ、アプリケーション３２ａ、および領域３１を含んでいる。領域３１は、ユーザが入力した個人識別番号（ＰＩＮ）を妥当性検証する（validate）ために用いられる、ログオンエージェント（ＬＡ）およびユーザブートＰＩＮマスク（ＵＢＰＭ）を含んでいる。一実施形態では、ＬＡは、ＧＩＮＡＣと称される。これは、カスタマイズされたバージョンの既存のグラフィカルな識別・認証ＤＬＬ（ＧＩＮＡ）である。アプリケーション区画２７ａは、全体が、ＩＫによって暗号化されている。
【００３２】
データ区画３６は、例えばデジタル著作権管理（ＤＲＭ）などの別の仕組みによって既に保護されている場合には暗号化する必要はなく、平文であってよい点について理解されるであろう。しかし本実施例では、ＭＢＲ２２およびプリブート区域２３ｂのみが平文であるように、フルディスク暗号化が用いられている。
【００３３】
ＢＢＩ１４ａは、バインドされたバージョンのカスタマイズされたＢＩＯＳコード１６ａを有しており、また領域１７ａは、ＰＢＢＡＨに加えて多数の項目を有するように改変されている。これらの追加的な項目には、本実施形態の製造段階においてＢＩＯＳイメージ１４のファームウェアイメージに追加されるセキュアブート信任証（secure boot credentials、ＳＢＣｓ）と称される一意の認証信任証と、ＳＢＡを暗号化および復号化するために用いられるセキュアブート認証子暗号キー（ＳＢＡＫ）と、ＳＢＡ（ＳＢＡＨ）のハッシュと、ＲＰＢＢＡ（ＲＰＢＢＡＨ）のハッシュとが含まれる。
【００３４】
イメージ２４ａは、製造プロセス中にＳＢＣを、好ましくはＢＩＯＳファームウェアイメージに追加することによって、Ｈ／Ｗボード１２上のＢＩＯＳイメージ１４ａその他のハードウェアコンポーネントに暗号的にバインドされる。実用的な見地から、破損その他の機能障害が発生したＨ／Ｗボード１２の機密保護を行う必要はないため、ハードウェアテスト後にバインディングが行われることが望ましい。
【００３５】
図２に示されているように、Ｈ／Ｗボード１２は、好ましくはテスト用ジグ（testing jig）に存在する間に、複数のコンポーネント同士の相互作用を用いてバインドされる。バインディングは、ハードウェアバインディング装置（ＨＢＭ）５０によって直接行われる。ＨＢＭ５０は、ユニバーサルシリアルバス（ＵＳＢ）接続５２を介してＨ／Ｗボード１２に直接接続されることが好ましい。バインディングプロセスは、セキュアネットワーク接続６２を介してＨＢＭ５０と通信するキー注入システム（key injection system）（ＫＩＳ）７０を用いて間接的に行われる。
【００３６】
ＫＩＳ７０は、別のセキュアネットワーク接続７６を介してサーバー７４に接続されたコントローラ７２と、ＨＢＭ５０上のハードウェアバインディングアプリケーション（ＨＢＡ）内に包含されるキーエージェントソフトウェア７５とを有している。キーエージェント（ＫＡ）７５は、ＨＢＭ５０とサーバー７４とのセキュア接続６２を確立する。
【００３７】
ハードウェアバインディングアプリケーション（ＨＢＡ）５２は、バインディング動作を行い、またＫＡ７５を用いてコントローラ７２とのセキュア接続６２を確立する。通常、ＨＢＭ５０は、ディスプレイ５４を有している。ディスプレイ５４は、ユーザが例えばラップトップコンピュータを用いてＨＢＭ５０を操作することができるように、アプリケーションプログラムインターフェース（ＡＰＩ）５６を提供する。実用的な見地からして、バインディング手順中には、ＣＰＵに負担のかかる他のアプリケーションを実行しない方が有利である。また、ＨＢＭ５０は、イメージ２４の暗号化されたコピー５３をデータ記憶装置５５に記憶する。一実施形態では、イメージ２４は、サーバー７４のみが知るキーによって暗号化されている。ＨＢＡ５２は、サーバー７４にセキュア接続された時に上記キーを取得し、そしてイメージ２４をＨ／Ｗボード１２へ送信する前に再暗号化する。また、ＨＢＭ５０は、バインディング動作の結果をサーバー７４へ戻す機能を担っており、これによってサーバー７４は口グデータをコントローラへ戻すことができる。ＨＢＭは、製造業者がバインディング手順を行うために用いられるものと、技術者がＨ／Ｗボード１２を修理およびアップグレードするために用いるものとの２つのタイプが存在することが好ましい。サーバー７４と各製造業者とが共有するキーは同一であることが好ましく、またそれぞれの技術者が異なるキーを用いることが好ましい。
【００３８】
ＫＩＳ７０は、デバイスの登録を遠隔監視し、一意かつ不変の情報の上記デバイス内への注入を測定する（meter）ために用いられるシステムである。ＫＩＳ７０については、２００６年６月１２日に出願された米国特許出願第１１／４５０,４１８号に完全に記載されている。この引用によって、当該特許文献の内容は、本明細書に記載加入される。本実施例では、コントローラ７２は、製造業者／テストの施設から離れて位置するコンピュータシステムであり、好ましくは上記デバイスを生産する企業内に配置されている。サーバー７４は、Ｈ／Ｗボード１２の製造、テスト、およびバインドを生産業者（producer）が委託した外部の製造業者に配置されている。上記生産業者は、ゲーム機１０を生産および販売しているが、少なくともＨ／Ｗモジュールの製造をサードパーティに委託しているゲーム会社であってもよい。
【００３９】
サーバー７４およびＨＢＭ５０は、同様の位置に配置されていてもいなくてもよい。サーバー７４およびＨＢＭ５０が物理的に同様の位置に配置されている場合は、ローカルネットワークにおいてセキュア接続６２が確立される。以下により詳しく説明するが、ＨＢＭ５０は、バインディングプロセスのためのみに用いられるのではなく、技術者が修理、保全、およびアップグレードを行うためにも用いられる。このため、ＨＢＭ５０はＨ／Ｗボード１２に接続される一方で、Ｈ／Ｗボード１２は例えばカジノなどに配置されたゲーム機１０内に配置されてもよい。従って、サーバー７４およびＨＢＭ５０の相対的な物理位置は、セキュア接続６２が確立されていてＨＢＭ５０とサーバー７４とが通信できる範囲において変更可能である。
【００４０】
コントローラ７２は、ハードウェアセキュリティモジュール（ＨＳＭ）７８を含んでいる。ＨＳＭ７８は、保護されたデバイスであり、コントローラ７２が暗号によるセキュリティ動作（例えば暗号化、復号化、および署名）を行うのに用いられる。１セットのシステムセキュリティベクトル（ＳＳＶ）が、データ記憶装置８３に記憶されている。各ＳＳＶは、バインドされた各Ｈ／Ｗボード１２に特有である１セットの値を含んでいる。この１セットの値は、ＳＳＶ識別子（ＳＳＶＩＤ）、マスターブートＰＩＮ（ＭＢＰ）、初期ユーザＰＩＮ（ＩＵＰ）、特定のボード１２に対するイメージキー（ＩＫ）、システムロック解除コード（ＳＵＣ）、およびＳＢＡＫを含んでいる。ＳＳＶＩＤを除く全ての値は、無作為に生成される。ＳＳＶＩＤは、ＳＳＶを識別するために用いられる整数値であり、コントローラ７２によって生成される各ＳＳＶに対して１づつ増えることが好ましい。ＭＢＰは、ユーザがＰＩＮを忘れた時にモジュールにアクセスするために用いられるＰＩＮである。ＩＵＰは、パスコード保護（ＰＣＰ）（あるいはその他のユーザパスワード認証方式）が出荷前に有効にされている場合には、ユーザが初めてシステムに電源を入れた時に入力するＰＩＮである。ＰＣＰが無効にされている場合、ユーザは新しいＰＩＮを入力するように求められるため、ＩＵＰは冗長である。これについては、以下により詳しく説明する。前述したように、ＩＫはイメージ２４ａを保護するために用いられ、ＳＵＣはＩＫ自体を保護するために用いられ、そしてＳＢＡＫは、ＢＩＯＳ１４ａがＳＢＡプロセスを保護するために用いられるキーである。
【００４１】
ＳＳＶのブロックは、必要に応じて、コントローラ７２によって事前計算され、そしてサーバー７４に安全に（securely）送信される。サーバー７４は、十分な（コンフィギュレーション可能な）数のＳＳＶをキャッシュに格納して、自身が生産工程中にコントローラ７２と通信しなくてもよいように、また、自身が係属中の出願第１１／４５０,４１８号に記載されている原理に従った工程中にデータを切らすことのないようにする。コントローラ７２は、周期的にサーバー７４をポーリングして、そのＳＳＶのキャッシュが低いか否かを判断し、そして必要に応じて自動的にキャッシュを補給することができる。コントローラ７２はまた、サーバー７４から、バインディングプロセスに関するログ情報を収集することができる。コントローラ７２は、グラフィカルユーザインターフェース（ＧＵＩ）８１をさらに含んでおり、これによってユーザはコントローラ７２と対話することができる。
【００４２】
一実施形態では、コントローラ７２は、ＨＳＭおよびセキュアファームウェアを含んだＰＣベースのサーバーマシン上において継続的に実行する、Ｗｉｎ３２ベースのウィンドウズ（登録商標）サービスである。セキュア接続７６において成された要求は、ＧＵＩ８１がアパッチトムキャットジャバサーブレットＧＵＩであるセキュアソケット接続（ＳＳＬ）を用いて確立することができる。上記インターフェースによって、サーバー７４からログデータを遠視することができ、またオペレータがＫＩＳ７０内のコンフィギュレーション設定を設定することができる。コントローラ７２はまた、キーイングデータを、後に（またはすぐに）サーバー７４へ送るためにデータベース８３内にロードできることが好ましい。
【００４３】
サーバー７４は、ＨＳＭ８４を含んでいる。ＨＳＭ８４は、ＭＢＰサーバー７４が、所定の時間においてキャッシュに格納した楕円曲線個人キー（ＥＣＰＲＫ）８０および対応する楕円曲線公開キー（ＥＣＰＵＫ）８２の数を決定するクレジットプール（credit pool）８６を記憶する。サーバー７４は、ＳＳＶのキャッシュをデータ記憶装置８８内に記憶する。一実施形態では、サーバー７４は、ＨＳＭ８４およびセキュアファームウェアを含んだＰＣベースのサーバーマシン上において継続的に実行する、リナックスベースのデーモンアプリケーションである。サーバー７４は、コントローラ７２からＳＳＬ要求を受信してキーイングデータを受信し、また、キーエージェント７５から要求を受信して、デバイスへの書き込みのためにキーイングデータを安全に送る。サーバー７４は、システムへの不正アクセスを防止するアクセス制御手段（例えばパスワードまたはＰＩＮコード）を含んでいるが、システムが一旦配置されると最小限のオペレータ対話を必要とする。サーバー７４は、２つのタイプの要求を処理する。これらはすなわち、１）両タイプのＨＢＭからの、キャッシュ８８からの新しいＳＳＶの復号化要求、および２）技術者ＨＢＭからの、コントローラのデータベース８３からの古いＳＶＶの検索要求である。
【００４４】
図３には、バインディングプロセスにおける工程を示すフロー図である。前述のように、コントローラ７２は、サーバー７４およびＳＳＶのトップアップ（top-up）と共に生産前ポーリングを行って、サーバー７４がその特定の実行に対して十分な数量のＳＳＶを確実に持つようにする。コントローラ７４はまた、生産後ログ検索を行って、バインディングプロセスに関する情報を収集する。ＫＩＳ７０によって用いられるログレポート手順は、係属中の出願第１１／４５０,４１８号に詳細に記載されている。
【００４５】
Ｈ／Ｗテストプロセス後、Ｈ／Ｗボードはまず、工程１においてＨ／Ｗ情報を収集することが好ましい。当該情報は、イメージ２４が、それが初期的にインストールされているハードウェア上においてのみ実行するように、プリブート認証プロセスを特定のハードウェアにさらにバインドするために用いられる。これは、模倣またはクローニングされたＨ／Ｗにおいて正規のイメージ２４が実行されること、あるいはこの逆の状況を防止するのに役立つ。Ｈ／Ｗ情報は、例えばＨＤＤシリアルナンバー、Ｈ／Ｗボードシリアルナンバー、ネットワークインターフェースカード（ＮＩＣ）のメディアアクセス制御（ＭＡＣ）アドレス、ＢＩＯＳシリアルナンバー等、ハードウェア固有の検証可能な識別子の任意の組み合わせを含んでいてよい。Ｈ／Ｗ情報は、本明細書ではＨＷＳＮと総称される。Ｈ／Ｗ情報は、任意の適切な方法で組み合わせて、および／または、互いに関連付けて、ＨＷＳＮを生成することができる。例えば、識別子を連結させて、得られる値をハッシュすることによって、ＨＷＳＮを生成することができる。
【００４６】
工程２では、Ｈ／Ｗボード１２が、ＵＳＢ接続５２（あるいは、専用クロスオーバーイーサネット（登録商標）（ＣＯＥ）接続など他の直接接続インターフェース）を介してＨＢＭ５０に接続し、Ｈ／Ｗ情報をＨＢＭ５０へ送信する。工程３において、ＨＢＡ５２が、キーエージェント７５（例えばＳＳＬ）を用いてサーバー７４とのセキュア接続６２を確立し、そして工程４において、Ｈ／Ｗ情報と共に信任証要求をサーバー７４へ送信する。工程５では、サーバー７４が多数の値を生成し、工程６において、これらの値が接続６２を介してＨＢＡ５２へ戻される。
【００４７】
工程５では、サーバー７４がまず、キャッシュ８８からＳＳＶを検索する。当該ＳＳＶからＭＢＰが取得され、そしてサーバー７４がＭＢＰのハッシュを計算して、マスターブートピンハッシュ（ＭＢＰＨ）を生成する。サーバー７４はさらに、上記ＳＳＶからＩＵＰを取得して、ＩＵＰのマスク（ＩＵＰＭ）を計算する。サーバー７４はさらに、ＳＳＶから回復されたＨＷＳＮおよびＳＵＣを用いてＳＢＣを計算する。図５を参照すると、ＳＵＣは、サーバーによって用いられて、バインディングプロセス下にある特定のＨ／Ｗボード１２に対してＳＢＣを計算する。サーバーのＨＳＭ８４では、楕円曲線ピンストフ−バンストーン署名（Elliptic Curve Pinstov-Vanstone Signature、ＥＣＰＶＳ）の署名関数に、ＳＵＣ、個人キーＥＣＰＲＫ、およびハードウェア情報ＨＷＳＮが入力される。
【００４８】
変換Ｔを用いた個人キーＥＣＰＲＫによってＳＵＣを暗号化することによって、第１の署名要素ｅが計算される。当該第１の署名要素ｅ、サーバー７４の識別、およびＨＷＳＮをハッシュすることによって、中間署名要素ｄが計算される。そして、上記dを用いて第２の署名要素ｓが計算される。ＳＢＣに対応した、要素（ｅ、ｓ、ＨＷＳＮ）を有するＥＣＰＶＳ署名が生成される。
【００４９】
工程６では、ＳＢＣ、ＳＵＣ、ＩＫ、ＳＢＡＫ、ＭＢＰＨ、およびＩＵＰＭが、接続６２を介してＨＢＡ５２へ送信され、そして工程７において、サーバー７４およびキーエージェント７５同士の接続が遮断される。工程８では、ＨＢＡ５２はまず、イメージ２４の記憶されたコピー５３を取得および復号化し、そして、サーバー７４によって事前に供給されたキーを用いてＳＢＡのコピーを取得および復号化する。次にＨＢＡ５２は、ＩＫを用いてイメージ２４（およびＭＢＰＨ並びにＩＵＰＭ）を再暗号化し、そしてＳＢＡＫを用いてＳＢＡを再暗号化する。次にＨＢＡ５２は、暗号化されたＳＢＡおよび暗号化されたイメージ２４のイメージ２４ａを生成する。最後にＨＢＡ５２は、新たに生成されたＳＢＣおよびＳＢＡＫを含んだＢＢＩ１６ａを生成する。工程９において、ＨＢＭ５０は、暗号化されたイメージ２４ａおよびＢＢＩ１４ａをＨ／Ｗボード１２へ送信する。工程１０において、Ｈ／Ｗボード１２上にて既に実行しているＰＢＢＡが、ＢＩＯＳ１４をＢＢＩ１４ａでフラッシュし、イメージ２４ａをＨＤＤ２０へ直接書き込む。最後に、ＥＣＰＵＫがＳＢＡコードでコンパイルされ、従ってＳＢＡコードの一部となる。
【００５０】
工程１１では、ＰＢＢＡ２６が、バインディング状態メッセージをＨＢＭ５０へ戻し、そして工程１２において、ＨＢＭ５０およびＨ／Ｗボード１２同士の接続が遮断される。工程１３において、ＨＢＭ５０は、キーエージェント７５を用いてサーバー７４との接続を再確立し、そして工程１４において、バインディング動作（例えばＳＳＶＩＤを含む）に関するログレポートを準備してサーバー７４へ送信する。工程１５では、サーバー７４が、好ましくは後の時点（すなわち生産後）において、コントローラ７２にレポートするために上記ログレポートを記憶する。工程１６ではでは、サーバー７４およびキーエージェント７５同士の接続が遮断される。コントローラ７２はデータベース８３と通信して、サーバー７４に送信された全てのＳＳＶを記憶する。ログレポートがサーバー７４から（例えばポーリングによって）検索されると、上記レポートからＳＳＶＩＤが回復されて、ログデータがデータベース８３内の特定のＳＳＶに再び関連付けられる。また、これらのログは、監査の目的で必要と考えられる他の情報（例えば、要求において提供されるＨＷＳＮ、および工程５において生成されるＳＢＣ）を含むように構成することもできる。
【００５１】
上述のバインディング手順では、Ｈ／Ｗボード１２上の様々な部分から特定の情報が収集および使用されているため、全ての要素がアッセンブルされた後にバインディングが行われることが好ましいことについて留意されたい。さらに、ＢＩＯＳ１４は、Ｈ／Ｗボード１２が装着される前かつハードウェアテストが行われる前に、標準的なバインドされていないＢＩＯＳイメージ（ＵＢＩ）を用いてプログラムされることが好ましい。
【００５２】
バインドされていないＨ／Ｗボードがブートされると、ＵＢＩは、自身がバインドされていないものと認識し、ＨＤＤの公知の位置からＰＢＢＡコードの実行を試みる。ＵＢＩ１４はまず、（バインドされている場合は）ＰＢＢＡコードを含むＨＤＤの公知の部分のハッシュを計算し、そしてこれをＢＩＯＳ内に記憶されているＰＢＢＡＨと比較する。上記ハッシュが適合しない場合、ＵＢＩはＰＢＢＡの実行を許可しない。
【００５３】
図４を参照すると、通常の電源投入時セルフテスト（ＰＯＳＴ）後に、工程１００においてセキュアブート手順が開始される。工程１０１において、ＢＢＩコード１６ａは、暗号化されたプリブートセクター２３ａを始点としてＨＤＤ２０の最初のＮブロック（ここでＮは、{ＰＢＢＡ、ＥＳＢＡ}の最小バイトサイズ）のハッシュを計算する。工程１０１において計算されたハッシュは、工程１０２において、領域１７ａ内に記憶されているＰＢＢＡＨと比較される。記憶されているＰＢＢＡＨと上記ハッシュとが等しい場合、ＢＢＩ１４ａは、バインディングが行われるべきであると判定する。すわなちＢＢＩ１４ａは、ＨＤＤイメージ２４がＰＢＢＡのイメージ２４であると判定し、工程１０３においてＰＢＢＡを実行する。上記ハッシュがＰＢＢＡＨと適合しない場合、ＢＢＩ１４ａは、工程１０４において、上記ハッシュと領域１７ａ内に記憶されているＳＢＡＨとが適合するか否かを判定する。上記ハッシュがＳＢＡＨと等しい場合、システムはバインドされる。そして工程１０５において、領域１７ａ内に記憶されているＳＢＡＫを用いてＳＢＡが復号化され、工程１０６において、ＳＢＡが実行される。上記ハッシュがＰＢＢＡＨまたはＳＢＡＨのいずれにも適合しない場合、ＢＢＩ１４ａは、工程１０７において、公知の位置２５ａ内においてＲＰＢＢＡを探し、そして上記区域のハッシュを計算する。工程１０８において、こハッシュが、領域１７ａ内に記憶されているＲＰＢＢＡＨと適合した場合、ＢＢＩ１４ａは、工程１０９においてＲＰＢＢＡコードを実行する。これらいずれのハッシュも適合しない場合は、工程１１０においてシステムは停止する。
【００５４】
工程１０６は、図６により詳しく示されている。工程１１１では、ＳＢＡがＢＢＩ１４ａからブートされる。そして工程１１２において、ＳＢＡが公開キーＥＣＰＵＫ８２を検索し、そしてＨＷＳＮおよびＳＢＣを集める。工程１１３においてＳＢＣが発見されない場合は、工程１１４においてシステムは停止する。ＳＢＣが発見された場合は、ＳＢＡは工程１１５においてＨ／Ｗボード１２の妥当性検証を試みて、ＳＵＣを回復する。
【００５５】
図６を参照すると、ＳＢＡは、ＥＣＰＶＳ検証関数を用いて、まず署名要素（ＳＢＣを含む）とＨＷＳＮとを組み合わせることによってＨ／Ｗボード１２を妥当性検証し、中間値Ｘを生成する。次に、上記検証関数は、公開キーＥＣＰＵＫ８２を用いて、ＸからＳＵＣを回復する。これが失敗した場合、工程１１４においてシステムは停止する。ＳＵＣが回復された場合、ＳＵＣを用いてＩＫのロックがＩＫＦから解除される。工程１１６において、イメージ２４ａが正常に復号化されると、工程１１８においてＯＳがブートし、従ってＨ／Ｗボード１２が検証されたことになる。ＩＫは、工程１１７においてメモリ内に配置される。工程１１６における復号化が失敗した場合、すなわち、得られたイメージが使用不可能である場合、工程１１４においてシステムはシャットダウンする。従って、ハードウェアがオリジナル（original）ではあるが、ＢＩＯＳ１４がスワップされており、ハードウェアにバインドされていない信任証が用いられる場合、ＳＢＡは、イメージ２４ａを適切に復号化することができない。同じことが、ハードウェアがスワップされているがＢＩＯＳはスワップされていない場合にも当てはまる。なぜなら、正確なＳＵＣを取得してＩＫのロックを解除するために適切なＨＷＳＮが必要とされるためである。
【００５６】
イメージ２４ａは、ＯＳ低レベルディスクアクセスルーチンにおいて、暗号インターフェース層（crypto interface layer）内に挿入されたイメージ暗号化／復号化ドライバ（ＩＥＤＤ）を用いて、暗号化および復号化される。ＩＥＤＤは、イメージ２４を暗号化によって保護するために、強い対称キーアルゴリズム（例えば、１２８ビットＡＥＳ規格）を用いる。ＩＥＤＤは、ＩＫがメモリ内に記憶されている間にアクセスする。
【００５７】
図７を参照すると、工程２００および工程２０２において、ＯＳ２８は、ブート時に自身の認証手順に移行し、ＬＡを用いて（例えばＧＩＮＡＣを実行することによって）、システムのオペレータの識別および認証を行う。通常、識別および認証を強いるメカニズムは、winlogon.exeまたはminlogon.exe（winlogon.exeaの必要最小限バージョン）のいずれかであり、ＯＳのコンフィギュレーションに依存する。ＬＡのwinlogon.exeバージョンは、前述したようにＧＩＮＡ  ＤＬＬを置き換え、前述したようにＧＩＮＡＣを取得することによって、カスタマイズされることができる。しかし、minlogon.exeが用いられる場合、これはＧＩＮＡ  ＤＬＬを含んでいないので、システムの設計は、シェルが実行される場合、あるいはＬＡが回避されないことが確実な他の適切な場合においてＬＡが直ちに実行されるように行われる必要がある。
【００５８】
工程２０２においてＬＡが初期化された後、ＬＡは、工程２１４において、ＰＣＰが有効であるか否かを判定する。ＰＣＰが有効ではない場合、工程２１８においてユーザはログオンされ、システムはログオン状態に入る。しかし、ゲーム機１０のＰＣＰが有効である場合、工程１１６において、ＬＡは、所定の時間内（例えば１５分以内）にゲーム機１０から電源が除去されたかどうかを判定する。所定の時間内に電源が遮断されなかった場合、ユーザログオン状態２１８が開始される。所定の時間内に電源が遮断された場合、工程２２０においてユーザＰＩＮ入力プロセスが開始される。ログオン時あるいはユーザがログオンしている間、工程２２２において、ＭＢＰを入力することによってＰＩＮを変更することができる。工程２１８におけるユーザモードの間中、工程２２４において、ユーザがＰＣＰを任意時に有効または無効にすることができ、あるいは工程２１２において、システムはシャットダウンする。
【００５９】
ユーザ認証におけるＰＣＰ方式の使用は、典型的な一方式にすぎないことについて理解されるであろう。例えば、標準的なユーザパスワードまたはチャレンジレスポンスを用いることもできる。これにより、自身のユーザ名およびパスワードをそれぞれ有する複数のユーザが認証されて、システムにＬＡを介して入ることも可能である。
【００６０】
工程２２０において行われるユーザＰＩＮ入力は、図８により詳しく示されている。工程２２０の開始後、工程３００において、ユーザはＰＩＮの入力を要求される。ＰＩＮが割り当てられると、次式が満たされるようにユーザブートＰＩＮマスク（ＵＢＰＭ）が記憶される。
【００６１】
【数１】
2009544084.tif 000003
記憶されたＵＢＰＭを用いて、入力されたＰＩＮの排他的論理和をとる（XOR）際に、得られるＭＢＰがハッシュされ、そしてバインディング中にサーバー７４から受信して記憶されたＭＢＰＨ値と比較される。ユーザが工程２２２においてＰＩＮを変更すると、初期のＭＢＰを変更する必要がないようにＵＢＰＭが変更される。
【００６２】
ＵＢＰＭ３１は、コントローラ７２からＳＳＶ内に送信されたＩＵＰＭから得られる。ＩＵＰは、ユーザがゲーム機１０を購入した際にユーザに伝えられる。ユーザがゲーム機１０を実行する際、割り当てられたＰＩＮを変更する際、あるいはＰＣＰを無効にする際には、ＰＩＮを入力しなければならないようにするため、ゲーム機１０の電源が投入された際にＰＣＰが有効にされる初期設定となっていることが好ましい。ユーザが工程２２４においてＰＣＰを無効にすると、ゲーム機１０は、ユーザが工程２２０へ進んで、前述したように工程２１８においてユーザモードに入るように要求しない。
【００６３】
工程３０４においてＰＩＮが正確であった場合、ユーザはユーザログ状態２１８に入る。ＰＩＮが不正確であった場合、工程３０６において失敗カウンタが１増加し、これが一回目の失敗であったか否かをＰＣＰが判定する。これが一回目の失敗であった場合、工程３１０においてタイマー（例えば３時間タイマー）が始動し、ユーザがＰＩＮ入力を試みるための限られたウィンドウ（limited window）が提供される。これが一回目の失敗ではなかった場合、これが５回目の失敗であったか否かをＰＣＰが判定する。これが５回目の失敗でではなかった場合、ユーザは割り当てられた時間内にＰＩＮを再び入力することができる。これが５回目の失敗であった場合、ユーザは、工程３１４の間中、タイマーが切れるまで再びＰＩＮを入力することができない。これによって、工程３１６において失敗カウンタがリセットされ、そして工程３００に戻る。
【００６４】
ユーザログ状態が開始され、そして工程２０８においてサービスモード選択が成されると、好ましくはこれと同時に、工程２１０において技術者チャレンジレスポンス手順が開始される。技術者がゲーム機１０を操作している時、技術者ＨＢＭ５０ａがＵＳＢ接続５２ａを介してＨ／Ｗボード１２に接続される。Ｈ／Ｗボードは、チャレンジレスポンスクライアント（ＣＲＣ）９２を有している。ＣＲＣ９２は、サーバー７４においてチャレンジレスポンスサーバー（ＣＲＳ）９０と共にチャレンジレスポンス手順を制御するために用いられる。
【００６５】
技術者が動作ユニット（例えばゲーム機１０）内のメニュー項目を選択し、サービスモードに入ることが好ましい。当該モードが選択されると、ＬＡはチャレンジレスポンスを開始する。これについては、以下に例証する。
【００６６】
図１０に示されている実施例では、ＬＡがまず、工程１において、乱数を用いてチャレンジ（ＣＨＡＬ）を生成する。次にＬＡは、（例えばウェブページを介して）サーバー７４においてＣＲＳ９０とセキュア接続６２ａを確立した後に、工程２においてＣＨＡＬおよびシステム識別子（ＳＩＮ）をＣＲＳ９０へ送信し、そして工程３においてＣＨＡＬおよびＳＩＮを送信する。ＣＲＳ９０は、ＣＨＡＬ、ＳＩＮ、および個人キーＥＣＰＲＫをＥＣＰＶＳ署名関数へ入力して、応答値ＲＥＳＰを取得する。応答値ＲＥＳＰは、技術者へ供給される。応答は、工程４において、個人キーＥＣＰＲＫを用いてＣＨＡＬを暗号化することによって第１の署名要素を計算し、第１の要素、サーバーの識別、およびＳＩＮの組み合わせをハッシュすることによって中間的な署名要素を計算し、そして当該中間的な署名要素を用いることによって第２の署名要素を計算することによって、生成される。上記２つの要素およびＳＩＮは、応答ＲＥＳＰとして用いられる署名である。
【００６７】
工程５において、ＣＲＳ９０はＲＥＳＰをＣＲＣ９２へ送信し（例えばディスプレイに対して）、そして工程６において、サーバー７４はＣＲＣ９２から遮断される。次に工程７において、ＬＡはＲＥＳＰを検証する。ＣＲＣ９２とＣＲＳ９０との接続は、技術者が既にＨ／Ｗボード１２に接続している場合は、ＨＢＭ５０を用いて行うこともできることについて理解されるであろう。
【００６８】
ＬＡは、ＥＣＰＶＳ検証関数を用いて、第１の署名要素とＳＩＮとを組み合わせて値Ｘを取得する。次に、ＳＢＡから検索された公開キーＥＣＰＵＫを用いて、ＣＨＡＬがＸから回復される。次に、ＬＡは、回復されたＣＨＡＬと、ＣＨＡＬがサーバー７４のみによって署名されたことを検証するために最初に生成したものとを比較する。チャレンジレスポンスが検証すると、システムは、工程２１０においてサービスが完了するまでサービスモードに入り、そして工程２１２においてシステムはシャットダウンする。
【００６９】
技術者がＨ／Ｗボード１２にアクセスしなければならない状況は、複数考えられる。１つ目としては、ＨＤＤが破損したために、交換する必要がある状況が考えられる。この場合、技術者は、ＢＩＯＳを、前述のバインディングプロセスが行われる前に存在していた標準的かつバインドされていないＢＩＯＳイメージにプログラムし直す。技術者は、標準的な製品イメージを有する新しいＨＤＤをボードに設置する。システムは、リブートされると、ＨＢＭ５０に接触して暗号化によるバインディングを試みる。このために、ＨＢＭ５０はサーバー７４と通信する。ＨＢＭアプリケーションは、この通信を確立する同一のデバイス（例えばキーエージェント７５またはＨＢＡ５２）上に存在することができる。バインディングが正常に完了すると、システムは、新しい信任証および新たに暗号化されたイメージ２４を有する。あるいは、技術者は、システムを、プリバインドされたＨ／ＷボードとＨＤＤとの対と交換することもできる。
【００７０】
別の状況としては、ＢＩＯＳ１４が破損したために、Ｈ／Ｗボード１２を交換しなければならない可能性が高いという状況が考えられる。上記状況と同様、技術者がＨ／Ｗボード１２を交換してユーザのＨＤＤ２０を挿入した場合は、セキュアブート認証プロセスは、ＳＢＣを見つけてバインディングプロセスに入ることができないため、ハードウェアはバインドされていないものと見なす。
【００７１】
さらに別の状況として、Ｈ／Ｗボード１２およびＨＤＤ２０が両方とも破損したため、ユーザが完全に新しいシステムを要求するという状況が考えられる。技術者は、サーバー７４に接続できる場合は、新しいＨ／ＷボードおよびＨＤＤを設置し、第１の状況において述べたバインディング手順を用いることができる。技術者がサーバー７４に接続できないために、オンサイトでバインディング動作を行うことができない場合は、上述の状況と同様に、プリバインドされたＨ／Ｗボード１２およびＨＤＤ２０を設置することができる。プリバインドされたシステムの不正使用を阻止するために、ユーザＰＩＮは保守技術者には知らされない。新しいシステムに最初に電源が投入された際、技術者は（前述の）サービスモードに入り、バインドシステムにテストを行わなければならない。その後、ユーザが製造業者または生産業者から新しいＰＩＮを取得し、ゲーム機１０を認証および操作する。
【００７２】
さらに別の状況としては、イメージ２４内のソフトウェアが何らかの形で破損した状況が考えられる。保守技術者は、ソフトウェアを修理するためにＨ／Ｗボード１２にアクセスしなければならない場合、サービスモードに入る。当該サービスモードは、技術者が様々なソフトウェア回復または再インストールアプリケーションを実行するためのツールキットを提供する。ＯＳ２８またはアプリケーションソフトウェア３２が、サービスモードを用いて修理可能な範囲を超えて破損した場合、技術者は、上記工程を行って、破損したＨＤＤ２０を交換することができる。あるいは、技術者は、上述したように、Ｈ／Ｗボード１２とＨＤＤ２０との両方を、プリバインドされた対と交換することもできる。
【００７３】
チャレンジレスポンスを実行するために特定の技術者を認証することは、製造業者または生産業者のネットワーク内に当該技術者をログするために用いられる認証手順によって制御することができる。また、例えばＣＲＳ９０に権限付与機能（enabling feature）を与えるなど、他のメカニズムを用いて、特定のシステムがサービスを受けることができるようにすることもできる。例えば、ゲーム機１０の所有者は、任意の適切な方法で生産業者に接触し、ゲーム機１０にサービスを施すように要求することができる。オペレータは、ユーザデータベース内にフラグを設定することによって、その特定のゲーム機１０（または、ゲーム機のシステム）に対するサービスをオーソライズする（authorize）。後に技術者が生産業者のネットワークにログオンしてＣＲＳ９０に接続すると、ＣＲＳ９０は、サーバー７４にコンタクトして、ユーザデータベース内のＳＩＮを参照し、そのサービスがオーソライズされていることを検証する。そして技術者は、チャレンジレスポンスを開始する。
【００７４】
Ｈ／Ｗボード１２は、ある時点において、セキュアソフトウェアアップグレードを行う必要がある。ソフトウェアアップグレードセキュリティは、ファイルポイントシステムを用いて行うことができる。図１１を参照すると、製品（例えばゲーム機１０）上に配置されたファイルポイントクライアント（ＦＰＣ）９６は、工程１において、既存のアプリケーションバイナリを用いて暗号要求を生成し、そして工程２において、当該暗号要求を、サーバー７４に配置されたファイルポイントサーバー（ＦＰＳ）９４へ送信する。このようにゲーム機１０は、図１１に示されているように、技術者に依頼することなく、（例えば周期的な時間間隔で）ソフトウェアアップグレードを要求することができる。ＦＰＳ９４は、工程３において、旧バージョンの全てのアプリケーションバイナリのデータベース９５を検索し、そして工程４において、技術者がどのバージョンのアプリケーションをアップグレードするのか、および当該技術者がアップグレード実施をオーソライズされているのかを検証する。ＦＰＳ９４は、工程５においてセッション暗号キーを取得し、工程６においてアップグレードバイナリを暗号化し、そして工程７において暗号化されたアップグレードをＦＰＣ９６に戻す。ＦＰＣ９６はさらに、工程８においてセッションキーを取得し、そして工程９においてアップグレードを復号化する。これらの工程を行うために用いられるアルゴリズムは、工程１０において、有効なアプリケーションバイナリを用いたＦＰＣ要求のみが上記キーを取得して、アップグレードのロードを行うことができるように設計されている。
【００７５】
具体的な一実施例では、ファイルポイントシステムは、独自のキー構築アルゴリズム（key establishment algorithm）を用いて、トランジット中にアプリケーションバイナリを保護する。ＦＰＣ９６は、アップグレードを要求すると、アップグレードされるオブジェクト（ＯＵ）内のデータを用いて、短期キー（ＥＫ）を生成する。そしてＦＰＣ９６は、ＯＵ、システムＩＤ、およびＥＫに関する情報を含んだデータグラムを要求する。このデータは、ＦＰＳ９４に送信される。ＦＰＳ９４は、ＳＩＤを用いてＦＰＣ９６の識別を参照および検証し、（また場合によっては、システムがアップグレードの実施をオーソライズされていることを妥当性検証し）、そしてシステムのＳＢＣのハッシュを取得する。そしてＦＰＳ９４は、要求内のＯＵ情報を用いて、そのアップグレードオブジェクトデータベース９５内のＯＵのバージョンを調べる。次にＦＰＳ９４は、妥当性検証として、セキュアブート信任証のハッシュ（ＳＢＣＨ）を用いてＥＫを生成して、ＥＫのＥＣＰＶＳ署名を計算し、そしてそれを応答データグラムとしてＦＰＣ９６へ戻す。
【００７６】
次にＦＰＳ９４は、２つのＥＫからセッションキー（ＳＫ）を取得し、このＳＫを用いてアップグレードオブジェクト（ＵＯ）を暗号化する。次にＦＰＳ９４は、暗号化されたＵＯをＦＰＣ９６へ送信する。ＦＰＣ９６は、応答データグラムを受信すると、そのＳＢＣ１８のハッシュを計算し、ＥＣＰＵＫおよびＳＢＣＨを用いてＥＣＰＶＳ署名を検証する。そして、ＦＰＳ９４を認証し、ＦＰＳのＥＫを回復する。次にＦＰＣ９６は、２つのＥＫからＳＫを取得し、これを用いてＵＯを復号化する。
【００７７】
署名生成は、ＥＣＰＶＳを用いて以下のように行うことができる：
【００７８】
【数２】
2009544084.tif 000004
応答は、ＥＣＰＶＳを用いて以下のように検証される：
【００７９】
【数３】
2009544084.tif 000005
【００８０】
一実施例では、ＡＰＩ５６は、単一の関数呼び出しFPC_getUpgrade（sid、appID、curVerID、appFilename、fpsIPAddr、timeout）を含んでいる。ここで、Sidはシステム識別子であり、appIDはアプリケーション識別子であり、curVerIDはアプリケーションの現在のバージョン識別子であり、appFilenameはアプリケーションバイナリのファイル名であり、fpsIPAddrはＦＰＳ９４のＩＰアドレスであり、timeoutはサーバー７４からの応答を待つ時間の長さである。この関数は、まず暗号による要求データグラムを構成し、そしてＦＰＳ９４に接続して要求を送る。次に上記関数は、指定されたタイムアウト時間、応答を待つ。上記関数は、応答が受信されると応答データグラムを妥当性検証し、そして前述したように、新しいアプリケーションバイナリを復号化および記憶する。
【００８１】
同じ実施例では、サーバーＡＰＩ（図示せず）は、単一の関数呼び出しFPS_waitUpgradeRequest（dbAddr、portNo）を含んでいる。ここで、dbAddrは、アップグレードデータベース９５にコンタクトするためのアドレス識別子である。サーバー７４は、あらゆるＦＰＣ９６からのソケット接続要求に対して、ポート番号であるポート識別子への要求を待つ。要求が受信されると、上記関数はデータベース９５にコンタクトして、応答データグラムを生成するために必要な情報を取得し、アップグレードされるバイナリイメージを暗号化する。次に、ＦＰＳ９４は、応答データグラムおよび暗号化されたイメージを呼び出しＦＰＣ９６に送り戻す。これが完了すると、ＦＰＳ９４は通信ログを生成する。
【００８２】
標準的なプラットフォームは、オープンかつ比較的安全ではない特徴を有しているため、上述したシステムのセキュリティは、ＢＩＯＳ１４とＨＤＤ２０との暗号識別を分離することによって維持される。以下では、システムが受ける可能性のある攻撃、および、そのような攻撃を阻止するためにシステムによって行われる効果的なセキュリティについて説明する。
【００８３】
１つの攻撃としては、攻撃者が、セキュアブート処理を阻止するために自身のＢＩＯＳをＨ／Ｗボード１２へフラッシュしようと試みるものがある。この攻撃は、セキュアブート処理に必要なＳＢＣが再フラッシングによって破壊されるため、防止することができる。攻撃者は、イメージキー（ＳＵＣ）を復号化することができないため、イメージ２４を復号化することができない。
【００８４】
別の攻撃としては、攻撃者がＨＤＤを取り外し、そして総当たり暗号解読（例えば、既知平文、選択平文、適応的選択平文、適応的選択暗号文、関連キー等）によって、暗号化されたイメージを回収しようと試みる攻撃がある。このような攻撃は、適切な暗号強度を有する、規格に基づいた強力な暗号化アルゴリズム（例えばＡＥＳ）を用いることによって回避することができるため、実行不可能である。例えば、分散型コンピュータネットワークを用いた場合、８０ビットＡＥＳキーに対する総当たり攻撃には何年（約１０年）もかかり、また上記キーの長さにビット数を追加することによって、上記年数は指数関数的に長くなる。ゲーム環境では、攻撃者がこのような種類の攻撃を実行するのは明らかに不可能である。
【００８５】
従って、ＢＩＯＳ内に記憶されている信任証にハードウェア固有のデータをバインドし、そしてＥＣＰＶＳ署名生成および検証を用いることによって、イメージ２４ａの暗黙的な検証（implicit verification）を行うことができる。さらに、ＫＩＳ７０を用いることによって、特別なＨＢＭと共に鍵データ（keying data）（例えばＳＳＶ）の配信および計測を行うことができる。製造中に、ＫＩＳ７０を用いてＨ／Ｗボード１２をバインディングすることによって、不正または不正に近い市場活動を阻止することができ、またゲーム機１０にロードされるコンテンツがサードパーティである受託業者に侵害されることはない。同様に、修理中にＨＢＭを用いることによって、技術者による不正変更からイメージ２４ａを保護することができる。
【００８６】
図１３〜図１７に示されているさらに別の実施形態では、ゲーム機１０において用いられるゲーム装置４００が、一回限りプログラム可能な（ＯＴＰ）読み出し専用メモリ（ＲＯＭ）ＢＩＯＳ４０２を用いて認証される。ＢＩＯＳ４０２は、性質的に改変不可能（すなわち「読み出し専用」）であるため信頼される。本実施形態では、性質的に改変可能であるフラッシュＢＩＯＳの代わってＢＩＯＳ４０２が用いられる。
【００８７】
まず図１３を参照すると、ゲーム装置４００は、一般的に、ＯＴＰ  ＲＯＭ  ＢＩＯＳ４０２、ハードディスク４０４、およびシステムランダムアクセスメモリ（ＲＡＭ）４０６を含んでいる。ＢＩＯＳ４０２は、ブート動作中にＲＡＭ４０６にロードされるシステム初期化モジュール４０８と、ハードディスク４０４のコンテンツのＥＣＰＶ検証または認証を行うために用いられるＥＣＰＶ認証子モジュール４１０とを記憶する。ＥＣＰＶ認証子モジュール４１０は、ＥＣＰＶ検証中に用いられる、ＥＣＰＶ公開キー４１２およびＥＣＰＶ署名要素を記憶する。
【００８８】
ハードディスク４０４は、オペレーティングシステム４１６をセットアップするブートローダ４１４を含んでいる。オペレーティングシステム４１６は、アプリケーション４１８をロードおよび実行する。本実施例では、アプリケーション４１８は、ゲーム機１０においてユーザによって実行、表示、およびプレイされるゲームデータである。図１３に示されているように、本実施形態では、ブートローダ４１４およびオペレーティングシステム（Ｏ／Ｓ）４１６は、ハードディスク４０４上において暗号化されており、アプリケーション４１８は、平文であり、すなわち「クリア状態である（in the clear）」、他には復号化されている、あるいは暗号化されていない。
【００８９】
ＥＣＰＶ認証モジュール４１０は、アプリケーション４１８の実行の前に、アプリケーション４１８およびＯ／Ｓ４１６を同時に妥当性検証するためにブートアップ動作において実行される。検証は、ＥＣＰＶ署名検証の原理に基づいて行われる。
【００９０】
図１４を参照すると、以下の頭字語が用いられている：
ＰｕｂＫｅｙ＝ＥＣＰＶ公開キー４１２
ＰＡＣ＝平文のアプリケーションコード（例えば、アプリケーション４１８）
ＥＢＬＣ＝暗号化されたブートローダコード（例えば、ブートローダ４１４）
ＥＯＳＣ＝暗号化されたオペレーティングシステムコード（例えば、Ｏ／Ｓ４１６）
ＰＢＬＣ＝平文のブートローダコード（例えば、復号化されたブートローダ４１４’）
ＰＯＳＣ＝平文のオペレーションシステムコード（例えば、復号化されたＯ／Ｓ４１６’）
【００９１】
本実施例では、ＥＣＰＶ署名は、要素（ＥＢＬＣ＋ＥＯＳＣ、s、ＰＡＣ）を含んでいる。ここで、ＰＡＣは可視部分（例えば平文のアプリケーション４１８）であり、ＥＢＬＣ＋ＥＯＳＣは署名要素ｅであり、sは他のＥＣＰＶ署名要素である。当該署名要素は、ＥＣＰＶ公開キー４１２と共に、ＥＣＰＶ認証モジュール４１０によってＥＣＰＶ検証関数４２０へ入力される。上記署名要素ｅよびsは、（例えば前述したバインディングまたは製造プロセス中に）ＥＣＰＶの原理に従って計算され、そして不変のＢＩＯＳ４０２に必要な要素が書き込まれる。
【００９２】
例えば、図１７に示されているように、全く暗号化されていない処理のハードディスク４０４は、可視部分Ｖと隠された部分Ｈとに分割することができる。可視部分Ｖはアプリケーション４１８を含んでおり、隠された部分Ｈは、暗号化されていないブートローダ４１４’、暗号化されていないＯ／Ｓ４１６’、および（必要であれば付加される）一定量の冗長を含んでいる。この場合、冗長は、隠された部分Ｈを構成する、暗号化されていないブートローダ４１４’および／またはＯ／Ｓ４１６’に付加される。冗長量は、実行時間中に、後に支払い検証を行うためにゲーム当局（gaming authority）によって保存される必要がある。これについては、以下により詳しく説明する。
【００９３】
隠された部分Ｈは、ＰｕｂＫｅｙを用いて暗号化されて、ＥＢＬＣ＋ＥＯＳＣと等しい署名要素ｅが生成される。ＰｕｂＫｅｙは、署名エンティティ（図示せず）によって計算された乱数ｋから生成される。署名エンティティはまた、図１７に示されているように署名個人キーを有している。要素ｅは、可視部分Ｖ（ＰＡＣと等しい）と連結され、そしてハッシュされて、中間的な要素ｄを生成する。そして、これら中間的な要素ｄ、個人キーａ、および乱数ｋを用いて、署名要素ｓが計算される。署名要素ｓは、ＥＣＰＶ公開キー４１２と共に認証子モジュール４１０に書き込むことができ、あるいはハードディスク４０４上の適切な位置に記憶させることができる。得られる署名は、（ｅ、ｓ、Ｖ）であるか、あるいは本実施例では（ＥＢＬＣ＋ＥＯＳＣ、s、ＰＡＣ）と等しい。
【００９４】
図１４を再度参照すると、ＥＣＰＶ検証関数４２０は、例えば連結によって、署名要素ｅ（例えばＥＢＬＣ＋ＥＯＳＣ）と可視部分Ｖ（例えばＰＡＣ）とを組み合わせることによって、中間的な要素ｄの表現（representation）ｄ’を計算する。そして、まずＸ＝ｓＰ（ここで、Ｐは楕円曲線上における点）を計算し、次にＹ＝ｅ  ＰｕｂＫｅｙを計算し、最後にＸからＹを引くことによって復号化キーＺが得られる。そして、復号化キーＺを用いて、ＥＢＬＣ＋ＥＯＳＣからＰＢＬＣ＋ＰＯＳＣを復号化する。
【００９５】
ブートアップ手順中に、まず、システム初期化モジュール４０８がシステムＲＡＭ４０６内にロードされて実行される。システム初期化モジュール４０８は、パワーオンセルフテスト（ＰＯＳＴ）を実行するが、ＢＩＯＳ４０２が不変であるため自己正真性チェックを行う必要はない。そして、システム初期化モジュール４０８は、ＥＣＰＶ認証子モジュール４１０をロードして実行する。認証子モジュール４１０は、その内部に記憶されているＥＣＰＶ公開キー４１２および署名要素にアクセスし、暗号化されたブートローダ４１４、暗号化されたＯＳ４１６（ＥＢＬＣ＋ＥＯＳＣ）、およびシステムＲＡＭ４０６内に一時的に記憶された平文のアプリケーション４１８のコピーを取得し、これらをＥＣＰＶ検証関数４００内に入力する。前述および図１７に示されているように、ＥＣＰＶ検証プロセスは、平文のブートローダ４１４’（ＰＢＬＣ）および平文のＯＳ４１６’（ＰＯＳＣ）を回復する。ＰＢＬＣおよびＰＯＳＣはシステムＲＡＭ４０６内にロードされ、そして実行はＰＢＬＣに移される。ＰＢＬＣはＰＯＳＣを実行し、ＰＯＳＣは、ＥＣＰＶ検証中に既にシステムＲＡＭ４０６内にロードされたアプリケーション４１８をロードおよび実行する。
【００９６】
ＰＡＣはＥＣＰＶ検証に用いられるため、アプリケーション４１８は、例えばコード追加等により改ざんされた場合には、不正確なブートローダ４１４’および／またはＯＳ４１６’が回復されるため正常に実行しない。従って、ブートアップにおける認証は暗黙的である。
【００９７】
実行時間においてコードを検証して、例えばゲーム装置４００からの払い出しを検証する際に、アプリケーションコード４１８、および（ブートアップ手順から既にシステムＲＡＭ４０６内に記憶されている）ＥＢＬＣ並びにＥＯＳＣを用いて別のＥＣＰＶ検証が行われる。払い出しを検証するために、装置４００にゲーム当局が呼び出されて、そして周辺機器（図示せず）が例えばＵＳＢ接続（図示せず）によって接続される。周辺機器は、ゲーム当局の監視下にあるという利点によって信頼すべきである。アプリケーションコード４１８、ＥＢＬＣ、ＥＯＳＣ、ＰｕｂＫｅｙ、および署名要素は、周辺機器に記憶されたＥＣＰＶ検証関数４２０と、隠された部分Ｈである回復された平文のＰＢＬＣ＋ＰＯＳＣとに入力される。前述したように、Ｈは特定量の冗長（例えば、所定数のゼロ）を有しているか、あるいは特定量の冗長（例えば、所定数のゼロ）が与えられている。周辺機器は、Ｈの冗長をチェックし、それが期待された冗長と適合した場合には、アプリケーションコード４１８は改ざんされていないため検証されない。
【００９８】
ゲーム機１０からの払い出しを検証するために、実行時間コードが検証された場合に、現金またはクレジットがゲーム当局によって払われる。実行時間検証によって、ゲーム当局は、払い出しを信号で示したアプリケーションコード（ＰＡＣ）が、ブートアップ手順と払い出しとの間において改ざんされなかったことを確信することができる。ブートアップ手順は、主に、ゲーム機の電源が切られている間に改ざんされなかったことを検証するために用いられる。ブートアップ検証は暗黙的であるため、いかなる改ざんによっても、正常に実行しない不正なコードが生じることがない。
【００９９】
図１５〜図１６を参照すると、別のシステムレイアウトが用いられている。
【０１００】
図１５に示されている第１の別の実施形態では、ブートローダ４１４のみが暗号化されており、Ｏ／Ｓ４１６’およびアプリケーション４１８は平文である。本実施形態では、隠された部分ＨはＰＢＬＣであり、可視部分はＰＡＣ＋ＰＯＳＣであり、ＥＣＰＶ署名は、ＨおよびＶに対して別の値を入力する間に、前述の原理を用いて計算された（ＥＢＬＣ、s、ＰＡＣ＋ＰＯＳＣ）である。従ってＥＣＰＶ検証は、実行時間における検証時にブートローダ４１４’の冗長をチェックし、そしてブートアップにおいて暗黙的に検証する。図１５に示されている実施形態は、ブートローダ４１４がＯ／Ｓ４１６’よりも小さいソフトウェア部分であるため、復号化およびメモリ要件を簡略化する。
【０１０１】
次に図１６を参照すると、アプリケーション４１８は（メモリの空き容量に比べて）比較的小さい。アプリケーション４１８は暗号化され、そして暗号化されたアプリケーション４１８’はハードディスク４０４に記憶される。本実施形態では、アプリケーション４１８の平文のバージョンは隠された部分Ｈであり、ここで署名要素ｅは暗号化されたアプリケーションＥＣとなる。可視部分は平文のブートローダＰＢＬＣおよび平文のＯＳ  ＰＯＳＣとなり、ＥＣＰＶ署名は（ＥＡＣ、ｓ、ＰＢＬＣ＋ＰＯＳＣ）となる。従ってＥＣＰＶ検証は、実行時間における検証時に平文のアプリケーション４１８の冗長をチェックし、ブートアップにおいて暗黙的に検証する。アプリケーションコード４１８を暗号化することによって、ＥＣＰＶ公開キー４１２が保護される場合であればアプリケーションコード４１８’の盗難に対していくらかの保護を与えることができる。攻撃者は、ハードディスク４０４を盗難できたとしても、ＥＣＰＶ公開キー４１２の知識を有していないのであれば、平文のアプリケーションコード４１８を回復することはできない。
【０１０２】
従って、図１３〜図１７に示されている実施形態は、ＥＣＰＶ署名検証を用いて、Ｏ／Ｓ４１６とアプリケーションコード４１８との両方を同時に検証することができることが分かる。不変のＯＴＰ  ＲＯＭ  ＢＩＯＳ４０２は、改変不可能であるため信用することができる。従って、ブートアップにおいてＢＩＯＳ４０２を検証する必要はなく、Ｏ／Ｓ４１６およびアプリケーション４１８の認証に直接進むことができる。ＥＣＰＶ署名検証を用いて、ブートアップ手順および実行時間との両方を検証して、例えば払い出しを検証することができる。このような検証を用いて、ゲーム機４００の電源が切られている間およびその実行中にアプリケーションコード４１８が改ざんされなかったことによってゲーム当局を満足させることができる。
【０１０３】
図１８〜図２７には、ゲーム機２００を認証するさらに別の実施形態が示されている。ゲーム機２００は、これまで説明した実施形態と同様に、ディスプレイ２０２および入力機構２０４を含んでいる。これらによって、プレーヤーはゲーム機２００と対話し、またゲーム機２００にロードされた１つ以上のゲームをプレイすることができる。ゲーム機２００はまた、保護されたハードウェアボード（Ｈ／Ｗ）２０６を含んでいる。本実施形態では、ハードウェアボード２０６は、データ接続２０８によってネットワーク２１０に接続されている。これによってゲーム機２００は、新しいゲームファイル２１２をダウンロードすることができる（あるいは新しいゲームファイル２１２にアップロードすることができる）。ネットワーク２１０は、ゲーム機２００の場所に応じて、内部またはローカルネットワークであってよく、あるいはインターネットなどの外部ネットワークであってよいことについて理解されるであろう。例えば、ゲーム機２００がカジノにある場合、同一のローカルネットワーク２１０に複数の装置が接続され、ゲームコンテンツの配信およびゲーム機の監視などを制御するサーバー（図示せず）を有する可能性がある。別の実施例では、ゲーム機２００は、公共場所に配置されたスタンドアロンユニットであり、ネットワーク接続によって外部エンティティまたはサーバー（図示せず）に接続する。
【０１０４】
図１８に示されているハードウェアボード２０６は、ＢＩＯＳ  ＯＴＰ  ＲＯＭ２１４と、装置２００の動作中にデータを記憶する、および／または、必要に応じて永続記憶するメモリ２１６と、ゲームファイル２１２を実行するゲームコンポーネント２１８と、権限関連のデータ（例えば、ゲーム規則および配当など）を記憶する権限コンポーネント２２０と、プラットフォームまたはＯＳ要素２２２（すなわち、ゲーム機２００によって用いられるコンテンツ部分）とを有している。
【０１０５】
次に図１９を参照すると、ハードウェアボード２０６の要素がより詳しく示されている。ＲＯＭ２１４は、（前述と同様の）システム初期化モジュール２２４と、ゲーム機２００をブートアップする検証エージェント２２６と、連鎖的な署名検証手順を開始するために用いられる入力値（本実施例では、公開キーＫＰＵＢ−Ａ）とを含んでいる。値ＫＰＵＢ−Ａは、このような手順において、連鎖的なキーまたは値回復工程の最初への入力として用いられる。上記手順の一般的な流れは、図１９に示されている。各ゲームコンポーネント２１８、権限コンポーネント２２０、およびプラットフォームコンポーネント２２２は、エントリモジュール２３３と、１つ以上の別のモジュール２３２と、エンドモジュール２３４とを含んでいる。各モジュール２３２、２３３、および２３４は、同一要素内の別のモジュール２３２、２３３、２３４と組み合わされた時に当該要素に対して完全なデータセットを構成する、コード、ファイル、複数のファイルの集合、あるいはデータの他のセグメントの一部である。本実施例では、ゲームコンポーネント２１８は、ゲームエントリモジュール、任意数Ｎの他のゲームモジュール２３２（以下では、ゲームモジュール１、ゲームモジュール２、．．．、ゲームモジュールＮと称される）、およびゲームエンドモジュールを含んでいる。
【０１０６】
権限コンポーネント２２０は、本実施例では、モジュール２３２を１つのみ含んでいる。これは権限モジュールであるため、エントリモジュール２３３もエンドモジュール２３４も必要ではない。プラットフォームコンポーネント２２２は、ゲームコンポーネント２１８と同様に、プラットフォームエントリモジュール、任意数の他のプラットフォームモジュール２３２（本実施例では、Ｍモジュールは以下ではプラットフォームモジュール１、プラットフォームモジュール２、．．．、プラットフォームモジュールＭと称される）、およびプラットフォームエンドモジュールを含んでいる。
【０１０７】
図１９に示されているコンフィギュレーションを、ゲームモジュール２１８とプラットフォームモジュール２２２との両方において用いることによって、署名検証手順を再プログラミングすることなく、モジュール２３２を例えば除去、挿入、置き換え、シフト、記録することができる。本実施例では、以下に説明するように、エントリモジュール２３３は常に最初に動作される。これは、エントリモジュール２３３が、前の要素のエンドモジュール２３４からの出力を用いて署名されるか、あるいはゲームコンポーネント２１８の場合はＫＰＵＢ−Ａを用いて署名されるからである。他のモジュール２３２が動作されて連鎖において次に必要とされる値を回復する順番は、メモリ２１６内に記憶されたコンポーネントマニフェスト２３１を参照することによって決定される。
【０１０８】
各モジュール２３２、２３３、２３４は、ハードウェアボード２０６の各コンポーネントにロードされる前に署名され、当該署名内に記憶された値は、回復関数２２８を用いて回復される。回復関数２２８は、１セットの署名要素を動作させて（１セットは、各モジュール２３２、２３３、２３４に関連付けられている）、上記署名要素において暗号化されたデータ部分を回復する。回復関数２２８は、連鎖的な検証手順中における各副工程において回復されたデータ部分を暗号化するかあるいは隠す、対応する署名生成関数に関連している。回復されたデータは、連鎖において行われる回復関数２２８の次の実行への入力として用いられる。このように、モジュール２３２、２３３、２３４は、関数２２８の各実行において個々に認証されるのではなく、暗黙的に、且つ、最後のコンポーネントのエンドモジュール２３４上の署名から回復された最後の出力と、連鎖への初期の入力とを比較することによって認証される。このように、ハードウェアボード２０６のコンテンツ全体を同時に認証することができる。回復関数２２８は、好ましくは署名生成および検証関数、好ましくはＥＣＰＶＳ方式（詳細については既に述べた）に関連している。図１９に示されているように、同一コンポーネント内の各モジュール２３２に対する回復関数２２８の実行によって、同一の値またはキーが回復され。これによって、これらのゲームモジュールまたはプラットフォームモジュール（すなわち、エントリモジュールでもエンドモジュールでもないモジュール）を、システム全体を再構成することなく、例えば除去、置き換え、追加することができる。
【０１０９】
新しいモジュールが追加されると、別の検証工程がブートアップにおいて必要となるため連鎖が延ばされる。しかし、出力は他のモジュール２３２と同一であるため、そのようなコンポーネント間において送られる必要のある各入力および出力が影響を受けることはない。モジュールの検証順番がコンポーネントマニフェスト２３１に基づいて決定される場合、コンポーネントマニフェスト２３１は、新しいゲームの追加時にアップデートされなければならない。
【０１１０】
図２０は、ネットワーク２１０からの新しいゲームファイル２１２のダウンロードを示している。新しいゲームファイル２１２に対応する新しいゲームモジュール（ゲームモジュールＮ＋１）が、ゲームコンポーネント２１８内のモジュール２３２のセットの最後に追加される。図１９に示されている連鎖的な構造によって、ゲーム機２００全体をリブートすることなく、新しいゲームモジュールをダウンロード時に検証することができる。システムをリブートすることなく新しいゲームモジュールを追加できるようにすることによって、時間を大幅に節減することができ、またゲーム機２００の動作中に新しいゲームを追加することができる。
【０１１１】
また、メモリ２１６が記憶する認証コード（例えばＨＭＡＣ）は、鍵付きハッシュ関数２３１を用いて生成された、プラットフォームまたはＯＳコンポーネント２２２におけるコンテンツの鍵付きハッシュを含む。本実施例では、ＨＭＡＣを生成するために用いられるキーは、ブートアップにおける連鎖的な検証手順中に回復される中間値（ＫＰＵＢ−Ｃ）を用いて生成される。
【０１１２】
前述したように、各モジュール２３２、２３３、２３４は、各モジュールから回復可能または隠された部分Ｈが、連鎖内の回復関数２２８の次の実行に対する入力（例えば公開キー）として用いられるように、好ましくはＥＣＰＶＳ方式を用いて署名される。モジュール２３２、２３３、２３４を署名するために用いられる値は、対応する公開キーを有する個人キーである。本願において用いられる公開キーは、「公開」であるとは考えられるが、値ＫＰＵＢ−Ａ（ＲＯＭ内に記憶されており、連鎖を開始するために必要とされる値）を除いては、ゲーム機２００に記憶させるべきではない。なぜなら、これらのキーを用いて、ゲーム機２００を認証するのに必要な入力を回復することができるからである。対応する個人キーは、ゲーム機２００の製造業者および／またはゲーム当局（規制機関、カジノ管理機関等）などの適切な機関において生成および安全に記憶させることができる。このように、ゲーム機２００の設置前におけるゲームモジュールおよびプラットフォームモジュールの署名、および新しいゲームモジュールの署名は、信頼の置ける機関が責任を負う。本明細書に記載の実施例では、ＫＰＵＢ−Ａ／ＫＰＲＩＶ−Ａ、ＫＰＵＢ−Ｘ／ＫＰＲＩＶ−Ｘ、ＫＰＵＢ−Ｂ／ＫＰＲＩＶ−Ｂ、ＫＰＵＢ−Ｃ／ＫＰＲＩＶ−Ｃ、およびＫＰＵＢ−Ｚ／ＫＰＲＩＶ−Ｚという５つのキーペアが用いられる。より大きいまたは小さいキーペアは、ゲーム機２００内により大きいまたは小さいモジュール／コンポーネントがある場合に存在することについて理解されるであろう。キーペアＫＰＵＢ−Ｃ／ＫＰＲＩＶ−Ｃは、ゲーム規則などを含む権限モジュールを署名するために用いられるため、ゲーム当局によって保有および／または生成されなければならず、また権限モジュールに対して一意でなくてはならない。これによってゲーム当局は、以下に説明するように、例えば払い出し中にプラットフォームモジュール２２２の独自の認証を行うためのＨＭＡＣのコピーを保持することができる。
【０１１３】
図２１（ａ）〜図２１（ｃ）は、ＥＣＰＶＳを用いてゲームコンポーネントモジュールを署名するために用いられる署名生成工程を示している。図２１（ａ）では、ゲームエントリモジュールはＫＰＲＩＶ−Ａを用いて署名され、また隠された部分または回復可能な部分（すなわち署名において暗号化された値）はＫＰＵＢ−Ｘである。第１の署名要素ｅＧＥＮＴは、工程２５０において、無作為に生成された短期公開／個人キーペアから得られるキーＺを用いてＫＰＵＢ−Ｘを暗号化することによって生成される。工程２５１では、コンポーネントｅＧＥＮＴとゲームエントリモジュールのコンテンツとの組み合わせ（例えば連結）をハッシュすることによって、中間的な要素ｄが計算される。次に工程２５２において、中間的な要素ｄに応じて、個人キーＫＰＲＩＶ−Ａおよび短期個人キーを用いて、第２の署名要素ｓＧＥＮＴが生成される。前述した別の実施形態と同様に、ＥＣＰＶＳ内のコンポーネント「s」は、例えばシュノール署名アルゴリズムを用いて生成することができる。工程２５３において得られる署名は、コンポーネントｅＧＥＮＴ、コンポーネントｓＧＥＮＴ、およびゲームエントリモジュールを含んでいる。これは、対応するモジュールに対して検証関数を実行している時に、ゲームコンポーネント２１８から直接取得することができる。
【０１１４】
図２１（ｂ）には、他のゲームモジュール（すなわち、１〜Ｎ）を署名する一般的な手順が示されている。この図からは、残りの各モジュール２３２（１〜Ｎ）が同一の入力ＺおよびＫＰＲＩＶ−Ｘを用いて署名され、そして同一の値を暗号化するか、あるいは隠すことが分かる。このように、これら他のモジュール２３２は、任意の順番で検証することができる。なぜなら、これら他のモジュール２３２はそれぞれ、同一の入力を必要とし、また（これらモジュールが本物である場合には）連鎖内の署名回復関数２２８の次の実行に用いられる同一の出力を生成するからである。工程２５４では、ＫＰＵＢ−Ｘが、無作為に生成された短期キーペアに由来するキーＺを用いて暗号化され、第１の署名要素ｅＧ１ｔｏＮを生成する際の入力となる。そして該入力は、各ゲームモジュールゲームモジュール１〜Ｎと連結され、そして工程２５５においてハッシュされて中間的な要素ｄを生成する。次に、工程２５６において、個人キーＫＰＲＩＶ−Ｘおよび短期個人キーを用いて上記ｄに応じて第２の署名要素が生成される。そして、工程２５７において署名が得られる。
【０１１５】
図２１（ｃ）には、ゲームエンドモジュールを署名する手順が工程２５８〜工程２６１に示されている。この図からは、署名が、図２１（ａ）および図２１（ｂ）に示されている方法と同様の方法によって生成されていることが分かる。しかし図２１（ｃ）では、値Ｚを用いて別の値（ＫＰＵＢ−Ｂ）が暗号化されており、当該別の値（ＫＰＵＢ−Ｂ）は、権限コンポーネント２２０の検証に用いられる。このため、工程２５８〜工程２６１の詳細についてさらに説明する必要はない。
【０１１６】
次に図２２を参照すると、権限モジュールの署名手順が示されている。権限モジュールは、検証中の入力としてＫＰＵＢ−Ｂを用いる。この値は、ゲームエンドモジュール上の署名から回復される。権限モジュールに関する署名は、部分的には、工程２６２においてキーＺを用いて別の値ＫＰＵＢ−Ｃを暗号化して第１の署名要素ｅＪＭを生成し、個人キーＫＰＲＩＶ−Ｂを用いて第２の署名要素ｓＪＭを生成することによって生成される。次に、権限モジュール上の署名から値ＫＰＵＢ−Ｃが回復される。値ＫＰＵＢ−Ｃは、一旦回復されると、プラットフォームコンポーネントモジュール上の署名において実行される回復関数２２８の連鎖への入力として用いられる。工程２６３では、第１の署名要素ｅＪＭおよび権限モジュールの連結をハッシュすることによって、中間的な要素ｄが生成される。そして工程２６４では、中間的な要素ｄに応じて（また、キーＫＰＲＩＶ−Ｂを用いて）、第２の署名要素ｓＪＭが生成される。工程２６５において得られる署名は、第１の署名要素ｅＪＭ、第２の署名要素ｓＪＭ、および権限モジュールである。
【０１１７】
次に図２３（ａ）〜図２３（ｃ）を参照すると、プラットフォームコンポーネント２２２のモジュール２３２、２３３、２３４を署名するためのフロー図が示されている。プラットフォームコンポーネント２２２のモジュール２３２、２３３、２３４は、値ＫＰＵＢ−Ｃを入力として用いて、プラットフォームエントリモジュールと共に、ゲームコンポーネント２１８の対応するモジュール２３２、２３３、２３４と同一の方法で署名されることに留意されたい。プラットフォームモジュール１〜Ｍ上の回復関数２２８の各アプリケーションは、同一の値ＫＰＵＢ−Ｚを回復する。値ＫＰＵＢ−Ｚは、最終的には、図１９にも示されているように、プラットフォームエンドモジュール上の署名からＫＰＵＢ−Ａを回復するための入力として用いられる。プラットフォームコンポーネント２２２に対しては、短期Ｚを用いてＫＰＵＢ−Ｚが暗号化され、そしてＫＰＲＩＶ−Ｃを用いてプラットフォームエントリモジュール上の署名が生成される；短期キーＺを用いてＫＰＵＢ−Ｚが暗号化され、そしてＫＰＲＩＶ−Ｚを用いて後のモジュール上の署名が生成される；短期キーＺを用いてＫＰＵＢ−Ａが暗号化され、そしてＫＰＲＩＶ−Ｚを用いてプラットフォームエンドモジュール上の署名が生成される。図２３（ａ）に示されている工程２６６〜工程２６９は、プラットフォームエントリモジュールの署名手順を示しており、図２３（ｂ）に示されている工程２７０〜工程２７３は、プラットフォームモジュール１〜Ｍの署名手順を示しており、図２３（ｃ）に示されている工程２７４〜工程２７７は、プラットフォームエンドモジュールの署名手順を示している。図２３に見られるように、プラットフォームモジュールの署名は、ゲームモジュールにおいて生成される署名と同様の方法で生成されるため、詳細な説明は省略する。
【０１１８】
図２４〜図２６および図１９を参照しながら、ゲーム機２００のブートアップ手順中における連鎖的な署名検証の実行手順について以下に説明する。
【０１１９】
連鎖的な署名検証手順の実行前に、ゲーム機２００がブートまたは電源投入されると、ブート手順中に、検証エージェント２２６が開始される。検証エージェント２２６は、ＲＯＭ２１４上に焼かれた値ＫＰＵＢ−Ａのコピーを読み出しまたは取得し、そしてコンポーネントマニフェスト２３１にアクセスして、他のゲームモジュール２３２が動作される順番を決定する。前述したように、まずゲームエントリモジュールが動作され、次に工程２７８において、検証エージェント２２６が署名要素ｅＧＥＮＴ、署名要素ｓＧＥＮＴ、およびゲームエントリモジュールのためのデータ（すなわちゲームエントリモジュールのための「署名」）を取得する（図２４を参照）。
【０１２０】
ＥＣＰＶＳ署名検証における工程では、工程２７９において、中間的な要素ｄ’が生成される。当該中間的な要素ｄ’は、署名生成中に行われる方法と同一の方法によって、すなわち第１の署名要素ｅＧＥＮＴおよびゲームエントリモジュールを用いて（例えば、２つのデータ部分を連結して結果をハッシュすることによって）生成される。工程２８０では、第２の署名要素ｓＧＥＮＴ、中間的な要素ｄ’、および値ＫＰＵＢ−Ａを用いて、復号化キーＺが取得される。次に、工程２８１において、復号化キーＺを用いて、第１の署名要素ｅＧＥＮＴから値ＫＰＵＢ−Ｘを復号化または「回復」する。回復された値ＫＰＵＢ−Ｘは、工程２８２において出力されて、残りのゲームモジュール１〜Ｎおよび最終的にはゲームエンドモジュールにおいて実行される回復関数２２８の第１の実行に対する入力として機能する。工程２８３〜工程２８７は、各残りのゲームモジュール１〜Ｎに対して（すなわちｉ＝Ｎとなるまで）繰り返し行われる。ここで、工程２８６の各インスタンスにおいて回復される値ＫＰＵＢ−Ｘのコピーは、関数２２８の次の動作に送られる。残りのモジュール２３２に対する連鎖的な手順の最後に、工程２８９〜工程２９３において、ゲームモジュールＮの署名から回復されたＫＰＵＢ−Ｘのバージョンを用いて、ゲームエンドモジュールの署名内に隠された次のキーが回復される。工程２９２において、ＫＰＵＢ−Ｘを用いて値ＫＰＵＢ−Ｂが回復される。値ＫＰＵＢ−Ｂは、図２５に示されているように、工程２９３において出力され、権限モジュールの署名から別の値を回復するための入力として用いられる。
【０１２１】
ＥＣＰＶＳは、署名内において暗号化されているもの、あるいは「隠された」ものを制御することを可能にする。このため、ＥＣＰＶＳを用いて予測可能な出力を回復し、当該予測可能な出力を、連鎖における次の工程への予測可能な入力として用いることができることを理解されであろう。言い換えると、メッセージの隠された部分Ｈは、次のモジュールに入力される必要のある出力である。従って、署名は、ゲームコードを可視部分として用い、次の段階に必要な入力を隠された部分として用いることによって行うことができる。コードおよび／または入力が侵害されていない場合であれば、ゲームコードおよび入力を用いた署名検証中における回復工程によって隠された値が回復される。回復関数２２８のそれぞれの実行によって、認証されていない入力が次の段階に対して生成される。しかし、いずれかのモジュールが侵害された場合、連鎖の最後における結果によって、コンテンツ全体の認証を許可する正確な出力が供給されない。このように、回復関数２２８の各実行において適切な出力を回復し、不正確な値が連鎖全体に伝播しないようにしなければならない。これによって、ゲーム機２００は、回復関数２２８の最後のアプリケーションにおいて回復された結果を用いて、ハードウェアボード２０６のコンテンツ全体を暗黙的に認証することができる。
【０１２２】
図２５の工程２９４〜工程２９９は、権限モジュールの署名とゲームエンドモジュールから回復された値ＫＰＵＢ−Ｂとを用いた、値ＫＰＵＢ−Ｃの回復を示している。値ＫＰＵＢ−Ｃは、プラットフォームコンポーネント２２２に対する回復動作の連鎖に対する入力として供給されると同時に、工程３００においてＨＭＡＣを生成するために供給される。ＨＭＡＣは、工程３０２において、後に新しいゲームモジュールがダウンロードされた時にプラットフォームモジュール２２２を認証するために記憶される。ＨＭＡＣは、プラットフォームモジュール２２２のコンテンツを、ＫＰＵＢ−Ｃから得られた値をキー（例えばキー＝f（ＫＰＵＢ−Ｃ））として用いる鍵付きハッシュ関数２３１によってハッシュすることによって生成される。ＨＭＡＣは、（図示されているように）プラットフォームコンポーネント２２２に対する検証連鎖と並行して生成することができ、あるいは、プラットフォームコンポーネント２２２に対する連鎖の開始前に生成することができ、あるいはブート認証手順の最後において行うこともできる。
【０１２３】
ゲームコンポーネント２１８内に含まれているゲームコードが改ざんされた場合、図示および説明されているゲームコンポーネント２１８のモジュール上の回復動作の連鎖中に、不正なキーＫＰＵＢ−Ｃが回復された可能性がある。同様に、プラットフォームコンポーネント２２２のコンテンツが改ざんされた場合、正しい値ＫＰＵＢ−Ｃが回復されたとしても、ＨＭＡＣは、通常はゲーム機２００の設置時およびアップグレード時に適切なゲーム当局によって保持される同様のＨＭＡＣと同一ではない。しかし、連鎖内における残りの工程が（認証されたハードウェアボード２０６を示す）認証された出力を生成しない場合、ＨＭＡＣは不正である可能性があるが、いずれにしても不要である。これは、ゲーム機２００が、そのような状況において問題を訂正するためにシャットダウンするからである。
【０１２４】
図２６を参照すると、工程３０５〜工程３０９において、回復された値ＫＰＵＢ−Ｃを用いてプラットフォームエントリモジューからＫＰＵＢ−Ｚが回復される。これは、署名要素ｅＰＥＮＴ、署名要素ｓＰＥＮＴ、およびプラットフォームエントリモジュールのコンテンツを取得することによって行われる。工程３０８において、要素ｅＰＥＮＴから値ＫＰＵＢ−Ｚが回復され、そして工程３０９において、次の検証手順で用いるために出力される。工程３１０〜工程３１５では、値ＫＰＵＢ−Ｚを用いて、連鎖において用いるために次のＫＰＵＢ−Ｚが回復される。他のモジュール２３２が全て動作されると、プラットフォームモジュールＭの署名から回復された最後のバージョンのＫＰＵＢ−Ｚが回復関数２２８内に送られ、これによって工程３１６〜工程３２０を用いて値ＫＰＵＢ−Ａを回復することができる。次に工程３２１において、出力ＫＰＵＢ−ＡとＢＩＯＳ  ＯＴＰ  ＲＯＭ２１４内に記憶されているＫＰＵＢ−Ａとが比較されて、ハードウェアボード２０６が認証される。これらの値が一致した場合、ブート手順は正常に行われており、工程３０３においてゲームをプレイすることができ、また通常の実行時間動作を開始することができる。出力ＫＰＵＢ−ＡとＲＯＭ２１４内に記憶された値とが一致しない場合、これは、１つ以上のコンポーネント内における１つ以上のモジュールが何らかの形で侵害、改ざん、あるいは破損されたことを示している。これによって、工程３０４においてエラーまたは無効関数が開始され、ゲーム機２００の動作が停止される。
【０１２５】
本実施形態では、前述したように、実行時間中にゲーム機２００に新しいゲームファイル２１２をダウンロードすることができる。新しいゲームファイル２１２がダウンロードされると、新しいゲームモジュール２３２が挿入されて、そのゲームのプレイする許可を進める前に検証が行われる。
【０１２６】
図２７は、工程３２２においてダウンロードされた新しいゲームファイル２１２を認証する手順を示している。新しいゲームモジュールは、それが不正ではない場合、ゲームの署名を含んでいるため既に署名されていることを理解されるであろう。ゲーム機２００は、新しい各ゲームの到着時に、これらに署名するようにプログラムすることができる。しかし、典型的なゲーム規則はこれを許可せず、ゲーム機２００において利用できる新しいゲームファイル２１２の署名および製造を、第三者機関（例えば、ゲーム当局またはそのためのＣＡ）に求める。
【０１２７】
工程３０１では、ＲＯＭ２１６から値ＫＰＵＢ−Ａが読み出され、そしてゲームエントリモジュールのための署名と共に用いられて、上述の工程２７８〜工程２８２に従ってＫＰＵＢ−Ｘが回復される。他のモジュール２３２は飛ばし、値ＫＰＵＢ−Ｘを用いて新しいゲームモジュールＮ＋１からＫＰＵＢ−Ｘが直ちに回復される。
【０１２８】
ゲームエントリモジュールから回復された値ＫＰＵＢ−Ｘを、工程３２４において取得された新しいゲームモジュールＮ＋１に対する署名要素と共に用いて、工程３２５において中間的な要素ｄ’が生成される。次に、工程３２６〜工程３２８が行われてＫＰＵＢ−Ｘが回復される。ＫＰＵＢ−Ｘは、工程３２８において用いられて、工程２８９〜工程２９３に従ってゲームエンドモジュールからＫＰＵＢ−Ｃが回復される。
【０１２９】
権限モジュールからＫＰＵＢ−Ｃが再回復されたため、工程３３０において、当該ＫＰＵＢ−Ｃを用いてハッシュ検証値ＨＭＡＣ’を計算することができる。ブートアップにおいてＨＭＡＣを生成する際に、値ＫＰＵＢ−Ｃを用いて、鍵付きハッシュ関数２３０のためのキーが得られる。このキーは、現在存在しているような、プラットフォームモジュール２２２のコンテンツに適用され、そしてＨＭＡＣの生成後にメモリから除去される。工程３３１では、値ＨＭＡＣ’と記憶されたＨＭＡＣとが比較される。これらが一致した場合、工程３０３においてゲーム機２００は動作を係属することができる。これらが一致しない場合、ブートアップ手順以来、新しいゲームモジュールが破損しているか、あるいはプラットフォームモジュール２２２のコンテンツが改ざんされているかのいずれかである。これは、ゲーム機２００に問題があることを示しており、工程３０４においてエラーまたは無効関数が実行される。
【０１３０】
従って、システムをリブートすることなく、また署名の連鎖を再構成することなく、新しいゲームファイル１５１をゲームコンポーネント２１８にダウンロードおよび追加することができる。再動作させる必要があるのはゲームコンポーネント２１８のエントリモジュール２３３およびエンドモジュール２３４のみであり、他のモジュール２３２の再動作は省略することができる。ブートアップにおいてＨＭＡＣを記憶することによって、新しいゲームが追加された時にハードウェアボード２０６のコンテンツ全体を認証するためにプラットフォームコンポーネント２２２に対する連鎖手順を行う必要がなくなる。これはまた、ＨＭＡＣが中間的なキーを用いて計算され、値ＨＭＡＣ’の生成に必要とされるのは中間的なキーの回復のみであるため可能となる。本実施例では、権限モジュールへの署名を用いて中間的なキーＫＰＵＢ−Ｃが回復され、またこの動作に対する入力が得られる。ゲームエンドモジュールに対する署名の暗号化された部分は、回復させる必要がある。
【０１３１】
図２４〜図２６に示されている検証連鎖の代わりとして、値ＫＰＵＢ−Ａを、エンドモジュール２３４以外のあらゆるモジュールに対する入力として用いることができる。これによって、特定のエントリモジュール２３３を標的とする必要を回避することができるが、各モジュール２３２に対する入力および出力が同一の方法によってリンクされない。このため、ＫＰＵＢ−Ａを用いて各モジュール２３２に署名することは可能であるが、本明細書に記載の実施例は、任意のモジュールの破損が連鎖を介して伝播して、非認証の出力をもたらすので好ましい。
【０１３２】
図２７に示されているダウンロード検証手順の代わりとなる、いくつかの手順が存在する。それらの手順のいずれを選択するのかは、アプリケーションの性質に依る。ここに示されている手順は、ＨＭＡＣを記憶し、そしてＫＰＵＢ−Ｃを回復して、メモリ２１６内に記憶されたＨＭＡＣを認証することによって、他のモジュール２３２の署名からの値ＫＰＵＢ−Ｘの回復を省略し、またプラットフォームモジュールの署名からの値ＫＰＵＢ−Ｂ、ＫＰＵＢ−Ｚ、およびＫＰＵＢ−Ａの回復を省略する。これによって、ゲーム機２００の完全なリブートが回避される。ゲーム環境においては、新しいゲームがダウンロードされる度にリブートすることは望ましくなく、特に、一般的なゲーム機２００が実行される度に新しいゲームをダウンロードする場合には望ましくない。リブートが望ましくない他のアプリケーションでは、新しいゲームが追加される度に、検証エージェント２２６は、ブートアップにおいてＨＭＡＣの生成を省略することができ、単に、（ゲームモジュールＮの後に挿入された新しいゲームモジュールＮ＋１を有する）ハードウェアボード２０６のコンテンツ全体を再認証する。他の手順としては、ＨＭＡＣを用いずに、図２７に示されている他のゲームモジュール２３２を省略し、単に連鎖の残りに対して値の回復を継続する手順がある。あるいは、他のゲームモジュール２３２を省略する一方でＨＭＡＣを用いて、後にプラットフォームコンポーネント２２２を認証する手順がある。
【０１３３】
図２８には、一般的な実施形態が示されている。本実施形態は、前述の原理に従って、
後にセキュア状態とされて認証されるデータを含んだ、コンピュータベースのシステム内における１つ以上のコードブロック３４４を認証するための実施形態である。コンテンツまたはコードブロック２４４の１つ以上の各部分は、エントリモジュール３４５、エンドモジュール３４８、および１つ以上の他のモジュール３４６を有しているか、あるいは権限モジュールと同様に、モジュールを１つのみ有していてもよい。いずれのコードブロック２４４も、モジュールを２つ有していてよく、従ってエントリモジュール３４５およびエンドモジュール３４８を有していてよいことについて理解されるであろう。連鎖的な検証手順を用いて、一コンポーネントの出力を次のコンポーネントへの入力へ送ることによって、また連鎖手順全体が行われた時に出力と初期の入力とを比較することによって、システム全体のコンテンツを暗黙的かつ同時に認証することができる。
【０１３４】
図２８に示されているシステムは、ＲＯＭ３４０を有している。ＲＯＭ３４０は、連鎖的な検証手順を行う検証エージェント３４２と、入力とを含んでいる。図示されているように、上記入力は、（例えばＥＣＰＶＳを用いてメッセージ回復動作を行う）回復関数２２８を動作させることによって、コードブロック１内のエントリモジュールから値Ａを回復するために用いられ、そしてこれは、全ての他のモジュール３４６からＡを回復するために用いられる。次に、値Ａを用いてエンドモジュールからＢが回復され、そしてこれを、次の要素であるコードブロック２に対して連鎖において用いる。値Ｂは、コードブロック２内のエントリモジュールから値Ｃを回復するために用いられ、そしてこれを用いてあらゆる他のモジュール３４６からＣが回復される。値Ｃは、エンドモジュールから値Ｄを回復するために用いられる。そして値Ｄは次のコードブロック３４４に送られて、最終的には最後のコードブロックＭにおいて値Ｄ’を用いて値Ｅが回復される。値Ｅは、コードブロックＭ内の全ての他のモジュール３４６から値Ｅを回復し、そしてコードブロックＭ内のエンドモジュールから出力を回復するために用いられる。
【０１３５】
一般的な上記実施形態では、回復関数２２８の使用により、回復可能な部分を特定できることが分かる。そして、この回復可能な部分により、モジュール同士を鎖状に結合し、その最終出力を用いてシステム全体を認証できるように、各モジュールに予測可能なように署名することができる。上記モジュールのいずれかが侵害された場合、上記出力は不正確となり、入力と一致しない。これは、適切な入力が用いられた場合にのみ適切な値が回復されるからである。モジュールを連鎖的にすることにより、侵害されたあらゆるコードによって、不正確な値が連鎖中に伝播して出力が拒否される。従って、本明細書に記載の連鎖的な検証は、連鎖の最後における出力と入力との比較に基づいて、全コードブロック３４４およびその内部の全モジュールを暗黙的に認証する。これによってさらに、全てのコードブロック３４４が同時に認証される。
【０１３６】
図２８に示されている一般的な実施形態はまた、鍵付きハッシュ（例えばＨＭＡＣ）を用いて、ゲーム機２００を認証する実施例において例証した効率を可能にすることができることについて理解されるであろう。一般的な上記実施形態はさらに、それぞれが単一モジュールのみを有しており、その１つのモジュールに対する署名から回復される値が、次のコードブロック内の次のモジュールから別の値を回復するための入力として用いられる、複数のコードブロック３４４に対して同一の原理を用いることができることについて理解されるであろう。従って、本明細書に示されている連鎖的な署名検証手順は、一コードブロックの署名から回復された値を次のコードブロックの署名の検証関数への入力として用いて別の値を回復できるように、多数のファイル構造およびデータ記憶方式に適合するように構成することができることが分かる。上記連鎖は、保護されることが求められる全コードブロックを含むように構築され、また最終的に回復された出力は、認証データセットに対する入力と同一でなければならない。
【０１３７】
本発明について、特定の具体的な実施形態を参照しながら説明したが、当業者には、これら実施形態の様々な変形が明らかである。
【図１】
2009544084.tif 000006
【図２】
2009544084.tif 000007
【図３】
2009544084.tif 000008
【図４】
2009544084.tif 000009
【図５】
2009544084.tif 000010
【図６】
2009544084.tif 000011
【図７】
2009544084.tif 000012
【図８】
2009544084.tif 000013
【図９ａ】
2009544084.tif 000014
【図９ｂ】
2009544084.tif 000015
【図１０】
2009544084.tif 000016
【図１１】
2009544084.tif 000017
【図１２】
2009544084.tif 000018
【図１３】
2009544084.tif 000019
【図１４】
2009544084.tif 000020
【図１５】
2009544084.tif 000021
【図１６】
2009544084.tif 000022
【図１７】
2009544084.tif 000023
【図１８】
2009544084.tif 000024
【図１９】
2009544084.tif 000025
【図２０】
2009544084.tif 000026
【図２１】
2009544084.tif 000027
【図２２】
2009544084.tif 000028
【図２３】
2009544084.tif 000029
【図２４】
2009544084.tif 000030
【図２５】
2009544084.tif 000031
【図２６】
2009544084.tif 000032
【図２７】
2009544084.tif 000033
【図２８】
2009544084.tif 000034
【国際調査報告】
2009544084.tif 000035
2009544084.tif 000036
2009544084.tif 000037
2009544084.tif 000038