セキュアデバイス認証システム及び方法
ブロックベースドメディアのセキュリティと認証のための技術は、保護鍵の使用を含み、認証と暗号プリミティブを提供する。本技術に従ったシステムは、保護鍵付きのセキュリティカーネルを有するセキュアデバイスを備えても良い。ディスクドライブ・セキュリティ機構は、データの認証や秘密性をサポートしたり、更にセキュリティカーネルやチケットサービス・モジュール（例えば、フラッシュのような他の記憶装置によって使用されたり、これを使用しない共有サービス）を用いたチケット有効化をサポートしても良い。
【発明の詳細な説明】
【技術分野】
【０００１】
今や、認証やその他のセキュリティ問題は、理論上及び実用上、広範囲の研究・開発の分野となっている。１つの分野は、ＤＶＤまたはそれに匹敵するテクノロジーでのデータの認証であり、それはＣＤや新しいＤＶＤテクノロジーを含むかは不明だが、ＤＶＤテクノロジー間の類似性ゆえに通常ＤＶＤテクノロジーの全域に適用可能なものとなっている。ＤＶＤやＣＤ、更にその他の自由に配給可能なメディアディスクを以て、その認証は特に強固でなければならない（例えば、暗号法の使用）。
【背景技術】
【０００２】
ディスクベースのメディアは通常、ブロックベースドデバイスである。それ故、ブロックデータへのアクセス時間や使用されるどんな暗号アルゴリズムの演算時間も、ディスクベースのメディアを使用するシステムの仕様を満足しなければならない。更に、コンテンツは秘密保持のためにしばしば暗号化される場合がある。また、セキュアデバイスの秘密保持やディスクベース・メディアのための認証技術に対するその他の考慮すべき事項には、その技術が読取専用媒体をサポートすべきこと、（各ディスクに特注又は固有のデータを要求せずに）ディスクの大量生産をサポートすべきこと、そして認証のためにディスク上に格納される付加データは妥当なオーバーヘッドを課すだけであるべきことが含まれる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
これらの要求事項を満たすべく幾つかの取り組みが提案されたが、秘密保持や認証技術における多くのソリューションと同様に、そこには改善の余地がある。例えば、公開鍵暗号に基づいたブロック署名（例えば、ＲＳＡ署名）を付けることも可能だろうが、読み込まれるデータのあらゆるブロックはＲＳＡ照合演算が必要となるために、この取り組みは比較的遅い処理となる。ＲＳＡは、公開鍵暗号化のためのアルゴリズムである。それは、暗号化と同様に署名に適切と思われた最初のアルゴリズムであった。ＲＳＡは十分に長い鍵があたえられ、セキュアである（技術的に安全性が保証された）と思われている。更に、比較的遅いことに加えて、ブロック毎に行われるＲＳＡ署名のサイズは比較的高いオーバーヘッドを課すことにもなるであろう。
【０００４】
別の例としては、ディスクのカスタム防護エリアに書き込まれたブロック毎にＳＨＡハッシュ（又は、その同等の物）を付けることも可能であるが、これはカスタムディスクの製造が必要となる。更に別の例として、各ブロックに対しＨＭＡＣ（又は同等の物）などの秘密鍵ベースのメッセージ認証コードを付けることも可能だろうが、この場合、総てのディスクに、ＨＭＡＣが同じでなければならず、これにより単一の秘密鍵機構となり、所望のセキュリティレベルを提供できない可能性がある。別の例としては、階層のメンバーを読み込むために、ブロックアクセス毎にブロックデバイスの複数のシーク(multiple seeks)が必要となる階層的署名アプローチを使用することも可能だろうが、この処理は待ち時間が長くなってしまう可能性がある。
【０００５】
上述したこれら関連技術の例や制限事項は、あくまで説明に役立つものとして例証したものであって排他的ではない。関連技術の他の制限事項は、当該技術者が本願明細書を読み、図面を検討することにより明らかになるであろう。
【課題を解決するための手段】
【０００６】
以下の実施形態とその特徴は、あくまで例証的であって範囲を制限しないことを意図したシステム、ツール、および方法に関連して記載、図示される。種々の実施形態では、上述した問題の１つ又はそれ以上が低減又は解消され、一方では他の実施形態がその他の改善に向けられる。
【０００７】
ブロックベースドメディアのセキュリティと認証のための技術は、保護鍵の使用を含み、認証と暗号プリミティブを提供する。本技術に従ったシステムは、保護鍵付きのセキュリティカーネルを有するセキュアデバイスを含んでも良い。ディスクドライブ・セキュリティ機構は、データ認証や秘密性をサポートしたり、更にセキュリティカーネルやチケットサービス・モジュール（例えば、フラッシュのような他の記憶装置によって使用されたり、これを使用しない共有サービス）を用いたチケット有効化をサポートしても良い。実装の形態によっては、セキュリティカーネル、ディスクドライブ・セキュリティ機構、及びチケットサービス・モジュールは、３つの異なった実行空間で動作する可能性もあり、それに非限定的な例として、例えば光学ディスクを含む様々な入出力・記憶装置により一般的に使用可能である。
【０００８】
非限定的な実施形態では、ブロックベースドメディアは読み取り専用であるが、その技術は追記型（ＷＯＲＭ）、書き込み可能型、或いは他のブロックベースドメディアなどに適用可能であるかもしれない。またその技術は、他の記憶媒体、暗号鍵を引き出すための代替法を導く他のライセンシング機構、及び／又は他の移送メディア（例えば、インターネットのパケットベースのダウンロード）に適用可能であるかもしれない。
【図面の簡単な説明】
【０００９】
本発明の実施形態を図面に示す。しかしながら、ここに示した実施形態と図面は、本発明を制限するものというよりむしろ説明するためのものであって、本発明の例を提供するものである。
【図１】階層的ハッシュ技術に関連する二分木構造の例を示す図である。
【図２】階層的ハッシュ技術に関連する非二分木構造の例を示す図である。
【図３】32KBブロックの例を示す図である。
【図４】図１乃至図３を参照して説明した技術の実装の形態に適したコンピュータ・システムを示す図である。
【図５】図１乃至図３を参照して説明した技術の実装の形態に適したセキュアシステムの例を示す図である。
【図６Ａ】セキュアなブロックベースドメディアアクセスの方法の例のフローチャートである。
【図６Ｂ】セキュアなブロックベースドメディアアクセスの方法の例のフローチャートである。
【図７Ａ】セキュアなブロックベースドメディアアクセスの別の方法を示すフローチャート７００である。
【図７Ｂ】セキュアなブロックベースドメディアアクセスの別の方法を示すフローチャート７００である。
【図７Ｃ】セキュアなブロックベースドメディアアクセスの別の方法を示すフローチャート７００である。
【発明を実施するための形態】
【００１０】
以下の説明では、本発明の実施形態の十分な理解を与えるために幾つかの特定の具体的な構成が提示される。しかし、当業者であれば、１つ以上のこれら特定の具体的な構成がなくとも、あるいは他の構成部などとの組み合わせにより、本発明を実施することが可能であることが理解されるであろう。また別の例では、様々な実施形態における本発明の側面を覆い隠すことがないように、周知の具体的構成は、図示または詳細に説明されていない。
【００１１】
図１は、階層的ハッシュ技術に関連する二分木構造１００の例を示している。本願明細書で援用されるものは、１９８２年１月５日にマークル（Merkle）に対し発行された「デジタル署名提供法（“Method of Providing Digital Signatures”）」と題する米国特許第4,309,569号である。一群のデータブロック{Y1, …Yk, …Yn}、(1<=k<=n)が認証されることになる。図１の例ではn=8である。ブロックYkは、Ykと一群の値H(i, j, Y)を用いることで認証される。伝達されたブロックYkと、これに対応する一群の値H(i, j, Y)はYkの信頼性を確立するために個々に使用できる。ここで、H(i, j, Y)は以下のように定義される。
H(i, i, Y)=F(Yi)
H(i, j, Y)=F(H(i, (i+j-1)/2, Y), H((i+j+1)/2, j, Y))
但し、F(Yi)はSHA-1などの一方向関数である。従って、H(i, j, Y)は、Yi, Yi+1, ...Yjの一方向関数、H(1, n, Y)は、Y1〜Ynの一方向関数である。即ち、レシーバーはYkとHの一群の値を選択的に認証することが可能である。
【００１２】
二分木構造１００のルート値H(1、8、Y)を信用するためには、例えばその値に対する公開鍵ベースの暗号署名（例えば、RSA署名）を獲得できなければならない。署名は、信頼できるルート鍵まで適切に証明書の連鎖を検証することで、署名を有効にすることが可能となる。しかしながら、何らかの適用可能な公知の（又は手頃な）セキュリティ機構を、信用構築のために使用できるであろう。
【００１３】
図１の例では、Y5を認証するために、信頼のあるH(1, 8, Y)を持ち、かつH(6, 6, Y)、H(7, 8, Y)、及びH(1, 4, Y)を受けとることが必要である。H(5, 6, Y)とH(5, 8, Y)は導き出すことが可能である。説明のために、これらのボックスは図１で陰影をつけられており、導き出された値を示すボックスは破線を有し、H(5, 5, Y)は検証ターゲットであって太線によって囲まれたブロックで表されており、ルート値H(1, 8, Y)は破線と実線との双方によって囲まれ、H(1, 8, Y)自体が受信されるものであると共に導き出されるものでもあることを示している。認証を成功させるためには、H(1, 8, Y)の受信値と導き出された値(received and derived values)は一致していなければならない。陰影のないボックスに関連した値は、Y5を認証するために既知である必要はない。
【００１４】
図１に示す例において、検証ターゲットH(5, 5, Y)、及び受信値(received values)の最初の値H(6, 6, Y)は、共に、上述したH(i, j, k)の定義を用いて、H(5, 6, Y)を導き出すのに使用できる。又、導き出された値(derived value) H(5, 6, Y)、及び受信値の２番目の値H(7, 8, Y)は、共に、H(5, 8, Y)を導き出すのに使用できる。更に、導き出された値H(5, 8, Y)、及び受信値の３番目の値H(1, 4, Y)は、共に、ルート値H(1, 8, Y)を導き出すのに使用できる。また、H(1, 8, Y)は４番目の受信値でもあった。H(1, 8, Y)の導き出された値と受信値が一致したならば、その時は４番目の受信値が信頼できることと仮定した上でH(5, 5, Y)が認証されることになる。
【００１５】
二分木構造１００の異なったレベルに属するH( )値のグループは、階層の夫々のレベルによって表示することができる。例えば:
H3: = H(1, 8, Y)
H2: = {H(l, 4, Y), H(5, 8, Y)}からなる値
H1: = {H(1, 2, Y), H(3, 4, Y), H(5, 6, Y), …}からなる値
H0: = {H(1, 1, Y), H(2, 2, Y), H(3, 3, Y), …}からなる値
従って、H0ハッシュはデータブロックＹ１、Ｙ２などのハッシュや、二分木構造１００の葉節点(leaf nodes)を言及している。ツリーの構造は、階層におけるレベルの数やツリー構造の各節点(node)の子の数によって定義しても良い。
【００１６】
図１を参照して説明した技術は、他の非二分木構造まで拡張することができる。構造の選択にあたっては、それらに限定されるものではないが、例えば：結果として生じるデータブロックの大きさやブロック認証に必要な認証データ；デバイスからの所望データ読み取り速度を満たすための一方向ハッシュ関数（例えば、SHA-1）の計算の数；シーク(seek)を最小限にしつつ、データを読み込むことの副作用として、又は認証データのための読み取りオーバーヘッドを最小限にする他の方法により、利用可能な認証データを持つことの必要性；ツリーによってカバーされなければならない最大データサイズ、などによって決めるようにしても良い。
【００１７】
図２は階層的ハッシュ技術に関連する非二分木構造２００を示す。図２の例に選ばれるツリーの構造は、例えばDVDディスクなどのブロックベースドメディアデバイスのための上記の要件を満たすものであり、デバイスの上において、データブロックY1、Y2などと共に値H0, H1…の配列(placement)を導くものとなる。
【００１８】
図２の例において、H0ハッシュがH(1, 1, Y)、H(2, 2, Y)などといったように選ばれ、各H0ハッシュが１個の1Kデータブロックをカバーするようになっている。データブロックサイズは、ここでは1Kバイトになるように選ばれているが、どんな適当なサイズでも良い。
【００１９】
図２の例では、非二分木構造２００のH1ハッシュがH(1, 31, Y)、H(32, 62, Y)などといったように選ばれる。即ち、図２の例では、各H1は、３１ブロックのデータをカバーする。その他の実施例としては、３１ブロックのデータというよりはむしろ、どんな適当な数のブロックも使用可能である。３１ブロックのデータは、それに限定されるものではないが、図３の例によって示されたデータブロックに準拠したものである。
【００２０】
図３は32KBブロック３００の例を示している。32KBブロック３００は、ハッシュブロック３０２と３１個の1KBデータブロック３０４を含む。ハッシュブロックは、後述するところのハッシュとパディング(padding)を含む。実装の形態によっては、３１個の1KBデータブロック３０４は、ハッシュブロック３０２によって先行されるように、またはハッシュブロック３０２に挟まれるようにして、例えばDVDディスク上の32KBブロック３００内に一緒に格納される場合もある。
【００２１】
再び図２の例を参照するに、H2ハッシュは、H(1, 31×8, Y)、H(31×8+1, 31×2×8, Y)などといったように選ばれる。即ち、各H2ハッシュは、31×8ブロックのデータをカバーする。これは、各H2節点(node)が、レベルH1において、８個の子を有していることを意味する。本例では被乗数は“８”だが、どんな数も選択可能である。被乗数を増やすことは、（相殺するアクション(counterbalancing action)が取られない限りにおいては）レベルH3の節点（ノード）数を減少させる効果があり、被乗数を減らすことは、その反対の効果をもたらすことになる。
【００２２】
H3ハッシュが、H(1, 31×8×8, Y)、H(31×8×8+1, 31×2×8×8, Y)などといったように選択される。即ち、各H3ハッシュは、31×8×8個のブロックデータをカバーする。これは各H3節点(node)が、レベルH2において、８個の子を有していることを意味する。本例では被乗数は“８”だが、どんな数も選択可能である。非限定的実施形態においては、H3ハッシュの数は、認証機構でカバーされる最大サイズのデータをカバーするように選ばれることもある。例えば、４１８２個のハッシュを9.4G実装品で使用したり、７６８個のハッシュを1.5G実装品で使用したりしても良い。図２の例では、非二分木構造２００は、本例で示されるパラメータと共に如何なるサイズのブロックベースドメディアデバイスにも一般化できるようにn個のハッシュを備える。
【００２３】
最終的なH4ハッシュ（ツリー階層の根の部分）は署名された値であって、コンテンツデータの公開が認可されたセキュアサーバーにおいて、公知または手頃な公開鍵署名法を使用することによって署名される。コンテンツのサイズは任意であっても、或いは任意でなくても良い。階層構造の値を演算するために、追加コンテンツブロックやハッシュ値がランダムなバイトとして当てがわれるようにしても良い。図２を参照して説明した技術は、ＤＶＤブロックに使用可能であり、或いは他のアプリケーションへと適用（拡張）することが可能である。
【００２４】
再度、図３を参照するに、本例ではハッシュブロック３０２は、３１個のH0ハッシュ／パディング３１０、８個のH1ハッシュ／パディング３１２、及び８個のH2ハッシュ／パディング３１４に細分される。
【００２５】
ディスクヘッダなどのヘッダ（図示せず）は、通常、32KBブロック３００に関連するブロックベースドメディアデバイスの最初のアクセスエリアに含まれることになる。一実施形態において、ヘッダに含まれた内容は、ブロックベースドメディアデバイス上の全ブロックに適用可能となる。これで殆どの目的に対し十分ではあるが、ヘッダは、先頭に付け加えたり、後ろに付け加えたり、さもなければデータのブロックに含められたりしてもよい。非限定的実施形態において、ヘッダはH4ハッシュとこれに関連するH3ハッシュを含んでいる（例えば、図２参照）。又、別の実施形態として、関連するH3を８個のH2ハッシュから導き出すことが出来るし、H3自体を提供する必要もないが、その際には全ブロックベースドデバイスからのデータアクセスが必要になるかもしれない。
【００２６】
非限定的実施形態において、ヘッダは、少なくとも最終的なハッシュ（例えばH4）、コンテンツ識別、及び任意の鍵を含む“チケット”と呼ばれる署名データ構造を含んでも良い。例えばこのチケットは、あくまで例であってこれに限定されないがＲＳＡなどの公開鍵署名法を使用するコンテンツ発行サーバーによって署名されるようにしても良い。非限定的実施形態では、チケットに、コンテンツに権利を付与する他の権利マネージメントデータや、別のライセンス供与サーバーによる署名を含ませるようにしても良い。ヘッダは更に、証明書チェーンや取消しリストなど、署名の有効化を補助する補助データ構造を含んでも良い。コンテンツに適用可能な権利を減らす或いは拡張するために、権利マネージメントライセンスは、代替手段によって供給された他の権利マネージメントライセンスと併せて使用されてもよい。
【００２７】
ヘッダに続き、ハッシュブロック３１０、３１２、３１４と３１個の1KBデータブロック３０４を挟んでも良い。図３の例では、１ブロックが32KBで、最初の1KBブロックはハッシュブロック３０２として留保される。一実施形態では、ハッシュブロック３０２は、ヘッダがプレロード（先行読み込み）されると仮定して、３１個の1KBデータブロック３０４を有効化するのに必要な全認証データを含んでも良い。３１個の1KBデータブロック３０４にはコンテンツを含ませても良い。如何なる適用可能な公知（又は手頃な）ハッシュアルゴリズムが使用されても良い。例えば、ハッシュサイズが２０バイトのＳＨＡ１であるならば十分であろう。
【００２８】
一実施形態では、総てのデータブロックが（例えば、ＡＥＳ暗号を使用する形で）、コンテンツのコピー防止を確実にするために暗号化される。別の実施形態としては、いくつかのデータブロックを暗号化しない場合もある。非限定的実施形態としては、ハッシュブロック３０２からスタートする形で、データが復号化される。ハッシュの復号化にあたっては、如何なる公知の、又は手頃な技術も使用可能である。例えば、一定の既知数を、ハッシュブロック３０２の始まりを復号化するために初期化ベクトルとして選択しても良いし、H2ハッシュの一部をデータブロック復号化用の初期化ベクトルとして使用しても良い。チケット有効化工程の副産物として復号化鍵を獲得しても良い（例えば図５参照）。
【００２９】
図４は、図１乃至図３を参照して上述した技術の実施に適するコンピュータ・システム４００を示している。コンピュータ・システム４００は、コンピュータ４０２、I/Oデバイス４０４、及びディスプレイデバイス４０６を含む。コンピュータ４０２は、プロセッサ４０８、通信インターフェース４１０、メモリ４１２、ディスプレイコントローラ４１４、不揮発性記憶装置４１６、及びI/Oコントローラ４１８を含む。コンピュータ４０２は、I/Oデバイス４０４やディスプレイデバイス４０６に接続する形でも、あるいはそれらを含む形でも良い。
【００３０】
コンピュータ４０２は、モデムやネットワークインターフェースを含んでもよい通信インターフェース４１０を介し、外部システムと接続する。通信インターフェース４１０は、コンピュータ・システム４００の一部かコンピュータ４０２の一部として考えることができる。通信インターフェース４１０は、アナログ・モデム、ISDNモデム、ケーブルモデム、トークン・リング・インタフェース、衛星通信インターフェース（例えば、“ダイレクトＰＣ”）、又は１つのコンピュータ・システムを他のコンピュータ・システムに接続する他のインターフェースのいずれでも良い。従来のコンピュータは通常、一種の通信インターフェースを備えるが、インターフェースを含まないコンピュータを作成することで、通信インターフェース４１０を厳密な意味で任意的なものとすることができる。
【００３１】
プロセッサ４０８は、それに限定されない一例として、インテル社のペンティアム（登録商標）マイクロプロセッサやモトローラ社のパワーＰＣマイクロプロセッサなどの従来マイクロプロセッサを具備しても良い。プロセッサ４０８は、総ての従来型コンピュータにとって重要な部品と言えるが、ここで説明した技術を実施するためには、適用可能な如何なる公知の（又は手頃な）プロセッサを使用することも可能である。メモリ４１２は、バス４２０によって、プロセッサ４０８に接続される。メモリ４１２（以下、“主記憶装置(primary memory)”と呼ぶこともある）は、ダイナミック・ランダムアクセス・メモリ（ＤＲＡＭ）を備えたり、またスタティック・ラム（ＳＲＡＭ）を備えたりすることも可能である。バス２２０は、プロセッサ４０８をメモリ４１２に接続したり、又不揮発性記憶装置４１６にも、ディスプレイコントローラ４１４にも、更にI/Oコントローラ４１８にも接続したりすることができる。
【００３２】
I/Oデバイス４０４は、キーボード、ディスクドライブ、プリンタ、スキャナ、及びマウスか他のポインティング・デバイスを含む他の入出力装置を含むことができる。説明のため、これらI/Oデバイスの少なくとも１つを、DVDプレーヤーのようなブロックベースドメディアデバイスと仮定する。ディスプレイコントローラ４１４は、公知の又は手頃な方法で、ディスプレイデバイス４０６上のディスプレイを制御しても良く、ディスプレイデバイス４０６は、例えば、ブラウン管（ＣＲＴ）だったり、液晶ディスプレイ（ＬＣＤ）だったりする。
【００３３】
ディスプレイコントローラ４１４とI/Oコントローラ４１８はデバイスドライバを具備しても良い。デバイスドライバは、ハードウェアデバイスとの相互作用を可能にするべく開発された特定のコンピュータ・ソフトウェアである。通常、これは、デバイスと通信するためのインターフェースを構成し、ハードウェアが接続されるバスや通信サブシステムを介し、デバイスへの命令送信及び／又はデバイスからのデータ受信を実行する一方、必要不可欠なものはOSとソフトウェアアプリケーションと相互作用する。
【００３４】
デバイスドライバは、OS特有でもあるハードウェア依存型コンピュータ・プログラムを含んでもよい。そのコンピュータ・プログラムにより、別のプログラム（通常OS、アプリケーションソフトウェアパッケージ、又はOSカーネル上で動くコンピュータ・プログラム）は、透過的にハードウェアデバイスと相互作用することができ、同コンピュータ・プログラムは通常、ニーズと調和した如何なる必要な非同期・時間依存型ハードウェアにも必要不可欠な割り込み処理を提供する。
【００３５】
往々にして不揮発性記憶装置４１６（以下、“補助記憶装置(secondary memory)”と呼ぶこともある）は、磁気ハードディスクだったり、光ディスクだったり、或いは大量データ用の他の種類の記憶装置だったりする。このデータのいくつかはしばしば、コンピュータ４０２でソフトウェアを実行している間に、ダイレクトメモリアクセス工程によってメモリ４１２に書き込まれる。不揮発性記憶装置４１６は、ブロックベースドメディアデバイスを含むものでも良い。“機械可読メディア”や“コンピュータ可読メディア”という用語は、プロセッサ４０８によってアクセス可能であって、データ信号を符号化する搬送波を包含する如何なる公知の（又は手頃な）記憶装置をも含んでいる。
【００３６】
コンピュータ・システム４００は、異なったアーキテクチャを持っている多くの実行可能なコンピュータ・システムの一例である。例えば、インテルマイクロプロセッサをベースとするパーソナルコンピュータは往々にして複数のバスを有し、その１つは周辺機器へのI/Oバスであったり、プロセッサ４０８とメモリ４１２を直接接続するもの（しばしば“メモリバス”と呼ばれる）であったりする。これらのバスは、バスプロトコルが異なることによって必要とされる如何なる変換(translation)を実行できるブリッジコンポーネントを介して接続される。
【００３７】
ネットワーク・コンピュータは、ここで提供した教示に関連して使用可能な別のタイプのコンピュータ・システムである。通常、ネットワーク・コンピュータはハードディスクや他の大容量記憶装置を備えておらず、実行可能プログラムは、プロセッサ４０８による実行のために、ネットワーク接続からメモリ４１２に取り込まれる。当該技術では既知のウェブテレビシステムも又、１つのコンピュータ・システムと考えることもできるが、ある入力や出力装置のように図４に示した特徴の幾つかを欠く可能性がある。通常、一般的なコンピュータ・システムは、少なくともプロセッサ、メモリ、メモリをプロセッサに接続するバスを具備することになる。
【００３８】
オペレーティングシステム（OS）でコンピュータ・システム４００を制御しても良い。OSは、全部ではないが殆どのコンピュータ・システムに使用されるソフトウェアプログラムであって、コンピュータのハードウェア及びソフトウェア・リソースを管理している。通常、OSは、メモリを制御して割り当てをしたり、システムの要求に優先順位を付けたり、入出力装置を制御したり、ネットワーキングを補助したり、ファイルを管理するといったような基本タスクを実行するものである。パーソナルコンピュータ用オペレーティングシステムの例としては、マイクロソフト社のウインドウズ（登録商標）、リナックス、マックOS（登録商標）などがある。OSとアプリケーション・ソフトウエアとの間の線引きは往々にしてかなり難しい。幸いにも、何らかのリーズナブルな線引きで十分であるため、本願で説明した技術を理解するのにこの線引きは不要である。
【００３９】
最も低いレベルのOSとしては、その（OSの）カーネルであっても良い。通常、カーネルは、システムブートや、スタートアップする際にメモリに取り込まれるソフトウェアの第１の層(first layer)である。カーネルにより、他のシステムやアプリケーション・プログラムに対する様々な共通コアサービスへのアクセスを提供する。
【００４０】
ここに使用されたように、コンピュータメモリ中のデータ・ビットにおける操作のアルゴリズム的記述と象徴(symbolic representations)は、当業者に対し最も効果的に技術を伝えるものと思われる。アルゴリズムという用語は、ここで使用するとき、また一般に使用されるとき、所望の結果を導き出す動作 (operations)の首尾一貫したシーケンス（self-consistent sequence）と考えられる。この動作は、物理量の物理的な操作(manipulations)を必要とするものである。必ずしも必要ではないが、通常、こうした量は、格納、転送、結合、比較、及び他の操作を行うことができる電気、または磁気の信号の形を取る。時には、主に一般的な使用のために、こうした信号をビット(bits)、値(values)、要素(elements)、記号(symbols)、文字(characters)、項(terms)、数字(numbers)などと呼ぶのが便利であることがわかっている。
【００４１】
しかしながら、これら、及びこれらと同様の用語はすべて、適切な物理量に関連付けられ、単にこうした量に適用される手頃なラベル(labels)にすぎないことを心に留めておくべきである。特に明記しない限り、または下記の記述から明らかであるように、“処理する(processing)”、“演算する(computing)”、“計算する(calculating)”、“決定する(determining)”、“表示する(displaying)”などの用語は、コンピュータ・システムのレジスタおよびメモリ内の物理的な（電子）量として表されるデータを操作し、コンピュータ・システムのメモリまたはレジスタ、または他のこうした情報記憶装置、送信装置または表示装置内の同じように物理（電子）量として表される他のデータに変換するコンピュータの動作および処理(process)を指す。
【００４２】
ここで説明した技術を実施するための装置は、要求された目的のためにそれ専用に構成しても良く、又コンピュータに格納されたコンピュータ・プログラムによって選択的に起動(activated)されたり再構成(reconfigured)されたりする汎用コンピュータから成るものでも良い。そのようなコンピュータ・プログラムは、それらに限定されるものではないが例えば、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、EPROM、EEPROM、磁気又は光学カード、フレキシブルディスクを含む如何なるタイプのディスク、光ディスク、CD-ROM、DVD、光磁気ディスク、或いは電子的な指示(instructions)を格納するのに適した如何なる公知の（又は手頃な）の媒体のような、コンピュータ可読記憶媒体に格納されても良い。
【００４３】
ここに提示されたアルゴリズムとディスプレイは本来、如何なる特定コンピュータ・アーキテクチャにも関連するものではない。この技術は、高いレベル（例えば、C/C++）であろうと低レベル（例えば、アセンブリ言語）だろうと、又インタープリタ型（例えば、Perl）だろうと、コンパイラ型（例えば、C/C++）だろうと、バイトコード（例えば、Java（登録商標））からコンパイルされるジャストインタイム（JIT）であろうと、如何なる公知の（又は手頃な）プログラミング言語を使用して実施されても良い。どんな公知の（又は手頃な）コンピュータでも、アーキテクチャに関係なく、コンパイルされた機械コードか、さもなければ何らかの言語からコンピュータ・アーキテクチャと互換性がある機械コードへとアセンブルされた機械コードを実行することが可能でなければならない。
【００４４】
図５は、図１乃至図３を参照して上述した技術を実施するのに適していたセキュアシステム５００の一例を示している。代表的なセキュアシステム５００は、ゲーム機、メディアプレーヤー、埋め込み型(embedded)セキュアデバイス、セキュアプロセッサ付き“従来型”PC、或いはセキュアプロセッサを備える他のコンピュータ・システムを備えても良い。
【００４５】
図５の例においてセキュアシステム５００は、セキュアプロセッサ５０２、OS５０４、ブロックベースドメディアドライバ５０６、ブロックベースドメディアデバイス５０８、プロテクト・メモリ５１０、及びチケットサービス５１２を含む。図５の例ではOS５０４は、鍵ストア５１６、暗号化/復号化エンジン５１７、及びセキュリティAPI５１８を順に含むセキュリティカーネル５１４を有する。上述したこれら部品の１つ又はそれ以上、或いはその一部を、プロテクト・メモリ５１０又は保護されていないメモリ（図示せず）に属させるようにしても良いことを留意すべきである。
【００４６】
さらに留意すべきは、慣例だけによって、セキュリティカーネル５１４が、OS５０４に属するように表現されていることである。実際にOS５０４の一部であってもなくても良く、OSの外側に存在することも、或いはOSを含まないシステム上に存在することも可能である。説明を簡単にする目的で、OS５０４は認証可能であることが前提である。実施形態では、ブロックベースドメディアドライバ５０６、及び／又は、チケットサービス５１２は、OS５０４の一部であっても良い。認証付きのブロックベースドメディアドライバ５０６とチケットサービス５１２を読み込むこと(loading)が、セキュリティを向上できるという理由で、これは望ましいかもしれない。従って、そのような実施形態では、OS５０４は認証付きで読み込まれ、ブロックベースドメディアドライバ５０６とチケットサービス５１２を含むことになる。
【００４７】
説明の簡略化のために、プロテクト・メモリは単一メモリとして示される。しかしながら、このプロテクト・メモリは、保護された主記憶装置、保護された補助記憶装置、及び／又は、シークレットメモリを含んでも良い。メモリが保護されるのを確実とするためには、公知の（又は手頃な）機構が適所にあることが前提である。主記憶装置と補助記憶装置との間、及び／又は、揮発性記憶装置と不揮発性記憶装置との間のインタープレイ(interplay)は、公知であるため、様々な種類のメモリと記憶装置の間の区別は図５に関しては示されていない。
【００４８】
チケットサービス５１２は、例えば“デジタルライセンス有効化サービス”として考えられても良く、また非限定的な実施形態では、ライセンス有効化に関連する公知の（又は手頃な）手順を含んでもよい。例えば、チケットサービス５１２は、デジタルライセンスを有効にするための手順、PKI有効化手順などを含んでも良い。図５の例では、チケットサービス５１２は、ブロックベースドメディアデバイス５０８上でチケットを有効化することができる。この動作において、ブロックベースドメディアドライバ５０６は、ブロックベースドメディアデバイス５０８からチケットを獲得する。次いで、ブロックベースドメディアドライバ５０６は、チケットサービス５１２へのチケットを供給し、同サービスはチケット有効化を進行させる。チケットが有効である場合、ブロックベースドメディアドライバ５０６は、チケットに関連したブロックを復号化することが許される。
【００４９】
一実施形態では、セキュリティカーネル５１４が、起動時点において読み込み(loaded)されてもよい。別の実施形態では、セキュリティカーネルの一部が、起動時点において読み込みされ、残りが後で読み込みされても良い。この技術の一例は、Srinivasanらによって、2003年2月7日に出願された“信頼性や下位互換性のあるプロセッサ、及びその上でのセキュアソフトウェア実行”というタイトルの出願番号：１０／３６０，８２７号に記載され、同技術がここで援用される。セキュアな方法（技術的に安全性が保証された方法、in a secure manner）で、セキュリティカーネル５１４を読み込みするべく、如何なる公知の（又は手頃な）技術も使用可能である。
【００５０】
鍵ストア５１６は、鍵のための格納場所群からなる。鍵を格納するのに使用されるデータ構造は重要な意味をもつものではないが、鍵ストア５１６は、鍵の一配列と思われても良い。鍵を格納するために、適用可能な如何なる公知の（又は、手頃な）構造も使用可能である。非限定的な実施形態では、鍵ストア５１６は、静的な(static)鍵を以て初期化されるが、可変鍵(variable keys)は初期化されない（或いは、セキュアでない値に初期化される）。例えば、幾つかの鍵ストア位置(key store locations)は、認証されたセキュリティカーネル５１４の読み込み(loading)の一部としての信頼値（例えば信頼ルート鍵）で予備充填(pre-filled)される。
【００５１】
一実施形態において、暗号化/復号化エンジン５１７は、暗号化と復号化の両方が可能である。例えば、かかる動作において、アプリケーションは、セキュリティAPI５１８に、アプリケーションが暗号化に使用できるというキーハンドルを要求するかもしれない。暗号化/復号化エンジン５１７を、キーハンドルを使用してデータを暗号化するのに使用しても良い。好都合なことには、セキュリティAPI５１８は、キーハンドルを平文で提供するが、鍵そのものは決してセキュリティカーネル５１４から離れることはない。
【００５２】
セキュリティAPI５１８は、鍵を明らかにすることなく（すなわち、鍵がセキュリティカーネル５１４を離れないか、或いは暗号化される場合にだけに限って鍵がセキュリティカーネル５１４を去るような状態で）、鍵ストア５１６内の鍵を使用した動作を実行することができる。セキュリティAPI５１８は、鍵ストア５１６で鍵（そして潜在的には、他のセキュリティ材料）を作成(create)し、投入(populate)し、使用するためのサービスを含んでも良い。また、一実施形態では、セキュリティAPI５１８は、また、秘密鍵とデバイスプライベート鍵を含む、内部の秘密と不揮発性データへのアクセスを与える。実装の形態によっては、セキュリティAPI５１８は、ハードウェア加速を使用することでAES及びSHAオペレ−ションをサポートするようにしても良い。
【００５３】
図５の例では、ブロックベースドメディアドライバ５０６は、ブロックベースドメディアデバイス５０８からの読み出しを行いながら、以下のセキュリティオペレーションを実行するように構成しても良い。
１）秘密鍵を使用して、ブロックベースドメディアデバイス５０８を復号化すること、及び
２）ブロックベースドメディアデバイス５０８上の認証データを使用して、ブロックベースドメディアデバイス５０８上のコンテンツを認証すること（認証が失敗した場合、読み出しは失敗する）
【００５４】
図５の例では、これらのセキュリティオペレーションを実行するために、ブロックベースドメディアドライバ５０６は、システム５００内の他のセキュアサービス、例えばチケットサービス５１２やセキュリティAPI５１８などを利用しても良い。一実施形態では、これらモジュールの夫々が、システムセキュリティのための個々の実行スペースにおいて実行する。データブロックを有効化するために、ブロックベースドメディアドライバ５０６は、データブロック・ヘッダを読み出し、ヘッダのデータを使ってチケットを有効にするためにチケットサービス５１２を用いる。ブロック復号化をサポートするために、チケットは、暗号化された鍵を含んでも良い。チケットサービス５１２は、セキュリティカーネル５１４（例えば、暗号化/復号化エンジン５１７）におけるサービスを利用して、鍵を復号化する。
【００５５】
一実施形態では、暗号化/復号化エンジン５１７は、この復号化を実行するために、鍵ストア５１８からの秘密共通鍵を使用する。別の実施形態では、チケットサービス５１２は、フラッシュかネットワーク（図示せず）から得られたデバイス個別チケット(device personalized ticket)を使用して、コンテンツに対する幾つかの権利を有効にして、その後に鍵を戻すことも可能である。いずれにしても、このプロセスは、ブロックベースドメディアドライバ５０６に戻り、ブロックを復号化する際に使用する鍵にリファレンスを与える。この鍵リファレンスは、ブロックベースドメディアドライバ５０６によって使用され、鍵に関連するブロックを復号化するセキュリティAPI５１６に次の呼び出しをする。
【００５６】
復号化の後に、ブロックベースドメディアドライバ５０６は、セキュリティAPI５１６（又は、ハッシュ演算エンジンへの他のインターフェース）に対し呼び出しをかけ、チケットに関連する階層的ハッシュツリーを有効にする（例えば、図３参照）。セキュリティAPI５１６は、チケットの中にあるものに対するルートハッシュを有効化する。有効化が成功したことを前提に、チケットに関連するコンテンツは使用可能なものにされる。非限定的な実施形態では、復号化と認証の順番はさほど重要でなく、入れ替えできるものである。
【００５７】
矢印５２０〜５３６を以て、システム５００のデータフローの例が例示を目的として供される。ブロックベースドメディアドライバ５０６においてブロック・ヘッダを受けることは、ブロックベースドメディアデバイス５０８からブロックベースドメディアドライバ５０６へのヘッダアクセス矢印５２０によって表わされている。データブロック・ヘッダは恐らくは、アクセスして読み出し可能となるために矢印５２０は双方向となる。
【００５８】
チケットを含むデータブロック・ヘッダからチケットサービス５１２へのデータ送信は、認証データ矢印５２２によって表わされている。チケットは、暗号化された鍵を含んでも良い。鍵の復号化のためにセキュリティAPI５１６に要求を送ることは、鍵復号化要求矢印５２４によって表されている。現在鍵ストア５１８に格納されている復号化された鍵へのリファレンスの戻しは、鍵へのリファレンス矢印５２６によって表わされる。チケットの有効化に成功した後、チケットサービスは、ブロック復号化の際にドライバが使用した鍵へのリファレンスと共に、チケット有効化データをブロックベースドメディアドライバ５０６に送ることになる。チケットサービス５１２からブロックベースドメディアドライバ５０６へのデータ送りは、チケット有効化矢印５２８として示されている。
【００５９】
データブロックアクセス矢印５３０は、ブロックベースドメディアドライバ５０６によるブロックベースドメディアデバイス５０８からのブロック読み出しを示している。データアクセスは、ヘッダ（５２０）の受信と同時に行っても、或いは時を一致させずに行っても良い。アクセスされたブロックは、チケット有効化データ（５２８）を使用して復号化され、ブロック復号化要求矢印５３２はかかる要求を表している。ハッシュツリー有効化矢印５３４は、１ブロックのコンテンツのその後の有効化を表している。
【００６０】
一実施形態として、あるレベルのハッシュ（例えば、図２のレベルH3参照）をヘッダに供給することも可能である。そのような実施形態では、第１ハッシュツリー有効化シーケンスは、ハッシュの計算や、このハッシュのヘッダに提供された関連値との比較を含んでも良い。別の実施形態では、あるハッシュ演算時間を節約出来るかもしれない将来のレファレンスのために(for future reference)、階層的ハッシュツリーの部分値が、ハッシュされてもよい。
【００６１】
図６Ａ及び図６Ｂは、セキュアなブロックベースドメディアアクセスの方法の一例としてのフローチャート６００を示している。この方法、及び他の方法は、連続的に並べられたモジュールの形で表現される。しかしながら、これらの方法における各モジュールは、並べ替えされたり、並列実行のために適当に並べられたりしても良い。図６Ａの例において、フローチャート６００は、モジュール６０２でスタートし、ここではブロックベースドメディアヘッダが読み込まれる。図６Ａの例において、フローチャート６００は、モジュール６０４に進み、ここでチケットの有効化が行われ、復号鍵へのリファレンスが得られる。
【００６２】
図６Ａの例で、フローチャート６００は、決定ポイント６０６に進み、チケットが有効であるか否かが判定される。チケットが有効でない場合（６０６−Ｎの場合）、プロセスは中止になり、フローチャート６００は終了することになる。他方、チケットが有効である場合（６０６−Ｙの場合）、フローチャート６００は、モジュール６０８に進み、H3ハッシュのハッシュを、チケットの中にあるルートハッシュ値と比較する。この比較は例えばセキュリティー・サービスで実行しても良い。
【００６３】
図６Ａの例で、フローチャート６００は、決定ポイント６１０に進み、チケットが有効であるか否かが判定される。その比較（モジュール６０８）で一致している場合には、チケットが有効であると仮定される。チケットが有効でないと判定されたならば（６１０−Ｎの場合）、プロセスは中止になり、フローチャート６００は終了する。他方、チケットが有効である場合（６１０−Ｙの場合）、フローチャート６００は、モジュール６１２に進み、H3ハッシュ群のH3ハッシュ値が格納され、読み出し要求(read request)が待機状態にされる。H3ハッシュ値は、例えばセキュアDRAMに格納されても良い。
【００６４】
図６Ａの例では、フローチャート６００は、モジュール６１４に進み、ここではコンテンツを解読するための鍵へのリファレンスが獲得される。コンテンツ解読のための鍵へのリファレンスは、リファレンス獲得のためチケットサービス（ヘッダ情報を伴う）に呼び出しをかけることで獲得するようにしても良い。図６Ａの例では、フローチャート６００は、モジュール６１６に進み、読み出し要求のハッシュサブブロックとデータサブブロックの所在確認が行われる(located)。図６Ａの例では、フローチャート６００は、更にモジュール６１８に進み、前記ハッシュサブブロックとデータサブブロックが復号化される。図６Ｂの例では、フローチャート６００は、モジュール６２０に進み、ここでデータサブブロックのハッシュが計算される。
【００６５】
図６Ｂの例では、フローチャート６００は、モジュール６２２に進み、データサブブロックのハッシュがレベルH0ハッシュ群の対応するH0ハッシュ値と比較される（例えば、図３参照）。図６Ｂの例では、フローチャート６００は、決定ポイント６２４に進み、ここで上記比較が有効な結果(valid result)をもたらしたか否かが判定される。比較結果が有効でない場合（モジュール６２４−Ｎ）、その時、フローチャート６００ではブロックベースドメディアデバイスからの読み出し要求を中止する。他方、上記比較結果が有効である場合（モジュール６２４−Ｙ）、フローチャート６００は、モジュール６２６に進み、レベルH0のハッシュ値を含む、H0ハッシュ群のハッシュH1’が計算される。
【００６６】
図６Ｂの例では、フローチャート６００は、モジュール６２８に進み、H1’がレベルH1ハッシュ群の対応するH1ハッシュ値と比較される（例えば、図３参照）。図６Ｂの例では、フローチャート６００は、決定ポイント６３０に進み、ここで上記比較が有効な結果をもたらしたか否かが判定される。比較結果が有効でない場合（モジュール６３０−Ｎ）、その時、フローチャート６００ではブロックベースドメディアデバイスからの読み出し要求を中止する。他方、上記比較結果が有効である場合（モジュール６３０−Ｙ）、フローチャート６００は、モジュール６３２に進み、レベルH1のハッシュ値を含む、H1ハッシュ群のハッシュH2’が計算される。
【００６７】
図６Ｂの例では、フローチャート６００は、モジュール６３４に進み、H2’がレベルH2ハッシュ群の対応するH2ハッシュ値と比較される（例えば、図３参照）。図６Ｂの例では、フローチャート６００は、決定ポイント６３６に進み、ここで上記比較が有効な結果をもたらしたか否かが判定される。比較結果が有効でない場合（モジュール６３６−Ｎ）、その時、フローチャート６００ではブロックベースドメディアデバイスからの読み出し要求を中止する。他方、上記比較結果が有効である場合（モジュール６３６−Ｙ）、フローチャート６００は、モジュール６３８に進み、レベルH2のハッシュ値を含む、H2ハッシュ群のハッシュH3’が計算される。
【００６８】
図６Ｂの例では、フローチャート６００は、モジュール６４０に進み、H3’が対応して格納されたH3ハッシュ値（６１２）と比較される（例えば、図３参照）。図６Ｂの例では、フローチャート６００は、決定ポイント６４２に進み、ここで上記比較が有効な結果をもたらしたか否かが判定される。比較結果が有効でない場合（モジュール６４２−Ｎ）、その時、フローチャート６００ではブロックベースドメディアデバイスからの読み出し要求を中止する。他方、上記比較結果が有効である場合（モジュール６４２−Ｙ）、フローチャート６００は、モジュール６４４に進み、ブロック読み出し要求が果たされる。
【００６９】
図７Ａ、７Ｂ及び図７Ｃは、セキュアなブロックベースドメディアアクセスの別の方法を説明するためのフローチャート７００を示している。図７Ａの例では、フローチャート７００は、ブロックベースドメディアデバイスのヘッダにアクセスするモジュール７０２でスタートする。次に、フローチャート７００は、モジュール７０４に進み、ヘッダに含まれるデータ構造を認証する。それに限定されない例としてデータ構造は、チケットやイーチケット(eTicket)、或いは実際に、ここに記載する意図した目的のために機能する如何なる他のデータ構造でも良い。
【００７０】
図７Ａの例で、フローチャート７００は、モジュール７０６に進み、ヘッダに含まれるハッシュ値群をセキュアに格納する(技術的に安全性が保証された状態で格納する、securely storing)。それに限定されない例として、これらのハッシュ値は、図２のH3ハッシュと同様なものでも良い。如何なる数のハッシュ値が、ヘッダ（例えば、H0、Hl、H2、H3、H4）に供されても良い。しかしながら、ハッシュサブブロックに供されないヘッダだけを含むことが望ましいかもしれない（例えば図３参照）。
【００７１】
図７Ａの例で、フローチャート７００は、モジュール７０８に進み、将来のレファレンスのために(for future reference)、階層的ハッシュツリーをキャッシュする(caching)。少なくとも１つの実施形態では、階層的ハッシュツリーをキャッシュするということは、データブロック検証プロセスの間の速度を幾分改善できる結果をもたらすことができる。しかしながら、階層的ハッシュツリーをキャッシュせずに続行する理由が存在するかもしれず、これはこの技術の有効性を損なわないはずである。
【００７２】
図７Ａの例で、フローチャート７００は、モジュール７１０に進み、データ構造から、階層的ハッシュツリーの第１のルートハッシュを獲得する。データ構造はハッシュ値群とは独立して認証（７０４）されているために、結果としては更なるセキュリティをもたらすことができる。
【００７３】
図７Ａの例で、フローチャート７００は、モジュール７１２に進み、ハッシュ値群から第２のルートハッシュを演算する。このハッシュ値はセキュアなもの（技術的に安全性が保証されたもの）かどうかわからないが、ヘッダがブロックベースドメディアデバイスからアクセスされているため、それらは恐らくはブロックベースドメディアデバイスからのものである。
【００７４】
図７Ａの例で、フローチャート７００は、モジュール７１４に進み、第１のルートハッシュを第２のルートハッシュと比較する。なお、データ構造に含まれていた第１のルートハッシュは、既に認証されており（７０４）、第２のルートハッシュはブロックベースドメディアデバイスのヘッダに供されたハッシュ群から導かれたものである。
【００７５】
図７Ａの例で、フローチャート７００は、決定ポイント７１６へと進み、第１のルートハッシュと第２のルートハッシュが一致しているか否かが判定される。第１のルートハッシュと第２のルートハッシュが一致していない場合（モジュール７１６−Ｎ）、その時、ヘッダが拒絶される（さらにフローチャート７００も終了する）。他方、第１のルートハッシュと第２のルートハッシュが一致している場合（モジュール７１６−Ｙ）、フローチャート７００は、任意的なモジュール７１８に進み、ヘッダ以外のソースからの権利マネージメントチケットを有効にする。
【００７６】
図７Ｂの例で、特定の実装形態には可能でないかもしれないし、或いはこの付加的レベルのセキュリティが不要であると思われる可能性があるため、モジュール７１８は任意で行ってもよいし行わなくてもよい。ヘッダ以外のソースからの権利マネージメントチケットが使用されているなら、その際、権利マネージメントチケット使用方法は、モジュール７０４、７１０、７１４に関して説明されたものと同様である。説明のために、この任意のモジュールが使用されるなら、有効化(validation)が成功した状態にある（それ故、ヘッダが拒絶されない）と推測される。
【００７７】
図７Ｂの例で、フローチャート７００は、モジュール７２０に進み、ここでデータ構造から暗号化された鍵を入手する。最初、そのデータ構造が認証され（７０４）、鍵がデータ構造から抽出される際に暗号化されるため、この鍵は特にセキュアなもの（技術的に安全性が保証されたもの）である。
【００７８】
図７Ｂの例で、フローチャート７００は、モジュール７２２に進み、ここで暗号化された鍵をセキュアに（技術的に安全性が保証された状態で）復号化する。“セキュアに復号化する”ということで、鍵がセキュアカーネルで復号化されることが前提となる。セキュアカーネルのそれに整合できるどんなセキュリティレベルも適当なものとなるであろう。しかしながら、セキュアカーネルによって提供されたセキュリティと同等であるなら、そのような多くのセキュリティ機構は、単に、何か他のものとして改名されたセキュアカーネルであっても良い。それにもかかわらず、十分にセキュアな機構が公知又は手頃なものであるならば、ここに説明された技術が適用可能であるかもしれない。
【００７９】
図７Ｂの例で、フローチャート７００は、モジュール７２４に進み、鍵をセキュアに格納する。“セキュアに格納すること”ということで、鍵は、セキュアカーネルに格納されるか、又はセキュアプロセッサによってアクセスされるセキュアカーネルに関連するメモリに格納されることが前提となる。又、セキュアカーネルのそれに整合できるどんなセキュリティレベルも適当なものとなるであろう。
【００８０】
図７Ｂの例で、フローチャート７００は、モジュール７２６に進み、鍵へのリファレンスを平文で提供する。それに限定されない例により、ブロックベースドメディアドライバは鍵へのリファレンスを受けるようにしても良い。その際、ブロックベースドメディアドライバは、鍵へのリファレンスを、例えば鍵アクセスのためにリファレンスを使用できるセキュアカーネルに戻すように発信しても良い。このようにして、鍵はセキュアカーネルに残ることができ、リファレンスだけが平文状態になる。
【００８１】
図７Ｂの例で、フローチャート７００は、モジュール７２８に進み、セキュア復号化エンジンに鍵のリファレンスを供する。“セキュア復号化エンジンであること”ということで、復号化エンジンはセキュアカーネルの一部、または同等の物であることが前提となる。これにより鍵の、平文状態での使用さえも回避される。
【００８２】
図７Ｂの例で、フローチャート７００は、モジュール７３０に進み、ここでデータブロックを復号化する。データブロックは、セキュアに復号化される。その後、フローチャート７００は、任意でモジュール７３２に進み、データブロックのサブブロックが復号化される。このレベルのセキュリティが不必要なものかどうか分らないし、システムの性能をいたずらに低減させるかもしれないので（多分、僅かだが）、この処理は任意で行っても良いし行わなくても良い。
【００８３】
図７Ｃの例では、フローチャート７００は、モジュール７３４に進み、サブブロックから認証データを読み込み、続くモジュール７３６では、この認証データにおいて、階層的ハッシュツリーの第１のレベルに関連する第１のハッシュ値群を識別する(identifying)。第１のレベルは図２のH0に対応するかもしれない。レベルの数は本例方法の一部でない実施詳細である。
【００８４】
図７Ｃの例で、フローチャート７００は、モジュール７３８に進み、第１ハッシュ値を決定するべくデータブロックの暗号学的ハッシュを演算し、続くモジュール７４０では、第１ハッシュ値を、第１のハッシュ値群の対応値と比較する。
【００８５】
図７Ｃの例で、フローチャート７００は、決定ポイント７４２に進み、第１ハッシュ値と、第１のハッシュ値群の対応値とが一致しているか否か判定される。第１ハッシュ値と、第１のハッシュ値群の対応値とが一致していない場合（モジュール７４２−Ｎ）、データブロック読み出し要求は拒絶される（そして、フローチャート７００は終了する）。他方、第１ハッシュ値と、第１のハッシュ値群の対応値とが一致している場合（モジュール７４２−Ｙ）、その際、フローチャート７００は、モジュール７４４に進み、ここで適宜ハッシュを演算して、比較する。演算と比較の反復回数は恐らく階層的ハッシュツリーのレベル数に依存し、それは実装の形態によって変化する。
【００８６】
図７Ｃの例で、フローチャート７００は、決定ポイント７４６に進み、ハッシュ比較のすべてが一致という結果になるか否かが判定される。ハッシュ比較のすべてが一致という結果にならないと判定された場合（モジュール７４６−Ｎ）、データブロック読み出し要求は拒絶される（そして、フローチャート７００は終了する）。他方、ハッシュ比較のすべてが一致という結果になったと判定された場合（モジュール７４６−Ｙ）、データブロックが戻される（そして、フローチャート７００は終了する）。推定するに、アクセス前にこれを参照した当業者には明白であるように、これらモジュールの幾つかは、その後のデータブロックアクセスのために繰り返される必要はないだろう。
【００８７】
ここで使用されたように、用語“コンテンツ”は、メモリに格納可能な如何なるデータをも広く含むことを意図する。
【００８８】
ここで使用されたように、用語“実施形態”は、それに限定されない一例として説明を行うための実施例を意味している。
【００８９】
当業者であれば前述した実施例と実施形態は、代表的なものであり、本発明の範囲を限定するものでないことが理解されるであろう。当業者が明細書を考慮し、図面を検討したときに自明な置き換え、増強、均等物やそれらへの改良が、本発明の要旨と範囲に含まれることを意図している。したがって、添付された特許請求の範囲は、本発明の要旨と範囲内にあるこのような総ての変更、置き換え、均等物を含むことを意図している。
【符号の説明】
【００９０】
１００ 二分木構造
２００ 非二分木構造
３００ 32KBブロック
３０２ ハッシュブロック
３０４ 1KBデータブロック
３１０ H0ハッシュ／パディング
３１２ H1ハッシュ／パディング
３１４ H2ハッシュ／パディング
４００ コンピュータ・システム
４０２ コンピュータ
４０４ I/Oデバイス
４０６ ディスプレイデバイス
４０８ プロセッサ
４１０ 通信インターフェース
４１２ メモリ
４１４ ディスプレイコントローラ
４１６ 不揮発性記憶装置
４１８ I/Oコントローラ
５００ セキュアシステム
５０２ セキュアプロセッサ
５０４ OS（オペレーティングシステム）
５０６ ブロックベースドメディアドライバ
５０８ ブロックベースドメディアデバイス
５１０ プロテクト・メモリ
５１２ チケットサービス
５１４ セキュリティカーネル
５１６ 鍵ストア
５１７ 暗号化/復号化エンジン
５１８ セキュリティAPI
５２０ ヘッダアクセス矢印
５２２ 認証データ矢印
５２４ 鍵復号化要求矢印
５２６ 鍵へのリファレンス矢印
５２８ チケット有効化矢印
５３０ データブロックアクセス矢印
５３２ ブロック復号化要求矢印
５３４ ハッシュツリー有効化矢印
【技術分野】
【０００１】
今や、認証やその他のセキュリティ問題は、理論上及び実用上、広範囲の研究・開発の分野となっている。１つの分野は、ＤＶＤまたはそれに匹敵するテクノロジーでのデータの認証であり、それはＣＤや新しいＤＶＤテクノロジーを含むかは不明だが、ＤＶＤテクノロジー間の類似性ゆえに通常ＤＶＤテクノロジーの全域に適用可能なものとなっている。ＤＶＤやＣＤ、更にその他の自由に配給可能なメディアディスクを以て、その認証は特に強固でなければならない（例えば、暗号法の使用）。
【背景技術】
【０００２】
ディスクベースのメディアは通常、ブロックベースドデバイスである。それ故、ブロックデータへのアクセス時間や使用されるどんな暗号アルゴリズムの演算時間も、ディスクベースのメディアを使用するシステムの仕様を満足しなければならない。更に、コンテンツは秘密保持のためにしばしば暗号化される場合がある。また、セキュアデバイスの秘密保持やディスクベース・メディアのための認証技術に対するその他の考慮すべき事項には、その技術が読取専用媒体をサポートすべきこと、（各ディスクに特注又は固有のデータを要求せずに）ディスクの大量生産をサポートすべきこと、そして認証のためにディスク上に格納される付加データは妥当なオーバーヘッドを課すだけであるべきことが含まれる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
これらの要求事項を満たすべく幾つかの取り組みが提案されたが、秘密保持や認証技術における多くのソリューションと同様に、そこには改善の余地がある。例えば、公開鍵暗号に基づいたブロック署名（例えば、ＲＳＡ署名）を付けることも可能だろうが、読み込まれるデータのあらゆるブロックはＲＳＡ照合演算が必要となるために、この取り組みは比較的遅い処理となる。ＲＳＡは、公開鍵暗号化のためのアルゴリズムである。それは、暗号化と同様に署名に適切と思われた最初のアルゴリズムであった。ＲＳＡは十分に長い鍵があたえられ、セキュアである（技術的に安全性が保証された）と思われている。更に、比較的遅いことに加えて、ブロック毎に行われるＲＳＡ署名のサイズは比較的高いオーバーヘッドを課すことにもなるであろう。
【０００４】
別の例としては、ディスクのカスタム防護エリアに書き込まれたブロック毎にＳＨＡハッシュ（又は、その同等の物）を付けることも可能であるが、これはカスタムディスクの製造が必要となる。更に別の例として、各ブロックに対しＨＭＡＣ（又は同等の物）などの秘密鍵ベースのメッセージ認証コードを付けることも可能だろうが、この場合、総てのディスクに、ＨＭＡＣが同じでなければならず、これにより単一の秘密鍵機構となり、所望のセキュリティレベルを提供できない可能性がある。別の例としては、階層のメンバーを読み込むために、ブロックアクセス毎にブロックデバイスの複数のシーク(multiple seeks)が必要となる階層的署名アプローチを使用することも可能だろうが、この処理は待ち時間が長くなってしまう可能性がある。
【０００５】
上述したこれら関連技術の例や制限事項は、あくまで説明に役立つものとして例証したものであって排他的ではない。関連技術の他の制限事項は、当該技術者が本願明細書を読み、図面を検討することにより明らかになるであろう。
【課題を解決するための手段】
【０００６】
以下の実施形態とその特徴は、あくまで例証的であって範囲を制限しないことを意図したシステム、ツール、および方法に関連して記載、図示される。種々の実施形態では、上述した問題の１つ又はそれ以上が低減又は解消され、一方では他の実施形態がその他の改善に向けられる。
【０００７】
ブロックベースドメディアのセキュリティと認証のための技術は、保護鍵の使用を含み、認証と暗号プリミティブを提供する。本技術に従ったシステムは、保護鍵付きのセキュリティカーネルを有するセキュアデバイスを含んでも良い。ディスクドライブ・セキュリティ機構は、データ認証や秘密性をサポートしたり、更にセキュリティカーネルやチケットサービス・モジュール（例えば、フラッシュのような他の記憶装置によって使用されたり、これを使用しない共有サービス）を用いたチケット有効化をサポートしても良い。実装の形態によっては、セキュリティカーネル、ディスクドライブ・セキュリティ機構、及びチケットサービス・モジュールは、３つの異なった実行空間で動作する可能性もあり、それに非限定的な例として、例えば光学ディスクを含む様々な入出力・記憶装置により一般的に使用可能である。
【０００８】
非限定的な実施形態では、ブロックベースドメディアは読み取り専用であるが、その技術は追記型（ＷＯＲＭ）、書き込み可能型、或いは他のブロックベースドメディアなどに適用可能であるかもしれない。またその技術は、他の記憶媒体、暗号鍵を引き出すための代替法を導く他のライセンシング機構、及び／又は他の移送メディア（例えば、インターネットのパケットベースのダウンロード）に適用可能であるかもしれない。
【図面の簡単な説明】
【０００９】
本発明の実施形態を図面に示す。しかしながら、ここに示した実施形態と図面は、本発明を制限するものというよりむしろ説明するためのものであって、本発明の例を提供するものである。
【図１】階層的ハッシュ技術に関連する二分木構造の例を示す図である。
【図２】階層的ハッシュ技術に関連する非二分木構造の例を示す図である。
【図３】32KBブロックの例を示す図である。
【図４】図１乃至図３を参照して説明した技術の実装の形態に適したコンピュータ・システムを示す図である。
【図５】図１乃至図３を参照して説明した技術の実装の形態に適したセキュアシステムの例を示す図である。
【図６Ａ】セキュアなブロックベースドメディアアクセスの方法の例のフローチャートである。
【図６Ｂ】セキュアなブロックベースドメディアアクセスの方法の例のフローチャートである。
【図７Ａ】セキュアなブロックベースドメディアアクセスの別の方法を示すフローチャート７００である。
【図７Ｂ】セキュアなブロックベースドメディアアクセスの別の方法を示すフローチャート７００である。
【図７Ｃ】セキュアなブロックベースドメディアアクセスの別の方法を示すフローチャート７００である。
【発明を実施するための形態】
【００１０】
以下の説明では、本発明の実施形態の十分な理解を与えるために幾つかの特定の具体的な構成が提示される。しかし、当業者であれば、１つ以上のこれら特定の具体的な構成がなくとも、あるいは他の構成部などとの組み合わせにより、本発明を実施することが可能であることが理解されるであろう。また別の例では、様々な実施形態における本発明の側面を覆い隠すことがないように、周知の具体的構成は、図示または詳細に説明されていない。
【００１１】
図１は、階層的ハッシュ技術に関連する二分木構造１００の例を示している。本願明細書で援用されるものは、１９８２年１月５日にマークル（Merkle）に対し発行された「デジタル署名提供法（“Method of Providing Digital Signatures”）」と題する米国特許第4,309,569号である。一群のデータブロック{Y1, …Yk, …Yn}、(1<=k<=n)が認証されることになる。図１の例ではn=8である。ブロックYkは、Ykと一群の値H(i, j, Y)を用いることで認証される。伝達されたブロックYkと、これに対応する一群の値H(i, j, Y)はYkの信頼性を確立するために個々に使用できる。ここで、H(i, j, Y)は以下のように定義される。
H(i, i, Y)=F(Yi)
H(i, j, Y)=F(H(i, (i+j-1)/2, Y), H((i+j+1)/2, j, Y))
但し、F(Yi)はSHA-1などの一方向関数である。従って、H(i, j, Y)は、Yi, Yi+1, ...Yjの一方向関数、H(1, n, Y)は、Y1〜Ynの一方向関数である。即ち、レシーバーはYkとHの一群の値を選択的に認証することが可能である。
【００１２】
二分木構造１００のルート値H(1、8、Y)を信用するためには、例えばその値に対する公開鍵ベースの暗号署名（例えば、RSA署名）を獲得できなければならない。署名は、信頼できるルート鍵まで適切に証明書の連鎖を検証することで、署名を有効にすることが可能となる。しかしながら、何らかの適用可能な公知の（又は手頃な）セキュリティ機構を、信用構築のために使用できるであろう。
【００１３】
図１の例では、Y5を認証するために、信頼のあるH(1, 8, Y)を持ち、かつH(6, 6, Y)、H(7, 8, Y)、及びH(1, 4, Y)を受けとることが必要である。H(5, 6, Y)とH(5, 8, Y)は導き出すことが可能である。説明のために、これらのボックスは図１で陰影をつけられており、導き出された値を示すボックスは破線を有し、H(5, 5, Y)は検証ターゲットであって太線によって囲まれたブロックで表されており、ルート値H(1, 8, Y)は破線と実線との双方によって囲まれ、H(1, 8, Y)自体が受信されるものであると共に導き出されるものでもあることを示している。認証を成功させるためには、H(1, 8, Y)の受信値と導き出された値(received and derived values)は一致していなければならない。陰影のないボックスに関連した値は、Y5を認証するために既知である必要はない。
【００１４】
図１に示す例において、検証ターゲットH(5, 5, Y)、及び受信値(received values)の最初の値H(6, 6, Y)は、共に、上述したH(i, j, k)の定義を用いて、H(5, 6, Y)を導き出すのに使用できる。又、導き出された値(derived value) H(5, 6, Y)、及び受信値の２番目の値H(7, 8, Y)は、共に、H(5, 8, Y)を導き出すのに使用できる。更に、導き出された値H(5, 8, Y)、及び受信値の３番目の値H(1, 4, Y)は、共に、ルート値H(1, 8, Y)を導き出すのに使用できる。また、H(1, 8, Y)は４番目の受信値でもあった。H(1, 8, Y)の導き出された値と受信値が一致したならば、その時は４番目の受信値が信頼できることと仮定した上でH(5, 5, Y)が認証されることになる。
【００１５】
二分木構造１００の異なったレベルに属するH( )値のグループは、階層の夫々のレベルによって表示することができる。例えば:
H3: = H(1, 8, Y)
H2: = {H(l, 4, Y), H(5, 8, Y)}からなる値
H1: = {H(1, 2, Y), H(3, 4, Y), H(5, 6, Y), …}からなる値
H0: = {H(1, 1, Y), H(2, 2, Y), H(3, 3, Y), …}からなる値
従って、H0ハッシュはデータブロックＹ１、Ｙ２などのハッシュや、二分木構造１００の葉節点(leaf nodes)を言及している。ツリーの構造は、階層におけるレベルの数やツリー構造の各節点(node)の子の数によって定義しても良い。
【００１６】
図１を参照して説明した技術は、他の非二分木構造まで拡張することができる。構造の選択にあたっては、それらに限定されるものではないが、例えば：結果として生じるデータブロックの大きさやブロック認証に必要な認証データ；デバイスからの所望データ読み取り速度を満たすための一方向ハッシュ関数（例えば、SHA-1）の計算の数；シーク(seek)を最小限にしつつ、データを読み込むことの副作用として、又は認証データのための読み取りオーバーヘッドを最小限にする他の方法により、利用可能な認証データを持つことの必要性；ツリーによってカバーされなければならない最大データサイズ、などによって決めるようにしても良い。
【００１７】
図２は階層的ハッシュ技術に関連する非二分木構造２００を示す。図２の例に選ばれるツリーの構造は、例えばDVDディスクなどのブロックベースドメディアデバイスのための上記の要件を満たすものであり、デバイスの上において、データブロックY1、Y2などと共に値H0, H1…の配列(placement)を導くものとなる。
【００１８】
図２の例において、H0ハッシュがH(1, 1, Y)、H(2, 2, Y)などといったように選ばれ、各H0ハッシュが１個の1Kデータブロックをカバーするようになっている。データブロックサイズは、ここでは1Kバイトになるように選ばれているが、どんな適当なサイズでも良い。
【００１９】
図２の例では、非二分木構造２００のH1ハッシュがH(1, 31, Y)、H(32, 62, Y)などといったように選ばれる。即ち、図２の例では、各H1は、３１ブロックのデータをカバーする。その他の実施例としては、３１ブロックのデータというよりはむしろ、どんな適当な数のブロックも使用可能である。３１ブロックのデータは、それに限定されるものではないが、図３の例によって示されたデータブロックに準拠したものである。
【００２０】
図３は32KBブロック３００の例を示している。32KBブロック３００は、ハッシュブロック３０２と３１個の1KBデータブロック３０４を含む。ハッシュブロックは、後述するところのハッシュとパディング(padding)を含む。実装の形態によっては、３１個の1KBデータブロック３０４は、ハッシュブロック３０２によって先行されるように、またはハッシュブロック３０２に挟まれるようにして、例えばDVDディスク上の32KBブロック３００内に一緒に格納される場合もある。
【００２１】
再び図２の例を参照するに、H2ハッシュは、H(1, 31×8, Y)、H(31×8+1, 31×2×8, Y)などといったように選ばれる。即ち、各H2ハッシュは、31×8ブロックのデータをカバーする。これは、各H2節点(node)が、レベルH1において、８個の子を有していることを意味する。本例では被乗数は“８”だが、どんな数も選択可能である。被乗数を増やすことは、（相殺するアクション(counterbalancing action)が取られない限りにおいては）レベルH3の節点（ノード）数を減少させる効果があり、被乗数を減らすことは、その反対の効果をもたらすことになる。
【００２２】
H3ハッシュが、H(1, 31×8×8, Y)、H(31×8×8+1, 31×2×8×8, Y)などといったように選択される。即ち、各H3ハッシュは、31×8×8個のブロックデータをカバーする。これは各H3節点(node)が、レベルH2において、８個の子を有していることを意味する。本例では被乗数は“８”だが、どんな数も選択可能である。非限定的実施形態においては、H3ハッシュの数は、認証機構でカバーされる最大サイズのデータをカバーするように選ばれることもある。例えば、４１８２個のハッシュを9.4G実装品で使用したり、７６８個のハッシュを1.5G実装品で使用したりしても良い。図２の例では、非二分木構造２００は、本例で示されるパラメータと共に如何なるサイズのブロックベースドメディアデバイスにも一般化できるようにn個のハッシュを備える。
【００２３】
最終的なH4ハッシュ（ツリー階層の根の部分）は署名された値であって、コンテンツデータの公開が認可されたセキュアサーバーにおいて、公知または手頃な公開鍵署名法を使用することによって署名される。コンテンツのサイズは任意であっても、或いは任意でなくても良い。階層構造の値を演算するために、追加コンテンツブロックやハッシュ値がランダムなバイトとして当てがわれるようにしても良い。図２を参照して説明した技術は、ＤＶＤブロックに使用可能であり、或いは他のアプリケーションへと適用（拡張）することが可能である。
【００２４】
再度、図３を参照するに、本例ではハッシュブロック３０２は、３１個のH0ハッシュ／パディング３１０、８個のH1ハッシュ／パディング３１２、及び８個のH2ハッシュ／パディング３１４に細分される。
【００２５】
ディスクヘッダなどのヘッダ（図示せず）は、通常、32KBブロック３００に関連するブロックベースドメディアデバイスの最初のアクセスエリアに含まれることになる。一実施形態において、ヘッダに含まれた内容は、ブロックベースドメディアデバイス上の全ブロックに適用可能となる。これで殆どの目的に対し十分ではあるが、ヘッダは、先頭に付け加えたり、後ろに付け加えたり、さもなければデータのブロックに含められたりしてもよい。非限定的実施形態において、ヘッダはH4ハッシュとこれに関連するH3ハッシュを含んでいる（例えば、図２参照）。又、別の実施形態として、関連するH3を８個のH2ハッシュから導き出すことが出来るし、H3自体を提供する必要もないが、その際には全ブロックベースドデバイスからのデータアクセスが必要になるかもしれない。
【００２６】
非限定的実施形態において、ヘッダは、少なくとも最終的なハッシュ（例えばH4）、コンテンツ識別、及び任意の鍵を含む“チケット”と呼ばれる署名データ構造を含んでも良い。例えばこのチケットは、あくまで例であってこれに限定されないがＲＳＡなどの公開鍵署名法を使用するコンテンツ発行サーバーによって署名されるようにしても良い。非限定的実施形態では、チケットに、コンテンツに権利を付与する他の権利マネージメントデータや、別のライセンス供与サーバーによる署名を含ませるようにしても良い。ヘッダは更に、証明書チェーンや取消しリストなど、署名の有効化を補助する補助データ構造を含んでも良い。コンテンツに適用可能な権利を減らす或いは拡張するために、権利マネージメントライセンスは、代替手段によって供給された他の権利マネージメントライセンスと併せて使用されてもよい。
【００２７】
ヘッダに続き、ハッシュブロック３１０、３１２、３１４と３１個の1KBデータブロック３０４を挟んでも良い。図３の例では、１ブロックが32KBで、最初の1KBブロックはハッシュブロック３０２として留保される。一実施形態では、ハッシュブロック３０２は、ヘッダがプレロード（先行読み込み）されると仮定して、３１個の1KBデータブロック３０４を有効化するのに必要な全認証データを含んでも良い。３１個の1KBデータブロック３０４にはコンテンツを含ませても良い。如何なる適用可能な公知（又は手頃な）ハッシュアルゴリズムが使用されても良い。例えば、ハッシュサイズが２０バイトのＳＨＡ１であるならば十分であろう。
【００２８】
一実施形態では、総てのデータブロックが（例えば、ＡＥＳ暗号を使用する形で）、コンテンツのコピー防止を確実にするために暗号化される。別の実施形態としては、いくつかのデータブロックを暗号化しない場合もある。非限定的実施形態としては、ハッシュブロック３０２からスタートする形で、データが復号化される。ハッシュの復号化にあたっては、如何なる公知の、又は手頃な技術も使用可能である。例えば、一定の既知数を、ハッシュブロック３０２の始まりを復号化するために初期化ベクトルとして選択しても良いし、H2ハッシュの一部をデータブロック復号化用の初期化ベクトルとして使用しても良い。チケット有効化工程の副産物として復号化鍵を獲得しても良い（例えば図５参照）。
【００２９】
図４は、図１乃至図３を参照して上述した技術の実施に適するコンピュータ・システム４００を示している。コンピュータ・システム４００は、コンピュータ４０２、I/Oデバイス４０４、及びディスプレイデバイス４０６を含む。コンピュータ４０２は、プロセッサ４０８、通信インターフェース４１０、メモリ４１２、ディスプレイコントローラ４１４、不揮発性記憶装置４１６、及びI/Oコントローラ４１８を含む。コンピュータ４０２は、I/Oデバイス４０４やディスプレイデバイス４０６に接続する形でも、あるいはそれらを含む形でも良い。
【００３０】
コンピュータ４０２は、モデムやネットワークインターフェースを含んでもよい通信インターフェース４１０を介し、外部システムと接続する。通信インターフェース４１０は、コンピュータ・システム４００の一部かコンピュータ４０２の一部として考えることができる。通信インターフェース４１０は、アナログ・モデム、ISDNモデム、ケーブルモデム、トークン・リング・インタフェース、衛星通信インターフェース（例えば、“ダイレクトＰＣ”）、又は１つのコンピュータ・システムを他のコンピュータ・システムに接続する他のインターフェースのいずれでも良い。従来のコンピュータは通常、一種の通信インターフェースを備えるが、インターフェースを含まないコンピュータを作成することで、通信インターフェース４１０を厳密な意味で任意的なものとすることができる。
【００３１】
プロセッサ４０８は、それに限定されない一例として、インテル社のペンティアム（登録商標）マイクロプロセッサやモトローラ社のパワーＰＣマイクロプロセッサなどの従来マイクロプロセッサを具備しても良い。プロセッサ４０８は、総ての従来型コンピュータにとって重要な部品と言えるが、ここで説明した技術を実施するためには、適用可能な如何なる公知の（又は手頃な）プロセッサを使用することも可能である。メモリ４１２は、バス４２０によって、プロセッサ４０８に接続される。メモリ４１２（以下、“主記憶装置(primary memory)”と呼ぶこともある）は、ダイナミック・ランダムアクセス・メモリ（ＤＲＡＭ）を備えたり、またスタティック・ラム（ＳＲＡＭ）を備えたりすることも可能である。バス２２０は、プロセッサ４０８をメモリ４１２に接続したり、又不揮発性記憶装置４１６にも、ディスプレイコントローラ４１４にも、更にI/Oコントローラ４１８にも接続したりすることができる。
【００３２】
I/Oデバイス４０４は、キーボード、ディスクドライブ、プリンタ、スキャナ、及びマウスか他のポインティング・デバイスを含む他の入出力装置を含むことができる。説明のため、これらI/Oデバイスの少なくとも１つを、DVDプレーヤーのようなブロックベースドメディアデバイスと仮定する。ディスプレイコントローラ４１４は、公知の又は手頃な方法で、ディスプレイデバイス４０６上のディスプレイを制御しても良く、ディスプレイデバイス４０６は、例えば、ブラウン管（ＣＲＴ）だったり、液晶ディスプレイ（ＬＣＤ）だったりする。
【００３３】
ディスプレイコントローラ４１４とI/Oコントローラ４１８はデバイスドライバを具備しても良い。デバイスドライバは、ハードウェアデバイスとの相互作用を可能にするべく開発された特定のコンピュータ・ソフトウェアである。通常、これは、デバイスと通信するためのインターフェースを構成し、ハードウェアが接続されるバスや通信サブシステムを介し、デバイスへの命令送信及び／又はデバイスからのデータ受信を実行する一方、必要不可欠なものはOSとソフトウェアアプリケーションと相互作用する。
【００３４】
デバイスドライバは、OS特有でもあるハードウェア依存型コンピュータ・プログラムを含んでもよい。そのコンピュータ・プログラムにより、別のプログラム（通常OS、アプリケーションソフトウェアパッケージ、又はOSカーネル上で動くコンピュータ・プログラム）は、透過的にハードウェアデバイスと相互作用することができ、同コンピュータ・プログラムは通常、ニーズと調和した如何なる必要な非同期・時間依存型ハードウェアにも必要不可欠な割り込み処理を提供する。
【００３５】
往々にして不揮発性記憶装置４１６（以下、“補助記憶装置(secondary memory)”と呼ぶこともある）は、磁気ハードディスクだったり、光ディスクだったり、或いは大量データ用の他の種類の記憶装置だったりする。このデータのいくつかはしばしば、コンピュータ４０２でソフトウェアを実行している間に、ダイレクトメモリアクセス工程によってメモリ４１２に書き込まれる。不揮発性記憶装置４１６は、ブロックベースドメディアデバイスを含むものでも良い。“機械可読メディア”や“コンピュータ可読メディア”という用語は、プロセッサ４０８によってアクセス可能であって、データ信号を符号化する搬送波を包含する如何なる公知の（又は手頃な）記憶装置をも含んでいる。
【００３６】
コンピュータ・システム４００は、異なったアーキテクチャを持っている多くの実行可能なコンピュータ・システムの一例である。例えば、インテルマイクロプロセッサをベースとするパーソナルコンピュータは往々にして複数のバスを有し、その１つは周辺機器へのI/Oバスであったり、プロセッサ４０８とメモリ４１２を直接接続するもの（しばしば“メモリバス”と呼ばれる）であったりする。これらのバスは、バスプロトコルが異なることによって必要とされる如何なる変換(translation)を実行できるブリッジコンポーネントを介して接続される。
【００３７】
ネットワーク・コンピュータは、ここで提供した教示に関連して使用可能な別のタイプのコンピュータ・システムである。通常、ネットワーク・コンピュータはハードディスクや他の大容量記憶装置を備えておらず、実行可能プログラムは、プロセッサ４０８による実行のために、ネットワーク接続からメモリ４１２に取り込まれる。当該技術では既知のウェブテレビシステムも又、１つのコンピュータ・システムと考えることもできるが、ある入力や出力装置のように図４に示した特徴の幾つかを欠く可能性がある。通常、一般的なコンピュータ・システムは、少なくともプロセッサ、メモリ、メモリをプロセッサに接続するバスを具備することになる。
【００３８】
オペレーティングシステム（OS）でコンピュータ・システム４００を制御しても良い。OSは、全部ではないが殆どのコンピュータ・システムに使用されるソフトウェアプログラムであって、コンピュータのハードウェア及びソフトウェア・リソースを管理している。通常、OSは、メモリを制御して割り当てをしたり、システムの要求に優先順位を付けたり、入出力装置を制御したり、ネットワーキングを補助したり、ファイルを管理するといったような基本タスクを実行するものである。パーソナルコンピュータ用オペレーティングシステムの例としては、マイクロソフト社のウインドウズ（登録商標）、リナックス、マックOS（登録商標）などがある。OSとアプリケーション・ソフトウエアとの間の線引きは往々にしてかなり難しい。幸いにも、何らかのリーズナブルな線引きで十分であるため、本願で説明した技術を理解するのにこの線引きは不要である。
【００３９】
最も低いレベルのOSとしては、その（OSの）カーネルであっても良い。通常、カーネルは、システムブートや、スタートアップする際にメモリに取り込まれるソフトウェアの第１の層(first layer)である。カーネルにより、他のシステムやアプリケーション・プログラムに対する様々な共通コアサービスへのアクセスを提供する。
【００４０】
ここに使用されたように、コンピュータメモリ中のデータ・ビットにおける操作のアルゴリズム的記述と象徴(symbolic representations)は、当業者に対し最も効果的に技術を伝えるものと思われる。アルゴリズムという用語は、ここで使用するとき、また一般に使用されるとき、所望の結果を導き出す動作 (operations)の首尾一貫したシーケンス（self-consistent sequence）と考えられる。この動作は、物理量の物理的な操作(manipulations)を必要とするものである。必ずしも必要ではないが、通常、こうした量は、格納、転送、結合、比較、及び他の操作を行うことができる電気、または磁気の信号の形を取る。時には、主に一般的な使用のために、こうした信号をビット(bits)、値(values)、要素(elements)、記号(symbols)、文字(characters)、項(terms)、数字(numbers)などと呼ぶのが便利であることがわかっている。
【００４１】
しかしながら、これら、及びこれらと同様の用語はすべて、適切な物理量に関連付けられ、単にこうした量に適用される手頃なラベル(labels)にすぎないことを心に留めておくべきである。特に明記しない限り、または下記の記述から明らかであるように、“処理する(processing)”、“演算する(computing)”、“計算する(calculating)”、“決定する(determining)”、“表示する(displaying)”などの用語は、コンピュータ・システムのレジスタおよびメモリ内の物理的な（電子）量として表されるデータを操作し、コンピュータ・システムのメモリまたはレジスタ、または他のこうした情報記憶装置、送信装置または表示装置内の同じように物理（電子）量として表される他のデータに変換するコンピュータの動作および処理(process)を指す。
【００４２】
ここで説明した技術を実施するための装置は、要求された目的のためにそれ専用に構成しても良く、又コンピュータに格納されたコンピュータ・プログラムによって選択的に起動(activated)されたり再構成(reconfigured)されたりする汎用コンピュータから成るものでも良い。そのようなコンピュータ・プログラムは、それらに限定されるものではないが例えば、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、EPROM、EEPROM、磁気又は光学カード、フレキシブルディスクを含む如何なるタイプのディスク、光ディスク、CD-ROM、DVD、光磁気ディスク、或いは電子的な指示(instructions)を格納するのに適した如何なる公知の（又は手頃な）の媒体のような、コンピュータ可読記憶媒体に格納されても良い。
【００４３】
ここに提示されたアルゴリズムとディスプレイは本来、如何なる特定コンピュータ・アーキテクチャにも関連するものではない。この技術は、高いレベル（例えば、C/C++）であろうと低レベル（例えば、アセンブリ言語）だろうと、又インタープリタ型（例えば、Perl）だろうと、コンパイラ型（例えば、C/C++）だろうと、バイトコード（例えば、Java（登録商標））からコンパイルされるジャストインタイム（JIT）であろうと、如何なる公知の（又は手頃な）プログラミング言語を使用して実施されても良い。どんな公知の（又は手頃な）コンピュータでも、アーキテクチャに関係なく、コンパイルされた機械コードか、さもなければ何らかの言語からコンピュータ・アーキテクチャと互換性がある機械コードへとアセンブルされた機械コードを実行することが可能でなければならない。
【００４４】
図５は、図１乃至図３を参照して上述した技術を実施するのに適していたセキュアシステム５００の一例を示している。代表的なセキュアシステム５００は、ゲーム機、メディアプレーヤー、埋め込み型(embedded)セキュアデバイス、セキュアプロセッサ付き“従来型”PC、或いはセキュアプロセッサを備える他のコンピュータ・システムを備えても良い。
【００４５】
図５の例においてセキュアシステム５００は、セキュアプロセッサ５０２、OS５０４、ブロックベースドメディアドライバ５０６、ブロックベースドメディアデバイス５０８、プロテクト・メモリ５１０、及びチケットサービス５１２を含む。図５の例ではOS５０４は、鍵ストア５１６、暗号化/復号化エンジン５１７、及びセキュリティAPI５１８を順に含むセキュリティカーネル５１４を有する。上述したこれら部品の１つ又はそれ以上、或いはその一部を、プロテクト・メモリ５１０又は保護されていないメモリ（図示せず）に属させるようにしても良いことを留意すべきである。
【００４６】
さらに留意すべきは、慣例だけによって、セキュリティカーネル５１４が、OS５０４に属するように表現されていることである。実際にOS５０４の一部であってもなくても良く、OSの外側に存在することも、或いはOSを含まないシステム上に存在することも可能である。説明を簡単にする目的で、OS５０４は認証可能であることが前提である。実施形態では、ブロックベースドメディアドライバ５０６、及び／又は、チケットサービス５１２は、OS５０４の一部であっても良い。認証付きのブロックベースドメディアドライバ５０６とチケットサービス５１２を読み込むこと(loading)が、セキュリティを向上できるという理由で、これは望ましいかもしれない。従って、そのような実施形態では、OS５０４は認証付きで読み込まれ、ブロックベースドメディアドライバ５０６とチケットサービス５１２を含むことになる。
【００４７】
説明の簡略化のために、プロテクト・メモリは単一メモリとして示される。しかしながら、このプロテクト・メモリは、保護された主記憶装置、保護された補助記憶装置、及び／又は、シークレットメモリを含んでも良い。メモリが保護されるのを確実とするためには、公知の（又は手頃な）機構が適所にあることが前提である。主記憶装置と補助記憶装置との間、及び／又は、揮発性記憶装置と不揮発性記憶装置との間のインタープレイ(interplay)は、公知であるため、様々な種類のメモリと記憶装置の間の区別は図５に関しては示されていない。
【００４８】
チケットサービス５１２は、例えば“デジタルライセンス有効化サービス”として考えられても良く、また非限定的な実施形態では、ライセンス有効化に関連する公知の（又は手頃な）手順を含んでもよい。例えば、チケットサービス５１２は、デジタルライセンスを有効にするための手順、PKI有効化手順などを含んでも良い。図５の例では、チケットサービス５１２は、ブロックベースドメディアデバイス５０８上でチケットを有効化することができる。この動作において、ブロックベースドメディアドライバ５０６は、ブロックベースドメディアデバイス５０８からチケットを獲得する。次いで、ブロックベースドメディアドライバ５０６は、チケットサービス５１２へのチケットを供給し、同サービスはチケット有効化を進行させる。チケットが有効である場合、ブロックベースドメディアドライバ５０６は、チケットに関連したブロックを復号化することが許される。
【００４９】
一実施形態では、セキュリティカーネル５１４が、起動時点において読み込み(loaded)されてもよい。別の実施形態では、セキュリティカーネルの一部が、起動時点において読み込みされ、残りが後で読み込みされても良い。この技術の一例は、Srinivasanらによって、2003年2月7日に出願された“信頼性や下位互換性のあるプロセッサ、及びその上でのセキュアソフトウェア実行”というタイトルの出願番号：１０／３６０，８２７号に記載され、同技術がここで援用される。セキュアな方法（技術的に安全性が保証された方法、in a secure manner）で、セキュリティカーネル５１４を読み込みするべく、如何なる公知の（又は手頃な）技術も使用可能である。
【００５０】
鍵ストア５１６は、鍵のための格納場所群からなる。鍵を格納するのに使用されるデータ構造は重要な意味をもつものではないが、鍵ストア５１６は、鍵の一配列と思われても良い。鍵を格納するために、適用可能な如何なる公知の（又は、手頃な）構造も使用可能である。非限定的な実施形態では、鍵ストア５１６は、静的な(static)鍵を以て初期化されるが、可変鍵(variable keys)は初期化されない（或いは、セキュアでない値に初期化される）。例えば、幾つかの鍵ストア位置(key store locations)は、認証されたセキュリティカーネル５１４の読み込み(loading)の一部としての信頼値（例えば信頼ルート鍵）で予備充填(pre-filled)される。
【００５１】
一実施形態において、暗号化/復号化エンジン５１７は、暗号化と復号化の両方が可能である。例えば、かかる動作において、アプリケーションは、セキュリティAPI５１８に、アプリケーションが暗号化に使用できるというキーハンドルを要求するかもしれない。暗号化/復号化エンジン５１７を、キーハンドルを使用してデータを暗号化するのに使用しても良い。好都合なことには、セキュリティAPI５１８は、キーハンドルを平文で提供するが、鍵そのものは決してセキュリティカーネル５１４から離れることはない。
【００５２】
セキュリティAPI５１８は、鍵を明らかにすることなく（すなわち、鍵がセキュリティカーネル５１４を離れないか、或いは暗号化される場合にだけに限って鍵がセキュリティカーネル５１４を去るような状態で）、鍵ストア５１６内の鍵を使用した動作を実行することができる。セキュリティAPI５１８は、鍵ストア５１６で鍵（そして潜在的には、他のセキュリティ材料）を作成(create)し、投入(populate)し、使用するためのサービスを含んでも良い。また、一実施形態では、セキュリティAPI５１８は、また、秘密鍵とデバイスプライベート鍵を含む、内部の秘密と不揮発性データへのアクセスを与える。実装の形態によっては、セキュリティAPI５１８は、ハードウェア加速を使用することでAES及びSHAオペレ−ションをサポートするようにしても良い。
【００５３】
図５の例では、ブロックベースドメディアドライバ５０６は、ブロックベースドメディアデバイス５０８からの読み出しを行いながら、以下のセキュリティオペレーションを実行するように構成しても良い。
１）秘密鍵を使用して、ブロックベースドメディアデバイス５０８を復号化すること、及び
２）ブロックベースドメディアデバイス５０８上の認証データを使用して、ブロックベースドメディアデバイス５０８上のコンテンツを認証すること（認証が失敗した場合、読み出しは失敗する）
【００５４】
図５の例では、これらのセキュリティオペレーションを実行するために、ブロックベースドメディアドライバ５０６は、システム５００内の他のセキュアサービス、例えばチケットサービス５１２やセキュリティAPI５１８などを利用しても良い。一実施形態では、これらモジュールの夫々が、システムセキュリティのための個々の実行スペースにおいて実行する。データブロックを有効化するために、ブロックベースドメディアドライバ５０６は、データブロック・ヘッダを読み出し、ヘッダのデータを使ってチケットを有効にするためにチケットサービス５１２を用いる。ブロック復号化をサポートするために、チケットは、暗号化された鍵を含んでも良い。チケットサービス５１２は、セキュリティカーネル５１４（例えば、暗号化/復号化エンジン５１７）におけるサービスを利用して、鍵を復号化する。
【００５５】
一実施形態では、暗号化/復号化エンジン５１７は、この復号化を実行するために、鍵ストア５１８からの秘密共通鍵を使用する。別の実施形態では、チケットサービス５１２は、フラッシュかネットワーク（図示せず）から得られたデバイス個別チケット(device personalized ticket)を使用して、コンテンツに対する幾つかの権利を有効にして、その後に鍵を戻すことも可能である。いずれにしても、このプロセスは、ブロックベースドメディアドライバ５０６に戻り、ブロックを復号化する際に使用する鍵にリファレンスを与える。この鍵リファレンスは、ブロックベースドメディアドライバ５０６によって使用され、鍵に関連するブロックを復号化するセキュリティAPI５１６に次の呼び出しをする。
【００５６】
復号化の後に、ブロックベースドメディアドライバ５０６は、セキュリティAPI５１６（又は、ハッシュ演算エンジンへの他のインターフェース）に対し呼び出しをかけ、チケットに関連する階層的ハッシュツリーを有効にする（例えば、図３参照）。セキュリティAPI５１６は、チケットの中にあるものに対するルートハッシュを有効化する。有効化が成功したことを前提に、チケットに関連するコンテンツは使用可能なものにされる。非限定的な実施形態では、復号化と認証の順番はさほど重要でなく、入れ替えできるものである。
【００５７】
矢印５２０〜５３６を以て、システム５００のデータフローの例が例示を目的として供される。ブロックベースドメディアドライバ５０６においてブロック・ヘッダを受けることは、ブロックベースドメディアデバイス５０８からブロックベースドメディアドライバ５０６へのヘッダアクセス矢印５２０によって表わされている。データブロック・ヘッダは恐らくは、アクセスして読み出し可能となるために矢印５２０は双方向となる。
【００５８】
チケットを含むデータブロック・ヘッダからチケットサービス５１２へのデータ送信は、認証データ矢印５２２によって表わされている。チケットは、暗号化された鍵を含んでも良い。鍵の復号化のためにセキュリティAPI５１６に要求を送ることは、鍵復号化要求矢印５２４によって表されている。現在鍵ストア５１８に格納されている復号化された鍵へのリファレンスの戻しは、鍵へのリファレンス矢印５２６によって表わされる。チケットの有効化に成功した後、チケットサービスは、ブロック復号化の際にドライバが使用した鍵へのリファレンスと共に、チケット有効化データをブロックベースドメディアドライバ５０６に送ることになる。チケットサービス５１２からブロックベースドメディアドライバ５０６へのデータ送りは、チケット有効化矢印５２８として示されている。
【００５９】
データブロックアクセス矢印５３０は、ブロックベースドメディアドライバ５０６によるブロックベースドメディアデバイス５０８からのブロック読み出しを示している。データアクセスは、ヘッダ（５２０）の受信と同時に行っても、或いは時を一致させずに行っても良い。アクセスされたブロックは、チケット有効化データ（５２８）を使用して復号化され、ブロック復号化要求矢印５３２はかかる要求を表している。ハッシュツリー有効化矢印５３４は、１ブロックのコンテンツのその後の有効化を表している。
【００６０】
一実施形態として、あるレベルのハッシュ（例えば、図２のレベルH3参照）をヘッダに供給することも可能である。そのような実施形態では、第１ハッシュツリー有効化シーケンスは、ハッシュの計算や、このハッシュのヘッダに提供された関連値との比較を含んでも良い。別の実施形態では、あるハッシュ演算時間を節約出来るかもしれない将来のレファレンスのために(for future reference)、階層的ハッシュツリーの部分値が、ハッシュされてもよい。
【００６１】
図６Ａ及び図６Ｂは、セキュアなブロックベースドメディアアクセスの方法の一例としてのフローチャート６００を示している。この方法、及び他の方法は、連続的に並べられたモジュールの形で表現される。しかしながら、これらの方法における各モジュールは、並べ替えされたり、並列実行のために適当に並べられたりしても良い。図６Ａの例において、フローチャート６００は、モジュール６０２でスタートし、ここではブロックベースドメディアヘッダが読み込まれる。図６Ａの例において、フローチャート６００は、モジュール６０４に進み、ここでチケットの有効化が行われ、復号鍵へのリファレンスが得られる。
【００６２】
図６Ａの例で、フローチャート６００は、決定ポイント６０６に進み、チケットが有効であるか否かが判定される。チケットが有効でない場合（６０６−Ｎの場合）、プロセスは中止になり、フローチャート６００は終了することになる。他方、チケットが有効である場合（６０６−Ｙの場合）、フローチャート６００は、モジュール６０８に進み、H3ハッシュのハッシュを、チケットの中にあるルートハッシュ値と比較する。この比較は例えばセキュリティー・サービスで実行しても良い。
【００６３】
図６Ａの例で、フローチャート６００は、決定ポイント６１０に進み、チケットが有効であるか否かが判定される。その比較（モジュール６０８）で一致している場合には、チケットが有効であると仮定される。チケットが有効でないと判定されたならば（６１０−Ｎの場合）、プロセスは中止になり、フローチャート６００は終了する。他方、チケットが有効である場合（６１０−Ｙの場合）、フローチャート６００は、モジュール６１２に進み、H3ハッシュ群のH3ハッシュ値が格納され、読み出し要求(read request)が待機状態にされる。H3ハッシュ値は、例えばセキュアDRAMに格納されても良い。
【００６４】
図６Ａの例では、フローチャート６００は、モジュール６１４に進み、ここではコンテンツを解読するための鍵へのリファレンスが獲得される。コンテンツ解読のための鍵へのリファレンスは、リファレンス獲得のためチケットサービス（ヘッダ情報を伴う）に呼び出しをかけることで獲得するようにしても良い。図６Ａの例では、フローチャート６００は、モジュール６１６に進み、読み出し要求のハッシュサブブロックとデータサブブロックの所在確認が行われる(located)。図６Ａの例では、フローチャート６００は、更にモジュール６１８に進み、前記ハッシュサブブロックとデータサブブロックが復号化される。図６Ｂの例では、フローチャート６００は、モジュール６２０に進み、ここでデータサブブロックのハッシュが計算される。
【００６５】
図６Ｂの例では、フローチャート６００は、モジュール６２２に進み、データサブブロックのハッシュがレベルH0ハッシュ群の対応するH0ハッシュ値と比較される（例えば、図３参照）。図６Ｂの例では、フローチャート６００は、決定ポイント６２４に進み、ここで上記比較が有効な結果(valid result)をもたらしたか否かが判定される。比較結果が有効でない場合（モジュール６２４−Ｎ）、その時、フローチャート６００ではブロックベースドメディアデバイスからの読み出し要求を中止する。他方、上記比較結果が有効である場合（モジュール６２４−Ｙ）、フローチャート６００は、モジュール６２６に進み、レベルH0のハッシュ値を含む、H0ハッシュ群のハッシュH1’が計算される。
【００６６】
図６Ｂの例では、フローチャート６００は、モジュール６２８に進み、H1’がレベルH1ハッシュ群の対応するH1ハッシュ値と比較される（例えば、図３参照）。図６Ｂの例では、フローチャート６００は、決定ポイント６３０に進み、ここで上記比較が有効な結果をもたらしたか否かが判定される。比較結果が有効でない場合（モジュール６３０−Ｎ）、その時、フローチャート６００ではブロックベースドメディアデバイスからの読み出し要求を中止する。他方、上記比較結果が有効である場合（モジュール６３０−Ｙ）、フローチャート６００は、モジュール６３２に進み、レベルH1のハッシュ値を含む、H1ハッシュ群のハッシュH2’が計算される。
【００６７】
図６Ｂの例では、フローチャート６００は、モジュール６３４に進み、H2’がレベルH2ハッシュ群の対応するH2ハッシュ値と比較される（例えば、図３参照）。図６Ｂの例では、フローチャート６００は、決定ポイント６３６に進み、ここで上記比較が有効な結果をもたらしたか否かが判定される。比較結果が有効でない場合（モジュール６３６−Ｎ）、その時、フローチャート６００ではブロックベースドメディアデバイスからの読み出し要求を中止する。他方、上記比較結果が有効である場合（モジュール６３６−Ｙ）、フローチャート６００は、モジュール６３８に進み、レベルH2のハッシュ値を含む、H2ハッシュ群のハッシュH3’が計算される。
【００６８】
図６Ｂの例では、フローチャート６００は、モジュール６４０に進み、H3’が対応して格納されたH3ハッシュ値（６１２）と比較される（例えば、図３参照）。図６Ｂの例では、フローチャート６００は、決定ポイント６４２に進み、ここで上記比較が有効な結果をもたらしたか否かが判定される。比較結果が有効でない場合（モジュール６４２−Ｎ）、その時、フローチャート６００ではブロックベースドメディアデバイスからの読み出し要求を中止する。他方、上記比較結果が有効である場合（モジュール６４２−Ｙ）、フローチャート６００は、モジュール６４４に進み、ブロック読み出し要求が果たされる。
【００６９】
図７Ａ、７Ｂ及び図７Ｃは、セキュアなブロックベースドメディアアクセスの別の方法を説明するためのフローチャート７００を示している。図７Ａの例では、フローチャート７００は、ブロックベースドメディアデバイスのヘッダにアクセスするモジュール７０２でスタートする。次に、フローチャート７００は、モジュール７０４に進み、ヘッダに含まれるデータ構造を認証する。それに限定されない例としてデータ構造は、チケットやイーチケット(eTicket)、或いは実際に、ここに記載する意図した目的のために機能する如何なる他のデータ構造でも良い。
【００７０】
図７Ａの例で、フローチャート７００は、モジュール７０６に進み、ヘッダに含まれるハッシュ値群をセキュアに格納する(技術的に安全性が保証された状態で格納する、securely storing)。それに限定されない例として、これらのハッシュ値は、図２のH3ハッシュと同様なものでも良い。如何なる数のハッシュ値が、ヘッダ（例えば、H0、Hl、H2、H3、H4）に供されても良い。しかしながら、ハッシュサブブロックに供されないヘッダだけを含むことが望ましいかもしれない（例えば図３参照）。
【００７１】
図７Ａの例で、フローチャート７００は、モジュール７０８に進み、将来のレファレンスのために(for future reference)、階層的ハッシュツリーをキャッシュする(caching)。少なくとも１つの実施形態では、階層的ハッシュツリーをキャッシュするということは、データブロック検証プロセスの間の速度を幾分改善できる結果をもたらすことができる。しかしながら、階層的ハッシュツリーをキャッシュせずに続行する理由が存在するかもしれず、これはこの技術の有効性を損なわないはずである。
【００７２】
図７Ａの例で、フローチャート７００は、モジュール７１０に進み、データ構造から、階層的ハッシュツリーの第１のルートハッシュを獲得する。データ構造はハッシュ値群とは独立して認証（７０４）されているために、結果としては更なるセキュリティをもたらすことができる。
【００７３】
図７Ａの例で、フローチャート７００は、モジュール７１２に進み、ハッシュ値群から第２のルートハッシュを演算する。このハッシュ値はセキュアなもの（技術的に安全性が保証されたもの）かどうかわからないが、ヘッダがブロックベースドメディアデバイスからアクセスされているため、それらは恐らくはブロックベースドメディアデバイスからのものである。
【００７４】
図７Ａの例で、フローチャート７００は、モジュール７１４に進み、第１のルートハッシュを第２のルートハッシュと比較する。なお、データ構造に含まれていた第１のルートハッシュは、既に認証されており（７０４）、第２のルートハッシュはブロックベースドメディアデバイスのヘッダに供されたハッシュ群から導かれたものである。
【００７５】
図７Ａの例で、フローチャート７００は、決定ポイント７１６へと進み、第１のルートハッシュと第２のルートハッシュが一致しているか否かが判定される。第１のルートハッシュと第２のルートハッシュが一致していない場合（モジュール７１６−Ｎ）、その時、ヘッダが拒絶される（さらにフローチャート７００も終了する）。他方、第１のルートハッシュと第２のルートハッシュが一致している場合（モジュール７１６−Ｙ）、フローチャート７００は、任意的なモジュール７１８に進み、ヘッダ以外のソースからの権利マネージメントチケットを有効にする。
【００７６】
図７Ｂの例で、特定の実装形態には可能でないかもしれないし、或いはこの付加的レベルのセキュリティが不要であると思われる可能性があるため、モジュール７１８は任意で行ってもよいし行わなくてもよい。ヘッダ以外のソースからの権利マネージメントチケットが使用されているなら、その際、権利マネージメントチケット使用方法は、モジュール７０４、７１０、７１４に関して説明されたものと同様である。説明のために、この任意のモジュールが使用されるなら、有効化(validation)が成功した状態にある（それ故、ヘッダが拒絶されない）と推測される。
【００７７】
図７Ｂの例で、フローチャート７００は、モジュール７２０に進み、ここでデータ構造から暗号化された鍵を入手する。最初、そのデータ構造が認証され（７０４）、鍵がデータ構造から抽出される際に暗号化されるため、この鍵は特にセキュアなもの（技術的に安全性が保証されたもの）である。
【００７８】
図７Ｂの例で、フローチャート７００は、モジュール７２２に進み、ここで暗号化された鍵をセキュアに（技術的に安全性が保証された状態で）復号化する。“セキュアに復号化する”ということで、鍵がセキュアカーネルで復号化されることが前提となる。セキュアカーネルのそれに整合できるどんなセキュリティレベルも適当なものとなるであろう。しかしながら、セキュアカーネルによって提供されたセキュリティと同等であるなら、そのような多くのセキュリティ機構は、単に、何か他のものとして改名されたセキュアカーネルであっても良い。それにもかかわらず、十分にセキュアな機構が公知又は手頃なものであるならば、ここに説明された技術が適用可能であるかもしれない。
【００７９】
図７Ｂの例で、フローチャート７００は、モジュール７２４に進み、鍵をセキュアに格納する。“セキュアに格納すること”ということで、鍵は、セキュアカーネルに格納されるか、又はセキュアプロセッサによってアクセスされるセキュアカーネルに関連するメモリに格納されることが前提となる。又、セキュアカーネルのそれに整合できるどんなセキュリティレベルも適当なものとなるであろう。
【００８０】
図７Ｂの例で、フローチャート７００は、モジュール７２６に進み、鍵へのリファレンスを平文で提供する。それに限定されない例により、ブロックベースドメディアドライバは鍵へのリファレンスを受けるようにしても良い。その際、ブロックベースドメディアドライバは、鍵へのリファレンスを、例えば鍵アクセスのためにリファレンスを使用できるセキュアカーネルに戻すように発信しても良い。このようにして、鍵はセキュアカーネルに残ることができ、リファレンスだけが平文状態になる。
【００８１】
図７Ｂの例で、フローチャート７００は、モジュール７２８に進み、セキュア復号化エンジンに鍵のリファレンスを供する。“セキュア復号化エンジンであること”ということで、復号化エンジンはセキュアカーネルの一部、または同等の物であることが前提となる。これにより鍵の、平文状態での使用さえも回避される。
【００８２】
図７Ｂの例で、フローチャート７００は、モジュール７３０に進み、ここでデータブロックを復号化する。データブロックは、セキュアに復号化される。その後、フローチャート７００は、任意でモジュール７３２に進み、データブロックのサブブロックが復号化される。このレベルのセキュリティが不必要なものかどうか分らないし、システムの性能をいたずらに低減させるかもしれないので（多分、僅かだが）、この処理は任意で行っても良いし行わなくても良い。
【００８３】
図７Ｃの例では、フローチャート７００は、モジュール７３４に進み、サブブロックから認証データを読み込み、続くモジュール７３６では、この認証データにおいて、階層的ハッシュツリーの第１のレベルに関連する第１のハッシュ値群を識別する(identifying)。第１のレベルは図２のH0に対応するかもしれない。レベルの数は本例方法の一部でない実施詳細である。
【００８４】
図７Ｃの例で、フローチャート７００は、モジュール７３８に進み、第１ハッシュ値を決定するべくデータブロックの暗号学的ハッシュを演算し、続くモジュール７４０では、第１ハッシュ値を、第１のハッシュ値群の対応値と比較する。
【００８５】
図７Ｃの例で、フローチャート７００は、決定ポイント７４２に進み、第１ハッシュ値と、第１のハッシュ値群の対応値とが一致しているか否か判定される。第１ハッシュ値と、第１のハッシュ値群の対応値とが一致していない場合（モジュール７４２−Ｎ）、データブロック読み出し要求は拒絶される（そして、フローチャート７００は終了する）。他方、第１ハッシュ値と、第１のハッシュ値群の対応値とが一致している場合（モジュール７４２−Ｙ）、その際、フローチャート７００は、モジュール７４４に進み、ここで適宜ハッシュを演算して、比較する。演算と比較の反復回数は恐らく階層的ハッシュツリーのレベル数に依存し、それは実装の形態によって変化する。
【００８６】
図７Ｃの例で、フローチャート７００は、決定ポイント７４６に進み、ハッシュ比較のすべてが一致という結果になるか否かが判定される。ハッシュ比較のすべてが一致という結果にならないと判定された場合（モジュール７４６−Ｎ）、データブロック読み出し要求は拒絶される（そして、フローチャート７００は終了する）。他方、ハッシュ比較のすべてが一致という結果になったと判定された場合（モジュール７４６−Ｙ）、データブロックが戻される（そして、フローチャート７００は終了する）。推定するに、アクセス前にこれを参照した当業者には明白であるように、これらモジュールの幾つかは、その後のデータブロックアクセスのために繰り返される必要はないだろう。
【００８７】
ここで使用されたように、用語“コンテンツ”は、メモリに格納可能な如何なるデータをも広く含むことを意図する。
【００８８】
ここで使用されたように、用語“実施形態”は、それに限定されない一例として説明を行うための実施例を意味している。
【００８９】
当業者であれば前述した実施例と実施形態は、代表的なものであり、本発明の範囲を限定するものでないことが理解されるであろう。当業者が明細書を考慮し、図面を検討したときに自明な置き換え、増強、均等物やそれらへの改良が、本発明の要旨と範囲に含まれることを意図している。したがって、添付された特許請求の範囲は、本発明の要旨と範囲内にあるこのような総ての変更、置き換え、均等物を含むことを意図している。
【符号の説明】
【００９０】
１００ 二分木構造
２００ 非二分木構造
３００ 32KBブロック
３０２ ハッシュブロック
３０４ 1KBデータブロック
３１０ H0ハッシュ／パディング
３１２ H1ハッシュ／パディング
３１４ H2ハッシュ／パディング
４００ コンピュータ・システム
４０２ コンピュータ
４０４ I/Oデバイス
４０６ ディスプレイデバイス
４０８ プロセッサ
４１０ 通信インターフェース
４１２ メモリ
４１４ ディスプレイコントローラ
４１６ 不揮発性記憶装置
４１８ I/Oコントローラ
５００ セキュアシステム
５０２ セキュアプロセッサ
５０４ OS（オペレーティングシステム）
５０６ ブロックベースドメディアドライバ
５０８ ブロックベースドメディアデバイス
５１０ プロテクト・メモリ
５１２ チケットサービス
５１４ セキュリティカーネル
５１６ 鍵ストア
５１７ 暗号化/復号化エンジン
５１８ セキュリティAPI
５２０ ヘッダアクセス矢印
５２２ 認証データ矢印
５２４ 鍵復号化要求矢印
５２６ 鍵へのリファレンス矢印
５２８ チケット有効化矢印
５３０ データブロックアクセス矢印
５３２ ブロック復号化要求矢印
５３４ ハッシュツリー有効化矢印
【特許請求の範囲】
【請求項１】
データ構造とハッシュ値群とを含むヘッダにアクセスし、
前記データ構造から、階層的ハッシュツリーの第１のルートハッシュを獲得し、
前記ハッシュ値群から第２のルートハッシュを演算し、
前記第１のルートハッシュを、前記第２のルートハッシュと比較し、
第１のルートハッシュと第２のルートハッシュとが一致する場合に、
前記データ構造から、暗号化された鍵を獲得し、
前記暗号化された鍵をセキュアに復号化し、
前記鍵が平文の形で送付されないように、前記鍵をセキュアに格納し、
前記鍵にリファレンスを提供し、
前記データブロックを前記鍵への前記リファレンスで復号化し、
前記データブロックに関連するサブブロックから認証データを読み込み、
前記認証データにおいて、前記階層的ハッシュツリーの第１のレベルに関連する第１のハッシュ値群を識別し、
第１ハッシュ値を決定するために、前記データブロックの暗号学的ハッシュを演算し、
前記第１ハッシュ値を、前記第１ハッシュ値群における対応値と比較し、
前記第１ハッシュ値と、前記第１ハッシュ値群の前記対応値が一致しない場合に、ブロックデータの要求を拒絶することを特徴とする方法。
【請求項２】
前記データ構造は署名された公開鍵であることを特徴とする請求項１に記載の方法。
【請求項３】
更に、前記データ構造を認証することを特徴とする請求項１に記載の方法。
【請求項４】
更に、ヘッダに含まれた前記ハッシュ値群をセキュアに格納することを特徴とする請求項１に記載の方法。
【請求項５】
更に、前記階層的ハッシュツリーをキャッシュすることを特徴とする請求項１に記載の方法。
【請求項６】
更に、前記第１のルートハッシュと前記第２のルートハッシュが一致していないならば、前記ヘッダを拒絶することを特徴とする請求項１に記載の方法。
【請求項７】
更に、前記ヘッダ以外のソースから権利マネージメントチケットを有効にすることを特徴とする請求項１に記載の方法。
【請求項８】
前記鍵への前記リファレンスは、平文で提供されることを特徴とする請求項１に記載の方法。
【請求項９】
前記鍵への前記リファレンスでデータブロックを復号化する処理は、更に
セキュア復号化エンジンに対し前記鍵へのリファレンスを提供し、
前記鍵が平文で送付されないように、前記データブロックを復号化することを特徴とする請求項１に記載の方法。
【請求項１０】
更に、少なくとも前記サブブロックの一部を復号化することを特徴とする請求項１に記載の方法。
【請求項１１】
更に、各ハッシュブロックにおいて、
計算で求められたハッシュを適切なロケーションに挿入し、
前記ハッシュブロックのハッシュを演算することを特徴とする請求項１に記載の方法。
【請求項１２】
前記第１ハッシュ値が、前記第１のハッシュ値群の前記対応値と一致する場合、
前記第１のハッシュ値群に対応する第２ハッシュ値を演算し、
前記認証データにおいて、前記階層的ハッシュツリーの第２のレベルに関連する第２のハッシュ値群を識別し、
前記第２ハッシュ値を、前記第２のハッシュ値群における対応値と比較し、
前記第２ハッシュ値と、前記第２のハッシュ値群の前記対応値とが一致していない場合に、前記ブロックデータの要求を拒絶することを特徴とする請求項１に記載の方法。
【請求項１３】
前記第２ハッシュ値が、前記第２のハッシュ値群の前記対応値と一致する場合、
前記第２のハッシュ値群に対応する第３ハッシュ値を演算し、
前記認証データにおいて、前記階層的ハッシュツリーの第３のレベルに関連する第３のハッシュ値群を識別し、
前記第３ハッシュ値を、前記第３のハッシュ値群における対応値と比較し、
前記第３ハッシュ値と、前記第３のハッシュ値群の前記対応値とが一致していない場合に、前記ブロックデータの要求を拒絶することを特徴とする請求項１２に記載の方法。
【請求項１４】
前記第３ハッシュ値が、前記第３のハッシュ値群の前記対応値と一致し、前記ヘッダのハッシュ値群が第４のハッシュ値群であり、前記第４ハッシュ値群が前記階層的ハッシュツリーの第４のレベルに関連する場合、
前記第３のハッシュ値群に対応する第４ハッシュ値を演算し、
前記階層的ハッシュツリーの第４のレベルに関連する第４のハッシュ値群を提供し、
前記第４ハッシュ値を、前記第４のハッシュ値群における対応値と比較し、
前記第４ハッシュ値と、前記第４のハッシュ値群の前記対応値とが一致していない場合に、前記ブロックデータの要求を拒絶し、
前記第４ハッシュ値と、前記第４のハッシュ値群の前記対応値とが一致している場合に、前記ブロックデータを戻すことを特徴とする請求項１３に記載の方法。
【請求項１５】
セキュリティAPIに接続されたブロックベースドメディアドライバであって、その動作において、ブロックベースドメディアデバイスに関連するヘッダにアクセスし、前記ヘッダから認証データを抽出するような前記ブロックベースドメディアドライバと、
前記セキュリティAPIと前記ブロックベースドメディアドライバに接続されるチケットサービスであって、その動作において、前記ブロックベースドメディアドライバからの前記認証データを受け取り、前記セキュリティAPIに鍵復号化要求を送るような前記チケットサービスと、
前記セキュリティAPI、暗号化/復号化エンジン、及び前記セキュリティAPIにアクセス可能な鍵ストアを含むセキュリティカーネルであって、その動作において、前記暗号化/復号化エンジンが鍵を復号化し、前記鍵は前記鍵ストアに格納され、前記セキュリティAPIは前記チケットサービスに、前記鍵に対するリファレンスを戻すような前記セキュリティカーネルとを備えるシステムであって、
動作において、前記チケッサービスは、前記認証データを有効化し、前記ブロックベースドメディアドライバに、前記鍵に対する前記リファレンスを戻し、
動作において、前記ブロックベースドメディアドライバは、前記ブロックベースドメディアデバイスのデータブロックにアクセスし、前記セキュリティAPIにブロック復号化要求を送り、前記セキュリティカーネルは、前記ブロックを復号化し、前記データブロックに関連する階層的ハッシュツリーを有効化することを特徴とするシステム。
【請求項１６】
更に、ブロックベースドメディアデバイスを更に備え、前記ブロックベースドメディアデバイスに関連するヘッダが、ルートハッシュ値と複数のルートの子のハッシュ値を含んでいることを特徴とする請求項１５に記載のシステム。
【請求項１７】
更に、ブロックベースドメディアデバイスを更に備え、前記データブロックの各々は、ハッシュサブブロックと、複数のコンテンツデータブロックを含むことを特徴とする請求項１５に記載のシステム。
【請求項１８】
ブロックベースドメディアと共にセキュアコンテンツ配信のための手段を有するシステムであって、
セキュア鍵ストア手段と、
ブロックベースドメディアデバイスのヘッダから暗号化された鍵にアクセスするための手段と、
前記暗号化された鍵をセキュアに復号化するための手段と、
前記鍵ストアに前記鍵をセキュアに格納する手段と、
前記ブロックベースドメディアデバイスのデータブロックをセキュアに復号化するために、前記鍵にリファレンスを与えるための手段と、
前記ブロックベースドメディアデバイスと前記ブロックベースドメディアデバイスの各データブロックに関連するハッシュ値を提供するための手段とを備えることを特徴とするシステム。
【請求項１９】
前記ヘッダのハッシュ値が拒絶された場合に、前記ブロックベースドメディアデバイスへのアクセスを中止するための手段を更に備えることを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記データブロックのハッシュ値が拒絶された場合に、前記データブロックへのアクセスを中止するための手段を更に備えることを特徴とする請求項１８に記載のシステム。
【請求項２１】
データ構造とハッシュ値群とを含むヘッダにアクセスし、
前記データ構造から階層的なハッシュツリーの第１のルートハッシュを獲得し、
前記ハッシュ値群から第２のルートハッシュを演算し、
前記第１のルートハッシュを、前記第２のルートハッシュと比較し、
前記第１のルートハッシュと、第２ルートハッシュ値とが一致する場合に、
前記データ構造から、暗号化された鍵を獲得し、
前記暗号化された鍵を、セキュアに復号化し、
前記鍵が平文の形で送付されないように、前記鍵をセキュアに格納し、
前記鍵にリファレンスを提供し、
暗号化されたデータブロックに関連するサブブロックから認証データを読み込み、
前記認証データにおいて、前記階層的ハッシュツリーの第１のレベルに関連する第１のハッシュ値群を識別し、
第１ハッシュ値を決定するために、前記暗号化されたデータブロックの暗号学的ハッシュを演算し、
前記第１ハッシュ値を、前記第１ハッシュ値群における対応値と比較し、
前記第１ハッシュ値と、前記第１ハッシュ値群の前記対応値が一致しない場合に、ブロックデータの要求を拒絶し、
前記鍵に対するリファレンスで、前記暗号化されたデータブロックを復号化することを特徴とする方法。
【請求項１】
データ構造とハッシュ値群とを含むヘッダにアクセスし、
前記データ構造から、階層的ハッシュツリーの第１のルートハッシュを獲得し、
前記ハッシュ値群から第２のルートハッシュを演算し、
前記第１のルートハッシュを、前記第２のルートハッシュと比較し、
第１のルートハッシュと第２のルートハッシュとが一致する場合に、
前記データ構造から、暗号化された鍵を獲得し、
前記暗号化された鍵をセキュアに復号化し、
前記鍵が平文の形で送付されないように、前記鍵をセキュアに格納し、
前記鍵にリファレンスを提供し、
前記データブロックを前記鍵への前記リファレンスで復号化し、
前記データブロックに関連するサブブロックから認証データを読み込み、
前記認証データにおいて、前記階層的ハッシュツリーの第１のレベルに関連する第１のハッシュ値群を識別し、
第１ハッシュ値を決定するために、前記データブロックの暗号学的ハッシュを演算し、
前記第１ハッシュ値を、前記第１ハッシュ値群における対応値と比較し、
前記第１ハッシュ値と、前記第１ハッシュ値群の前記対応値が一致しない場合に、ブロックデータの要求を拒絶することを特徴とする方法。
【請求項２】
前記データ構造は署名された公開鍵であることを特徴とする請求項１に記載の方法。
【請求項３】
更に、前記データ構造を認証することを特徴とする請求項１に記載の方法。
【請求項４】
更に、ヘッダに含まれた前記ハッシュ値群をセキュアに格納することを特徴とする請求項１に記載の方法。
【請求項５】
更に、前記階層的ハッシュツリーをキャッシュすることを特徴とする請求項１に記載の方法。
【請求項６】
更に、前記第１のルートハッシュと前記第２のルートハッシュが一致していないならば、前記ヘッダを拒絶することを特徴とする請求項１に記載の方法。
【請求項７】
更に、前記ヘッダ以外のソースから権利マネージメントチケットを有効にすることを特徴とする請求項１に記載の方法。
【請求項８】
前記鍵への前記リファレンスは、平文で提供されることを特徴とする請求項１に記載の方法。
【請求項９】
前記鍵への前記リファレンスでデータブロックを復号化する処理は、更に
セキュア復号化エンジンに対し前記鍵へのリファレンスを提供し、
前記鍵が平文で送付されないように、前記データブロックを復号化することを特徴とする請求項１に記載の方法。
【請求項１０】
更に、少なくとも前記サブブロックの一部を復号化することを特徴とする請求項１に記載の方法。
【請求項１１】
更に、各ハッシュブロックにおいて、
計算で求められたハッシュを適切なロケーションに挿入し、
前記ハッシュブロックのハッシュを演算することを特徴とする請求項１に記載の方法。
【請求項１２】
前記第１ハッシュ値が、前記第１のハッシュ値群の前記対応値と一致する場合、
前記第１のハッシュ値群に対応する第２ハッシュ値を演算し、
前記認証データにおいて、前記階層的ハッシュツリーの第２のレベルに関連する第２のハッシュ値群を識別し、
前記第２ハッシュ値を、前記第２のハッシュ値群における対応値と比較し、
前記第２ハッシュ値と、前記第２のハッシュ値群の前記対応値とが一致していない場合に、前記ブロックデータの要求を拒絶することを特徴とする請求項１に記載の方法。
【請求項１３】
前記第２ハッシュ値が、前記第２のハッシュ値群の前記対応値と一致する場合、
前記第２のハッシュ値群に対応する第３ハッシュ値を演算し、
前記認証データにおいて、前記階層的ハッシュツリーの第３のレベルに関連する第３のハッシュ値群を識別し、
前記第３ハッシュ値を、前記第３のハッシュ値群における対応値と比較し、
前記第３ハッシュ値と、前記第３のハッシュ値群の前記対応値とが一致していない場合に、前記ブロックデータの要求を拒絶することを特徴とする請求項１２に記載の方法。
【請求項１４】
前記第３ハッシュ値が、前記第３のハッシュ値群の前記対応値と一致し、前記ヘッダのハッシュ値群が第４のハッシュ値群であり、前記第４ハッシュ値群が前記階層的ハッシュツリーの第４のレベルに関連する場合、
前記第３のハッシュ値群に対応する第４ハッシュ値を演算し、
前記階層的ハッシュツリーの第４のレベルに関連する第４のハッシュ値群を提供し、
前記第４ハッシュ値を、前記第４のハッシュ値群における対応値と比較し、
前記第４ハッシュ値と、前記第４のハッシュ値群の前記対応値とが一致していない場合に、前記ブロックデータの要求を拒絶し、
前記第４ハッシュ値と、前記第４のハッシュ値群の前記対応値とが一致している場合に、前記ブロックデータを戻すことを特徴とする請求項１３に記載の方法。
【請求項１５】
セキュリティAPIに接続されたブロックベースドメディアドライバであって、その動作において、ブロックベースドメディアデバイスに関連するヘッダにアクセスし、前記ヘッダから認証データを抽出するような前記ブロックベースドメディアドライバと、
前記セキュリティAPIと前記ブロックベースドメディアドライバに接続されるチケットサービスであって、その動作において、前記ブロックベースドメディアドライバからの前記認証データを受け取り、前記セキュリティAPIに鍵復号化要求を送るような前記チケットサービスと、
前記セキュリティAPI、暗号化/復号化エンジン、及び前記セキュリティAPIにアクセス可能な鍵ストアを含むセキュリティカーネルであって、その動作において、前記暗号化/復号化エンジンが鍵を復号化し、前記鍵は前記鍵ストアに格納され、前記セキュリティAPIは前記チケットサービスに、前記鍵に対するリファレンスを戻すような前記セキュリティカーネルとを備えるシステムであって、
動作において、前記チケッサービスは、前記認証データを有効化し、前記ブロックベースドメディアドライバに、前記鍵に対する前記リファレンスを戻し、
動作において、前記ブロックベースドメディアドライバは、前記ブロックベースドメディアデバイスのデータブロックにアクセスし、前記セキュリティAPIにブロック復号化要求を送り、前記セキュリティカーネルは、前記ブロックを復号化し、前記データブロックに関連する階層的ハッシュツリーを有効化することを特徴とするシステム。
【請求項１６】
更に、ブロックベースドメディアデバイスを更に備え、前記ブロックベースドメディアデバイスに関連するヘッダが、ルートハッシュ値と複数のルートの子のハッシュ値を含んでいることを特徴とする請求項１５に記載のシステム。
【請求項１７】
更に、ブロックベースドメディアデバイスを更に備え、前記データブロックの各々は、ハッシュサブブロックと、複数のコンテンツデータブロックを含むことを特徴とする請求項１５に記載のシステム。
【請求項１８】
ブロックベースドメディアと共にセキュアコンテンツ配信のための手段を有するシステムであって、
セキュア鍵ストア手段と、
ブロックベースドメディアデバイスのヘッダから暗号化された鍵にアクセスするための手段と、
前記暗号化された鍵をセキュアに復号化するための手段と、
前記鍵ストアに前記鍵をセキュアに格納する手段と、
前記ブロックベースドメディアデバイスのデータブロックをセキュアに復号化するために、前記鍵にリファレンスを与えるための手段と、
前記ブロックベースドメディアデバイスと前記ブロックベースドメディアデバイスの各データブロックに関連するハッシュ値を提供するための手段とを備えることを特徴とするシステム。
【請求項１９】
前記ヘッダのハッシュ値が拒絶された場合に、前記ブロックベースドメディアデバイスへのアクセスを中止するための手段を更に備えることを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記データブロックのハッシュ値が拒絶された場合に、前記データブロックへのアクセスを中止するための手段を更に備えることを特徴とする請求項１８に記載のシステム。
【請求項２１】
データ構造とハッシュ値群とを含むヘッダにアクセスし、
前記データ構造から階層的なハッシュツリーの第１のルートハッシュを獲得し、
前記ハッシュ値群から第２のルートハッシュを演算し、
前記第１のルートハッシュを、前記第２のルートハッシュと比較し、
前記第１のルートハッシュと、第２ルートハッシュ値とが一致する場合に、
前記データ構造から、暗号化された鍵を獲得し、
前記暗号化された鍵を、セキュアに復号化し、
前記鍵が平文の形で送付されないように、前記鍵をセキュアに格納し、
前記鍵にリファレンスを提供し、
暗号化されたデータブロックに関連するサブブロックから認証データを読み込み、
前記認証データにおいて、前記階層的ハッシュツリーの第１のレベルに関連する第１のハッシュ値群を識別し、
第１ハッシュ値を決定するために、前記暗号化されたデータブロックの暗号学的ハッシュを演算し、
前記第１ハッシュ値を、前記第１ハッシュ値群における対応値と比較し、
前記第１ハッシュ値と、前記第１ハッシュ値群の前記対応値が一致しない場合に、ブロックデータの要求を拒絶し、
前記鍵に対するリファレンスで、前記暗号化されたデータブロックを復号化することを特徴とする方法。
【図２】
【図３】
【図６Ａ】
【図６Ｂ】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図１】
【図４】
【図５】
【図３】
【図６Ａ】
【図６Ｂ】
【図７Ａ】
【図７Ｂ】
【図７Ｃ】
【図１】
【図４】
【図５】
【公表番号】特表２０１０−５０７３２８（Ｐ２０１０−５０７３２８Ａ）
【公表日】平成２２年３月４日（２０１０．３．４）
【国際特許分類】
【出願番号】特願２００９−５３３２９９（Ｐ２００９−５３３２９９）
【出願日】平成１９年９月１２日（２００７．９．１２）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０１９８６２
【国際公開番号】ＷＯ２００８／０４８４０３
【国際公開日】平成２０年４月２４日（２００８．４．２４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．リナックス
【出願人】（５０５２８６７１８）ブロードオン コミュニケーションズ コーポレーション (8)
【氏名又は名称原語表記】ＢｒｏａｄＯｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．
【Ｆターム（参考）】
【公表日】平成２２年３月４日（２０１０．３．４）
【国際特許分類】
【出願日】平成１９年９月１２日（２００７．９．１２）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０１９８６２
【国際公開番号】ＷＯ２００８／０４８４０３
【国際公開日】平成２０年４月２４日（２００８．４．２４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．リナックス
【出願人】（５０５２８６７１８）ブロードオン コミュニケーションズ コーポレーション (8)
【氏名又は名称原語表記】ＢｒｏａｄＯｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．
【Ｆターム（参考）】
[ Back to top ]