(57)【要約】  本発明は、システムデータの完全性の検証装置に関し、より詳細には、信頼できない装置を失効するための失効データを含むＥＫＢ（Ｅｆｆｅｃｔｉｖｅ  Ｋｅｙ  Ｂｌｏｃｋ）またはＭＫＢ（Ｍｅｄｉａ  Ｋｅｙ  Ｂｌｏｃｋ）のようなコピー保護情報の完全性の検証装置に関する。現在、コンテンツ保護に関する暗号情報はディスクに予め記録されている。セキュリティリスクを有するこの情報の変更を回避するため、従来方法により、暗号情報の暗号ハッシュが読み出し専用としてディスクに格納される。しかしながら、従来方法による処理は、処理速度が遅く、始動時間を増大させてしまう。本発明のよるシステムデータの完全性の検証方法によりこの問題が解決される。本方法は、システムデータから暗号鍵を生成するステップと、ハッシュ関数を利用して前記暗号鍵からチェックデータを生成するステップと、前記生成されたチェックデータと前記チェックデータの信頼できるものとを比較することにより前記システムデータの完全性を検証するステップとを有する。本発明はさらに、そのようなチェックデータの生成方法、対応する装置、記憶媒体及びコンピュータプログラムに関する。
2005512258.tif 000002
【特許請求の範囲】
【請求項１】
システムデータの完全性を検証するための方法であって、
前記システムデータから暗号鍵を生成するステップと、
ハッシュ関数を利用して前記暗号鍵からチェックデータを生成するステップと、
前記生成されたチェックデータと前記チェックデータの信頼できるものとを比較することにより前記システムデータの完全性を検証するステップとを有することを特徴とする方法。
【請求項２】
請求項１記載の方法であって、前記チェックデータの信頼できるものは記録キャリアから取得され、特に、読み出し専用領域あるいはチャンネルに前記信頼できるものを格納する記録キャリアから読み出されることを特徴とする方法。
【請求項３】
請求項１記載の方法であって、前記チェックデータの信頼できるものは信頼できる第三者から受け取られ、特に、インターネットのようなネットワークを介しライセンス供与当局から受け取られることを特徴とする方法。
【請求項４】
請求項３記載の方法であって、前記チェックデータの信頼できるものは暗号化形式で前記第三者から受け取られ、前記生成されたチェックデータとの比較前にまず解読されることを特徴とする方法。
【請求項５】
請求項１記載の方法であって、前記ハッシュ関数は一方向ハッシュ関数であることを特徴とする方法。
【請求項６】
請求項１記載の方法であって、前記ハッシュ関数は固定された入力を有する暗号化関数であることを特徴とする方法。
【請求項７】
請求項７記載の方法であって、前記固定された入力は記録キャリアから取得され、特に、読み出し専用領域あるいはチャンネルに入力を格納する記録キャリアから読み出されることを特徴とする方法。
【請求項８】
請求項１記載の方法であって、前記システムデータはコピー保護データを、特に、光記録キャリアの再生、記録あるいは複製のための再生装置、記録装置あるいは複製装置のような信頼できない装置を失効するためのＥＫＢ（Ｅｆｆｅｃｔｉｖｅ  Ｋｅｙ  Ｂｌｏｃｋ）あるいはＭＫＢ（Ｍｅｄｉａ  Ｋｅｙ  Ｂｌｏｃｋ）のような失効データを有することを特徴とする方法。
【請求項９】
請求項８記載の方法であって、前記暗号鍵はユーザデータの暗号化及び/または復号化に利用されることを特徴とする方法。
【請求項１０】
請求項８記載の方法であって、前記チェックデータの信頼できるものは前記コピー保護データの少なくとも一部を、特に、前記ＥＫＢの記述部を有することを特徴とすることを特徴とする方法。
【請求項１１】
請求項７記載の方法であって、前記チェックデータの信頼できるものは、前記暗号鍵のハッシュ関数と、前記コピー保護データの少なくとも一部、特に、前記ＥＫＢの記述部を有することを特徴とする方法。
【請求項１２】
システムデータの完全性を検証するためのチェックデータを生成する方法であって、
前記システムデータから暗号鍵を生成するステップと、
ハッシュ関数を利用して前記暗号鍵からチェックデータを生成するステップと、
前記システムデータを格納する記録キャリアにおける読み出し専用領域あるいはチャンネルへの格納のため、あるいは送信ラインを介した送信のため、前記チェックデータを提供するステップとを有することを特徴とする方法。
【請求項１３】
システムデータの完全性の検証装置であって、
前記システムデータから暗号鍵を生成する手段と、
ハッシュ関数を利用して前記暗号鍵からチェックデータを生成する手段と、
前記生成されたチェックデータと前記チェックデータの信頼できるものとを比較することにより、前記システムデータの完全性を検証する手段とを有することを特徴とする装置。
【請求項１４】
システムデータを格納する光記録キャリアの再生及び/または記録装置であって、
前記記録キャリアから前記システムデータを読み出す手段と、
請求項１３記載の検証装置と、
前記検証装置から受け取る検証結果に応じて再生及び/または記録を中断する手段とを有することを特徴とする装置。
【請求項１５】
システムデータの完全性を検証するためのチェックデータの生成装置であって、
前記システムデータから暗号鍵を生成する手段と、
ハッシュ関数を利用して前記暗号鍵からチェックデータを生成する手段と、
前記システムデータを格納する記録キャリアにおける読み出し専用領域あるいはチャンネルへの格納のため、あるいは送信ラインを介した送信のため、前記チェックデータを提供する手段とを有することを特徴とする装置。
【請求項１６】
データを格納するための記憶媒体であって、
システムデータを、特に、信頼できない装置の失効のためのコピー保護データを格納する記録可能なデータ領域と、
前記システムデータの完全性を検証するためのチェックデータを格納する読み出し専用データ領域とを有し、前記チェックデータはハッシュ関数を利用して暗号鍵から生成され、前記生成されたチェックデータと前記チェックデータの信頼できるものとを比較することにより前記システムデータの完全性を検証するために利用され、前記暗号鍵は前記システムデータから生成されることを特徴とする記憶媒体。
【請求項１７】
請求項１６記載の記憶媒体であって、前記読み出し専用領域はさらに前記ハッシュ関数への入力を格納し、前記チェックデータは規格を通じて固定化されることを特徴とする記憶媒体。
【請求項１８】
請求項１または１２記載の方法をコンピュータに実行させるためのプログラムコード手段を有するコンピュータプログラム。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
本発明は、システムデータの完全性（ｉｎｔｅｇｒｉｔｙ）の検証方法、システムデータの完全性を検証するためのチェックデータ生成方法、対応する装置、データを格納するための記憶メディア及びコンピュータプログラムに関する。
【０００２】
近年、ＤＶＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ＋ＲＷ及びＤＶＲのような光メディア規格は失効（ｒｅｖｏｃａｔｉｏｎ）を採用し始めている。失効とは、ハッキングされたとわかったレコーダやプレーヤーを無効にする機構である。これは、ＭＫＢ（Ｍｅｄｉａ  Ｋｅｙ  Ｂｌｏｃｋ）やＥＫＢ（Ｅｆｆｅｃｔｉｖｅ  Ｋｅｙ  Ｂｌｏｃｋ）として知られる情報ブロックを、書き換え可能あるいは記録可能なブランクメディアにマスタ記録することにより実現される。特に、ＥＫＢはＷＯ０１／７８２９８Ａ１及びＷＯ０１／７８２９９Ａ１から既知であり、参照することによりここに含まれる。このような鍵ブロックは、レコーダやプレーヤーが音楽、映画やソフトウェアなどのユーザデータをそのようなブランクメディアへの暗号化に必要な情報を有する。ある装置がハッキングされているとわかると、新しいブランクメディアの鍵ブロックが、当該装置がその鍵ブロックをもはや利用できないように、そしてその他すべての装置は依然として利用できるよう変更される。以下において、特に断りがない場合、ＭＫＢとＥＫＢの両方を意味するＥＫＢが参照される。
【０００３】
ＥＫＢ装置失効構成は、シンプルな（すなわち、安価な）装置に有効な対称暗号化方式に完全に基づいている。ＥＫＢの他の効果は、それのよく構成された設計のため、少数の装置のみが失効される場合には、そのサイズは小さくて済む。ＥＫＢが大きいものとなるのは、多数の装置が失効される場合のみである（他方、例えば、ＣＰＲＭのＭＫＢでは、１、２台の装置が失効される場合でもその最大サイズまで増大しうる）。
【０００４】
ＥＫＢ構成の問題点は、十分な（少ない）台数の装置がハッキングされると、すなわち、ある装置に一意的な装置鍵群が公開されると、アタッカーが比較的容易にＥＫＢを偽造できてしまうという点である。従って、問題となるのは、特に記録可能あるいは書き換え可能なメディアに記録されているＥＫＢの場合に真のＥＫＢと偽のＥＫＢをどのように見分けるかという点である。１つの解決法として、完全なＥＫＢのデジタルサインハッシュをそのヘッダ部分に含めるというものがあり、任意のビット変更がデジタル署名をチェックする装置により検出可能とすることができる。しかしながら、このデジタル署名はＥＫＢシステムを維持する当局により生成されるということに注意せねばならない。
【０００５】
技術的には、鍵ブロックがディスクの通常の利用に影響を及ぼさないように、予めマスタ記録された情報を有する光ディスクを作成することは大きな挑戦である。メディア製造業者とレコーダ製造業者の両方の使いやすさを同時に最適化することは困難である。一例となる技術として、鍵ブロックを空のディスクに「プレエンボス（ｐｒｅ−ｅｍｂｏｓｓ）」するというものがある。このような鍵ブロックは装置において読み出しが容易であるが、低歩留まりのためディスク製作コストは高くなると同時に、書き込みの質は低いものとなる。他方、鍵ブロックをウォブルのようなサブチャンネルに記録するテクニックは、低コストで高品質のメディアの作成を可能にするが、ウォブルの低データチャンネルのため、読み出しはきわめて低速なものとなる。
【０００６】
出願番号００２０１９５１．１（ＰＨＮＬ０００３０３ＥＰＰ）による欧州特許出願では、書き換え可能なデータ記憶媒体にデータを記録するための記録装置が説明されている。そこでは、ブランクディスクにアクセスする第１レコーダが、低データレートサブチャンネルの鍵ブロックをディスクのノーマルデータ領域あるいはリードイン領域にコピーするという手法が提案されている。この開示では、鍵ブロックはシステムデータとして呼ばれていることに注意すべきである。このディスクへのアクセスを必要とする以降の装置は、しばしばＨＦチャンネルと呼ばれる、すなわち、通常のユーザデータが書き込まれる高周波数チャンネルである通常の高データレートチャンネルを利用して鍵ブロックにアクセスことができる。他の実現形態では、この鍵ブロックはメディア製造業者によりＨＦチャンネルにすでに書き込まれているかもしれない。ハッカーがＨＦチャンネル（ディスクは書き換え可能）の現在の鍵ブロックを消去しようとし、より新しい鍵ブロックは明らかに古いものより多くの失効された装置を含んでいることによるこの現在鍵ブロックを古い鍵ブロックと取り替えようとする脅威があると考えられる。この問題に対して提案される１つの解決法は、暗号化ハッシュまたは署名を、ユーザによる変更が不可能な、すなわち、ウォブルや（Ｎ）ＢＣＡにおいて、この署名をディスクの一部に格納している鍵ブロック上で計算するというものである。このような領域はしばしばＲＯ（Ｒｅａｄ−Ｏｎｌｙ）サブチャンネルと呼ばれる。
【０００７】
この解決法による問題点は、鍵ブロックへのアクセスを求めるすべての装置がまずはそのような署名を計算し、ＲＯサブチャンネルに含まれるような署名に対してそれを検証しなければならない。この計算は、追加的なハードウェアの点から、しかし大部分は起動時間の点からコストがかかる。現在のドライブはすでに、この署名検証が追加するほとんど許容できないくらい長い起動時間（２０秒のオーダー）を有する。
【０００８】
従って、本発明の課題は、上記問題点を解消する解決法を提供することであり、特に起動時間の問題を解消するとともに、ハッキングに対する高いレベルの防御を提供し、上記鍵ブロックのようなシステムデータの完全さに対する高信頼性を有する検証を可能にすることである。
【０００９】
本課題は、請求項１に記載されるような検証方法と、請求項１１に記載されるような検証装置により実現される。本課題はさらに、請求項１０に記載されるようなシステムデータの完全性を検証するためのチェックデータ生成方法と、請求項１３に記載されるような対応する装置により実現される。上記課題を解決し、本発明を実現するデータ及びコンピュータプログラムを格納する記憶媒体がさらに請求項１４及び１５に記載される。
【００１０】
本発明は、提供されるシステムデータの利用に従って、暗号鍵がすでに生成されているというアイディアに主として基づくものである。すでに通常の起動手続きの一部であるこの暗号化処理は、わずかな追加によりハッシュ計算と同等なものとすることができる。言い換えると、必要とされる暗号鍵が生成され、この暗号鍵からハッシュ関数を利用して生成されたチェックデータを容易にアーカイブすることができる。もしハッカーがシステムデータを変更したとすると、これによる暗号鍵も変更され、これによりもとのシステムデータから最終的にアーカイブされたチェックデータと比較して異なるチェックデータがもたらされる。
【００１１】
従って、システムデータの完全さを検証するため、さらに本発明によると、チェックデータの信頼できるものが、生成されたチェックデータと比較されることにより検証のため提供される。この信頼できるチェックデータはもとのシステムデータから、あるいは暗号鍵から直接生成される。ハッカーがシステムデータを変更すると、生成されたチェックデータと信頼できるチェックデータとの比較により不一致が見出されると、システムデータの変更を検出することが可能となる。
【００１２】
信頼できるチェックデータの生成は、好ましくはＣＤやＤＶＤのような記録キャリアに記憶されるユーザデータの暗号化/復号化のため、秘密鍵である暗号鍵からチェックデータを生成する適当なハッシュ関数を利用するメディア製造業者により好適に実現される。
【００１３】
信頼できるチェックデータの生成はまた、適切なハッシュ関数を利用し、検証のため暗号化あるいは復号化形式で信頼できるチェックデータを提供する暗号化及び復号化のための暗号鍵を提供する鍵ライセンス供与当局のような信頼できる第３者により実現されるかもしれない。このチェックデータは、インターネットや電話網のようなネットワークを介し検証のためそのような信頼できるチェックデータを実際に必要とする装置に送信されてもよい。
【００１４】
システムデータの完全さの検証方法の好適な実施例が従属クレームに含まれる。ここで、本発明によるチェックデータ生成方法、装置、記憶媒体及びコンピュータプログラムがさらに展開され、従属クレームに含まれるような類似あるいは同一の実施例を有する。
【００１５】
好適な実施例では、信頼できるチェックデータが記録キャリアから取得され、特にこの信頼できるチェックデータを読み出し専用領域またはチャンネルに格納している記録キャリアから読み出される。プレーヤーやレコーダのような装置が記録キャリアにアクセスしようとすると、ユーザによる変更が不可な信頼できるチェックデータを利用することにより、記録キャリアの記録可能領域に好適に格納されるシステムデータの完全さのチェックが可能となる。この完全さのチェックが否定的結果を導けば、すなわち、システムデータの変更が発生していれば、アクセスは拒絶される。その後、信頼できるチェックデータが好適には生成され、メディア製造業者や他の信頼された第３者により記録キャリアに記録される。
【００１６】
あるいは、信頼できるチェックデータは信頼できる第３者、特にライセンス供与当局からネットワーク、特にインターネットを介し受け取られる。本実施例は、記録キャリアへのアクセスのためコンピュータが利用される場合に特に好適に利用される。インターネットに接続されたコンピュータはインターネットを介し信頼できるチェックデータを受信することができ、それにより記録キャリアに格納された、あるいは同一あるいは他のネットワークを介し第３者から同時あるいは別々に受信されるシステムデータの完全さを検証することができる。好ましくは、システムデータは同一のライセンス供与当局からインターネットを介し信頼できるチェックデータと共に同時に受信される。
【００１７】
さらに、好ましくは、システムデータから生成された暗号鍵の一方向ハッシュの楕円曲線署名が計算され、リクエストを行った装置への送信のためシステムデータに添付される。これにより信頼できるチェックデータは暗号化あるいは復号化形式となり、第１のケースはシステムデータの完全さを検証するためそれを利用する前に復号化ステップが必要となる。
【００１８】
暗号鍵からチェックデータを構成するハッシュ関数は、チェックデータの計算は容易であるが、このチェックデータから暗号鍵を求めることはきわめて困難であるという意味で、暗号鍵の一方向関数であることが好ましい。もしそうでない場合、ハッカーはチェックデータを読み出し、暗号鍵を計算し、アクセスが認められていないディスク上のすべての暗号化されたコンテンツへのアクセスが可能となってしまう。ハッシュ関数はまた、暗号化のための鍵としてこの暗号鍵を利用した固定された入力を有する暗号化関数であるかもしれない。好ましくは、このハッシュ関数への固定された入力は、記録キャリアから取得され、特に読み出し専用領域またはチャンネルへの入力を格納する記録キャリアから読み込まれる。
【００１９】
一般に、システムデータはその完全さがチェックされる任意のタイプのデータであってよい。好適な応用はコピー保護の分野である。すなわち、システムデータはコピー保護データを、特にＣＤ、ＤＶＤあるいはＤＶＲ技術で利用されるような光記録キャリアの再生、記録または複製のための再生装置、記録装置または複製装置のような信頼できない（ｕｎｔｒｕｓｔｅｄ）装置を失効するＥＫＢやＭＫＢのような失効データを有することが好ましい。従って、ＤＶＩインタフェースを利用してＰＣがもはや映画を送るべきでないレコーダやモニタのリストを含むコピー保護情報は、書き換え可能なディスクに分散させることもできる。
【００２０】
この信頼されたチェックデータがシステムデータの一部を含む場合、特に他の実施例により提案されるようなＥＫＢのきわめて小さな記述部分を含む場合、ハッキングに対するより高いレベルの保護が可能になる。すなわち、暗号鍵からのＥＫＢの偽造が回避可能となる。この信頼できるチェックデータはまた、暗号鍵のハッシュ関数と、少なくともコピー保護データの一部、特にＥＫＢの記述部分を有するかもしれない。
【００２１】
本発明は、システムデータを格納する光記録キャリアを再生及び/または記録する装置に好適に適用され、本装置は、
−前記記録キャリアから前記システムデータを読み出す手段と、
−請求項９記載の検証装置と、
−該検証装置から受信される検証結果に基づき、再生及び/または記録を中断する手段とを有する。
【００２２】
好ましくは光記録キャリアであるデータの格納するための記憶媒体は、
−システムデータ、特に信頼できない装置の失効のためのコピー保護データを格納する記録可能データ領域と、
−システムデータの検証のための、ハッシュ関数を利用して前記システムデータから生成される暗号鍵から生成され、信頼性できるチェックデータとの比較により前記システムデータの完全性の検証に利用されるチェックデータを格納する読み出し専用データ領域とを有する。
【００２３】
ハッシュ関数への入力が前記読み出し専用領域に格納されてもよい。さらに、前記チェックデータは、好ましくは規格により固定化されたものであってもよい。
【００２４】
本発明が図面を参照してより詳細に説明される。
【００２５】
図１は、記録可能ブランクディスクの生成方法と共に、このブランクディスクにアクセスする第１レコーダで実現される以降のステップを示すブロック図を示す。メディア工場１で、予めマスタ記録された情報を有するブランク光ディスクが製造される。この情報には、レコーダやプレーヤーがこのような記録可能ブランクメディアにデータを暗号化したり、そこからデータを復号化したりするのに必要となる情報を含むＥＫＢ（Ｅｆｆｅｃｔｉｖｅ  Ｋｅｙ  Ｂｌｏｃｋ）２、あるいはＭＫＢ（Ｍｅｄｉａ  Ｋｅｙ  Ｂｌｏｃｋ）（図示せず）が含まれる。ＥＫＢ２は、きわめて低いデータレートチャンネルであるウォブルを利用することにより、読み出し専用サブチャンネルに記録される。レーザービームレコーダ（ＬＢＲ）５により、まずマスタディスク６が生成され、その後このマスタディスクから書き換え可能なブランクディスク７がプレス処理される。マスタディスク６に示されるように、ＥＫＢ２はマスタディスク６の読み出し専用領域６２（ＲＯ−ＥＫＢ）に記録される。ディスク７の任意の１つであるブランクディスク９にアクセスする第１レコーダ８は、ＥＫＢを低データレートサブチャンネル９２から、高周波数（ＨＦ）チャンネルと呼ばれるディスク９のノーマルデータ領域９３あるいはリードイン領域にコピーする。このディスク９へのアクセスを要する以降の装置は、低データレートサブチャンネル９２の代わりに、通常の高データレートチャンネル９３を利用することによりＥＫＢにアクセスすることができる。
【００２６】
ハッカーがＨＦチャンネル９３のＥＫＢを消去して、これを古いＥＫＢ、暗号ハッシュまたは署名、すなわち、検証のためのチェックデータに取り替えようとする脅威が存在するため、ＥＫＢ２がハッシュ関数３を利用することにより生成され、この署名がマスタディスク６とユーザによる変更が不可であるブランクディスク７及び９の一部に、例えば、一般には読み出し専用サブチャンネル６１及び９１のウォブルまたは（Ｎ）ＢＣＡに格納される。
【００２７】
さらに、ＬＢＲ５は、アドレス情報、ディスク製造者識別情報及び光記録パラメータのようなブランクディスク７及び９に予めプレスされる情報を含むグルーブデータ４を利用する。このグルーブデータは、しばしばウォブルと呼ばれるディスクの螺旋状の溝に沿った前後の動きにより符号化されるかもしれない。
【００２８】
図２において、システムデータ、すなわち、図１を参照して説明されたようなブランクディスク３の高データレートチャンネル９３に格納されるＥＫＢ２の完全性を検証する従来方法が示される。この方法は、ディスク９へのアクセスを要求するレコーダまたはプレーヤーで実現される。この従来方法によると、高データレートチャンネル９３に格納されたＥＫＢがディスク９から読み出される。その後、チェックデータがハッシュ関数を適用することによりＥＫＢから生成される。このチェックデータは、比較ステップ１１において、ディスク９の読み出し専用データチャンネル９１に格納される署名と比較される。ＥＫＢが変更されていないとすると、生成されるチェックデータと署名は同様のものとなり、装置によるディスク９へのアクセスが許可される。もう一方のケースでは、アクセスは許可されず、再生あるいは記録は中断される。
【００２９】
この従来方法によると、ＥＫＢへのアクセスを求めるすべての装置は、まずそのような署名を計算し、ＲＯサブチャンネルに含まれるような署名に対して検証をしなければならない。この計算は追加的ハードウェア、多くは追加的始動時間の点で比較的コストのかかるもの。本発明は、この始動時間の問題に対する解決法を提供するものである。
【００３０】
本発明を詳細に説明する前に、ＥＫＢによる鍵ブロックの利用の簡単な紹介が与えられる。ＥＫＢの通常処理による結果は秘密鍵であり、一般には、ＥＫＢではｒｏｏｔ＿ｋｅｙｋｒｏｏｔと、ＭＫＢではｍｅｄｉａ＿ｋｅｙＫｍとして知られている。以下では、ＥＫＢという用語が使われる。この暗号鍵を利用して、ディスク上の音楽/映画の暗号化あるいは復号化が行われる。暗号鍵を取得するため、いわゆるｄｅｖｉｃｅ＿ｎｏｄｅ＿ｋｅｙｓ（ＥＫＢ）またはｄｅｖｉｃｅ＿ｋｅｙｓ（ＭＫＢ）を利用して、装置はＥＫＢの一部を復号化しなければならない。各装置は潜在的にはかなり大きな集合から少数のそのような鍵（１６〜３２のオーダーで）を有する。ここで、各装置はそのような鍵のもう一つの一意的な部分集合を有する。ある装置の失効のためそれが決定される場合、この執行された装置のｄｅｖｉｃｅ＿ｎｏｄｅ＿ｋｅｙｓを利用して復号化が可能なＥＫＢの部分が、空のまま、あるいは無効な情報を含むようにされる。これにより、そのような装置はもはやこのＥＫＢを利用することができず、コンテンツの暗号化あるいは復号化のための暗号鍵Ｋｒｏｏｔを取得することができなくなる。
【００３１】
図３において、ｄｅｖｉｃｅ＿ｎｏｄｅ＿ｋｅｙｓの利用によるＥＫＢからの暗号鍵Ｋｒｏｏｔの生成が示される。図４において、ｄｅｖｉｃｅ＿ｋｅｙｓの利用によるＭＫＢからの暗号鍵Ｋｍの生成が示される。ここで、ボックス１２と１３は復号化機能を表している。ＥＫＢとＭＫＢは１００ＫＢから１５ＭＢのオーダーのかなり大きなものでありうるので、ＥＫＢまたはＭＫＢの暗号署名の計算は時間とハードウェアに対してコストを要するものであるということが容易に明らかである。
【００３２】
図３及び図４において、装置は暗号化形式でＥＫＢ／ＭＫＢの一部をすでに所持しているということがわかる。小さな追加により、通常の始動手続きのすでに一部であるこの暗号処理はハッシュの計算と同等のものとしうるということがわかった。言い換えると、必要となる暗号鍵を計算し、追加的な労力なくＥＫＢのハッシュ値を得ることができる。しかしながら、ハッカーがＭＫＢやＥＫＢを変更した場合、得られる暗号鍵も変わるであろう。従って、本発明により、メディア製造業者は暗号鍵の一機能である署名の選択、すなわち、チェックデータの生成を行うことが提案されている。この場合、ＥＫＢ／ＭＫＢ、すなわち、システムデータが取り替えられると、署名はもはやＥＫＢ／ＭＫＢから計算されるような暗号鍵の値と一致しなくなるであろう。本質的に、署名を構成するこの機能は、それが署名の計算は容易に行うが、署名を知っているだけでは暗号鍵の計算は容易にはできないという意味で、暗号鍵の一方向関数である。そうでなければ、ハッカーはこの署名を読み出し、暗号鍵を計算し、回避されるべきディスク上の暗号化コンテンツへのアクセスを行うことが可能となるであろう。
【００３３】
図５において、暗号鍵から署名を生成するためのハッシュ関数の他の例が示される。図５ａによると、ＭＤ４、ＭＤ５またはＳＨＡのような優れた暗号一方向ハッシュ関数が利用されている。図５ｂによると、ＤＥＳ、ＡＥＳなどのような一方向ハッシュ関数として利用される優れた暗号が利用されている。これは、暗号化関数が通常ＥＫＢを処理するユニットにおいて与えられているため、より有益である。「ＩＶ」は、初期ベクトル（Ｉｎｉｔｉａｌ  Ｖｅｃｔｏｒ）を表し、あるランダムな６４または１２８ビットの文字列である。図５ｃによると、暗号鍵Ｋｒｏｏｔが鍵として利用され、公開されているテキストがデータ入力として利用される暗号が利用される。署名チェック装置は入力内容を確認する必要があるという意味から、入力は固定的なものとされる必要がある。従って、この入力は規格の一部、すなわち、あるテキストとして認められるかもしれないし、あるいは署名が格納される読み出し専用サブチャンネルに書き込まれてもよい。言い換えると、実際には、署名は入力と署名から構成される。図５ｃに示される例では、ＥＫＢのバージョン番号がランダムな平文として利用される。
【００３４】
図６において、本発明による検証のためのチェックデータ生成及びフォーマット化されたブランクディスク生成方法が示される。図１に示されるような従来方法に対して、署名ｆ（Ｋｒｏｏｔ）はＥＫＢ２では生成されず、暗号鍵はＥＫＢ２よりはるかに短いため、より容易かつ迅速に実行できる暗号鍵Ｋｒｏｏｔから生成される。メディア製造業者１’により与えられる暗号鍵Ｋｒｏｏｔの利用により、ＥＫＢ２、すなわちシステムデータが生成される。署名６１’、すなわち、チェックデータの信頼できるものとＥＫＢ２の両方が、ブランクディスク７’が作成されるマスタディスク６’上の読み出し専用領域あるいはサブチャンネルに格納される。従来方法と同様に、第１レコーダ８は１つのブランクディスク９’のＥＫＢ９２を記録可能領域またはチャンネル９３にコピーする。
【００３５】
図７ａ及び７ｂにおいて、システムデータの完全性を検証するための方法の他の実施例が示される。本発明による図２に示される従来方法とは反対に、装置はまず記録可能領域またはチャンネル９３から読み出されたＥＫＢを処理し（ステップ２０）、暗号鍵Ｋｒｏｏｔを生成する。この暗号鍵から、チェックデータはハッシュ関数２１を利用して生成される。ここで、ハッシュ関数２１は図５に示されるような異なる方法で実現されうる。生成されたチェックデータは、その後ステップ２２で、ディスク９’の読み出し専用サブチャンネルまたは領域に格納されるチェックデータの信頼できるものである署名９１’と比較される。この検証結果に応じて、ディスク９へのアクセスが許可あるいは拒絶される。図７ｂにおいて、署名９１”、すなわち、ｆ（Ｋｒｏｏｔ）の左部分あるいは右部分（入力）の何れかはディスクに記録される必要はなく、ディスク規格に別々に従うことが可能であるということがわかるであろう。
【００３６】
図７ａに示されるような方法は、ＥＫＢの代わりにＭＫＢを実現すると考えられるＤＶＤ＋ＲＷの例による示される。ＤＶＤ＋ＲＷに対して、ハッシュ関数ｆ（）は、図５に示されるように、入力として適当な付足しによるテキスト「０ｘＤＥＡＤＢＥＥＦ」と、暗号としていわゆるＣ２＿Ｄ関数を有するタイプのものである。署名９１′のＲＯサブチャンネルとして、ＮＢＣＡ（Ｎａｒｒｏｗ  Ｂｕｓｔ  Ｃｕｔ  Ａｒｅａ）が利用される。この実現形態は、図５ｃに示されるようなチェックデータの生成の一部である暗号化処理が通常のＭＫＢ処理の一部として起こる必要があるという効果を有する。従来方法で実行されるようなＭＫＢのフルハッシュの実行を回避することにより、始動負荷を減少することが好ましい。
【００３７】
図７ｂに示されるような修正された方法は、ハッシュ関数が図５ｃに示されるような入力としてＥＫＢバージョンフィールド（バージョン番号）と、署名９１”としてｅｎｃｒｙｐｔｅｄ＿ｖｅｒｓｉｏｎ（）フィールドを有するタイプのものであるＤＶＲのための例により説明される。ＲＯ−ＥＫＢ９２と署名９１”の両方に対するＲＯサブチャンネルは、いわゆるＰＩＣバンドであるだろう。この実現形態は、フィールド/チャンネルがすでにＤＶＲにあるため、新しいフィールドやサブチャンネルがフォーマットで定義される必要がないという効果を有する。また、暗号化ステップ２１”は現在のＤＶＲ規格の一部であり、この方法による記録装置への追加的負荷は単なる１６ビットの比較である。従来方法により必要とされるようなフル１２．５ＭバイトのＥＫＢの必要なハッシュ処理と比較して、本発明のよる方法は、システムデータの完全性の検証に利用される必要時間を大きく減少させるということはすぐに明らかとなる。
【００３８】
新たなＣＤ規格では、ＥＫＢは必ずしもメディア製造業者により予めマスタ記録される必要はなく、ネットワークを介して送信されてもよい。送信中の不正利用（ｔａｍｐｅｒｉｎｇ）を避けるため、ＥＫＢは楕円曲線署名を利用することにより、ＥＫＢライセンス供与当局により署名されたものである。このようなＥＫＢを受信した記録または再生装置は、ＥＫＢをハッシュ処理し、ＥＫＢに添付されるハッシュの楕円曲線署名に対してハッシュをチェックし、このチェックが肯定的結果を与える場合、暗号鍵Ｋｒｏｏｔを取得するための通常の方法によりＥＫＢを処理する必要があるであろう。この楕円曲線の署名は、上述のＲＯサブチャンネルと等価なものである。しかしながら、安価なＣＤ装置に対しては、大量のデータに対するハッシュを計算する必要がでてくるという負担がある。
【００３９】
同様に、上述のように、本発明による以下の手続きを適用することによりこのようなハッシュの計算を回避することができる。ＥＫＢの送信者、すなわち、ＥＫＢライセンス供与当局のような信頼できる第三者がまず、暗号鍵Ｋｒｏｏｔを取得するための通常の方法によりＥＫＢの処理を行う。その後、一方向ハッシュＫｒｏｏｔの楕円曲線署名が計算される。この署名が記録または再生装置への送信のため、ＥＫＢに添付される。再び、図５に示される暗号鍵Ｋｒｏｏｔのハッシュを生成するための異なる可能性からそれを選ぶことができる。特に、バージョンＥ（Ｋｒｏｏｔ，ｖｅｒｓｉｏｎ）から構成されるハッシュ値は興味深い。その理由として、この数はＥＫＢ処理の一部として計算される必要があるためである。
【００４０】
図８において、例えば、ＰＣで実現されるインターネットを介した受信装置により受信されたＥＫＢの完全性を検証するための方法が示される。そこでは、以降においてチェックデータを生成する一方向ハッシュ３３が適用される暗号鍵Ｋｒｏｏｔを取得するための通常の方法により、ＥＫＢ３０が処理される（ステップ３２）。並行して、信頼できる第三者により生成され、本来的に信頼できるチェックデータを含むＥＫＢ３０に並行して送信されるデジタル署名３１が、信頼できるチェックデータを生成する公開鍵Ｋｐｕｂｌｉｃの利用によりステップ３５において解読される。その後、これらは完全性の検証のため、生成されたチェックデータと比較される（ステップ３４）。この結果に応じて、記録キャリアに格納されるデータへのアクセスが許可または拒絶される。
【００４１】
上述の署名方法は、ＥＫＢが他のＥＫＢにより他のＫｒｏｏｔと取り替えられるハッキングを効果的に回避することができる。このことは、ハッカーがもはや新しいＥＫＢを古いＥＫＢにより上書きすることができないということを意味する。ハッカーが同一のＫｒｏｏｔを有するＥＫＢを偽造できるだけの十分な知識を備えていれば、ＲＯサブチャンネルの署名はハッキングされたＥＫＢと一致してしまうかもしれない。しかしながら、これを実行するためには、ハッカーは多くのｄｅｖｉｃｅ＿ｎｏｄｅ＿ｋｅｙｓを知っている必要がある。なぜなら、ハッカーはどの装置がハッカーによりハッキングされたＥＫＢを使用するか前もってはわからないためである。前提として、これらは他の装置をハッキングすることにより取得されるものである。
【００４２】
その構成において、ハッキングを要する装置の台数は、ＭＫＢよりＥＫＢの場合にかなり少ない。しかしながら、署名に含まれる情報をわずかに増やすことにより、このハッキングに対する保護を得ることができる。この機能を理解するため、ＥＫＢが概ね２つの部分、すなわち、記述部とデータ部に分割可能であると知る必要がある。データ部は新しくされた記述鍵に関して実際の情報を含む一方、記述部はデータ部がどのように解釈されるべきかを示す。例えば、どのｄｅｖｉｃｅ＿ｎｏｄｅ＿ｋｅｙｓがＫｒｏｏｔに導く復号化チェーンの開始に利用されるかを装置に知らせる。典型的には、この記述部のサイズは、ＥＫＢ全体のサイズの数パーセントである。記述部を固定化することにより、すなわち、記述部を上述の署名に付加することにより、ハッカーによるＥＫＢの偽造を効果的に防ぐことができる。
【図面の簡単な説明】
【００４３】
【図１】図１は、光記録キャリア上にデータを記録するための従来方法を示す。
【図２】図２は、従来の検証方法を示す。
【図３】図３は、暗号鍵の生成を示す。
【図４】図４は、暗号化鍵の他の生成方法を示す。
【図５】図５は、チェックデータを生成するための様々な方法を示す。
【図６】図６は、本発明による記録方法を示す。
【図７ａ】図７ａは、本発明による検証方法の様々な実施例を示す。
【図７ｂ】図７ｂは、本発明による検証方法の様々な実施例を示す。
【図８】図８は、本発明による検証の他の実施例を示す。
【図１】
2005512258.tif 000003
【図２】
2005512258.tif 000004
【図３】
2005512258.tif 000005
【図４】
2005512258.tif 000006
【図５】
2005512258.tif 000007
【図６】
2005512258.tif 000008
【図７ａ】
2005512258.tif 000009
【図７ｂ】
2005512258.tif 000010
【図８】
2005512258.tif 000011
【国際調査報告】
2005512258.tif 000012
2005512258.tif 000013
2005512258.tif 000014