デジタルデータストリーム及びその形成方法並びにその形成装置
【課題】デジタル伝送システムで伝送されるデータを認証する方法を提供する。
【解決手段】この方法は、伝送よりも前にデータの少なくともいくつかに対する少なくとも２つの暗号化値を決定するステップであって、各々の暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して決定されることと、前記少なくとも２つの暗号化値を前記データとともに出力するステップとを含む。
【解決手段】この方法は、伝送よりも前にデータの少なくともいくつかに対する少なくとも２つの暗号化値を決定するステップであって、各々の暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して決定されることと、前記少なくとも２つの暗号化値を前記データとともに出力するステップとを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタル伝送システムで伝送されるデータの認証の方法並びにその形成装置に関するものである。
【背景技術】
【０００２】
デジタルデータの同報伝送は、スクランブルオーディオビジュアル情報が、通常衛星あるいは衛星／ケーブルリンクによって各々がその後見るための伝送番組を暗号解読できるデコーダを所有する多数の加入者に送信されるペイＴＶシステムの分野で周知である。地上デジタル放送システムも公知である。最近のシステムは、視聴覚データに加えてあるいは視聴覚データと同様に、デコーダあるいは接続ＰＣのためのコンピュータプログラムあるいは対話型アプリケーションのような他のデータを伝送する放送リンクも使用した。
【０００３】
アプリケーションの伝送に関する特定の問題は、いかなるこのようなデータの一貫性および発生源も検証する必要性にある。この種のデータは、いかなる対話型アプリケーション数も実行するのと同様にデコーダを再構成するために使用されてもよいので、受信データは完全であり、かつ公知の発生源から発生するものとして識別されることの両方であることが重要である。特に、不完全なデータのダウンロードに関係付けられる操作上の問題が、デコーダが第三者等による攻撃を受けやすいようになる危険と同様に生じ得る。
【０００４】
このようなデータの一貫性を検証することは、デコーダによって直接受信されたデータのパケットストリームの検証によって行われてもよい。伝送より前に、パケットは、一般的にはハッシングアルゴリズムをパケットのデータの少なくともいくつかに用いることによって署名される。生じるハッシュ値はパケットに記憶される。データパケットの受信の際に、デコーダは、同じハッシングアルゴリズムをデータに用い、受信データの一貫性を検証するためにデコーダによって計算されたハッシュ値を受信パケットに記憶されたハッシュ値と比較する。例えば、伝送の故障あるいは遮断の場合、計算ハッシュ値は、受信ハッシュ値と同じでない。次に、デコーダは、ダウンロードデータパケットの可能なエラーの存在のために変更され、間違ったデータパケットを再ロードする。
【０００５】
メッセージダイジェストアルゴリズムＭＤ５のような周知のハッシングアルゴリズムの使用に関連した問題は、ハッシュ値の計算が公に公知の一連の計算ステップに従って実行されるということであり、その結果、誰でもデータパケットのハッシュ値を計算できる。したがって、デコーダによって受信されたデータパケットの発生源を検証できる。受信データがデコーダの演算データファイルを修正する場合、このことは特に重要であり得る。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
この問題を解決するために、データの少なくともいくつかに対するハッシュ値を計算するハッシングアルゴリズムを使用する代わりに、データパケットのシグネチャ値は、放送者にだけ公知である秘密鍵値を使用して計算されてもよい。この鍵は、データ暗号化規格、すなわちＤＥＳのアルゴリズムのような対称性鍵アルゴリズムを等価鍵を記憶するデコーダとともに使用して得ることができる。しかしながら、より便利なことは、公開鍵および私用鍵が数式の補数部を形成する、リベスト（Ｒｉｖｅｓｔ）、シャミール（Ｓｈａｍｉｒ）およびアデルマン（Ａｄｌｅｍａｎ）、あるいはＲＳＡのアルゴリズムのような非対称性公開／私用鍵アルゴリズムを使用することによってもたらすことができることである。
【０００７】
データパケットを生成する責任のある放送者は、私用鍵を記憶し、私用鍵を使用してシグネチャ値を計算する。この公開鍵は、製造中公開鍵をデコーダメモリへハードコーディングすることによってデータを受信すべきであるデコーダに記憶される。データパケットの受信の際に、デコーダは、受信データを公開鍵アルゴリズムを受信シグネチャ値に用いる結果と比較することによって記憶された公開鍵を使用してシグネチャ値を検証する。
【０００８】
このような安全システムにおいてさえ、私用鍵の値は、例えば不法に公然と配信することによって危険にさらされ得る。このような場合、放送者は、データパケットの無許可受信を防止するために等しい公開鍵の使用を迅速に取り消すことが必要になる。さらに、新しい公開／私用鍵対が使用されることも必要になる。したがって、放送会社は、合法ユーザのデコーダに記憶された公開鍵を新しい公開鍵と交換する必要がある。公開鍵の感度に応じて、このことは、放送者がこれらのデコーダのメモリへの新しい公開鍵のハードコーディングするために製造者へのこれらのデコーダの高価で、煩わしい返却を計画することを必要とし得る。
【課題を解決するための手段】
【０００９】
本発明の目的は、これらの問題および他の問題を解決しようとするものである。
本発明の第１の態様は、デジタル伝送システムで伝送されるデータを認証する方法を提供し、前記方法は、伝送より前に、データの少なくともいくつかに対する少なくとも２つの暗号化値を決定するステップであって、各暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して同じデータに対して決定されることと、前記少なくとも２つの暗号化値を前記データとともに出力するステップとを含む。
【００１０】
本発明は、データが「出されるように」受信されることを保証するために新しい暗号化アルゴリズムで使用される鍵のような影響されやすいデータを安全に更新することが望ましい状態に特に応用できるが、これに限定されない。このようなセキュリティを行うために、データの少なくともいくつか、好ましくは多数、より好ましくは全てに対する少なくとも２つの暗号化値が決定される。各々の暗号化値は、それぞれの暗号化アルゴリズムの鍵を使用して決定される。鍵の１つが危険にさらされるようになった場合、「ハッカー」は、データを遮断し、データおよび危険にさらされた鍵を使用して計算された暗号化値の内容を変更でき得る。暗号化値を計算するために使用される鍵と等しい鍵を使用する暗号化値の検証の際に、データが破損されるようになったことを示す、等価鍵を使用する２つの値は同じでない。
【００１１】
データおよび暗号化値は、好ましくは受信機／デコーダに伝送するために出力される。好ましくは、前記データおよび前記暗号化値は、受信機／デコーダによって受信され、この受信機／デコーダで、各暗号化値は、前記それぞれの暗号化アルゴリズムの鍵を使用して処理され、各々のその後に生じる値は、データの前記少なくともいくつかと比較され、データの前記少なくともいくつかを認証する。このデータが破損されるようになった場合、受信機／デコーダは、データを無視するように選択できるので、危険にさらされるかあるいは破損された新しい鍵は、デコーダのメモリに記憶されない。好ましくは、その後に生じる値の少なくとも１つがデータの前記少なくともいくつかとは異なる場合、前記受信データは、受信機／デコーダによって拒否される。
【図面の簡単な説明】
【００１２】
【図１】図１は本発明と併用するためのデジタルテレビシステムの概略図を示す。
【図２】図２は図１のシステムのデコーダの構成を示す。
【図３】図３はＭＰＥＧ放送トランスポートシステム内の多数の構成要素の構成を示す。
【図４】図４は多数のＭＰＥＧテーブルへのソフトウェアアプリケーションの分割を示す。
【図５】図５はＤＥＳ−ＣＣデータファイルと最終的に発生されたＭＰＥＧテーブルとの関係を示す。
【図６】図６はＤＥＳ−ＣＣの前後関係で規定されるようなクライアント、サーバ、ネットワークマネージャ関係を示す。
【図７】図７は認証ディレクトリ、サブディレクトリおよびファイルオブジェクトを示す。
【図８】図８は放送認証、認証局認証およびルート認証局認証のフォーマットを示す。
【図９】図９は認証取消リストのフォーマットを示す。
【図１０】図１０はルート認証管理メッセージ（ＲＣＭＭ）のフォーマットを示す。
【図１１】図１１はデコーダによる受信の際にＲＣＭＭの処理に含まれるステップを示す。
【図１２】図１２は本発明の動作を説明するフローチャートである。
【発明を実施するための形態】
【００１３】
したがって、本発明は、デジタル伝送システムで伝送されるデータを認証する方法に及び、前記方法は、前記データおよびデータの少なくともいくつかに対して決定された少なくとも２つの暗号化値を受信するステップであって、各々の暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して決定されることと、複数の鍵を記憶するステップと、それぞれの暗号化アルゴリズムの記憶された鍵を使用して各々の暗号化値を処理するステップと、各々のその後に生じる値をデータの前記少なくともいくつかと比較し、データの前記少なくともいくつかを認証するステップとを含む。
【００１４】
好ましくは、各アルゴリズムは非対称である。好ましい実施形態では各々の暗号化値は暗号化アルゴリズムの私用鍵で計算されたデジタルシグネチャにそれぞれ対応し、各シグネチャは前記暗号化アルゴリズムの公開鍵を使用し処理しうる。
【００１５】
好ましくは、この方法は、各々のシグネチャとともに、このシグネチャを処理するために使用される公開鍵の識別子を出力するステップを含む。これによって、受信機／デコーダは、このシグネチャを検証するために使用される鍵を容易に識別することを可能にできる。
【００１６】
好ましくは、このデータは鍵を含む。好ましい実施形態では、データは、データを処理するための暗号化アルゴリズムの公開鍵を含む少なくとも１つのデジタル認証、好ましくは少なくとも１つのデジタルルート認証を含む。この少なくとも１つのデジタル認証は、この認証に含まれる公開鍵の暗号化アルゴリズムの私用鍵を使用して計算されたデジタルシグネチャを含んでもよい。したがって、デジタル認証は、デコーダのメモリの新しい認証のハードコーディングのために製造者に戻されねばならないデコーダなしにデコーダに安全に伝送できる。
【００１７】
好ましくは、前記データは、取り消された公開鍵の識別子を含む。この識別子は、前記取り消された公開鍵を含む、デジタル認証、好ましくはデジタルルート認証の識別子を含んでもよい。このデータは、複数の前記識別子を含んでもよく、各々の識別子は、それぞれの取り消された公開鍵を識別する。したがって、取り消された鍵の識別子のリストは、デコーダに安全に伝送できる。
【００１８】
前記の方法によって、危険にさらされた鍵の数がデータとともに記憶される暗号化値の数よりも小さいとすれば、データは安全に更新できる。したがって、前記データおよび前記少なくとも２つの暗号化値は、その後に生成されたデータファイルに記憶される暗号化値の最小数の指示を含んでもよいデータファイルに構成されてもよい。鍵が危険にさらされたようになるべきであるので、暗号化値の最小数が危険にさらされた鍵の数よりも大きいままである場合、これによって、暗号化値の最小数は、変更でき、例えば増加できる。
【００１９】
好ましくは、前記データファイルに記憶された暗号化値の数を前記最小数と比較し、前記データファイルに記憶された暗号化値の数が前記最小数よりも小さい場合、前記データファイルを拒否する受信機／デコーダによって受信される。
【００２０】
このデータファイルはデータモジュールに伝送されてもよい。前記モジュールのデータの少なくともいくつかに対するモジュール暗号化値は、送信機暗号化アルゴリズムの鍵を使用して計算し、前記データモジュールに記憶できる。このデータモジュールは、送信機暗号化アルゴリズムの鍵を使用して前記モジュール暗号化値を処理し、その後に生じる値を前記モジュールのデータの前記少なくともいくつかと比較し、前記モジュールのデータの前記少なくともいくつかを認証する受信機／デコーダによって受信されてもよい。
【００２１】
前記モジュールのデータの少なくともいくつかに対する暗号化値は、送信機暗号化アルゴリズムの私用鍵を使用して計算され、前記送信機暗号化アルゴリズムの公開鍵を使用して処理可能であるデジタルシグネチャに対応し得る。
【００２２】
デジタル伝送システムは、テレビあるいはオーディオシステムのようなデジタル放送システムであってもよい。
本発明は、デジタル伝送システムで伝送されるデータを認証する装置も提供し、前記装置は、データの少なくともいくつかに対する少なくとも２つの暗号化値を決定する手段であって、各々の暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して同じデータに決定されることと、前記データとともに前記少なくとも２つの暗号化値を出力する手段とを備えている。
【００２３】
本発明は、デジタル伝送システムで伝送されるデータを認証するシステムも提供し、前記システムは前述されるような装置を含む。このシステムは、好ましくは、前記データおよび前記暗号化値を受信する手段と、前記それぞれの暗号化アルゴリズムの鍵を使用して各々の暗号化値を処理する手段と、各々のその後に生じる値をデータの前記少なくともいくつかと比較し、データの前記少なくともいくつかを認証する手段とを含む受信機／デコーダをさらに含む。
【００２４】
本発明は、データおよびデータの少なくともいくつかに対して決定される少なくとも２つの暗号化値を含むデータファイルを受信する手段であって、各々の暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して決定されることと、複数の鍵を記憶する手段と、前記それぞれの暗号化アルゴリズムの記憶された鍵を使用して各々の暗号化値を処理する手段と、各々のその後に生じる値をデータの前記少なくともいくつかと比較し、データの前記少なくともいくつかを認証する手段とを含む受信機／デコーダに及ぶ。
【００２５】
本発明は、デジタル伝送システムで伝送されるデータを認証するシステムにも及び、前記システムは、前述されたような装置および前述されたような受信機／デコーダを含む。
【００２６】
本発明は、さらにデータおよびデータの少なくともいくつかに対して決定された少なくとも２つの暗号化値を含む信号に及び、各々の暗号化値は、それぞれの暗号化アルゴリズムの鍵を使用して決定される。
【００２７】
本発明は、さらに実質的に添付図面を参照してここに説明されるようなデータを認証する方法、あるいは装置、受信機／デコーダ、あるいは信号に及ぶ。
ここで使用される用語「受信機／デコーダ」あるいは「デコーダ」は、いくつかの他の手段によって放送されてもよいしあるいは伝送されてもよい、符号化信号あるいは非符号化信号のいずれか、例えばテレビおよび／またはラジオ信号を受信する受信機を意味してもよい。この用語は、受信信号を復号化するデコーダも意味してもよい。このような受信機／デコーダの実施形態は、例えば、物理的に別個の受信機との組み合わせで機能を果たすデコーダ、あるいはウェブブラウザのようなあるいはビデオレコーダあるいはテレビのような他の装置と一体化された付加機能を含むデコーダのような「セットトップボックス」で受信信号を復号化する受信機と一体であるデコーダを含んでもよい。
【００２８】
ここで使用されるように、用語「デジタル伝送システム」は、例えば、主に視聴覚データあるいはマルチメディアデータを伝送あるいは放送するいかなる伝送システムも含む。
【００２９】
本発明は、放送デジタルテレビシステムに特に用いることができるが、本発明は、マルチメディアインターネット用途のための固定電気通信網、閉回路テレビ等にも応用できてもよい。
【００３０】
ここで使用されるように、用語「デジタルテレビシステム」は、例えば、任意の衛星システム、地上システム、ケーブルシステムおよび他のシステムを含む。
本発明で使用し、私用／公開鍵を生成するための適当なアルゴリズムは、ＲＳＡ、フィアット−シャミール、あるいはディフィ−ヘルマンを含んでもよく、適当な対称鍵アルゴリズムは、例えばＤＥＳ形アルゴリズムを含んでもよい。しかしながら、前後関係を考慮して不可欠でない限りあるいは別段の指定がない限り、対称アルゴリズムに関連した鍵と公開／私用アルゴリズムに関連した鍵との間の一般的な区別は全然行われない。
【００３１】
用語「スクランブル」および「暗号化」および「制御ワード」および「鍵」は、用語を明瞭にするためにテキストのいろいろな部分で使用された。しかしながら、「スクランブルデータ」と「暗号化データ」、「制御ワード」と「鍵」との基本的区別は、全然行われるべきでないことが分かる。
【００３２】
さらに、用語「暗号化」および「署名」や「暗号解読」および「検証」は、用語を明瞭にするためにテキストのいろいろな部分で使用された。しかしながら、「暗号化データ」と「署名データ」および「暗号解読データ」および「検証データ」との基本的区別は、全然行われるべきでないことが分かる。
【００３３】
同様に、用語「等価鍵」は、第１の記載された鍵によって暗号化されたデータを暗号解読、あるいはその逆をするために構成された鍵を示すために使用される。
本発明の方法態様に関連する前述の機能は、装置態様にも応用でき、あるいはその逆でも用いることができる。
【００３４】
次に、添付図面を参照して本発明の好ましい実施形態だけが例として説明される。
本発明によるデジタルテレビシステム１の概略１は、図１に示される。本発明は、圧縮デジタル信号を伝送するために公知のＭＰＥＧ−２圧縮システムを使用する多くの従来のデジタルテレビシステム２を含む。より詳細には、放送局のＭＰＥＧ−２圧縮器３は、デジタル信号ストリーム（一般的には、ビデオ信号のストリーム）を受信する。この圧縮器３は、リンク装置５によってマルチプレクサおよびスクランブラ４に接続される。
【００３５】
マルチプレクサ４は、複数の他の入力信号を受信し、トランスポートストリームを組み立て、もちろん通信リンクを含むいろいろの形をとることができるリンク結合装置７を介して圧縮デジタル信号を放送局の送信機６に送信する。送信機６は、アップリンク８を介して電磁信号を電子的に処理される衛星トランスポンダ９の方へ送信し、概念上のダウンリンク１０を介して従来はエンドユーザによって所有されるかあるいは賃貸される皿の形の地上受信機１２に放送する。受信機１２によって受信された信号は、ユーザエンドによって所有されるかあるいは賃貸され、エンドユーザのテレビ受像機１４に接続された統合受信機／デコーダ１３に送信される。この受信機／デコーダ１３は、圧縮ＭＰＥＧ−２信号をテレビ受像機１４のためのテレビ信号に復号化する。
【００３６】
地上放送、ケーブル伝送、結合衛星／ケーブルリンク、電話網等のようなデータの伝送のための他のトランスポートチャネルは、もちろん可能である。
マルチチャネルシステムでは、マルチプレクサ４は、多数の並列発生源から受信されたオーディオおよびビデオ情報を処理し、送信機６と対話し、対応するチャネル数に沿って情報を放送する。オーディオビジュアル情報に加えて、デジタルデータのメッセージあるいはアプリケーションもしくは任意の他の種類のデジタルデータは、送信されたデジタルオーディオおよびビデオ情報とインタレースされたこれらのチャネルのいくつかあるいは全部に導入される。このような場合、例えば、ＤＳＭ−ＣＣ（デジタル記憶メディアコマンドおよびコントロール）フォーマットソフトウェアファイルおよびメッセージの形のデジタルデータのストリームは、圧縮器３によってＭＰＥＧフォーマットに圧縮され、パケット化される。ソフトウェアモジュールのダウンロードは、下記により詳細に説明される。
【００３７】
条件付アクセスシステム１５は、マルチプレクサ４および受信機／デコーダ１３に接続され、一部が放送局にあり、一部がデコーダにある。このシステムによって、エンドユーザは、１つあるいはそれ以上の放送供給者からデジタルテレビ放送にアクセスできる。市販の売り物（すなわち、放送供給者によって宣伝された１つあるいはいくつかのテレビ番組）に関するメッセージを解読できるスマートカードは、受信機／デコーダ１３に挿入できる。デコーダ１３およびスマートカードを使用すると、エンドユーザは、加入モードあるいはペイ・パー・ビューモードのいずれかで市販の売り物を購入できる。実際には、デコーダは、例えば同時暗号あるいは複数暗号設計の多重アクセス制御システムを処理するように構成されてもよい。
【００３８】
前述されたように、システムによって放送された番組は、マルチプレクサ４でスクランブルされ、所与の伝送に加えられる条件および暗号化鍵は、アクセス制御システム１５によって決定される。このようにスクランブルされたデータの伝送は、ペイＴＶシステムの分野で周知である。一般的には、スクランブルデータは、データを暗号解読する制御ワードとともに伝送され、制御ワードそのものは、いわゆる利用鍵によって暗号化され、暗号化形式で伝送される。
【００３９】
スクランブルデータおよび暗号化制御ワードは、次にデコーダに挿入されたスマートカードに記憶された利用鍵の均等物へのアクセス権を有するデコーダ１３によって受信され、暗号化制御ワードを暗号解読し、その後、伝送データを暗号解読する。支払った加入者は、例えば、伝送を見ることができるように暗号化制御ワードを暗号解読するのに必要な利用鍵を放送月ＥＭＭ（資格管理メッセージ）で受信する。視聴覚テレビ番組を暗号解読する際のその使用に加えて、同じ利用鍵が、前述されるようなソフトウェアモジュールのような他のデータの検証で使用するために生成され、送信されてもよい。
【００４０】
マルチプレクサ４および受信機／デコーダ１３にも接続され、さらに一部が放送局にあり、一部がデコーダにある対話システム１６によって、エンドユーザは、モデム逆方向チャネル１７を介していろいろなアプリケーションと対話できる。このモデム逆方向チャネルも、条件付アクセスシステム１５で使用される通信のために使用されてもよい。対話システムは、例えば、視聴者は、直ちに放送局と通信し、特定の試合を見て、アプリケーション等をダウンロードするための許可を要求することができる。
【００４１】
（受信機／デコーダの物理的要素）
図２を参照すると、本発明で使用されるように構成される受信機／デコーダ１３あるいはセットトップボックスの物理的要素は、次に簡単に説明される。この図に示された要素は、機能ブロックによって説明される。
【００４２】
デコーダ１３は、関連メモリ要素を含み、かつ直列インタフェース２１、並列インタフェース２２、および（図１のモデム逆方向チャネル１７に接続される）モデムから入力データを受信するように構成される中央プロセッサ２０を含む。
【００４３】
デコーダは、さらに制御装置２６を介して赤外線遠隔制御装置２５からおよびデコーダの正面パネル上のスイッチコンタクト２４から入力を受信するように構成される。このデコーダは、銀行スマートカードおよび加入スマートカード２９、３０のそれぞれを読み取るように構成される２つのスマートカード読み取り器２７、２８も持つ。入力も、赤外線キーボード（図示せず）を介して受信されてもよい。加入スマートカード読み取り器２８は、挿入加入カード３０および条件付アクセス装置２９と係合し、必要な制御ワードを多重分離装置／暗号解読器３０に供給し、暗号化放送信号は暗号解読できる。デコーダは、装置３０によってフィルタリングされ、多重分離される前に衛星伝送を受信し、復調する従来のチューナ３１および復調器３２も含む。
【００４４】
デコーダ内のデータの処理は、通常、中央プロセッサ２０によって処理される。中央プロセッサのソフトウェアアーキテクチャは、デコーダのハードウェア構成要素で実行される下部レベルオペレーティングシステムと対話する仮想機械に対応する。
【００４５】
（伝送データのパケット構造）
次に、図３および４を参照して、送信機からデコーダに送信される放送ＭＰＥＧトランスポートストリーム内のデータのパケット構造が説明される。理解されるように、この説明はＭＰＥＧ規格で使用される作表フォーマットに集中するが、同じ原理は、同様に他のパケット化データストリームフォーマットに用いる。
【００４６】
特に、図３を参照すると、ＭＰＥＧビットストリームは、０のパケット識別（ＰＩＤ）を有する番組アクセステーブル（ＰＡＴ）４０を含む。ＰＡＴは、多数の番組の番組マップテーブル（ＰＭＴ）４１のＰＩＤの関連を含む。各ＰＭＴは、この番組のためのオーディオＭＰＥＧテーブル４２およびビデオＭＰＥＧテーブル４３のストリームのＰＰＩＤの関連を含む。ゼロのＰＩＤを有するパケット、すなわち、番組アクセステーブル４０は、全ＭＰＥＧアクセスのためのエントリポイントを与える。
【００４７】
アプリケーションおよびそのためのデータをダウンロードするために、２つの新しいストリーム形式が規定され、関連するＰＭＴは、アプリケーションＭＰＥＧテーブル４４（あるいはこれらの一部）およびデータＭＰＥＧテーブル４５（あるいはこれらの一部）のストリームのＰＩＤの関連も含む。実際は、実行可能なアプリケーションソフトウェアおよびこのようなソフトウェアによって処理するためのデータのための別個のストリーム形式を規定することはいくつのかの場合便利であり得るが、これは重要でない。他の実現では、データおよび実行可能なコードは、記載されるようなＰＭＴを介してアクセスされる単一ストリームに組み立てできる。
【００４８】
図４を参照すると、例えばストリーム４４内のアプリケーションをダウンロードするために、アプリケーション４６は、各々がＭＰＥＧテーブルによって形成されるモジュール４７に分割される。これらのテーブルのいくつかは単一部分を含むが、他のものは複数の部分４８によって構成されてもよい。典型的なセクション４８は、１バイトのテーブルＩＤ（「ＴＩＤ」）５０、テーブルのこのセクションのセクション番号５１、このテーブルの全セクション数５２および２バイトのＴＩＤ拡張関連５３を含むヘッダを有する。各セクションは、データ部５４およびＣＲＣ５５も有する。特定のテーブル４７の場合、このテーブル４７を構成するセクション４８の全ては、同じＴＩＤ５０および同じＴＩＤ拡張部５３を有する。特定のアプリケーション４６の場合、このアプリケーション４６を構成するテーブルの全ては、同じＴＩＤ５０であるが、異なるそれぞれのＴＩＤ拡張部を有する。
【００４９】
各々のアプリケーション４６の場合、単一ＭＰＥＧテーブルは、ディレクトリテーブル５６として使用される。このディレクトリテーブル５６は、そのヘッダにおいて、アプリケーションを構成する他のテーブル４７と同じＴＩＤを有する。しかしながら、ディレクトリテーブルは、ＩＤ目的のためにゼロの所定のＴＩＤ拡張部を有し、この事実のために単一テーブルだけはディレクトリの情報に対して必要である。他のテーブル４７の全ては、通常非ゼロＴＩＤ拡張部を有し、多数の関連セクション４８で構成される。ディレクトリテーブルのヘッダは、ダウンロードされるアプリケーションのバージョン番号も含む。
【００５０】
戻って図３を参照すると、ＰＡＴ４０、ＰＭＴ４１、およびアプリケーション・データストリーム成分４４、４５は、周期的に伝送される。伝送される各アプリケーションは、それぞれの所定のＴＩＤを有する。アプリケーションをダウンロードするために、適切なＴＩＤおよびゼロのＴＩＤ拡張部を有するＭＰＥＧテーブルは、受信機／デコーダにダウンロードされる。これは、必要とされるアプリケーションのためのディレクトリテーブルである。このディレクトリのデータは、次にデコーダによって処理され、必要とされるアプリケーションを構成するテーブルのＴＩＤ拡張部を決定する。その後、ディレクトリテーブルと同じＴＩＤおよびディレクトリから決定されるＴＩＤ拡張部を有するいかなる必要とされるテーブルもダウンロードできる。
【００５１】
このデコーダは、そのいかなる更新のためのディレクトリテーブルも検査するように構成される。これは、例えば、３０秒あるいは１分あるいは５分毎に周期的に再度ディレクトリをダウンロードし、予めダウンロードされるディレクトリテーブルのバージョン番号を比較することによって行われてもよい。新しくダウンロードされたバージョン番号が後のバージョン番号である場合、前のディレクトリテーブルに関連したテーブルは削除され、新しいバージョンに関連したテーブルは、ダウンロードされ、集められる。
【００５２】
代替の装置では、入ってくるビットストリームは、アプリケーションのＴＩＤ、ゼロのＴＩＤ拡張部および目下ダウンロードされたディレクトリのバージョン番号よりも１つ大きいバージョン番号のためにセットされる値とともにＴＩＤ、ＴＩＤ拡張部およびバージョン番号に対応するマスクを使用してフィルタリングされる。したがって、バージョン番号の増加が検出され、一旦検出されると、前述されるように、ディレクトリはダウンロードされ、アプリケーションは更新される。アプリケーションが終了されるべきである場合、次のバージョン番号を有する空のディレクトリは、ディレクトリに列挙された少しのモジュールもないことを除いて伝送される。このような空のディレクトリの受信に応じて、デコーダ２０２０は、アプリケーションを削除するようにプログラムされる。
【００５３】
実際には、デコーダでアプリケーションを実行するソフトウェアおよびコンピュータプログラムは、特に前述されるような衛星リンクを介して受信されるデータストリームに、デコーダの一部のいずれかを介してであるが、直列ポート、スマートカードリンク等も介して導入されてもよい。このようなソフトウェアは、ネットブラウザ、クイズアプリケーション、番組案内等のようなデコーダ内の対話型アプリケーションを実行するために使用される高レベルアプリケーションを含んでもよい。ソフトウェアも、例えば「パッチ」等によってデコーダソフトウェアの作動構成を変えるようにダウンロードされてもよい。
【００５４】
アプリケーションも、デコーダを介してダウンロードされ、デコーダに接続されたＰＣ等に送信されてもよい。このような場合、デコーダは、最終的には接続装置で実行されるソフトウェアのための通信ルータの役目を果たす。このルーティング機能に加えて、デコーダも、ＰＣに経路指定する前にＭＰＥＧパケット化データを例えばＤＳＭ−ＣＣプロトコル（下記を参照）に従って構成されたコンピュータファイルソフトウェアに変換する機能を果たしてもよい。
【００５５】
（データファイルのデータの構成）
図５は、ＤＳＭ−ＣＣ Ｕ−Ｕ（ユーザ対ユーザ）データファイル６０のセット、集められたアプリケーション４６に構成され、一連のＭＰＥＧテーブル４７内にカプセル化されるようなデータ間の関係を示す。この関係は国際特許出願番号第９９／４９６１４に記載されており、その内容は下記に参照される。
【００５６】
伝送より前に、データファイルは、アプリケーション４６に集められ、その後、ＭＰＥＧ圧縮器によって、前述されるようにＭＰＥＧパケットストリームに固有なヘッダ４９を含み、かつテーブルＩＤ、バージョン番号等を含むＭＰＥＧテーブルあるいはモジュール４７にパケット化される。理解されるように、データファイル６１に構成されるデータと最終的なＭＰＥＧテーブル４７との間に一定の関係が全然ない。デコーダによる受信およびフィルタリング後、パケットヘッダ４９は、廃棄され、アプリケーション４６は、テーブル４７のペイロードから再構成される。
【００５７】
データファイルのためのＤＳＭ−ＣＣフォーマットは、特にマルチメディアネットワークで使用するために適合され、図６に示されるように、クライアントユーザ７０、サーバユーザ７１とネットワーク資源マネージャ７２との間の通信のための一連のメッセージフォーマットおよびセッションコマンドを規定する規格である。ネットワーク資源マネージャ７２は、ネットワーク内の資源の属性を管理するように作動する論理エンティティとみなされてもよい。
【００５８】
クライアントとサーバとの間の通信は、一連のセッションによって作動可能な状態にされ、第１の一連のメッセージは、通信のためのクライアントおよび／またはサーバを構成するためにユーザ（クライアント７０あるいはサーバ７１）とネットワークマネージャ７２との間で交換される。このようなメッセージは、いわゆるＤＳＭ−ＣＣ Ｕ−Ｎ（ユーザ対ネットワーク）に従ってフォーマット化される。このプロトコルのサブセットは、特にデータを放送ダウンロードするために規定された。
【００５９】
一旦通信リンクが確立されると、メッセージは、ＤＳＭ−ＣＣ Ｕ−Ｕプロトコルに従ってクライアント７０とサーバ７１との間でその後交換される。この種の一連のメッセージは、図５のデータファイル６０に対応する。ＤＳＭ−ＣＣ Ｕ−Ｕメッセージの場合、データは、ＢＩＯＰ（Ｂｒｏａｄｃａｓｔ ＩｎｔｅｒＯｒｂ Ｐｒｏｔｏｃｏｌ）従ってグループ化される。
【００６０】
各メッセージあるいはオブジェクト６１は、ヘッダ６２と、サブヘッダ６３と、データそのものを含むペイロード６４とを含む。ＢＩＯＰプロトコルに従って、ヘッダ６２は、とりわけ、メッセージおよびＢＩＯＰバージョンの形式の指示を含むが、サブヘッダは、システム設計者によって規定されるオブジェクトおよび他の情報の形式を示す。
【００６１】
ＤＳＭ−ＣＣ Ｕ−Ｕファイルのペイロード内のデータオブジェクト６４は、通常３つの形式、すなわちディレクトリオブジェクト、ファイルオブジェクトおよびストリームオブジェクト、の中の１つとして規定できる。ディレクトリオブジェクトは、実際のアプリケーションデータを含む一連の関連ファイルオブジェクトを関連付けるために使用されるルートディレクトリあるいはサブディレクトリを規定する。
【００６２】
ストリームオブジェクトは、一時の関係がデータファイルに含まれるデータとＭＰＥＧパケットストリームそのものとの間に確立できるために使用されてもよい。これは、例えば、データファイルに含まれ、かつデコーダによって受信され、処理される基本ビデオあるいはオーディオストリームと同期されるように設計される対話形アプリケーションの場合、使用されてもよい。前述されるように、特にＭＰＥＧパケット化データとデータファイルとの間に全然直接の相関が有り得ない。
【００６３】
ＭＰＥＧテーブルと違って、単一ディレクトリがテーブルのセットを単一レベルの階層のみと関連付ける場合、データファイル６０は、かなりより複雑な階層のように構成されてもよい。ＰＣあるいはサーバに記憶されるファイルのように、主ディレクトリあるいはルートディレクトリは、順に第２のレベルのデータファイルを参照する１つあるいはそれ以上のサブディレクトリを参照してもよい。（データファイルのセットのためのファイル構造）
【００６４】
図７を参照すると、データファイルのセットのためのファイル構造の例が示されている。７５に示されるルートディレクトリＤＩＲＡ０は、サブディレクトリＡ１のグループをオブジェクトファイル７７に関連付ける。明瞭にするために、サブディレクトリＡ４と関連するオブジェクトファイルＦ１、Ｆ２等の単一グループだけが示されている。実際には、多数のオブジェクトファイルのグループは、サブディレクトリＡ１からＡ４の各々によって関連付けられてもよい。
【００６５】
各々のディレクトリおよびサブディレクトリ内で、認証ステップのセットは、このディレクトリに結合されるファイルのために導入される。ルートディレクトリ７５を参照すると、サブヘッダ６３は、ハッシュアルゴリズムを７６と示されたサブディレクトリファイルＡ１からＡ４に記憶されたデータのいくつかあるいは全てに用いることによって得られたハッシュ値を含む。使用されるハッシングは、例えば、メッセージダイジェストアルゴリズムＭＤ５のような任意の公知の形式のものであってもよい。
【００６６】
１つの実現では、このアルゴリズムは、各々の関連ファイルあるいはサブディレクトリに個別に適用され、各サブディレクトリ７６のためのハッシュ値のリストは、伝送より前にルートディレクトリ７５に記憶されてもよい。しかしながら、このような解決策は、各々のサブディレクトリを検証することに関する分解能をチェックする度合いの増加を可能にするが、この解決策は、対応するシグネチャを計算するためにデコーダのために必要である処理時間に関してかなり役に立たないことが有り得る。したがって、ディレクトリ７９のサブヘッダ６３は、好ましくは、ＭＤ５ハッシングアルゴリズムを結合されたサブヘッダおよびサブディレクトリ７６のペイロード部６３、６４に用いることによって計算され、すなわちヘッダ６２がない累積ハッシュ値７９を含む。特に、サブディレクトリ７６内に含まれ、ファイルオブジェクト７７の層を示すハッシュ値８２は、このハッシング計算に含まれる。
【００６７】
図７に示されたサブディレクトリＡ４の場合、このサブディレクトリそれ自体は、７７に示されるオブジェクトＦ１〜Ｆｎのセットを示す。この場合、累積ハッシュ値８２は、オブジェクトファイル７７の結合内容のために生成される。この値は、ハッシュ値７９を生じるハッシング処理に含まれる。したがって、順にディレクトリ７５のハッシュ値７９を変えるサブディレクトリ７６のハッシュ値８２を変えないでオブジェクトファイル７７のいずれかを変えることができない。
【００６８】
この場合、結合されたハッシュ値は、ディレクトリに示されたサブディレクトリの全てに対して計算される。このハッシュ値は、そこからデータがとられるサブディレクトリのグループの識別子とともに記憶される。他の実施形態では、一連の結合されるかあるいは個別のハッシュ値および対応する識別子は、ディレクトリのサブヘッダに記憶されてもよい。
【００６９】
例えば、ルートディレクトリとも関連するが、異なるデータのセットあるいは実行可能なコードに関する第２のサブディレクトリのセットも、一緒にグループ化され、累積ハッシュ値は、計算され、サブヘッダルートディレクトリに記憶されたこれらのサブディレクトリのために計算されてもよい。単一ディレクトリに関連した単一ハッシュ値は、同様にルートディレクトリのサブヘッダに記憶されてもよい。
【００７０】
グループあるいは個別のデータファイルの認証は、もちろん、ルートディレクトリ（あるいは、実際に任意の他のファイル）が無効あるいは未ハッシュのデータファイルも示すことを防止しなくて、このようなファイルの確認がないことは、このファイルとの任意の動作を考慮する必要がある。この点では、例えば、システムオブジェクトを認証することは必要であり得ない。
【００７１】
この場合のハッシング関数の使用によって、主にデコーダは、ダウンロードデータファイルの一貫性あるいはダウンロードデータファイルを完備していることを検証できる。例えば、伝送における故障あるいは遮断の場合、受信された従属ファイルの累積ハッシングアルゴリズムの演算は、ルートディレクトリに記憶されたこれらのファイルに対するハッシュ値と同じ結果を得られる。次に、デコーダは、ダウンロードデータの可能なエラーがあることに変更され、誤ったデータファイルを再ロードする。
【００７２】
（ルートディレクトリのためのシグネチャ値）
高められたセキュリティの場合、ルートディレクトリ７５のためのシグネチャ値が計算される。本実施形態では、リベスト（Ｒｉｖｅｓｔ）、シャミール（Ｓｈａｍｉｒ）およびアデルマン（Ａｄｌｅｍａｎ）あるいはＲＳＡアルゴリズムが使用され、データファイルを生成する責任を負うべき放送会社は、私用鍵値を所有し、公開鍵は、デコーダによって保持される。一方、秘密鍵は、データ暗号規格あるいはＤＥＳアルゴリズムのような対称性鍵アルゴリズムによって得られる鍵に対応し得る。
【００７３】
図７に示されるように、ルートディレクトリ７５は、放送会社の私用鍵を使用して生成される計算されたシグネチャ値８１とともに検証工程で使用される公開鍵をデコーダのために識別する放送会社識別子８０を含む。この場合、シグネチャ値８１は、放送会社によって保持される私用鍵を好ましくはペイロードデータ６４および／または累積ハッシュ値７９を含むディレクトリ７５内のデータのいくつかあるいは全てに用いることによって生成される。次に、このデコーダは、放送会社識別子８０によって識別される対応する公開鍵を使用してこのシグネチャ値８１を検証できる。
【００７４】
本例では、ディレクトリ７５のデータは、暗号化されなくて、この私用鍵は、公開鍵によって検証できるシグネチャ値を生じるために単に使用できる。代替実施形態では、ディレクトリの内容のいくつかあるいは全ては、私用鍵によって暗号化され、その後、対応する鍵によって暗号解読されてもよい。
【００７５】
どちらかの場合でも、秘密鍵の使用による暗号化コードのシグネチャ値あるいはブロックの生成によって、デコーダは、ディレクトリ７５の一貫性および発生源、および密接な関係によってこのルートディレクトリによって参照されるファイルの一貫性および発生源を検証できる。参照ファイルのための累積ハッシュ値は、シグネチャ８１の計算に含まれるので、これが検証工程で検出されない限りこれらの値を変更できない。各ハッシュ値は通常所与のデータのセットに固有であるので、したがってその固有のハッシュ値、それによってディレクトリの生じるシグネチャ値を変えないで従属ハッシュファイルのいずれかの内容を変えることができない。
【００７６】
理解されるように、多数の変更は、特に各工程でハッシュされるかあるいは署名されるデータ量を減らすことを可能にし得る。特に、下部レベルデータファイルを検証するために使用されるディレクトリあるいはサブディレクトリのシグネチャあるいはハッシュ値の場合、ディレクトリシグネチャあるいはハッシュ値は、下部レベルハッシュ値だけを使用し、他のデータだけを使用しないで生成されてもよい。
【００７７】
例えば、Ａ０ディレクトリ７５の結合ハッシュ値７９は、７６に示されるＡ１−Ａ４サブディレクトリの各々の結合ハッシュ値８２、８３を使用して生成されてもよい。これらの値は、丁度サブディレクトリのペイロードのデータと同様に独自であるので、結合ハッシュ値７９は、なお当のサブディレクトリに固有である。さらに、ハッシュ値８２はなお計算で使用されるので、オブジェクトファイルおよびディレクトリファイル７７、７８の下部レベルの一貫性がなお推測される。
【００７８】
（放送会社デジタル認証）
図８を参照すると、公開鍵９１および放送会社識別子８０は、好ましくは、製造中デコーダのメモリにハードコード化される周知の国際標準化機構（ＩＳＯ）Ｘ．５０９の形のデジタル認証でデコーダのユーザに供給される。このような認証は、通常認証局（ＣＡ）と呼ばれる信用された第三者によってデコーダの製造者に配信される。このような認証の使用は、ワールドワイドウェブ（ＷＷＷ）を介するクレジットカードトランザクションを保護するネットスケープ通信によって開発され、標準化された安全ソケットレイヤー（ＳＳＬ）安全トランスポートプロトコルにより主により広く受け入れるようになる。
【００７９】
公開鍵９１および放送会社識別子８０と同様に、放送会社に関連したデジタル認証、すなわち、放送会社認証９０は、以下を含む。
放送会社認証９０のバージョン番号９２；
放送会社認証９０の連続番号９３；
放送会社認証９０を配信したＣＡのＣＡ識別子９４；
認証が使用されることを意図されている時間の開始および終了を示す放送会社認証９０の有効期間９５；
放送会社認証９０のシグネチャ値９６。
【００８０】
前述から分かるように、放送会社認証は、２つの異なる識別子、すなわち認証の分配者のＩＤ９４に対応する第１の「発行者名」識別子および公開鍵９１を識別する識別子８０に対応する第２の「主題名」識別子を含む。
【００８１】
ＣＡは、ＣＡの私用鍵、すなわちＣＡ私用鍵を放送会社認証内のデータの少なくともいくつかあるいは全てに用いることによって放送会社認証９０のシグネチャ値９６を計算する。次に、デコーダは、ＣＡ識別子９４によって識別される対応するＣＡ公開鍵１０１を使用してシグネチャを処理することによってこのシグネチャ値９６を検証し、認証の内容がＣＡによってシグネチャに続いて修正されなかったことを判定する。
デコーダは、異なるそれぞれの放送会社に対する複数のこのような認証を記憶してもよい。
【００８２】
（認証局デジタル認証）
さらに図８を参照すると、対応するＣＡ公開鍵１０１およびＣＡ識別子９４は、製造中デコーダでもハードコード化されるＣＡ認証１００のデコーダのユーザに供給される。ＣＡ認証１００は、以下を含む。
ＣＡ認証１００のバージョン番号１０２；
ＣＡ認証１００の連続番号１０３；
ＣＡ認証１００を配信した欧州電気通信標準化機構（ＥＴＳＩ）のようなルート認証局（ＲＣＡ）のＲＣＡ識別子１０４；
ＣＡ認証１００の妥当性期間１０５；
ＣＡ認証１００のシグネチャ値１０６。
【００８３】
前述から分かるように、ＣＡ認証は、２つの異なる識別子、すなわち認証の分配者の識別子１０４に対応する第１の「発行者名」識別子および公開鍵１０１を識別する識別子９４に対応する第２の「主題名」識別子を含む。
【００８４】
ＲＣＡは、ＲＣＡの私用鍵、すなわちＲＣＡ私用鍵をＣＡ認証内のデータの少なくともいくつかあるいは全てに用いることによってＣＡ認証１００のシグネチャ値１０６を計算する。次に、デコーダは、ＲＣＡ識別子１０４によって識別される対応するＲＣＡ公開鍵１１１を使用して認証を処理することによってこのシグネチャ値９６を検証し、認証の内容がＲＣＡによってシグネチャに続いて修正されなかったことを判定する。
【００８５】
デコーダは、異なるそれぞれのＣＡに対する複数のこのような認証を記憶してもよい。
【００８６】
（ＲＣＡデジタル認証）
対応するＲＣＡ公開鍵１１１およびＲＣＡ識別子１０４は、製造中にデコーダのメモリでもハードコード化され、ＲＣＡ、すなわちルート認証１１０のデコーダのユーザに供給される。各デコーダは、一般的には２つあるいはそれ以上のルート認証（ｒｏｏｔ ｃｅｒｔｉｆｉｃａｔｅ）のセットを含む。各ルート認証１１０は、以下も含む。
ルート認証１１０のバージョン番号１１２；
ルート認証１１０の連続番号１１３；
ルート認証１１０の妥当性期間１１４；
ルート認証１１０のシグネチャ値１１５。
前述から分かるように、ルート認証は、単一の識別子、すなわち認証の配信者の識別子１０４だけを含む。この識別子１０４は公開鍵１１１も含む。したがって、ルート認証は、発行者名が主題名と同じである認証として規定されてもよい。
【００８７】
ルート認証は、放送会社認証９０−ＣＡ認証１００−ルート認証１１０の連鎖の最終認証であるので、ルート認証は、自動署名され、すなわち、シグネチャ値は、公開鍵１１１と等価の私用鍵を使用して計算される。したがって、ルート認証の内容が公に利用できるようにならないことに関心がある。
【００８８】
もちろん、ＲＣＡは、放送会社認証をデコーダの製造者に直接供給することができ、その場合、放送会社認証は、ＲＣＡ識別子１１１を含み、ＲＣＡ私用鍵を使用して署名される。
【００８９】
（認証取り消しリスト）
放送会社認証９０およびＣＡのいずれかは、例えば認証に記憶された公開鍵に対応する私用鍵が危険にさらされるようになる場合、それで指定された妥当性期間の満了より前に例えば削除によって取り消されてもよい。このような取り消しは、取り消される認証の連続番号９２、１０２のリストを含む認証取り消しリスト（ＣＲＬ）のデコーダへの伝送によって行うことができる。取り消しの際に、認証は、好ましくは、デコーダのメモリからの認証の削除によって実行できないようになり、それによって危険にさらされた私用鍵を使用して署名される任意の不許可の可能性のある悪意のあるデータパケットのダウンロードを防止する。
【００９０】
ＣＲＬは、ＣＡあるいはＲＣＡのいずれかによって放送会社に配信される。そして放送会社はＣＲＬをデコーダに伝送するが、モデム逆方向チャネル１７、あるいはＭＰＥＧトランスポートストリームにＣＲＬを含めて放送することのいずれかによってＣＲＬを伝送する。放送会社が、送信機からデコーダに送信されるトランスポートストリームの全てにＣＲＬを挿入することは重要でない。デコーダによって同調される可能性が非常に高いトランスポートストリームに放送会社がＣＲＬを挿入すれば十分である。ＣＲＬは、例えば、データファイルとして送信機からデコーダへ放送されるデータファイルのセットのルートディレクトリ７５あるいはサブディレクトリ７６に挿入されてもよい。
【００９１】
図９を参照すると、ＣＲＬ１２０は、一般的には、以下を含む。
ＣＲＬ１２０を配信したＣＡあるいはＲＣＡの識別子９４あるいは１０４；
ＣＲＬ１２０が発行された日付１２２；
次のＣＲＬの発行が予想される日付１２４；
各々の取り消された認証に対して、この認証の取り消しの時間および日付を含む、取り消された認証の連続番号のリスト１２５；
ＣＲＬ１２０を配信したＣＡあるいはＲＣＡの私用鍵を使用して計算されたＣＲＬのシグネチャ値１２６。
【００９２】
ＣＲＬの受信の際に、デコーダは、そのＣＲＬ１２０が発行された日付１２２を、予め受信したＣＲＬによって通知されたＣＲＬ１２０の発行が予想される日付１２４と比較する。新しく受信されたＣＲＬの日付１２２がＣＲＬの発行が予想される日付１２４よりも後でない場合、新しく受信されたＣＲＬは無視される。
【００９３】
新しく受信されたＣＲＬの日付１２２が、ＣＲＬの発行が予想される日付１２４よりも後である場合、ＣＲＬのシグネチャは、ＣＲＬに含まれる識別子９４あるいは１０４を使用して識別されるように、ＣＡの発行者の公開鍵を使用して検証される。
【００９４】
ＣＲＬの一貫性がそのように検証される場合、ＣＲＬは、次のＣＲＬが出されることが予想される日付１２４を固定メモリに記憶し、取り消された認証の連続番号のリスト１２５を記憶するように日付１２４を加えるために処理される。取り消された認証の受信リスト１２５は、デコーダの固定メモリにも記憶される。性能の理由のために、ＣＲＬ１２０がデコーダのメモリにキャッシュされるのが好ましい。デコーダのキャッシュメモリがＣＲＬ１２０を樹枝状に記憶することも好ましく、ＲＣＡのＣＲＬは、「ツリー」の上部およびこのＲＣＡがツリーの底部にある認証を配信するＣＡのＣＲＬにある。
【００９５】
放送会社認証９０の取り消しの場合、例えば、放送会社の私用鍵が危険にさらされるようになる場合、この放送会社に対する認証局は、放送会社認証９０の連続番号９３をそのＣＲＬ１２０に加える。認証局は、その後、新しいＣＲＬ１２０を放送会社に配信する。その配信先は、放送のために放送会社認証９０を配信するすべての放送会社である。デコーダが新しいＣＲＬ１２０をダウンロードするや否や、例えば、放送会社のチャネルで早送りする際に、ＣＲＬキャッシュは、更新され、ＣＲＬ１２０のリスト１２５でそのように識別されたいかなる認証の取り消しも行われる。
【００９６】
交換される放送会社認証９０は、認証局によって生成され、ファイルのディレクトリ７５あるいは７６のユーザに放送する。交換される放送会社認証は、とりわけ、新しい公開鍵９１と、更新バージョン番号９２と、更新妥当性期間９５と、ＣＡの私用鍵を使用して計算された新しいシグネチャ値９６とを含む。放送会社識別子８０およびＣＡ識別子９４は変更されないままである。交換される放送会社認証９０の受信の際に、デコーダは、ＣＡ識別子９４によって識別されたＣＡ認証に含まれる対応するＣＡ公開鍵を使用して、交換される放送会社認証９０を処理することによって、その認証を検証する。
【００９７】
ＣＡ認証１００の取り消しの際に、このＣＡのＣＲＬは、デコーダのメモリから取り除かれる。したがって、例えば、このＣＡのＣＲＬのサイズがデコーダのキャッシュメモリに記憶するためにあまりに大きくなる場合、ＣＡ認証１００を任意に取り消すことは望ましいことで有り得る。この場合、ＣＡ認証１００をこのＣＡに配信するＲＣＡは、このＣＡ認証１００の連続番号をそのＣＲＬに追加する。ルート認証局は、その後、ＲＣＡがＣＡ認証を配信するＣＡが放送するための放送会社認証を順に配信する放送会社の全てに新しいＣＲＬを配信する。デコーダが新しいＣＲＬをダウンロードするや否や、例えば、放送会社のチャネルで早送りする際に、ＣＲＬキャッシュは更新され、ＣＲＬ１２０のリスト１２５にそのように識別されたＣＡ認証の取り消しが行われる。
【００９８】
認証局のＣＡ認証１００の取り消しの際に、この認証局のための新しいＣＡ認証をデコーダに記憶させ、その上、この認証局が認証を配信する放送会社の全てに対して放送会社認証９０を交換する必要がある。それは、この認証局のための私用鍵対はもはや有効でないので、認証局の、異なるか更新された私用鍵を使用して署名された新しい放送会社認証９０が必要とされるからである。交換されるＣＡ認証１００は、ルート認証局１１０によって生成され、ファイルのディレクトリ７５あるいは７６のユーザに放送される。交換される放送会社認証と同様に、交換されるＣＡ認証は、とりわけ、新しいＣＡ公開鍵１０１と、更新バージョン番号１０２と、更新妥当性期間１０５と、ＲＣＡの私用鍵を使用して計算された新しいシグネチャ値１０６とを含む。ＣＡ識別子９４およびＲＣＡ識別子１０４は変更されないままである。交換されるＣＡ認証１００の受信の際に、デコーダは、ＲＣＡ識別子１０４によって識別されたＲＣＡ認証１００に含まれる対応するＲＣＡ公開鍵を使用してＣＡ認証１００を処理することによって認証を検証する。
【００９９】
（ルート認証管理メッセージ）
ルート認証局のＲＣＡ認証１１０の取り消しの際に、取り消されたＲＣＡ認証を新しいＲＣＡと交換する必要がある。前述されるように、ＲＣＡ認証は自動署名されるので、ＣＲＬへＲＣＡ認証を含めることは、ハッカーがＣＲＬを署名するために使用される私用鍵を知っている場合、ハッカーは認証を持つことができるので望ましくない。したがって、例えば、ＲＣＡ認証が旧式になったかあるいは取り消されるようになった場合、これまでＲＣＡ認証が更新されるべきである度にデコーダを製造者に戻すことが必要であった。
【０１００】
この問題を解決するために、ルート認証管理メッセージ（ＲＣＭＭ）は、放送会社によってデコーダに放送するためにルート認証局によって生成される。下記により詳細に説明されるように、ＣＲＬと同様に、ＲＣＭＭは、旧式になったかあるいはリスト１２５に識別されたこれらの認証のための１つあるいはそれ以上の交換ルート認証とともに、各々の取り消されたルート認証に対してこの認証の取り消しのための時間および日付を含む、取り消されるルート認証の連続番号のリスト１２５を含む。
【０１０１】
理解されるように、ＲＣＭＭの秘密にかかわる内容（新しいルート認証）に関して、放送会社に「出されるような」デコーダによって受信されることを保証すること、すなわちＲＣＭＭの内容が配信と受信との間で交換されないことを保証することは、重要である。ＲＣＭＭが、ＲＣＭＭがアドレスされる誰かにデコーダによってだけアクセスできることを保証することも重要である。
【０１０２】
セキュリティを高めるために、ＣＲＬと違って、ＲＣＭＭは、その中に含まれるデータの少なくともいくつか、好ましくは全てに対する少なくとも２つのシグネチャ値を含む。各々のシグネチャ値は、公開鍵／私用鍵対の私用鍵のようなそれぞれの暗号化アルゴリズムの鍵を使用して計算される。
【０１０３】
ＲＣＭＭがルート認証局（ＲＣＡ）によって出され、新しいルート認証１１０を含む場合、ＲＣＭＭは、少なくとも２つのシグネチャ値を含む。各々のシグネチャ値は、例えば、ＲＣＡが認証を供給する認証局のそれぞれの私用鍵を使用して計算される（ただし、デコーダが等しい鍵を記憶するいかなる鍵も選択されてもよい）。これらの認証局の中の１つに未知であり、その私用鍵が危険にさらされるようになる場合、「ハッカー」は放送会社の放送を遮断することが可能であり得る。ハッカーが放送会社および認証局の両方の私用鍵を知っている場合、ハッカーは、ＲＣＭＭの内容および認証局の私用鍵を使用して計算されたＲＣＭＭのシグネチャ値を変える。しかしながら、この鍵は危険にさらされているようにならないために、ハッカーは、他の認証局の私用鍵を使用して計算されたシグネチャ値を変えることができない。したがって、２つの認証局の公開鍵を使用してデコーダによるシグネチャの検証の際に、それぞれの公開鍵を使用してデコーダによって計算された２つの値は同じでない。したがって、デコーダは、ＲＣＭＭの内容の一貫性の欠如のために変えられ、ＲＣＭＭの処理を拒否し、またはその他ＲＣＭＭの処理を続けない。
【０１０４】
したがって、もし危険にさらされた認証数がＲＣＭＭに含まれたシグネチャ数よりも小さいとすれば、ルート認証は安全に更新できる。したがって、ＲＣＭＭのシグネチャ数は、ＲＣＭＭを配信するルート認証局によって決定された変数である。
【０１０５】
次に、ＲＣＭＭのフォーマットは、図を参照してより詳細に示されている。
ＲＣＭＭ１３０は、ＲＣＭＭ１３０を配信したＲＣＡの一貫性１３２；
ＲＣＭＭ１３０が発行した日付１３４；
その後のＲＣＭＭが含むシグネチャ値の数１３６；
１つあるいはそれ以上の更新されるかあるいはデコーダに記憶される交換ルート認証を含むフィールド１３８；
【０１０６】
各々の取り消されたルート認証に対してこの認証の取り消しの時間および日付を含む、取り消されたルート認証の連続番号のリスト１４０；および各々が、このシグネチャフィールドに含まれたシグネチャ値を検証するために使用される公開鍵を含む、デコーダに記憶された認証の識別子１４４；および識別子１４４によって識別される認証に含まれる公開鍵に等しい私用鍵を使用して計算されたＲＣＭＭのシグネチャ値１４６を含む少なくとも２つのシグネチャフィールド１４２を含む。
【０１０７】
シグネチャフィールド数１４２は、予め受信されたＲＣＭＭに通知されるようなシグネチャフィールド数１３６に等しいかあるいはそれよりも大となるべきである。
モデム逆方向チャネルは容易に切り離してもよいしあるいは単に存在しなくてもよいので、ＲＣＭＭはＭＰＥＧトランスポートストリームを介して伝送されることが好ましい。ＲＣＭＭが、デコーダによってダウンロードされることを保証するために放送会社によってデータファイルとしてルートディレクトリ７５に挿入されることも好ましい。
【０１０８】
（ルート認証管理メッセージの処理および生成）
次に、デコーダによるＲＣＭＭの受信および処理は、図１１を参照して説明される。
ＲＣＭＭの受信の際に、ステップ２００では、デコーダは、予めＲＣＭＭを出されたＲＣＭＭ１３０が出された日付１３４を比較する。新しい受信されたＲＣＭＭの日付１３４が前のＲＣＭＭが出された日付よりも後でない場合、ＲＣＭＭは拒否される。
【０１０９】
新しく受信されたＲＣＭＭの日付１３４が前のＲＣＭＭの受信の日付よりも後である場合、予め受信されたＲＣＭＭによって通知されるように、新しく受信されたＲＣＭＭが含むべきであるシグネチャ値の数１３６は、ステップ２０２で新しく受信されたＲＣＭＭで実際に含まれたシグネチャ値の数と比較される。新しく受信されたＲＣＭＭに含まれたシグネチャの数が予想よりも低い場合、ＲＣＭＭが拒否される。これは、ＲＣＭＭが危険にさらされていない私用鍵／公開鍵対に関連したシグネチャを取り除くハッカーの結果として特に処理されることを防止する。
【０１１０】
新しく受信されたＲＣＭＭに含まれたシグネチャの数が予想されたシグネチャの数に等しいかあるいはそれよりも大きい場合、ステップ２０４で、ＲＣＭＭに含まれた各々のシグネチャ値１４６は、このシグネチャ値と同じシグネチャフィールド１４２に含まれる識別子１４４によって識別された公開鍵を使用して検証される。ステップ２０６では、デコーダは、公開鍵を使用して計算された値の少なくとも１つが異なる公開鍵を使用して計算された他の値のいずれかと異なるかどうかを決定する。少なくとも１つの計算された値が他の計算された値の少なくとも１つと異なる場合、ＲＣＭＭは拒否される。
【０１１１】
ＲＣＭＭの一貫性がステップ２０６で証明される場合、ＲＣＭＭは、ステップ２０８で処理され、デコーダの固定メモリに取り消されたルート認証の連続番号のリスト１４０を記憶するので、これらの認証は、ステップ２１２で、デコーダのメモリから削除され、フィールド１３８に含まれたルート認証あるいは各ルート認証をデコーダの固定メモリに記憶し、ステップ２１２でＲＣＭＭの日付１３４を固定メモリに記憶してもよい。ルート認証局の認証が削除される場合、この局によって出される任意のＣＲＬも削除される。
【０１１２】
ＲＣＭＭに含まれたデータの固定メモリの一貫性が、デコーダがＲＣＭＭメッセージの処理中スイッチオフされる場合、保持されることが好ましい。したがって、電力が実際にＲＣＭＭ処理中スイッチオフされる場合、デコーダに記憶される予め処理されたＲＣＭＭに関連したリスト１４０は、あたかも新しく受信されたＲＣＭＭメッセージが全然処理されなかったかのように保持される。
【０１１３】
前述されるように、ルート認証局（ＲＣＡ）は、一般的には各デコーダに記憶された少なくとも２つのＲＣＡ認証、すなわちＲＣ０およびＲＣ１を有する。これらの認証の１つ、例えばＲＣ０が危険にさらされるようになる場合、ＲＣ０に記憶された公開鍵の等価私用鍵を使用して署名されたデコーダに記憶された全ＣＡ認証を交換し、新しいＲＣＡ認証ＲＣ２を生成し、ＲＣ０を交換する必要がある。
【０１１４】
図１２を参照すると、これらのＣＡ認証を交換するために、最初にステップ３００では取り消されるＣＡ認証の連続番号を識別する適切なＣＲＬメッセージがＲＣＡによって出される。第二に、ステップ３０２では、危険にさらされていない認証ＲＣ１の私用鍵を使用して署名され交換ＣＡ認証は、デコーダに放送するために放送会社に出される。
【０１１５】
次に、交換ＣＡ認証は、危険にさらされたＲＣＡ認証ＲＣ０を削除し、この認証を新しいＲＣＡ認証ＲＣ２と交換するままである。ステップ３０４では、ＲＣＡは、新しい公開鍵／私用鍵対を生成し、認証ＲＣ２に新しい公開鍵を挿入し、新しい私用鍵を使用して認証を署名する。
【０１１６】
ステップ３０６では、ＲＣＡは、フィールド１３８では、認証ＲＣ２およびリスト１４０ではＲＣ０の連続番号を含むＲＣＭＭを生成する。このＲＣＭＭは、ステップ３０８では、デコーダに伝送するために放送会社に配信され、危険にさらされた認証ＲＣ０を削除し、これを新しい認証ＲＣ２と交換する。
【０１１７】
ＲＣＡ認証ＲＣ１およびＲＣ２は、その後新しいデコーダのメモリにハードコーディングするためにデコーダ製造者に供給される。
本発明は例として単に前述され、詳細の修正は本発明の範囲内に行うことができることが分かる。
【０１１８】
例えば、ＲＣＭＭは、新しいＲＣＡ認証１１０に加えて、新しいＣＡ認証１００および／または新しい放送会社認証９０を含んでもよく、リスト１４０は、ＣＡ認証および／または取り消されるべきである放送会社認証の識別子を含んでもよい。これは、ＲＣＡによる別個のＣＲＬメッセージの生成が不要にされることを可能にすることができる。
説明で開示された各々の特徴、および（適切である場合）特許請求の範囲および図面は、独立してあるいは任意の適切な組み合わせで提供されてもよい。
【符号の説明】
【０１１９】
１ デジタルテレビシステム
２ 従来のデジタルテレビシステム
３ 圧縮器
４ スクランブラ、マルチプレクサ
５ リンク装置
６ 送信機
７ リンク結合装置
８ アップリンク
９ 衛星トランスポンダ
１０ ダウンリンク
１２ 受信機
１３ 統合受信機／デコーダ
１４ テレビ受像機
１５ 条件付アクセスシステム
１６ 対話システム
１７ モデム逆方向チャネル
【技術分野】
【０００１】
本発明は、デジタル伝送システムで伝送されるデータの認証の方法並びにその形成装置に関するものである。
【背景技術】
【０００２】
デジタルデータの同報伝送は、スクランブルオーディオビジュアル情報が、通常衛星あるいは衛星／ケーブルリンクによって各々がその後見るための伝送番組を暗号解読できるデコーダを所有する多数の加入者に送信されるペイＴＶシステムの分野で周知である。地上デジタル放送システムも公知である。最近のシステムは、視聴覚データに加えてあるいは視聴覚データと同様に、デコーダあるいは接続ＰＣのためのコンピュータプログラムあるいは対話型アプリケーションのような他のデータを伝送する放送リンクも使用した。
【０００３】
アプリケーションの伝送に関する特定の問題は、いかなるこのようなデータの一貫性および発生源も検証する必要性にある。この種のデータは、いかなる対話型アプリケーション数も実行するのと同様にデコーダを再構成するために使用されてもよいので、受信データは完全であり、かつ公知の発生源から発生するものとして識別されることの両方であることが重要である。特に、不完全なデータのダウンロードに関係付けられる操作上の問題が、デコーダが第三者等による攻撃を受けやすいようになる危険と同様に生じ得る。
【０００４】
このようなデータの一貫性を検証することは、デコーダによって直接受信されたデータのパケットストリームの検証によって行われてもよい。伝送より前に、パケットは、一般的にはハッシングアルゴリズムをパケットのデータの少なくともいくつかに用いることによって署名される。生じるハッシュ値はパケットに記憶される。データパケットの受信の際に、デコーダは、同じハッシングアルゴリズムをデータに用い、受信データの一貫性を検証するためにデコーダによって計算されたハッシュ値を受信パケットに記憶されたハッシュ値と比較する。例えば、伝送の故障あるいは遮断の場合、計算ハッシュ値は、受信ハッシュ値と同じでない。次に、デコーダは、ダウンロードデータパケットの可能なエラーの存在のために変更され、間違ったデータパケットを再ロードする。
【０００５】
メッセージダイジェストアルゴリズムＭＤ５のような周知のハッシングアルゴリズムの使用に関連した問題は、ハッシュ値の計算が公に公知の一連の計算ステップに従って実行されるということであり、その結果、誰でもデータパケットのハッシュ値を計算できる。したがって、デコーダによって受信されたデータパケットの発生源を検証できる。受信データがデコーダの演算データファイルを修正する場合、このことは特に重要であり得る。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
この問題を解決するために、データの少なくともいくつかに対するハッシュ値を計算するハッシングアルゴリズムを使用する代わりに、データパケットのシグネチャ値は、放送者にだけ公知である秘密鍵値を使用して計算されてもよい。この鍵は、データ暗号化規格、すなわちＤＥＳのアルゴリズムのような対称性鍵アルゴリズムを等価鍵を記憶するデコーダとともに使用して得ることができる。しかしながら、より便利なことは、公開鍵および私用鍵が数式の補数部を形成する、リベスト（Ｒｉｖｅｓｔ）、シャミール（Ｓｈａｍｉｒ）およびアデルマン（Ａｄｌｅｍａｎ）、あるいはＲＳＡのアルゴリズムのような非対称性公開／私用鍵アルゴリズムを使用することによってもたらすことができることである。
【０００７】
データパケットを生成する責任のある放送者は、私用鍵を記憶し、私用鍵を使用してシグネチャ値を計算する。この公開鍵は、製造中公開鍵をデコーダメモリへハードコーディングすることによってデータを受信すべきであるデコーダに記憶される。データパケットの受信の際に、デコーダは、受信データを公開鍵アルゴリズムを受信シグネチャ値に用いる結果と比較することによって記憶された公開鍵を使用してシグネチャ値を検証する。
【０００８】
このような安全システムにおいてさえ、私用鍵の値は、例えば不法に公然と配信することによって危険にさらされ得る。このような場合、放送者は、データパケットの無許可受信を防止するために等しい公開鍵の使用を迅速に取り消すことが必要になる。さらに、新しい公開／私用鍵対が使用されることも必要になる。したがって、放送会社は、合法ユーザのデコーダに記憶された公開鍵を新しい公開鍵と交換する必要がある。公開鍵の感度に応じて、このことは、放送者がこれらのデコーダのメモリへの新しい公開鍵のハードコーディングするために製造者へのこれらのデコーダの高価で、煩わしい返却を計画することを必要とし得る。
【課題を解決するための手段】
【０００９】
本発明の目的は、これらの問題および他の問題を解決しようとするものである。
本発明の第１の態様は、デジタル伝送システムで伝送されるデータを認証する方法を提供し、前記方法は、伝送より前に、データの少なくともいくつかに対する少なくとも２つの暗号化値を決定するステップであって、各暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して同じデータに対して決定されることと、前記少なくとも２つの暗号化値を前記データとともに出力するステップとを含む。
【００１０】
本発明は、データが「出されるように」受信されることを保証するために新しい暗号化アルゴリズムで使用される鍵のような影響されやすいデータを安全に更新することが望ましい状態に特に応用できるが、これに限定されない。このようなセキュリティを行うために、データの少なくともいくつか、好ましくは多数、より好ましくは全てに対する少なくとも２つの暗号化値が決定される。各々の暗号化値は、それぞれの暗号化アルゴリズムの鍵を使用して決定される。鍵の１つが危険にさらされるようになった場合、「ハッカー」は、データを遮断し、データおよび危険にさらされた鍵を使用して計算された暗号化値の内容を変更でき得る。暗号化値を計算するために使用される鍵と等しい鍵を使用する暗号化値の検証の際に、データが破損されるようになったことを示す、等価鍵を使用する２つの値は同じでない。
【００１１】
データおよび暗号化値は、好ましくは受信機／デコーダに伝送するために出力される。好ましくは、前記データおよび前記暗号化値は、受信機／デコーダによって受信され、この受信機／デコーダで、各暗号化値は、前記それぞれの暗号化アルゴリズムの鍵を使用して処理され、各々のその後に生じる値は、データの前記少なくともいくつかと比較され、データの前記少なくともいくつかを認証する。このデータが破損されるようになった場合、受信機／デコーダは、データを無視するように選択できるので、危険にさらされるかあるいは破損された新しい鍵は、デコーダのメモリに記憶されない。好ましくは、その後に生じる値の少なくとも１つがデータの前記少なくともいくつかとは異なる場合、前記受信データは、受信機／デコーダによって拒否される。
【図面の簡単な説明】
【００１２】
【図１】図１は本発明と併用するためのデジタルテレビシステムの概略図を示す。
【図２】図２は図１のシステムのデコーダの構成を示す。
【図３】図３はＭＰＥＧ放送トランスポートシステム内の多数の構成要素の構成を示す。
【図４】図４は多数のＭＰＥＧテーブルへのソフトウェアアプリケーションの分割を示す。
【図５】図５はＤＥＳ−ＣＣデータファイルと最終的に発生されたＭＰＥＧテーブルとの関係を示す。
【図６】図６はＤＥＳ−ＣＣの前後関係で規定されるようなクライアント、サーバ、ネットワークマネージャ関係を示す。
【図７】図７は認証ディレクトリ、サブディレクトリおよびファイルオブジェクトを示す。
【図８】図８は放送認証、認証局認証およびルート認証局認証のフォーマットを示す。
【図９】図９は認証取消リストのフォーマットを示す。
【図１０】図１０はルート認証管理メッセージ（ＲＣＭＭ）のフォーマットを示す。
【図１１】図１１はデコーダによる受信の際にＲＣＭＭの処理に含まれるステップを示す。
【図１２】図１２は本発明の動作を説明するフローチャートである。
【発明を実施するための形態】
【００１３】
したがって、本発明は、デジタル伝送システムで伝送されるデータを認証する方法に及び、前記方法は、前記データおよびデータの少なくともいくつかに対して決定された少なくとも２つの暗号化値を受信するステップであって、各々の暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して決定されることと、複数の鍵を記憶するステップと、それぞれの暗号化アルゴリズムの記憶された鍵を使用して各々の暗号化値を処理するステップと、各々のその後に生じる値をデータの前記少なくともいくつかと比較し、データの前記少なくともいくつかを認証するステップとを含む。
【００１４】
好ましくは、各アルゴリズムは非対称である。好ましい実施形態では各々の暗号化値は暗号化アルゴリズムの私用鍵で計算されたデジタルシグネチャにそれぞれ対応し、各シグネチャは前記暗号化アルゴリズムの公開鍵を使用し処理しうる。
【００１５】
好ましくは、この方法は、各々のシグネチャとともに、このシグネチャを処理するために使用される公開鍵の識別子を出力するステップを含む。これによって、受信機／デコーダは、このシグネチャを検証するために使用される鍵を容易に識別することを可能にできる。
【００１６】
好ましくは、このデータは鍵を含む。好ましい実施形態では、データは、データを処理するための暗号化アルゴリズムの公開鍵を含む少なくとも１つのデジタル認証、好ましくは少なくとも１つのデジタルルート認証を含む。この少なくとも１つのデジタル認証は、この認証に含まれる公開鍵の暗号化アルゴリズムの私用鍵を使用して計算されたデジタルシグネチャを含んでもよい。したがって、デジタル認証は、デコーダのメモリの新しい認証のハードコーディングのために製造者に戻されねばならないデコーダなしにデコーダに安全に伝送できる。
【００１７】
好ましくは、前記データは、取り消された公開鍵の識別子を含む。この識別子は、前記取り消された公開鍵を含む、デジタル認証、好ましくはデジタルルート認証の識別子を含んでもよい。このデータは、複数の前記識別子を含んでもよく、各々の識別子は、それぞれの取り消された公開鍵を識別する。したがって、取り消された鍵の識別子のリストは、デコーダに安全に伝送できる。
【００１８】
前記の方法によって、危険にさらされた鍵の数がデータとともに記憶される暗号化値の数よりも小さいとすれば、データは安全に更新できる。したがって、前記データおよび前記少なくとも２つの暗号化値は、その後に生成されたデータファイルに記憶される暗号化値の最小数の指示を含んでもよいデータファイルに構成されてもよい。鍵が危険にさらされたようになるべきであるので、暗号化値の最小数が危険にさらされた鍵の数よりも大きいままである場合、これによって、暗号化値の最小数は、変更でき、例えば増加できる。
【００１９】
好ましくは、前記データファイルに記憶された暗号化値の数を前記最小数と比較し、前記データファイルに記憶された暗号化値の数が前記最小数よりも小さい場合、前記データファイルを拒否する受信機／デコーダによって受信される。
【００２０】
このデータファイルはデータモジュールに伝送されてもよい。前記モジュールのデータの少なくともいくつかに対するモジュール暗号化値は、送信機暗号化アルゴリズムの鍵を使用して計算し、前記データモジュールに記憶できる。このデータモジュールは、送信機暗号化アルゴリズムの鍵を使用して前記モジュール暗号化値を処理し、その後に生じる値を前記モジュールのデータの前記少なくともいくつかと比較し、前記モジュールのデータの前記少なくともいくつかを認証する受信機／デコーダによって受信されてもよい。
【００２１】
前記モジュールのデータの少なくともいくつかに対する暗号化値は、送信機暗号化アルゴリズムの私用鍵を使用して計算され、前記送信機暗号化アルゴリズムの公開鍵を使用して処理可能であるデジタルシグネチャに対応し得る。
【００２２】
デジタル伝送システムは、テレビあるいはオーディオシステムのようなデジタル放送システムであってもよい。
本発明は、デジタル伝送システムで伝送されるデータを認証する装置も提供し、前記装置は、データの少なくともいくつかに対する少なくとも２つの暗号化値を決定する手段であって、各々の暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して同じデータに決定されることと、前記データとともに前記少なくとも２つの暗号化値を出力する手段とを備えている。
【００２３】
本発明は、デジタル伝送システムで伝送されるデータを認証するシステムも提供し、前記システムは前述されるような装置を含む。このシステムは、好ましくは、前記データおよび前記暗号化値を受信する手段と、前記それぞれの暗号化アルゴリズムの鍵を使用して各々の暗号化値を処理する手段と、各々のその後に生じる値をデータの前記少なくともいくつかと比較し、データの前記少なくともいくつかを認証する手段とを含む受信機／デコーダをさらに含む。
【００２４】
本発明は、データおよびデータの少なくともいくつかに対して決定される少なくとも２つの暗号化値を含むデータファイルを受信する手段であって、各々の暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して決定されることと、複数の鍵を記憶する手段と、前記それぞれの暗号化アルゴリズムの記憶された鍵を使用して各々の暗号化値を処理する手段と、各々のその後に生じる値をデータの前記少なくともいくつかと比較し、データの前記少なくともいくつかを認証する手段とを含む受信機／デコーダに及ぶ。
【００２５】
本発明は、デジタル伝送システムで伝送されるデータを認証するシステムにも及び、前記システムは、前述されたような装置および前述されたような受信機／デコーダを含む。
【００２６】
本発明は、さらにデータおよびデータの少なくともいくつかに対して決定された少なくとも２つの暗号化値を含む信号に及び、各々の暗号化値は、それぞれの暗号化アルゴリズムの鍵を使用して決定される。
【００２７】
本発明は、さらに実質的に添付図面を参照してここに説明されるようなデータを認証する方法、あるいは装置、受信機／デコーダ、あるいは信号に及ぶ。
ここで使用される用語「受信機／デコーダ」あるいは「デコーダ」は、いくつかの他の手段によって放送されてもよいしあるいは伝送されてもよい、符号化信号あるいは非符号化信号のいずれか、例えばテレビおよび／またはラジオ信号を受信する受信機を意味してもよい。この用語は、受信信号を復号化するデコーダも意味してもよい。このような受信機／デコーダの実施形態は、例えば、物理的に別個の受信機との組み合わせで機能を果たすデコーダ、あるいはウェブブラウザのようなあるいはビデオレコーダあるいはテレビのような他の装置と一体化された付加機能を含むデコーダのような「セットトップボックス」で受信信号を復号化する受信機と一体であるデコーダを含んでもよい。
【００２８】
ここで使用されるように、用語「デジタル伝送システム」は、例えば、主に視聴覚データあるいはマルチメディアデータを伝送あるいは放送するいかなる伝送システムも含む。
【００２９】
本発明は、放送デジタルテレビシステムに特に用いることができるが、本発明は、マルチメディアインターネット用途のための固定電気通信網、閉回路テレビ等にも応用できてもよい。
【００３０】
ここで使用されるように、用語「デジタルテレビシステム」は、例えば、任意の衛星システム、地上システム、ケーブルシステムおよび他のシステムを含む。
本発明で使用し、私用／公開鍵を生成するための適当なアルゴリズムは、ＲＳＡ、フィアット−シャミール、あるいはディフィ−ヘルマンを含んでもよく、適当な対称鍵アルゴリズムは、例えばＤＥＳ形アルゴリズムを含んでもよい。しかしながら、前後関係を考慮して不可欠でない限りあるいは別段の指定がない限り、対称アルゴリズムに関連した鍵と公開／私用アルゴリズムに関連した鍵との間の一般的な区別は全然行われない。
【００３１】
用語「スクランブル」および「暗号化」および「制御ワード」および「鍵」は、用語を明瞭にするためにテキストのいろいろな部分で使用された。しかしながら、「スクランブルデータ」と「暗号化データ」、「制御ワード」と「鍵」との基本的区別は、全然行われるべきでないことが分かる。
【００３２】
さらに、用語「暗号化」および「署名」や「暗号解読」および「検証」は、用語を明瞭にするためにテキストのいろいろな部分で使用された。しかしながら、「暗号化データ」と「署名データ」および「暗号解読データ」および「検証データ」との基本的区別は、全然行われるべきでないことが分かる。
【００３３】
同様に、用語「等価鍵」は、第１の記載された鍵によって暗号化されたデータを暗号解読、あるいはその逆をするために構成された鍵を示すために使用される。
本発明の方法態様に関連する前述の機能は、装置態様にも応用でき、あるいはその逆でも用いることができる。
【００３４】
次に、添付図面を参照して本発明の好ましい実施形態だけが例として説明される。
本発明によるデジタルテレビシステム１の概略１は、図１に示される。本発明は、圧縮デジタル信号を伝送するために公知のＭＰＥＧ−２圧縮システムを使用する多くの従来のデジタルテレビシステム２を含む。より詳細には、放送局のＭＰＥＧ−２圧縮器３は、デジタル信号ストリーム（一般的には、ビデオ信号のストリーム）を受信する。この圧縮器３は、リンク装置５によってマルチプレクサおよびスクランブラ４に接続される。
【００３５】
マルチプレクサ４は、複数の他の入力信号を受信し、トランスポートストリームを組み立て、もちろん通信リンクを含むいろいろの形をとることができるリンク結合装置７を介して圧縮デジタル信号を放送局の送信機６に送信する。送信機６は、アップリンク８を介して電磁信号を電子的に処理される衛星トランスポンダ９の方へ送信し、概念上のダウンリンク１０を介して従来はエンドユーザによって所有されるかあるいは賃貸される皿の形の地上受信機１２に放送する。受信機１２によって受信された信号は、ユーザエンドによって所有されるかあるいは賃貸され、エンドユーザのテレビ受像機１４に接続された統合受信機／デコーダ１３に送信される。この受信機／デコーダ１３は、圧縮ＭＰＥＧ−２信号をテレビ受像機１４のためのテレビ信号に復号化する。
【００３６】
地上放送、ケーブル伝送、結合衛星／ケーブルリンク、電話網等のようなデータの伝送のための他のトランスポートチャネルは、もちろん可能である。
マルチチャネルシステムでは、マルチプレクサ４は、多数の並列発生源から受信されたオーディオおよびビデオ情報を処理し、送信機６と対話し、対応するチャネル数に沿って情報を放送する。オーディオビジュアル情報に加えて、デジタルデータのメッセージあるいはアプリケーションもしくは任意の他の種類のデジタルデータは、送信されたデジタルオーディオおよびビデオ情報とインタレースされたこれらのチャネルのいくつかあるいは全部に導入される。このような場合、例えば、ＤＳＭ−ＣＣ（デジタル記憶メディアコマンドおよびコントロール）フォーマットソフトウェアファイルおよびメッセージの形のデジタルデータのストリームは、圧縮器３によってＭＰＥＧフォーマットに圧縮され、パケット化される。ソフトウェアモジュールのダウンロードは、下記により詳細に説明される。
【００３７】
条件付アクセスシステム１５は、マルチプレクサ４および受信機／デコーダ１３に接続され、一部が放送局にあり、一部がデコーダにある。このシステムによって、エンドユーザは、１つあるいはそれ以上の放送供給者からデジタルテレビ放送にアクセスできる。市販の売り物（すなわち、放送供給者によって宣伝された１つあるいはいくつかのテレビ番組）に関するメッセージを解読できるスマートカードは、受信機／デコーダ１３に挿入できる。デコーダ１３およびスマートカードを使用すると、エンドユーザは、加入モードあるいはペイ・パー・ビューモードのいずれかで市販の売り物を購入できる。実際には、デコーダは、例えば同時暗号あるいは複数暗号設計の多重アクセス制御システムを処理するように構成されてもよい。
【００３８】
前述されたように、システムによって放送された番組は、マルチプレクサ４でスクランブルされ、所与の伝送に加えられる条件および暗号化鍵は、アクセス制御システム１５によって決定される。このようにスクランブルされたデータの伝送は、ペイＴＶシステムの分野で周知である。一般的には、スクランブルデータは、データを暗号解読する制御ワードとともに伝送され、制御ワードそのものは、いわゆる利用鍵によって暗号化され、暗号化形式で伝送される。
【００３９】
スクランブルデータおよび暗号化制御ワードは、次にデコーダに挿入されたスマートカードに記憶された利用鍵の均等物へのアクセス権を有するデコーダ１３によって受信され、暗号化制御ワードを暗号解読し、その後、伝送データを暗号解読する。支払った加入者は、例えば、伝送を見ることができるように暗号化制御ワードを暗号解読するのに必要な利用鍵を放送月ＥＭＭ（資格管理メッセージ）で受信する。視聴覚テレビ番組を暗号解読する際のその使用に加えて、同じ利用鍵が、前述されるようなソフトウェアモジュールのような他のデータの検証で使用するために生成され、送信されてもよい。
【００４０】
マルチプレクサ４および受信機／デコーダ１３にも接続され、さらに一部が放送局にあり、一部がデコーダにある対話システム１６によって、エンドユーザは、モデム逆方向チャネル１７を介していろいろなアプリケーションと対話できる。このモデム逆方向チャネルも、条件付アクセスシステム１５で使用される通信のために使用されてもよい。対話システムは、例えば、視聴者は、直ちに放送局と通信し、特定の試合を見て、アプリケーション等をダウンロードするための許可を要求することができる。
【００４１】
（受信機／デコーダの物理的要素）
図２を参照すると、本発明で使用されるように構成される受信機／デコーダ１３あるいはセットトップボックスの物理的要素は、次に簡単に説明される。この図に示された要素は、機能ブロックによって説明される。
【００４２】
デコーダ１３は、関連メモリ要素を含み、かつ直列インタフェース２１、並列インタフェース２２、および（図１のモデム逆方向チャネル１７に接続される）モデムから入力データを受信するように構成される中央プロセッサ２０を含む。
【００４３】
デコーダは、さらに制御装置２６を介して赤外線遠隔制御装置２５からおよびデコーダの正面パネル上のスイッチコンタクト２４から入力を受信するように構成される。このデコーダは、銀行スマートカードおよび加入スマートカード２９、３０のそれぞれを読み取るように構成される２つのスマートカード読み取り器２７、２８も持つ。入力も、赤外線キーボード（図示せず）を介して受信されてもよい。加入スマートカード読み取り器２８は、挿入加入カード３０および条件付アクセス装置２９と係合し、必要な制御ワードを多重分離装置／暗号解読器３０に供給し、暗号化放送信号は暗号解読できる。デコーダは、装置３０によってフィルタリングされ、多重分離される前に衛星伝送を受信し、復調する従来のチューナ３１および復調器３２も含む。
【００４４】
デコーダ内のデータの処理は、通常、中央プロセッサ２０によって処理される。中央プロセッサのソフトウェアアーキテクチャは、デコーダのハードウェア構成要素で実行される下部レベルオペレーティングシステムと対話する仮想機械に対応する。
【００４５】
（伝送データのパケット構造）
次に、図３および４を参照して、送信機からデコーダに送信される放送ＭＰＥＧトランスポートストリーム内のデータのパケット構造が説明される。理解されるように、この説明はＭＰＥＧ規格で使用される作表フォーマットに集中するが、同じ原理は、同様に他のパケット化データストリームフォーマットに用いる。
【００４６】
特に、図３を参照すると、ＭＰＥＧビットストリームは、０のパケット識別（ＰＩＤ）を有する番組アクセステーブル（ＰＡＴ）４０を含む。ＰＡＴは、多数の番組の番組マップテーブル（ＰＭＴ）４１のＰＩＤの関連を含む。各ＰＭＴは、この番組のためのオーディオＭＰＥＧテーブル４２およびビデオＭＰＥＧテーブル４３のストリームのＰＰＩＤの関連を含む。ゼロのＰＩＤを有するパケット、すなわち、番組アクセステーブル４０は、全ＭＰＥＧアクセスのためのエントリポイントを与える。
【００４７】
アプリケーションおよびそのためのデータをダウンロードするために、２つの新しいストリーム形式が規定され、関連するＰＭＴは、アプリケーションＭＰＥＧテーブル４４（あるいはこれらの一部）およびデータＭＰＥＧテーブル４５（あるいはこれらの一部）のストリームのＰＩＤの関連も含む。実際は、実行可能なアプリケーションソフトウェアおよびこのようなソフトウェアによって処理するためのデータのための別個のストリーム形式を規定することはいくつのかの場合便利であり得るが、これは重要でない。他の実現では、データおよび実行可能なコードは、記載されるようなＰＭＴを介してアクセスされる単一ストリームに組み立てできる。
【００４８】
図４を参照すると、例えばストリーム４４内のアプリケーションをダウンロードするために、アプリケーション４６は、各々がＭＰＥＧテーブルによって形成されるモジュール４７に分割される。これらのテーブルのいくつかは単一部分を含むが、他のものは複数の部分４８によって構成されてもよい。典型的なセクション４８は、１バイトのテーブルＩＤ（「ＴＩＤ」）５０、テーブルのこのセクションのセクション番号５１、このテーブルの全セクション数５２および２バイトのＴＩＤ拡張関連５３を含むヘッダを有する。各セクションは、データ部５４およびＣＲＣ５５も有する。特定のテーブル４７の場合、このテーブル４７を構成するセクション４８の全ては、同じＴＩＤ５０および同じＴＩＤ拡張部５３を有する。特定のアプリケーション４６の場合、このアプリケーション４６を構成するテーブルの全ては、同じＴＩＤ５０であるが、異なるそれぞれのＴＩＤ拡張部を有する。
【００４９】
各々のアプリケーション４６の場合、単一ＭＰＥＧテーブルは、ディレクトリテーブル５６として使用される。このディレクトリテーブル５６は、そのヘッダにおいて、アプリケーションを構成する他のテーブル４７と同じＴＩＤを有する。しかしながら、ディレクトリテーブルは、ＩＤ目的のためにゼロの所定のＴＩＤ拡張部を有し、この事実のために単一テーブルだけはディレクトリの情報に対して必要である。他のテーブル４７の全ては、通常非ゼロＴＩＤ拡張部を有し、多数の関連セクション４８で構成される。ディレクトリテーブルのヘッダは、ダウンロードされるアプリケーションのバージョン番号も含む。
【００５０】
戻って図３を参照すると、ＰＡＴ４０、ＰＭＴ４１、およびアプリケーション・データストリーム成分４４、４５は、周期的に伝送される。伝送される各アプリケーションは、それぞれの所定のＴＩＤを有する。アプリケーションをダウンロードするために、適切なＴＩＤおよびゼロのＴＩＤ拡張部を有するＭＰＥＧテーブルは、受信機／デコーダにダウンロードされる。これは、必要とされるアプリケーションのためのディレクトリテーブルである。このディレクトリのデータは、次にデコーダによって処理され、必要とされるアプリケーションを構成するテーブルのＴＩＤ拡張部を決定する。その後、ディレクトリテーブルと同じＴＩＤおよびディレクトリから決定されるＴＩＤ拡張部を有するいかなる必要とされるテーブルもダウンロードできる。
【００５１】
このデコーダは、そのいかなる更新のためのディレクトリテーブルも検査するように構成される。これは、例えば、３０秒あるいは１分あるいは５分毎に周期的に再度ディレクトリをダウンロードし、予めダウンロードされるディレクトリテーブルのバージョン番号を比較することによって行われてもよい。新しくダウンロードされたバージョン番号が後のバージョン番号である場合、前のディレクトリテーブルに関連したテーブルは削除され、新しいバージョンに関連したテーブルは、ダウンロードされ、集められる。
【００５２】
代替の装置では、入ってくるビットストリームは、アプリケーションのＴＩＤ、ゼロのＴＩＤ拡張部および目下ダウンロードされたディレクトリのバージョン番号よりも１つ大きいバージョン番号のためにセットされる値とともにＴＩＤ、ＴＩＤ拡張部およびバージョン番号に対応するマスクを使用してフィルタリングされる。したがって、バージョン番号の増加が検出され、一旦検出されると、前述されるように、ディレクトリはダウンロードされ、アプリケーションは更新される。アプリケーションが終了されるべきである場合、次のバージョン番号を有する空のディレクトリは、ディレクトリに列挙された少しのモジュールもないことを除いて伝送される。このような空のディレクトリの受信に応じて、デコーダ２０２０は、アプリケーションを削除するようにプログラムされる。
【００５３】
実際には、デコーダでアプリケーションを実行するソフトウェアおよびコンピュータプログラムは、特に前述されるような衛星リンクを介して受信されるデータストリームに、デコーダの一部のいずれかを介してであるが、直列ポート、スマートカードリンク等も介して導入されてもよい。このようなソフトウェアは、ネットブラウザ、クイズアプリケーション、番組案内等のようなデコーダ内の対話型アプリケーションを実行するために使用される高レベルアプリケーションを含んでもよい。ソフトウェアも、例えば「パッチ」等によってデコーダソフトウェアの作動構成を変えるようにダウンロードされてもよい。
【００５４】
アプリケーションも、デコーダを介してダウンロードされ、デコーダに接続されたＰＣ等に送信されてもよい。このような場合、デコーダは、最終的には接続装置で実行されるソフトウェアのための通信ルータの役目を果たす。このルーティング機能に加えて、デコーダも、ＰＣに経路指定する前にＭＰＥＧパケット化データを例えばＤＳＭ−ＣＣプロトコル（下記を参照）に従って構成されたコンピュータファイルソフトウェアに変換する機能を果たしてもよい。
【００５５】
（データファイルのデータの構成）
図５は、ＤＳＭ−ＣＣ Ｕ−Ｕ（ユーザ対ユーザ）データファイル６０のセット、集められたアプリケーション４６に構成され、一連のＭＰＥＧテーブル４７内にカプセル化されるようなデータ間の関係を示す。この関係は国際特許出願番号第９９／４９６１４に記載されており、その内容は下記に参照される。
【００５６】
伝送より前に、データファイルは、アプリケーション４６に集められ、その後、ＭＰＥＧ圧縮器によって、前述されるようにＭＰＥＧパケットストリームに固有なヘッダ４９を含み、かつテーブルＩＤ、バージョン番号等を含むＭＰＥＧテーブルあるいはモジュール４７にパケット化される。理解されるように、データファイル６１に構成されるデータと最終的なＭＰＥＧテーブル４７との間に一定の関係が全然ない。デコーダによる受信およびフィルタリング後、パケットヘッダ４９は、廃棄され、アプリケーション４６は、テーブル４７のペイロードから再構成される。
【００５７】
データファイルのためのＤＳＭ−ＣＣフォーマットは、特にマルチメディアネットワークで使用するために適合され、図６に示されるように、クライアントユーザ７０、サーバユーザ７１とネットワーク資源マネージャ７２との間の通信のための一連のメッセージフォーマットおよびセッションコマンドを規定する規格である。ネットワーク資源マネージャ７２は、ネットワーク内の資源の属性を管理するように作動する論理エンティティとみなされてもよい。
【００５８】
クライアントとサーバとの間の通信は、一連のセッションによって作動可能な状態にされ、第１の一連のメッセージは、通信のためのクライアントおよび／またはサーバを構成するためにユーザ（クライアント７０あるいはサーバ７１）とネットワークマネージャ７２との間で交換される。このようなメッセージは、いわゆるＤＳＭ−ＣＣ Ｕ−Ｎ（ユーザ対ネットワーク）に従ってフォーマット化される。このプロトコルのサブセットは、特にデータを放送ダウンロードするために規定された。
【００５９】
一旦通信リンクが確立されると、メッセージは、ＤＳＭ−ＣＣ Ｕ−Ｕプロトコルに従ってクライアント７０とサーバ７１との間でその後交換される。この種の一連のメッセージは、図５のデータファイル６０に対応する。ＤＳＭ−ＣＣ Ｕ−Ｕメッセージの場合、データは、ＢＩＯＰ（Ｂｒｏａｄｃａｓｔ ＩｎｔｅｒＯｒｂ Ｐｒｏｔｏｃｏｌ）従ってグループ化される。
【００６０】
各メッセージあるいはオブジェクト６１は、ヘッダ６２と、サブヘッダ６３と、データそのものを含むペイロード６４とを含む。ＢＩＯＰプロトコルに従って、ヘッダ６２は、とりわけ、メッセージおよびＢＩＯＰバージョンの形式の指示を含むが、サブヘッダは、システム設計者によって規定されるオブジェクトおよび他の情報の形式を示す。
【００６１】
ＤＳＭ−ＣＣ Ｕ−Ｕファイルのペイロード内のデータオブジェクト６４は、通常３つの形式、すなわちディレクトリオブジェクト、ファイルオブジェクトおよびストリームオブジェクト、の中の１つとして規定できる。ディレクトリオブジェクトは、実際のアプリケーションデータを含む一連の関連ファイルオブジェクトを関連付けるために使用されるルートディレクトリあるいはサブディレクトリを規定する。
【００６２】
ストリームオブジェクトは、一時の関係がデータファイルに含まれるデータとＭＰＥＧパケットストリームそのものとの間に確立できるために使用されてもよい。これは、例えば、データファイルに含まれ、かつデコーダによって受信され、処理される基本ビデオあるいはオーディオストリームと同期されるように設計される対話形アプリケーションの場合、使用されてもよい。前述されるように、特にＭＰＥＧパケット化データとデータファイルとの間に全然直接の相関が有り得ない。
【００６３】
ＭＰＥＧテーブルと違って、単一ディレクトリがテーブルのセットを単一レベルの階層のみと関連付ける場合、データファイル６０は、かなりより複雑な階層のように構成されてもよい。ＰＣあるいはサーバに記憶されるファイルのように、主ディレクトリあるいはルートディレクトリは、順に第２のレベルのデータファイルを参照する１つあるいはそれ以上のサブディレクトリを参照してもよい。（データファイルのセットのためのファイル構造）
【００６４】
図７を参照すると、データファイルのセットのためのファイル構造の例が示されている。７５に示されるルートディレクトリＤＩＲＡ０は、サブディレクトリＡ１のグループをオブジェクトファイル７７に関連付ける。明瞭にするために、サブディレクトリＡ４と関連するオブジェクトファイルＦ１、Ｆ２等の単一グループだけが示されている。実際には、多数のオブジェクトファイルのグループは、サブディレクトリＡ１からＡ４の各々によって関連付けられてもよい。
【００６５】
各々のディレクトリおよびサブディレクトリ内で、認証ステップのセットは、このディレクトリに結合されるファイルのために導入される。ルートディレクトリ７５を参照すると、サブヘッダ６３は、ハッシュアルゴリズムを７６と示されたサブディレクトリファイルＡ１からＡ４に記憶されたデータのいくつかあるいは全てに用いることによって得られたハッシュ値を含む。使用されるハッシングは、例えば、メッセージダイジェストアルゴリズムＭＤ５のような任意の公知の形式のものであってもよい。
【００６６】
１つの実現では、このアルゴリズムは、各々の関連ファイルあるいはサブディレクトリに個別に適用され、各サブディレクトリ７６のためのハッシュ値のリストは、伝送より前にルートディレクトリ７５に記憶されてもよい。しかしながら、このような解決策は、各々のサブディレクトリを検証することに関する分解能をチェックする度合いの増加を可能にするが、この解決策は、対応するシグネチャを計算するためにデコーダのために必要である処理時間に関してかなり役に立たないことが有り得る。したがって、ディレクトリ７９のサブヘッダ６３は、好ましくは、ＭＤ５ハッシングアルゴリズムを結合されたサブヘッダおよびサブディレクトリ７６のペイロード部６３、６４に用いることによって計算され、すなわちヘッダ６２がない累積ハッシュ値７９を含む。特に、サブディレクトリ７６内に含まれ、ファイルオブジェクト７７の層を示すハッシュ値８２は、このハッシング計算に含まれる。
【００６７】
図７に示されたサブディレクトリＡ４の場合、このサブディレクトリそれ自体は、７７に示されるオブジェクトＦ１〜Ｆｎのセットを示す。この場合、累積ハッシュ値８２は、オブジェクトファイル７７の結合内容のために生成される。この値は、ハッシュ値７９を生じるハッシング処理に含まれる。したがって、順にディレクトリ７５のハッシュ値７９を変えるサブディレクトリ７６のハッシュ値８２を変えないでオブジェクトファイル７７のいずれかを変えることができない。
【００６８】
この場合、結合されたハッシュ値は、ディレクトリに示されたサブディレクトリの全てに対して計算される。このハッシュ値は、そこからデータがとられるサブディレクトリのグループの識別子とともに記憶される。他の実施形態では、一連の結合されるかあるいは個別のハッシュ値および対応する識別子は、ディレクトリのサブヘッダに記憶されてもよい。
【００６９】
例えば、ルートディレクトリとも関連するが、異なるデータのセットあるいは実行可能なコードに関する第２のサブディレクトリのセットも、一緒にグループ化され、累積ハッシュ値は、計算され、サブヘッダルートディレクトリに記憶されたこれらのサブディレクトリのために計算されてもよい。単一ディレクトリに関連した単一ハッシュ値は、同様にルートディレクトリのサブヘッダに記憶されてもよい。
【００７０】
グループあるいは個別のデータファイルの認証は、もちろん、ルートディレクトリ（あるいは、実際に任意の他のファイル）が無効あるいは未ハッシュのデータファイルも示すことを防止しなくて、このようなファイルの確認がないことは、このファイルとの任意の動作を考慮する必要がある。この点では、例えば、システムオブジェクトを認証することは必要であり得ない。
【００７１】
この場合のハッシング関数の使用によって、主にデコーダは、ダウンロードデータファイルの一貫性あるいはダウンロードデータファイルを完備していることを検証できる。例えば、伝送における故障あるいは遮断の場合、受信された従属ファイルの累積ハッシングアルゴリズムの演算は、ルートディレクトリに記憶されたこれらのファイルに対するハッシュ値と同じ結果を得られる。次に、デコーダは、ダウンロードデータの可能なエラーがあることに変更され、誤ったデータファイルを再ロードする。
【００７２】
（ルートディレクトリのためのシグネチャ値）
高められたセキュリティの場合、ルートディレクトリ７５のためのシグネチャ値が計算される。本実施形態では、リベスト（Ｒｉｖｅｓｔ）、シャミール（Ｓｈａｍｉｒ）およびアデルマン（Ａｄｌｅｍａｎ）あるいはＲＳＡアルゴリズムが使用され、データファイルを生成する責任を負うべき放送会社は、私用鍵値を所有し、公開鍵は、デコーダによって保持される。一方、秘密鍵は、データ暗号規格あるいはＤＥＳアルゴリズムのような対称性鍵アルゴリズムによって得られる鍵に対応し得る。
【００７３】
図７に示されるように、ルートディレクトリ７５は、放送会社の私用鍵を使用して生成される計算されたシグネチャ値８１とともに検証工程で使用される公開鍵をデコーダのために識別する放送会社識別子８０を含む。この場合、シグネチャ値８１は、放送会社によって保持される私用鍵を好ましくはペイロードデータ６４および／または累積ハッシュ値７９を含むディレクトリ７５内のデータのいくつかあるいは全てに用いることによって生成される。次に、このデコーダは、放送会社識別子８０によって識別される対応する公開鍵を使用してこのシグネチャ値８１を検証できる。
【００７４】
本例では、ディレクトリ７５のデータは、暗号化されなくて、この私用鍵は、公開鍵によって検証できるシグネチャ値を生じるために単に使用できる。代替実施形態では、ディレクトリの内容のいくつかあるいは全ては、私用鍵によって暗号化され、その後、対応する鍵によって暗号解読されてもよい。
【００７５】
どちらかの場合でも、秘密鍵の使用による暗号化コードのシグネチャ値あるいはブロックの生成によって、デコーダは、ディレクトリ７５の一貫性および発生源、および密接な関係によってこのルートディレクトリによって参照されるファイルの一貫性および発生源を検証できる。参照ファイルのための累積ハッシュ値は、シグネチャ８１の計算に含まれるので、これが検証工程で検出されない限りこれらの値を変更できない。各ハッシュ値は通常所与のデータのセットに固有であるので、したがってその固有のハッシュ値、それによってディレクトリの生じるシグネチャ値を変えないで従属ハッシュファイルのいずれかの内容を変えることができない。
【００７６】
理解されるように、多数の変更は、特に各工程でハッシュされるかあるいは署名されるデータ量を減らすことを可能にし得る。特に、下部レベルデータファイルを検証するために使用されるディレクトリあるいはサブディレクトリのシグネチャあるいはハッシュ値の場合、ディレクトリシグネチャあるいはハッシュ値は、下部レベルハッシュ値だけを使用し、他のデータだけを使用しないで生成されてもよい。
【００７７】
例えば、Ａ０ディレクトリ７５の結合ハッシュ値７９は、７６に示されるＡ１−Ａ４サブディレクトリの各々の結合ハッシュ値８２、８３を使用して生成されてもよい。これらの値は、丁度サブディレクトリのペイロードのデータと同様に独自であるので、結合ハッシュ値７９は、なお当のサブディレクトリに固有である。さらに、ハッシュ値８２はなお計算で使用されるので、オブジェクトファイルおよびディレクトリファイル７７、７８の下部レベルの一貫性がなお推測される。
【００７８】
（放送会社デジタル認証）
図８を参照すると、公開鍵９１および放送会社識別子８０は、好ましくは、製造中デコーダのメモリにハードコード化される周知の国際標準化機構（ＩＳＯ）Ｘ．５０９の形のデジタル認証でデコーダのユーザに供給される。このような認証は、通常認証局（ＣＡ）と呼ばれる信用された第三者によってデコーダの製造者に配信される。このような認証の使用は、ワールドワイドウェブ（ＷＷＷ）を介するクレジットカードトランザクションを保護するネットスケープ通信によって開発され、標準化された安全ソケットレイヤー（ＳＳＬ）安全トランスポートプロトコルにより主により広く受け入れるようになる。
【００７９】
公開鍵９１および放送会社識別子８０と同様に、放送会社に関連したデジタル認証、すなわち、放送会社認証９０は、以下を含む。
放送会社認証９０のバージョン番号９２；
放送会社認証９０の連続番号９３；
放送会社認証９０を配信したＣＡのＣＡ識別子９４；
認証が使用されることを意図されている時間の開始および終了を示す放送会社認証９０の有効期間９５；
放送会社認証９０のシグネチャ値９６。
【００８０】
前述から分かるように、放送会社認証は、２つの異なる識別子、すなわち認証の分配者のＩＤ９４に対応する第１の「発行者名」識別子および公開鍵９１を識別する識別子８０に対応する第２の「主題名」識別子を含む。
【００８１】
ＣＡは、ＣＡの私用鍵、すなわちＣＡ私用鍵を放送会社認証内のデータの少なくともいくつかあるいは全てに用いることによって放送会社認証９０のシグネチャ値９６を計算する。次に、デコーダは、ＣＡ識別子９４によって識別される対応するＣＡ公開鍵１０１を使用してシグネチャを処理することによってこのシグネチャ値９６を検証し、認証の内容がＣＡによってシグネチャに続いて修正されなかったことを判定する。
デコーダは、異なるそれぞれの放送会社に対する複数のこのような認証を記憶してもよい。
【００８２】
（認証局デジタル認証）
さらに図８を参照すると、対応するＣＡ公開鍵１０１およびＣＡ識別子９４は、製造中デコーダでもハードコード化されるＣＡ認証１００のデコーダのユーザに供給される。ＣＡ認証１００は、以下を含む。
ＣＡ認証１００のバージョン番号１０２；
ＣＡ認証１００の連続番号１０３；
ＣＡ認証１００を配信した欧州電気通信標準化機構（ＥＴＳＩ）のようなルート認証局（ＲＣＡ）のＲＣＡ識別子１０４；
ＣＡ認証１００の妥当性期間１０５；
ＣＡ認証１００のシグネチャ値１０６。
【００８３】
前述から分かるように、ＣＡ認証は、２つの異なる識別子、すなわち認証の分配者の識別子１０４に対応する第１の「発行者名」識別子および公開鍵１０１を識別する識別子９４に対応する第２の「主題名」識別子を含む。
【００８４】
ＲＣＡは、ＲＣＡの私用鍵、すなわちＲＣＡ私用鍵をＣＡ認証内のデータの少なくともいくつかあるいは全てに用いることによってＣＡ認証１００のシグネチャ値１０６を計算する。次に、デコーダは、ＲＣＡ識別子１０４によって識別される対応するＲＣＡ公開鍵１１１を使用して認証を処理することによってこのシグネチャ値９６を検証し、認証の内容がＲＣＡによってシグネチャに続いて修正されなかったことを判定する。
【００８５】
デコーダは、異なるそれぞれのＣＡに対する複数のこのような認証を記憶してもよい。
【００８６】
（ＲＣＡデジタル認証）
対応するＲＣＡ公開鍵１１１およびＲＣＡ識別子１０４は、製造中にデコーダのメモリでもハードコード化され、ＲＣＡ、すなわちルート認証１１０のデコーダのユーザに供給される。各デコーダは、一般的には２つあるいはそれ以上のルート認証（ｒｏｏｔ ｃｅｒｔｉｆｉｃａｔｅ）のセットを含む。各ルート認証１１０は、以下も含む。
ルート認証１１０のバージョン番号１１２；
ルート認証１１０の連続番号１１３；
ルート認証１１０の妥当性期間１１４；
ルート認証１１０のシグネチャ値１１５。
前述から分かるように、ルート認証は、単一の識別子、すなわち認証の配信者の識別子１０４だけを含む。この識別子１０４は公開鍵１１１も含む。したがって、ルート認証は、発行者名が主題名と同じである認証として規定されてもよい。
【００８７】
ルート認証は、放送会社認証９０−ＣＡ認証１００−ルート認証１１０の連鎖の最終認証であるので、ルート認証は、自動署名され、すなわち、シグネチャ値は、公開鍵１１１と等価の私用鍵を使用して計算される。したがって、ルート認証の内容が公に利用できるようにならないことに関心がある。
【００８８】
もちろん、ＲＣＡは、放送会社認証をデコーダの製造者に直接供給することができ、その場合、放送会社認証は、ＲＣＡ識別子１１１を含み、ＲＣＡ私用鍵を使用して署名される。
【００８９】
（認証取り消しリスト）
放送会社認証９０およびＣＡのいずれかは、例えば認証に記憶された公開鍵に対応する私用鍵が危険にさらされるようになる場合、それで指定された妥当性期間の満了より前に例えば削除によって取り消されてもよい。このような取り消しは、取り消される認証の連続番号９２、１０２のリストを含む認証取り消しリスト（ＣＲＬ）のデコーダへの伝送によって行うことができる。取り消しの際に、認証は、好ましくは、デコーダのメモリからの認証の削除によって実行できないようになり、それによって危険にさらされた私用鍵を使用して署名される任意の不許可の可能性のある悪意のあるデータパケットのダウンロードを防止する。
【００９０】
ＣＲＬは、ＣＡあるいはＲＣＡのいずれかによって放送会社に配信される。そして放送会社はＣＲＬをデコーダに伝送するが、モデム逆方向チャネル１７、あるいはＭＰＥＧトランスポートストリームにＣＲＬを含めて放送することのいずれかによってＣＲＬを伝送する。放送会社が、送信機からデコーダに送信されるトランスポートストリームの全てにＣＲＬを挿入することは重要でない。デコーダによって同調される可能性が非常に高いトランスポートストリームに放送会社がＣＲＬを挿入すれば十分である。ＣＲＬは、例えば、データファイルとして送信機からデコーダへ放送されるデータファイルのセットのルートディレクトリ７５あるいはサブディレクトリ７６に挿入されてもよい。
【００９１】
図９を参照すると、ＣＲＬ１２０は、一般的には、以下を含む。
ＣＲＬ１２０を配信したＣＡあるいはＲＣＡの識別子９４あるいは１０４；
ＣＲＬ１２０が発行された日付１２２；
次のＣＲＬの発行が予想される日付１２４；
各々の取り消された認証に対して、この認証の取り消しの時間および日付を含む、取り消された認証の連続番号のリスト１２５；
ＣＲＬ１２０を配信したＣＡあるいはＲＣＡの私用鍵を使用して計算されたＣＲＬのシグネチャ値１２６。
【００９２】
ＣＲＬの受信の際に、デコーダは、そのＣＲＬ１２０が発行された日付１２２を、予め受信したＣＲＬによって通知されたＣＲＬ１２０の発行が予想される日付１２４と比較する。新しく受信されたＣＲＬの日付１２２がＣＲＬの発行が予想される日付１２４よりも後でない場合、新しく受信されたＣＲＬは無視される。
【００９３】
新しく受信されたＣＲＬの日付１２２が、ＣＲＬの発行が予想される日付１２４よりも後である場合、ＣＲＬのシグネチャは、ＣＲＬに含まれる識別子９４あるいは１０４を使用して識別されるように、ＣＡの発行者の公開鍵を使用して検証される。
【００９４】
ＣＲＬの一貫性がそのように検証される場合、ＣＲＬは、次のＣＲＬが出されることが予想される日付１２４を固定メモリに記憶し、取り消された認証の連続番号のリスト１２５を記憶するように日付１２４を加えるために処理される。取り消された認証の受信リスト１２５は、デコーダの固定メモリにも記憶される。性能の理由のために、ＣＲＬ１２０がデコーダのメモリにキャッシュされるのが好ましい。デコーダのキャッシュメモリがＣＲＬ１２０を樹枝状に記憶することも好ましく、ＲＣＡのＣＲＬは、「ツリー」の上部およびこのＲＣＡがツリーの底部にある認証を配信するＣＡのＣＲＬにある。
【００９５】
放送会社認証９０の取り消しの場合、例えば、放送会社の私用鍵が危険にさらされるようになる場合、この放送会社に対する認証局は、放送会社認証９０の連続番号９３をそのＣＲＬ１２０に加える。認証局は、その後、新しいＣＲＬ１２０を放送会社に配信する。その配信先は、放送のために放送会社認証９０を配信するすべての放送会社である。デコーダが新しいＣＲＬ１２０をダウンロードするや否や、例えば、放送会社のチャネルで早送りする際に、ＣＲＬキャッシュは、更新され、ＣＲＬ１２０のリスト１２５でそのように識別されたいかなる認証の取り消しも行われる。
【００９６】
交換される放送会社認証９０は、認証局によって生成され、ファイルのディレクトリ７５あるいは７６のユーザに放送する。交換される放送会社認証は、とりわけ、新しい公開鍵９１と、更新バージョン番号９２と、更新妥当性期間９５と、ＣＡの私用鍵を使用して計算された新しいシグネチャ値９６とを含む。放送会社識別子８０およびＣＡ識別子９４は変更されないままである。交換される放送会社認証９０の受信の際に、デコーダは、ＣＡ識別子９４によって識別されたＣＡ認証に含まれる対応するＣＡ公開鍵を使用して、交換される放送会社認証９０を処理することによって、その認証を検証する。
【００９７】
ＣＡ認証１００の取り消しの際に、このＣＡのＣＲＬは、デコーダのメモリから取り除かれる。したがって、例えば、このＣＡのＣＲＬのサイズがデコーダのキャッシュメモリに記憶するためにあまりに大きくなる場合、ＣＡ認証１００を任意に取り消すことは望ましいことで有り得る。この場合、ＣＡ認証１００をこのＣＡに配信するＲＣＡは、このＣＡ認証１００の連続番号をそのＣＲＬに追加する。ルート認証局は、その後、ＲＣＡがＣＡ認証を配信するＣＡが放送するための放送会社認証を順に配信する放送会社の全てに新しいＣＲＬを配信する。デコーダが新しいＣＲＬをダウンロードするや否や、例えば、放送会社のチャネルで早送りする際に、ＣＲＬキャッシュは更新され、ＣＲＬ１２０のリスト１２５にそのように識別されたＣＡ認証の取り消しが行われる。
【００９８】
認証局のＣＡ認証１００の取り消しの際に、この認証局のための新しいＣＡ認証をデコーダに記憶させ、その上、この認証局が認証を配信する放送会社の全てに対して放送会社認証９０を交換する必要がある。それは、この認証局のための私用鍵対はもはや有効でないので、認証局の、異なるか更新された私用鍵を使用して署名された新しい放送会社認証９０が必要とされるからである。交換されるＣＡ認証１００は、ルート認証局１１０によって生成され、ファイルのディレクトリ７５あるいは７６のユーザに放送される。交換される放送会社認証と同様に、交換されるＣＡ認証は、とりわけ、新しいＣＡ公開鍵１０１と、更新バージョン番号１０２と、更新妥当性期間１０５と、ＲＣＡの私用鍵を使用して計算された新しいシグネチャ値１０６とを含む。ＣＡ識別子９４およびＲＣＡ識別子１０４は変更されないままである。交換されるＣＡ認証１００の受信の際に、デコーダは、ＲＣＡ識別子１０４によって識別されたＲＣＡ認証１００に含まれる対応するＲＣＡ公開鍵を使用してＣＡ認証１００を処理することによって認証を検証する。
【００９９】
（ルート認証管理メッセージ）
ルート認証局のＲＣＡ認証１１０の取り消しの際に、取り消されたＲＣＡ認証を新しいＲＣＡと交換する必要がある。前述されるように、ＲＣＡ認証は自動署名されるので、ＣＲＬへＲＣＡ認証を含めることは、ハッカーがＣＲＬを署名するために使用される私用鍵を知っている場合、ハッカーは認証を持つことができるので望ましくない。したがって、例えば、ＲＣＡ認証が旧式になったかあるいは取り消されるようになった場合、これまでＲＣＡ認証が更新されるべきである度にデコーダを製造者に戻すことが必要であった。
【０１００】
この問題を解決するために、ルート認証管理メッセージ（ＲＣＭＭ）は、放送会社によってデコーダに放送するためにルート認証局によって生成される。下記により詳細に説明されるように、ＣＲＬと同様に、ＲＣＭＭは、旧式になったかあるいはリスト１２５に識別されたこれらの認証のための１つあるいはそれ以上の交換ルート認証とともに、各々の取り消されたルート認証に対してこの認証の取り消しのための時間および日付を含む、取り消されるルート認証の連続番号のリスト１２５を含む。
【０１０１】
理解されるように、ＲＣＭＭの秘密にかかわる内容（新しいルート認証）に関して、放送会社に「出されるような」デコーダによって受信されることを保証すること、すなわちＲＣＭＭの内容が配信と受信との間で交換されないことを保証することは、重要である。ＲＣＭＭが、ＲＣＭＭがアドレスされる誰かにデコーダによってだけアクセスできることを保証することも重要である。
【０１０２】
セキュリティを高めるために、ＣＲＬと違って、ＲＣＭＭは、その中に含まれるデータの少なくともいくつか、好ましくは全てに対する少なくとも２つのシグネチャ値を含む。各々のシグネチャ値は、公開鍵／私用鍵対の私用鍵のようなそれぞれの暗号化アルゴリズムの鍵を使用して計算される。
【０１０３】
ＲＣＭＭがルート認証局（ＲＣＡ）によって出され、新しいルート認証１１０を含む場合、ＲＣＭＭは、少なくとも２つのシグネチャ値を含む。各々のシグネチャ値は、例えば、ＲＣＡが認証を供給する認証局のそれぞれの私用鍵を使用して計算される（ただし、デコーダが等しい鍵を記憶するいかなる鍵も選択されてもよい）。これらの認証局の中の１つに未知であり、その私用鍵が危険にさらされるようになる場合、「ハッカー」は放送会社の放送を遮断することが可能であり得る。ハッカーが放送会社および認証局の両方の私用鍵を知っている場合、ハッカーは、ＲＣＭＭの内容および認証局の私用鍵を使用して計算されたＲＣＭＭのシグネチャ値を変える。しかしながら、この鍵は危険にさらされているようにならないために、ハッカーは、他の認証局の私用鍵を使用して計算されたシグネチャ値を変えることができない。したがって、２つの認証局の公開鍵を使用してデコーダによるシグネチャの検証の際に、それぞれの公開鍵を使用してデコーダによって計算された２つの値は同じでない。したがって、デコーダは、ＲＣＭＭの内容の一貫性の欠如のために変えられ、ＲＣＭＭの処理を拒否し、またはその他ＲＣＭＭの処理を続けない。
【０１０４】
したがって、もし危険にさらされた認証数がＲＣＭＭに含まれたシグネチャ数よりも小さいとすれば、ルート認証は安全に更新できる。したがって、ＲＣＭＭのシグネチャ数は、ＲＣＭＭを配信するルート認証局によって決定された変数である。
【０１０５】
次に、ＲＣＭＭのフォーマットは、図を参照してより詳細に示されている。
ＲＣＭＭ１３０は、ＲＣＭＭ１３０を配信したＲＣＡの一貫性１３２；
ＲＣＭＭ１３０が発行した日付１３４；
その後のＲＣＭＭが含むシグネチャ値の数１３６；
１つあるいはそれ以上の更新されるかあるいはデコーダに記憶される交換ルート認証を含むフィールド１３８；
【０１０６】
各々の取り消されたルート認証に対してこの認証の取り消しの時間および日付を含む、取り消されたルート認証の連続番号のリスト１４０；および各々が、このシグネチャフィールドに含まれたシグネチャ値を検証するために使用される公開鍵を含む、デコーダに記憶された認証の識別子１４４；および識別子１４４によって識別される認証に含まれる公開鍵に等しい私用鍵を使用して計算されたＲＣＭＭのシグネチャ値１４６を含む少なくとも２つのシグネチャフィールド１４２を含む。
【０１０７】
シグネチャフィールド数１４２は、予め受信されたＲＣＭＭに通知されるようなシグネチャフィールド数１３６に等しいかあるいはそれよりも大となるべきである。
モデム逆方向チャネルは容易に切り離してもよいしあるいは単に存在しなくてもよいので、ＲＣＭＭはＭＰＥＧトランスポートストリームを介して伝送されることが好ましい。ＲＣＭＭが、デコーダによってダウンロードされることを保証するために放送会社によってデータファイルとしてルートディレクトリ７５に挿入されることも好ましい。
【０１０８】
（ルート認証管理メッセージの処理および生成）
次に、デコーダによるＲＣＭＭの受信および処理は、図１１を参照して説明される。
ＲＣＭＭの受信の際に、ステップ２００では、デコーダは、予めＲＣＭＭを出されたＲＣＭＭ１３０が出された日付１３４を比較する。新しい受信されたＲＣＭＭの日付１３４が前のＲＣＭＭが出された日付よりも後でない場合、ＲＣＭＭは拒否される。
【０１０９】
新しく受信されたＲＣＭＭの日付１３４が前のＲＣＭＭの受信の日付よりも後である場合、予め受信されたＲＣＭＭによって通知されるように、新しく受信されたＲＣＭＭが含むべきであるシグネチャ値の数１３６は、ステップ２０２で新しく受信されたＲＣＭＭで実際に含まれたシグネチャ値の数と比較される。新しく受信されたＲＣＭＭに含まれたシグネチャの数が予想よりも低い場合、ＲＣＭＭが拒否される。これは、ＲＣＭＭが危険にさらされていない私用鍵／公開鍵対に関連したシグネチャを取り除くハッカーの結果として特に処理されることを防止する。
【０１１０】
新しく受信されたＲＣＭＭに含まれたシグネチャの数が予想されたシグネチャの数に等しいかあるいはそれよりも大きい場合、ステップ２０４で、ＲＣＭＭに含まれた各々のシグネチャ値１４６は、このシグネチャ値と同じシグネチャフィールド１４２に含まれる識別子１４４によって識別された公開鍵を使用して検証される。ステップ２０６では、デコーダは、公開鍵を使用して計算された値の少なくとも１つが異なる公開鍵を使用して計算された他の値のいずれかと異なるかどうかを決定する。少なくとも１つの計算された値が他の計算された値の少なくとも１つと異なる場合、ＲＣＭＭは拒否される。
【０１１１】
ＲＣＭＭの一貫性がステップ２０６で証明される場合、ＲＣＭＭは、ステップ２０８で処理され、デコーダの固定メモリに取り消されたルート認証の連続番号のリスト１４０を記憶するので、これらの認証は、ステップ２１２で、デコーダのメモリから削除され、フィールド１３８に含まれたルート認証あるいは各ルート認証をデコーダの固定メモリに記憶し、ステップ２１２でＲＣＭＭの日付１３４を固定メモリに記憶してもよい。ルート認証局の認証が削除される場合、この局によって出される任意のＣＲＬも削除される。
【０１１２】
ＲＣＭＭに含まれたデータの固定メモリの一貫性が、デコーダがＲＣＭＭメッセージの処理中スイッチオフされる場合、保持されることが好ましい。したがって、電力が実際にＲＣＭＭ処理中スイッチオフされる場合、デコーダに記憶される予め処理されたＲＣＭＭに関連したリスト１４０は、あたかも新しく受信されたＲＣＭＭメッセージが全然処理されなかったかのように保持される。
【０１１３】
前述されるように、ルート認証局（ＲＣＡ）は、一般的には各デコーダに記憶された少なくとも２つのＲＣＡ認証、すなわちＲＣ０およびＲＣ１を有する。これらの認証の１つ、例えばＲＣ０が危険にさらされるようになる場合、ＲＣ０に記憶された公開鍵の等価私用鍵を使用して署名されたデコーダに記憶された全ＣＡ認証を交換し、新しいＲＣＡ認証ＲＣ２を生成し、ＲＣ０を交換する必要がある。
【０１１４】
図１２を参照すると、これらのＣＡ認証を交換するために、最初にステップ３００では取り消されるＣＡ認証の連続番号を識別する適切なＣＲＬメッセージがＲＣＡによって出される。第二に、ステップ３０２では、危険にさらされていない認証ＲＣ１の私用鍵を使用して署名され交換ＣＡ認証は、デコーダに放送するために放送会社に出される。
【０１１５】
次に、交換ＣＡ認証は、危険にさらされたＲＣＡ認証ＲＣ０を削除し、この認証を新しいＲＣＡ認証ＲＣ２と交換するままである。ステップ３０４では、ＲＣＡは、新しい公開鍵／私用鍵対を生成し、認証ＲＣ２に新しい公開鍵を挿入し、新しい私用鍵を使用して認証を署名する。
【０１１６】
ステップ３０６では、ＲＣＡは、フィールド１３８では、認証ＲＣ２およびリスト１４０ではＲＣ０の連続番号を含むＲＣＭＭを生成する。このＲＣＭＭは、ステップ３０８では、デコーダに伝送するために放送会社に配信され、危険にさらされた認証ＲＣ０を削除し、これを新しい認証ＲＣ２と交換する。
【０１１７】
ＲＣＡ認証ＲＣ１およびＲＣ２は、その後新しいデコーダのメモリにハードコーディングするためにデコーダ製造者に供給される。
本発明は例として単に前述され、詳細の修正は本発明の範囲内に行うことができることが分かる。
【０１１８】
例えば、ＲＣＭＭは、新しいＲＣＡ認証１１０に加えて、新しいＣＡ認証１００および／または新しい放送会社認証９０を含んでもよく、リスト１４０は、ＣＡ認証および／または取り消されるべきである放送会社認証の識別子を含んでもよい。これは、ＲＣＡによる別個のＣＲＬメッセージの生成が不要にされることを可能にすることができる。
説明で開示された各々の特徴、および（適切である場合）特許請求の範囲および図面は、独立してあるいは任意の適切な組み合わせで提供されてもよい。
【符号の説明】
【０１１９】
１ デジタルテレビシステム
２ 従来のデジタルテレビシステム
３ 圧縮器
４ スクランブラ、マルチプレクサ
５ リンク装置
６ 送信機
７ リンク結合装置
８ アップリンク
９ 衛星トランスポンダ
１０ ダウンリンク
１２ 受信機
１３ 統合受信機／デコーダ
１４ テレビ受像機
１５ 条件付アクセスシステム
１６ 対話システム
１７ モデム逆方向チャネル
【特許請求の範囲】
【請求項１】
デジタルデータとデジタルオーディオビジュアル情報が含まれているデジタルデータストリーミングを形成する方法であって、当該方法は、
ＤＳＭ−ＣＣ Ｕ−Ｕファイルのペイロード内にデータオブジェクトと共に当該デジタルデータをＤＳＭ−ＣＣフォーマット形式にフォーマットする工程であって、当該データオブジェクトの少なくとも１つは、当該データオブジェクトの少なくとも１つに含まれているデータと当該デジタルオーディオビジュアル情報との間に一時の関係を形成するストリームオブジェクトである様なフォーマット工程と
当該デジタルデータと当該デジタルオーディオビジュアル情報とをインターレースする工程、
とから構成されている事を特徴とする方法。
【請求項２】
当該データオブジェクトの少なくとも１つに含まれているデータは、少なくとも１つの対話型アプリケーションと対応している事を特徴とする請求項１に記載の方法。
【請求項３】
当該少なくとも１つの対話型アプリケーションは、当該デジタルオーディオビジュアル情報と同期される様に設計されている事を特徴とする請求項２に記載の方法。
【請求項４】
当該方法は、更に当該デジタルデータをＢＩＯＰ（Ｂｒｏａｄｃａｓｔ ＩｎｔｅｒＯｒｂ Ｐｒｏｔｏｃｏｌ）に従ってグループ化された一連のメッセージ内に組織化する工程を含んでいる事を特徴とする請求項１乃至３の何れかに記載の方法。
【請求項５】
当該方法は、更に当該データをＭＰＥＧパケットとしてフォーマッティングする工程を含んでいる事を特徴とする請求項１乃至４の何れかに記載の方法。
【請求項６】
デジタルデータとデジタルオーディオビジュアル情報が含まれているデジタルデータストリーミングを形成する装置であって、当該装置は、
ＤＳＭ−ＣＣ Ｕ−Ｕファイルのペイロード内にデータオブジェクトと共に当該デジタルデータをＤＳＭ−ＣＣフォーマット形式にフォーマットする手段であって、当該データオブジェクトの少なくとも１つは、少なくとも１つのデータオブジェクトに含まれているデータと当該デジタルオーディオビジュアル情報との間に一時の関係を形成するストリームオブジェクトである様なフォーマット手段と
当該データと当該デジタルオーディオビジュアル情報とをインターレースする手段、
とから構成されている事を特徴とする装置。
【請求項７】
インターレースされたデジタルデータとデジタルオーディオビジュアル情報が含まれているデジタルデータストリームであって、当該デジタルデータは、ＤＳＭ−ＣＣ Ｕ−Ｕファイルのペイロード内にデータオブジェクトと共にＤＳＭ−ＣＣフォーマット形式にフォーマットされているものであり、且つ当該データオブジェクトの少なくとも１つは、当該データオブジェクトの少なくとも１つに含まれているデータと当該デジタルオーディオビジュアル情報との間に一時の関係を形成するストリームオブジェクトである事を特徴とするデジタルデータストリーム。
【請求項１】
デジタルデータとデジタルオーディオビジュアル情報が含まれているデジタルデータストリーミングを形成する方法であって、当該方法は、
ＤＳＭ−ＣＣ Ｕ−Ｕファイルのペイロード内にデータオブジェクトと共に当該デジタルデータをＤＳＭ−ＣＣフォーマット形式にフォーマットする工程であって、当該データオブジェクトの少なくとも１つは、当該データオブジェクトの少なくとも１つに含まれているデータと当該デジタルオーディオビジュアル情報との間に一時の関係を形成するストリームオブジェクトである様なフォーマット工程と
当該デジタルデータと当該デジタルオーディオビジュアル情報とをインターレースする工程、
とから構成されている事を特徴とする方法。
【請求項２】
当該データオブジェクトの少なくとも１つに含まれているデータは、少なくとも１つの対話型アプリケーションと対応している事を特徴とする請求項１に記載の方法。
【請求項３】
当該少なくとも１つの対話型アプリケーションは、当該デジタルオーディオビジュアル情報と同期される様に設計されている事を特徴とする請求項２に記載の方法。
【請求項４】
当該方法は、更に当該デジタルデータをＢＩＯＰ（Ｂｒｏａｄｃａｓｔ ＩｎｔｅｒＯｒｂ Ｐｒｏｔｏｃｏｌ）に従ってグループ化された一連のメッセージ内に組織化する工程を含んでいる事を特徴とする請求項１乃至３の何れかに記載の方法。
【請求項５】
当該方法は、更に当該データをＭＰＥＧパケットとしてフォーマッティングする工程を含んでいる事を特徴とする請求項１乃至４の何れかに記載の方法。
【請求項６】
デジタルデータとデジタルオーディオビジュアル情報が含まれているデジタルデータストリーミングを形成する装置であって、当該装置は、
ＤＳＭ−ＣＣ Ｕ−Ｕファイルのペイロード内にデータオブジェクトと共に当該デジタルデータをＤＳＭ−ＣＣフォーマット形式にフォーマットする手段であって、当該データオブジェクトの少なくとも１つは、少なくとも１つのデータオブジェクトに含まれているデータと当該デジタルオーディオビジュアル情報との間に一時の関係を形成するストリームオブジェクトである様なフォーマット手段と
当該データと当該デジタルオーディオビジュアル情報とをインターレースする手段、
とから構成されている事を特徴とする装置。
【請求項７】
インターレースされたデジタルデータとデジタルオーディオビジュアル情報が含まれているデジタルデータストリームであって、当該デジタルデータは、ＤＳＭ−ＣＣ Ｕ−Ｕファイルのペイロード内にデータオブジェクトと共にＤＳＭ−ＣＣフォーマット形式にフォーマットされているものであり、且つ当該データオブジェクトの少なくとも１つは、当該データオブジェクトの少なくとも１つに含まれているデータと当該デジタルオーディオビジュアル情報との間に一時の関係を形成するストリームオブジェクトである事を特徴とするデジタルデータストリーム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１０−１８３５８８（Ｐ２０１０−１８３５８８Ａ）
【公開日】平成２２年８月１９日（２０１０．８．１９）
【国際特許分類】
【出願番号】特願２０１０−４５３４５（Ｐ２０１０−４５３４５）
【出願日】平成２２年３月２日（２０１０．３．２）
【分割の表示】特願２００８−２５７６８８（Ｐ２００８−２５７６８８）の分割
【原出願日】平成１３年１月１１日（２００１．１．１１）
【出願人】（５０２３０３８４３）カナル プラス テクノロジーズ ソシエテ アノニム (9)
【Ｆターム（参考）】
【公開日】平成２２年８月１９日（２０１０．８．１９）
【国際特許分類】
【出願日】平成２２年３月２日（２０１０．３．２）
【分割の表示】特願２００８−２５７６８８（Ｐ２００８−２５７６８８）の分割
【原出願日】平成１３年１月１１日（２００１．１．１１）
【出願人】（５０２３０３８４３）カナル プラス テクノロジーズ ソシエテ アノニム (9)
【Ｆターム（参考）】
[ Back to top ]