JP4199925B2 - ディジタル伝送システムにおけるデータ認証方法 - Google Patents

Description

【０００１】
【産業上の利用分野】
本発明は、ディジタル伝送システムにおいて送信されるデータの認証方法に関する。
【０００２】
【従来の技術】
有料ＴＶシステムの業界ではディジタルデータによる放送内容の伝送は公知のものであり、映像音声情報にスクランブルをかけて、通常、衛星または衛星／ケーブルリンクにより、引き続き視聴するために伝送された番組をスクランブル解除することが可能な復号器をそれぞれが有する多数の視聴者に情報が送信されている。地上ディジタル放送システムも知られている。また、最近のシステムは、コンピュータプログラム、復号器や接続ＰＣへの双方向アプリケーションなど、映像音声データに加え、またはそれと同様の他のデータを伝送するための放送リンクを用いている。
【０００３】
アプリケーションデータの伝送に関する主要な問題は、このようなデータの完全性と発信源を検証する必要性にある。この種のデータが復号器を再形成し、さらには任意の数の双方向アプリケーションを実行するために使用される場合があるため、受信データが完全なものであり、かつ既知の発信源からのものとして確認されることが必須である。そうでなければ、不完全データのダウンロードに関して動作上の問題が生じ、さらには復号器が第三者などによる侵入を受けやすくなるリスクを伴うことにもなる。
【０００４】
このようなデータを認証するこれまでの試みは、パケットストリームのデータのカプセル化またはフォーマット化のレベルでの検証に集中していた。例えば、欧州特許出願第０７５２７８６号には、連続したモジュールまたはＭＰＥＧ規格に関連する用語を用いて、連続したテーブルまたはセクションでデータがカプセル化され、次いでＭＰＥＧトランスポートストリームのパケットでテーブルまたはセクションがカプセル化されるシステムが開示されている。
【０００５】
テーブル化されたデータに対して認証動作が実行され、ディレクトリテーブルは、例えば、アプリケーションのデータを含むすべてのテーブルのリストと共に、後にテーブルデータの検証を可能とする各テーブルに関連するハッシュ値のリストを含む。このディレクトリテーブル自体が伝送前に署名されることがあるため、この情報は修正されない場合がある。
【０００６】
このような公知のシステムの問題は、より複雑なデータの組織構造を取り扱うには不適切なことである。特に、一つのディレクトリテーブルが各関連するテーブルのハッシュ値の完全なリストを含むということは、すなわち、このシステムが多数または可変数のテーブルを取り扱うように容易に適用できないということである。
【０００７】
同様に、このシステムは、一つのＭＰＥＧディレクトリテーブルが全てのテーブルとリンクし、認証動作がパケットのカプセル化および放送の用のテーブルにおいてデータを形成する段階で実行されるので、複数の放送オペレータが提供するソフトウェアの認証には、ほぼ不適切なものとなる。この動作はたいてい単一のオペレータの制御下で実行される。
【０００８】
【発明の開示】
本発明の第１の態様によれば、少なくとも１つのルートディレクトリユニットと、サブディレクトリユニットと、ファイルユニットとからなる階層に、伝送前にデータを組織化して認証させる方法であって、ファイルのデータが認証アルゴリズムに従って作用し、関連するファイル認証値が参照サブディレクトリユニットに格納され、さらにファイル認証値が認証アルゴリズムに従って作用し、関連するサブディレクトリ認証値が参照ルートディレクトリに格納されることを特徴とするディジタル伝送において送信されるデータの認証方法が提供される。
【０００９】
一つのテーブルディレクトリが関連するテーブルのすべてを参照する公知のシステムと異なり、複数の階層構造を用いると共に、階層構造の各ステップで認証アルゴリズムを適用することによって、セキュアなモジュール化されたデータ構造が得られる。サブディレクトリのファイル認証値が、ルートディレクトリの対応する値により上位レベルで認証されると、より高いレベルで認証値を変更しなければ、下位レベルの一つの要素を変更することができない（逆もまた同様である）。
【００１０】
ファイルデータの認証は、ファイルデータの一部またはすべてにハッシュ関数アルゴリズムを用いて実行され、その結果得られたハッシュ値が参照サブディレクトリにファイル認証値として格納されることが好ましい。同様に、サブディレクトリの認証は、ファイル認証値（および望めば他のデータ）にハッシュ関数アルゴリズムを用いて実行され、その結果得られたハッシュ値が参照ルートディレクトリにサブディレクトリ認証として格納されてもよい。
【００１１】
他の実施形態も考察すると、例えば、ファイルデータが、暗号化アルゴリズムと、サブディレクトリに格納された認証値として使用される暗号鍵（またはその確認鍵のナンバー）により暗号化される。このファイル鍵は暗号化されてもよく、暗号鍵は認証値などとしてルートディレクトリに格納される。これも可能ではあるが、この実施形態は、暗号鍵の値を発生させるために動作がさらに複雑になり、実行するにはかなり複雑なものとなる。
【００１２】
対比して、各モジュールの認証を実行するためにハッシュ関数アルゴリズムを使用することによって、実行する各モジュールの完全性を非常に単純かつ高速に検証することが可能となる。一実施形態では、検査合計などの単純なハッシュ関数アルゴリズムが使用されてもよい。しかしながら、これは、メッセージのあらゆる変化がどのようにハッシュ値に影響するかを決定する比較的単純なものであるため、誤りの検出ができない。
【００１３】
ハッシュ関数アルゴリズムは、ある任意のセットのデータから実質的に特有のハッシュ値を発生する暗号学的にセキュナなアルゴリズムに相当するものであることが好ましい。この目的で使用可能な適切なハッシュ関数アルゴリズムは、例えば、メッセージダイジェストバージョン５（ＭＤ５）アルゴリズムや、セキュアハッシュ関数アルゴリズム（ＳＨＡ）を含む。
【００１４】
複数のファイルのファイルデータの認証は、一つのハッシュ値を発生させるために、複数のファイルからのデータの蓄積にハッシュ関数アルゴリズムを適用して実行されることが有益である。同様に、多数のサブディレクトリの認証は、一つのハッシュ値を発生させるために、複数のサブディレクトリ（および望めば他のデータ）からファイル認証値の蓄積にハッシュアルゴリズムをかけて実行されてもよい。
【００１５】
下位層にある複数のデータモジュール（ファイル、サブディレクトリなど）に及ぶように累積してハッシュプロセスを用いることによって、例えば、各モジュールに個々のハッシュ値のリストを格納するシステムと比較するとシステムがさらに単純化されたものとなる。これにより、システムが各レベルで必要な計算ステップをさらに減少でき、さらには上位層に格納された認証データのサイズも減少される。
【００１６】
各層を認証するためにハッシュ関数アルゴリズムを用いる実施形態の場合、システムは「オープン」な状態となり、すなわち、すべてのハッシュ値がルートディレクトリまで読出し可能となる。ハッシュ関数アルゴリズムは公開されて入手可能であるため、理論的には第三者が、例えば、サブディレクトリとルートディレクトリのレベルでの対応するハッシュ値が同時に変更されると、検出せずにファイルレベルで格納されたデータを変更することができる。
【００１７】
これを避けるために、ルートディレクトリに格納されたデータの少なくともいくつかを、暗号化アルゴリズムの秘密鍵により作用されるようにして、その結果得られた暗号化値をルートディレクトリに格納する。暗号化された値は、ディジタル署名に相当するものが好ましい。この目的に適した私有／公開鍵のアルゴリズムは、例えば、ＲＳＡアルゴリズムを含む。
【００１８】
少なくとも一以上のサブディレクトリ認証値が、ルートディレクトリに格納される署名を発生させるために秘密鍵によって暗号化されることは有益である。しかしながら、システムを「クローズ」にするために、署名されるサブディレクトリ認証以外に、ルートディレクトリのデータを考察することが可能である。
【００１９】
署名を発生させる代替例において、ルートディレクトリすべて、もしくは一部を単純に暗号化するかまたはスクランブルをかけて、受信機に暗号化されたルートディレクトリのデータを復号するための同等の鍵をもたせてもよい。この場合、ＤＥＳなどの対称鍵アルゴリズムが使用されてもよい。
【００２０】
理解されるように、２つの階層レベルを参照して認証プロセスを上述してきたが、同様の認証ステップが、さらに参照されるファイル、サブディレクトリ、ルートディレクトリなど無限のレベルで実行されてもよい。
【００２１】
同様に、表記を明確にするために、ルートディレクトリ／サブディレクトリ／ファイルとしてこの構造を規定してきたが、２つの上位層のモジュールで下位層のモジュールを指し示す以外、層の各モジュールには特別な特徴はない。理解されるように、データ構造は、ルートディレクトリ／サブディレクトリ／第２のルートディレクトリ、もしくはあらゆる他の組み合わせと同等のものであってもよい。
【００２２】
以下に記載する実施形態は、下位層、すなわちディレクトリまたはサブディレクトリと呼ばれる層のモジュールに焦点を当てたものである。以下から明らかになるように、上位層から参照するが、このモジュール自体は、ディレクトリモジュール、サブディレクトリモジュールなどであってよい。
【００２３】
一実施形態では、一つの参照モジュールは、秘密鍵で発生した暗号化された値を含み、このモジュールの認証値は、暗号化値の認証アルゴリズムの結果に基づいて計算され、参照モジュールに格納される。特に、上述した同等のルートディレクトリの実施形態にあるように、参照されたモジュールが署名されてもよく、このモジュールの認証値がその署名のハッシュ関数の結果として計算される。
【００２４】
参照されるユニットは、例えば、ファイルまたはサブディレクトリに対応するものであってよい。しかしながら、この実施形態は、参照ユニットが、さらなるデータセット、例えば、異なる発信地からのデータのルートディレクトリであり、参照ルートユニットも署名を含む状況に特に適用される。この場合、第１のオペレータがルートディレクトリのレベルまでデータを蓄積し署名することができる。
【００２５】
その後、第２のオペレータが、暗号鍵を知らずともこのデータを参照でき、参照ルートディレクトリの署名のハッシュ値により任意のリンクが単純に参照ユニットで認証される。両方のデータセットの認証は、当然のごとく、両方のルートディレクトリの署名を検証するために必要な鍵を所有する受信機だけが可能となる。
【００２６】
上述したように、本発明は、任意のセットの複数の階層データユニットに適用されてもよい。さらに、ルートディレクトリ、サブディレクトリ、ファイルなどの複数のレベルがパケットストリームに与えられる場合には、トランスポートストリームでのテーブルまたはパケットの組織化に適用されてもよい。しかしながら、本発明は、ユニットがデータテーブルまたはセクションでカプセル化されたデータファイルのセットに相当する場合に特に応用可能であり、その後、これらのテーブルはデータパケットに暗号化されてトランスポートストリームを形成する。
【００２７】
パケットまたはテーブルレベルでの認証と異なり、本発明の実施形態により、認証データをアセンブルすることと、トランスポートストリームをカプセル化することを完全に独立させることができるようになり、単一の放送オペレータにより制御されたトランスポートストリームでの異なる発信源からソフトウェアを供給することがさらに容易になる。本発明の実施形態により認証されたデータは、データを送信するための代替カプセル化フォーマットを用いて、異なる伝送ルート（例えば、両方向遠隔通信リンクまたは衛星リンクなど）を介して伝送されてもよい。
【００２８】
データユニットは、ＤＳＭＣＣ規格に従ってフォーマット化されたデータオブジェクトに相当するものが好ましい。一実施形態では、データオブジェクトは後に、ＭＰＥＧ規格に従うテーブルおよびパケットにカプセル化される。
【００２９】
本発明の第２の態様によれば、ディジタル伝送システムにおいて送信されるリンクされたデータユニットの第１および第２のセットの認証方法であって、第１のユニットのセットの少なくとも１つが、第１のユニットに作用する秘密鍵で発生された署名を含み、少なくとも署名の値が、認証アルゴリズムにより認証され、この認証値が、第１のユニットを参照する第２のユニットのセットにある１つのユニットに格納されることを特徴とする方法が提供される。
【００３０】
本発明の第３の態様によれば、ディジタル伝送システムにおいて送信されるデータの認証方法であって、データが連続したデータファイルに組織化され、パケットトランスポートストリームで伝送するためのデータを準備するために、ディジタル伝送システムで使用されるデータのフォーマット化およびカプセル化の一つまたは複数の段階から独立して、その前にファイル間に認証が実行されることを特徴とする方法が提供される。
【００３１】
特に、テーブルまたはセクションでフォーマット化する前に認証が実行されてもよく、その後、テーブルはトランスポートパケットストリームのデータパケットにカプセル化される。
【００３２】
上述したように、伝送用にデータを準備する前に適用される認証プロセスを用いることによって、認証プロセスを変更せずに放送チャネルまたは遠隔通信チャネルなど、任意の数のチャネルにより、後にデータが受信機に送られるという効果が得られる。同様に、受信機または復号器が、伝送ルートに関連するフォーマットからデータファイルを再構成すると、選択された伝送モードから独立して、このデータに検証が実行されてもよい。
【００３３】
本発明の第１の態様および好適な実施形態の任意またはすべての特徴は、当然のごとく、本発明の第２および第３の態様と組み合わせてもよい。
【００３４】
本発明を伝送前に認証データを発生させるためのステップに関連して上述してきた。同様に、最も広範囲の好適な実施形態において、本発明は、このデータ検証するための受信機で実行される逆ステップにも適合する。
【００３５】
最も広範囲の態様では、本発明は、あらゆるディジタル伝送システムに適用されてもよい。しかしながら、本発明は、ディジタルテレビジョンシステムに適用されることが好ましく、特に、ディジタルテレビジョンシステムの受信機／復号器で使用するためのデータモジュール保有アプリケーションソフトウェアに適用されることが好ましい。
【００３６】
本願明細書での使用にさいし、「ディジタル伝送システム」という用語は、例えば、主に映像音声またはマルチメディアディジタルデータを伝送または放送するためのあらゆる伝送システムを含む。本発明は、特に、放送ディジタルテレビジョンシステムに応用可能であるが、本発明はまた、マルチメディアインターネットアプリケーション用の固定遠隔通信網、閉回路テレビジョンなどにも応用可能である。理解されるように、「ディジタルテレビジョンシステム」という用語は、例えば、任意の衛星、地上、ケーブルおよび他のシステムを含むものである。
【００３７】
本願明細書で使用される「受信機／復号器」または「復号器」という用語は、例えば、何らかの他の手段で放送または送信されるテレビジョンおよび／またはラジオ信号などの符号化または非符号化された信号のいずれかの信号を受信するための受信機を意味することがある。また、この用語は、受信信号を複合化するための復号器を意味することもある。このような受信機／復号器の実施形態は、例えば、「セットトップボックス」において受信信号を復号化するための受信機一体型復号器を含むものであってもよく、このような復号器は、物理的に離れた受信機との組み合わせで機能するか、もしくはこのような復号器は、ウェブブラウザの機能および／またはビデオレコーダやテレビジョンなどの他のデバイスと一体化させるなど、他の機能を含むものであってもよい。
【００３８】
ＭＰＥＧという用語は、国際標準化機構が運営するグループである「モーションピクチャーズエキスパートグループ」により開発されたデータ伝送規格を指し、特に、独占的ではないが、ＭＰＥＧ−２規格はディジタルテレビジョンの用途用に開発され、ドキュメントＩＳＯ １３８１８−１、ＩＳＯ １３８１８−２、ＩＳＯ １３８１８−３、ＩＳＯ １３８１８−４に記載されている。本願明細書の文脈では、この用語は、ディジタルデータ伝送分野に応用可能なＭＰＥＧフォーマットのすべての変形、修正または発展したものを含む。
【００３９】
ＤＳＭＣＣという用語は、ＭＰＥＧドキュメントに記載され、最新のドキュメントＩＳＯ１３８１８−６に記載されたデータファイルフォーマットの規格を指す。
【００４０】
【発明を実施するための最良の形態】
添付の図面を参照して、本発明の好適な実施形態を例示的目的のみで以下に記載する。
【００４１】
本発明によるディジタルテレビジョンシステムの概要が図１に示されている。本発明は、公知のＭＰＥＧ−２圧縮方式を用いて圧縮ディジタル信号を伝送するほぼ従来型のディジタルテレビジョンシステム２を含む。さらに詳しく言えば、放送センタにあるＭＰＥＧ−２圧縮機３が、ディジタル信号ストリーム（通常、ビデオ信号のストリーム）を受信する。圧縮機３は、マルチプレクサおよびスクランブラ４にリンク５で接続される。
【００４２】
マルチプレクサ４は、複数のさらなる入力信号を受信し、トランスポートストリームをアセンブルして、リンク７を介して放送センタのトランスミッタ６に圧縮されたディジタル信号を送信する。このリンク７は、勿論、遠隔通信リンクを含むあらゆる種類の形をとるものであってよい。送信機６は、アップリンク８を介して電磁信号を衛星トランスポンダ９へと送信し、エンドユーザーが所有またはレンタルする従来の皿状のアンテナの地上の受信機１２へと概念上のダウンリンク１０を介して電子的に処理および提供される。受信機１２により受信された信号は、エンドユーザーが所有またはレンタルする一体型の受信機／復号器１３に送信され、エンドユーザーのテレビジョンセット１４に接続される。受信機／復号器１３は、圧縮されたＭＰＥＧ−２の信号をテレビジョンセット１４用のテレビジョン信号に復号する。
【００４３】
地上放送、ケーブル伝送、衛星／ケーブルを組み合わせたリンク、電話網など、データの送信用の他の輸送チャネルも勿論可能である。
【００４４】
マルチチャネルシステムにおいて、マルチプレクサ４は、多数のパラレル発信源から受信した音声および映像情報を処理し、送信機６と相互に作用して対応する数のチャネルに沿って情報を提供する。音声映像情報以外にも、メッセージまたはアプリケーションやあらゆる種類の他のディジタルデータを、送信されるディジタル音声および映像情報と組み合わせてこれらのチャネルの一部またはすべての導入されてもよい。このような場合、例えば、ＤＳＭ−ＣＣフォーマットソフトウェアファイルおよびメッセージなどの形式のディジタルデータのストリームが、圧縮機３によりＭＰＥＧフォーマットに圧縮されてパケット化される。以下にソフトウェアモジュールのダウンロードをより詳細に記載する。
【００４５】
マルチプレクサ４と受信機／復号器１３には、限定受信システム１５が接続されており、一部は放送センタに配置され、さらに一部は復号器に配置されている。これにより、エンドユーザーが１以上の放送提供者からのディジタルテレビ放送にアクセスすることができるようになる。営利的提供物に関するメッセージ（すなわち、放送提供者が販売する１つまたはいくつかのテレビ番組に関するもの）を復号化可能なスマートカードが、受信機／復号器１３に差し込まれる。復号器１３とスマートカードを用いて、エンドユーザーは、有料予約モードまたはペイパービューモードのいずれかで営利的提供物を購入してもよい。実際、復号器は、ＳｉｍｕｌｃｒｙｐｔまたはＭｕｌｔｉｃｒｙｐｔデザインなどの多数のアクセス制御システムを処理するように構成されてもよい。
【００４６】
上述したように、システムにより送信された番組は、マルチプレクサ４でスクランブルがかけられ、ある所与の伝送に適用される条件および暗号鍵がアクセス制御システム１５で決定される。このようなスクランブルがかけられたデータの送信は、有料ＴＶシステムの分野では公知のものである。通常、スクランブルデータは、データのスクランブルを解除するための制御ワードとともに送信され、この制御ワード自体は、いわゆる開発鍵により暗号化され、暗号化された形式で送信される。
【００４７】
次いで、スクランブルデータと暗号化された制御ワードは、復号器に差し込まれたスマートカード上に格納された開発鍵と同等のものにアクセス権を有する復号器１３により受信されて、暗号化された制御ワードを復号化し、その後、送信されたデータのスクランブル解除を行う。支払済みの視聴者は、提供される月別ＥＭＭ（権利付与管理コード（Ｅｎｔｉｔｌｅｍｅｎｔ Ｍａｎａｇｅｍｅｎｔ Ｍｅｓｓａｇｅ））において、暗号化された制御ワードを復号するのに必要な開発鍵を受けとり、送信の視聴が可能となる。音声映像テレビジョン番組を復号化するさいの使用以外にも、同様の開発鍵が発生されて、以下に記載するように、ソフトウェアモジュールなどの他のデータを検証するさいに使用するように送信されてもよい。
【００４８】
マルチプレクサ４と受信機／復号器１３にも接続され、また一部が放送センタに配置され、さらに一部が復号器に配置された双方向システム１６により、エンドユーザーがモデムバックチャネル１７を介してさまざまなアプリケーションと相互作用できるようになる。モデムバックチャネルはまた、限定受信システム１５で使用される通信用に用いられてもよい。特定のイベントの視聴や、アプリケーションのダウンロードなどの許可を要請するために、双方向システムを用いることで、例えば、視聴者が伝送センタと直接通信することも可能となる。
【００４９】
図２を参照すると、本発明で使用されるように適用された受信機／復号器１３またはセットトップボックスの物理的要素に関して、以下簡潔に記載する。この図に示されている要素は、機能ブロックにより記載されている。
【００５０】
復号器１３は、関連するメモリ要素を含み、シリアルインターフェース２１、パラレルインターフェース２２およびモデム２３（図１のモデムバックチャネル１７に接続されている）から入力データを受信するように適用された中央処理装置２０を備える。
【００５１】
さらに、復号器は、制御ユニット２６を介して赤外線リモートコントロール２５からの入力と、復号器のフロントパネル上にあるスイッチコンタクト２４からの入力を受けるように適用される。復号器はまた、バンクを読取るための２つのスマートカードリーダ２７、２８かまたは視聴用スマートカード２９、３０をそれぞれ有する。入力は、赤外線キーボード（図示せず）を介して受信されてもよい。視聴用スマートカードリーダ２８は、差し込まれた視聴用カード３０と限定受信ユニット２９とつながり、必要な制御ワードをデマルチプレクサ／デスクランブラ３０に供給して、暗号化された放送信号のスクランブルを解除可能となる。また、復号器は、従来の同調器３１と復調器３２を含み、ユニット３０によりフィルタがけと逆多重化される前に、衛星通信を受信して復調する。
【００５２】
復号器内のデータ処理は、一般に、中央処理装置２０で処理される。中央処理装置のソフトウェアアーキテクチャは、復号器のハードウェアコンポーネントで実行される下位レベルのオペレーティングシステムと相互作用するバーチャルマシンに相当するものである。
【００５３】
以下、図３および図４を参照して、送信器から復号器へと送信される放送ＭＰＥＧトランスポートストリーム内のデータのパケット構造に関して記載する。認識されるように、ＭＰＥＧ規格で使用されているテーブル化フォーマットに焦点を当てて記載しているが、同じことが、他のパケット化されたデータストリームフォーマットにも同様に当てはまる。
【００５４】
さらに詳しく図３を参照すると、ＭＰＥＧビットストリームが、パケット識別（「ＰＩＤ」）が０であるプログラムアクセステーブル（「ＰＡＴ」）４０を含む。ＰＡＴは、多数のプログラムからなる複数のプログラムマップテーブル（「ＰＭＴ」）のＰＩＤを参照する。各ＰＭＴは、そのプログラム用の音声ＭＰＥＧテーブル４２と映像ＭＰＥＧテーブル４３のストリームのＰＩＤを参照する。ＰＩＤがゼロであるパケット、すなわちプログラムアクセステーブル４０は、すべてのＭＰＥＧアクセスのエントリーポイントを提供する。
【００５５】
プログラムのアプリケーションおよびデータをダウンロードするために、２つの新しいストリームタイプが規定され、それと関連するＰＭＴはまた、アプリケーションＭＰＥＧテーブル４４（またはそれらのセクション）とデータＭＰＥＧテーブル４５（またはそれらのセクション）のストリームのＰＩＤを参照する。実際のところ、実行可能なアプリケーションソフトウェアとこのようなソフトウェアにより処理されるデータに別々のストリームタイプを規定することが便利な場合もあるが、これは必須ではない。また、他の実行例として、データおよび実行可能なコードが、上述したようなＰＭＴを介してアクセスされる単一のストリームにアセンブルされてもよい。
【００５６】
図４を参照すると、例えば、ストリーム４４内のアプリケーションをダウンロードするために、アプリケーション４６が複数のモジュール４７に分割され、それぞれがＭＰＥＧテーブルにより形成される。これらのテーブルのうち、単一のセクションからなるものもあれば、複数のセクション４８からなるものもある。一般的なセクション４８はヘッダを有し、このヘッダは、１バイトのテーブル識別（「ＴＩＤ」）５０、テーブルにおけるセクションのセクションナンバー５１、このテーブルにあるセクションの総数５２および２バイトのＴＩＤ拡張リファレンス５３を含む。各セクションはまた、データ部５４とＣＲＣ５５を含む。ある特定のテーブル４７に関して、テーブル４７を構成するセクション４８のすべては、同じＴＩＤ５０と同じＴＩＤ拡張５３を有する。ある特定のアプリケーション４６に関して、アプリケーション４６を構成するテーブル４７のすべては、同じＴＩＤ５０を有するが、それぞれのＴＩＤ拡張は異なる。
【００５７】
各アプリケーション４６に対して、ディレクトリテーブル５６として単一のＭＰＥＧテーブルが用いられる。ディレクトリテーブル５６は、そのヘッダに、アプリケーションを構成する他のテーブル４７と同じＴＩＤを有する。しかしながら、ディレクトリテーブルは、識別を目的とし、さらに単一のテーブルしかディレクトリ内の情報に必要でないため、所定のＴＩＤ拡張がゼロである。他のテーブル４７のすべては、通常ゼロではないＴＩＤ拡張を有し、多数の関連するセクション４８からなる。また、ディレクトリテーブルのヘッダは、ダウンロードすべきアプリケーションのバージョンナンバーを含む。
【００５８】
図３を再度参照すると、ＰＡＴ４０、ＰＭＴ４１およびアプリケーションとデータのストリームコンポーネント４４、４５は、周期的に伝送されるものである。伝送される各アプリケーションは、それぞれ所定のＴＩＤを有する。アプリケーションをダウンロードするには、適切なＴＩＤを有しＴＩＤ拡張がゼロのＭＰＥＧテーブルが、受信機／復号器にダウンロードされる。これは、必要なアプリケーション用のディレクトリテーブルである。次いで、ディレクトリのデータが復号器により処理されて、必要なアプリケーションを構成するテーブルのＴＩＤ拡張を決定する。その後、ディレクトリテーブルと同じＴＩＤを有し、ディレクトリテーブルから決定されたＴＩＤ拡張を有するテーブルが必要であれば、ダウンロードしてもよい。
【００５９】
復号器は、ディレクトリテーブルのあらゆるアップグレードに対応するためにテーブルを検査するように調整される。これは、ディレクトリテーブルを再度、例えば、３０秒毎、１分毎または５分毎と、周期的にダウンロードして、前回ダウンロードしたディレクトリテーブルのバージョンナンバーと比較することによって行ってもよい。新しくダウンロードしたバージョンナンバーが最新のバージョンのものであれば、前のディレクトリテーブルと関連するテーブルは削除され、新しいバージョンと関連するテーブルがダウンロードされ組み合わされる。
【００６０】
代替となる構成では、入力ビットストリームは、アプリケーションのＴＩＤと、ゼロのＴＩＤ拡張と、現在ダウンロードしているディレクトリのバージョンナンバーよりも１つ上のバージョンナンバーに重きを置いて、ＴＩＤ、ＴＩＤ拡張およびバージョンナンバーに相当するマスクを用いてフィルタリングされる。したがって、バージョンナンバーが上がっていることが検出でき、一旦検出されると、上述したように、そのディレクトリがダウンロードされて、アプリケーションがアップグレードされる。アプリケーションを終了させる場合、次のバージョンナンバーを有する空のディレクトリが伝送されるが、ディレクトリ内にはモジュールはリストされない。このような空のディレクトリを受けると、復号器２０２０は、アプリケーションを削除するようにプログラムされる。
【００６１】
実際のところ、復号器でアプリケーションを実行するためのソフトウェアとコンピュータプログラムは、復号器のあらゆる部分を介して、特に、上述したような衛星リンクを介して受信するデータストリームで導入されてもよいが、シリアルポートやスマートカードリンクなどを介して導入されてもよい。このようなソフトウェアは、ネットブラウザ、クイズアプリケーション、プログラムガイドなど、復号器内で双方向アプリケーションを実行するために用いるハイレベルのアプリケーションからなるものであってもよい。また、ソフトウェアは、例えば、「パッチ」などを用いて、復号器ソフトウェアの稼動構成を変化するためにダウンロードされてもよい。
【００６２】
また、アプリケーションは、復号器を介してダウンロードされ、復号器に接続されたＰＣなどに接続されてもよい。このような場合、復号器はソフトウェアの通信ルータとして作用し、最終的には接続されたデバイス上で実行される。また、このようなルータ機能の他にも、復号器は、ＰＣに送信される前にＭＰＥＧパケット化されたデータを、例えば、ＤＳＭＣＣプロトコル（以下参照）に従って組織化したコンピュータファイルソフトウェアに変換してもよい。
【００６３】
アプリケーションデータの完全性および発信源を検証するために実行される測定は、これまで、ＭＰＥＧパケットストリームのテーブルを検証することに焦点を当ててきた。特に、従来のシステムでは、伝送前に個々のセクション４８のそれぞれにハッシュ関数が適用され、各セクションのチェック値または署名が復号器に送られるディレクトリテーブル５６のリストに格納される。復号器により引き続き計算されるハッシュ値と受信セクションのディレクトリに格納されたチェック値とを比較することによって、受信セクションの完全性が検証できる。
【００６４】
同様に、ディレクトリ４０内のデータをハッシュプロセスにかけて、ディレクトリテーブル４０のさらなるチェック値または署名を発生させてもよい。さらに、このチェック値は、私有鍵により暗号化され、ディレクトリテーブル内に格納されてもよい。対応する公開鍵を所有するこれらの復号器のみが署名を認証してもよい。
【００６５】
このような従来のシステムと対比して、本発明は、アプリケーションレベルでデータファイルまたはオブジェクトからなる多階層に組織化したアプリケーションデータをセキュアにし、検証するための手段に関する。これに関しては、図５からより明確に理解され、この図は、アセンブルされたアプリケーション４６において連続したＭＰＥＧテーブル４７内でカプセル化された場合、ＤＳＭＣＣ Ｕ−Ｕデータファイル６０のセットに組織化されたデータ間の関係を示す図である。
【００６６】
伝送前に、データファイルはアプリケーション４６にアセンブルされ、その後、ＭＰＥＧ圧縮機により、上述したように、ＭＰＥＧパケットストリームに特有のヘッダ４９を含み、テーブルＩＤ、バージョンナンバーなどを含むＭＰＥＧテーブルまたはモジュール４７にフォーマットされる。次いで、これらのテーブルは、ＭＰＥＧ圧縮機によりＭＰＥＧパケットにカプセル化される。理解されるように、データファイル６１に組織化されたデータと最終的なＭＰＥＧテーブル４７との間の関係は一定のものでなくてもよい。復号器による受信およびフィルタリングの後、パケットヘッダは破棄され、連続したテーブルが放送パケットのペイロードから再構築される。その後、テーブルヘッダ４９が破棄され、アプリケーション４６がテーブル４７のペイロードから再構築される。
【００６７】
データファイルのＤＳＭＣＣフォーマットは、マルチメディアネットワークでの使用に特に適した規格であり、クライアントユーザー７０と、サーバーユーザー７１と、ネットワークリソース管理者７２間の通信用に、連続したメッセージフォーマットとセッションコマンドを規定する。図６を参照されたい。ネットワークリソース管理者７２は、ネットワーク内でリソースの機能を管理するように作用する論理上のエンティティとして考えてもよい。当初、双方向ネットワーク通信のコンテキストでの使用とされてきたが、ＤＳＭ−ＣＣ規格の最近の実施では、一方向の放送目的のみの使用に焦点が当てられてきた。
【００６８】
クライアントとサーバー間の通信は、連続したセッションで成立し、第１の連続したメッセージは、ユーザー（クライアント７０またはサーバー７１）とネットワーク管理者７２間で交換され、クライアントおよび／またはサーバの通信を構築する。このようなメッセージは、いわゆるＤＳＭＣＣ Ｕ−Ｎ（ユーザ対ネットワーク）プロトコルに従ってフォーマットされる。このプロトコルのサブセットが、データの放送ダウンローディング用に特に規定されている。
【００６９】
一旦通信リンクが確立されると、ＤＳＭＣＣ Ｕ−Ｕ（ユーザー対ユーザ）プロトコルに従って、メッセージがクライアント７０とサーバー７１間で引き続き交換される。この種の連続したメッセージは、図５のデータファイル６０に相当するものである。ＤＳＭＣＣ Ｕ−Ｕメッセージの場合、ＢＩＯＰ（Ｂｒｏａｄｃａｓｔ ＩｎｔｅｒＯｒｂ Ｐｒｏｔｃｏｌ）に従ってグループ化された連続したメッセージ６１にデータが組織化される。
【００７０】
各メッセージまたはオブジェクト６１は、ヘッダ６２と、サブヘッダ６３と、データ自体を含むペイロード６４からなる。ＢＩＯＰプロトコルに従って、ヘッダ６２は、特に、メッセージのタイプとＢＩＯＰバージョンを表示するのに対し、サブヘッダは、オブジェクトのタイプとシステムアーキテクチャにより規定される他の情報を表示する。
【００７１】
ＤＳＭＣＣ Ｕ−Ｕのペイロード内のデータオブジェクト６４は、３つのタイプ、すなわち、ディレクトリオブジェクトと、ファイルオブジェクトと、ストリームオブジェクトのうちの１つとして概して規定される。ディレクトリオブジェクトは、実際のアプリケーションデータを含む連続した関連ファイルオブジェクトを参照するために使用されるルートディレクトリまたはサブディレクトリを規定する。
【００７２】
ストリームオブジェクトを使用して、データファイルに含まれるデータとＭＰＥＧパケットストリーム自体との間に一時的な関係を確立できるようにしてもよい。これは、例えば、データファイルに含まれ、復号器で受信処理される基本的な映像および音声ストリームと同期させるようにした双方向アプリケーションの場合などで使用されてもよい。上述したように、ＭＰＥＧパケット化データとデータファイルとの間には直接的な相関関係はなくてもよい。
【００７３】
単一のディレクトリが、単一の階層レベルしかもたないテーブルセットを参照するＭＰＥＧテーブルと異なり、データファイル６０は、さらにより複雑な階層方法で組織化されてもよい。ＰＣまたはサーバーに格納されたファイルのように、メインまたはルートディレクトリが、第２のレベルのデータファイルを参照する１以上のサブディレクトリを参照してもよい。さらに、別のアプリケーションデータセットと関連する第２のルートディレクトリを参照してもよい。
【００７４】
図７を参照すると、データファイルまたはユニットセットのファイル構造の例が示されている。参照番号７５で示されているルートディレクトリＤＩＲ Ａ０が、参照番号７６で示されているサブディレクトリＡ１〜Ａ４のグループを参照する。各サブディレクトリ７６は、１以上の関連するオブジェクトファイル７７のセットを参照する。明瞭にするために、サブディレクトリＡ４と関連するオブジェクトファイルＦ１、Ｆ２・・・の単一グループのみが示されている。実際は、多数のオブジェクトファイルのグループが、サブディレクトリＡ１〜Ａ４のそれぞれによって参照させてもよい。
【００７５】
各ディレクトリとサブディレクトリ内には、認証ステップのセットがそのディレクトリにリンクされたファイルに対して導入される。ルートディレクトリ７５を参照すると、サブヘッダ６３は、参照番号７６で示したサブディレクトリファイルＡ１〜Ａ４に格納されたデータの一部またはすべてにハッシュ関数アルゴリズムを適用することによって得られたハッシュ値を有する。使用するハッシュ関数アルゴリズムは、例えば、メッセージダイジェストアルゴリズムＭＤ５など、あらゆる公知のタイプのものであってもよい。
【００７６】
一つの実行例では、アルゴリズムは、各関連するファイルまたはサブディレクトリに個々に適用され、各サブディレクトリ７６のハッシュ値のリストが、伝送前にルートディレクトリ７５に格納されてもよい。しかしながら、このような解決法は、各サブディレクトリを検証する点でチェック精度を上げることができるが、復号器が対応する署名を計算するのに必要な処理時間の点ではむしろ非効率的といえる。
【００７７】
したがって、ディレクトリ７９のサブヘッダ６３は、サブディレクトリ７６のサブヘッダとペイロードセクション６３、６４を組み合わせたところ、すなわち、ヘッダ６２を含まないところにＭＤ５ハッシュ関数アルゴリズムを適用することによって計算される累積ハッシュ値７９を有することが好ましい。特に、サブディレクトリ７６内に含まれ、ファイルオブジェクト７７の層を参照するハッシュ値８２は、このハッシュ計算に含まれる。
【００７８】
図７に示すサブディレクトリＡ４の場合、このサブディレクトリ自体が、参照番号７７で示されたオブジェクトファイルＦ１〜Ｆｎのセットを参照する。この場合、累積ハッシュ値８２が、オブジェクトファイル７７の組み合わせコンテンツ用に発生される。この値は、ハッシュ値７９を生じるハッシュプロセス内に含まれる。したがって、ディレクトリ７５のハッシュ値７９を変更することになるサブディレクトリ７６のハッシュ値８２を変更しなければ、オブジェクトファイル７７のいずれをも変更することはできない。
【００７９】
このような場合、組み合わせたハッシュ値が、ディレクトリで参照されたサブディレクトリＡ１〜Ａ４のすべてに対して計算される。このハッシュ値は、データが取られたサブディレクトリのグループの識別子と共に格納される。他の実施形態では、連続した組み合わせたハッシュ値または個別のハッシュ値と対応する識別子が、ディレクトリのサブヘッダに格納されてもよい。
【００８０】
例えば、ルートディレクトリと関連するが、異なるセットのデータまたは実行可能なコードにも関係する第２のセットのサブディレクトリが、共にグループ化されてもよく、これらのサブディレクトリに対して計算された累積ハッシュ値が計算されて、サブヘッダルートディレクトリに格納されてもよい。同様に、単一のディレクトリと関連する単一のハッシュ値が、ルートディレクトリのサブヘッダに格納されてもよい。
【００８１】
グループまたは個々のデータファイルの許可では、勿論、ルートディレクトリ（または、実際、あらゆる他のファイル）が許可されていないかまたはハッシュされていないデータファイルを参照することは防げないが、このようなファイルの許可がなければ、このファイルのあらゆる動作を考慮する必要が出てくる。この点で、例えば、ストリームオブジェクトを認証することは不要な場合がある。
【００８２】
この場合、ハッシュ関数を用いることによって、主に復号器がダウンロードしたデータファイルの完全性および完璧性を検証できる。例えば、伝送が失敗や切断した場合、受信した従属ファイル上で累積ハッシュ関数アルゴリズムを動作すると、ルートディレクトリに格納されたこれらのファイルのハッシュ値と同じ結果を生じない。次いで、復号器は、ダウンロードしたデータにエラーがある可能性を警告され、不完全なデータファイルをリロードする。
【００８３】
理解されるように、ハッシュ関数アルゴリズムの場合、ハッシュ値の計算が、公知の連続した計算ステップに従って実行され、したがって、誰もがある所与のデータファイルセットのハッシュ値を生成することができる。このように、ハッシュ値を単純に検査することによって、このようなデータの発信源を検証することは通常不可能である。
【００８４】
この問題を解消するために、オペレータだけが知る秘密鍵を用いて、ルートディレクトリ７５の署名値が計算される。この鍵は、データ暗号標準（ＤＥＳ：Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）アルゴリズムなどの対称鍵アルゴリズムで得られる鍵に相当するものであってよい。しかしながら、ＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｌｔｅｍａｎ）アルゴリズムなどの私有／公開鍵が使用されることが好ましく、オペレータが私有鍵値を所有するデータファイルの生成に責任をもち、公開鍵が復号器により保持される。
【００８５】
図７に示すように、ルートディレクトリ７５は、オペレータの私有鍵を用いて発生した計算された署名値８１と共に、検証段階で使用される公開鍵を復号器に対して識別する鍵識別子またはマジックナンバー８０を有する。この場合、署名値８１は、ペイロードデータ６４および／または１つまたは複数の累積ハッシュ値７９を含むことが好ましいディレクトリ７５内のデータの一部またはすべてに対して、オペレータにより保持された私有鍵を適用することによって発生される。次いで、復号器は、鍵ナンバー８０により識別された対応する公開鍵を用いて、この署名値８１を検証できる。
【００８６】
この例では、ディレクトリ７５のデータは暗号化されておらず、私有鍵は単純に公開鍵によって検証可能な署名値を与えるように用いられる。代替実施形態では、ディレクトリのコンテンツの一部またはすべてが、私有鍵によって暗号化され、その後に対応する鍵によって復号化されてもよい。
【００８７】
いずれにせよ、秘密鍵を用いて暗号化されたコードの署名値またはブロックを発生させることによって、ディレクトリ７５の完全性および発信源と、暗に、このルートディレクトリにより参照されるファイルの完全性および発信源をデコーダが検証できるようになる。参照されるファイルの累積ハッシュ値が、署名８１の計算に含まれるため、検証段階で検出されなければ、これらの値を変更することは不可能である。各ハッシュ値がある所与のデータセットに一般に特有のものであるため、その特有のハッシュ値と、さらにはディレクトリの発生した署名値を変更しなければ、あらゆる従属したハッシュ処理されたファイルのコンテンツを変更することは不可能となる。
【００８８】
ルートディレクトリ７５と、サブディレクトリ７６と、オブジェクトファイル７７はすべて、オペレータＡとしてここに示されているシステムの第１のオペレータにより発生される。この場合、これらのファイルはすべて、公知の検証可能な共通した発信源をもつものとなる。
【００８９】
しかしながら、実行するアプリケーションによっては、第２のオペレータＢと関連するデータファイルのセットを参照させてもよい。この場合、サブディレクトリ７６は、参照番号７８で示した第２のデータファイルのセットのルートディレクトリＤＩＲ Ｂ０とを参照する。また、他のレベル、例えば、第１のセットのファイルにある第１のサブディレクトリが第２のデータファイルのセットを参照するなどのファイル階層の異なる発生源からデータファイル間の接続を想定することも可能である。
【００９０】
オペレータＡのルートディレクトリＤＩＲ Ａ０のように、参照番号７８で示したルートディレクトリＤＩＲ Ｂ０は、関連するサブディレクトリ（図示せず）と関連する１以上の累積ハッシュコード値８４と、検証ステップで用いられるオペレータＢの公開鍵を識別する鍵ナンバー８５と、対応するオペレータの私有鍵で発生される署名値８６を含む。
【００９１】
ディレクトリのサブヘッダにあるハッシュ値８４と署名８６、さらにディレクトリ７８のペイロードデータ６４を用いて、このディレクトリのハッシュ値が計算される。次いで、このハッシュ値は、サブディレクトリＡ４に格納されることによって、実行されるディレクトリテーブルにあるデータの完全性が検証可能となる。
【００９２】
署名８６とハッシュ値８４が、ハッシュ値８３の計算に含まれるということから、ルートディレクトリ７８により参照されるデータファイルの残りファイルの完全性が確認されてもよい。なぜならば、ハッシュ値８４と、さらにより重要なことに、署名値８６を変更しなければ、これらの従属ファイルはどれも変更されることはないと言えるからである。署名値８６が私有オペレータ鍵を有する者によってのみ計算可能であるため、対応するハッシュ値がさらなる従属サブディレクトリとオブジェクトファイルに対して計算されると仮定すると、ディレクトリ７８によって参照されたすべてのファイルの完全性が確認されてもよい。
【００９３】
このようにして、第２のオペレータにより発生された実行可能なプログラムなどに関係するアプリケーションデータが、安全かつ信頼できる方法で第１のオペレータと関連するアプリケーションとつなげられてもよい。
【００９４】
理解されるように、特に、各段階でハッシュ処理または署名されるデータ量を減少させるために、場合によっては多数の変更が可能である。特に、下位レベルのデータファイルを検証するために用いられるディレクトリまたはサブディレクトリにある署名またはハッシュ値の場合、ディレクトリ署名またはハッシュ値は、下位レベルのハッシュ値のみを用いて、他のデータをまったく用いずに発生されてもよい。
【００９５】
例えば、Ａ０ディレクトリ７５にある組み合わせハッシュ値７９は、参照番号７６で示されるＡ１〜Ａ４サブディレクトリのそれぞれの組み合わせハッシュ値８２、８３を用いて発生されてもよい。これらの値は、サブディレクトリのペイロードのデータと同等に特有のものであるため、組み合わせハッシュ値７９は、該当するサブディレクトリに特有の値のままとなる。さらに、ハッシュ値８２がなお計算に使用されるため、オブジェクトとディレクトリファイル７７、７８の下位レベルの完全性はなお確認されたものとしてよい。
【００９６】
同様に、参照番号７８で示されるＢ０ディレクトリを検証するために計算されるハッシュ値８２は、単純に署名値８６を用いて計算されてもよい。これは、ハッシュ値８４に従属し、特別に関連し、このハッシュ値は次のレベルのファイルに従属するため、ディレクトリ７８により参照されたデータファイルのセットのすべての完全性がなお確認されたものとしてよい。
【図面の簡単な説明】
【図１】 本発明を用いるディジタルテレビジョンシステムの概略図である。
【図２】 図１のシステムの復号器の構造を示す図である。
【図３】 ＭＰＥＧ放送トランスポートストリーム内の多数のコンポーネントの構造を示す図である。
【図４】 ソフトウェアアプリケーションが多数のＭＰＥＧテーブルに分割された状態を示す図である。
【図５】 ＤＳＭＣＣデータファイルと均等に生成されたＭＰＥＧテーブルとの関係を示す図である。
【図６】 ＤＳＭＣＣのコンテキストで規定される場合のクライアント、サーバ、ネットワーク管理者との関係を示す図である。
【図７】 本発明の実施形態における認証されるディレクトリ、サブディレクトリ、ファイルオブジェクトを示す図である。

