(57)【特許請求の範囲】
【請求項１】
終点デバイスでのコードの実行を制御する方法であって、
該方法は、
第１のビットストリームをデバイスにおいて受信することと、
該第１のビットストリームに対応する第１のキーを取得することであって、該第１のキーは、該第１のビットストリームをハッシュし、対称関数を使用して該ハッシュされた第１のビットストリームを暗号化することによって作成されたものである、ことと、
該デバイスに特有の第１の秘密キーにアクセスするように動作可能な該デバイスにおけるハードウェアを使用して該第１のビットストリームを認証することであって、該第１の秘密キーは、該デバイスのハードウェアの中に格納され、該デバイスがセキュア化モードで実行しているときにアクセス可能であり、該第１のビットストリームを認証することは、
該第１のビットストリームをハッシュすることと、
該ハッシュされた第１のビットストリームを暗号化することによって第２のキーを生成することであって、該ハッシュされた第１のビットストリームの該暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイスに特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第２のキーを該第１のキーと比較することと
を含む、ことと、
該第２のキーと該第１のキーとが整合する場合、該デバイスにおいて該第１のビットストリームをセキュア化モードで実行することであって、該第１のビットストリームは、第１の暗号化エンジンを含み、該第１のビットストリームを実行することは、該第１の暗号化エンジンおよび該デバイスに特有の第１の秘密キーを使用して、該第１のビットストリームと関連付けられた暗号化されたデジタルコンテンツを復号化することを含み、該第１のビットストリームの実行は、セキュア化モードで行われる、ことと、
該第２のキーと該第１のキーとが整合しない場合、該第１のビットストリームが暗号化されているか否かを決定し、該第１のビットストリームが暗号化されているとき、
第２のビットストリームを取得することと、
該ハードウェアの中に格納される該デバイスに特有の第１の秘密キーにアクセスするように動作可能な該デバイスにおける該ハードウェアを使用して、該第２のビットストリームを認証することであって、該第２のビットストリームを認証することは、
該第２のビットストリームに対応する第３のキーを取得することであって、該第３のキーは、該第２のビットストリームをハッシュし、該ハッシュされた第２のビットストリームを暗号化することによって作成されたものである、ことと、
該第２のビットストリームをハッシュすることであって、該第２のビットストリームをハッシュすることは、該第１のビットストリームから生成された該第２のキーをシード値として利用する、ことと、
該ハッシュされた第２のビットストリームを暗号化することによって第４のキーを生成することであって、該ハッシュされた第２のビットストリームの該暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイスに特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと
を含む、ことと、
該生成された第４のキーを該第３のキーと比較することと
を実行することと、
該第４のキーと該第３のキーとが整合するとき、該第２のビットストリームを該デバイスにおいてセキュア化モードで実行することと
を含む、方法。
【請求項２】
終点デバイスでのコードの実行を制御する方法であって、
該方法は、
第１のビットストリームをデバイスにおいて受信することと、
該第１のビットストリームに対応する第１のキーを取得することであって、該第１のキーは、該第１のビットストリームをハッシュし、対称関数を使用して該ハッシュされた第１のビットストリームを暗号化することによって作成されたものである、ことと、
該デバイスに特有の第１の秘密キーにアクセスするように動作可能な該デバイスにおけるハードウェアを使用して該第１のビットストリームを認証することであって、該第１の秘密キーは、該デバイスのハードウェアの中に格納され、該デバイスがセキュア化モードで実行しているときにアクセス可能であり、該第１のビットストリームを認証することは、
該第１のビットストリームをハッシュすることと、
該ハッシュされた第１のビットストリームを暗号化することによって第２のキーを生成することであって、該ハッシュされた第１のビットストリームの該暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイスに特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第２のキーを該第１のキーと比較することと
を含む、ことと、
該第２のキーと該第１のキーとが整合する場合、該デバイスのプロセッサにおいて該第１のビットストリームをセキュア化モードで実行することであって、該第１のビットストリームは、第１の暗号化エンジンを含み、該第１のビットストリームを実行することは、該第１の暗号化エンジンおよび該デバイスに特有の第１の秘密キーを使用して、該第１のビットストリームと関連付けられた暗号化されたデジタルコンテンツを復号化することを含み、該第１のビットストリームの実行は、セキュア化モードで行われる、ことと、
該第２のキーと該第１のキーとが整合しない場合、該第１のビットストリームが暗号化されているか否かを決定し、該第１のビットストリームが暗号化されているとき、
第２のビットストリームを取得することであって、該第２のビットストリームは、第２の暗号化エンジンを含む、ことと、
該ハードウェアの中に格納される該デバイスに特有の第１の秘密キーにアクセスするように動作可能な該デバイスにおける該ハードウェアを使用して、該第２のビットストリームを認証することであって、該第２のビットストリームを認証することは、
該第２のビットストリームに対応する第３のキーを取得することであって、該第３のキーは、該第２のビットストリームをハッシュし、該ハッシュされた第２のビットストリームを暗号化することによって作成されたものである、ことと、
該第２のビットストリームをハッシュすることと、
該ハッシュされた第２のビットストリームを暗号化することによって第４のキーを生成することであって、該ハッシュされた第２のビットストリームの該暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイスに特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと
を含む、ことと、
該生成された第４のキーを該第３のキーと比較することと、
該第４のキーと該第３のキーとが整合するとき、該第２のビットストリームを該プロセッサにおいてセキュア化モードで実行することであって、該第２のビットストリームを実行することは、該デバイスに特有の第１の秘密キーを使用して、該第２の暗号化エンジンを用いて暗号化されたデジタルコンテンツおよび該第１のビットストリームの両方を復号化することを含む、ことと
を実行することと
を含む、方法。
【請求項３】
前記第２のビットストリームの認証および前記第２のビットストリームの実行は、前記第１のビットストリームの実行の前に行われる、請求項２に記載の方法。
【請求項４】
前記第２のビットストリームの実行後、前記第１のビットストリームの実行前に、該第１のビットストリームを認証することをさらに含む、請求項３に記載の方法。
【請求項５】
前記第１のビットストリーム、第２のビットストリーム、暗号化されたデジタルコンテンツ、第１のキー、および第３のキーは、メッセージの中に受信されており、該メッセージは、
該第１のビットストリームの第１の暗号化エンジンを用いて、該デジタルコンテンツを暗号化することと、
該第１のビットストリームをハッシュし、前記デバイスに特有の第１の秘密キーを用いて、該ハッシュされた第１のビットストリームを暗号化することによって、該第１のキーを生成することと、
該第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと、
該第２のビットストリームの第２の暗号化エンジンを用いて、該関連付けられた該第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを暗号化することと、
該第２のビットストリームをハッシュし、該デバイスに特有の第１の秘密キーを用いて、該ハッシュされた第２のビットストリームを暗号化することによって、該第３のキーを生成することと、
第１の復号化アルゴリズムを該第１の暗号化されたビットストリームと関連付けることと、
該第３のキーと第２のビットストリームと暗号化された関連付けられた第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと
によって生成される、請求項４に記載の方法。
【請求項６】
コードの実行を制御するシステムであって、該システムは、デバイスを含み、
該デバイスは、
プロセッサと、
第１の秘密キーを格納する第１のハードウェアと、
第２のハードウェアであって、該プロセッサがセキュア化モードで実行しているときに、該第１の秘密キーにアクセスし、該第１の秘密キーを使用して、暗号化アルゴリズムを実装するように動作可能である第２のハードウェアと、
該プロセッサによって実行可能な命令を含むコンピュータ可読記憶媒体と
を含み、
該命令は、
第１のビットストリームを該デバイスにおいて受信することであって、該第１のビットストリームは、第１の暗号化エンジンを含む、ことと、
該第１のビットストリームに対応する第１のキーを取得することであって、該第１のキーは、該第１のビットストリームをハッシュし、対称関数を使用して該ハッシュされた第１のビットストリームを暗号化することによって作成されたものである、ことと、
該デバイスにおける該第２のハードウェアを使用して、該第１のビットストリームを認証することであって、該第１のビットストリームを認証することは、
該第１のビットストリームをハッシュすることと、
該ハッシュされた第１のビットストリームを暗号化することによって、第２のキーを生成することであって、該ハッシュされた第１のビットストリームの暗号化は、該デバイスの第２のハードウェアの中で行われ、該第２のハードウェアは、該デバイスに特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第２のキーを該第１のキーと比較することと
を含む、ことと、
該第２のキーと該第１のキーとが整合する場合、該プロセッサにおいて該第１のビットストリームをセキュア化モードで実行することであって、該第１のビットストリームを実行することは、該第１の暗号化エンジンおよび該デバイスに特有の第１の秘密キーを使用して、該第１のビットストリームと関連付けられた暗号化されたデジタルコンテンツを復号化することを含み、該第１のビットストリームの実行は、セキュア化モードで行われる、ことと、
該第１のビットストリームが暗号化されているか否かを決定し、該第１のビットストリームが暗号化されているときは、
第２のビットストリームを取得することと、
該第１のハードウェアの中に格納される該デバイスに特有の第１の秘密キーにアクセスするように動作可能である該デバイスにおける該第２のハードウェアを使用して、該第２のビットストリームを認証することであって、該第２のビットストリームを認証することは、
該第２のビットストリームに対応する第３のキーを取得することであって、該第３のキーは、該第２のビットストリームをハッシュし、該ハッシュされた第２のビットストリームを暗号化することによって作成されたものである、ことと、
該第２のビットストリームをハッシュすることであって、該第２のビットストリームをハッシュすることは、該第１のビットストリームから生成された該第２のキーをシード値として利用する、ことと、
該ハッシュされた第２のビットストリームを暗号化することによって、第４のキーを生成することであって、該ハッシュされた第２のビットストリームの暗号化は、該デバイスの該第２のハードウェアの中で行われ、該第２のハードウェアは、該デバイスに特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと
を含む、ことと、
該生成された第４のキーを該第３のキーと比較することと
を実行することと、
該第４のキーと該第３のキーとが整合する場合、該プロセッサにおいて該第２のビットストリームをセキュア化モードで実行することと
を行うためのものである、システム。
【請求項７】
コードの実行を制御するシステムであって、該システムは、デバイスを含み、
該デバイスは、
プロセッサと、
第１の秘密キーを格納する第１のハードウェアと、
第２のハードウェアであって、該プロセッサがセキュア化モードで実行しているときに、該第１の秘密キーにアクセスし、該第１の秘密キーを使用して、暗号化アルゴリズムを実装するように動作可能である第２のハードウェアと、
該プロセッサによって実行可能な命令を含むコンピュータ可読記憶媒体と
を含み、
該命令は、
第１のビットストリームを該デバイスにおいて受信することであって、該第１のビットストリームは、第１の暗号化エンジンを含む、ことと、
該第１のビットストリームに対応する第１のキーを取得することであって、該第１のキーは、該第１のビットストリームをハッシュし、対称関数を使用して該ハッシュされた第１のビットストリームを暗号化することによって作成されたものである、ことと、
該デバイスにおける該第２のハードウェアを使用して、該第１のビットストリームを認証することであって、該第１のビットストリームを認証することは、
該第１のビットストリームをハッシュすることと、
該ハッシュされた第１のビットストリームを暗号化することによって、第２のキーを生成することであって、該ハッシュされた第１のビットストリームの暗号化は、該デバイスの第２のハードウェアの中で行われ、該第２のハードウェアは、該デバイスに特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと
該生成された第２のキーを該第１のキーと比較することと
を含む、ことと、
該第２のキーと該第１のキーとが整合する場合、該プロセッサにおいて該第１のビットストリームをセキュア化モードで実行することであって、該第１のビットストリームを実行することは、該第１の暗号化エンジンおよび該デバイスに特有の第１の秘密キーを使用して、該第１のビットストリームと関連付けられた暗号化されたデジタルコンテンツを復号化することを含み、該第１のビットストリームの実行は、セキュア化モードで行われる、ことと、
該第１のビットストリームが暗号化されているか否かを決定し、該第１のビットストリームが暗号化されているときは、
第２のビットストリームを取得することであって、該第２のビットストリームは、第２の暗号化エンジンを含む、ことと、
該第１のハードウェアの中に格納される該デバイスに特有の第１の秘密キーにアクセスするように動作可能である該デバイスにおける該第２のハードウェアを使用して、該第２のビットストリームを認証することであって、該第２のビットストリームを認証することは、
該第２のビットストリームに対応する第３のキーを取得することであって、該第３のキーは、該第２のビットストリームをハッシュし、該ハッシュされた第２のビットストリームを暗号化することによって作成されたものである、ことと、
該第２のビットストリームをハッシュすることと、
該ハッシュされた第２のビットストリームを暗号化することによって、第４のキーを生成することであって、該ハッシュされた第２のビットストリームの暗号化は、該デバイスの該第２のハードウェアの中で行われ、該第２のハードウェアは、該デバイスに特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと
を含む、ことと、
該生成された第４のキーを該第３のキーと比較することと
を実行することと、
該第４のキーと該第３のキーとが整合する場合、該プロセッサにおいて該第２のビットストリームをセキュア化モードで実行することであって、該第２のビットストリームを実行することは、該デバイスに特有の第１の秘密キーを使用して、該第２の暗号化エンジンを用いて暗号化されたデジタルコンテンツおよび該第１のビットストリームの両方を復号化することを含む、ことと
を行うためのものである、システム。
【請求項８】
前記第２のビットストリームの認証および前記第２のビットストリームの実行は、前記第１のビットストリームの実行の前に行われる、請求項７に記載のシステム。
【請求項９】
前記命令は、前記第２のビットストリームの実行後、前記第１のビットストリームの実行前に、該第１のビットストリームを認証するように動作可能である、請求項８に記載のシステム。
【請求項１０】
前記第１のビットストリーム、第２のビットストリーム、暗号化されたデジタルコンテンツ、第１のキー、および第３のキーは、メッセージにおいて受信されており、該メッセージは、
該第１のビットストリームの第１の暗号化エンジンによって、該デジタルコンテンツを暗号化することと、
該第１のビットストリームをハッシュし、前記デバイスに特有の第１の秘密キーを用いて該ハッシュされた第１のビットストリームを暗号化することによって、該第１のキーを生成することと、
該第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと、
該第２のビットストリームの第２の暗号化エンジンを用いて、該関連付けられた該第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを暗号化することと、
該第２のビットストリームをハッシュし、該デバイスに特有の第１の秘密キーを用いて該ハッシュされた第２のビットストリームを暗号化することによって、第３のキーを生成することと、
第１の復号化アルゴリズムを該第１の暗号化されたビットストリームと関連付けることと、
該第３のキーと第２のビットストリームと暗号化された関連付けられた第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと
によって生成される、請求項９に記載のシステム。
【請求項１１】
終点デバイスにおけるコードの実行を制御するプロセッサによって実行可能な命令を含む非一時的なコンピュータ可読媒体であって、該命令は、方法を実行するために実行可能な命令を含み、
該方法は、
第１のビットストリームをデバイスにおいて受信することと、
該第１のビットストリームに対応する第１のキーを取得することであって、該第１のキーは、該第１のビットストリームをハッシュし、対称関数を使用して該ハッシュされた第１のビットストリームを暗号化することによって作成されたものである、ことと、
該デバイスに特有の第１の秘密キーにアクセスするように動作可能な該デバイスにおけるハードウェアを使用して該第１のビットストリームを認証することであって、該第１の秘密キーは、該デバイスのハードウェアの中に格納され、該デバイスがセキュア化モードで実行しているときにアクセス可能であり、該第１のビットストリームを認証することは、
該第１のビットストリームをハッシュすることと、
該ハッシュされた第１のビットストリームを暗号化することによって第２のキーを生成することであって、該ハッシュされた第１のビットストリームの該暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイスに特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第２のキーを該第１のキーと比較することと
を含む、ことと、
該第２のキーと該第１のキーとが整合する場合、該プロセッサにおいて該第１のビットストリームをセキュア化モードで実行することであって、該第１のビットストリームは、第１の暗号化エンジンを含み、該第１のビットストリームを実行することは、該第１の暗号化エンジンおよび該デバイスに特有の第１の秘密キーを使用して、該第１のビットストリームと関連付けられた暗号化されたデジタルコンテンツを復号化することを含み、該第１のビットストリームの実行は、セキュア化モードで行われる、ことと、
該第２のキーと該第１のキーとが整合しない場合、該第１のビットストリームが暗号化されているか否かを決定し、該第１のビットストリームが暗号化されているとき、
第２のビットストリームを取得することと、
該ハードウェアの中に格納される該デバイスに特有の第１の秘密キーにアクセスするように動作可能な該デバイスにおける該ハードウェアを使用して、該第２のビットストリームを認証することであって、該第２のビットストリームを認証することは、
該第２のビットストリームに対応する第３のキーを取得することであって、該第３のキーは、該第２のビットストリームをハッシュし、該ハッシュされた第２のビットストリームを暗号化することによって作成されたものである、ことと、
該第２のビットストリームをハッシュすることであって、該第２のビットストリームをハッシュすることは、該第１のビットストリームから生成された該第２のキーをシード値として利用する、ことと、
該ハッシュされた第２のビットストリームを暗号化することによって第４のキーを生成することであって、該ハッシュされた第２のビットストリームの該暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイスに特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと
を含む、ことと、
該生成された第４のキーを該第３のキーと比較することと
を実行することと、
該第４のキーと該第３のキーとが整合するとき、該第２のビットストリームを該プロセッサにおいてセキュア化モードで実行する、ことと
を含む、非一時的なコンピュータ可読媒体。
【請求項１２】
終点デバイスにおけるコードの実行を制御するプロセッサによって実行可能な命令を含む非一時的なコンピュータ可読媒体であって、該命令は、
第１のビットストリームをデバイスにおいて受信することと、
該第１のビットストリームに対応する第１のキーを取得することであって、該第１のキーは、該第１のビットストリームをハッシュし、対称関数を使用して該ハッシュされた第１のビットストリームを暗号化することによって作成されたものである、ことと、
該デバイスに特有の第１の秘密キーにアクセスするように動作可能な該デバイスにおけるハードウェアを使用して該第１のビットストリームを認証することであって、該第１の秘密キーは、該デバイスのハードウェアの中に格納され、該デバイスがセキュア化モードで実行しているときにアクセス可能であり、該第１のビットストリームを認証することは、
該第１のビットストリームをハッシュすることと、
該ハッシュされた第１のビットストリームを暗号化することによって第２のキーを生成することであって、該ハッシュされた第１のビットストリームの該暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイスに特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第２のキーを該第１のキーと比較することと
を含む、ことと、
該第２のキーと該第１のキーとが整合する場合、該プロセッサにおいて該第１のビットストリームをセキュア化モードで実行することであって、該第１のビットストリームは、第１の暗号化エンジンを含み、該第１のビットストリームを実行することは、該第１の暗号化エンジンおよび該デバイスに特有の第１の秘密キーを使用して、該第１のビットストリームと関連付けられた暗号化されたデジタルコンテンツを復号化することを含み、該第１のビットストリームの実行は、セキュア化モードで行われる、ことと、
該第２のキーと該第１のキーとが整合しない場合、該第１のビットストリームが暗号化されているか否かを決定し、該第１のビットストリームが暗号化されているとき、
第２のビットストリームを取得することであって、該第２のビットストリームは、第２の暗号化エンジンを含む、ことと、
該ハードウェアの中に格納される該デバイスに特有の第１の秘密キーにアクセスするように動作可能な該デバイスにおける該ハードウェアを使用して、該第２のビットストリームを認証することであって、該第２のビットストリームを認証することは、
該第２のビットストリームに対応する第３のキーを取得することであって、該第３のキーは、該第２のビットストリームをハッシュし、該ハッシュされた第２のビットストリームを暗号化することによって作成されたものである、ことと、
該第２のビットストリームをハッシュすることと、
該ハッシュされた第２のビットストリームを暗号化することによって第４のキーを生成することであって、該ハッシュされた第２のビットストリームの該暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイスに特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと
を含む、ことと、
該生成された第４のキーを該第３のキーと比較することと、
を実行することと、
該第４のキーと該第３のキーとが整合するとき、該第２のビットストリームを該プロセッサにおいてセキュア化モードで実行することであって、該第２のビットストリームを実行することは、該デバイスに特有の第１の秘密キーを使用して、該第２の暗号化エンジンを用いて暗号化されたデジタルコンテンツおよび該第１のビットストリームの両方を復号化することを含む、ことと
を実行可能な命令を含む、非一時的なコンピュータ可読媒体。
【請求項１３】
前記第２のビットストリームの認証および前記第２のビットストリームの実行は、前記第１のビットストリームの実行の前に行われる、請求項１２に記載の非一時的なコンピュータ可読媒体。
【請求項１４】
前記第２のビットストリームの実行後、前記第１のビットストリームの実行前に、該第１のビットストリームを認証することをさらに含む、請求項１３に記載の非一時的なコンピュータ可読媒体。
【請求項１５】
前記第１のビットストリーム、第２のビットストリーム、暗号化されたデジタルコンテンツ、第１のキー、および第３のキーは、メッセージにおいて受信されており、該メッセージは、
該第１のビットストリームの第１の暗号化エンジンを用いて、該デジタルコンテンツを暗号化することと、
該第１のビットストリームをハッシュし、前記デバイスに特有の第１の秘密キーを用いて、該ハッシュされた第１のビットストリームを暗号化することによって、該第１のキーを生成することと、
該第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと、
該第２のビットストリームの第２の暗号化エンジンを用いて、該関連付けられた第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを暗号化することと、
該第２のビットストリームをハッシュし、該デバイスに特有の第１の秘密キーを用いて該ハッシュされた第２のビットストリームを暗号化することによって、第３のキーを生成することと、
第１の復号化アルゴリズムを該第１の暗号化されたビットストリームと関連付けることと、
該第３のキーと第２のビットストリームと暗号化された関連付けられた第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと
によって生成される、請求項１４に記載の非一時的なコンピュータ可読媒体。
【請求項１６】
前記第２のビットストリームの認証および前記第２のビットストリームの実行は、前記第１のビットストリームの実行の前に行われる、請求項１に記載の方法。
【請求項１７】
前記第２のビットストリームの実行後、前記第１のビットストリームの実行前に、該第１のビットストリームを認証することをさらに含む、請求項１６に記載の方法。
【請求項１８】
前記第２のビットストリームの認証および前記第２のビットストリームの実行は、前記第１のビットストリームの実行の前に行われる、請求項６に記載のシステム。
【請求項１９】
前記命令は、前記第２のビットストリームの実行後、前記第１のビットストリームの実行前に、該第１のビットストリームを認証するように動作可能である、請求項１８に記載のシステム。
【請求項２０】
前記第２のビットストリームの認証および前記第２のビットストリームの実行は、前記第１のビットストリームの実行の前に行われる、請求項１１に記載の非一時的なコンピュータ可読媒体。
【請求項２１】
前記第２のビットストリームの実行後、前記第１のビットストリームの実行前に、該第１のビットストリームを認証することをさらに含む、請求項２０に記載の非一時的なコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（発明の分野）
この開示は、汎用コンピュータにおいて任意のコード実行を制御する方法に関する。具体的には、この開示は、コードの実行をコンピューティングデバイスとリンクさせて、コードの実行を制御する効果的な方法に関する。さらに、より具体的には、この開示は、再帰的セキュリティプロトコルの実装と併用してコードの実行を制御することに関する。
【背景技術】
【０００２】
コンピュータウイルスおよび他の悪質なソフトウェアは、情報技術業界にとって大きな問題となっている。汎用コンピュータは、定義によれば、任意のコードを起動可能であるので、所与の汎用コンピュータプラットフォーム上において、部分的または全体的に、どのソフトウェアの起動が許容されるかを正確に制御することが非常に困難であって、したがって、マルウェアまたは他の種類の望ましくないソフトウェアの実行を防止することが困難であり得る。現在、このレベルの制御が試みられているいくつかの方法が存在するが、攻撃からプロセッサを隔離するための大部分の努力は、２つの基礎的な問題、すなわち、プロセッサプラットフォームにおける汎用性の損失または性能の損失に悩まされている。これらの損失は、承認と未承認の使用モードとをどのように迅速かつ明確に区別するかの基礎的な問題から生じる。
【０００３】
第２の、しかし、関連する問題は、著作権管理の問題である。今日作成されている文書、音声、および視覚的芸術作品の大部分は、元々デジタルフォーマットであるか、または最終的にデジタルフォーマットとなる。デジタルデータの特徴の１つは、容易に、実質的に正確に複製可能なことである。この特性は、多種多様な安価な配信メカニズムを促進し、その大部分は容易に制御されるものではない。デジタルコンテンツの配信特有の制御不能性は、過去数十年にわたって著作権法の分野に広範囲に及ぶ関連事項をもたらした。あるシステムおよび方法が、そのような複製されたデータのコピーならびに配信を制御するために開発されたが、これらのシステムおよび方法が有する問題の１つは、これらのシステムおよび方法と併用したある種類のソフトウェア、例えば、システムおよび方法を修正するか、またはそのようなシステムおよび方法によって利用されるデータを取得するコードの実行を介して、回避され得ることである。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
したがって、汎用コンピューティングデバイスにおけるコードの実行に対するある程度の制御が行使され得、セキュリティプロトコルと併用して、それを利用することによって、そのようなシステムの有効性が向上され得るシステムおよび方法を見つける必要性が存在する。
【課題を解決するための手段】
【０００５】
汎用コードブロックの実行に対して高度に特有の管理を提供するシステムおよび方法の実施形態が開示される。これらの実施形態は、所与のコードブロックが特異性によって決定されるように実行されるまさにその環境を可能にし得る。そのような制御メカニズムは、例えば、再帰的実行を介して実装されるコードセグメントの集合の順序付けられた実行に基づくデータ隠蔽システムおよび方法の実施形態と結合されてもよい。これらのシステムおよび方法の実施形態がともに利用されると、妨害されない普遍性だけではなく、多くの他のセキュリティシステムに勝る、攻撃に対する一定レベルの保護が獲得され得る。
【０００６】
特に、一実施形態では、実行に対する条件付き制御のためのシステムおよび方法とともに、特定のコンピュータ操作において使用されるデータを難読化しつつ、依然として、そのデータの使用を可能にするシステムおよび方法が開示される。制御または難読化のためのこれらのシステムおよび方法は、デジタルセキュリティ、著作権管理、条件付きアクセス、望ましくないコンピュータウイルスに対する保護等を包含し得るが、それらに限定されないセキュリティの分野を含む、多数の潜在的用途分野において使用可能である。具体的には、実施形態は、再帰的セキュリティプロトコルと併用して利用され、そのようなセキュリティプロトコルを強化し得る。
【０００７】
加えて、これらの種類の方法論をコンピュータシステム、ハードウェア、およびソフトウェアにおいて具現化するシステムの実施形態が提示される。全く同一のハードウェア実装は、潜在的に、ソフトウェアの要件に応じて、解決策の全範囲のうちの任意の１つまたは組み合わせを実装するために使用され得ることに留意されたい。
本明細書は、例えば、以下の項目も提供する。
（項目１）
終点デバイスでのコードの実行を制御する方法であって、
第１のビットストリームをデバイスにおいて受信することと、
該第１のビットストリームに対応する第１のキーを取得することであって、該第１のキーは、該第１のビットストリームをハッシュし、該ハッシュされた第１のビットストリームを暗号化することによって作成された、ことと、
該デバイス特有の第１の秘密キーにアクセスするように動作可能な該デバイスにおけるハードウェアを使用して該第１のビットストリームを認証することであって、該第１の秘密キーは、該デバイスのハードウェアの中に格納され、該デバイスがセキュアモードで実行しているときにアクセス可能であり、該第１のビットストリームを認証することは、
該第１のビットストリームをハッシュすることと、
該ハッシュされた第１のビットストリームを暗号化することによって第２のキーを生成することであって、該ハッシュされた第１のビットストリームの該暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイス特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第２のキーを該第１のキーと比較することと
を含む、ことと
を含み、該第２のキーと該第１のキーとが整合する場合、該プロセッサにおいて該第１のビットストリームをセキュア化モードで実行する、方法。
（項目２）
前記第１のビットストリームは、第１の暗号化エンジンを含み、該第１のビットストリームを実行することは、該第１の暗号化エンジンおよび前記デバイス特有の第１の秘密キーを使用して、該第１のビットストリームと関連付けられた暗号化されたデジタルコンテンツを復号化することを含み、該第１のビットストリームの実行は、セキュアモードで行われる、項目１に記載の方法。
（項目３）
前記第２のキーと前記第１のキーとが整合しない場合、
前記第１のビットストリームが暗号化されているか否かを決定することを含み、該第１のビットストリームが暗号化されているとき、
第２のビットストリームを取得することと、
該ハードウェアの中に格納される前記デバイス特有の第１の秘密キーにアクセスするように動作可能な前記デバイスにおける前記ハードウェアを使用して、該第２のビットストリームを認証することであって、該第２のビットストリームを認証することは、
該第２のビットストリームに対応する第３のキーを取得することであって、該第３のキーは、該第２のビットストリームをハッシュし、該ハッシュされた第２のビットストリームを暗号化することによって作成される、ことと、
該第２のビットストリームをハッシュすることと、
該ハッシュされた第２のビットストリームを暗号化することによって第４のキーを生成することであって、該ハッシュされた第２のビットストリームの該暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイス特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第４のキーを該第３のキーと比較することであって、該第４のキーと該第３のキーとが整合するとき、該第２のビットストリームを該プロセッサにおいてセキュア化モードで実行する、ことと
含む、ことと
を含む、項目２に記載の方法。
（項目４）
前記第２のビットストリームをハッシュすることは、前記第１のビットストリームから生成された前記第２のキーをシード値として利用する、項目３に記載の方法。
（項目５）
前記第２のビットストリームは、第２の暗号化エンジンを含み、該第２のビットストリームを実行することは、前記デバイス特有の第１の秘密キーを使用して、前記第１のビットストリームおよび該第２の暗号化エンジンを用いて暗号化されたデジタルコンテンツの両方を復号化することを含み、該第２のビットストリームの実行は、セキュアモードで行われる、項目３に記載の方法。
（項目６）
前記第２のビットストリームの認証および前記第２のビットストリームの実行は、前記第１のビットストリームの実行の前に行われる、項目５に記載の方法。
（項目７）
前記第２のビットストリームの実行後、前記第１のビットストリームの実行前に、該第１のビットストリームを認証することをさらに含む、項目６に記載の方法。
（項目８）
前記第１のビットストリーム、第２のビットストリーム、暗号化されるデジタルコンテンツ、第１のキー、および第３のキーは、メッセージの中に受信されており、該メッセージは、
該第１のビットストリームの第１の暗号化エンジンを用いて、該デジタルコンテンツを暗号化することと、
該第１のビットストリームをハッシュし、前記デバイス特有の第１の秘密キーを用いて、該ハッシュされた第１のビットストリームを暗号化することによって、該第１のキーを生成することと、
該第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと、
該第２のビットストリームの第２の暗号化エンジンを用いて、該関連付けられた該第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを暗号化することと、
該第２のビットストリームをハッシュし、該デバイス特有の第１の秘密キーを用いて、該ハッシュされた第２のビットストリームを暗号化することによって、該第３のキーを生成することと、
第１の復号化アルゴリズムを該第１の暗号化されたビットストリームと関連付けることと、
該第３のキーと第２のビットストリームと暗号化された関連付けられた第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと
によって生成される、項目７に記載の方法。
（項目９）
コードの実行を制御するシステムであって、該システムは、
デバイスであって、
プロセッサと、
第１の秘密キーを格納する第１のハードウェアと、
第２のハードウェアであって、該プロセッサがセキュア化モードで実行しているときに、該第１の秘密キーにアクセスし、該第１の秘密キーを使用して、暗号化アルゴリズムを実装するように動作可能である第２のハードウェアと、
該プロセッサによって実行可能な命令を含むコンピュータ可読記憶媒体であって、該命令は、
第１のビットストリームを該デバイスにおいて受信することと、
該第１のビットストリームに対応する第１のキーを取得することであって、該第１のキーは、該第１のビットストリームをハッシュし、該ハッシュされた第１のビットストリームを暗号化することによって作成された、ことと、
該デバイスにおける該第２のハードウェアを使用して、該第１のビットストリームを認証することであって、該第１のビットストリームを認証することは、
該第１のビットストリームをハッシュすることと、
該ハッシュされた第１のビットストリームを暗号化することによって、第２のキーを生成することであって、該ハッシュされた第１のビットストリームの暗号化は、該デバイスの第２のハードウェアの中で行われ、該第２のハードウェアは、該デバイス特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第２のキーを該第１のキーと比較することと
を含む、ことと
該第２のキーと該第１のキーとが整合する場合、該プロセッサにおいて該第１のビットストリームをセキュア化モードで実行することと
を行うためのものである、コンピュータ可読記憶媒体と
を含む、デバイスを含む、システム。
（項目１０）
前記第１のビットストリームは、第１の暗号化エンジンを含み、該第１のビットストリームを実行することは、該第１の暗号化エンジンおよび前記デバイス特有の第１の秘密キーを使用して、該第１のビットストリームと関連付けられ暗号化されたデジタルコンテンツを復号化することを含み、該第１のビットストリームの実行は、セキュアモードで行われる、項目９に記載のシステム。
（項目１１）
前記第２のキーと前記第１のキーとが整合しない場合、前記命令は、
前記第１のビットストリームが暗号化されているか否かを決定することと、該第１のビットストリームが暗号化されているときは、
第２のビットストリームを取得することと、
該第１のハードウェアの中に格納される、前記デバイス特有の第１の秘密キーにアクセスするように動作可能である前記デバイスにおける前記第２のハードウェアを使用して、該第２のビットストリームを認証することであって、該第２のビットストリームを認証することは、
該第２のビットストリームに対応する第３のキーを取得することであって、該第３のキーは、該第２のビットストリームをハッシュし、該ハッシュされた第２のビットストリームを暗号化することによって生成される、ことと、
該第２のビットストリームをハッシュすることと、
該ハッシュされた第２のビットストリームを暗号化することによって、第４のキーを生成することであって、該ハッシュされた第２のビットストリームの暗号化は、該デバイスの該第２のハードウェアの中で行われ、該第２のハードウェアは、該デバイス特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第４のキーを該第３のキーと比較することと
を含む、ことと、
該第４のキーと該第３のキーとが整合する場合、前記プロセッサにおいて該第２のビットストリームをセキュア化モードで実行することと
を行うようにさらに動作可能である、項目１０に記載のシステム。
（項目１２）
前記第２のビットストリームをハッシュすることは、前記第１のビットストリームから生成された前記第２のキーをシード値として利用する、項目１１に記載のシステム。
（項目１３）
前記第２のビットストリームは、第２の暗号化エンジンを含み、該第２のビットストリームを実行することは、前記デバイス特有の第１の秘密キーを使用して、前記第１のビットストリームおよび該第２の暗号化エンジンを用いて前記暗号化されたデジタルコンテンツの両方を復号化することを含み、該第２のビットストリームの実行は、セキュアモードで行われる、項目１１に記載のシステム。
（項目１４）
前記第２のビットストリームの認証および前記第２のビットストリームの実行は、前記第１のビットストリームの実行の前に行われる、項目１３に記載のシステム。
（項目１５）
前記命令は、前記第２のビットストリームの実行後、前記第１のビットストリームの実行前に、該第１のビットストリームを認証するように動作可能である、項目１４に記載のシステム。
（項目１６）
前記第１のビットストリーム、第２のビットストリーム、暗号化されるデジタルコンテンツ、第１のキー、および第３のキーは、メッセージにおいて受信されており、該メッセージは、
該第１のビットストリームの第１の暗号化エンジンによって、該デジタルコンテンツを暗号化することと、
該第１のビットストリームをハッシュし、前記デバイス特有の第１の秘密キーを用いて該ハッシュされた第１のビットストリームを暗号化することによって、該第１のキーを生成することと、
該第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと、
該第２のビットストリームの第２の暗号化エンジンを用いて、該関連付けられた該第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを暗号化することと、
該第２のビットストリームをハッシュし、該デバイス特有の第１の秘密キーを用いて該ハッシュされた第２のビットストリームを暗号化することによって、第３のキーを生成することと、
第１の復号化アルゴリズムを該第１の暗号化されたビットストリームと関連付けることと、
該第３のキーと第２のビットストリームと暗号化され関連付けられた第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと
によって生成される、項目１５に記載のシステム。
（項目１７）
終点デバイスにおけるコードの実行を制御するプロセッサによって実行可能な命令を含むコンピュータ可読媒体であって、
第１のビットストリームをデバイスにおいて受信することと、
該第１のビットストリームに対応する第１のキーを取得することであって、該第１のキーは、該第１のビットストリームをハッシュし、該ハッシュされた第１のビットストリームを暗号化することによって作成される、ことと、
デバイス特有の第１の秘密キーにアクセスするように動作可能である該デバイスにおけるハードウェアを使用して、該第１のビットストリームを認証することであって、該デバイス特有の第１の秘密キーは、該デバイスのハードウェアの中に格納され、該デバイスがセキュア化モードで実行しているときにアクセス可能であり、該第１のビットストリームを認証することは、
該第１のビットストリームをハッシュすることと、
該ハッシュされた第１のビットストリームを暗号化することによって、第２のキーを生成することであって、該ハッシュされた第１のビットストリームの暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイス特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第２のキーを該第１のキーと比較することと
を含む、ことと、
該第２のキーと該第１のキーとが整合する場合、該第１のビットストリームを該プロセッサにおいてセキュア化モードで実行することと
を行うための実行可能な命令を含む、コンピュータ可読媒体。
（項目１８）
前記第１のビットストリームは、第１の暗号化エンジンを含み、該第１のビットストリームを実行することは、該第１の暗号化エンジンおよび前記デバイス特有の第１の秘密キーを使用して、該第１のビットストリームと関連付けられ暗号化されたデジタルコンテンツを復号化することを含み、該第１のビットストリームの実行は、セキュアモードで行われる、項目１７に記載の方法。
（項目１９）
前記第２のキーと前記第１のキーとが整合しない場合、前記命令は、
前記第１のビットストリームが暗号化されているか否かを決定することと、該第１のビットストリームが暗号化されている場合、
第２のビットストリームを取得することと、
前記ハードウェアの中に格納される前記デバイス特有の第１の秘密キーにアクセスするように動作可能である前記デバイスにおける該ハードウェアを使用して、該第２のビットストリームを認証することであって、該第２のビットストリームを認証することは、
該第２のビットストリームに対応する第３のキーを取得することであって、該第３のキーは、該第２のビットストリームをハッシュし、該ハッシュされた第２のビットストリームを暗号化することによって作成される、ことと、
該第２のビットストリームをハッシュすることと、
該ハッシュされた第２のビットストリームを暗号化することによって、第４のキーを生成することであって、該ハッシュされた第２のビットストリームの暗号化は、該デバイスのハードウェアの中で行われ、該ハードウェアは、該デバイス特有の第１の秘密キーにアクセスすることを試み、該暗号化において該アクセスの結果を使用する、ことと、
該生成された第４のキーを該第３のキーと比較することと
を含む、ことと、
該第４のキーと該第３のキーとが整合する場合、該第２のビットストリームを該プロセッサにおいてセキュア化モードで実行することと
を行うようにさらに動作可能である、項目１８に記載のコンピュータ可読媒体。
（項目２０）
前記第２のビットストリームをハッシュすることは、前記第１のビットストリームから生成された前記第２のキーをシード値として利用する、項目１９に記載のコンピュータ可読媒体。
（項目２１）
前記第２のビットストリームは、第２の暗号化エンジンを含み、該第２のビットストリームを実行することは、前記デバイス特有の第１の秘密キーを使用して、該第１のビットストリームおよび該第２の暗号化エンジンを用いて前記暗号化されたデジタルコンテンツの両方を復号化することを含み、該第２のビットストリームの実行は、セキュアモードで行われる、項目１９に記載のコンピュータ可読媒体。
（項目２２）
前記第２のビットストリームの認証および前記第２のビットストリームの実行は、前記第１のビットストリームの実行の前に行われる、項目２１に記載のコンピュータ可読媒体。
（項目２３）
前記前記第２のビットストリームの実行後、前記第１のビットストリームの実行前に、該第１のビットストリームを認証することをさらに含む、項目２２に記載のコンピュータ可読媒体。
（項目２４）
前記第１のビットストリーム、第２のビットストリーム、暗号化されたデジタルコンテンツ、第１のキー、および第３のキーは、メッセージにおいて受信されており、該メッセージは、
該第１のビットストリームの第１の暗号化エンジンを用いて、該デジタルコンテンツを暗号化することと、
該第１のビットストリームをハッシュし、前記デバイス特有の第１の秘密キーを用いて、該ハッシュされた第１のビットストリームを暗号化することによって、該第１のキーを生成することと、
該第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと、
該第２のビットストリームの第２の暗号化エンジンを用いて、該関連付けられた第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを暗号化することと、
該第２のビットストリームをハッシュし、該デバイス特有の第１の秘密キーを用いて該ハッシュされた第２のビットストリームを暗号化することによって、第３のキーを生成することと、
第１の復号化アルゴリズムを該第１の暗号化されたビットストリームと関連付けることと、
該第３のキーと第２のビットストリームと暗号化され関連付けられた第１のキーと第１のビットストリームと暗号化されたデジタルコンテンツとを関連付けることと
によって生成される、項目２３に記載のコンピュータ可読媒体。
【０００８】
本発明のこれらおよび他の側面は、以下の説明ならびに添付図面と併用して検討されることによって、さらに認識および理解されるであろう。しかしながら、本発明の種々の実施形態およびそれらの多数の特有の詳細を示す以下の説明は、限定ではなく、例示として与えられることを理解されたい。多くの解決策、修正、追加、および／または再配設が、その精神から逸脱することなく発明の範囲内で行われ得、本発明は、あらゆるそのような解決策、修正、追加、および／または再配設を含んでいる。
【図面の簡単な説明】
【０００９】
本明細書に付随かつその一部を形成する図面は、本発明のある側面を図示するために含まれる。本発明ならびに本発明が提供されるシステムの構成要素および動作のより明確な概念は、例示的であって、したがって、限定ではない、図面に例示される実施形態を参照することによって、より容易に明白となるであろう（同一の参照番号は、同一の構成要素を示す）。本発明は、本明細書に提示される説明と組み合わせて、これらの図面のうちの１つ以上を参照することによって、さらに理解され得る。図面に例示される特徴は、必ずしも、正確な縮尺で図示されていないことに留意されたい。
【図１】図１は、コンテンツ配信のためのアーキテクチャの一実施形態を図示する。
【図２】図２は、標的ユニット汎用コンピューティングデバイスの一実施形態を図示する。
【図３】図３は、複合キーの作成の一実施形態を図示する。
【図４Ａ】図４Ａおよび図４Ｂは、デジタル署名またはそれらの同等物の作成の実施形態を図示する。
【図４Ｂ】図４Ａおよび図４Ｂは、デジタル署名またはそれらの同等物の作成の実施形態を図示する。
【図５Ａ】図５Ａおよび５Ｂは、複合キー構造とセキュア化コードブロックの使用の実施形態を図示する。
【図５Ｂ】図５Ａおよび５Ｂは、複合キー構造とセキュア化コードブロックの使用の実施形態を図示する。
【図６】図６は、複合メッセージダイジェストの使用の一実施形態を図示する。
【図７Ａ】図７Ａ、７Ｂおよび７Ｃは、セキュア化コードブロックメッセージの実施形態を図示する。
【図７Ｂ】図７Ａ、７Ｂおよび７Ｃは、セキュア化コードブロックメッセージの実施形態を図示する。
【図７Ｃ】図７Ａ、７Ｂおよび７Ｃは、セキュア化コードブロックメッセージの実施形態を図示する。
【図８】図８は、復号化動作のある実施形態を図示する。
【図９】図９は、複合キーの使用の一実施形態を図示する。
【図１０】図１０は、候補コードブロックの承認における複合キーの使用の一実施形態を図示する。
【図１１】図１１は、復号化動作の一実施形態を図示する。
【図１２】図１２は、コードブロックの照合の一実施形態を図示する。
【図１３】図１３は、再帰的セキュリティプロトコルを使用して行われる、復号化動作の一実施形態を図示する。
【図１４】図１４は、コード照合の動作の一実施形態を図示する。
【図１５】図１５は、デジタル署名機能ブロックの一実施形態を図示する。
【発明を実施するための形態】
【００１０】
本発明および種々の特徴ならびにそれらの有利な詳細は、添付の図面に例示され、以下の説明において詳述される非限定的な実施形態を参照して、より完全に説明される。周知の開始材料、処理技術、構成要素、および機器の説明は、詳細において、本発明を不必要に曖昧化しないために省略される。しかしながら、本発明の好ましい実施形態を示す、発明を実施するための形態および特有の実施例は、限定としてではなく、例示としてのみ与えられることを理解されたい。基礎となる本発明の概念の精神および／または範囲内の種々の代用、修正、追加、および／または再配設は、本開示から、当業者には明白となるであろう。本明細書に論じられる実施形態は、コンピュータ可読媒体（例えば、ＨＤ）、ハードウェア回路等、または任意の組み合わせ上に常駐し得る、好適なコンピュータ実行可能命令として実装可能である。
【００１１】
特有の実施形態について論じる前に、ある実施形態を実装するためのハードウェアアーキテクチャの実施形態が、本明細書において説明される。一実施形態は、ネットワークに通信可能に結合される１つ以上のコンピュータを含むことが可能である。当業者に周知のように、コンピュータは、中央処理装置（「ＣＰＵ」）、少なくとも１つの読取専用メモリ（「ＲＯＭ」）、少なくとも１つのランダムアクセスメモリ（「ＲＡＭ」）、少なくとも１つのハードドライブ（「ＨＤ」）、および１つ以上の入／出力（「Ｉ／Ｏ」）デバイスを含むことが可能である。Ｉ／Ｏデバイスは、キーボード、モニタ、プリンタ、電子ポイントデバイス（マウス、トラックボール、スタイレット等）等を含むことが可能である。種々の実施形態では、コンピュータは、ネットワーク上の少なくとも１つのデータベースへのアクセスを有する。
【００１２】
ＲＯＭ、ＲＡＭ、およびＨＤは、ＣＰＵによって、コンピュータ実行可能な命令（すなわち、直接実行可能である、または、例えば、コンパイル、変換等によって、実行可能となる）を格納するためのコンピュータメモリである。本開示では、用語「コンピュータ可読媒体」とは、ＲＯＭ、ＲＡＭ、およびＨＤに限定されず、プロセッサによって読取可能な任意の種類のデータ記憶媒体を含むことが可能である。いくつかの実施形態では、コンピュータ可読媒体は、データカートリッジ、データバックアップ磁気テープ、フロッピー（登録商標）ディスク、フラッシュメモリドライブ、光学データ記憶ドライブ、ＣＤ−ＲＯＭ、ＲＯＭ、ＲＡＭ、ＨＤ等を指し得る。
【００１３】
本明細書に説明される機能またはプロセスの少なくとも一部は、好適なコンピュータ実行可能命令として実装可能である。コンピュータ実行可能命令は、１つ以上のコンピュータ可読媒体上のソフトウェアコード構成要素またはモジュールとして格納され得る（不揮発性メモリ、揮発性メモリ、ＤＡＳＤアレイ、磁気テープ、フロッピー（登録商標）ディスク、ハードドライブ、光学記憶デバイス等、あるいは任意の他の適切なコンピュータ可読媒体または記憶デバイス等）。一実施形態では、コンピュータ実行可能命令は、一連のコンパイルされたＣ＋＋、Ｊａｖａ（登録商標）、ＨＴＭＬ、あるいは任意の他のプログラミングまたはスプリプティングコードを含み得る。
【００１４】
加えて、開示される実施形態の機能は、１つのコンピュータ上に実装されるか、あるいはネットワーク内またはネットワークを介して、２つ以上のコンピュータ間で共有／分散されてもよい。実施形態を実装するコンピュータ間の通信は、既知のネットワークプロトコルに準拠して、任意の電子、光学、無線周波数信号、または他の好適な通信の方法およびツールを使用して、達成可能である。
【００１５】
本明細書で使用されるように、用語「ｃｏｍｐｒｉｓｅｓ（備える）」、「ｃｏｍｐｒｉｓｉｎｇ（備えている）」、「ｉｎｃｌｕｄｅｓ（含む）」、「ｉｎｃｌｕｄｉｎｇ（含んでいる）」、「ｈａｓ（有する）」、「ｈａｖｉｎｇ（有している）」、またはそれらの任意の他の変形例は、非排他的包含を網羅することが意図される。例えば、要素の列挙を備える、プロセス、工程、物品、または装置は、必ずしも、それらの要素のみに限定されず、明示的に列挙されない、あるいはそのようなプロセス、工程、物品、または装置に付随しない他の要素を含んでもよい。さらに、そうではない旨が明示的に記述されない限り、「ｏｒ（または）」とは、包含的「ｏｒ」を指し、排他的「ｏｒ」を指すわけではない。例えば、条件ＡまたはＢは、以下のうちの任意の１つによって充足される。Ａは真（または、存在する）であって、Ｂは偽である（または、存在しない）、Ａは偽であって（または、存在しない）、Ｂは真である（または、存在する）、ならびにＡおよびＢの両方が、真である（または、存在する）。
【００１６】
加えて、本明細書において与えられる任意の実施例または例示は、それらが利用される任意の用語または複数の用語の定義に関する制限、限定、あるいはそれらの表明として、いかようにもみなされるものではない。代わりに、これらの実施例または例示は、１つの特定の実施形態に関して、例示のみとして説明されるものとみなされるべきである。当業者は、これらの実施例または例示が利用される、任意の用語あるいは複数の用語が、それらとともに、または明細書内のいずれかに与えられ得る、あるいは与えられ得ない、他の実施形態をも包含し、あらゆるそのような実施形態は、その用語または複数の用語の範囲内に含まれることが意図されることを理解するであろう。そのような非限定的実施例および例示を指す言葉として、「ｆｏｒ  ｅｘａｍｐｌｅ（例えば）」、「ｆｏｒ  ｉｎｓｔａｎｃｅ（例えば）」、「ｅ．ｇ．（例えば）」、「ｉｎ  ｏｎｅ  ｅｍｂｏｄｉｍｅｎｔ（一実施形態では）」を含むが、それららに限定されない。
【００１７】
上述のように、プロセッサに、所定の方法において、任意のコードのセグメントを実行させることが望ましい。この制御の問題は、合法ソフトウェアでさえ、操作するか、意図しないか、またはさらに悪質な結果をもたらし得る、多くの多様な方法によって悪化する。これらの攻撃の方法として、入力データの稀なケースまたはさらに他のアルゴリズムの欠損を悪用するために、偽引数を入力としてルーチンにフィードすることによって、不完全に書き込まれてはいるが、その他の点においては有効なコードを利用することを含み得る。他の可能性のある攻撃の手段として、不適切または意図的に誤った結果をもたらすように、その他の点においては合法的であるコードによって参照される種々のプロセッサレジスタ（スタックポインタ等）あるいは外部記憶場所内に格納されているデータを個別に書き換えることを含む。
【００１８】
この種類の制御が影響を受け得るいくつかのメカニズムが存在する。これらのシステムは、この種類の意図しない使用からプロセッサを保護することを試みる、単純な方式だけではなく、複雑な方式も含む。合理的にセキュアではあるが、複雑なメカニズムの１つとして、その実行に先立って、コードセグメントを事前に暗号化することを含む。コードセグメントが、メモリからプロセッサにロードされると、注意深く制御された環境下において復号され、次いで、セキュアな態様で実行されなければならない（言い換えると、復号化動作と後続の実行との間において書き換えまたは改ざんされてはならない）。このメカニズムは、プロセッサが、当該コードセグメントが、実行開始可能となることに先立って、復号されるまで、待機しなければならないために被り得る性能上の非効率性に悩まされる。実行される特定のコードセグメントの選択と、実際の復号化後の実行との間のこの待ち時間は、プロセッサパイプラインの失速およびデータパスの非効率性を含むが、それらに限定されない多くの問題を生じさせるだけではなく、潜在的攻撃のための別の手段を提供し得る（復号化と実行動作との間に、何らかの形でコードを奪取することによる）。
【００１９】
また、この暗号化されたコードメカニズムは、表面上保護されている暗号化コードセグメントを適切に復号化しようとする（または、復号化されたコピーを取得する）ハッカーの不測の事態からプロセッサを保護するものでは全くない。その場合、次いで、彼らは、標的プロセッサまたはある他の非承認プロセッサのいずれかにおいて、その非保護コードを非制御態様で起動し得る。したがって、コードが、暗号化されていない状態（すなわち、プレーンテキスト形式）において、または暗号化された形式で配信されているかどうかにかかわらず、どのコードセグメントが、特定のプロセッサまたは複数のプロセッサにおいて起動可能であるかを正確に制御する方法を見出すことが好ましい。一方、特定のプロセッサにおいて起動可能なコードが、ある事前に選択されたサブ集合に限定される場合、プロセッサ自体の汎用的性質が侵害され得る。これは、可能性として、プロセッサの汎用性が低くなり、したがって、その潜在的応用の余地における柔軟性がほとんどなくなるようにアーキテクチャを制約する影響を有し得る。最大限に柔軟性のある汎用プロセッサアーキテクチャが、常に、強く求められているが、マルウェア攻撃を最も受けやすいのは、正にそれらのプロセッサである。
【００２０】
したがって、任意の特定のプロセッサアーキテクチャに依存しない、十分に汎用性のあるコード実行の制御のための方法の必要性が存在する。また、そのような方法が、標的プロセッサのオブジェクトコード密度または実行パイプラインのいずれにも悪影響を及ぼさないかどうかも有用であろう。同時に、そのようなシステムおよび方法が、オリジナルの標的プロセッサまたはある他の意図されない標的プロセッサのいずれかにおける、その他の点において合法的であるコードセグメントの無許可使用に対する保護を提供することが望ましい。そのような方法は、ソフトウェアウイルスおよびマルウェアの制御のための競争における貴重なツールとなるだけではなくデジタルコンテンツの世界において、著作権を保護するための一意的強力なメカニズムとなるであろう。
【００２１】
これを受けて、汎用コードブロックの実行に対する高度に特有の制御を提供し、それによって、所与のコードブロックが実行されるまさにその環境下においてプログラマが決定することを可能にするシステムおよび方法の実施形態に焦点が向けられる。これらの条件として、コードブロックが実行を試みる個々のデバイス、コードブロックが呼び出される環境、実行の時間、実行の順序だけではなく、コードブロックが特定の実行スレッドにおいて呼び出された回数等の制約を含み得る（しかしながら、それらに限定されない）。
【００２２】
そのような制御メカニズムは、例えば、一実施形態では、再帰的実行を介して実装される、呼び出されたコードセグメント集合の明示的に順序付けられた実行に基づいて、データ隠蔽システムおよび方法の実施形態と結合されてもよい。これらのシステムおよび方法の実施形態がともに利用されると、妨害されることのない普遍性だけではなく、多くの他のセキュリティシステムに勝る攻撃に対する一定レベルの保護が得られ得る。
【００２３】
実施形態をより詳細に論じる前に、本発明の実施形態が効果的に利用され得るアーキテクチャの一般的概要を与えることが、有用となるであろう。図１は、そのようなトポロジの一実施形態を図示する。ここでは、コンテンツ配信システム１０１は、プロトコルエンジンを備える１つ以上の標的ユニット１００（また、本明細書では、終点デバイスとも呼ばれる）にデジタルコンテンツ（例えば、音声または映像データ、ソフトウェアアプリケーション等を備える、ビットストリームであってもよい）を配信するように動作し得る。これらの標的ユニットは、例えば、有線または無線ネットワーク、あるいはネットワークで結ばれていないコンピュータデバイス上のコンピューティングデバイスの一部であってもよく、そのようなコンピューティングデバイスとして、例えば、ネットワークを介して、または、例えば、メール等を介して送達され得るコンピュータ可読記憶媒体上で、ビットストリームとして送達されるコンテンツを再生し得る、パーソナルコンピュータ、携帯電話、携帯端末、メディアプレーヤを含む。後述のように、このデジタルコンテンツは、デジタルコンテンツの実行の制御が、デジタルコンテンツに関して制御され、セキュアに実装され得るように、構成または配信されてもよい。
【００２４】
図２は、受信したデジタルコンテンツと併せて、デジタルコンテンツの実行の制御またはセキュリティプロトコルの実装が可能な標的ユニットの一実施形態のアーキテクチャを図示する。標的ユニットの要素は、標的ユニット１００のプロトコルエンジン上にセキュアな態様でプロトコルを実装するブロック集合を含んでもよい。これらのブロックは、この実施形態において、ハードウェアとして説明されるが、ソフトウェアを利用し、同様の効果を有する類似機能を達成してもよいことに留意されたい。また、ある実施形態は、ここに説明される全ブロックを含んでもよい一方で、他の実施形態では、より少ないか、または付加的なブロックを利用してもよいことに留意されたい。
【００２５】
これらのブロックの第１は、リアルタイムクロックまたは日付／時間レジスタ１０２である。これは、中央サーバとのセキュアな交信によって設定またはリセット可能な自走タイマである。時間は、セキュアな時間標準についてクエリを行うことによって確立され得るので、この機能を内蔵することはより便宜的となり得る。また、標的ユニット１００は、十分にランダムな数の並びを生成するように構成され得るか、または、次に疑似乱数発生システムに対するシード値を供給するために使用可能である乱数発生器１８０を備えてもよい。また、この疑似乱数発生器は、潜在的に、ハードウェア、ソフトウェア、または「セキュアな」ソフトウェアの中に実装可能である。
【００２６】
一方向ハッシュ関数ブロック１６０は、ハッシュ機能を実質的にハードウェアの中に実装するように動作可能であってもよい。標的ユニット１００の別の部分は、ハードウェア支援暗号化／復号化システム１７０であって、これは、実行可能コードブロックに変換するために、標的ユニット１００の秘密キーまたは公開／個人キー（後述）を使用して、暗号化されたメッセージに作用するか、あるいは非暗号化データに作用し、暗号化されたメッセージに変換する。この復号化システム１７０は、いくつかの方法で実装可能である。また、一方向ハッシュ関数と後続の暗号化／復号化システムとの組み合わせは、任意のデジタルデータが暗号化形式またはプレーンテキスト形式で配信されているかどうか、そのデータの照合のために使用可能なデジタル署名発生器を備えてもよいことに留意されたい。プロトコル全体の速度およびセキュリティは、このブロックの構造に応じて変動してもよく、したがって、セキュリティシステムのアップデートに対応するために十分に柔軟であるだけでなく、システムに、時間クリティカルなメッセージのリアルタイム復号化を行わせることに十分に高速であるように構成され得る。
【００２７】
これに留意すると、正確にどの暗号化アルゴリズムが、このハードウェアブロック１７０に対して使用されるかは、プロトコルの実施形態にとって重要ではない。最大の柔軟性を促進するために、実際のハードウェアは、非アルゴリズム的に特有の態様で使用されることに十分に汎用性であることが想定されるが、このメカニズムを実装可能な多くの異なる手段が存在する。この点において、用語「暗号化」および「復号化」とは、暗号化／復号化を行うためのエンジン（アルゴリズム、ハードウェア、ソフトウェア等）を指す場合、本明細書では互換可能に利用されることに留意されたい。理解されるように、対称暗号化が、ある実施形態で使用される場合、同一または類似の暗号化あるいは復号化エンジンが、暗号化と復号化の両方のために使用されてもよい。
【００２８】
別のブロックは、実行されるコードを記憶可能であるメモリ１１０である。これは、一般的には、命令キャッシュ（Ｉ−キャッシュ）として知られている。いくつかの実施形態では、このＩ−キャッシュ１１０の一部の重要な特徴は、あるブロック内に含有されるデータが、ＣＰＵ実行ユニット１２０によってのみ可読であることである。言い換えると、Ｉ−キャッシュメモリ１３０のこの特定のブロックは、任意のソフトウェアによる実行専用であって、そこからの読取り、またはそこへの書込みができない。また、Ｉ−キャッシュのこのブロックは、本明細書では、「セキュア化Ｉ−キャッシュ」１３０と呼ばれる。実行されるコードが、このセキュア化Ｉ−キャッシュブロック１３０内に格納される態様は、図示され得るか、またはされ得ない別のブロックを経由してもよい。通常、当技術分野において知られるように、Ｉ−キャッシュ１５０を利用して通常実行されるコードを格納してもよい。
【００２９】
加えて、いくつかの実施形態では、あるブロックを使用して、セキュアなコードブロックの動作を加速してもよい。故に、ＣＰＵレジスタ集合１４０は、ＣＰＵ１２０が、セキュアなコードを実行中、アクセスのみ可能、またはセキュアなコードブロック（セキュアモードと呼ばれるセキュア化コードブロック１３０内の命令）の実行の完了に応じて、あるいは、何らかの理由から、セキュア化Ｉ−キャッシュ１３０内に格納されるコードの実行の際に、非セキュアまたは「通常」のＩ−キャッシュもしくは他のエリア内に位置するコードの任意のセクションへのジャンプが生じる場合、消去されるように規定されてもよい。
【００３０】
一実施形態において、ＣＰＵ実行ユニット１２０は、どのレジスタ１４０が、セキュア化コードブロック１３０内に格納されたコードを実行中に、読み取られるか、または書き込まれるかを追跡し、次いで、「セキュア化実行」モードの終了に対応してこれらのレジスタを自動的に消去するように構成されてもよい。これは、セキュア化コード自体に、２つの種類のコードブロック間で共有が許可されているデータのみが保全されるように、迅速に「後始末」を行わせる。別の可能性は、セキュア化コードブロック１３０内で実行されるコードの著者が、どのレジスタ１４０が消去されるべきかを明示的に識別可能であることである。
【００３１】
セキュアと非セキュアなコードセグメントとの間のレジスタ１４０内に格納されたデータの「漏洩」に対処するための別の潜在的態様は、ＣＰＵ１２０がセキュア化コードを実行中にのみ使用されるレジスタ集合１４０を識別することである。一実施形態では、これは、多くの最新ＣＰＵ設計において実践されるレジスタリネームおよびスコアボードメカニズムの一種を利用して達成されてもよい。セキュア化コードブロックの実行が、アトミックアクション（すなわち、割込み不可能である）として処理される場合、このリネームおよびスコアボードの実装をより容易にし得る。
【００３２】
ＣＰＵ１２０が、「セキュア化」コード（セキュア化コードブロック１３０内のコード）と「非セキュア化コード」（通常Ｉ−キャッシュ１５０等の別の場所またはメモリの別の場所内のコード）との混合を実行する可能性はほとんどないように思われ得るが、そのような環境は、割込みルーチン内にジャンプする場合等、コンテキストを切り替えるプロセスにおいて、またはＣＰＵ１２０のコンテキストが格納される場所に応じて生じ得る（大部分のＣＰＵは、潜在的に、メインメモリ内にコンテキストを格納し、そこでは、非セキュア化コードブロックによる発見および操作を被る）。
【００３３】
この不測の事態に対する保護を支援するために、一実施形態では、実行中に割り込まれたセキュア化コードブロックの実行の際に得られた結果がシステム内の他の実行スレッドに曝露されることを防止するために利用され得る別の方法は、プロセッサがセキュア化実行モードで動作中、スタックプッシュを無効にすることである。このスタックプッシュの無効化は、セキュア化コードブロックが、その通常完了に先立って、割り込まれる場合、再開不可能であって、したがって、最初から再開されなければならないという点において、セキュア化コードブロックが、このように、割込み不可能であるということを意味するであろう。ある実施形態では、「セキュア化実行」モードが、プロセッサ割込みの際に無効化される場合、また、セキュア化コードブロックは、潜在的に、呼出し連鎖全体が再開されない限り、再開不可能であり得ることに留意されたい。
【００３４】
また、各標的ユニット１００は、秘密キー定数１０４の２つの集合（そのうちのいずれの値も、ソフトウェア読取り不可能である）を有してもよい。これらのキー（一次秘密キー）の第１のものは、秘密キー集合として体系化されてもよく、そのうちの１つだけが、任意の特定の時間に可読である。ユニットの「所有権」が変更される場合（例えば、プロトコルエンジンを含有する機器が販売されるか、またはその所有権が、別様に譲渡される）、現在アクティブな一次秘密キーは「消去される」か、または異なる値によって上書きされてもよい。この値は、セキュアな態様でユニットに転送可能であるか、またはこの第１のキーが消去されるときにのみ使用されるような態様でユニットに既に格納され得る。事実上、これは、その所有権が変更されるとき、またはそのような変更のある他の理由が存在する場合（危殆化キー等）、その特定のユニットに対して新しい一次秘密キーを発行することに相当する。二次秘密キーは、標的ユニット１００自体と併用されてもよい。標的ユニット１００のＣＰＵ１２０は、一次または二次秘密キーのいずれかの値にそもそもアクセス不可能であるため、ある意味、標的ユニット１００は、その独自の秘密キー１０４を「把握」さえしていないことになる。これらのキーは、標的ユニットのＣＰＵ１２０のセキュリティブロックの中に格納され、その中で使用されるだけである。
【００３５】
さらに別のキー集合が、一時的公開／個人キーシステム（また、非対称キーシステムまたはＰＫＩシステムとしても知られる）の一部として動作してもよい。この対のキーは、高速で生成され、中央サーバの介入なく、類似ユニット間のセキュアな通信リンクを確立するために使用されてもよい。そのようなシステムのセキュリティは、一般的には、同等キー長の対称キー暗号化システムより低いため、これらのキーは、上述の秘密キー集合よりサイズが大きくなり得る。これらのキーは、特に、「リプレー攻撃」に対して防護するために、オンチップタイマブロック内に存在する値と併用されてもよい。これらのキーは、高速で生成されるので、それらが生成される態様は、乱数発生システム１８０に依存し得る。
【００３６】
一実施形態では、特定の標的ユニットの「所有権」の変更に影響を及ぼすために使用可能な方法の１つは、タイムスタンプまたはタイムスタンプ値と呼ばれる別のキー１０７と併せて、一次秘密キーを複合キーとして常に使用することである（このキーの値は、変更され得（言い換えると、異なる時間で異なる値を有し得る）、必ずしも、現在の日時を反映し得ないため）。このタイムスタンプ値自体は、構造上可視であってもよく、またはそうでなくてもよい（すなわち、必ずしも、秘密キーではあり得ない）が、それでもなお、標的ユニットが、セキュア化実行モードで動作中でない限り、書換え不可能となるであろう。そのような場合、一次秘密が使用される場合は常に、複合キーの構成要素として、タイムスタンプ値を一貫して使用することは、本質的に、別個の値に切り替えられた場合と同一効果をもたらすことが可能であって、したがって、一次秘密キー自体を書き換える必要なく、効果的に、特定の標的終点ユニットの「所有権の変更」を可能にする。
【００３７】
ここで、標的ユニットの一方向ハッシュ関数ハードウェアに関する更なる詳細を述べることが有用となるであろう。次に、図１５を参照すると、後続の反復における一方向ハッシュ関数のためのシード値として、再帰的セキュリティプロトコルの１回の反復において生成されたデジタル署名動作の結果を使用可能な一方向ハッシュ関数ブロックの一実施形態が、図示されている。一実施形態では、標的ユニットの状態は、セキュア化実行モードで動作中であるかどうかに関連する限り、本明細書で「セキュア化モード有効化」ビットと呼ばれる、ハードウェアビット１５７０の値に反映可能である。
【００３８】
ここでは、このハードウェアビットのデフォルト状態は消去されてもよい（すなわち、標的プロセッサのデフォルト状態は、セキュア化実行モードにおいて動作することができない）。ある実施形態における、一方向ハッシュ関数ハードウェアブロック１５６１とのこのビットの交信は、２つに分けて説明されてもよい。第１の（非セキュア化）場合、「セキュア化モード有効化」ビットが、このハードウェアビットが設定されると（例えば、「１」に、しかしながら、また、あるアーキテクチャでは、ビットは、「０」の値を有するときに「設定された」とみなされてもよいことに留意されたい）、秘密ハードウェアキーの使用のみを可能にするゲートキーパーとして作用するため、秘密ハードウェアキー１５４０へのアクセスはすべて阻止される。また、この場合、デジタル署名レジスタ１５６４の出力がフィードバックされ、一方向ハッシュ関数１５６１の入力「シード」１５１０を形成する。したがって、プロセッサが、この「非セキュア化実行」モードにおいて実行中、一方向ハッシュ関数演算のいずれかの中間結果がフィードバックされ、任意の後続の一方向ハッシュ関数演算のためのシードを形成する。これは、ネスト化または連結された機能集合の呼出し連鎖全体に相当する自走チェックサムを維持可能にする。実行が試みられる各コードブロックが、実行が可能になることに先立って、この一方向ハッシュ関数によって、最初に評価される場合、任意の所与のコードブロックの呼出し連鎖全体が、実質的に、この単一メカニズムによって明確に決定可能である。
【００３９】
同様に、「セキュア化モード有効化」ビットが設定される場合（すなわち、プロセッサが、「セキュア化実行モード」で動作中の場合）、秘密ハードウェアキーは、アクセス可能である（言い換えると、直接アクセス可能、またはその値がプロセッサ自体によって直接アクセス可能ではない場合でも、少なくともその値は、計算動作において使用可能である）。加えて、セキュア化実行モードで動作時に、デジタル署名レジスタの出力は、一方向ハッシュ関数の後続の評価のためのシード値を形成するために、フィードバックされない。このデジタル署名発生器ブロックのまさにその実装については、後にさらに詳細に論じられる。次いで、理解されるように、ある実施形態では、特定のコードブロックの呼出し連鎖全体が、システム全体のソフトウェアまたはハードウェア照合（または、認証）動作等の手段を利用する必要なく、そのセキュアな実行に先立って照合可能である。タイムスタンプレジスタに関して上述の場合のように、ある実施形態では、この「セキュア化モード有効化」ビットは、プロセッサに対して構造上可視であってもよく、またはそうでなくてもよいが、その状態は、プロセッサによって、明示的に設定されなくてもよいことに留意されたい。このハードウェアビットは、非セキュア化コードセグメントを読み出すことによって、デフォルト値にリセットされ得るが、一実施形態では、このビットが設定可能な唯一の態様は、ハードウェアの一部への直接作用を介してである。ビットが、構造上可視である場合、プロセッサが、セキュア化実行モードで動作中であるかどうかを明示的に決定可能である。構造上可視ではない場合、それでもなお、決定は、その値がハードウェア秘密キーに何らかの形で依存する何らかの式を評価することによって、黙示的に可能である。
【００４０】
ここで、コード実行の制御およびセキュリティプロトコルの実装と密接な関係があり得る、主題に内在する基本的問題について、さらに詳細に説明することは、有用となるであろう。次いで、上述のハードウェアの実施形態を使用して、任意の汎用プロセッサ上の任意コードの実行の制御をどのように実装するか、ならびにこれらのシステムおよび方法の実施形態が、どのようにセキュリティプロトコルおよびシステムと効果的に併用され、効果的セキュリティシステム全体を構築し得るかを示すことが可能となる。
【００４１】
（秘密キーの隠蔽）
市販のデジタルコンテンツ送達システムの大部分は、デジタルメディアデータが自由に複製および配信されることを保護しようとする、ある形式の暗号化またはデータ隠蔽を含む。大部分の場合、データ隠蔽戦略は、最終的には、コンテンツ保護の完全に非効果的な手段であることがわかる。この隠蔽が不成功であることがわかる主要な理由の１つは、曝露から保護されるべきまさにそのデータが、それでもなお、任意の承認された当事者による使用に対して自由に利用可能でなければならないことである。したがって、一見矛盾した要件集合が、デジタルコンテンツの配信には存在する。
【００４２】
オリジナルデジタルコンテンツが、意図された受信者すべてに対して、別個に暗号化可能であって、意図された受信者のみが、配信されたデジタルコンテンツを利用し得る場合、システムのセキュリティは、潜在的に、非常に優れたものとなることが可能である。しかしながら、いくつかの特有の条件が合致しない限り、この種類のシステムのセキュリティは、いくつかの点において、不完全があることが示され得る。第１に、そのようなシステムは、配信されたデータ集合全体が、各意図された受信者に対して、別個に再暗号化されなければならないことを必要とする点において、あまり効率的ではない。第２に、配信者は、汎用プロセッサ上において、いかなる未承認の復号化も不可能であることを保証する必要があり得る。第３に、各個々の受信デバイスが、別の終点デバイスにおいては容易に複製（または、汎用プロセッサ上でエミュレート）できない、ある属性を保有しなければならないという点において、一意的でなければならない。これらの最後の２つの条件のうちのいずれかが侵害される場合、このシステムは、個々に暗号化されたデータだけではなく、そのデータと関連付けられたデバイス特有のキーの両方を傍受することによって簡単に攻撃を受けやすくなる。
【００４３】
実際、そのようなシステムのセキュリティは、受信デバイスのそれぞれの一意的な属性のセキュリティに基づき得ることが分かる。この一意的な属性は、一般的には、配信者および承認受信者のみに知られている秘密キーを使用して実装される。原則として、この種類の設定は、効果的セキュリティシステムであり得るが、オリジナルデジタルコンテンツが、各受信者に対して別個に暗号化されるという要件は、大部分の目的に対して現実の実装を非実用的にする。オリジナルデジタルコンテンツが一度暗号化され、潜在的に承認された当事者すべてに完全に同じように配信されることが望ましいならば、問題はデータ隠蔽へと逆戻りする。これらの種類の問題は、ブロードキャスト暗号化の分野として知られている。
【００４４】
ほとんどのあらゆる種類の配信された秘密データシステムが有する基礎的問題の１つは、大部分の場合、セキュリティシステムの別個のエンティティ間を行き来するメッセージおよびデータがすべて、通常、公に伝送され、したがって、盗聴者によって観察可能であることである。したがって、そのようなシステムの個々の構成要素間で伝送される、任意のメッセージまたはデータは、暗号化され、未承認当事者による傍受に対して保護されなければならない。そのようなシステムにおいて対処されなければならない別の問題は、任意のそのような秘密データ伝送において、送信者だけではなく、受信者の両方の身元の照合である。２人の当事者が相互に知らない場合、相互に信頼される媒介戦略が、一般的に採用される。
【００４５】
しかしながら、加えて、秘密データがその宛先に到達したときに対処されなければならない同様に困難な問題は、危殆化されない態様において、その秘密データをどのようにセキュアに使用するかである。この予防措置は、通常、合法的な終点であっても、それに偽情報を提供することによって、セキュリティを傷つけられ得る可能性があるので必要である。したがって、配信の際の未承認発見に対する保護に加え、時として、その他の点では承認されているユーザによってその秘密データが発見されることから、秘密データを保護することが望ましい。
【００４６】
一実施形態では、そのような望ましい制御は、構造上隠蔽されている秘密キーの単純な時間依存的な使用、または実行に先立ってリアルタイムで復号化されなければならない暗号化オブジェクトコードブロックを利用して、実装されてもよい。前者の場合、コードブロック実行は、制御メカニズムに対して完全に透明であり得、実行速度が最小の影響を受けるはずであることを意味する。後者の場合、起動されるコードブロックは、実行に先立って復号化されてもよく、したがって、復号化プロセスの呼出し時間に起因する性能の同時損失の可能性が最も高い。しかしながら、この後者の場合、オブジェクトコードは、分解されるおそれが比較的なく、したがって、潜在的に、可能性のある攻撃者による妨害はより困難である。後に本明細書において論じられる実施形態は、高度にセキュアな暗号化されたオブジェクトコードの方法から、比較的高度な性能であるが、それでもなお、依然として非常にセキュアな選択的に利用可能な秘密キーの方法に及ぶ、一連の可能性のある解決策において実装可能なシステムおよび方法を開示する。
【００４７】
一実施形態では、そのような秘密キーのユーザからの秘密キーの隠蔽は、ハーバードアーキテクチャメモリ空間分岐に類似する方法で達成されてもよい。しかしながら、本実施形態では、秘密キーが、暗号化／復号化計算において使用されてもよいが、プロセッサによって実際に直接読み取られることが決してないように区別がなされ得る。この区別は、ハードウェア内に実装されたもの、またはハードウェアの設計時に定められた所定のソフトウェアマクロ（また、マイクロコードとしても知られる）に、暗号化／復号化動作を限定することによって実施されてもよい。例えば、ハードウェア秘密キーが、任意のコードによって使用され得る場合、プロセッサによって直接読取り可能でない場合でも、それでもなお、単純計算によって容易に決定可能である。したがって、セキュリティ関連計算のみ、ハードウェア秘密キーにアクセスし、そのようなコードセグメントをより汎用的ではあるが、あまりセキュアではないコードブロックから差別化し得るように規定することが望ましいであろう。
【００４８】
この区別は、ある実施形態では、この明細書に説明されるものに本質的に類似する照合方法を利用して達成されてもよい。上述の適応デジタル署名方法の実施形態が、ハードウェア秘密キーがアクセスされ得るかどうかを決定するために利用される場合、標的プロセッサが、セキュリティ関連計算（すなわち、標的プロセッサが、「セキュア化実行」モードで動作時に行われる計算）およびセキュア化されていないものを実行中であるかどうかを容易かつ確実に決定可能である。加えて、上述のものに実質的に類似する再帰的方法を利用して、最終計算が完了し、完全に解読された結果が報告されるまで、任意の中間キー結果が発見されないように隠蔽されてもよい。したがって、本明細書に説明される実施形態は、同一ビットストリームを発生させるために使用される、秘密グローバルキーを曝露することなく、暗号化されたデジタルビットストリームを解読する能力を有してもよい。
【００４９】
（コード実行の制御）
特定のコードセグメントが、所与のプロセッサにおいてセキュアに実行されることを保証するための方法は、長年、広範囲に研究されている。セキュアなコード実行の保護をもたらすための以前の試みのいくつかとして、「特権的」命令集合を確立するために、プロセッサアーキテクチャに書換えを行うことが挙げられる。これらの特権的命令は、プロセッサが「監視者」または「カーネル」モードとして知られる、特定のモードで起動中にのみ、これらの特権的命令が実行可能であるようにアーキテクチャを設計することによってセキュア化されていた。この種類のプロセッサアーキテクチャの分岐は、プロセッサの汎用性の潜在的損失だけではなく、潜在的性能の劣化を含むいくつかの欠点を有する。これらの欠点に加え、そのような保護手段は、多くの場合、プロセッサが監視者モードで実行中、想定外の実行パスを利用するように、標準システムルーチンに対して、特異的に設計されたソフトウェア読み出しを使用することによって迂回可能である。そのような特異的に設計されたマルウェア攻撃の実施例として、いわゆる「スタックオーバーフロー」、「スタックオーバーラン」、および「コードインジェクション」攻撃が挙げられる。
【００５０】
これらの種類のセキュリティ上の弱点に対する保護を支援するための試みにおいて、主に、チェックサム照合または引数上下限検査の種々の手段に基づいて、いくつかの戦略が考案されている。これらの種類の保護手段にもかかわらず、多形性ウイルス（すなわち、自己書換えコード）を含む、種々の対対抗手段が進化している。上下限検査にもかかわらず、プロセッサの脆弱性を悪用するための別の戦略として、上下限検査「監視者」ルーチン自体を単純に迂回することが挙げられる。また、この種類の搾取は、種々のコピー保護システムを回避する際に、頻繁に使用される。結局、監視ルーチンを奪取する戦略は、コンピュータセキュリティの世界にとって一意的ではなく、全く新しい概念ではない。実際、正にこの問題は、種々の用途において類似点を有し、Ｐｌａｔｏの文献「Ｔｈｅ  Ｒｅｐｕｂｌｉｃ」にまで遡って参照されている。基本的問題は、任意の所与のシステムにおいて、最終的なセキュリティまたは構造の安定性が委ねられるある種類のグローバルな監視者を常に識別可能であることである。あらゆる後続のセキュリティ機能に対するグローバルな基礎についてのそのような概念は、「Ｒｏｏｔ−ｏｆ−Ｔｒｕｓｔ（信頼の基点）」として、セキュリティシステムの最新の研究において知られている。
【００５１】
より最近では、プロセッサが、本質的に読取り専用である命令をそこから取り出すメモリセグメントを制限することによって、プロセッサを監視ルーチン攻撃から保護する試みがなされている（これは、いわゆるＷ＾Ｘまたは「ｗｒｉｔｅ−ＸＯＲ−ｅｘｅｃｕｔｅ」アプローチを含む）。データベースのパーティションと、コードベースのパーティションとに、その他の点では汎用であるコンピュータのメモリ空間を分割する概念は、いわゆる「Ｈａｒｖａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ハーバードアーキテクチャ）」の変形例として示され得る。この方法は、保護メカニズムだけではなく、メモリ利用の同時増加と関連付けられたある性能に不利な条件を有する。最後に、最近、これらの種類の防護でさえも、いわゆる「戻り値ベース」のプログラミングのセキュリティ上の弱点の使用によって、または２つの別個の実行スレッドが、異なるモード（一方は、「データモード」、他方は、「実行モード」）において、メモリの同一ブロックを参照可能である、単純なメモリ−エイリアシングのセキュリティ上の弱点によってさえ回避可能であることも示されている。
【００５２】
プロセッサの実行スレッドが奪取されることを保護する別の提案される手段として、暗号化されたコードブロックの使用が挙げられる。この方法では、実行されるコードセグメントは事前に暗号化され、したがって、プロセッサへのそれらのロードの前には読取り不可能である（おそらく、さらにより重要なこととして、改ざん不可能である）。また、この方法は、いくつかの脆弱性を有する。第１に、コードセグメント自体が、保護され得るが、引数は、必ずしも同一レベルのセキュリティを備えていない。したがって、完全に合法かつセキュアなコードセグメントは、それでもなお、予想外の方式で挙動させることが可能な、その呼出しルーチンからの偽引数を備え得る。第２に、ある場合には、実行スレッドは、必ずしも、上述の戻り値ベースのプログラミング攻撃に対して保護されていない。また、プロセッサバスが、攻撃者によって容易に観察可能である場合、正確に実行される（暗号化されていても）コードセグメントの長期観察だけではなく、実行可能ストリームに投入される不適切に暗号化されたコードセグメントによって生じる例外欠陥の観察が、書き換えられた辞書攻撃方法を使用して、暗号化キーを明らかにすることに有用となり得る。最後に、そのようなシステムにおけるプロセッサ性能は、必然的に、類似するが、暗号化されていないコードシステムよりも大きく低下させられる。この性能上の不利な条件は、いくつかの問題によって生じ得、その最も重要なものは、メモリから取り出されるときと、実行されるために利用可能となるときとの間のコードブロックの必須復号化によって被る待ち時間である。最新のプロセッサは、パイプライン方式メカニズムを使用して、並行して実行可能な命令の数を増加させようとするが（種々の手段によって）、暗号化されたコードのブロックは、最初に復号化されるまで、そのようなパイプラインに読み込まれることは不可能である。コードが頻繁に分岐する場合、復号化プロセスは、潜在的に、ハードウェア支援復号化によってさえ、コード実行自体よりもさらに時間がかかり得る。
【００５３】
本発明に説明されるシステムおよび方法の実施形態は、非暗号化コードブロックの利用を可能にし得、したがって、暗号化された実行ファイルと関連付けられた性能上の不利な条件は、あまり問題とならない。しかしながら、実行効率が重大な懸念ではない場合、暗号化されたコードブロックが、依然として利用されてもよい。したがって、本明細書に開示される実施形態は、プレーンテキスト実行ファイルの効率だけではなく、同一または類似の方法およびシステムを利用して、暗号化されたコードセグメントの追加のセキュリティの両方を有し得る。加えて、本明細書に説明されるセキュリティシステムおよび方法の実施形態は、その場でアップデートされ、新しく発見されたセキュリティ上の懸念を解決するだけではなく、実施形態が既に配備された後においても新しい機能を追加することが可能である。
【００５４】
本発明の実施形態は、とりわけ、「セキュア化コードセグメント」が、暗号学的ハッシュ関数によって、実行に先立って照合されることを保証することによって、これらの利点を成就し得る。この照合は、例えば、そのようなセキュア化コードセグメントのために生成されたメッセージダイジェストまたはデジタル署名を認証することによって達成されてもよい。この暗号学的ハッシュ関数の評価が、デジタル署名を形成するために、上述のように、複合キー構造を使用して、結果として生じるメッセージダイジェストの暗号化と併せて生じる場合、特定のコードブロックは、特有の標的ユニットまたはプロセッサと一意的に関連付けられることが可能である。このプロセスは、ある実施形態において、このセキュア化コードブロックが、デジタル署名に基づく複合キーを使用して、特定の標的ユニットに暗号学的に結合することが可能であるという事実に基づいて、本明細書では、「セキュア化コード結合」と呼ばれる。
【００５５】
そのようなハッシュ関数の実行は、リソースフリーであってもよいが、このアプローチの利点は、セキュア化コードセグメントが、その暗号学的照合の完了の前に、実行パイプラインに導入可能であることである。したがって、ハッシュ関数は、潜在的に、セキュア化コードセグメント自体の実行と並行して評価可能である（推論的分岐実行に類似する方式において）。この実施形態では、セキュア化コードセグメントの結果は、結果として生じるメッセージダイジェストが本物であると決定される場合にのみ利用されてもよい。しかしながら、別の実施形態では、セキュア化コードセグメントの結果は、後続の動作において利用されてもよいが、結果自体が、プロセッサがセキュア化実行モードで動作しているかどうかに応じて、異なってもよい。この実施形態は、デジタル署名において使用するための複合キーの評価に関して上述のプロセスに実質的に類似し、図１５に図示されるようなハードウェアの使用によって生成することが可能である。
【００５６】
しかしながら、暗号学的照合の使用は、暗号化されたコードセグメントの使用を妨げるものではない。実際、正確に復号化されたコード（任意の種類の暗号化を適用する前のそのオリジナル状態において、セキュア化されているコードセグメント）のメッセージダイジェストまたはデジタル署名の使用は、付加的レベルの保護を提供し得る。これは、潜在的な攻撃者が、偽造メッセージダイジェストを生成するためには、正確に復号化されたコードブロックの演繹的知識を有する必要があるだろうという事実によるものである。したがって、コードセグメント照合だけではなく、暗号化されたコード方法の両方が同時に使用可能である場合に、攻撃に対してより高いロバスト性が実現され得る。
【００５７】
しかしながら、また、理解され得るように、そのようなハッシュ照合を迂回可能ないくつかの方法が存在し、その最も単純なものは、ハッシュ関数自体を妨害することであろう。この戦略が、ある実施形態について不可能であることが想定される場合でも（例えば、ハードウェアハッシュ関数を利用することについて）、適切に照合されたメッセージダイジェストとともに偽りのコードセグメントを提供することによって、依然として、そのような実施形態のセキュリティを攻撃することが可能であり得る。多くのメッセージダイジェストは、実際に、暗号化され、デジタル署名を形成するので、表面上、この攻撃戦略は、一見、困難であることがわかるであろう。しかしながら、デジタル署名メカニズムでさえ、デジタル署名の公開キー検索部分をスプーフィングし、したがって、偽りのデジタル署名の人為的照合を提供することによって、または代替として、署名照合ルーチン自体の悪質な破壊によって、潜在的に攻撃され得る。
【００５８】
これらの制限は、セキュア化コードセグメントと関連付けられたメッセージダイジェストを二重に暗号化することによって、本明細書に開示されるシステムおよび方法の実施形態において克服される（一度目は、（グローバルな）「著者の」秘密キーによって、次いで、再度、終点「製造業者」（実際には、オリジナルチップ製造業者ではなく、二次レベルの配信者、システムインテグレータ、サービスプロバイダ等であり得る）および当該コードセグメントが実行される特定の終点デバイスにのみ知られている秘密キーによって）。この実施形態の利点は、上述のデジタル署名が、類似した終点デバイス間で共有される場合でも、異なる標的ユニットの秘密キーが異なるので、その意図された標的ユニットにおいてのみ正確に機能することである。したがって、任意のそのようなデジタル署名は、暗号化されていない状態で伝送かつ格納可能である。
【００５９】
秘密キーを二重に暗号化する技術（いわゆる「階層化キー」システムだけではなく、再帰的セキュリティシステムにおいても使用され得る）の実施形態は、不正確に使用される場合、ある問題を有し得る。第１に、そのような階層化暗号化プロセスの中間結果が傍受されると、この中間キーを使用してそのようなシステムの一部または全部のより高いレベルのセキュリティを迂回可能である。また、そのような階層化システムの「最下層」においては、この中間結果が、実際に発見されると実質的に類似した終点デバイスすべてに対するセキュリティシステム全体を迂回するために使用可能である「グローバル」復号化キーであることに留意されたい。この種類の「傍受」攻撃が、復号化プロセスの際に、任意のメモリトランザクションを単に注視し、次いで、潜在的グローバル復号化キーのそのような記憶場所すべてを検証することによって、１回以上生じ得る。復号化プロセスの際のメモリアクセスすべてを注視するプロセスは、最初は、煩わしく思われ得るが、ほぼ確実に、そのような秘密キーの値の総当たりによる推測よりも効率的な攻撃戦略である。階層化キーシステムにおける第２の潜在的な脆弱性が、リプレー攻撃の改良型によって悪用可能である。階層化キーシステムのセキュリティが危殆化され、そのキーがアップデートされなければならない場合、古い（危殆化された）キーは、依然として、オリジナルシステムがその以前の状態にリセットされるとき、またはその以前の状態が、偽りのユニットによってクローン化されるとき、使用され得る。
【００６０】
これらの脆弱性は、「階層化キー」構造とは対照的に、「複合キー」と呼ばれるものを使用して、本明細書に論じられる実施形態において解決され得る。複合キーと階層化キーとの間の主要な相違の１つは、前者のセグメントがすべて単一モノリシックパスにおいて評価され得ることである。対照的に、階層化キーシステムでは、「最外」層キーを最初に評価することが可能であって、次の最内キー（これは、次に、引数として使用され、キースタック全体がトラバースされるまで次の層のキーを生成する）に戻る。このシステムに伴う問題は、より低いレベルのキーが傍受かつ後に使用され、効果的に最外セキュリティ層を迂回可能であることである。したがって、そのような階層化キー実施形態においては、最も重要な（この場合、グローバル）キーは、連鎖内において最後に生成され、使用されるものであって、ここにおいて、任意の付加的な（または、より新しい）層のセキュリティは完全に欠如している。
【００６１】
この理由から、そのようなセキュリティスタックをトラバースするためのよりロバストな方法が利用されて、「インサイドアウト」からトラバースされ得る。これは、セキュリティ連鎖への最も新しい追加物が、順序通り最初に実行されるが、実際は、セキュリティシステムの最内層に位置するものであることを意味する。故に、実施形態を使用して、そのような「インサイドアウト」の実行順序が実施され得る。この特定のコードスタックトラバーサルの順序は、単純反復アプローチを使用して達成可能であって、そこでは、コードループは、最初に現在のセキュリティレベルを評価し、次いで、それに従って、分岐する。しかしながら、反復方法では、セキュリティシステムトラバーサルの中間結果は、上述のように、攻撃者が、次のより低いレベルのキーが合法セキュリティシステムトラバーサルにおいて曝露されることを単に待機し、次いで、その傍受したキーを使用して、システムの偽造「初期」バージョンをクローン化し得るので、潜在的に、迂回可能である。したがって、システムおよび方法の実施形態は、この「インサイドアウト」実行順序を実施するだけではなく、また、中間結果が悪質なコードまたは他の周知のセキュリティシステムのセキュリティ上の弱点によって傍受されることから保護可能であるように説明される。
【００６２】
そのような「インサイドアウト」セキュリティアプローチを使用する場合の別の主要利点は、呼出し引数のシーケンス全体が、セキュリティシステムの最内層（したがって、最も新しいバージョン）に対して可視であり得ることである。この「インサイドアウト」実行シーケンスが、適切に実装される場合、そのようなシステムで採用される正確に構築された上下限検査メカニズムが、呼出し連鎖全体にわたって可視性を有し得ることが分かる。したがって、実施形態は、通常、そのような機能と関連付けられる任意の付加的性能上の不利な条件を被ることなく、相当量のシステム認証機能を行うための内蔵メカニズムを有してもよい。
【００６３】
故に、ある実施形態は、中間キーがより高いレベルの（したがって、あまりセキュアではない）セキュリティシステムルーチンに曝露されることを防止するだけではなく、適切なセキュリティスタックトラバーサル方法を保証するための手段を利用してもよい。これを達成するためのそのような方法の１つは、再帰的セキュリティ構造の使用であって、その一実施形態は、２００３年６月１９日に出願され、その後、２００７年４月１０日に米国特許出願公開第７，２０３，８４４号として発行されている、Ｗｉｌｌｉａｍ  Ｖ．  Ｏｘｆｏｒｄによる米国特許出願公開第１０／４６５，２７４号「Ｍｅｔｈｏｄ  ａｎｄ  Ｓｙｓｔｅｍ  ｆｏｒ  ａ  Ｒｅｃｕｒｓｉｖｅ  Ｓｅｃｕｒｉｔｙ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  Ｄｉｇｉｔａｌ  Ｃｏｐｙｒｉｇｈｔ  Ｃｏｎｔｒｏｌ」に図示されており、あらゆる目的のために、参照することによって本明細書に組み込まれる。
【００６４】
そのような再帰的セキュリティプロトコルの実施形態が利用される場合、ある利点が実現され得る。第１に、スタック順序トラバーサルは、「インサイドアウト」から評価されなければならないように設計可能である。これは、最も新しいセキュリティシステムの追加が、最初に実行され、システムは、「途中から開始」不可能であることを意味する（例えば、「戻り値ベース」のプログラミングのセキュリティ上の弱点において使用されるように）。再帰的システムの第２の利点は、セキュリティシステムへの任意のアップデートの追加が、セキュリティシステム自体において、オリジナル呼出し引数を変更できないことである。故に、従来のリプレーベースの攻撃メカニズムを使用することによって、セキュリティシステムをスプーフィングすることはより困難となり得る。本明細書に開示される実施形態の場合、反復方式において、逆の順序でインライン実行スタックを採用することが確実に可能であるが、反復メカニズムは、割り込みを受け得、したがって、また、セキュリティスタックの部分的評価が行われる環境をもたらすことも可能であり得る。これは、潜在的に、外部観察者によって、１つ以上の中間結果が傍受されることを可能にするであろう。本明細書の実施形態によって利用され得るように、再帰を介して実装されるインサイドアウトセキュリティシステムでは、中間結果は、引数として、任意の時点において、次のレベルのルーチンにパス不可能であって、現在実行されているセキュリティシステム層の最終結果のみが、セキュリティシステムスタックの次の上位レベルで利用可能である。
【００６５】
また、複合キー構造は、ある実施形態では、標的ユニットの秘密キーへのアクセスを厳密に制御することによって、部分的評価から保護されてもよい。例えば、秘密キーが、構造上可視ではないアクセス不可能な記憶場所内に格納されている場合、特定のセキュリティ関連命令または機能の一部としてのみアクセスされてもよい。ある実施形態では、この機能または命令は、非自明な一方向変換等、容易に反転され得ないものである。そうすることによって、偽造セキュリティシステムさえ、秘密キーの値を明らかにすることが不可能であるはずである。その結果、一方向機能の一部として、秘密キーを間接的に参照のみさせることによって、秘密キーは、数学的動作の一部として、それ自体では決して使用可能ではなく、単独で、またはある別のデータとともに、ハッシュ動作の一部としてのみ使用可能であって、そこでは、ハッシュ関数の結果のみが観察可能であり得るので、秘密キーは保護され得る。
【００６６】
また、秘密キーを保護するための付加的メカニズムが、ある実施形態では、有用であることがわかり得る。そのような潜在的メカニズムの１つは、複合キーの使用であって、そこでは、標的ユニットの秘密キーは、ある別の制約または付加的オペランド集合に厳密に結合される。そのような二次オペランドの実施例として、別個の秘密キー、グローバル的可視レジスタ（タイムスタンプまたはシステムバージョン番号等）、秘密キーにアクセスするコードのメッセージダイジェスト等を含んでもよい。そのようなシステムの実施形態では、この最後の実施例は、秘密キーが、その全く同一キーを使用するために承認される、コードのセグメントによってのみアクセスされてもよいことを保証し得る。さらに、メッセージダイジェストが暗号化され、デジタル署名を形成する場合、かつそのメッセージダイジェストを暗号化するために使用されるキーが、秘密キー自体である場合、秘密キーにアクセスする唯一の方法が、その秘密キーが何であったかを既に知っている者によって作成されたコードセグメントを使用することであることを保証可能なように、依存性の循環を生成することが可能である。
【００６７】
この場合、複合キー構造の使用は、そのキーを使用可能にする前に、標的ユニットの秘密キーの使用を要求する、コードの一部の「権限」を照合させる。「階層化キー」構造と「複合キー」構造との間の差異は、ある実施形態においては、後者は、それ自体が再帰的手段によって達成可能である解剖学的方式で評価され得ることであることを思い起こされたい。再帰的構造とは対照的に、反復アプローチを使用して類似構造のアセンブルを試みる場合、キー評価プロセスの中間結果を曝露する（したがって、潜在的に、秘密キーを曝露する）危険性があり得る。この「曝露」は、秘密キー（または、それらの原体）が、割り込みが生じるとメインメモリに押し出される、汎用レジスタ等の公的に利用可能な場所に格納されるときに（または、直接メモリ自体内でさえ）生じ得る。
【００６８】
ある実施形態において解決され得る潜在的セキュリティの崩壊は、セキュリティスタック動作が、評価中に割り込まれ、次いで、標的ユニットのプロセッサの状態が、外部観察者によって検証を受けやすいメインメモリに書き出されるときの部分的結果の保護である。一実施形態では、このメモリ「曝露」を防止するために、プロセッサがセキュア化実行モードにある間、ヒーププッシュは拒否される。その条件が実施される場合、再帰的セキュリティプロトコルは、その現在の状態を損失することなく、割り込みは不可能である（中間引数が存在しないため）。再帰的セキュリティプロトコルの実施形態では、セキュリティプロトコル全体は、再帰が終了し、プロセッサがセキュア化実行モードで起動しているときにトラバースされ、したがって、割り込み以外のいかなる場合でも、ヒープへの任意の引数のさらなるプッシュは存在し得ないことに留意されたい。したがって、複合キー評価が、任意の時点で割り込まれる場合、かつ、ヒーププッシュがセキュア化実行モードにおいて拒否される場合、セキュリティシステムスタックトラバーサルは、実行中に再開できない（すなわち、計算は、最初から再開しなければならない）。したがって、再帰的セキュリティプロトコルは、任意の中間結果がシステムヒープ上に格納される（したがって、潜在的に、未承認観察者に曝露される）ことを防止するように使用可能である。当然ながら、ある実施形態では、反復セキュリティシステム評価の際、ヒープ動作を無効にすることが可能であって、したがって、効果的に、そのような割り込されたセキュリティシステム動作が、最初から再開されなければならないことを要求する。しかしながら、そのような反復アプローチは、「インサイドアウト」実行順序、「戻り値ベースの」プログラミングのセキュリティ上の弱点に対する保護、オリジナル機能に対して、呼出し引数を改善しないように、後続のセキュリティ層に追加する能力だけではなく、中間結果および最終機能出力結果の隔離等、再帰的構造が提供する条件のすべてを施行しない場合がある。セキュリティシステム再帰が終了し、プロセッサがセキュア化実行モードに入ることが許可されるメカニズムについては、より詳細に後述される。
【００６９】
（再帰の終了）
一実施形態では、再帰は、所与のコードセグメントのメッセージダイジェストが、コードセグメント自体とともに供給されたものと整合すると、終了するように信号伝達可能である。この方法論は、メッセージダイジェストが、ハードウェアハッシュ関数によって計算される場合、攻撃に対してよりロバストになり得る。また、ある実施形態では、デジタル署名が利用されてもよい。デジタル署名メカニズムは、１）コードセグメントが改ざんされていないことの保証と、２）コードセグメント著者の即時識別の少なくとも２つの主要属性を提供する潜在性を有する。しかしながら、そのようなデジタル署名が、公的に可視または書換え可能場所にキャッシュされる実施形態の場合、デジタル署名自体が、任意の時間に書き換えられ、したがって、必ずしも、本物ではない可能性があるので、付加的セキュリティが望ましいであろう。したがって、これらの種類の実施形態においては、公開キーシステムを使用して、デジタル署名を照合してもよく、または複合キー構造（上述のように）を使用して、当該コードセグメントを備えるデジタル署名が、標的ユニットの秘密キーを所有していたある当事者によって作成されていることを保証してもよい。後者の場合、また、複合キーの使用は、単一終点またはある終点集合に限定されてもよい。加えて、公開キーだけではなく、複合キーアプローチの両方を併用してもよい。その態様では、コードセグメントが本物であることだけではなく、コードセグメントが複合デジタル署名の受信者のために意図されたものであることの両方を保証可能である。
【００７０】
また、ある実施形態においては、標的ユニット上のセキュリティメカニズムを照合することが望ましいであろう。標的デバイス上のセキュリティシステムの任意の１つのセグメントに対して、ハードウェア生成デジタル署名が利用されてもよいが、セキュリティシステムが再帰的である場合、個別デジタル署名が、セキュリティシステム自体がトラバースされることに伴って、実質的に、自動的に生成され得る。上述のように、再帰的セキュリティプロトコルの実行が終了すると、呼出し連鎖全体が曝露される。したがって、セキュリティプロトコルの最内（したがって、最も新しい）部分は、潜在的に、スタック上に格納された呼出し引数だけではなく、システムヒープ（または、さらにメモリ内のいずれかの場所）内に格納される別の環境変数を含む、呼び出される環境全体へのアクセスを有する。この内蔵システム認証メカニズムは、特に、セキュリティプロトコル自体のトラバーサルと同時に評価されるので、効率的であるだけではなく、攻撃に対してロバストである。
【００７１】
一実施形態においては、次いで、セキュリティシステムスタックトラバーサルの「実行段階」の前に導入されていなければならない条件集合が、規定され得る。一実施形態では、これらの条件は、個々に要求されるセキュリティ条件のすべての「共通集合」として表現可能である。そうすることによって、新しいセキュリティの危険性が発見されるとき、それらの危険性を考慮する付加的条件が、容易に導入され得る。これらの条件は、セキュリティシステムのいかなる部分も、新しいのも、古いのも、条件すべてが合致するまで、実行されないように保証可能である。種々のセキュリティシステム条件のこの「共通集合」は、上述のように、複合キー構造メカニズムの使用を通して達成可能である。例えば、そのような複合キー構造の構成要素の１つが、部分的に、標的ユニットの秘密キーに基づく場合、この秘密キーは、セキュリティシステム全体の「信頼の基点」の１つとしてみなされ得る。さらに、ハードウェアベースのタイムスタンプメカニズムが、複合キーの他の構成要素の１つとして利用される場合、システムは、リプレー攻撃に対してより保護され得る。ある実施形態では、他の条件を実施するために、上述に加え、ある実施形態において採用され得るいくつかの構成要素が存在する。そのような構成要素は、コードが改ざんされている場合、キーを適切に評価されることを防止するために、複合キーの一部として、コードブロックのメッセージダイジェストのハードウェアベースのハッシュ計算の使用を含む。一実施形態では、別のそのような構成要素は、スタックオーバーフロー型攻撃に対して保護し得る、実行されるコードブロックの呼出し引数のある選択されたサブ集合のデジタル署名であってもよい。
【００７２】
コードセグメントが、タイムスタンプまたは使用関連制限等、その実行に関する他の制約を有する場合、ある実施形態においては、さらなる条件が複合デジタル署名に追加され、それらの制約もまた適切に実施されていることを保証することが可能である。また、この同一メカニズムを使用して、中間セキュリティトークンの正確な評価に基づいて、システムの各層内で適切なコード分岐を実施することによって、種々のセキュリティスタック層を通して、特有の複数の反復を強いることが可能であることに留意されたい。
【００７３】
上述のように、再帰的セキュリティシステムの実施形態は、条件のすべてが、セキュリティトークンの評価開始に先立って導入されていることを保証することが望ましいある実施形態において、有利である。したがって、インサイドアウトセキュリティスタックトラバーサルを実施するその能力および中間結果の可視性に関する制限を有する再帰的システムは、最小に破壊的な方式において、セキュリティシステム評価に関してより制約を追加することが望ましいとき、外部攻撃に対する向上したロバスト性だけではなく、柔軟性を提供することが可能である。
【００７４】
ここでは、セキュリティシステムスタックの再帰的トラバーサルは、必ずしも、アルゴリズム的フロー全体に対する再帰的形式と等しいわけではないことに留意されたい。したがって、セキュリティシステムの論理的フローおよびシステムのセキュリティシステムを利用するコードスレッドの論理的フローは、完全に異なってもよい。
【００７５】
加えて、ある実施形態では、特定のコードセグメントが解析されることに伴って、デジタル署名がどのように書き換えられるかを規定する機能集合を含むことによって、デジタル署名がどのように使用されるかの柔軟性が向上させられ得る。例えば、コードセグメントが、第１の反復後、デジタル署名を不変のまま解析プロセスを通過させる場合、そのコードセグメントは、セキュリティシステムが何回特定のコードブロックを循環するかを事前に規定する必要なく、照合可能である。同様に、デジタル署名は、特定のコードセグメントに直面することに伴って、既知の「シード」状態にリセットされるように規定可能である。したがって、単に、単一の一意的数（暗号化されていない状態で格納可能）を供給することによって、セキュリティシステムの種々の部分が、何回およびどの順序でトラバースされるかの一意的変動が、規定されてもよい。実際、そのようなコード照合プロセスを使用して、種々の有用な機能を実装可能であって、したがって、この技術は、必ずしも、セキュリティシステム自体の排他的使用に限定される必要はない。
【００７６】
適切なデジタル署名が、一般的コード（セキュリティの実装に関連し得る、またはし得ないコード）を備える場合、コードのその特定のブロックが、特有の標的ユニット上で実行される態様は、非常に特異的に制御されてもよい。これは、一般的コードを標的デバイス集合にセキュアに分配するために使用可能な、非常に強力なメカニズムである。この分配方法は、例えば、効果的にアプリケーションへの無料または有料アップグレードに、またはソフトウェアウイルスおよび他の望ましくないマルウェアの拡散を管理するために効果的に適用されてもよい。この後者の実施形態では、再帰的セキュリティシステムを使用して、標的デバイス上での実行のための候補であるあらゆるコードブロックを照合可能である。したがって、マルウェアアプリケーションまたは以前に認証されたコードセグメント上の多形性ウイルス攻撃さえ実行が防止され得る。
【００７７】
ハードウェア依存性をセキュリティシステム評価に組み込む能力を提供するために、ある実施形態においては、ハードウェア実装バージョン番号が、デジタル署名評価の複合構成要素の１つとして利用されてもよい。セキュリティシステムが書き換えられる度に、ハードウェアバージョン番号が、アップデートされる場合（かつ、そのアップデートがセキュアである場合）、セキュリティシステムが、実行されている標的ユニットと整合されることを保証することが可能である。これは、上述のタイムスタンプメカニズムと異なるが、複合キー評価において、２つを併用し、リプレー攻撃シナリオまたは他の侵害に対して保護し得ることに留意されたい。
【００７８】
例えば、我々の複合キー構造の一部として、ＪＴＡＧ署名等のハードウェア導出チェックサムを使用する場合、ハードウェア実装自体が認証されてもよい。次いで、この種類のメカニズムは、ソフトウェアおよびハードウェアが整合された対であって、ハードウェアが本物である（または、改ざんされていない）ことを保証し得る。さらに、複合キー評価の一部として使用されるＪＴＡＧ署名が、直接観察可能ではない場合（例えば、その状態が、外的に可視でもなく、構造上可視でもない場合、スキャン連鎖のある時点から求められる）、ハードウェアのクローン化に基づく潜在的攻撃をマウントする困難性は、数倍も高まり得る。この戦略は、例えば、デバイスの個々の通し番号が、このスキャン連鎖に含まれる場合、効果的となり得る。
【００７９】
ここでは、プロセッサの観点から、本質的に、暗号化されたコードブロック（直接実行可能ではない）と「アップデートされていない」コードブロック（正確なデジタル署名整合を前提として、可能性として同時に実行可能であり得るが、そのデジタル署名は、もはや有効ではないので、もはや実行可能ではない）と間に論理的差異は存在し得ないことに留意されたい。このシナリオは、例えば、標的デバイスのタイムスタンプレジスタが変更されたため、または代替として標的デバイスのハードウェアがある未承認態様において書き換えられた場合に生じ得る。
【００８０】
したがって、特定のコードブロックが、アップデートされたバージョンと置換される場合（両方とも、潜在的に、実行可能であっても）、一実施形態では、これを達成するための単純ではあるが、さらに効果的方法は、最初に、当該コードブロックのための復号化キーポインタを、コードブロックの古いバージョンをアップデートされたバージョンと置換するための手段につながる新しいポインタと置換し、次いで、標的終点デバイスのタイムスタンプレジスタをアップデートすることであり得る。ここでは、アップデートされたタイムスタンプレジスタ値は、古い値を使用して生成された以前のデジタル署名すべてを無効にし、したがって、セキュリティシステム全体が更新され（理想的には、セキュアな態様において）、最新の状態にし、古いデジタル署名（または、キー）を新しいキー／デジタル署名値およびアップデートされた機能と置換することを伴い得る。これは、終点デバイスのタイムスタンプレジスタ内に格納された値への単一の変更によって容易に影響を受け得る、非常に強力な（かつ、潜在的に、非常に広範囲に及ぶ）メカニズムである。この場合、終点タイムスタンプレジスタ値が、非セキュアまたは無謀な態様において変更されないように注意を払う必要がある。そのような強制アップデートシナリオの一実施形態は、暗号化の層をその他の点では直接実行可能なコードブロックに追加する（単に、単一デジタル署名不整合を強いることによって）ことと論理的に同等とみなされ得る。
【００８１】
（セキュア化モードおよびセキュア化コード結合）
システムが、上述のように、構造上不可視である秘密キーの１つを利用する実施形態では、そのようなキーを利用するコードは、これらの秘密キーが危殆化されることを防止するように設計されなければならない。上述のように、セキュア化コード結合メカニズムを使用して未承認態様で使用される際に、特定の終点デバイスにおいてその他の点では合法であるコードブロックの正確な実行を防止可能である。
【００８２】
一実施形態では、このセキュア化コード結合は、特有の種類のハッシュ関数を候補コードセグメントに適用する結果が、コードセグメントが実行可能となる前に、そのコードセグメントを備えた特別に事前に決定されたメッセージダイジェストと整合しなければならないという要件に基づいている。このハッシュ関数は、候補コードセグメントが読み出された後、実行が可能となる前に適用されてもよい。このハッシュ関数が開始されると、候補コードセグメントを備える、その特定のメモリ空間へのいかなる書き込みも、無効化または無視され得る。候補コードセグメントが、ＣＰＵの命令キャッシュ内等のＣＰＵ実行ユニットと同一チップ上に位置する場合、これは、容易に実装され得る。しかしながら、マルチプロセッサシステムでは、例えば、Ｉ−キャッシュが、同一チップ上に常駐する２つ以上のプロセッサ間に共有され得る場合、見た目ほど実装は単純ではないであろう。メッセージダイジェストが算出された後に、コードが書き換えら得ることを防止するための別の潜在的方法は、ハッシュ関数が開始された後に生じる、そのメモリ空間へのいかなる書き込みの試みも、プロセッサ割り込みを生じさせるように、システムを構成することである。上述のように、これは、プロセッサのセキュアな実行モードをそのデフォルトの初期「非セキュア」モードにリセットし得る。そのような侵入に対する別の対応は、例えば、メモリセグメンテーション違反を開始することによって、エラーによってセキュア化実行スレッドを決定させることであろう。
【００８３】
候補コードセグメントの計算されたメッセージダイジェストが、候補コードセグメントとともに受信した事前に決定されたメッセージダイジェストと整合する場合、候補コードセグメントは、「セキュア化モード」または「セキュア化実行モード」と呼ばれるもので実行可能となる。上述のように、セキュア化モードで動作中のコードのみ、構造上不可視の秘密キーを利用可能である。特定のコードセグメントが、セキュア化モードで動作していない場合、秘密キーは、無効化され、それらの１つに対する任意の参照は、ある他の値（ゼロ等）を返すであろう。
【００８４】
ある実施形態においては、候補コードセグメントのためのメッセージダイジェストを計算する差異に利用されるハッシュ関数は、ある特性を有し得る。第１の特性は、ハッシュ関数が、標的ユニットのハードウェア内に実装され得ることである。これは、この機能が、このオリジナルハードウェアハッシュ関数のある別の（おそらく破壊された）バージョンによって、完全に置換できないことを意味する。このハッシュ関数は、所望に応じて、オリジナル機能の改良バージョンによって補完（または、条件付き完全置換さえ）されてもよいことに留意されたい。一実施形態では、ハードウェアハッシュ関数を改良バージョンと置換する方法は、セキュリティシステムの構造の再帰的定義を介して新しい層をセキュリティシステム内に挿入するために使用される、上述の手順と実質的に類似するであろう。しかしながら、この場合、新しいハッシュ関数が、あらゆる後続のセキュリティシステム動作の目的のために、オリジナル機能を置換可能である場合でも、この新しいハッシュ関数自体は、依然として、その信頼の基点の基礎として、オリジナルハードウェアハッシュ関数に依存し得ることに留意されたい。したがって、用語「条件付き完全置換」が使用される。一実施形態では、オリジナルのハードウェアベースの信頼の基点は、一定のままであってもよい。これは、そのようなハードウェアベースのセキュリティシステムを攻撃することが非常に難しくなり得るという点において、望ましいであろう。しかしながら、オリジナルハードウェアハッシュ関数における欠点が、標的デバイスが現場に配備された後に見つかる場合、そのような欠点は、潜在的に、呼出し引数を効果的に制限可能な単一アプリケーション内においてオリジナルハッシュ関数を使用することによって含有され得る。
【００８５】
ハードウェアハッシュ関数の第２の特性は、構造上不可視の秘密キーをそのシード値として使用し得ることである。したがって、同一入力引数を前提とする場合でも、そのようなハードウェアハッシュ関数のメッセージダイジェスト結果は、ユニット毎に異なり得る。この差異は、あらゆる標的ユニットに対して一意的なメッセージダイジェストをもたらし得るという点において活用されることが可能である。この特性は、デジタル署名の概念と類似するが、必ずしも、ハードウェアハッシュ関数に対して、別個の暗号化／復号化ブロックの追加を要求しない。次いで、候補コードセグメントは、ハードウェア生成メッセージダイジェストが、候補コードセグメントとともに分配されるものと整合するユニット上のみでの実行（少なくとも、セキュア化モードにおいて）に制約されるので、循環依存関係が生成される。この循環依存関係は、そのメッセージダイジェストが、正確な標的ユニットの秘密キーによって生成されたコードのみが、実際に、この同一秘密キーを利用可能であることを意味する。この特性は、標的デバイス上においてセキュア化モードで実行可能となるコードセグメントを生成する、可能性のある攻撃者の能力を実質的に損なわせる。
【００８６】
コードセグメントは、特定の標的デバイス（または、さらに特有の終点デバイス集合）に「結合」可能であるので、上述のメカニズムは、「セキュア化コード結合」と呼ばれる。上述のように、セキュア化コードの実行ブロックが割り込まれると、コンテキストは保存されず、したがって、このコードセグメントの実行は中止されるか、または最初から再開されなければならない。また、セキュア化モードにおけるコードセグメントの実行が割り込まれると、プロセッサは、もはやセキュア化モードで動作せず、構造上不可視の秘密キーへの任意のアクセスは、プロセッサがセキュア化モードに戻るまで、遮断され得る。また、ある実施形態においては、任意のオフチップ格納動作は、プロセッサがセキュア化モードで動作中は、制御されるか、または禁止され得る。
【００８７】
論じられるように、ある実施形態においては、各標的ユニットは、構造上不可視の一意的な秘密キー集合を有してもよい。しかしながら、別の実施形態においては、これらのキーのあるサブ集合が、いくつかの同等のデバイスに対して共通であってもよい。したがって、特定のコードセグメントは、キーの共通サブ集合によって、特定の種類の終点デバイスに結合可能である一方で、依然として、そのようなデバイス間で共通に保持される、この構造上不可視の秘密キー集合を保護する。したがって、ハードウェアハッシュ関数と１つ以上の構造上不可視の秘密キーの組み合わせは、高度に効果的かつロバストな再帰的セキュリティプロトコルのための信頼の連鎖の基礎を提供し得る。
【００８８】
次に、種々の実施形態の実装の詳細について、添付図面を使用して、さらに説明される。これらの実施例のすべてにおいて、用語「デジタルビットストリーム」とは、デジタルデータの一般的集合を指し、したがって、この用語は、デジタルコンテンツ、コードブロック、またはデジタルデータ集合等の用語と交換可能に使用されてもよいことに留意されたい。コードブロック用語の場合、参照データは、さらに、実行可能ファイル、実行可能スクリプト、あるいはアルゴリズム的記述または疑似コードのブロックさえ表すものと想定され得る。
【００８９】
図３は、デジタルコンテンツのための複合キー作成の一実施形態を図示する。この複合キー３１０は、特定の終点デバイス（標的ユニット）と関連付けられた構造上不可視の秘密キー（上述のような）であり得る終点特有のハードウェアキー３４０を利用して、暗号化エンジン３２０をグローバルコンテンツキー３３０（デジタルコンテンツの所有者または著者によって提供あるいは決定されてもよい）を適用することによって、作成されてもよい。特定の終点およびデジタルコンテンツの両方に特有である、結果として生じる複合キーは、複合キーが提供される終点デバイス上に伝送および格納され、そこに暗号化されていない状態で格納されてもよい。
【００９０】
図４Ａは、セキュア化デジタルデータブロック構造の作成の一実施形態を図示する。この実施形態では、デジタルデータブロック４１０は、暗号化されなくてもよいが、デジタル署名４２０は、１つ以上のトークン４４０または４５０によって、デジタルデータブロックからのハッシュ関数４３０によって計算されたメッセージダイジェストを暗号化することによって形成される。これらのトークンは、タイムスタンプ等の秘密キーまたは公的に利用可能なデータであってもよい。暗号化エンジン４６０および４６１を通過するデータを暗号化するために採用される方法は、同じであっても、またはそうでなくてもよいことに留意されたい。秘密キーが、暗号化キーの１つとして使用される場合、その秘密キー値の知識なく、デジタル署名を偽造することはより困難となり得る。また、暗号化動作４６０および４６１の順序は、結果のセキュリティ全体に関連しないが、結果として生じるデジタル署名４２０は、動作の順序が変更されると異なるであろうことに留意することは有益である。
【００９１】
図４Ｂは、セキュア化コードブロックデータ構造の作成の代替実施形態を図示する。この場合、秘密キー４７０は、デジタルデータブロック４７１に付加され、メッセージ４８０全体を形成する。上述のように、この付加作用が、オリジナルデジタルデータ集合４７１の前または後に秘密キー４７０を置くかは、必ずしも、得られたセキュリティのロバスト性に関連しないが、順序が変更されると最終結果は異なるであろう。また、セキュリティを保証するために、秘密キー４７０は、オリジナルデジタルデータ集合４７１とともに公開されるべきであることに留意されたい。したがって、公開されるデータ集合は、データ構造４８０全体ではなく、デジタルデータ集合４７１だけに制限されるであろう。次いで、このデータ構造４８０全体は、図４Ａに関して上述のものと本質的に同一態様で、ハッシュ関数４３０にかけられる。しかしながら、本実施形態では、最終出力４９０は、図４Ａに示されるデジタル署名４２０の特徴の多くを有するが、暗号化エンジン４６０または４６１の使用を必要とし得ない。したがって、この動作の結果４９０は、デジタル署名同等物と呼ばれるであろう。このデジタル署名同等物４９０は、各一意的データ構造４８０全体に対して、一意的である（ハッシュ関数４３０が、適切に構築されていると想定して）ことに留意されたい。したがって、秘密キー４７０が、デジタルデータ集合４７１の著者およびそのデジタルデータ集合の消費者（終点デバイスまたは標的デバイス）によってのみ共有される場合、これらの２人の当事者のみが、同一の正確なデジタル署名同等物４９０を再作成することが可能であるはずである。この場合、デジタルデータブロック４７１は、その秘密キー４７０（したがって、標的デバイス）に「結合」されているとみなされ得る。
【００９２】
図５Ａは、本明細書に説明されるもの等のセキュリティシステムを使用して、どのように暗号化されたデータブロック５１０を特有の復号化エンジンコードブロック５６２に暗号学的に結合し、次いで、ハッシュ関数５４０および暗号化エンジン５６１によって計算されるデジタル署名５２４を使用して、その組み合わせ５３０を特有の終点のハードウェア秘密キー５２３に結合し得るかの一実施形態を図示する。この実施例では、公開キー５２２（グローバルコンテンツ秘密キー５２０によって、復号化エンジンコードブロック５６２のメッセージダイジェスト５２１を暗号化することによって構築される）は、単一の連結されたデータ集合５３０として、オリジナルの暗号化されたデータブロック５１０とともに公的に分配されることに留意されたい。組み合わせられたメッセージ５３０（公開キー５２２と組み合わせられたオリジナルの暗号化されたデータブロック５１０を備える）のメッセージダイジェストから、デジタル署名５２４を作成する作用は、適切に承認された終点デバイスのみが、オリジナルの暗号化されたデータブロック５１０を復号化可能であるだけでなく、この復号化プロセスが、復号化エンジン５６２の所定の方法を使用することによってのみ達成可能であることを保証する。暗号化エンジン連鎖５６０により多くの構成要素（例えば、多項複合暗号化等）を追加することによって、より多くの制約が、復号化承認手順に容易に追加可能であることに留意されたい。
【００９３】
図５Ｂは、図５Ａに示される実施形態の変形例を図示する。この実施形態においては、特定の暗号化されたメッセージ５１１の著者は、特有の終点デバイス上においてのみ明確に認証可能である。ここでは、オリジナルの暗号化されたデータブロック５１１は、上述のように、特有の復号化ルーチン５６２に暗号学的に結合される。この時点では、復号化ルーチン５６２は、非対称暗号化エンジンであって、入力は、著者の秘密個人キー５２５であり得、出力は、著者の公開キーを使用してのみ、正確に復号化されるであろうことが、さらに規定され得る。非対称暗号化ルーチン５６２のメッセージダイジェスト５２７は、デジタル署名５２６とともに、オリジナルの暗号化されたデジタルデータ５１１に付加され、データ構造５３１全体を形成する。次いで、データ構造５３１は、その終点デバイスの秘密キー５２３、ハッシュ関数５４４、および暗号化エンジン５６１を使用して、デジタル署名５２８を形成することによって、特有の終点デバイスに暗号学的に結合可能である。この実施形態の場合、暗号化されたメッセージ５１１が、本物であって、その著者が、既知であるだけではなく、著者がハードウェア秘密キー５２３を所有しているという事実を保証可能である。ここでは、本明細書において使用されるように、著者という用語は、必ずしも、データの創設者を意味するわけではなく、また、使用許諾者、配信者、あるいはそのようなデータの配信または別様に通信を所望する別の種類のエンティティをも指し得ることに留意されたい。この特定の信頼の連鎖の使用が重要となり得る一実施例は、終点デバイスのセキュリティシステムが、セキュア化コードブロック（オリジナルデータブロック５１１内に、暗号化された形式で含有されるであろう）を使用して、アップデートされるべき場合である。
【００９４】
図６は、セキュア化コードブロック６２０の実行を制御するために、カスケード式ハッシュ方法を利用する一実施形態を図示する。この場合、２つの独立コードブロック６１０、６２０が存在する。本実施例では、第１のコードブロック（セキュア化コードブロック６１０）は、第２のルーチン（セキュア化コードブロック６２０）に対する埋め込みサブルーチン呼出しを含む。したがって、セキュア化コードブロック６１０のためのハッシュ関数６４０によって算出されたメッセージダイジェスト６３０は、セキュア化コードブロック６１０内に含有される、セキュア化コードブロック６２０への参照に依存する。次いで、このメッセージダイジェスト６３０は、セキュア化コードブロック６１０の観点から、２つのセキュア化コードブロックをともにリンクする。次に、メッセージダイジェスト６５０は、ハッシュ関数６７０を使用して、コードブロック６２０のために構築されてもよい。しかしながら、メッセージダイジェスト６５０をセキュア化コードブロック６２０だけではなく、その呼出し親ルーチン（この場合、セキュア化コードブロック６１０）の両方に結び付けるために、オリジナルメッセージダイジェスト６３０は、ハッシュ関数６７０によって算出されるメッセージダイジェスト６５０へのシードとして使用されてもよい。そのようなシード値は、多くの方法において実装可能であるが、しかし、１つのそのような方法は、単に、オリジナルメッセージダイジェスト６３０を第２のデジタルデータ集合（例えば、この場合、セキュア化コードブロック６２０）に連結し、メッセージ６６０全体を形成することであることを思い起こされたい。次いで、メッセージ６６０全体は、ハッシュ関数６７０（ハッシュ関数６４０と同一である、またはある別の独立ハッシュ関数であることが可能である）にかけられ、第２のメッセージダイジェスト６５０を形成し、したがって、セキュア化コードブロック６２０だけではなく、オリジナルメッセージダイジェスト６３０（それ自体、セキュア化コードブロック６１０および６２０の両方に依存する）の両方に依存する。図４Ｂの議論に記載したように、これらの連結された要素６２０および６３０の順序は、結果として生じるメッセージダイジェスト６５０に重要であり得るが、ハッシュ関数６７０の場合、メッセージ６６０全体を備える要素の順序は、ハッシュ関数６７０のセキュリティに実質的な影響を及ぼし得ない。
【００９５】
次いで、この第２のメッセージダイジェスト６５０は、セキュア化コードブロック６２０が、コードブロック６１０から呼び出される場合にのみ正確に実行され得ることを保証する、上述と実質的に類似する態様で使用可能である。コードブロック６２０は、実際に、コードブロック６１０の正確な複製（または、同等参照）であり得、これは、再帰的システムの実施形態となるであろうことに留意されたい。同一コードブロックの２つの事例間の唯一の相違は、セキュア化コードブロックメッセージダイジェストを形成するために、コードブロックに付加される特定のメッセージダイジェストであり得る。
【００９６】
この特定の実施形態においては、任意の秘密キーを使用しておらず、したがって、この種類の構造は、本明細書において説明されるものと同一のセキュリティシステム全体を使用する、任意の終点デバイス上で適切な実行順序を実施するための特異性を伴わずに使用可能であることに留意されたい。また、上述のように、類似の実施例は、加えて、セキュア化コードブロック６１０または６２０のいずれかの実行が、それぞれ、メッセージダイジェスト６３０または６５０の代わりに、複合キーベースのデジタル署名構造あるいはその同等物を利用することによって、ある特有の終点デバイスもしくはデバイスの集合に制約されるように構築されてもよい。
【００９７】
図７Ａは、セキュア化コードブロックメッセージの構築の実施形態を図示する。一実施形態では、暗号化されたデジタルデータ集合７１１は、ポインタ７２０によって識別される暗号化アルゴリズムを使用して暗号化されている。データ構造７３０は、デジタルデータ集合７１１およびポインタ７２０の連結によって形成される。データ構造７３０のメッセージダイジェスト７５０は、ハッシュ関数７４０によって生成される。この配設は、暗号化されたデータ集合およびその関連付けられた復号化ルーチンの暗号学的結合を可能にする。
【００９８】
第２の実施形態では、付加的条件が、連結されたデータ構造７３１に、すなわち、ポインタ７２１が復号化キー７６０に追加される。このキー７６０は、この特定の実施形態に図示されるように、必ずしも、ハードウェアベースの秘密キーではないことに留意されたい。実際、ポインタ７２１によってポイントされるキー７６０は、以下の図７Ｃの説明に論じられるように、それ自体がデータ構造であってさえよい。その他の点では、この実施形態は、上述の実施形態に実質的に類似する。暗号化されたデジタルデータ集合７１１は、オリジナルの非暗号化データ集合７１０に作用する暗号化エンジン７７０および１つ以上のキー７６０を使用する結果として作成される。メッセージダイジェスト７５１は、連結されたデータ構造７３１にハッシュ関数７４１を使用して生成される。この場合、現状では、非暗号化データ集合７１０を暗号化エンジン７７０だけではなく、暗号化されたデータ集合７１１から非暗号化データ集合７１０を再作成するために使用することが可能な一意的キー７６０の両方に暗号学的に関連付けるためのメカニズムが存在する。上述の実施形態と同様に、構造全体を所与の終点デバイスおよびその一意的秘密ハードウェアキー７６０に関して充足されているべき特有の条件集合に暗号学的に結合するために、付加的条件が、暗号化連鎖に追加されてもよい。デジタルデータ集合７１０および７１１のフォーマットおよび暗号化状態（すなわち、暗号化されているか、またはそうでないか）は、これらの詳細が、ポインタ７２０、７２１から推測可能であるので、このプロセスに関連し得ないことは着目に値する。
【００９９】
この点を考慮して、図７Ｂは、このように、再帰的セキュリティシステムにおいて使用可能なユニバーサル暗号化データ構造のための基本的な汎用フォーマットの１つの可能性のある実施形態を図示する。この構造の実施形態は、単純かつ強力であり得、一般的データブロック７１２、復号化ポインタ７２０、および復号化キーポインタ７２１の３つの基本的要素の単純にリンクされたリストとして実装可能である。リンクされたリスト全体は、データ構造７３２内でともにバンドルされる。リンクされたリストを使用することによって、連結されたデータ構造７３２内の要素の順序が、その機能に関連しないが、データ構造の動作または評価に影響を及ぼし得ることが容易に分かる。一般的（例えば、所定ではない）データブロック構造およびリンクされたリストのフォーマットを使用する、別の興味深い側面は、３つの要素７１２、７２０、ならびに７２１もまた、必ずしも、線形または連続的にさえ、順序付けられる必要がないことである。したがって、一実施形態は、データ構造７３２全体と併せて格納される、独立しているが、恐らく、関連している、ある他のデータを含む、補助データ構造７１３を備えてもよい。この概念の一実施形態は、図７の補助データ構造７１３内のポインタ７２０によってポイントされるもの等、実際の復号化エンジンコードブロック７７１を特定することであろう。別のそのような実施例は、この補助データブロック内のポインタ７２１によって規定される、実際のキー値を格納し得る。
【０１００】
これら両方の場合、そのような補助データブロック内に含有される実際のデータは、図４Ａ、４Ｂ、５Ａ、５Ｂ、６、および７Ａに提示される、実施形態の実施例に様々に図示されるように、メッセージダイジェストまたはデジタル署名を生成するプロセスにおいて使用されてもよい。この開示に記載されるように、連結されたデータ集合内に格納される種々のデータフィールドの順序は、ハッシュ関数が適切に設計される場合、結果として生じるメッセージダイジェスト（または、デジタル署名）に影響を及ぼし得る。
【０１０１】
したがって、また、類似ブロック構造を使用して、ある実施形態で利用されるキーをセキュア化してもよいことは、明白であろう。図７Ｃは、キーのみを備える、そのようなセキュア化データブロック７３３の一実施形態を図示する。ここでは、データブロックは、デバイス特有のキー７１４、７１５、７１６（または、所望に応じて、その他）のリストを備えてもよい。この実施例では、これらのキーのいずれも、（例えば）終点デバイス７６０の秘密キーと、それぞれ、暗号化エンジン７７１および７７２を使用して暗号化された終点デバイスタイムスタンプレジスタ７９０を使用して作成されてもよい。セキュリティシステムのロバスト性の観点からのそのような動作の上述の説明と同様、暗号化エンジン７７１および７７２が、個別またはさらに異なっているべきであるという要件は存在せず、暗号化連鎖におけるある数のこれらの暗号化動作に対して、基礎的限度がなくてもよい一方、これらの動作の順序は、結果として生じる複合キーに重要でなくてもよく、暗号化動作のための特定の順序に対する要件は存在しない。この場合に留意すべき他の特徴の１つは、連結されたキーリストデータ構造７３３のキーリストポインタ要素７２１が、さらに別の連結されたキーリストデータ構造７３４をポイントし得ることである。これらのデータ構造は両方とも、図７Ｂに図示されるように、同一ユニバーサル暗号フォーマットであるため、キーリストデータ構造は、再帰的態様で形成可能である。故に、そのような再帰的セキュリティシステムにおける実施形態で使用するためのキー７３３は、そのようなセキュリティプロトコルの実施形態が適用され得る、任意の他のデータと同一態様および同一構造を使用して、保護されてもよく、同様に、これらの保護されたキーは、また、本明細書に開示されるシステムおよび方法の実施形態によってセキュア化された他のデータと同一態様において、終点デバイス上で復号化および認証されてもよい。
【０１０２】
次に図８を参照すると、複合キーがどのように暗号化されたコンテンツを復号化するために利用され得るかについての一実施形態が図示されている。この復号化動作は、上述のように、「セキュア化モード」において生じてもよい。ここでは、コンテンツ８１０は、複合キー８３０とともに、終点デバイスに提供されてもよく、そこでは、コンテンツは、最初に、グローバルコンテンツキーを使用して暗号化される。複合キー８３０は、図３に上述のように、作成されてもよい。故に、暗号化されたコンテンツ８１０が、終点デバイスで受信されると、関連付けられた複合キー８３０とともに受信され得る。デバイスにおける秘密キー８４０が、アクセスされ得るように、セキュア化モードで実行することによって、複合キー８３０は、セキュア化コードブロック８６０内で復号化され、グローバルコンテンツキーをもたらし得る。グローバルコンテンツキーは、次に、セキュア化コードブロック８６０内で使用され、オリジナルの暗号化されたコンテンツ８１０を復号化し、復号化されたコンテンツ８８０をもたらしてもよい。
【０１０３】
図９は、コードブロックが、実行前に特定の終点デバイスにおいて起動するために承認されていることを照合するために、どのように秘密キーが利用され得るかの一実施形態を図示する。実行のための候補コードブロック９１０は、終点デバイスに提供されてもよく、または受信された暗号化されたデジタルコンテンツを復号化することによって得られてもよい（例えば、図８に上述のように）。加えて、終点デバイスは、候補コードブロック９１０に相当する、対応するデジタル署名９２０を受信してもよい。このデジタル署名９２０は、終点デバイスハードウェア特有の秘密キー９３０を使用して暗号化されているコードブロックから作成される（例えば、そのコードブロックをハッシュすることによって）、メッセージダイジェストを備えてもよい。したがって、候補コードブロック９１０が実行され得るかどうかを照合するために、認証動作が、セキュア化モードで実装されてもよく、それによって、候補コードブロック９１０が、メッセージダイジェスト（９１２）を作成するためにハッシュされる。次いで、このメッセージダイジェスト９１２は、終点デバイスの終点デバイスハードウェア特有のキー９３０（照合がセキュア化モードで生じるため、アクセス可能であってもよい）を使用して暗号化され、ステップ９１４において、オリジナルとして供給されたデジタル署名９２０と比較される、デジタル署名を作成可能である。このデジタルハードウェア生成デジタル署名が、候補コードブロック９１０に対応する、受信したデジタル署名９２０と整合する場合、候補コードブロック９１０は、照合され、考えられ、実行可能であるとみなされてもよく、そうでなければ、例外エラーが生じ得る（ステップ９１６）。
【０１０４】
図１０は、コードブロックが、どのように「セキュア化実行」モードにおいて、特定の終点プロセッサ（所定の環境下）上で起動可能となり得るかの一実施形態のブロック図である。この特定の場合、コードブロック１０１１の事前に算出されたデジタル署名１０３０（また、終点特有の復号化キーとも称され得る）は、コードブロックのメッセージダイジェストを使用し、承認標的終点デバイスの秘密キー１０４０、承認標的終点デバイスの最も新しいタイムスタンプ値１０４１、または上述のような任意の数の制約条件の１つ以上（この特定の実施形態では図示せず）の１つ以上によって暗号化することによって構築される。
【０１０５】
また、これらの条件の任意の１つも、マスク機能を条件自体のサブ集合に適用することによって事前に条件付けられ得ることに留意されたい。例えば、タイムスタンプフィールドのいくつかの最小有効ビットのマスクが、外されている場合（したがって、デジタル署名の計算では考慮され得ない）、そのタイムスタンプ値の有効粒度は、ハードウェアにおける任意の変更を伴わずに、コードセグメント基準によって、コードセグメント上で容易に制御可能である。この同一原理は、ある実施形態において、デジタル署名の計算において使用される、任意の数の条件に提供可能である。
【０１０６】
図７に図示されるキーリストデータ構造と同様、コードブロック１０１１を含有する、連結されたデジタルデータ集合１０１０は、また、少なくとも１つの復号化ポインタ１０１２および少なくとも１つの復号化キーまたはキーリストポインタ１０１３を含む。また、上述のように、これらのいずれか１つは、外部データ構造（終点特有のデジタルキーまたはデジタル署名１０３０等）、あるいは連結されたデータ集合１０１０内に全体として含有される、埋め込みデータ構造を参照してもよい。
【０１０７】
図１０に示される実施形態を説明する目的として、コードブロック１０１１は、暗号化されていない（したがって、潜在的に、終点デバイス標的プロセッサ上で実行可能である）ことを前提する。この場合、復号化ポインタは、その使用に先立って、コードブロック１０１１のためにさらなる復号化が要求されないため、空値であってもよい。この場合のように、コードブロックが、暗号化されていない場合、その対応する復号化キー（ポインタ）１０１３は、関連付けられた終点またはハードウェア特有のデジタル署名１０３０をポイントしてもよい。したがって、図４Ａ、４Ｂ、５Ａ、および５Ｂに上述のもの等のデータ構造ならびに方法の実施形態を使用して、ブロック１０１１に図示されるような非暗号化データ集合の使用に関する、多種多様な認証、暗号学的結合、または他の制約を施行してもよい。
【０１０８】
終点特有のデジタル署名（または、復号化キー）１０３０が、ハードウェア秘密キー１０４０のみ、または代替として、ハードウェア秘密キー１０４０および終点デバイスタイムスタンプレジスタ１０４１のみをポイントする場合、セキュリティシステム関連呼出しが、呼出し連鎖の「最下層」に到達し、この特定の呼出し連鎖におけるセキュリティシステムの付加的層へのさらなる呼出しが存在しないことを決定可能となる。したがって、セキュリティシステム再帰は、この時点で「終了」する。この再帰終了条件は、終点特有のハードウェア秘密キー１０４０の値へのアクセスを選択的に許可または拒否する「ゲートキーパー」として、したがって、ハードウェアハッシュ関数ブロック１０６１の使用する暗号化機能への入力成分としてのみ作用する、ハードウェアブロック１０５０によって検出される。図１０に示される実施例では、ハードウェア特有の秘密キー１０４０およびハードウェアハッシュ関数ブロック１０６１の（メッセージダイジェスト）出力は、暗号化エンジン１０６２および１０６３への入力引数として使用される。
【０１０９】
最後に、そこで、暗号化エンジン１０６３の出力（オリジナルの連結されたデータ構造１０１０のデジタル署名である）が、供給されたデジタル署名１０３０の値と整合する場合、「セキュア化モード有効化」ハードウェアビット１０７０が、設定される。この条件は、終点ハードウェアＩ−キャッシュ１０２０にロードされた候補コードブロック１０１１が、現時点において、「セキュア化」モードで実行することが承認されていることを示す。Ｉ−キャッシュ１０２０内に常駐する候補コードブロック１０１１への物理的変更、またはＩ−キャッシュ１０２０自体への任意の変更が存在しないことに留意されたい。この時点で変更されている唯一のものは、「セキュア化モード有効化」ハードウェアビット１０７０の値である。
【０１１０】
図１１は、再帰的セキュリティシステムによって行われ得る、復号化動作の一実施形態を図示する。この復号化動作は、配信されたコンテンツを復号化または別様に操作および利用するプロセスにおいて、使用されるべきセキュア化コードブロックを照合してもよい。上述のように、終点デバイスは、暗号化されたコンテンツ１１１１を含有するデータ構造１１１０、復号化エンジン１１２０へのポインタ１１１２（または、復号化エンジン自体）、および終点特有の複合キー１１３０へのポインタ１１１３（図９に関して上述のように）を受信してもよい。セキュア化モードにおいて実行可能にされる前に、ポイントまたは受信される複合復号化エンジン１１４０が認証されるであろう。この認証は、終点デバイス内に常駐するハッシュ関数１１２１を使用して、複合復号化エンジン１１４０コードブロックのメッセージダイジェスト１１２２を計算することによって、達成されてもよい。ハッシュ関数１１２１は、本実施例では、ハードウェアブロックとして図示されているが、このハッシュ関数１１２１は、上述のように、例えば、終点デバイスの内蔵ハードウェアハッシュ関数の代わりに使用可能なセキュア化ソフトウェアコードブロックであってもよいことに留意されたい。しかしながら、この場合、ハッシュ関数のソフトウェアバージョンは、依然として、最終的には、認証または承認目的のために、内蔵ハードウェアハッシュ関数に依存し得、したがって、この場合の最終的信頼の基点は、依然として、終点の内蔵ハードウェアハッシュ関数ブロック１１２１とともに常駐する。
【０１１１】
次いで、このハッシュブロック１１２１によって生成されるメッセージダイジェスト１１２２は、ステップ１１２３において、復号化エンジン１１４０に対応する、事前に算出されたメッセージダイジェスト１１５０と比較されてもよい。この事前に算出されたメッセージダイジェスト１１５０は、例えば、セキュアな方式において、終点デバイスに提供されるか、または終点デバイス自体で事前に算出され、格納されてもよい。メッセージダイジェストが整合する場合、複合復号化エンジン１１４０は、終点デバイス（ステップ１１２５）上で実行可能となってもよい。メッセージダイジェストが、実質的に等しくない場合、無効なコード例外が生じ得る（ステップ１１２６）。
【０１１２】
しかしながら、メッセージダイジェストが、実質的に等しい場合、終点デバイスのプロセッサは、セキュア化実行モードを入力し、複合復号化エンジン１１４０内に含有されるコードを実行してもよい。この複合復号化エンジン１１４１の第１の部分は、複合キーからグローバルコンテンツ特有のキーを生成するために、終点デバイスのハードウェア特有の秘密キー１１３１を利用して達成されてもよい（ステップ１１３２）。次いで、第２の復号化動作１１４２は、得られたグローバルコンテンツ特有のキーを使用して、暗号化されたコンテンツ１１１０から復号化されたコンテンツ１１５２を生成するために、復号化動作１１４１によって生成された中間結果を使用してもよい。ここでは、復号化エンジン１１４０は、一対の復号化アルゴリズム（１１４１および１１４２）として図示されるが、オリジナルの暗号化されたデータ集合１１１０に適用される、セキュア化コードブロック１１４０の種々の個々の構成要素（１１４１、１１４２等）の動作の最終結果が、所望の復号化されたコンテンツ結果１１５２を生成するように、任意のより少ないまたはより多い数のカスケード式復号化段階を包含してもよいことに留意されたい。また、これらの種々の個々の復号化構成要素の任意の２つは、同一または異なるアルゴリズムであってもよいことに留意されたい。
【０１１３】
ある実施形態では、加えて、さらなるセキュリティを層状にすることが所望さ得、したがって、いくつかの実施形態では、複合キーは、図４Ａ、７Ｃ、および１０に関して上述のように、実質的に同一態様において、終点デバイス特有のハードウェアキーおよび終点特有のタイムスタンプ値を使用して、事前に算出されたメッセージダイジェストから形成されてもよい。
【０１１４】
図１２は、終点デバイスにおける、再帰的セキュリティプロトコルの実装の一実施形態を図示する。具体的には、セキュア化コードブロックの照合のためだけではなく、配信されたデジタルビットストリームの実際の復号化／または他の使用のための複合キー集合の使用の一実施形態について図示される。本実施形態は、多くの側面において、図１１に図示される実施形態に類似しており、したがって、実施形態の異なるそれらの側面のみ、図１２に関して焦点が当てられる。暗号化されたコンテンツ１２１１を備えるメッセージ１２１０は、復号化エンジン１２４０（または、復号化エンジン自体）、コンテンツ特有の複合キー１２３１（図８に関して上述のように）、ならびに終点およびタイムスタンプ特有の複合キー１２３２へのポインタ１２１２を含め、受信されてもよい。暗号化されたコンテンツ１２１１は、終点デバイスにおけるメモリ内にロード可能であって、また、復号化エンジン１２４０へのポインタ１２１２も、メモリ（例えば、終点デバイスにおける命令キャッシュまたは命令キャッシュのセキュア化部分）内にロードされてもよい。次いで、ポイントされる復号化エンジン１２４０が認証されるであろう。この認証は、図１１に関して上述のものと実質的に類似態様において、終点デバイス内に常駐するハッシュ関数１２２１を使用して、暗号化エンジン１２４０のメッセージダイジェストを算出することによって達成されてもよい。
【０１１５】
次いで、本実施例では、ハードウェア生成メッセージダイジェストは、ハードウェアまたは終点デバイス上のソフトウェアの中に実装されてもよく、算出されたメッセージダイジェストおよび終点デバイスハードウェア特有の秘密キー１２７０または終点デバイスタイムスタンプレジスタ１２６０の値等のハードウェア特有のキーあるいはレジスタの１つ以上に作用する、１つ以上のカスケード式複合暗号化エンジン段階１２２４、１２２５等を備える暗号化エンジンを使用して、暗号化されてもよい。生成される、結果として生じる複合デジタル署名１２２６は、復号化エンジンコードブロック１２４０に正確に対応してもよく、したがって、また、特有の終点デバイスに暗号学的に結合されてもよい（１つ以上の暗号化段階１２２４、１２２５と、１２６０および１２７０等の種々の秘密または公開変数あるいは定数を使用することによって）。上述のように、この生成されたデジタル署名は、随意に、この複合デジタル署名の可用性をさらに制限するために、他の制約変数または定数とともに、さらに暗号化されてもよい（同一または異なる暗号化エンジンを使用して）。また、例えば、このデジタル署名１２３２と関連付けられたコードブロック１２４０の用途が、単一の一意的終点ユニットを超えて、拡張することが所望される場合、暗号化段階の１つ以上は、随意に潜在的に生成された複合デジタル署名整合のフィールドを拡大するために制限されてもよい。
【０１１６】
次いで、生成された複合デジタル署名１２２６は、ステップ１２２３において、オリジナルとして終点デバイスに提供され得る（例えば、事前に、終点コード使用許諾プロセスの一部として、使用許諾権限者によって）、その暗号化エンジン１２４０に対応する終点およびタイムスタンプ特有の複合デジタル署名１２３２と比較されてもよい。データ構造は、このトークン１２３２が、デジタル署名またはキーであるかにかかわらず、等しくあり得、したがって、用語「キー」および「デジタル署名」は、それらの場合、可能性として、互換可能に使用されてもよいことに留意されたい。
【０１１７】
複合デジタル署名１２２６および１２３２が、実質的に同じである場合、終点デバイスのプロセッサは、復号化エンジンコードブロック１２４０内に含有されるコードをセキュア化実行モードで起動することが可能となり得る。セキュア化実行モードで起動すると、復号化エンジン１２４０は、復号化エンジン１２４１または１２４２を使用して、デバイス特有の複合キー１２３１からグローバルコンテンツ特有のキーを生成するために、終点デバイスのハードウェアキー１２７０を利用してもよい。したがって、グローバルコンテンツ特有のキーは、中間結果であってもよく、故に、複合復号化エンジンコードブロック１２４０以外の任意のソフトウェアまたはハードウェアエンティティに決してキャッシュされないか、あるいは別様に可視となり得ない。次いで、このグローバルコンテンツ特有のキーは、復号化エンジン１２４３によって使用され、オリジナルの暗号化されたコンテンツ１２１１から、最終復号化コンテンツ１２５０を生成する。
【０１１８】
しかしながら、生成されたデジタル署名１２２６が、供給されたデジタル署名１２３２と実質的に整合しない場合、復号化エンジンコードブロック１２４０利用の試みが、未承認当事者によって行われる場合を含む不整合が生じ得る、いくつかの可能性のある理由が存在するであろう。しかしながら、不整合の別の可能性のある理由は、復号化エンジンのためのソフトウェアがアップデートされた（および、終点のタイムスタンプレジスタが、同様に、漸増または別様に変更された）場合であろう。この場合、２つのデジタル署名は整合し得ず、ステップ１２８１において、暗号化エンジンコード１２４０自体が、暗号化されている（例えば）か、または別様に置換を必要としているかどうかチェックされてもよい。本明細書に論じられる実施形態は、再帰的セキュリティプロトコルのために効果的に利用され得、したがって、多くの場合、暗号化アルゴリズム（ポイントされるか、または暗号化されたコンテンツとともに含まれてもよい）自体が暗号化される、これらの暗号化された暗号化アルゴリズム自体が暗号化される等であってもよいことを思い起こされたい。したがって、暗号化アルゴリズムのための生成された終点およびタイムスタンプ特有の複合キー１２２６と、受信した終点およびタイムスタンプ特有の複合キー１２３２が整合しない場合、少なくとも１つ以上の層の間接参照または暗号化が利用されている場合であり得る。
【０１１９】
上述のように、特定の実行可能コードブロックに暗号化の層を追加する概念は、特定のコードブロックのアップデートされていないバージョンをそのコードブロックのより新しいバージョンと置換する作用と論理的に同等であり得る。故に、終点およびタイムスタンプ特有の複合デジタル署名１２３２、コードブロックの復号化ポインタ（図示せず）、またはコードブロックの復号化キーポインタ（同様に、図示せず）といった、そのコードブロックと関連付けられたトークンの１つ以上を検証することによって示されるように、復号化エンジン１２４０自体が、暗号化されているか、または別様に置換を必要とするか（ステップ１２８２に示されるように）どうかを決定可能である。一実施例では、コードブロック１２４０の関連付けられた復号化ポインタが、空値をポイントする場合、暗号化エンジン１２４０が、暗号化されていない、または別様にアップデートされておらず、したがって、生成されたデジタル署名１２２６および供給されたデジタル署名１２３２が、実質的に等しくないが、コードブロックを正確なデジタル署名を可能性として生成し得る異なるバージョンと置換するための他のリソースが存在し得ないため、例外エラーが生じ得る結果（ステップ１２８３）ことを示すであろう。しかしながら、復号化エンジンコードブロック１２４０の復号化ポインタが、別のコードブロック（別の（可能性として、アップデートされている）暗号化エンジン（図示せず）またはある他のコードブロック）をポイントする場合、この新しいコードブロックがロードされ、上述の認証ステップが、この次の暗号化エンジンに適用されてもよい（言い換えると、別の再帰層が導入されてもよい）。この再帰的実行メカニズムは、生成された終点およびタイムスタンプ特有の複合デジタル署名１２２６と供給された終点およびタイムスタンプ特有の複合デジタル署名１２３２との間に整合が生じると決定される（ステップ１２２７）、または整合が存在せず、復号化エンジン１２４０自体が、暗号化されておらず、その時点で、例外エラーが生じ得ると決定される（ステップ１２８３）まで、継続してもよい。
【０１２０】
生成された終点およびタイムスタンプ特有の複合デジタル署名１２２６と、供給された終点およびタイムスタンプ特有の複合デジタル署名１２３２が整合すると決定される場合に、再帰が終了され、巻き戻されてもよい。これは、再帰的呼出し連鎖全体を通しての初期順方向パスの際に直面し、スタックに保存される、コードブロックのそれぞれの認証および実行を伴ってもよい。これらのコードブロックの一部または恐らく全部さえ、必ずしも、暗号化または復号化エンジンでなくてもよいことに留意されたい。いずれの場合も、これらのコードブロックはそれぞれ、標的終点デバイスのプロセッサがセキュア化実行モードで動作中に認証され得る。
【０１２１】
この実行は、再帰的セキュリティシステムによって行われ得る復号化動作の一実施形態を図示する、図１３を参照することによって、より詳細に説明されるであろう。説明されるように、終点デバイスは、特に、暗号化されたコンテンツ１３１２とともに、コンテンツ特有の複合キー１３１６（図８を参照して論じられるように）、復号化エンジンデータ構造１３２０へのポインタ１３１３、またはオリジナルメッセージ１３１０内に埋め込まれる場合、復号化エンジン自体、およびキーまたはキーリストデータ構造１３１８をポイントするキーリストポインタ１３１４を含有し得る、メッセージ１３１０を受信してもよい。上述のように、このデータ構造は、キーまたはキーリスト１３１６あるいはデジタル署名１３１７を含んでもよい。同様に、復号化エンジンデータ構造１３２０は、暗号化されたコードブロック１３２１、暗号化された（または代替として、置換を必要とする古い）復号化コードブロック１３２１と関連付けられた後続の復号化ポインタ１３２２、および関連付けられた復号化キーリストポインタ１３２３を含有してもよい。後続の復号化ポインタ１３２２は、復号化コードブロックデータ構造１３２０のものと実質的に類似する構造を有するが、データ構造１３３０の場合、復号化コードブロック１３３１自体は、暗号化された形式ではない最終復号化コードブロックデータ構造１３３０をポイントしてもよい。
【０１２２】
図１３に図示される実施形態の動作は、以下のように説明可能である。暗号化されたコンテンツデータ構造１３１０が、その中に含有される暗号化されたコンテンツ１３１２を復号化することを予測して、終点プロセッサのメモリ空間内にロードされる。データ構造１３１０は、復号化ポインタ１３１３を含有するので関連付けられた復号化エンジンコードブロックデータ構造１３２０は、メモリ内にロードされ、読み込まれる。また、この後続のデータ構造１３２０は、復号化ポインタ１３２２を含有するため、次いで、ポインタ１３２２と関連付けられた復号化エンジンコードブロックデータ構造１３３０が特定され、メモリ内にロードされる。データ構造１３３０の場合、本実施例の埋め込み復号化ポインタ１３３２は、空値ポインタであると決定され、したがって、標的終点デバイスのセキュリティシステムは、現在の復号化再帰連鎖が終了し（例えば、図１０に論じられるように）、したがって、データ構造１３３０の一部として、メモリにちょうど読み込まれた復号化エンジン１３３１が、非暗号化（したがって、潜在的に、実行可能）コードブロックを含有し得ることを決定可能である。
【０１２３】
デジタルコンテンツ１３３１が、コードブロックであって、データではないことが決定可能であるため（呼び出された態様によって）、また、復号化キーリストポインタ１３３３（データ構造１３３０の一部として、メモリに内に読み込まれた）によってポイントされるキーリストデータ構造１３３８が、デジタル署名１３３７（複合キー１３３６に加え）を含有し得ることも決定可能である。また、本実施例におけるキーリストデータ構造（１３１８、１３２８、および１３３８）は、図７Ｂに関して上述のように、ユニバーサル暗号化データ構造を使用して実装されてもよいことに留意されたい。したがって、これらのキーリストデータ構造１３１８、１３２８、および１３３８内の引数の順序は、必ずしも、固定ではなく、したがって、データ構造自体がトラバースされるのに伴って、ランタイム時に解釈されてもよい。実際、これらのキーリストデータ構造（１３１８、１３２８、および１３３８）自体、補助的復号化ポインタおよびキーリストポインタをこれらのキーリストデータ構造（１３１８、１３２８、および１３３８）自体の一部または全部内に組み込ことによって、さらなる復号化または後続の解釈への参照を含んでもよいが、この特定の選択肢は、単純化を目的として、図１３の実施形態には図示されないことに留意されたい。
【０１２４】
さらに、キーリストデータ構造１３３８内のキーポインタ１３３６の少なくとも１つが、終点のハードウェア秘密キー１３９２への参照に対応することを決定可能である。終点のハードウェア秘密キー１３９２へのこの参照は、適切に確保された記憶場所（プロセッサのアーキテクチャの中に規定され得るが、決して、プロセッサによって直接読み取られ得ず、したがって、構造上直接不可視である場所）へポイントすることによって明示的に、またはポインタのためにある特別に確保された値を使用することによって暗示的に達成されてもよい。いずれの場合も、この参照は、種々の手段を使用して実装されてもよいが、１つのそのような実施形態の実施例は、キーリストデータ構造内の「０」の値（「空値」とは別として）を終点のハードウェア秘密キー１３９２への参照と一致させることであろう。キーリストデータ構造の少なくとも一部は、終点のハードウェア秘密キー１３９２を参照するという事実は、復号化エンジンコードブロック１３３１が、標的終点デバイスのプロセッサ上において、セキュア化実行モードで起動することが意図されることをさらに示し得る。したがって、ハードウェアベースのデジタル署名発生器ブロック１３９０の出力は、データ構造１３３７内に格納された値と比較される。２つの値が実質的に整合する場合、プロセッサは、セキュア化実行モードに入ることが可能となる。
【０１２５】
ここでは、ハードウェアベースのデジタル署名発生器ブロック１３９０（その一実施形態の詳細は、図１５に関して、より包括的に提示される）は、一実施形態では、１つ以上のソフトウェアベースの要素を備えてもよいが、また、上述のように、直接または間接的に、少なくとも１つのハードウェアベースのセキュリティ構成要素を備えてもよいことに留意されたい。そのハードウェア構成要素は、本明細書に含有される上述の説明の多くにおいて参照され、標的終点ユニットのセキュリティシステムの信頼の基点全体を成す、ハードウェアベースのハッシュ関数である。
【０１２６】
この時点では、次いで、復号化エンジンコードブロック１３３１が、セキュア化実行モードで起動可能となり、終点プロセッサが、潜在的に、セキュリティ関連動作の一部として、終点のハードウェアデバイス特有の秘密キー１３９２を利用可能となる（本明細書で上述のように）。プロセッサが、セキュア化実行モードで動作していない場合、秘密キー１３９２の値は、そのようなセキュリティ関連動作における使用のために利用可能とならないであろう。この概念は、プロセッサがセキュア化実行モードにおいて起動中の場合にのみ、秘密キー１３９２の値を後続の使用（例えば、復号化エンジンコードブロック１３３１における）に通過させる、ハードウェアアクセス制御ブロック１３４３として、図１３に関して図示される。
【０１２７】
加えて、ハードウェアアクセス制御ブロック１３４３への入力パラメータの１つは、アクセス制御ブロック１３４１の出力であることが分かる。このように、ハードウェアアクセス制御ブロック１３４３の状態（事実上、復号化コードブロック１３２１のための「セキュア化実行モード有効化」インジケータである）は、復号化コードブロック１３３１もまた、セキュア化実行モードで起動中であるという事実に依存する。これは、復号化コードブロック１３３１（例えば、ハードウェアアクセス制御ブロック１３４１の出力）のための「セキュア化実行モード有効化」インジケータの状態によって示されてもよい。この依存性は、復号化エンジンコードブロック１３２１の能力を、復号化コードブロック１３３１が、またセキュア化実行モードで起動中である場合にのみ、セキュア化実行モードで機能可能となるように制約する。本質的に同様の態様において、ハードウェアアクセス制御ブロック１３４３の出力は、復号化コードブロック１３１１のための「セキュア化実行モード有効化」インジケータである、ハードウェアアクセス制御ブロック１３４５への入力の１つとして使用される。したがって、両方が適切に認証され（図１４に関して、より詳細に説明されるように）、再帰的呼出し連鎖内の下位のセキュリティ連鎖の適切に承認された部分からの認証復号化結果が供給されている場合のみ、先行する親コードブロックがセキュア化実行モードで起動することを許可する目的として、呼出し連鎖を逆方向に後退して、「セキュア化実行モード有効化」ビットを伝播させるメカニズムとなる。上述のように、いくつかの条件の任意の１つは、「セキュア化実行モード有効化」ビットのいずれかを「非セキュア化」デフォルト状態にリセットさせてもよい（したがって、潜在的に、セキュリティ連鎖全体を再開させることを必要とする）ことに留意されたい。そのような条件は、プロセッサ割り込みまたは後続のデジタル署名比較不整合を含んでもよい。これらのハードウェアアクセス制御ブロック１３４１、１３４３、および１３４５は、図１３において、明確性を目的として、別個のエンティティとして図示されるが、それらは、実際、単一ハードウェアユニット（図１５に関して説明されるような）に埋め込まれてもよく、したがって、その出力は、その独自入力条件と１つとして、フィードバックされることが分かる。最終的には、連鎖全体における最高レベルまたは最終「セキュア化実行モード有効化」ビットの出力（本実施形態では、ハードウェアアクセス制御ブロック１３４５の出力）は、制御メカニズムの一部として使用され、標的デバイスに対するある外部可視出力を有効または無効にしてもよい（例えば、音声または映像出力を有効にする）。
【０１２８】
ステップ１３７０における復号化エンジンコードブロック１３３１の作用は、データ構造１３２０の復号化エンジンコードブロック部分１３２１内に格納されたデータ集合を、オリジナルデータのアップデートおよび／または適切に実行可能バージョンと置換または別様に補完することである。この作用は、１３２１内に格納されたオリジナルデータを利用して、キーリストデータ構造１３２８内に格納されたか、またはポイントされた１つ以上の復号化キーによって復号化することによって達成されてもよい。代替として、上述のように、復号化エンジンコードブロック１３３１の作用１３７０は、復号化コードブロック１３２１をアップデートされたバージョンと置換するか、またはさらに復号化エンジンコードブロック１３２１の代わりに直接実行することであってもよい。いずれの場合も、復号化エンジンコードブロック１３３１は、最初、（本実施形態では）標的終点デバイスのタイムスタンプレジスタ１３９４内に含有される値、標的終点デバイスのハードウェア特有の秘密キー１３９２（ハードウェアアクセス制御１３４２を通過することによって書き換えられるような）、ならびに終点およびタイムスタンプ特有の複合デジタルキー１３２６を含む、種々の入力データを使用して動作してもよい。復号化エンジンコードブロック１３３１が、続いて、復号化エンジンコードブロック１３２１の直接置換として動作する場合に、第２の入力データ集合（例えば、この実施形態においては、標的終点デバイスのタイムスタンプレジスタ１３９４内に含有される値、標的終点デバイスのハードウェア特有の秘密キー１３９２（ハードウェアアクセス制御１３４４を通過することによって書き換えられるような）、ならびに終点およびタイムスタンプ特有の複合デジタルキー１３１６）を利用してもよい。
【０１２９】
ステップ１３７１におけるアップデートされた復号化エンジンコードブロック１３２１のさらなる作用は、所望の出力データ１３８０を生成するために、オリジナルの暗号化されたコンテンツデータ１３１２を置換または別様に解釈することである。本作用は、１３１２内に格納されたオリジナルデータを利用して、キーリストデータ構造１３１８内に格納またはそれによってポイントされた１つ以上の復号化キーによって復号化することによって達成されてもよい。復号化エンジンコードブロック１３２１および１３３１両方の作用は、性質上類似するので、復号化エンジンコードブロック１３３１の動作の説明において上述の選択肢のいずれかが、復号化エンジンコードブロック１３２１のアップデートされたバージョンの動作に等しく適用可能であることは明白であるはずである。また、復号化エンジンコードブロック１３２１の動作の場合、いくつかの実施形態では、関連付けられたハードウェアアクセス制御ブロック１３４４は、ハードウェアアクセス制御ブロック１３４２と異なることに留意されたい。しかしながら、これらの２つのハードウェアアクセス制御ブロック１３４２および１３４４の作用は、それらの目的が、それぞれ、それらの関連付けられた復号化エンジン１３３１または１３２１によって、標的終点デバイスのハードウェア特有の秘密キー１３９２の使用を有効あるいは無効にするという点において、性質上類似しており、したがって、他の実施形態では、異なっていなくてもよい。
【０１３０】
最後に、上述の図１３の実施形態に図示される動作すべてにおいて、標的終点デバイスのタイムスタンプレジスタ１３９４の使用は、他の実施形態に対して本明細書に上述のそれらの実施例と本質的に類似する。したがって、レジスタ１３９４内に格納された値は、図１３に図示される特定の実施形態に記載される異なる承認ならびに復号化動作で採用される、種々の複合キーおよび／またはデジタル署名の発生において、付加的要素として使用されてもよいということになる。
【０１３１】
図１４は、再帰的呼出し連鎖が、そのようにトラバースおよび終了され、プロセッサが、どのように１つ以上の埋め込みコードブロックのメッセージ−ダイジェストベースの認証を使用して、セキュア化実行モードに入ることが可能となり得るかの一実施形態を図示する。本実施形態では、２つの候補コードブロック１４１２および１４２２の動作が説明され得、その両方とも、図７Ｂに関して上述のように、ユニバーサル暗号化データ構造（それぞれ、１４１１および１４２１）内に含有されてもよい。
【０１３２】
図１４では、コードブロックデータ構造１４２１が、２回現れていることに気付かれたい。この重複は、明確にすることを目的として、別個の反復を表すように例示されるが、これは、両方の事例において、正確に同一のデータ構造であることに留意されたい。しかしながら、気付かれ得る差異の１つは、キーリストポインタ１４２１の事例によってポイントされるのはキーリストデータ構造１４２８および１４３８であることである。キーリストポインタ１４２１の値は、この図に示される２つの事例間で変動しないが、キーリストデータ構造１４２８内に含有される（または、それによってポイントされる）値は、２つの反復間で変化してもよく、したがって、この詳細は、データ構造（および、その種々の構成要素）を、それぞれ、１４２６、１４２７、および１４２８から、１４３６、１４３７、および１４３８に再ナンバリングすることによって示される。この構造が再ナンバリングされるという事実は、必ずしも、データ構造の実際の場所が移動したことを示すものではなく、そのコンテンツが変化した可能性があるにすぎない。同様に、また、ハードウェアハッシュ関数１４８０が、本図では、明確性を増大させるという同一理由から、複数化図示される。最後に、２つの候補コードブロック１４１２または１４２２のいずれも、暗号化されておらず、したがって、それらの関連付けられた復号化ポインタ１４１６、１４２６、および１４３６はすべて、空値ポインタであってもよいことに留意されたい。
【０１３３】
本実施形態では、候補コードブロック１４１２に対する読み出しが、開始されてもよい。上述と同一態様において、コードブロックデータ構造１４１１が、メモリ内に読み込まれてもよく、そのメッセージダイジェスト１４４１は、ハッシュ関数１４８０によって算出されてもよい（上述のように、ハードウェア内で全体的または部分的に実現されてもよい）。しかしながら、本実施形態では、ハッシュ関数は、初期シード値１４４０が与えられてもよい（すべてゼロに設定されてもよく、またはそうでなくてもよい）。上述のように、このハッシュ関数シード値特徴は、いくつかの方法の１つを使用して実装されてもよいが、本実施形態では、シード値１４４０は、既知であって、ハッシュ関数ブロック１４８０のメッセージダイジェスト出力１４４１に影響を及ぼす方法は、反復可能かつ決定性である。
【０１３４】
ハッシュ関数の結果１４４１が生成されると、プロセッサは、コードブロック１４１２内に含有されるコードの実行を開始可能となる。図１４に示される実施形態では、復号化ポインタ１４１３ならびにキーリストポインタ１４１４によってポイントされる両場所１４１６および１４１７（キーリストデータ構造１４１８内に含有される）の両方の値がすべて、空値である場合、コードブロック１４１２は、セキュア化実行モードで起動するように設計されなくてもよく、したがって、標的終点ユニットのセキュリティハードウェア特徴のいずれかの使用を必要としない。したがって、プロセッサは、コードブロック１４２２をポイントする埋め込みサブルーチン呼出しに到達するまで、コードブロック１４１２内に含有される命令の実行を開始する。
【０１３５】
その時点で、コードブロックデータ構造１４２１は、メモリ内にロードされ、次のメッセージダイジェスト１４４２を生成するプロセスが、ハッシュ関数ブロック１４８０によって繰り返される。しかしながら、この特定の事例では、ハッシュ関数シード値は、もはや初期シード値１４４０ではなく、以前に生成された結果１４４１であり得る。したがって、メッセージダイジェスト１４４２の値は、コードブロック１４１１および１４２１の両方のメッセージダイジェストに確定的に依存することが分かる。しかしながら、上述の場合のように、復号化ポインタ１４２３の値およびキーリストポインタ１４２４によってポイントされるキーリストデータ構造１４２８内に含有される値は、依然として、空値であってもよく、したがって、プロセッサは、上述のように、非セキュア化実行モードで継続する。
【０１３６】
後に、プロセッサは、別のサブルーチン呼出しに直面するが、本実施例では、コードブロック１４２２は、再帰的呼出し（例えば、それ自体に対するサブルーチン呼出し）を含有する。ある実施形態では、そのような再帰的呼出し構造は、例示にすぎず、標的終点デバイスのセキュリティシステムの正確な動作は、他の手段、例えば、セキュリティシステムに対する任意の呼出しが、コードの単一層内に含有されることを保証する、他の手段によって達成されてもよいことに留意されたい。しかしながら、多重レベルのセキュリティシステムがトラバースされると、再帰的呼出し形式は、上述のように、比較的によりセキュアであって、図示された実施形態と併せて、セキュリティシステムを実装するために、効果的に利用され得る。
【０１３７】
いずれの場合も、プロセッサが、コードブロック１４２２内に埋め込まれたサブルーチン呼出し（それ自体を参照する）に直面すると、コードブロックデータ構造１４２１は、再び、メモリ内にロードされ（例えば、最新システムでは、データ構造１４２１は、フェッチされる２度目は、異なる物理的場所にロードされてもよい）、ハッシュ関数１４８０は、新しいメッセージダイジェスト１４４３を計算する。この新しいメッセージダイジェスト１４４３は、初期メッセージダイジェストシード値１４４０、（コードブロック１４１２の）メッセージダイジェスト１４４１だけではなく、コードブロック１４２２の２つの別個の反復のメッセージダイジェストに依存することに気付かれたい。
【０１３８】
また、この２度目は、キーリストポインタは、非空値デジタル署名値１４３７を含有する、新しいデータ構造１４３８をポイントすることに留意されたい。この非空値は、コードブロック１４２２のこの反復が、標的終点ハードウェア特有のセキュリティシステムへの参照を含有する、セキュリティシステムに対するインジケータである。したがって、本実施形態では、そのような参照が、適切に動作するために、プロセッサは、ある時点において、セキュア化実行モードに入らなければならない。したがって、次いで、コードブロックデータ構造１４２１が、メモリ内に最も新しくロードされた時に生成されたデジタル署名１４４３が、キーリストデータ構造１４３８内に含有されるデジタル署名１４３７と比較されてもよい。ステップ１４９１において、２つの値が、実質的に類似することが分かった場合、標的終点プロセッサは、セキュア化実行モードに入ることが可能となる。しかしながら、２つのデジタル署名値１４３７および１４４３が、整合しない場合（デジタル署名１４３７が、この時点では、非空値であることが分かっていることを前提とする）、ステップ１４９２の結果は、プロセッサに、セキュリティシステムの適切な例外エラーハンドラ部分１４７０を実行させることになる。
【０１３９】
図１５は、デジタル署名発生器ブロック１５６０が、どのように上述の特徴をサポートするために、ハードウェア内に実装され得るかの一実施形態を図示する。図１５に図示される実施形態は、図１０に図示され、例えば、図１１、１２、１３、および１４に関して、動作の詳細において説明された機能特徴をサポートする、デジタル署名発生器ブロックの機能に類似する機能のハードウェア実装を示す。
【０１４０】
ハッシュ関数シードレジスタ１５１０は、図１４のブロック１４４０として標識されたものと類似機能を備えてもよく、ハッシュ関数ブロック１５６１にフィードされる、初期値を保持するように動作可能であってもよい。ハッシュ関数ブロック１５６１の出力は、複合暗号化エンジンの第１の段階１５６２への入力の１つとしてフィードされる。暗号化エンジン１５６２への他の入力は、標的終点デバイスのタイムスタンプレジスタ１５４１の出力である。次いで、第１の段階の暗号化エンジン１５６２の結果として生じる出力は、第２の段階の暗号化エンジン１５６３への入力の１つとして供給される。第２の段階の暗号化エンジン１５６３への他の入力は、セキュア化実行モードアクセスポイント１５６６の出力である。
【０１４１】
アクセスポイント１５６６は、標的終点デバイスが、セキュア化実行モードで起動中であるとき、または図１４に関して上述のように、「再帰終了」条件が検出されるときにのみ、標的終点のハードウェア特有の秘密キー１５４０の値を通過するように動作可能である。次いで、第２の段階の暗号化エンジン１５６３からの結果として生じる出力値は、この生成されたデジタル署名を候補コードブロックとともに供給されるデジタル署名と比較する際に使用するために、デジタル署名レジスタ１５６４内に格納される（例えば、図９、１０、１１、１２、１３、および１４の説明において参照されるように）。
【０１４２】
デジタル署名レジスタ１５６４の出力は、その作用が、標的終点デバイスがセキュア化実行モードで起動中ではないとき、デジタル署名レジスタ１５６４の値を通過させることであるアクセスポイント１５６５によってゲートされる。次いで、アクセスポイント１５６５の出力は、図１４に関する説明において詳述されたカスケード式メッセージダイジェスト特徴を作成するために、ハッシュ関数シードレジスタ１５１０の入力にフィードバックされる。標的終点デバイスが、セキュア化実行モードで起動中の時、ハッシュ関数シードレジスタ１５１０への入力は、デジタル署名レジスタ１５６４の値に依存せず、したがって、ある初期値に（図１４に関する説明において詳述されるように）、またはある他の手段（例えば、特有の記憶場所へのプロセッサ書き込み等）によって、設定可能である。
【０１４３】
上述の明細書では、本発明は、特有の実施形態を参照して説明された。しかしながら、当業者は、記載される本発明の範囲から逸脱することなく、種々の修正および変更が成され得ることを理解するであろう。故に、明細書、付属書、および図面は、限定的意味ではなく、例示としてみなされ、そのような修正はすべて、任意の制限的用語の使用に関わらず、発明の範囲内に含まれることが意図される。
【０１４４】
効果、他の利点、および問題の解決策について、特有の実施形態に関して上述された。しかしながら、任意の効果、利点、または解決策を生じさせるか、あるいはより顕著となり得る、効果、利点、問題の解決策、および任意の構成要素は、請求項の一部または全部の決定的、必要、あるいは必須特徴もしくは構成要素と解釈されるべきではない。
（付属書Ａ）
本発明ならびにその種々の特徴および利点の詳細は、付随の図面に例示され、以下の説明に詳述される、非限定的な実施形態を参照してより完全に説明される。周知の開始材料、処理技術、構成要素、および機器の説明は、本発明を細部において不必要に曖昧にしないように省略される。しかしながら、発明を実施するための形態および特有の実施例は、本発明の好ましい実施形態を示すが、限定としてではなく、例示のみとして与えられることを理解されたい。根底にある発明の概念の精神および／または範囲内における、種々の代用、修正、追加、および／または再配設は、この開示から、当業者には明白となるであろう。
【０１４５】
ここで、デジタルコンテンツを保護するために意図されたセキュリティプロトコルのためのシステムおよび方法に注意が向けられる。これらのセキュリティプロトコルは、任意のデジタルコンテンツのために使用可能であって、また、実際のデジタルコンテンツが改変されることを必要とすることなく、通常、従来の電子透かし方式と関連付けられている、身元追跡の概念をサポート可能である。これらのプロトコルは、全デジタルビットストリームが等しいという前提に基づいているため、プロトコル自体に対するアップデートへのアクセスを制御するために、再帰的方式でも使用可能である。言い換えると、プロトコルは、データが、保護されるべきメディアストリーム、それらのストリームを再生するために必要とされる実行可能コード、それらのストリームを再生するために必要とされる暗号化された実行可能コード、それらのストリームを再生するために必要とされる暗号化されたコードを復号化するために必要とされる実行可能コード、復号化コード等とともに使用されるべきキー等であるかどうかにかかわらず、デジタルデータの種類を区別しない。これらのデータのデジタル性質はすべて、プロトコルに重要なものである。したがって、デジタルデータの性質および／または使用は、セキュリティプロトコルに対して懸念とはならないため、プロトコル自体を保護可能である。
【０１４６】
この能力は、セキュリティプロトコルが実行の間においてさえ、起動中のハードウェアに対する任意の変更を必要とすることなく、アップデート可能であることを意味する（例えば、最近発見されたセキュリティホールを修復するために）。「より古い」セキュリティシステムは、より新しいセキュリティシステムの一部として、「組み込まれる」（すなわち、新しく、潜在的に、よりセキュアなレベルの保護をシステム全体に追加するために、古い保護「ラッパ」を除去する必要はない）。したがって、システム全体が、最新の最もセキュアな暗号化および／またはアクセス制御システム内に封入される。新しいキーが追加され得るだけではなく、同様に、完全に新しいセキュリティおよび／または暗号化アルゴリズムが、既存のシステム上に追加可能である。
【０１４７】
この柔軟性によって、プロトコルは、時間制限レンタル、番組有料視聴、多重バージョニング、機械依存的使用許諾権の取消、およびユーザ間の所有権の永久譲渡を含む、いくつかのビジネルモデルをサポート可能となる。
【０１４８】
著作権のあるソフトウェアアプリケーションが、例示的実施形態において利用されるが、同一方法およびシステムを使用して、テキスト、映像および音声データ、ソース、ならびにオブジェクトコード等を含む何であれ、任意のビットストリームにセキュリティを提供可能であることが、当業者によって理解されるであろう。
【０１４９】
セキュリティプロトコルの実施形態が、提供するように設計される、基本的機能は、以下；
公正使用（「時間シフト」、「空間シフト」、および保存用バックアップ）
増分アップグレード
所有権の一時的譲渡
所有権の永久譲渡
時間制限アクセス
使用制限アクセス（使用回数）
デバイス特有の使用許諾権の取消
データまたはストリーム特有の使用許諾権の取消
を含む（しかしながら、それらに限定されない）。
【０１５０】
多くのセキュリティシステムの場合、著作権のある作品内に含有される知的特性の保護のための一次メカニズムの１つは、単純アクセス制御である。しかしながら、そのようなメカニズムが、そもそも迂回される場合、最も高度なアクセス制御メカニズムによって供与される保護さえ、ほとんど価値がなくなる。これは、アクセス制御が、無益なメカニズムであるというわけではないが、単に、それ自体が総合的セキュリティシステムではないということである。いくつかの著作権のあるメディアストリームが、インターネット上で公開消費のために自由に利用可能であるという事実は、そのようなセキュリティシステムが、ほぼ常に迂回可能であるということの証拠である。また、この種類のアクセス制御は、オリジナルがそもそも破壊される危険性がある場合に必要である、合法的に購入された著作権のある作品のバックアップコピーを作成するためのメカニズムを確立することをより困難にする。したがって、本明細書に説明されるセキュリティプロトコルは、それを有用にするための任意の種類のアクセス制御システムを必要としない。
【０１５１】
説明されるセキュリティプロトコルは、作品自体を成すデジタルデータではなく、著作権のある作品の表現を制御することに焦点を合わせる。したがって、プロトコルは、著作権のある作品を封入するために使用されるデジタルデータ、またはその作品が解釈されるべき方法を記述するために使用される他のデジタルデータを区別しない。その結果、プロトコルは、他のセキュリティプロトコルを封入するためにさえ使用可能である。
【０１５２】
（基本的動作の説明：）
セキュリティプロトコルの実施形態は、ある１本のソフトウェアの著者が、それらのコードが、そのアルゴリズムのコピーまたは別様に不正流用を所望する者による分解から保護されているという十分な信頼性を持てるように設計される。また、本コードが、その機能を改変しようとする者による書換えから保護するように設計される。これらの主要特徴が、その他の点では汎用であるコンピューティングシステム内に実装可能である方法の１つは、以下のセクションで論じられる。これらの２つの主要機能の副産物として生じる付加的特性は、ソフトウェアが起動可能な条件（すなわち、コードを実行可能な時、方法、および機械または複数の機械）を制御する能力である。これらの機能の第１は、改ざん防止タイマ要素をシステムに追加することによって達成されてもよい。その他は、当該コードブロックを実行するために満たされなければならない所望の条件を示すために使用されるセキュアなデータ構造を実装することによって達成される。このデータ構造は、ハードウェア特有ではないので、種々の方法において使用可能であって、それを解釈するために使用されるソフトウェアをアップデートすることによって書換え可能である。プロトコルをより効率的に実装するために利用されるハードウェア特有の特徴について論じられ、これらの特徴が、どのようにプロトコルをサポートするために利用可能であるかの実施例が与えられる。最後に、プロトコルが、どのように使用され、著作権のある作品を保護可能であるかを示す。
【０１５３】
セキュリティプロトコルの実施形態は、その意図された受信者による復号化のみを可能にするためにデジタルビットストリームを暗号化する能力に依存する。これは、良く理解されている問題であって、多数の業界標準暗号化アルゴリズムの基本である。しかしながら、セキュリティプロトコルの実施形態と併用するために、一般的オンチップ命令キャッシュ（Ｉ−キャッシュ）の（比較的に）小範囲内に適合可能な場合に有用であるという事実と、半自律態様で起動可能であるという事実の考慮されるべき２つの付加的要因が存在する。言い換えると、プロトコルが小さく、通常の日々の動作のために、中央セキュリティサーバの使用を必要としない場合、有用である。
【０１５４】
（ハードウェア：）
次に図１を参照すると、このセキュリティプロトコルを実行可能なデバイスの例示的全体のブロック図が示される。セキュリティプロトコルシステムの要素として、プロトコルエンジン（また、「標的ユニット」としても知られる）１００上において、セキュアな態様がプロトコルを実装するハードウェアブロック集合を含んでもよい。これらのブロックは、プロトコルが正確に動作するために、ハードウェア内でキャストされる必要がない。しかしながら、後述のハードウェア要素のすべてを含むデバイスは、最小オーバーヘッドによってプロトコルを実装可能であろう。
【０１５５】
これらのハードウェアブロックの第１は、リアルタイムクロック１０２である。これは、中央サーバとのセキュアな更新によって設定またはリセット可能である、自走タイマである。セキュアな時間標準のクエリを行うことによって時間が確立され得るため、これは、完全に必須のブロックではないが、この機能をオンチップとして有することは、より便宜的となるであろう。これは、時間依存ソフトウェアライセンスと関係があり、そのような実施例は、本書の後のセクションに与えられる。
【０１５６】
別のハードウェア要素は、メモリ１１０のブロックであって、そこでは、実行されるコードが、オンチップとして格納可能である。これは、一般的には、命令キャッシュ（Ｉ−キャッシュ）と知られるが、いくつかの実施形態では、このＩ−キャッシュ１１０の一部の重要な特性は、あるブロック内に含有されるデータが、ＣＰＵ実行ユニット１２０によってのみ可読であることである。言い換えると、Ｉ−キャッシュメモリ１３０のこの特定のブロックは、実行専用であって、任意のソフトウェアによっては、読取りまたは書込みできない。Ｉ−キャッシュのこの特別セクションを「セキュア化コードブロック」１３０と称する。実行されるコードが、このセキュア化Ｉ−キャッシュブロック１３０内に実際に置かれる態様は、別のハードウェア要素によるものであってもよい。
【０１５７】
加えて、セキュアなコードブロックの動作を加速させるために使用可能な可能性のある「拡張」の他のカテゴリが存在する。これらの１つは、ＣＰＵ１２０がセキュアなコードで実行中、アクセスのみ可能である、および／またはセキュアなコードブロックの実行の完了に応じて消去される（すなわち、ある理由から、実行ユニットが、非セキュアなまたは「正常」Ｉ−キャッシュ内に位置する、コードの任意のセクションにジャンプする場合）、ＣＰＵレジスタ１４０の（サブ）集合を指定する能力である。ＣＰＵ１２０が、「セキュア化」コードと「非セキュア化コード」の混合を実行する可能性はないと考えられ得るが、割り込みルーチン内にジャンプする際、コンテキストを切り替えるプロセスにおいて何が生じ得るか、およびＣＰＵ１２０コンテキストが格納される場所（大部分のＣＰＵは、潜在的に、非セキュア化コードブロックによって、後に発見を被る、メインメモリ内にコンテキストを格納する）を、常に考慮しなければならない。
【０１５８】
別の可能性（セキュア化コードブロックの著者が、どのレジスタ１４０が消去されるべきかを明示的に識別することを必要とする以外）は、自動的にそれを行わせることである。これは、ＣＰＵ実行ユニット１２０が、セキュア化コードブロック内で実行中、どのレジスタ１４０が、読み取りまたは書き込まれるかを記録し、次いで、「セキュアな」モードの終了に応じて、それらを自動的に消去することになる。これによって、セキュア化コードは、２種類のコードブロック間で共有が許可されているデータのみをそのままにするために、その後、迅速に「クリーンアップ」可能となる。「自動」プロセスは、潜在的に、「明示」手順よりもセキュアであり得るが、コード著者が、セキュア化と非セキュア化コードブロックとの間で情報を共有することを所望する場合、より複雑となるであろう。
【０１５９】
セキュアと非セキュアなコードセグメントとの間のレジスタ格納データの「漏洩」に対処するための別の潜在的態様は、ＣＰＵ１２０が、セキュア化コードで実行中にのみ使用される一意的集合のレジスタを識別することである。大きい汎用レジスタ集合１４０を有するあるＣＰＵアーキテクチャの場合、これは、一見、非常に高価であると考えられ得る。しかしながら、同一効果は、多くの最新ＣＰＵ設計において実践されている、レジスタリネームおよびスコアボードメカニズムの書き換えられたバージョンを使用することによって、過度の量のオーバーヘッドを必要とすることなく（すなわち、物理的に個別の集合の「セキュアな」レジスタを実装する際に伴う、シリコンオーバーヘッドがなく）、達成可能である。セキュア化コードブロックの実行をアトミックアクション（すなわち、割込み不可能）として処理する場合、これらの問題は、より対処しやくなるが、この便宜性は、性能および潜在的コード全体の複雑性を犠牲にし得る。Ｉ−キャッシュ１３０の「セキュア化」部分は、必ずしも、Ｉ−キャッシュ１５０の「正常」部分として、ＣＰＵに対する異なるデータパスを必要としないことに留意されたい。実際、２つは、完全に同義的であり得る。
【０１６０】
また、一方向ハッシュ関数ブロック１６０も図示されている。ハードウェア内にこの機能を実装する必要なく、セキュリティプロトコルの実施形態を実行可能なエンジンを構築可能である。しかしながら、ハッシュアルゴリズムのある部分のためのハードウェアアクセラレータは、当然ながら、望ましい特徴である。この機能ブロックのハードウェアとソフトウェア実装との間のトレードオフについては、後述される。
【０１６１】
標的ユニット１００の別の部分は、標的ユニット１００の秘密キーおよび公開／個人キー（後述）を使用して、実行可能コードブロックに変換するために、暗号化されたメッセージに作用する、ハードウェア支援復号化システム１７０であってもよい。この復号化システム１７０は、いくつかの方法で実装可能である。プロトコル全体の速度およびセキュリティは、このブロックの構造に依存してもよく、したがって、セキュリティシステムアップデートに対応するために十分柔軟性があるだけではなく、システムが時間クリティカルなメッセージのリアルタイム復号化を行うために十分高速であるべきである。
【０１６２】
それらの２つの制約を考慮すると、正確にどの暗号化アルゴリズムが、このハードウェアブロック１７０のために使用されるかは、プロトコルにとって重要ではない。最大の柔軟性を促進するために、実際のハードウェアは、非アルゴリズム的に特有の態様で使用可能であるために十分汎用性であることが想定されるが、このメカニズムを実装可能な多くの異なる手段が存在する。
【０１６３】
また、点線でブロック図内に示される、オンチップ乱数発生器１８０が存在することに留意されたい。このブロックは、任意である。加えて、次いで、ソフトウェアベースの疑似乱数発生システムのためのシード値を供給するために使用可能な、十分に乱数であるシーケンスを生成する好適なオフチップ方法と置換可能でもある。また、この疑似乱数発生器は、潜在的に、ハードウェアまたは「セキュアな」ソフトウェア内に実装可能である。当然ながら、ソフトウェアベースのシステムの柔軟性とハードウェア実装との間の同一原理トレードオフが、この場合にも当てはまる。しかしながら、標的デバイス１００が、乱数を生成しなければならない場合は、このプロトコルでは、頻繁に発生しないため、この特定の機能が、ハードウェアによって加速されない場合、性能全体に影響を及ぼす可能性は低い。
【０１６４】
（秘密キー：）
各プロトコルエンジン（「標的」ユニット）１００は、オンチップとして格納される、２つの秘密キー定数集合１０４を有してもよい（いずれも、ソフトウェア不可読値）。これらのキーの第１（一次秘密キー）は、実際には、秘密キー集合として編成可能であって、その１つのみ、任意の特定の時間に可読である。ユニットの「所有権」が変更される（例えば、プロトコルエンジンを含有する機械が販売されるか、またはその所有権が別様に譲渡される）場合、現在アクティブな一次秘密キーは、「消去」あるいは異なる値によって上書きされてもよい。この値は、セキュアな方法でユニット譲渡可能であるか、またはこの第１のキーが消去されるときにのみ使用されるような方法で、ユニット内に既に格納されていることが可能である。事実上、これは、その所有権が変更されるときか、またはそのような変更に対するある他の理由が存在する場合（危殆化キー等）、新しい一次秘密キーをその特定のユニットに発行することに相当する。この一次秘密キー値（または、値集合）が格納される唯一の他の場所は、中央サーバ上である。
【０１６５】
一次秘密キーは、中央サーバのデータベース内の特定の標的ユニット１００の通し番号１０６と関連付けられてもよい。通し番号１０６は、標的デバイス１００上のいずれかの場所に格納可能であって、ソフトウェアアクセス可能であってもよく、一次秘密キーと他の関係を有さない。ユニットの動作上の側面に対する任意のアップデート（セキュリティシステムのアップデート等）は、一次秘密キーを使用することによって達成されてもよい。このキーの値が、標的ユニット１００および使用許諾権限者以外の任意の当事者によって既知ではない場合、セキュアな中央サーバを介したリンクを伴わない、任意のセキュアなトランザクションのために使用不可能である。しかしながら、この一次キーのセキュリティは最も重要であるので、絶対的に必要であるときにのみ使用されるべきである。したがって、可能性として、例えば、中央の使用許諾権限者のサーバと標的ユニットとの間のセキュアなトランザクションのための通信リンクを暗号化するためには、使用されるべきではない。このリンクは、現在容認されている標準的実践に従って、高速で生成される、一時的キーを使用する標準的キー交換プロトコルを利用して、セキュア化可能である。
【０１６６】
二次秘密キーは、標的ユニット１００自体にのみ既知であってもよい（したがって、使用許諾権限者には既知ではない）。標的ユニット１００のＣＰＵ１２０は、そもそも、一次または二次秘密キーのいずれの値にもアクセス不可能であるので、ある意味において、標的ユニット１００はその独自の秘密キー１０４さえ「知らない」ことになる。これらのキーは、標的ユニットのＣＰＵ１２０のセキュリティブロック内にのみ、格納および使用される。これらの秘密キーの両方の組み合わせは、標的ユニットのセキュリティ全体を向上させる。その使用方法については、後述される。
【０１６７】
さらに別のキー集合が、一時的公開／個人キーシステム（また、非対称キーシステムまたはＰＫＩシステムとしても知られる）の一部として動作してもよい。この対にあるキーは、高速で生成され、中央サーバの介入を伴わずに、類似ユニット間のセキュアな通信リンクを確立するために使用される。そのようなシステムのセキュリティは、一般的には、同等キー長の対称キー暗号化システムのものより低いため、これらのキーは、上述の秘密キー集合のものよりサイズが大きくなければならない。これらのキーは、特に、「リプレー攻撃」に対して防護するために、オンチップタイマブロック内に存在する値と併用されてもよい。これらのキーは、高速で生成されるため、生成される態様は、ある種類の乱数発生システム１８０に依存する。最後に、生成されたキーが、いわゆる「脆弱」キーの種類に含有されないことを確実にするように配慮しなければならないことに留意されたい。「脆弱」とみなされる、特有のキー集合は、使用される特有の暗号化アルゴリズムに依存する。
【０１６８】
（動作詳細：）
セキュリティプロトコルの実施形態が動作する態様は、システム初期化、セキュアなコード生成および一斉配信、セキュアなコードロードおよび実行、キーリストデータ構造構築、一時的使用許諾権譲渡、永久使用許諾権譲渡、システム所有権譲渡、使用許諾権の取消、およびセキュリティシステムアップデートと、いくつかの離散プロセスに分解可能である。これらは、それぞれ、次に論じられる。しかしながら、後述の実施例は、議論の簡略化を目的として選択され、必ずしも、このプロトコルを実装可能な最も効率的な（または、唯一の）態様であるわけではないことに留意されたい。
【０１６９】
（システム初期化）
これは、標的ユニットの秘密キー１０４が、ある初期値に設定されるステップである。この手順は、いくつかの場所の１つ内で達成可能である（２つの秘密キーのいずれかの場合、論理的理由を別にすれば、通し番号または秘密キーが、可能性として変更され得る、アセンブリプロセス内の最終ステップであるべきである）。ユニット１００の通し番号が、オフチップとして格納される場合、この手順は、最終アセンブリの時点で行われる可能性が高い。ユニットのための通し番号１０６が、オンチップとして格納される場合、任意の生産後またはバーンイン副産物が、非機能部分から選別される機会を有するように、チップ製造プロセスの最終時点で（すなわち、チップがパッケージ化された後に）、この手順を行うことが最も実践的であろう。このようにして、セキュアに維持しなければならないデータの量が最小となる。プロトコル全体のセキュリティは、ユニットの秘密キー１０４のものに基づき得るため、初期化手順は、物理的セキュリティが可能な時点で行われるべきである。
【０１７０】
一次秘密キーは、二次秘密キーを供給するために使用されるものと異なる手順において、初期化される（または、デバイスに「焼き付けられる」）べきである。実際は、この二次キーは、ある時点で既知となるが（製造プロセスの際のある時点において、ユニット内にプログラムされるため）、標的デバイス１００上に格納されると、関連付けられるユニットは、いずれの場所にも記録されるべきではない。監査目的の場合、総二次秘密キー値集合が、どの部分が、どのキーを保持するかを知らずに、検証されることが望ましいであろう（配信の無作為性を試験するため、またはある他の理由のため）。しかしながら、システムのセキュアな性質を維持するために、この第２の秘密キーをユニット内にプロググラムするデバイスが、二次秘密キーを第１の秘密キーまたは標的デバイス通し番号１０６のいずれにも関連付ける任意の手段を有していないことが望ましい。また、これらの秘密キーは両方とも、後述の理由から、改ざん防止態様で実装されるべきである。どの順序で、これらの２つの秘密キーが初期化されるかは重要ではない。例示的実施形態に記載の初期化手順後に、標的デバイスの通し番号１０６およびそれらの関連付けられた一次秘密キーが、共に置かれる唯一の場所（実際のチップ上以外）は、使用許諾権限者のセキュアなサーバ上であるべきである。
【０１７１】
（セキュアなコード生成および一斉配信）
図５を簡単に参照すると、例示的シナリオでは、開発者５２０は、合理的に、分解を受けるおそれがなく、特有のデバイス上でのみ実行可能である、このプロトコル下で起動するためのアプリケーションを生成することを所望すると仮定する。各登録開発者５２０は、使用許諾権限者のサーバと通信するだけではなく、任意の公開コードブロックまたは他のビットストリームを認証するために使用可能な署名されたメッセージ認証コードまたはＭＡＣ（一般的には、デジタル署名と呼ばれる）を作成するために使用する、任意のメッセージを認証するために使用される、公開キー／個人キーの対を有するであろう。
【０１７２】
アプリケーションがデバッグされた後、オリジナル開発者にのみ既知である、アプリケーション特有の暗号化アルゴリズムおよびキーを使用してエンコードされる。本願の特有のアルゴリズムおよびキーは、対称（秘密）キーシステムまたは非対称（ＰＫＩ）キーベースのシステムのいずれかであり得る。コードの暗号化されたブロックの末端に付随するのは、次いで、それらの公開された公開キー／個人キー対（したがって、暗号化されたコードブロックのための一義的デジタル署名を形成する）の個人キーを使用して、開発者５２０によって署名される、ＭＡＣである。デジタル署名またはオリジナルＭＡＣのいずれかおよび対応するコード特有のＩＤ番号は、使用許諾権限者に供給されてもよい。また、アプリケーション開発者５２０は、適切なデコードキーも同様に供給するように選択してもよい（この決定のトレードオフについては、本書の後のセクションに論じる）。
【０１７３】
アプリケーション特有のアルゴリズムが、非対称暗号化システムである場合、必ずしも、署名されたメッセージ認証コード（デジタル署名）を生成するために使用される同一公開ＰＫＩキー対を使用して、暗号化される必要はないことに留意されたい。しかしながら、コードブロックの末端に格納されるＭＡＣは、既知のハッシュアルゴリズムを使用して生成されるべきであって、また、開発者の公開された公開キーの１つを使用して署名されなければならない（したがって、デジタル署名を形成する）。これによって、標的は、既知のハッシュ関数および既知の公開キーを使用して、ＭＡＣの真正性を照合可能となる。
【０１７４】
次に図２を参照すると、全アプリケーション特有の暗号化キーデータ構造２１０は、いくつかの余剰フィールド（復号化キー自体２２０に加え）を含有してもよい。これらのフィールドの１つは、タイムスタンプ２３０および関連付けられたマスク値２４０を備えてもよい。第２は、「カウントダウン値」２５０を含有してもよい。マスク値２４０は、キーが有効である時を決定するために、他の２つのフィールド２３０、２５０と併用されてもよい。また、正確にいくつのビットが、フィールドのそれぞれに分配されるかは、プロトコルに関連しないことに留意されたい。
【０１７５】
タイムスタンプ値２３０は、タイムスタンプマスク２４０フィールド内に格納されるビットパターンに応じて、いくつかの方法で使用可能であることに留意されたい。タイムスタンプマスク２４０値によって、開発者５２０は、標的ユニット１００の現在の時間との比較を行う際に無視される、あるサブ集合のタイムスタンプ値を選択可能である。しかしながら、実施例として、タイムスタンプフィールド２３０によってサポートされる最小分解能が１秒であると仮定する場合、タイムスタンプデータ２３０の下位５ビットからマスクを除去することによって、特定のキーデータ構造２１０は、タイムスタンプフィールド２３０内に格納される時間から開始して、約３２秒にわたって使用されるときにのみ有効であるように生成可能である。セキュリティプロトコルの機能全体は、タイムスタンプフィールド２３０の最下位ビットの実際の分解能に依存しない。
【０１７６】
マスクフィールド２４０と関連付けられる他のビットが存在してもよく、その一部は、タイムスタンプ２３０内に規定される値の前または後に、キーが有効であるかどうかを示すために使用可能である。さらに別のマスクフィールド２４０ビットは、タイムスタンプ２３０および「カウントダウン」値２５０がどのように関連付けられるかを示すために使用可能である。例えば、これは、アプリケーション開発者５２０の意図が、ある日付および時間窓に限定するのではなく、ある日付前または後のいずれかにおいて、ソフトウェアの使用をある反復数に制限することである場合に有用であろう。当然ながら、これらの条件の任意の組み合わせが構築可能であって、したがって、プロトコルは、この点において、非常に柔軟性である。加えて、さらに、フラッグをこのデータ構造に含み、いくつのキーの法的コピーが、オリジナル標的ユニット１００から他に同時に配信されてもよいか等、他の特性を示すことが可能である。これは、例えば、デジタルライブラリに見られるような多重コピー使用許諾権が所望される場合に有用であろう。
【０１７７】
暗号化プロセスの一実施形態を表す工程図が図３に見られる。デジタルメディアストリームまたはソフトウェアアプリケーション（そのメディアストリームを解釈するために使用される、復号化命令等）を配信するために使用されるであろうプロセス間に実質的差異は存在しないことに留意されたい。いずれの場合も、オンラインサーバまたはシリアル番号が付与されたディスク（標準的ＤＶＤ等）のいずれかを介して暗号化されたコードブロック３１０、３２０を配信するために、いくつかの異なる選択肢が存在する。後者の場合、次いで、開発者５２０は、使用許諾権限者５１０によって（または、そうではなく）、大量生産されたディスクの個々の通し番号を事前に登録することを選択可能である。その場合、通し番号は、バーストカッティングエリアへの焼き付け（ＤＶＤの場合）またはインクジェット印刷（標準的ＣＤの場合）によって、ディスクに永久に固定され得る。開発者５２０は、同一通し番号が、大量生産されたディスクのすべてにおいて複製されるため、ＣＤまたはＤＶＤのデータエリアにこれらの通し番号を埋め込むことはできないことに留意されたい。ディスクの一部が大量生産され、別の部分が一度書き込み可能であるある種類のハイブリッドフォーマットが使用される場合、これは、個々の通し番号とともに、ディスクを配信する別の潜在的方法となるであろう。いずれの場合も、登録プロセスの際にエラーを受けにくいので、機械可読の通し番号が当然ながら好ましい。
【０１７８】
開発者５２０が、使用許諾権限者によって、メディア通し番号を登録しないことを選択する場合、適切な暗号化キーをアプリケーションまたはメディアストリームファイルと関連付け可能なある他の態様が存在し得る。したがって、アプリケーション開発者５２０は、コード特有のＩＤまたは関連付けられたメディア通し番号のいずれかを登録してもよい。前者の場合、アプリケーションは、自由に配信可能である（すなわち、特有のリリースフォーマットおよびメディアに限定されない）。
【０１７９】
個々の通し番号メカニズムの場合、使用許諾権限者５１０は、どのアプリケーション（または、メディアストリーム）が、どの通し番号と関連付けられているかを知る必要（潜在的に、その意図）がないため、エンドユーザのプライバシーは、維持される。開発者５２０が、アプリケーションＩＤ（または、メディアストリームＩＤ）とともに、その関連付けられたキーを登録する場合、使用許諾権限者５１０は、どのアプリケーションまたはメディアストリームが、特定のエンドユーザによって「所有」されているかを知ることが可能である。一方、この潜在的プライバシーの欠如は、開発者５２０が物理的メディアを製造および配信することを必要としないという、付加的便宜性および費用の節約によって相殺される。用語「物理的メディア」は、必ずしも、ディスクを意味するものではないことに留意されたい。この機能は、それに貼付された個々の通し番号ステッカーとともに、印刷されたマニュアル（またはさらに単純登録形式）を使用することによって、同様に達成され得る。必要とされるものは、開発者５２０が、エンドユーザに供給される一意的な通し番号とともに、あるオブジェクトを生産しなければならないことだけである。この通し番号の目的は、ビットストリーム登録番号として作用することである。この通し番号が、どのようにプロトコル内で使用されるかについては、以下のセクションで論じられる。
【０１８０】
図３に示される実施例の場合、暗号化されたソフトウェアアプリケーション（または、メディアストリーム）３１０および機械依存性復号化ソフトウェア３３０は両方とも、同一メカニズムを使用して配信される。これが該当し、暗号化されたコードブロック３１０、３３０の一方または両方が、オンラインあるいはディスクをプレスすることによって配信可能であることは、プロトコルの要件ではない。しかしながら、デジタルメディアストリームの場合、メディアストリーム自体が、２つのブロック３１０、３３０より数倍大きい可能性が高いことに留意されたい。したがって、その場合、大量生産されたディスクフォーマットとして、少なくとも本ブロックの配信をもたらすことが、最も有用である。多くの場合、そのようなディスク上には、随伴暗号化コードブロック（その１つは、第１のブロックをデコードする方法の命令を含有する）だけではなく、一次暗号化コードブロックに適合する、十分な余地が存在し得る。また、２つのデータ集合のいずれも、公開後、任意の変化を受ける可能性がなく、したがって、オンラインで配信されなければならないという基礎的要件が存在しないことに留意されたい。したがって、両方とも、大量生産されたディスクベースの配信メカニズムに好適である。また、同一ディスク上に両方を有することは、一義的方式において、一方を他方と関連付けることをより容易にする。
【０１８１】
（セキュアなコードロードおよび実行）
配信メカニズムが、実際のディスクを介して達成される場合、消費者は、従来のソフトウェア購入と正確に同一態様において、アプリケーションを含有するディスクを購入可能である。当然ながら、エンドユーザは、「標的」ユニットのプロセッサ上で書き換えられていない暗号化されたコードブロックを起動することは不可能であろう。ユーザが、それらの機械上でアプリケーションを起動しようとすると、ＣＰＵ１２０は、暗号化されたソフトウェアブロックをロードし、コードブロックの末端に格納されたデジタル署名（「署名された」ＭＡＣ）とともに、ソフトウェア開発者の公開キーを使用して、当該コードブロックが本物であることを照合する。ここで、その他の点では汎用であるＣＰＵ１２０への最初のハードウェア書換えが、作用し始め得る。セキュア化コードのそのようなブロックをロードおよび復号化するためのプロセスは、図４に示される。
【０１８２】
ハッシュ関数が正確に算出される（さらに、生成されたメッセージダイジェストと「実」メッセージダイジェストとの間の比較が有効である）ことを確実にするために、ＣＰＵ１２０は、セキュアな態様において、このハッシュ関数を行わなければならない。したがって、ハッシュ関数は、デコーダユニットのハードウェアによって、直接生成されるか、またはハッシュ関数自体が、「セキュアな」コードのブロックを使用して算出されなければならず、その動作は、その他の点では「非セキュアな」プログラムによって改ざん不可能である。
【０１８３】
ソフトウェアベースのハッシュの場合、セキュアなコードのこのブロックは、ユニット１００のセキュリティシステムの一部としてみなされるべきであって、したがって、ユニット１００と使用許諾権限者５１０とのセキュアなトランザクションを介して、プレーヤに対して、ダウンロードのみ可能であってもよいことに留意された。大変興味深いことに、「セキュアな」ハッシュ関数の確立は、本明細書に説明される同一のセキュアなプロトコルを介して達成可能である。セキュリティシステムのあらゆる側面に対するこの再帰的挙動は、その暗号化／復号化アーキテクチャにおいて、このプロトコルのソフトウェアベースのバージョンを非常に柔軟性のあるものにするものである（したがって、アップデート可能）。
【０１８４】
メッセージダイジェスト計算が、ハードウェア内に固定される場合、潜在的に、ある程度のセキュリティを得ることが可能であるが、これは、柔軟性を犠牲にする。専用ハードウェアブロックが、ハッシュ値を生成するために使用され、次いで、チップが製造された後、ハッシュアルゴリズムにおけるある脆弱性が、ある時点で発見される場合（または、その実装内にあるバグが存在する場合）、事後に問題を解決する機会は存在しない。これは、プロセスを加速するために、ソフトウェアベースのハッシュ関数（プログラム可能Ｓ−Ｂｏｘ構造等）のある種類のハードウェア加速の使用が不可能であるというわけではない。しかしながら、その場合、ハードウェアは、理想的には、多種の一方向ハッシュ関数をサポートするために十分に汎用性であるべきである。
【０１８５】
しかしながら、このプロトコルのセキュリティは、最終的には、このセキュアなコードロード手順の一部として提供される最下位機能に依存することに留意されたい。下位特徴（ハッシュ関数において使用される秘密キーまたは初期動作等）は、異なる方法で組み合わせられ、署名されたメッセージダイジェスト等のより高位の機能をもたらす。次に、これらの高位機能ブロックは、身元照合等のさらに高位の可用性を提供するために使用される。より多くの初期層の上部に、より高位の機能を構築するこのプロセスは、「信頼の連鎖」の構築として知られている。システムの柔軟性は、セキュリティ関連機能が、この階層内の可能な限り低位の書換え可能な時点に置くことにかかっている。しかしながら、ある時点において、この連鎖が基づく基礎的な初期動作は、性質上アトミックでなければならない（すなわち、これは、ハードウェア内に実装されなければならない最小レベルの機能である）。ハードウェア粒度のこの時点の正確な選択は、大部分は、実装上の詳細であって、このプロトコルの動作全体は、上述の条件を考慮して、この側面に依存しない。
【０１８６】
暗号化されたコードブロック３１０が、標的のメモリ空間１１０内にロードされ、メッセージダイジェストが計算されると、次いで、結果が、開発者の公開キーによって暗号化されたコード３１０とともに格納されたデジタル署名３４０を復号化することによって計算される、メッセージダイジェストと比較される。２つが整合する場合、標的ユニット１００は、暗号化されたコードブロック３１０が本物である（または、少なくとも、コードが、その公開キーがデジタル署名を復号化するために使用された開発者５２０によって配信された）ことが確実であり得る。
【０１８７】
この時点では、標的１００は、次いで、新しく照合された暗号化コードブロックと併用される復号化キーのコピーを要求する、セキュアなメッセージを使用許諾権限者５１０に送信する。使用許諾権限者とのセキュアな接続を設定する一部として、標的ユニット１００は、一時的公開／個人キー対を生成する（その公開部分は、使用許諾権限者５１０のサーバに供給される）。キー交換手順の詳細は周知であって、この議論では、これが達成される正確なメカニズムについて詳述する必要はない。いずれの場合も、標的ユニット１００と使用許諾権限者５１０の中央サーバとの間のネットワークトラフィック全体が、数回のキー譲渡、コード特有のＩＤ、およびそれとともに格納されるＭＡＣから成るので、合理的に小データ集合に制限されることに留意されたい。
【０１８８】
コード特有のＩＤ２６０が、使用許諾権限者５１０が認識するものであると仮定すると、アプリケーション著者が、使用許諾権限者５１０に、要求された復号化キーの「純正」コピーを既に提供しているかどうかに応じて、２つの可能性のある一連の作用が存在し得る。開発者５２０が、使用許諾権限者５１０に、そのような情報を提供していない場合、中央サーバは、標的デバイスの一時的公開キーのコピー（同様に、当該コード特有のＩＤ２６０）をアプリケーション開発者のサーバに伝送する。この時点で、開発者のサーバは、要求された復号化キー（標的の一時的公開キーによって暗号化されている）および適切に復号化されたコードから生成されたメッセージダイジェストを含有するメッセージによって、使用許諾権限者５１０サーバに応答する。このように、標的デバイス１００のみ、メッセージを復号化し、アプリケーション特有の復号化キーを得ることが可能であって、使用許諾権限者５１０は、そもそも、純正形式にある復号化キーへのアクセスを有していない。
【０１８９】
メッセージダイジェストは、事前に算出され、使用許諾権限者のサーバに格納可能であるが、トランザクションの際に、開発者５２０によって提供され得るという事実は、ハッシュ関数（メッセージダイジェストを生成するために使用される）が、そもそも、変更するはずである場合、潜在的に有用である。これが生じる場合、開発者５２０は、標的デバイス１００との実際のトランザクションに先立って、またはその間に、アップデートされたバージョンの復号化されたコードメッセージダイジェストを使用許諾権限者５１０に提供する必要であろう。使用許諾権限者５１０は、オリジナル（復号化された）コードへのアクセスを有するべきではないため、開発者５２０は、この情報を提供しなければならない。上述のように、使用許諾権限者のサーバと開発者のサーバとの間のネットワークトラフィックの量は、依然として、非常に小さい。次いで、開発者５２０から受信された暗号化されたキーは、使用許諾権限者５１０から標的への伝送に先立って、標的デバイスの一次秘密キーによって、再び、さらに暗号化される。この第２の暗号化は、実際には、他のトランザクションの一部として、開発者側で行われ得るが、その場合、開発者は、潜在的に、エンドユーザの潜在的プライバシー問題の損失をもたらす、標的ユニットの一次キーへのアクセスを有するであろう（両方のキーが、何らかの形で組み合わされていない限り）。
【０１９０】
アプリケーション開発者５２０が、使用許諾権限者５１０と標的デバイス１００との間のトランザクションに対して、「ループ外」に留まることを所望する場合、単に、使用許諾権限者５１０に、純正（非暗号化）形式にある関連復号化キーのコピーおよび復号化されたコードブロックのための関連付けられたＭＡＣ（その値は、ハッシュアルゴリズムが変更される度に、アップデートされなければならない）を提供することが可能であることに留意されたい。したがって、使用許諾権限者５１０の中央サーバは、自律的に作用可能であって、標的ユニット１００からのキー要求を充足するために、開発者のサーバとの通信リンクを確立する必要はないであろう。しかしながら、これは、この「純正キー」情報が、そもそも、使用許諾権限者によって、意図的または非意図的に、危殆化される場合、潜在的セキュリティの危険性を開発者にもたらす。
【０１９１】
キー暗号化／復号化プロセス全体の工程図が、図５に概略される。この場合、純正キーは、依然として、伝送（上述のように）に先立って、標的デバイスの一時的公開キーと、次いで、再び、標的の一次秘密キーの両方によって、暗号化されるであろう。この時点で、標的デバイス１００は、二重に暗号化されたフォーマットにおける適切な復号化キーを有する。使用許諾権限者５１０が、暗号化されていない状態のアプリケーション特有のキー５５０情報へのアクセスを有していない場合、各ユニット１００のための秘密キーは、使用許諾権限者５１０にのみ既知であって、伝送のための個人キーが、標的１００によってのみ知られているため、意図された標的デバイス１００以外の任意の者が、純正形式におけるこのキーデータを複製することが可能となることは不可能であるはずである。
【０１９２】
しかしながら、この時点では、標的１００がアプリケーション開発者５２０から受信する、エンコードされた復号化キーは、未だ、標的１００において、公に安全に格納不可能である（例えば、フラッシュＲＯＭ内またはハードドライブ上のバックアップ）。問題は、標的デバイス１００が、また、使用許諾権限者５１０から伝送された、エンコードされた復号化キーとともに、一時的個人キーのコピーを格納する必要があることである。次いで、使用許諾権限者５１０の任意の者が、ある手段によって、これらの２つのデータへのアクセスを得ることになる場合、潜在的に、復号化されたアプリケーション特有のキー５５０を再構築可能となるであろう（標的デバイス１００の一次秘密キーへのアクセスも同様に有すると仮定して）。
【０１９３】
ここで、標的デバイスの二次秘密キーが使用されるようになる。この二次秘密キーは、標的ユニットの復号化ユニット以外のいずれの者にも未知であることを思い起こされたい。したがって、標的１００に使用許諾権限者から供給されたキーを復号化するために、一時的個人キーが使用されると、二次秘密キーは、その使用（および／またはアーカイブ）に先立って、アプリケーション特有のキーを再暗号化するために使用される。
【０１９４】
次いで、標的は、コードブロック（または、メディアストリーム）を復号化するために、アプリケーション特有の（純正）キー５５０を使用可能となる。したがって、アプリケーションコードが純正形式において存在する、唯一の２つの場所は、オリジナル開発者５２０自体と、標的デバイスのＩ−キャッシュ１１０の「セキュア化」部分内（実行のみ可能であって、純正形式におけるメモリへの書き込みは不可能である）である。これは、ユーザと使用許諾権限者５１０との間のプライバシーを可能にする。言い換えると、使用許諾権限者５１０は、ユーザが使用許諾権を有するのは何なのか（計り知れないプライバシー上の利点）を知る必要はないが、依然として、そのユニット１００が損傷を受けるか、または盗まれるか、あるいは別様に動作不可能にされる場合のユーザのキーリストのためのリポジトリ（または、バックアップ）として作用可能である。
【０１９５】
復号化プロセスが正確に行われたかを検証するための確認として、次いで、適切に復号化されたコードのメッセージダイジェストが、オリジナル開発者５２０から、使用許諾権限者５１０を介して標的ユニット１００に転送されたデジタル署名を復号化することによって生成されたメッセージダイジェストと比較される。上述のように、このデジタル署名は、非暗号化コードブロックのメッセージダイジェストをアプリケーション開発者の個人キーによって暗号化することによって作成される。代替として、また、このデジタル署名は、開発者５２０によって、接続が確立された時、使用許諾権限者５１０に供給された、別の一時的公開キー５３０を使用して、再び、暗号化可能である。いずれの場合も、次いで、正確なメッセージダイジェストは、開発者の公開キーによって、デジタル署名を復号化することによって、標的デバイス１００によってデコード可能である。このメッセージダイジェストが、復号化されたコードブロックのＭＡＣと整合する場合、コードは、本物であるとみなされ、標的１００上で実行可能となる。次いで、このメッセージダイジェストは、再暗号化されたアプリケーション特有のキー５５０とともにアーカイブのために、標的ユニットの二次キー５４０によって、再暗号化されてもよい。
【０１９６】
この手順における最終ステップは、新しく暗号化された（標的デバイスの二次キー５４０によって）バージョンのアプリケーション特有のキー５６０が、アーカイブ目的のために、使用許諾権限者５１０サーバに再伝送されることである。この伝送は、いくつかの目的を果たす。第１に、標的デバイス１００が、コードブロックを適切に復号化可能であったことの確認応答である。第２に、エンドユーザが、ある種類の壊滅的データ故障を被り、それらのアクセスキーの独自のバックアップコピーの作成を怠った場合に対処するために、使用許諾権限者５１０は、この暗号化されたキー５６０のコピーを有することが必要とである。次いで、使用許諾権限者５１０は、任意の特定のユーザのためのバックアップ記憶施設として作用可能である。この手順のさらに別の理由は、特定の標的デバイス１００が、あるユーザから別のユーザに所有権を変更する場合、またはユーザが、それらの標的デバイス１００のアップグレードを所望する場合に対処するためにある。この種類の所有権の永久譲渡は、そのユニット１００のための使用許諾のあるアプリケーションキーのすべての譲渡を伴い得る（その場合、新しい所有者の名前下のユニットを再登録する以外行う必要はない）。しかしながら、ユーザが、第１から第２のデバイスへのそれらのキーデータの永久所有権の譲渡を所望する場合、これは、使用許諾権限者５１０と両方の標的デバイスとの間のセキュアなトランザクションによって達成されてもよい。
【０１９７】
標的デバイス１００が、使用許諾権限者５１０のサーバに返送する他の情報は、標的デバイスの新しくアップデートされたキーリストデータ構造６１０のメッセージダイジェストである（図６に図示されるように）。これは、新しくアップデートされたキーリストデータ６１０構造の確認応答でもあり、また、使用許諾権限者５１０のサーバおよび標的デバイス１００上のその特定の標的デバイス１００と関連付けられたキーリストデータ構造６１０の等価性を検証するためにも使用される。このデータ構造の正確な構造については、以下のセクションで後述される。また、後のセクションにおいて、特定のキーまたはキー集合の所有権の永久譲渡が達成される方法についても論じる。
【０１９８】
この時点では、上述のプロセスが、プロトコルが、開発者５２０から標的デバイス１００に、アプリケーション特有のキー５５０を譲渡するために使用可能な唯一の態様ではないことに留意されたい。例えば、実際のキー譲渡トランザクションは、標的１００とアプリケーション開発者５２０との間のみの直接接続を伴うことが可能である。しかしながら、その場合、接続は、デバイス特有の暗号化情報をトランザクションに寄与するために、開発者のサーバと使用許諾権限者のサーバとの間で確立されなければならない。このプロトコルがセキュアな態様で作用可能ないくつかのメカニズムが存在するが、上述の実施例は、これらの１つにすぎない。しかしながら、共通の特徴は、標的１００に譲渡されるキーデータが、その標的デバイス１００のためにのみ使用可能であることを保証するために、３当事者すべてが、ともに作用しなければならないことである。
【０１９９】
キーの構造は、ハードウェア特有の部分だけではなく、アプリケーション特有の部分の２つの部分を有するように設定可能であることに留意されたい。これらの２つの部分が、完全に非分離であることは要件ではない。非分離である場合、上述のように、その特性を正確に得る。しかしながら、キー部分を独立して動作可能にする方法が存在する場合、グローバルコピー集合を有効化し、実際のコードまたは実際の標的デバイス１００から独立し得る、制約を使用可能である。言い換えると、任意の開発者５２０は、配信に関する制約を有さないが、読取不可能であって、実行のみ可能なアプリケーションまたはメディアストリームを公開し得る。これは、使用許諾権限者５１０が、製造業者にかかわらず、あらゆるデバイス上で起動するであろう、セキュリティシステムアップデートの送信を所望する場合、有用となり得る。これの別の実施例は、公的に利用可能である一方、依然として、そのストリームに対する著作権の制御を維持するメディアストリームのブロードキャストであろう。同様に、公開者は、任意の者が、読取および／またはコピー可能であるが、１つの特有の標的デバイス１００またはデバイス集合上でのみ実行する、アプリケーションを配信し得る。これは、例えば、「この特有の種類のデバイスのアップデート」メッセージを送信するために有用であり得る。別の可能性のある用途は、どこでも起動され、配信に関する制約を有さない、アプリケーションを送信することである。これは、特定のアプリケーションのためのソースコードの公開に性質上類似するであろう（すなわち、オープンソース配信）。分離可能Ｈ／Ｗ特有のおよびＳ／Ｗ特有のキー構造によって有効化される、異なる種類のセキュリティは、表１に例示される。
【０２００】
【表１】
0005636371.tif 000002
（キーリストデータ構造構築）
次に図６を参照すると、特定の標的デバイス１００に使用許諾されているアプリケーションまたはメディア特有のキーのリストを含有するデータ構造６１０は、有益な利点であって、したがって、所有者によってバックアップ可能であるべきである。個々のキーは、標的の二次秘密キーによって暗号化されているため（上述のように）、リストは、キーが使用許諾されているユニットに対してのみ有用である。しかしながら、このデータ構造６１０が、改ざん、破損、および／または完全な損失に対してセキュアであることが、確証可能である必要がある。キーリストデータ構造が損失される場合、データ構造６１０全体が、上述のように、使用許諾権限者５１０から、その特定の標的デバイス１００のためのキーリストの新しいコピーを要求することによって復元可能である。一時的変化がキーリストデータ構造に成される場合（そのようなシナリオの理由については、以下のセクションにおいて論じる）、プロトコルは、そのような変化を一時的として識別するための手段を講じてもよい。最後に、キーリストデータ構造６１０の真正性、適時性、および有効性を検証するためのある改ざん防止メカニズムを含む。
【０２０１】
これらの要件を考慮して、図６に示されるような態様において、これらの品質すべてを呈するセキュアなキーリストデータ構造６１０を構築可能である。これまでのように、示される実施例は、所望の特性すべてがそのようなデータ構造内に含まれ得る唯一の方法ではない。しかしながら、図６に例示される特定のデータ構造は、実際、プロトコルの基本的要件のすべてを充足するものである。
【０２０２】
上述の概略図において留意されるべきいくつかの基本的指針が存在する。第１は、キーリストデータ構造６１０の上位暗号化が、標的デバイスの一次秘密キーによって行われなければならないことである。この特定のキーを使用するためのいくつかの理由が存在するが、主要な問題は、このデータ構造のローカルコピーが復元されなければならない場合、使用許諾権限者５１０が、標的デバイス１００から独立して、このデータ構造の暗号化された形式を再生成可能でなければならないことである。任意の他のキーが、このデータ構造（例えば、標的の二次秘密キー等）を暗号化するために使用される場合、標的が、データ構造に変更を行う必要があると（キーがリストに追加される場合のように）、リスト全体が、バックアップ目的のために、使用許諾権限者５１０に譲渡されなければならない。これは、潜在的に、使用許諾権限者５１０に返送されなければならない、ネットワークトラフィックの量を大幅に増加させ得、必ずしも、チャネル帯域幅の最も効率的使用ではない。
【０２０３】
また、このキーリストデータ構造６１０は、標準的アプリケーションまたはメディアストリーム特有の使用許諾キーの記憶のために使用されるのに加え、セキュリティシステム関連キーの記憶のために使用されることが望ましい。このデータ構造は、使用許諾権限者５１０によって再生成可能であるため、標的デバイス１００上で起動する、セキュリティソフトウェアをアップデートすることが望ましい場合には、同一キーリストデータ構造６１０が、両機能のために使用され得る場合、よりセキュアかつより効率的となるであろう（標的デバイス１００上のコード記憶要件の観点から）。
【０２０４】
第２の問題は、暗号化されたバージョンのキーリストデータ構造６１０が、オリジナルキーリストデータ構造６１０のメッセージダイジェストを含むことである。個々のキーそれぞれが、暗号化されるが、リスト自体の他の部分は、メッセージダイジェストが計算される時に別個に暗号化されないことに留意されたい。メッセージダイジェスト計算後、キーリストデータ構造６１０全体（メッセージダイジェストを含む）は、次いで、上位（または、マスタ）キーによって識別される、キー値およびアルゴリズムによって暗号化される。これは、悪質な第三者が、リストを改ざんし、新しいメッセージダイジェストを計算し、次いで、書き換えられたリストを本物の代わりに代用することを防止ために行われる。キーリストデータ構造６１０が、標的ユニット１００のメモリ空間内に読み込まれると、この（復号化された）メッセージダイジェストは、ＭＡＣが、任意の他のセキュアな暗号化されたコードブロックのために使用される方法と同一態様において、キーリスト自体の真正性および有効性を検証するために使用される。個々のキー以外の要素はすべて、マスタキーによってのみ暗号化されるという事実は、上位キー以外の任意のキーへのアクセスを有する必要なく、リストがトラバース（さらに、リストが維持）可能であることを意味する。また、キーリスト一覧は、復号化ブロックを通る唯一の単一パスとともにコンパイル可能である。
【０２０５】
着目される第３の原理は、個々のアプリケーションコードまたはメディアストリーム特有のキーが、各標的デバイス１００のための個別のキーに対応するために十分大容量に作成され得ることである。コードまたはメディアストリームが、大量生産されたディスクを介して配信される場合、これは、アプリケーション開発者５２０が、新しいコード特有のＩＤとともに、個々の復号化キーを発行する必要があることを意味するであろう。これは、使用許諾プロセスに関与する当事者すべて間で譲渡されなければならないデータ量を最小に使用とする観点から、あまり効率的であり得ないが、危殆化復号化キーを追跡する能力を含め（しかしながら、これに限定されない）、プロトコルに機能を追加することになる。また、これについても、キー取消の対処に関する後のセクションにおいて論じられる。
【０２０６】
留意すべき次の問題は、キーリストデータ構造６１０ヘッダが、リストの残りを編成する、アプリケーション特有のキーと同一特徴集合を共有することである。実際、ヘッダは、キーリストデータ構造６１０自体の残りのためのマスタキー６２０と考えられ得る。したがって、このキーが、どのようにリストの残りの管理を決定するために使用可能であるかに関する限り、同一動作原理が適用され得る。これは、標的デバイス１００のセキュリティシステムの時間依存性管理を含む。したがって、標的ユニット１００は、事前に決定された間隔において、そのセキュリティシステムをアップデートするよう強制され得、これは、それ自体、非常に強力な概念である。
【０２０７】
また、キーリストが、それぞれ、その独自のマスタキー６２０（リストヘッダ）と、したがって、その独自の独立暗号化メカニズムを伴う、いくつかのセクションを含有し得る可能性が存在する。任意の他のキーと同様に、リストヘッダは、キーリストデータ構造６１０を解釈するために使用される、暗号化されたコードブロックをポイント可能なコード特有のＩＤフィールド２６０を含有する。次いで、リスト全体が、その独自のマスタキー（さらに別のリストヘッダである）を含む、さらに別のマスタリスト内に含有され得る。したがって、キーリストデータ構造６１０全体を再帰的に画定可能である。上述のように、この再帰的特性は、新しいキーリストデータ構造を作成し、同一データ構造の以前のバージョンの欠点を解決することによって、セキュリティシステムをアップデートするために使用可能である。リスト全体のセキュリティは、「最外」（または、最も新しい）セキュリティ層内に含有されるため、キーリストデータ構造６１０全体のセキュリティは、常に、セキュリティソフトウェアの最新の反復に基づく。
【０２０８】
したがって、キーリストデータ構造６１０の再帰的特性は、有力な特徴である。また、上述のセクションにおいて論じられたデータ構造のまさにその実装が、それほど重要ではない理由でもある。上述の説明は、単に、プロトコルの再帰的性質を作用させるために必要とされる機能の最小サブ集合である特徴が含まれる、実施例である。
【０２０９】
どのように構築されるかに関わらず、キーリスト６１０は、いくつかの共通環境下、維持および／またはアップデートされてもよい。これらの環境として、リスト内に含有されるキーの１つ以上の状態が書き換えられる場合を含む（しかしながら、それらに限定されない）特定のキー２１０の所有権が、あるユニットから別のユニットに譲渡され得る、いくつかの基本的メカニズムが存在するが、これらについては、後のセクションで論じられる。しかしながら、いずれの場合も、改訂されたキーリストが維持されるメカニズムは、使用許諾権限者５１０の介入を必要とするものと、独立して実行可能であるものの、２つの種類に分割可能である。
【０２１０】
このプロトコルが基づく、主要動作概念の１つは、使用許諾権限者５１０の中央サーバと個々の標的ユニットとの間の必要とされるネットワークトラフィックの量を最小に低減させることである。したがって、キーリストデータ構造６１０への任意の一時的変更（その理由については、後述される）は、標的ユニット１００によって、独立して維持可能であるべきである。これに対する主要理由は、これらの変更が、表面上は、デバイスのセキュリティシステムへの永久変更（標的デバイス１００と使用許諾権限者５１０との間の交信によってのみ、常に、達成されるべきである）より頻繁に、生じるであろうことである。
【０２１１】
いずれの場合も、標的デバイス１００が、一義的態様においてマスタキーリストデータ構造の現在の状態を記録可能なあるメカニズムが存在しなければならない。これは、２つの「マスタ」リストを有することによって達成可能である。これらの２つのリストの第１（永久キーリストと称する）は、使用許諾権限者５１０によって維持される。このリストは、当該標的ユニット１００と関連付けられる、アプリケーション特有のキーの「永久」所有権に関係している。第２のリストは、同様に重要であるが、「永久」キーリストデータ構造への一時的書換えに関係しているものである。これらの書換えは、リストへの追加またはリストからの削除のいずれかであり得ることに留意されたい。２つのリスト自体のデータ構造の実装に必要な差異は存在しない。主要な差異は、それらがどのように維持されるかに関して生じる。これらのリストの一方または両方のデータが損失する場合から、標的ユニット１００が回復するためのある方法が存在することが望ましい。この損失は、ある壊滅的故障により得る、またはリストの１つ内に含有される情報が、何らかの形で破損した場合により得る（無意識または故意に）。そのような「キーリスト破損」事象の関連事項については、後のセクションで論じられる。永久リストが、使用許諾権限者との接続によって復元可能であることは必要であるが、使用許諾権限者５１０が、特定の標的デバイスの一時的キーリストを復元可能であることは必要ではない（または、望ましくさえない）。この点に関して、多くの理由が存在するが、主要理由は、一時的キーリストが、永久キーリストより遥かに頻繁にアップデートされる可能性が高いことであって、中央使用許諾権限者５１０と標的ユニットとの間で必要とされるネットワークトラフィックの量を絶対最小値に維持することが所望される。しかしながら、潜在的に、いくつかの理由から、使用許諾権限者５１０が、特定の標的の一時的キーリストに書換えを行うことが可能であることが望ましい場合がある（その一部は、後に論じられる）。この場合、標的デバイスの一次秘密キー（使用許諾権限者５１０に既知である）を使用して、このリストを暗号化することが望ましいであろう。
【０２１２】
上述のように、キーリストデータ構造の両方の完全性は、リスト自体とともに格納される、署名されたメッセージダイジェスト（デジタル署名）を使用することによって照合可能である。このメッセージダイジェストを生成するために使用される、セキュアなコードメカニズムの実装については、上述のセクションで説明されており、再び、その手順に言及する必要はない。また、損失および／または破損の場合に、永久キーリストデータ構造６１０を復元するための手順についても、既に説明されている。解決しなければならない唯一の残っている問題は、一時的キーリストデータ構造の時間依存性部分を、どのように解釈するかということと、一時的キーリストが、何らかの形で使用不可になる場合にどのように対処するかということである。
【０２１３】
（一時的使用許諾権譲渡）
これは、タイムスタンプフィールド２３０の使用が、最も重要である、セキュリティプロトコルのセクションの１つである。上述のように、一時的キーリストデータ構造は、標的デバイスの永久キーリストと正確に同一態様で構築される。しかしながら、２つには、いくつかの差異が存在する。第１の差異は、一時的キーリストが、潜在的に、標的ユニットの秘密キー１０４のいずれか１つによって暗号化可能なことである。使用許諾権限者５１０は、通常環境下、このデータ構造を再構築可能である必要はないため、表面上は、どの標的ユニットのキーが、それを暗号化するために使用されるかは関係ない。しかしながら、潜在的に、このリストが、また、標的ユニットの一次秘密キーを使用して暗号化される場合は、使用許諾権限者５１０に有用となるであろう。これに対する理由は、使用許諾権の取消と関係があり、その環境については、後のセクションで論じられる。
【０２１４】
一時的と永久キーリストとの間の第２の（かつ、より重要な）区別は、最も新しい一時的キーリストデータ構造と関連付けられる、タイムスタンプ値２３０のコピーもまた、標的デバイス１００内に格納されることである（すなわち、オンチップ）。このレジスタは、ソフトウェア可読ではなく、セキュリティブロックの一部であるため、セキュアなコードによってのみ上書き可能である。このレジスタ内の値は、一時的キーリストデータ構造が、何らかの形で損失および／またはは損される場合にどうすべきかを決定するために使用される。その手順については、このセクションに後述される。
【０２１５】
一時的キーリストと永久キーリストとの間のさらに別の区別は、標的ユニット１００が、その永久リストから別のユニット１００の一時的リストに、特定のキーの所有権を（一時的に）譲渡可能であるが、いかなる（正確に動作する）デバイスも、その一時的キーリストから任意の他のキーリストに、特定のキーの所有権を譲渡不可能であることである。これはは、当然ながら、他のユニットの一時的キーリストだけではなく、また、標的１００の独自の永久キーリストも同様に含む。これは、永久所有者のみ、どのデバイスが、任意の特定のキーを「貸出」可能であるか（かつ、いつ可能であるか）を決定可能であることを意味する。しかしながら、この「貸与」期間は、不定にすることが可能である（かつ、このトランザクションは、使用許諾権限者と接触する必要なく実行可能である）ことに留意されたい。この「永久貸与」特徴は、最新のデジタル著作権管理情報（ＣＣＩ）システムの一部である、標準的「一世代コピー可（Ｃｏｐｙ  Ｏｎｃｅ）」機能要件に匹敵する。
【０２１６】
次に、図７を参照すると、一時的「キー借用」手順を図示する、詳細な工程図が示される。「キー所有権」譲渡手順は、図書館から１冊の書籍を借りる手順に若干類似する。「借り手７２０」が、永久所有者（「貸し手」７１０）からの特定のアプリケーション特有のキー５５０の一時的使用を要求すると、貸し手７１０は、最初に、アップデートされた一時的キーリストを生成し、それ自体が、キー借用交渉プロセスの期間の間、その特定のキーを使用することを禁止する。この作用は、２つ以上の借り手７２０ユニットが、同一キーを要求することを禁止する。貸し手ユニット７１０の一時的キーリスト上の「借用されたキー」の存在は、任意の特定のキーへのアクセスを制御するためのセマフォとして、効果的に使用される。しかしながら、キーが「制限」された状態に置かれる初期の時間は、比較的に短い期間に限定されるべきである。これは、借り手７２０デバイスが、長期間の間、特定のキーへのアクセスを要求し、次いで、ある理由から、トランザクションを完了できず、特定のキーの使用を不公平に独占する場合を防止することである。また、この比較的に短い借用交渉段階のタイムアウトは、貸し手ユニット７１０に対する「サービス妨害」攻撃の同等物をマウントしようし得る、悪意のあるデバイスに対抗する際に有用である。実際、貸し手ユニット７１０は、随意に、その「承認された借り手」リスト上に存在しない、またはそれらのユニットの任意の１つが、ある時間期間内に多過ぎる要求を行おうとする場合、デバイスからの要求を無視可能である。この一時的ブロックがキーに設定される正確な時間長は、重要ではないが、任意の所与の借用手順が完了まで進むことが可能な十分な時間であるべきである。高ネットワークトラフィック量または待ち時間の場合、この期間は、延長され得る。
【０２１７】
所与のキーの２つ以上のコピーが、同時に借用可能である場合、貸し手デバイス７１０の一時的キーリスト内の適切なフィールドは、時間内の任意のある時点において、所与のキーのいくつのコピーが借用されているかを示すために使用可能であることに留意されたい。借り手７２０および貸し手７１０が、所与のキーのための特有の借用期間を交渉すると、貸し手７１０は、キー７４０の暗号化されたコピーを借り手７２０に送信する。この暗号化は、貸し手デバイス７１０にのみ既知である、一時的秘密キー７３０を使用して行われる。次いで、借り手７２０が、暗号化されたキーの確実な受信を確認応答すると（暗号化されたメッセージから計算される、メッセージだイジェクトによって）、貸し手７１０は、借用されたキーの「貸与期間」を延長し、次いで、一時的秘密キー７３０を借り手デバイス７２０に送信する。この貸与プロセスの最長期間は、プロトコルの動作にとって重要ではなく、この値の選択において行われなければならない、あるトレードオフが存在する。それらの特定の問題については、このセクションに後述される。上述の実施例では、「借り手７２０」および「貸し手７１０」デバイスは、キー対キーベースで、借用期間の実際の長さを交渉可能であることが想定されるが、これは、当然ながら、プロトコルの要件ではない。
【０２１８】
借り手７２０または貸し手７１０のいずれかの一時的キーリストがアップデートされる直前に、この新しい一時的リストと関連付けられたタイムスタンプ値２３０のコピーは、不揮発性方式において、標的１００上に格納される。その時点で、一時的キーリストデータ構造の暗号化されたバージョンは、メモリに安全に書き出される（あるいは、搭載ＮＶＲＡＭ、フラッシュＲＯＭ等のある他のより多くの永久場所内に保存される、またはさらにあるハードディスク７５０上のバックアップファイルに書き出される）ことが可能となる。一時的キーリストは、潜在的に、永久キーリストより遥かに頻繁に、読み出され、アップデートされるため、このリストは、標的ユニットに迅速にアクセス可能であることが望ましく、したがって、このリストが、アクセス待ち時間が比較的に短い、少なくとも１つの場所内に格納されることが推奨される（しかしながら、これは、プロトコルの実際の要件ではない）。一方、電源異常によって、潜在的に、途中でユニット１００の機能の損失が生じ得るため、このリストが格納される唯一の場所は、ある揮発性記憶媒体（ＤＲＡＭ等）だけではないことが推奨される。この問題については、このセクションで後に詳述される。
【０２１９】
特定のキーのための借用期間の時間が満了すると、借り手７２０および貸し手７１０デバイスは両方とも、それらのそれぞれの一時的キーリストデータベースを独立してアップデート可能となる。したがって、借り手７２０が、「貸出のために、特定のキーを返却」するために、貸し手７１０ユニットと接触することは、要件ではない。これは、借り手７２０および貸し手７１０デバイスが、広範囲にわたって分離されている場合、主要な便宜的要因である。当然ながら、この動作のセキュリティは、キータイムスタンプ記録を生成および制御するために使用される、オンチップクロック間の非常に密接な相関に依存し得る。したがって、時間／日付クロックは、セキュリティシステムの一体部分でなければならず、したがって、中央サーバとのトランザクションによって上書き可能であるべきである。また、クロックは、悪質なユーザが、内部タイムスタンプ値２３０を書き換えようとする場合、改ざんを抑止するために十分にロバストであって、また、通常生じるシステムの電源異常を克服可能なように設計されなければならない。このクロックが、バッテリ駆動であって、バッテリが、除去される、または経時的に停止し得ることは、あり得ないことではないため、システムは、クロックが、潜在的に、使用許諾権限者とのセキュアな交信によって、再開およびリセットされ得るように、設計されるべきである。
【０２２０】
このように、特定のアプリケーション特有のキー５５０の所有権が、あるユニットから別のユニットに、一時的に譲渡可能な環境について説明された。「貸与期間」の終了時、「借り手７２０」および「貸し手７１０」ユニットは両方とも、それらの一時的キーリストデータ構造をアップデートし、そのオリジナル所有者へのキーの「返却」を反映可能である。この手順は、両ユニット上で独立して実行可能であって、したがって、２つのデバイス間の任意の交信を必要としないことに留意されたい。
【０２２１】
次に、１つ以上のキーが「借用」あるいは「貸与」されている間、一時的キーリストデータ構造の一方もしくは他方が、破損および／または損失される場合に対処しなければならない。「貸し手７１０」ユニット側では、任意のキーが借用されると、最初に行うことは、「貸与」期間の終了の決定である。この値は、貸与期間の持続時間を現在の時間／日付フィールドの値に追加することによって、明白に構築される。次いで、この時間／日付値は、デバイスの一時的キーリストがアップデートされた最終時間の結果として、チップ上に格納される値と比較される。新しい値が古い値より大きい（より最近である）場合、新しい値は、古い値の代わりに上書きされる。「借り手７２０」側では、結果として、任意の所与の標的ユニットにおいて、一時的キーリストタイムスタンプが、常に、その特定のユニット１００の一時的キーリストの一部として格納される、タイムスタンプのいずれかの最新のものであるように、この同一プロセスが使用される。
【０２２２】
ユニット１００の一時的キーリストが、損失または別様に不適切に書き換えられる場合、一時的キーリストおよび永久リストの両方とも、この「最新タイムスタンプ」値が満了する時点（事実上、「タイムアウト」期間）まで、無効とされる。次いで、この時点で、ユニットは、永久キーリストの使用に戻ることができ、新しい一時的キーリストを再構築するプロセスを開始可能となる。
【０２２３】
したがって、デバイスの一時的リストが、そもそも、改ざんまたは削除される場合、ユニットは、タイムアウト期間が満了するまで、事実上、動作不能である。このタイムアウト手順は、不必要に制限的であるように考えられ得るが、ある悪質な行為の結果として、あるいはあるユニットから別のユニットへのキーの譲渡の際に生じ得る、ある誤作動（停電またはネットワーク接続のダウン等）のため、これまで存在している任意の特定のアプリケーション特有のキーの複数のコピーの潜在的な問題を回避する。また、一時的なキーリストデータ構造の改ざんの結果としてのそのような深刻な影響の潜在性は、すべてではないが、より巧妙な攻撃者を除いた全攻撃者による実践を阻止するのに有用であるはずである。
【０２２４】
この点に関して、プロトコルの動作を向上させるために使用され得る、いくつかの任意の付加的特徴が存在する。そのような可能性のある選択肢の１つは、暗号化されたキーリストデータ構造の一方（または、両方）から生成される署名されたメッセージダイジェスト（デジタル署名）を、標的ユニットのオンチップセキュリティセクション内に格納される値に追加することである。デジタル署名の復号化から生じるＭＡＣ値は、復号化プロセス全体を経る必要なく、任意の特定のキーリストの有効性を迅速に検証するために使用され得る。しかしながら、複数のネスト化されたキーリストの問題は、この復号化手順が、非暗号化キーを最終的に生成するために、ある時点で複数回行われなければならない可能性が高いことを意味し、したがって、これらのデジタル署名がオンチップとして格納されることは、プロトコルの動作に重要ではない。
【０２２５】
向上のための別の可能性は、１つのみではなく、一対のオンチップタイムスタンプ値を格納することである。付加的タイムスタンプは、一時的キーリストがアップデートされなければならない最短（次の）時間を示すために使用され得る。これは、リスト全体を定期的にチェックする（復号化プロセスを踏むことを伴う）必要がないため、標的デバイス１００が、その一時的キーリストを改訂する必要がある時を決定することをより容易にするであろう。この特徴は、非常に有用となるであろうが、同様に、ユニットが、このプロトコルを実行可能となるための基礎的要件ではない。しかしながら、この第２のタイムスタンプを含有するシステムが実装される場合、２つのタイムスタンプが、ある理由から「非同期」となる場合には、混乱の潜在性をもたらす。思い浮かぶ、そのような実施例の１つは、そのようなタイムスタンプの１つが書き出された直後、第２がアップデートされる前の時点で、電力以上が生じる場合である。
【０２２６】
解決されるべき最後の問題は、どのような最小限界および最大限界がこれらの一時的キーリストタイムスタンプの値に対するものであるかということである。一方では、最長の「一時的貸与期間」に対する限度が大きいほど、ユーザは、合理的に長期間の間、あるユニットから別のユニットに特定のデータアプリケーション（または、メディアストリーム）の使用を譲渡可能となり得る。これは、潜在的に、ユーザがその「ホームユニット」からポータブルユニットに、メディアストリームの所有権を譲渡することを所望する場合に有用となるであろう長期「借用期間」を有することによって、ユーザは、オリジナル「貸し手」ユニット７１０と接触することを必要とせずに、長期間の旅行の際に、ポータブルユニットを（その関連付けられた一時的キーとともに）携行可能となるであろう。長い「借用」期間のマイナス面は、オリジナルユニット上の一時的キーリストデータ構造に何らかが生じる場合、ユニットは、潜在的に、長時間、無効となることである。
【０２２７】
また、この最後の問題は、悪質なコードが、オンチップタイムスタンプレジスタの値をある中間値に設定可能である場合の標的ユニット１００に対する潜在的危険性を指摘する。これは、潜在的に、攻撃の標的を無効にすることに等しく、したがって、このタイムスタンプレジスタの値は、「セキュアな」コードブロックによってのみ書き込み可能であるべきである。同様に、各ユニットは、個別の秘密キー集合を有するため、１つの特定のユニットの秘密キー１０４データの発見は、任意の他のユニットに対する懸念を生じさせるはずはないが、但し、悪意のあるデバイスが、事実上、合法ユニットになりすますことが可能である場合を除く。攻撃のモードは、身元照合関連問題に対処する、後のセクションで論じられる。
【０２２８】
（永久使用許諾権譲渡）
この手順の要素の多くは、本書の上述のセクションにおいて論じられた。特有のキーが、あるユニットから別のユニットに永久に譲渡される基本的プロセスは、図５において上述された。多くの方法では、この手順は、直前のセクションに説明されるように、キー所有権の一時的譲渡に本質的に類似する。
【０２２９】
２つの手順の間の主要な差異は、永久譲渡が、一時的譲渡より単純なプロセスであって、永久キー所有権譲渡手順が、使用許諾権限者５１０と標的ユニット１００との間の交信を利用すべきことである。永久譲渡プロセスが、より単純である理由は、一時的キーの借用手順の前提条件である、借用時間期間交渉を必要としないという事実に依るものである。永久譲渡機能が、使用許諾権限者５１０と標的ユニット１００との間の交信を利用する理由は、アップデートされたキーリストデータ構造が、トランザクションの両終点において、再構築可能でなければならないという事実のためである。
【０２３０】
永久使用許諾権譲渡は、通常、使用許諾権限者５１０との交信によって生じるため、どのアプリケーションまたはメディアストリーム特有のキーが、どの標的ユニットに属するかの記録が存在する。上述のように、これは、標的ユニット１００のキーリストが、ある壊滅的データ損失環境後に復元されなければならない場合、または特定の標的ユニット１００の所有権が、異なるエンティティに譲渡される場合、必要である。また、使用許諾権限者５１０側のこの介入は、特有のキーの永久所有権が、ある標的ユニット１００から別のユニットに譲渡される場合にも必要である。別のエンティティから元々購入された資産を再販する、所有者のこの能力は、「一次販売権」として知られ、この特定の機能をサポートするために、本明細書に説明されるプロトコルにとって重要な能力である。
【０２３１】
標的ユニット１００の永久キーリストが、使用許諾権限者５１０によって維持されるという事実の別の重要な側面は、ユニット１００が、何らかの形で危殆化されていることが証明される場合、またはキーの１つが、危殆化されていると識別される場合、個々の標的ユニット１００の使用許諾権キーの一部あるいは全部を取り消す能力をこのメカニズムが有することである。キーの一意的リストを各すべての標的ユニット１００に与える潜在性が存在するため（上述のように）、また、使用許諾権限者５１０が、任意の危殆化キーの源を追跡する機会を提供し得る。そのような環境では、このプロトコルは、通常、「透かし」特徴の機能と関連付けられる、機能を充足し得るが、従来の透かしプロセスの欠点（メディアストリームの品質に悪影響を及ぼす、透かしの潜在性等）を伴わない。
【０２３２】
該当しないと考えられ得るが、アプリケーションコードまたはメディアストリーム特有のＩＤ情報は、アプリケーション開発者５２０に由来し、使用許諾権限者５１０は、必ずしも、任意の特定のアプリケーションまたはメディアストリームとその使用許諾権のある所有者との間の関連付けを成すことが可能な十分な情報を有しているわけではないため、デジタルコンテンツ所有者のプライバシーは、依然として、このプロセスによって維持される。また、ユーザのプライバシーを保護するこの能力は、このプロトコルの重要な側面である。
【０２３３】
永久キー譲渡プロセスに関して留意されるべき最後の問題は、実際は、一時的キー使用許諾権譲渡によって、永久キー譲渡が行う同一機能すべてを達成可能であることである。しかしながら、標的ユニットのセキュリティシステムの維持は、理想的には、中央のセキュアなサーバによって制御されるべき機能であって、したがって、連鎖内のいずれかの場所の定位置にそのようなメカニズムを有することが必要である。また、ユーザが、それらのプライバシーの維持に関して懸念する場合、中央サーバが、著作権保有者と標的ユニット１００との間のバッファとして作用可能であるという事実は、非常に有用である。最後にまた、使用許諾権限者５１０が、一時的キー譲渡メカニズムに加えて、この機能を設定する、特定の標的ユニット１００の永久キーリストのための中央バックアップ記憶メカニズムとして作用可能であることも魅力である。
【０２３４】
（システム所有権譲渡、使用許諾権の取消、およびセキュリティシステムアップデート）
標的ユニット１００の使用許諾権（または、キー）の１つ以上が取り消され得る、いくつかの異なる手段が存在する。最も簡単な方法は、単に、標的１００の一次秘密キーをアップデートすることである。次いで、この時点で、標的１００は、その永久キーリストへのアクセスが不可能となり、したがって、新しいリストを作成するプロセスを開始しなければならないであろう。一次秘密キーが、一時的キーリストデータ構造のための暗号化プロセスで使用されない場合、この一時的キーリストは、潜在的に、依然として、アクセス可能であるが、永久キーリストは、別様にはアクセス不可能であり得ることに留意されたい。
【０２３５】
このポイントは、一時的キーリストのための暗号化プロセスの説明において記載された。この理由から、標的ユニット１００の一次秘密キーを永久および一時的キーリストデータ構造の両方のための暗号化キーとして使用することは、可能性として、最良の考えである。
【０２３６】
標的ユニット１００の所有権が、ある個人から別の個人に変更する場合、この所有権変更を発効させる最も単純な態様は、ユニット１００の一次秘密キーをある新しい値に設定することである。しかしながら、オリジナル所有者が、標的からそれらの永久キーすべてを復元する機会を有する前に、これが生じる場合、それらの使用許諾権を失うであろう。オリジナル所有者が、関連付けられた永久キーリストの所有権とともに、標的ユニットの譲渡を所望する場合、その特定のデバイスと関連付けられた所有権情報（使用許諾権限者５１０において格納される）の変更以外、標的ユニット１００に何も行う必要はない。
【０２３７】
使用許諾権の取消が生じ得る別の態様は、特定の標的ユニット１００の永久キーリストのためのマスタキーが「満了」する場合である。ユニット１００のセキュリティシステムへのアップデートは、永久キーリストの一部として格納されるため、この環境は、潜在的に、壊滅的な影響を有し得る。
【０２３８】
潜在的に、この窮地から回復することは可能であろうが、標的１００に、完全に新しい「信頼の連鎖」を初めから作り直す必要があることを要求することになる。この環境では、新しく初期化されたセキュリティシステムのコアは、標的１００の一部上で、アトミックに起動可能であると検証され得る、動作にのみ基づく必要があるであろう。したがって、これは、その他の点では汎用であるコード（潜在的に、疑わしい可能性がある）の最小量であっても必要とする、任意のハッシュ関数の使用を妨げるであろう。幸いにも、この環境は、失効しない永久キーリストデータ構造の一部として、検証可能なセキュアなコードフラグメントの永久コアを常に維持するという単純な事によって回避可能である。しかしながら、これは、上述の理由から、それ自体、セキュリティの危険性であって、したがって、この永久コードコアのコンテンツは、可能な限り限定されるべきである。
【０２３９】
使用許諾権の取消のさらに別の態様は、使用許諾権限者５１０が、標的ユニット１００の永久または一時的キーリスト内の特定のキーの入力を上書きすることを選択する場合に生じ得る。これは、セキュリティシステムアップグレードが必要とされる場合、あるいは特定の標的ユニット１００が、特定のアプリケーションまたはメディアストリームの使用許諾権のないコピーを有すると識別される場合に使用され得る。標的ユニット１００は、通常、その独自のキーリストデータ構造を維持するため、この手順は、使用許諾権限者５１０と標的ユニットとの間のネットワークトラフィックが通常より大きくなることを伴うであろう。したがって、この一連の作用は、極端な場合に確保されるべきである。
【０２４０】
しかしながら、そのような手順は、当該標的デバイス１００に、疑問視されるキーを検索し、無効にする、および／または、次いで、より古いソフトウェアをアップデートされたバージョンと置換するように設計される、標的特有のカスタムバージョンによって、そのセキュリティシステムソフトウェアを改訂させることによって達成可能である。当然ながら、この手順は、標的デバイス１００が、使用許諾権限者の中央サーバとの接続を開始する時点においてのみ、作動可能である。通常環境下では、任意の特定の標的ユニット１００が、任意の特定のスケジュールにおいて、使用許諾権限者５１０と接触を開始することは保証不可能である。幸いにも、標的デバイス１００は、その永久キーリストへの任意の新しい追加を承認するために、使用許諾権限者５１０（直接または間接的に）と接続しなければならず、したがって、任意のキー取消作用は、新しいキー使用許諾手順の一部として達成可能である。また、上述の「セキュリティシステムタイムアウト」メカニズムは、この「リスト監視」作用をサポートするために使用され得ることも可能性として考えられる。しかしながら、これに該当することは、このプロトコルの要件ではなく、そのようなシステムは、ユーザのプライバシー権の侵害をもたらす可能性が高い。
【０２４１】
（他の懸念：）
必ずしも、プロトコル自体の一部ではないが、それでもなお、本明細書に説明されるプロトコルを適切に実行可能な実践的システムを作製するプロセスにおいて解決されなければならない、いくつかの問題が存在する。これらの問題の一部は、実際のプロセッサデバイス実装に依存し、その他は、大部分が、アプリケーション特有のものである。この情報は、好適な標的デバイス１００の適切な構築に密接な関係があるため、これらの問題の一部については、以下のセクションで論じられる。
【０２４２】
（相互運用可能なユニットの数の制限）
著作権保有者が、主要標的が所有権を一時的に譲渡可能なデバイスの総数を限定することを所望する場合、これは、任意のある時間にアクティブとなり得る、限定数の公開／個人キー対を確立することによって達成されてもよい。これは、上述のセクションで説明された、同一アプリケーション特有のキーの複数のコピーが、同時に「貸与」される場合と異なることに留意されたい。特定の標的デバイス１００からアプリケーション特有のキーのいずれかを「借用」可能なデバイスのリストが、ある通し番号集合に限定可能であるという、他のシナリオも可能である。使用許諾権限者５１０は、標的ユニット１００のセキュリティシステムが管理されるのと正確に同一態様において、そのような「承認された借り手」リストを運営可能である。したがって、使用許諾権限者５１０は、例えば、「承認された借り手」リスト上の通し番号集合を、オリジナル標的デバイス１００と同一所有権情報を有する者に限定可能である。この問題に対する別の可能性のある解決策は、中央使用許諾権限者５１０の公開キーによって証明書を復号化することによってのみ照合可能である、資格証明書（署名された証明書等）を貸し手に提示することによって、任意の「借り手」デバイス７２０が「権限のある」借り手として照合されることを要求することである。また、このシナリオは、当然ながら、使用許諾権限者５１０が、特定のユニットが危殆化されていると決定される場合、そのような証明書を取り消す能力も伴うであろう。この証明書取消プロセスが達成され得る、周知の方法の１つとして、定期的に公開される「取消リスト」を介して達成可能である。
【０２４３】
（秘密キー発見および身元照合問）
特定のプレーヤのための一次秘密キーが、物理的分解およびチップダイ検証によって発見される場合、各デバイスは、個別の秘密キー１０４集合を有するため、これは、任意の他のデバイスのセキュリティを危殆化することにはならないはずである。しかしながら、特定のプレーヤのための一次キーが、何らかの形で危殆化される場合、潜在的に、使用許諾がないデバイスは、合法標的ユニットになりすますことが可能である。この問題が検出されない場合、この知識を備えた使用許諾がないデバイスは、その特定の標的ユニットに発行されたアプリケーション特有の復号化キーのいずれかを危殆化させ得る可能性が存在する。最初に、標的ユニット１００の通し番号１０６は、使用許諾権限者５１０が、復号化キーをデバイスに発行するために、登録される必要があるため、この目的に関する問題は、表面上は、使用許諾がないデバイスによる、その他の点では合法である標的ユニット１００の模倣に限定されるであろう。
【０２４４】
しかしながら、ユニット１００の秘密キーの両方が、そのようなプロセスによって発見される場合、以前にバックアップされた暗号化されたキーリストダイジェストのコピーの検証に基づいて、そのユニットに使用許諾が付与されたアプリケーション特有のキーすべてのセキュリティを危殆化させる可能性がある。この理由から、一次および二次秘密キーの両方とも、これらのキーの値を発見しようとするいかなる試みも、キーデータの損失をもたらすような「改ざん防止」態様において、標的チップ上に実装されるべきである。
【０２４５】
この改ざん防止特徴が標的デバイス１００上に実装され得るいくつかの手段が存在するが、その正確な実装は、本書に説明されるプロトコルに重要ではない。「秘密キー損失」環境が、ユーザ側のある悪意のない過失行為（または、不正使用）を通して生じる場合、合法ユーザは、それらの損傷ユニットを、損傷ユニットのアプリケーション特有のキーを新しいデバイスに譲渡させように手配可能な使用許諾権限者５１０に返却可能であるべきである。しかしながら、オリジナル標的デバイス１００が、機能しない場合、新しい標的デバイス１００へのキーの譲渡は、アプリケーション開発者５２０とのトランザクションを伴わなければならない（少なくとも、そもそも、暗号化されていない状態で使用許諾権限者５１０に供給されていないキーのために）ことに留意されたい。
【０２４６】
しかしながら、その他の点では本物である標的ユニット１００になりすますことが可能なデバイスは、表面上、疑いのない合法的に使用許諾のあるデバイスに、そのアプリケーション特有のキーの１つ以上の所有権を一時的に断念させる、または動作を一時停止させることが可能であり得ることに留意されたい（上述のように）。後者が生じる場合、そこからキーを借用しようとするユニットすべてを無効にし得る、「不正ユニット」を有する可能性が存在する。前者が生じる場合、任意の数のアプリケーションまたはメディア特有のキーは、潜在的に、危殆化され得る。
【０２４７】
したがって、特定の標的ユニット１００に対する潜在的「使用許諾のある借り手」の数を、使用許諾権限者５１０サーバからのセキュアなアップデートによってのみ、合法ユニットに供給可能であったリストに限定する上述の概念は、賢明である。前者の場合、これは、その他の点では疑いのないユニットの所有者が、そのユニットが、そもそも、実際に彼らに属していない限り、機能ユニットを分解し、その秘密キーへのアクセスを得るハッカーによってそれらの合法デバイスを無効にされることを防止するであろう。後者の場合、これは、アプリケーションまたはメディア特有のキーの譲渡を、ある時点において、使用許諾権限者によって、適切に登録された使用許諾のあるデバイスにのみに限定するであろう。しかしながら、執拗なハッカーは、依然として、合法ユニットを購入し、それをこじ開け、何らかの形で、その秘密キーデータへのアクセスを得、次いで、この情報を使用して、合法デバイスになりすまし得る。
【０２４８】
したがって、どのようにこの種類のなりすまし事象を検出しようとするかという問題が残存する。非常に資金力のあるこの性質の敵を打ち負かすたまの唯一の成功する戦略は、潜在的入手が、少なくとも、費用トレードオフの観点から、必要とされる努力に値しないように、システムを設計することである。
【０２４９】
通信中である、その他の点では未知のデバイスの真正性を証明しようとする、いくつかの手段が存在する。しかしながら、あるデバイスが、実際に、要求されるものであることを証明するための最も成功する方法は、このデバイスを他のデバイスから一意的にする特徴に焦点を当てることである。本書によって説明されるデジタル復号化メカニズム等の特殊用途装置の場合、セキュリティプロトコルを適切に実行し、所与の入力変数集合に基づいて、正確な結果を計算するデバイスの能力であろう。しかしながら、本明細書に説明されるセキュリティプロトコルは、公知のアルゴリズムに基づくため、これは、表面上は、動作を完了するために十分な時間を有することを前提として、任意の汎用コンピューティングデバイスによって達成され得る。実際、デバイスを一意的にする秘密キー情報が、何らかの形で危殆化される場合、この問題は、公的に利用可能な技術に基づく、任意のデバイスにとって、潜在的問題となるであろう。したがって、最終的には、合法標的デバイスのすべてに対して、オンチップとして格納される秘密キー情報が、分解およびチップダイ検査に直面する場合でも、秘密のままでなければならないという指針に依存する必要がある。
【０２５０】
当然ながら、一定時間内に、検証可能なＭＡＣ値を正確に見出す能力等、標的識別および照合プロセスに要件を追加可能である。最終ＭＡＣ値が複数回暗号化されることを要求することによって、手順をさらに困難にすることも可能である。したがって、潜在的に、通常、単に、使用許諾権自体の合法コピーを購入する費用より遥かに高価である、（より汎用性の）動作上のリソースへのアクセスを有することが必要とされるという点において、合法デバイスを模倣する攻撃者の能力を制限し得る。また、メディアストリームプレーヤの場合、プレーヤが、表面上、対応するように設計される、メディアストリームの１つ以上の一部を正確にデコードする能力を含み得る。
【０２５１】
しかしながら、いずれの場合も、デジタル著作権保護のプロセス全体は、チューリング（Ｔｕｒｉｎｇ）問題である。したがって、十分な時間およびリソースを前提として、任意のデジタル著作権保護方式は、執拗な敵に敗れる可能性がある。これは、当然ながら、秘密キー情報へのアクセスが、可能性のある攻撃者にとって、確実に大きな利点となるであろうという事実とは無関係でさえある。したがって、ユニットの秘密キーが危殆化されることを防止する能力は、このセキュリティプロトコルの重要な部分である。
【０２５２】
（結論：）
上述の著作権保護プロトコルは、いくつかの点において、一意的である。第１は、ユーザが、それらの法的に購入されたアプリケーションまたはメディア特有のキーデータのバックアップコピーを作成する能力を禁止しようとしないという事実である。２つ目は、このプロトコルが、任意の種類のデジタルデータを区別せず、したがって、セキュリティプロトコルを保護するように設計されるデータストリームとして、容易にアップデート可能であることである。３つ目は、このプロトコルによって、ユーザは、それらのアプリケーションまたはメディア特有のキーの所有権を、プロトコルを実行可能な別のユニットに一時的に譲渡可能となることである。また、このプロトコルは、被許諾者に、ある標的ユニット１００から別のユニットに所有権の永久譲渡を発効させるための能力を提供する。この最後の特性によって、このプロトコル下の消費者の法的「一次販売権」の実装が可能となる。
【０２５３】
実際、本書に説明されるプロトコルと、他のコピー保護方式との間の基礎的差異の１つは、本システムのセキュリティが、特定のデータ集合にアクセスする能力を制御することではなく、むしろ、そのデータ集合内に含有されるアイディアを表現する作用を制御する能力に依存することである。
【０２５４】
上述の明細書において、本発明が、特有の実施形態を参照して説明された。しかしながら、当業者は、以下の請求項に記載される本発明の範囲から逸脱することなく、種々の修正および変更を行うことが可能であることを理解されたい。故に、明細書および図は、限定的意味ではなく、例示としてみなされるべきであって、そのような修正はすべて、発明の範囲内に含まれるものと意図される。
【０２５５】
効果、他の利点、および問題の解決策について、特有の実施形態に関して、上述された。しかしながら、効果、利点、問題の解決策、および任意の利益、利点、または解決策を生じさせる、あるいはそれらがより顕著となり得る、任意の構成要素は、請求項の一部または全部の必須、必要、あるいは不可欠な特徴もしくは構成要素と解釈されるべきではない。
【０２５６】
【化１】
0005636371.tif 000003
【０２５７】
【化２】
0005636371.tif 000004
【０２５８】
【化３】
0005636371.tif 000005
【０２５９】
【化４】
0005636371.tif 000006
【０２６０】
【化５】
0005636371.tif 000007
【０２６１】
【化６】
0005636371.tif 000008
【０２６２】
【化７】
0005636371.tif 000009
【図１】
0005636371.tif 000010
【図２】
0005636371.tif 000011
【図３】
0005636371.tif 000012
【図４Ａ】
0005636371.tif 000013
【図４Ｂ】
0005636371.tif 000014
【図５Ａ】
0005636371.tif 000015
【図５Ｂ】
0005636371.tif 000016
【図６】
0005636371.tif 000017
【図７Ａ】
0005636371.tif 000018
【図７Ｂ】
0005636371.tif 000019
【図７Ｃ】
0005636371.tif 000020
【図８】
0005636371.tif 000021
【図９】
0005636371.tif 000022
【図１０】
0005636371.tif 000023
【図１１】
0005636371.tif 000024
【図１２】
0005636371.tif 000025
【図１３】
0005636371.tif 000026
【図１４】
0005636371.tif 000027
【図１５】
0005636371.tif 000028