Claims (4)

1. ディジタル伝送システムによって送信されるデータを認証する方法であって、
   前記データを、少なくとも１つのルートディレクトリユニットとサブディレクトリユニットとファイルユニットとからなる階層に組織化するステップと、
   ファイル中のデータに第１の認証アルゴリズムを適用して、該ファイルに関連付けられたファイル認証値を取得するステップと、
   前記ファイル認証値を前記ファイルに関連するサブディレクトリに格納するステップと、
   少なくとも前記ファイル認証値に第２の認証アルゴリズムを適用して、前記サブディレクトリに関連付けられたサブディレクトリ認証値を取得するステップと、
   サブディレクトリ認証値を前記サブディレクトリに関連するルートディレクトリに格納するステップと、
   を含む、前記方法。
2. ディジタル伝送システムによって送信されるデータを認証するための装置であって、
   伝送前に、前記データを、少なくとも１つのルートディレクトリユニットとサブディレクトリユニットとファイルユニットとからなる階層に組織化する手段と、
   ファイル中のデータに第１の認証アルゴリズムを適用して、該ファイルに関連付けられたファイル認証値を取得する手段と、
   前記ファイル認証値を前記ファイルに関連するサブディレクトリに格納する手段と、
   少なくとも前記ファイル認証値に第２の認証アルゴリズムを適用して、前記サブディレクトリに関連付けられたサブディレクトリ認証値を取得する手段と、
   サブディレクトリ認証値を前記サブディレクトリに関連するルートディレクトリに格納する手段と、
   を備える、前記装置。
3. ディジタル伝送ネットワークの受信装置によって、受信されたデータを検証する方法であって、
   前記データは、少なくとも１つのルートディレクトリユニットと、サブディレクトリユニットと、ファイルユニットとからなる階層に組織化されてなり、ファイル認証値は、第１の認証アルゴリズムがファイル中のデータに適用されて得られたものであって該ファイルに関連するサブディレクトリに格納されており、サブディレクトリ認証値は、第２の認証アルゴリズムが当該ファイル認証値に適用されて得られたものであって、該サブディレクトリに関連するルートディレクトリに格納されており、
   ファイル中のデータに第１の認証アルゴリズムを適用して、第１の結果値を取得するステップと、
   前記第１の結果値を前記関連するサブディレクトリに格納されている前記ファイル認証値と比較するステップと、
   前記関連するサブディレクトリに格納されている少なくとも前記ファイル認証値に第２の認証アルゴリズムを適用して、第２の結果値を取得するステップと、
   前記第２の結果値を前記関連するルートディレクトリに格納された前記サブディレクトリ認証値と比較するステップと、
   を含む、前記方法。
4. ディジタル伝送ネットワークにおいて受信されたデータの検証するための装置であって、
   前記データは、少なくとも１つのルートディレクトリユニットと、サブディレクトリユニットと、ファイルユニットとからなる階層に組織化されてなり、ファイル認証値は、第１の認証アルゴリズムがファイル中のデータに適用されて得られたものであって該ファイ ルに関連するサブディレクトリに格納されており、サブディレクトリ認証値は、第２の認証アルゴリズムが当該ファイル認証値に適用されて得られたものであって、該サブディレクトリに関連するルートディレクトリに格納されており、
   ファイル中のデータに第１の認証アルゴリズムを適用して、第１の結果値を取得する手段と、
   前記第１の結果値を前記関連するサブディレクトリに格納されている前記ファイル認証値と比較する手段と、
   前記関連するサブディレクトリに格納されている少なくとも前記ファイル認証値に第２の認証アルゴリズムを適用して、第２の結果値を取得する手段と、
   前記第２の結果値を前記関連するルートディレクトリに格納された前記サブディレクトリ認証値と比較する手段と、
   を備える、前記装置。

Images