デジタル伝送システムで伝送されるデータの認証及び証明の方法及びその装置
【課題】デジタル伝送システムで伝送されるデータを認証する方法を提供する。
【解決手段】この方法は、伝送よりも前にデータの少なくともいくつかに対する少なくとも2つの暗号化値を決定するステップであって、各々の暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して決定されることと、前記少なくとも2つの暗号化値を前記データとともに出力するステップとを含む。
【解決手段】この方法は、伝送よりも前にデータの少なくともいくつかに対する少なくとも2つの暗号化値を決定するステップであって、各々の暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して決定されることと、前記少なくとも2つの暗号化値を前記データとともに出力するステップとを含む。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、デジタル伝送システムで伝送されるデータの認証及び証明の方法及びその装置に関するものである。
【背景技術】
【0002】
デジタルデータの同報伝送は、スクランブルオーディオビジュアル情報が、通常衛星あるいは衛星/ケーブルリンクによって各々がその後見るための伝送番組を暗号解読できるデコーダを所有する多数の加入者に送信されるペイTVシステムの分野で周知である。地上デジタル放送システムも公知である。最近のシステムは、視聴覚データに加えてあるいは視聴覚データと同様に、デコーダあるいは接続PCのためのコンピュータプログラムあるいは対話型アプリケーションのような他のデータを伝送する放送リンクも使用した。
【0003】
アプリケーションの伝送に関する特定の問題は、いかなるこのようなデータの一貫性および発生源も検証する必要性にある。この種のデータは、いかなる対話型アプリケーション数も実行するのと同様にデコーダを再構成するために使用されてもよいので、受信データは完全であり、かつ公知の発生源から発生するものとして識別されることの両方であることが重要である。特に、不完全なデータのダウンロードに関係付けられる操作上の問題が、デコーダが第三者等による攻撃を受けやすいようになる危険と同様に生じ得る。
【0004】
このようなデータの一貫性を検証することは、デコーダによって直接受信されたデータのパケットストリームの検証によって行われてもよい。伝送より前に、パケットは、一般的にはハッシングアルゴリズムをパケットのデータの少なくともいくつかに用いることによって署名される。生じるハッシュ値はパケットに記憶される。データパケットの受信の際に、デコーダは、同じハッシングアルゴリズムをデータに用い、受信データの一貫性を検証するためにデコーダによって計算されたハッシュ値を受信パケットに記憶されたハッシュ値と比較する。例えば、伝送の故障あるいは遮断の場合、計算ハッシュ値は、受信ハッシュ値と同じでない。次に、デコーダは、ダウンロードデータパケットの可能なエラーの存在のために変更され、間違ったデータパケットを再ロードする。
【0005】
メッセージダイジェストアルゴリズムMD5のような周知のハッシングアルゴリズムの使用に関連した問題は、ハッシュ値の計算が公に公知の一連の計算ステップに従って実行されるということであり、その結果、誰でもデータパケットのハッシュ値を計算できる。
【0006】
従って、デコーダによって受信されたデータパケットの発生源を検証できる。受信データがデコーダの演算データファイルを修正する場合、このことは特に重要であり得る。
【発明の開示】
【発明が解決しようとする課題】
【0007】
この問題を解決するために、データの少なくともいくつかに対するハッシュ値を計算するハッシングアルゴリズムを使用する代わりに、データパケットのシグネチャ値は、放送者にだけ公知である秘密鍵値を使用して計算されてもよい。この鍵は、データ暗号化規格、すなわちDESのアルゴリズムのような対称性鍵アルゴリズムを等価鍵を記憶するデコーダとともに使用して得ることができる。しかしながら、より便利なことは、公開鍵および私用鍵が数式の補数部を形成する、リベスト(Rivest)、シャミール(Shamir)およびアデルマン(Adleman)、あるいはRSAのアルゴリズムのような非対称性公開/私用鍵アルゴリズムを使用することによってもたらすことができることである。
【0008】
データパケットを生成する責任のある放送者は、私用鍵を記憶し、私用鍵を使用してシグネチャ値を計算する。この公開鍵は、製造中公開鍵をデコーダメモリへハードコーディングすることによってデータを受信すべきであるデコーダに記憶される。データパケットの受信の際に、デコーダは、受信データを公開鍵アルゴリズムを受信シグネチャ値に用いる結果と比較することによって記憶された公開鍵を使用してシグネチャ値を検証する。
【0009】
このような安全システムにおいてさえ、私用鍵の値は、例えば不法に公然と配信することによって危険にさらされ得る。このような場合、放送者は、データパケットの無許可受信を防止するために等しい公開鍵の使用を迅速に取り消すことが必要になる。さらに、新しい公開/私用鍵対が使用されることも必要になる。したがって、放送会社は、合法ユーザのデコーダに記憶された公開鍵を新しい公開鍵と交換する必要がある。公開鍵の感度に応じて、このことは、放送者がこれらのデコーダのメモリへの新しい公開鍵のハードコーディングするために製造者へのこれらのデコーダの高価で、煩わしい返却を計画することを必要とし得る。
【課題を解決するための手段】
【0010】
本発明の目的は、これらの問題および他の問題を解決しようとするものである。
本発明の第1の態様は、デジタル伝送システムで伝送されるデータを認証する方法を提供し、前記方法は、伝送より前に、データの少なくともいくつかに対する少なくとも2つの暗号化値を決定するステップであって、各暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して同じデータに対して決定されることと、前記少なくとも2つの暗号化値を前記データとともに出力するステップとを含む。
【0011】
本発明は、データが「出されるように」受信されることを保証するために新しい暗号化アルゴリズムで使用される鍵のような影響されやすいデータを安全に更新することが望ましい状態に特に応用できるが、これに限定されない。このようなセキュリティを行うために、データの少なくともいくつか、好ましくは多数、より好ましくは全てに対する少なくとも2つの暗号化値が決定される。各々の暗号化値は、それぞれの暗号化アルゴリズムの鍵を使用して決定される。鍵の1つが危険にさらされるようになった場合、「ハッカー」は、データを遮断し、データおよび危険にさらされた鍵を使用して計算された暗号化値の内容を変更でき得る。暗号化値を計算するために使用される鍵と等しい鍵を使用する暗号化値の検証の際に、データが破損されるようになったことを示す、等価鍵を使用する2つの値は同じでない。
データおよび暗号化値は、好ましくは受信機/デコーダに伝送するために出力される。
【0012】
好ましくは、前記データおよび前記暗号化値は、受信機/デコーダによって受信され、この受信機/デコーダで、各暗号化値は、前記それぞれの暗号化アルゴリズムの鍵を使用して処理され、各々のその後に生じる値は、データの前記少なくともいくつかと比較され、データの前記少なくともいくつかを認証する。このデータが破損されるようになった場合、受信機/デコーダは、データを無視するように選択できるので、危険にさらされるかあるいは破損された新しい鍵は、デコーダのメモリに記憶されない。好ましくは、その後に生じる値の少なくとも1つがデータの前記少なくともいくつかとは異なる場合、前記受信データは、受信機/デコーダによって拒否される。
【発明を実施するための最良の形態】
【0013】
したがって、本発明は、デジタル伝送システムで伝送されるデータを認証する方法に及び、前記方法は、前記データおよびデータの少なくともいくつかに対して決定された少なくとも2つの暗号化値を受信するステップであって、各々の暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して決定されることと、複数の鍵を記憶するステップと、それぞれの暗号化アルゴリズムの記憶された鍵を使用して各々の暗号化値を処理するステップと、各々のその後に生じる値をデータの前記少なくともいくつかと比較し、データの前記少なくともいくつかを認証するステップとを含む。
【0014】
好ましくは、各アルゴリズムは非対称である。好ましい実施形態では各々の暗号化値は暗号化アルゴリズムの私用鍵で計算されたデジタルシグネチャにそれぞれ対応し、各シグネチャは前記暗号化アルゴリズムの公開鍵を使用し処理しうる。
【0015】
好ましくは、この方法は、各々のシグネチャとともに、このシグネチャを処理するために使用される公開鍵の識別子を出力するステップを含む。これによって、受信機/デコーダは、このシグネチャを検証するために使用される鍵を容易に識別することを可能にできる。
【0016】
好ましくは、このデータは鍵を含む。好ましい実施形態では、データは、データを処理するための暗号化アルゴリズムの公開鍵を含む少なくとも1つのデジタル認証、好ましくは少なくとも1つのデジタルルート認証を含む。この少なくとも1つのデジタル認証は、この認証に含まれる公開鍵の暗号化アルゴリズムの私用鍵を使用して計算されたデジタルシグネチャを含んでもよい。したがって、デジタル認証は、デコーダのメモリの新しい認証のハードコーディングのために製造者に戻されねばならないデコーダなしにデコーダに安全に伝送できる。
【0017】
好ましくは、前記データは、取り消された公開鍵の識別子を含む。この識別子は、前記取り消された公開鍵を含む、デジタル認証、好ましくはデジタルルート認証の識別子を含んでもよい。このデータは、複数の前記識別子を含んでもよく、各々の識別子は、それぞれの取り消された公開鍵を識別する。したがって、取り消された鍵の識別子のリストは、デコーダに安全に伝送できる。
【0018】
前記の方法によって、危険にさらされた鍵の数がデータとともに記憶される暗号化値の数よりも小さいとすれば、データは安全に更新できる。したがって、前記データおよび前記少なくとも2つの暗号化値は、その後に生成されたデータファイルに記憶される暗号化値の最小数の指示を含んでもよいデータファイルに構成されてもよい。鍵が危険にさらされたようになるべきであるので、暗号化値の最小数が危険にさらされた鍵の数よりも大きいままである場合、これによって、暗号化値の最小数は、変更でき、例えば増加できる。
【0019】
好ましくは、前記データファイルに記憶された暗号化値の数を前記最小数と比較し、前記データファイルに記憶された暗号化値の数が前記最小数よりも小さい場合、前記データファイルを拒否する受信機/デコーダによって受信される。
【0020】
このデータファイルはデータモジュールに伝送されてもよい。前記モジュールのデータの少なくともいくつかに対するモジュール暗号化値は、送信機暗号化アルゴリズムの鍵を使用して計算し、前記データモジュールに記憶できる。このデータモジュールは、送信機暗号化アルゴリズムの鍵を使用して前記モジュール暗号化値を処理し、その後に生じる値を前記モジュールのデータの前記少なくともいくつかと比較し、前記モジュールのデータの前記少なくともいくつかを認証する受信機/デコーダによって受信されてもよい。
【0021】
前記モジュールのデータの少なくともいくつかに対する暗号化値は、送信機暗号化アルゴリズムの私用鍵を使用して計算され、前記送信機暗号化アルゴリズムの公開鍵を使用して処理可能であるデジタルシグネチャに対応し得る。
デジタル伝送システムは、テレビあるいはオーディオシステムのようなデジタル放送システムであってもよい。
【0022】
本発明は、デジタル伝送システムで伝送されるデータを認証する装置も提供し、前記装置は、データの少なくともいくつかに対する少なくとも2つの暗号化値を決定する手段であって、各々の暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して同じデータに決定されることと、前記データとともに前記少なくとも2つの暗号化値を出力する手段とを備えている。
【0023】
本発明は、デジタル伝送システムで伝送されるデータを認証するシステムも提供し、前記システムは前述されるような装置を含む。このシステムは、好ましくは、前記データおよび前記暗号化値を受信する手段と、前記それぞれの暗号化アルゴリズムの鍵を使用して各々の暗号化値を処理する手段と、各々のその後に生じる値をデータの前記少なくともいくつかと比較し、データの前記少なくともいくつかを認証する手段とを含む受信機/デコーダをさらに含む。
【0024】
本発明は、データおよびデータの少なくともいくつかに対して決定される少なくとも2つの暗号化値を含むデータファイルを受信する手段であって、各々の暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して決定されることと、複数の鍵を記憶する手段と、前記それぞれの暗号化アルゴリズムの記憶された鍵を使用して各々の暗号化値を処理する手段と、各々のその後に生じる値をデータの前記少なくともいくつかと比較し、データの前記少なくともいくつかを認証する手段とを含む受信機/デコーダに及ぶ。
【0025】
本発明は、デジタル伝送システムで伝送されるデータを認証するシステムにも及び、前記システムは、前述されたような装置および前述されたような受信機/デコーダを含む。
【0026】
本発明は、さらにデータおよびデータの少なくともいくつかに対して決定された少なくとも2つの暗号化値を含む信号に及び、各々の暗号化値は、それぞれの暗号化アルゴリズムの鍵を使用して決定される。
本発明は、さらに実質的に添付図面を参照してここに説明されるようなデータを認証する方法、あるいは装置、受信機/デコーダ、あるいは信号に及ぶ。
【0027】
ここで使用される用語「受信機/デコーダ」あるいは「デコーダ」は、いくつかの他の手段によって放送されてもよいしあるいは伝送されてもよい、符号化信号あるいは非符号化信号のいずれか、例えばテレビおよび/またはラジオ信号を受信する受信機を意味してもよい。この用語は、受信信号を復号化するデコーダも意味してもよい。このような受信機/デコーダの実施形態は、例えば、物理的に別個の受信機との組み合わせで機能を果たすデコーダ、あるいはウェブブラウザのようなあるいはビデオレコーダあるいはテレビのような他の装置と一体化された付加機能を含むデコーダのような「セットトップボックス」で受信信号を復号化する受信機と一体であるデコーダを含んでもよい。
【0028】
ここで使用されるように、用語「デジタル伝送システム」は、例えば、主に視聴覚データあるいはマルチメディアデータを伝送あるいは放送するいかなる伝送システムも含む。
本発明は、放送デジタルテレビシステムに特に用いることができるが、本発明は、マルチメディアインターネット用途のための固定電気通信網、閉回路テレビ等にも応用できてもよい。
【0029】
ここで使用されるように、用語「デジタルテレビシステム」は、例えば、任意の衛星システム、地上システム、ケーブルシステムおよび他のシステムを含む。
本発明で使用し、私用/公開鍵を生成するための適当なアルゴリズムは、RSA、フィアット−シャミール、あるいはディフィ−ヘルマンを含んでもよく、適当な対称鍵アルゴリズムは、例えばDES形アルゴリズムを含んでもよい。しかしながら、前後関係を考慮して不可欠でない限りあるいは別段の指定がない限り、対称アルゴリズムに関連した鍵と公開/私用アルゴリズムに関連した鍵との間の一般的な区別は全然行われない。
【0030】
用語「スクランブル」および「暗号化」および「制御ワード」および「鍵」は、用語を明瞭にするためにテキストのいろいろな部分で使用された。しかしながら、「スクランブルデータ」と「暗号化データ」、「制御ワード」と「鍵」との基本的区別は、全然行われるべきでないことが分かる。
【0031】
さらに、用語「暗号化」および「署名」や「暗号解読」および「検証」は、用語を明瞭にするためにテキストのいろいろな部分で使用された。しかしながら、「暗号化データ」と「署名データ」および「暗号解読データ」および「検証データ」との基本的区別は、全然行われるべきでないことが分かる。
【0032】
同様に、用語「等価鍵」は、第1の記載された鍵によって暗号化されたデータを暗号解読、あるいはその逆をするために構成された鍵を示すために使用される。
本発明の方法態様に関連する前述の機能は、装置態様にも応用でき、あるいはその逆でも用いることができる。
【0033】
次に、添付図面を参照して本発明の好ましい実施形態だけが例として説明される。
本発明によるデジタルテレビシステム1の概略1は、図1に示される。本発明は、圧縮デジタル信号を伝送するために公知のMPEG−2圧縮システムを使用する多くの従来のデジタルテレビシステム2を含む。より詳細には、放送局のMPEG−2圧縮器3は、デジタル信号ストリーム(一般的には、ビデオ信号のストリーム)を受信する。この圧縮器3は、リンク装置5によってマルチプレクサおよびスクランブラ4に接続される。
【0034】
マルチプレクサ4は、複数の他の入力信号を受信し、トランスポートストリームを組み立て、もちろん通信リンクを含むいろいろの形をとることができるリンク結合装置7を介して圧縮デジタル信号を放送局の送信機6に送信する。送信機6は、アップリンク8を介して電磁信号を電子的に処理される衛星トランスポンダ9の方へ送信し、概念上のダウンリンク10を介して従来はエンドユーザによって所有されるかあるいは賃貸される皿の形の地上受信機12に放送する。受信機12によって受信された信号は、ユーザエンドによって所有されるかあるいは賃貸され、エンドユーザのテレビ受像機14に接続された統合受信機/デコーダ13に送信される。この受信機/デコーダ13は、圧縮MPEG−2信号をテレビ受像機14のためのテレビ信号に復号化する。
【0035】
地上放送、ケーブル伝送、結合衛星/ケーブルリンク、電話網等のようなデータの伝送のための他のトランスポートチャネルは、もちろん可能である。
【0036】
マルチチャネルシステムでは、マルチプレクサ4は、多数の並列発生源から受信されたオーディオおよびビデオ情報を処理し、送信機6と対話し、対応するチャネル数に沿って情報を放送する。オーディオビジュアル情報に加えて、デジタルデータのメッセージあるいはアプリケーションもしくは任意の他の種類のデジタルデータは、送信されたデジタルオーディオおよびビデオ情報とインタレースされたこれらのチャネルのいくつかあるいは全部に導入される。このような場合、例えば、DSM−CC(デジタル記憶メディアコマンドおよびコントロール)フォーマットソフトウェアファイルおよびメッセージの形のデジタルデータのストリームは、圧縮器3によってMPEGフォーマットに圧縮され、パケット化される。ソフトウェアモジュールのダウンロードは、下記により詳細に説明される。
【0037】
条件付アクセスシステム15は、マルチプレクサ4および受信機/デコーダ13に接続され、一部が放送局にあり、一部がデコーダにある。このシステムによって、エンドユーザは、1つあるいはそれ以上の放送供給者からデジタルテレビ放送にアクセスできる。市販の売り物(すなわち、放送供給者によって宣伝された1つあるいはいくつかのテレビ番組)に関するメッセージを解読できるスマートカードは、受信機/デコーダ13に挿入できる。デコーダ13およびスマートカードを使用すると、エンドユーザは、加入モードあるいはペイ・パー・ビューモードのいずれかで市販の売り物を購入できる。実際には、デコーダは、例えば同時暗号あるいは複数暗号設計の多重アクセス制御システムを処理するように構成されてもよい。
【0038】
前述されたように、システムによって放送された番組は、マルチプレクサ4でスクランブルされ、所与の伝送に加えられる条件および暗号化鍵は、アクセス制御システム15によって決定される。このようにスクランブルされたデータの伝送は、ペイTVシステムの分野で周知である。一般的には、スクランブルデータは、データを暗号解読する制御ワードとともに伝送され、制御ワードそのものは、いわゆる利用鍵によって暗号化され、暗号化形式で伝送される。
【0039】
スクランブルデータおよび暗号化制御ワードは、次にデコーダに挿入されたスマートカードに記憶された利用鍵の均等物へのアクセス権を有するデコーダ13によって受信され、暗号化制御ワードを暗号解読し、その後、伝送データを暗号解読する。支払った加入者は、例えば、伝送を見ることができるように暗号化制御ワードを暗号解読するのに必要な利用鍵を放送月EMM(資格管理メッセージ)で受信する。視聴覚テレビ番組を暗号解読する際のその使用に加えて、同じ利用鍵が、前述されるようなソフトウェアモジュールのような他のデータの検証で使用するために生成され、送信されてもよい。
【0040】
マルチプレクサ4および受信機/デコーダ13にも接続され、さらに一部が放送局にあり、一部がデコーダにある対話システム16によって、エンドユーザは、モデム逆方向チャネル17を介していろいろなアプリケーションと対話できる。このモデム逆方向チャネルも、条件付アクセスシステム15で使用される通信のために使用されてもよい。対話システムは、例えば、視聴者は、直ちに放送局と通信し、特定の試合を見て、アプリケーション等をダウンロードするための許可を要求することができる。
【0041】
(受信機/デコーダの物理的要素)
図2を参照すると、本発明で使用されるように構成される受信機/デコーダ13あるいはセットトップボックスの物理的要素は、次に簡単に説明される。この図に示された要素は、機能ブロックによって説明される。
デコーダ13は、関連メモリ要素を含み、かつ直列インタフェース21、並列インタフェース22、および(図1のモデム逆方向チャネル17に接続される)モデムから入力データを受信するように構成される中央プロセッサ20を含む。
【0042】
デコーダは、さらに制御装置26を介して赤外線遠隔制御装置25からおよびデコーダの正面パネル上のスイッチコンタクト24から入力を受信するように構成される。このデコーダは、銀行スマートカードおよび加入スマートカード29、30のそれぞれを読み取るように構成される2つのスマートカード読み取り器27、28も持つ。入力も、赤外線キーボード(図示せず)を介して受信されてもよい。加入スマートカード読み取り器28は、挿入加入カード30および条件付アクセス装置29と係合し、必要な制御ワードを多重分離装置/暗号解読器30に供給し、暗号化放送信号は暗号解読できる。デコーダは、装置30によってフィルタリングされ、多重分離される前に衛星伝送を受信し、復調する従来のチューナ31および復調器32も含む。
【0043】
デコーダ内のデータの処理は、通常、中央プロセッサ20によって処理される。中央プロセッサのソフトウェアアーキテクチャは、デコーダのハードウェア構成要素で実行される下部レベルオペレーティングシステムと対話する仮想機械に対応する。
【0044】
(伝送データのパケット構造)
次に、図3および4を参照して、送信機からデコーダに送信される放送MPEGトランスポートストリーム内のデータのパケット構造が説明される。理解されるように、この説明はMPEG規格で使用される作表フォーマットに集中するが、同じ原理は、同様に他のパケット化データストリームフォーマットに用いる。
【0045】
特に、図3を参照すると、MPEGビットストリームは、0のパケット識別(PID)を有する番組アクセステーブル(PAT)40を含む。PATは、多数の番組の番組マップテーブル(PMT)41のPIDの関連を含む。各PMTは、この番組のためのオーディオMPEGテーブル42およびビデオMPEGテーブル43のストリームのPPIDの関連を含む。ゼロのPIDを有するパケット、すなわち、番組アクセステーブル40は、全MPEGアクセスのためのエントリポイントを与える。
【0046】
アプリケーションおよびそのためのデータをダウンロードするために、2つの新しいストリーム形式が規定され、関連するPMTは、アプリケーションMPEGテーブル44(あるいはこれらの一部)およびデータMPEGテーブル45(あるいはこれらの一部)のストリームのPIDの関連も含む。実際は、実行可能なアプリケーションソフトウェアおよびこのようなソフトウェアによって処理するためのデータのための別個のストリーム形式を規定することはいくつのかの場合便利であり得るが、これは重要でない。他の実現では、データおよび実行可能なコードは、記載されるようなPMTを介してアクセスされる単一ストリームに組み立てできる。
【0047】
図4を参照すると、例えばストリーム44内のアプリケーションをダウンロードするために、アプリケーション46は、各々がMPEGテーブルによって形成されるモジュール47に分割される。これらのテーブルのいくつかは単一部分を含むが、他のものは複数の部分48によって構成されてもよい。典型的なセクション48は、1バイトのテーブルID(「TID」)50、テーブルのこのセクションのセクション番号51、このテーブルの全セクション数52および2バイトのTID拡張関連53を含むヘッダを有する。各セクションは、データ部54およびCRC55も有する。特定のテーブル47の場合、このテーブル47を構成するセクション48の全ては、同じTID50および同じTID拡張部53を有する。特定のアプリケーション46の場合、このアプリケーション46を構成するテーブルの全ては、同じTID50であるが、異なるそれぞれのTID拡張部を有する。
【0048】
各々のアプリケーション46の場合、単一MPEGテーブルは、ディレクトリテーブル56として使用される。このディレクトリテーブル56は、そのヘッダにおいて、アプリケーションを構成する他のテーブル47と同じTIDを有する。しかしながら、ディレクトリテーブルは、ID目的のためにゼロの所定のTID拡張部を有し、この事実のために単一テーブルだけはディレクトリの情報に対して必要である。他のテーブル47の全ては、通常非ゼロTID拡張部を有し、多数の関連セクション48で構成される。ディレクトリテーブルのヘッダは、ダウンロードされるアプリケーションのバージョン番号も含む。
【0049】
戻って図3を参照すると、PAT40、PMT41、およびアプリケーション・データストリーム成分44、45は、周期的に伝送される。伝送される各アプリケーションは、それぞれの所定のTIDを有する。アプリケーションをダウンロードするために、適切なTIDおよびゼロのTID拡張部を有するMPEGテーブルは、受信機/デコーダにダウンロードされる。これは、必要とされるアプリケーションのためのディレクトリテーブルである。このディレクトリのデータは、次にデコーダによって処理され、必要とされるアプリケーションを構成するテーブルのTID拡張部を決定する。その後、ディレクトリテーブルと同じTIDおよびディレクトリから決定されるTID拡張部を有するいかなる必要とされるテーブルもダウンロードできる。
【0050】
このデコーダは、そのいかなる更新のためのディレクトリテーブルも検査するように構成される。これは、例えば、30秒あるいは1分あるいは5分毎に周期的に再度ディレクトリをダウンロードし、予めダウンロードされるディレクトリテーブルのバージョン番号を比較することによって行われてもよい。新しくダウンロードされたバージョン番号が後のバージョン番号である場合、前のディレクトリテーブルに関連したテーブルは削除され、新しいバージョンに関連したテーブルは、ダウンロードされ、集められる。
【0051】
代替の装置では、入ってくるビットストリームは、アプリケーションのTID、ゼロのTID拡張部および目下ダウンロードされたディレクトリのバージョン番号よりも1つ大きいバージョン番号のためにセットされる値とともにTID、TID拡張部およびバージョン番号に対応するマスクを使用してフィルタリングされる。したがって、バージョン番号の増加が検出され、一旦検出されると、前述されるように、ディレクトリはダウンロードされ、アプリケーションは更新される。アプリケーションが終了されるべきである場合、次のバージョン番号を有する空のディレクトリは、ディレクトリに列挙された少しのモジュールもないことを除いて伝送される。このような空のディレクトリの受信に応じて、デコーダ2020は、アプリケーションを削除するようにプログラムされる。
【0052】
実際には、デコーダでアプリケーションを実行するソフトウェアおよびコンピュータプログラムは、特に前述されるような衛星リンクを介して受信されるデータストリームに、デコーダの一部のいずれかを介してであるが、直列ポート、スマートカードリンク等も介して導入されてもよい。このようなソフトウェアは、ネットブラウザ、クイズアプリケーション、番組案内等のようなデコーダ内の対話型アプリケーションを実行するために使用される高レベルアプリケーションを含んでもよい。ソフトウェアも、例えば「パッチ」等によってデコーダソフトウェアの作動構成を変えるようにダウンロードされてもよい。
【0053】
アプリケーションも、デコーダを介してダウンロードされ、デコーダに接続されたPC等に送信されてもよい。このような場合、デコーダは、最終的には接続装置で実行されるソフトウェアのための通信ルータの役目を果たす。このルーティング機能に加えて、デコーダも、PCに経路指定する前にMPEGパケット化データを例えばDSM−CCプロトコル(下記を参照)に従って構成されたコンピュータファイルソフトウェアに変換する機能を果たしてもよい。
【0054】
(データファイルのデータの構成)
図5は、DSM−CC U−U(ユーザ対ユーザ)データファイル60のセット、集められたアプリケーション46に構成され、一連のMPEGテーブル47内にカプセル化されるようなデータ間の関係を示す。この関係は国際特許出願番号第99/49614に記載されており、その内容は下記に参照される。
【0055】
伝送より前に、データファイルは、アプリケーション46に集められ、その後、MPEG圧縮器によって、前述されるようにMPEGパケットストリームに固有なヘッダ49を含み、かつテーブルID、バージョン番号等を含むMPEGテーブルあるいはモジュール47にパケット化される。理解されるように、データファイル61に構成されるデータと最終的なMPEGテーブル47との間に一定の関係が全然ない。デコーダによる受信およびフィルタリング後、パケットヘッダ49は、廃棄され、アプリケーション46は、テーブル47のペイロードから再構成される。
【0056】
データファイルのためのDSM−CCフォーマットは、特にマルチメディアネットワークで使用するために適合され、図6に示されるように、クライアントユーザ70、サーバユーザ71とネットワーク資源マネージャ72との間の通信のための一連のメッセージフォーマットおよびセッションコマンドを規定する規格である。ネットワーク資源マネージャ72は、ネットワーク内の資源の属性を管理するように作動する論理エンティティとみなされてもよい。
【0057】
クライアントとサーバとの間の通信は、一連のセッションによって作動可能な状態にされ、第1の一連のメッセージは、通信のためのクライアントおよび/またはサーバを構成するためにユーザ(クライアント70あるいはサーバ71)とネットワークマネージャ72との間で交換される。このようなメッセージは、いわゆるDSM−CC U−N(ユーザ対ネットワーク)に従ってフォーマット化される。このプロトコルのサブセットは、特にデータを放送ダウンロードするために規定された。
【0058】
一旦通信リンクが確立されると、メッセージは、DSM−CC U−Uプロトコルに従ってクライアント70とサーバ71との間でその後交換される。この種の一連のメッセージは、図5のデータファイル60に対応する。DSM−CC U−Uメッセージの場合、データは、BIOP(BroadcastInterOrbProtocol)従ってグループ化される。
【0059】
各メッセージあるいはオブジェクト61は、ヘッダ62と、サブヘッダ63と、データそのものを含むペイロード64とを含む。BIOPプロトコルに従って、ヘッダ62は、とりわけ、メッセージおよびBIOPバージョンの形式の指示を含むが、サブヘッダは、システム設計者によって規定されるオブジェクトおよび他の情報の形式を示す。
【0060】
DSM−CC U−Uファイルのペイロード内のデータオブジェクト64は、通常3つの形式、すなわちディレクトリオブジェクト、ファイルオブジェクトおよびストリームオブジェクト、の中の1つとして規定できる。ディレクトリオブジェクトは、実際のアプリケーションデータを含む一連の関連ファイルオブジェクトを関連付けるために使用されるルートディレクトリあるいはサブディレクトリを規定する。
【0061】
ストリームオブジェクトは、一時の関係がデータファイルに含まれるデータとMPEGパケットストリームそのものとの間に確立できるために使用されてもよい。これは、例えば、データファイルに含まれ、かつデコーダによって受信され、処理される基本ビデオあるいはオーディオストリームと同期されるように設計される対話形アプリケーションの場合、使用されてもよい。前述されるように、特にMPEGパケット化データとデータファイルとの間に全然直接の相関が有り得ない。
【0062】
MPEGテーブルと違って、単一ディレクトリがテーブルのセットを単一レベルの階層のみと関連付ける場合、データファイル60は、かなりより複雑な階層のように構成されてもよい。PCあるいはサーバに記憶されるファイルのように、主ディレクトリあるいはルートディレクトリは、順に第2のレベルのデータファイルを参照する1つあるいはそれ以上のサブディレクトリを参照してもよい。(データファイルのセットのためのファイル構造)
【0063】
図7を参照すると、データファイルのセットのためのファイル構造の例が示されている。75に示されるルートディレクトリDIRA0は、サブディレクトリA1のグループをオブジェクトファイル77に関連付ける。明瞭にするために、サブディレクトリA4と関連するオブジェクトファイルF1、F2等の単一グループだけが示されている。実際には、多数のオブジェクトファイルのグループは、サブディレクトリA1からA4の各々によって関連付けられてもよい。
【0064】
各々のディレクトリおよびサブディレクトリ内で、認証ステップのセットは、このディレクトリに結合されるファイルのために導入される。ルートディレクトリ75を参照すると、サブヘッダ63は、ハッシュアルゴリズムを76と示されたサブディレクトリファイルA1からA4に記憶されたデータのいくつかあるいは全てに用いることによって得られたハッシュ値を含む。使用されるハッシングは、例えば、メッセージダイジェストアルゴリズムMD5のような任意の公知の形式のものであってもよい。
【0065】
1つの実現では、このアルゴリズムは、各々の関連ファイルあるいはサブディレクトリに個別に適用され、各サブディレクトリ76のためのハッシュ値のリストは、伝送より前にルートディレクトリ75に記憶されてもよい。しかしながら、このような解決策は、各々のサブディレクトリを検証することに関する分解能をチェックする度合いの増加を可能にするが、この解決策は、対応するシグネチャを計算するためにデコーダのために必要である処理時間に関してかなり役に立たないことが有り得る。したがって、ディレクトリ79のサブヘッダ63は、好ましくは、MD5ハッシングアルゴリズムを結合されたサブヘッダおよびサブディレクトリ76のペイロード部63、64に用いることによって計算され、すなわちヘッダ62がない累積ハッシュ値79を含む。特に、サブディレクトリ76内に含まれ、ファイルオブジェクト77の層を示すハッシュ値82は、このハッシング計算に含まれる。
【0066】
図7に示されたサブディレクトリA4の場合、このサブディレクトリそれ自体は、77に示されるオブジェクトF1〜Fnのセットを示す。この場合、累積ハッシュ値82は、オブジェクトファイル77の結合内容のために生成される。この値は、ハッシュ値79を生じるハッシング処理に含まれる。したがって、順にディレクトリ75のハッシュ値79を変えるサブディレクトリ76のハッシュ値82を変えないでオブジェクトファイル77のいずれかを変えることができない。
【0067】
この場合、結合されたハッシュ値は、ディレクトリに示されたサブディレクトリの全てに対して計算される。このハッシュ値は、そこからデータがとられるサブディレクトリのグループの識別子とともに記憶される。他の実施形態では、一連の結合されるかあるいは個別のハッシュ値および対応する識別子は、ディレクトリのサブヘッダに記憶されてもよい。
【0068】
例えば、ルートディレクトリとも関連するが、異なるデータのセットあるいは実行可能なコードに関する第2のサブディレクトリのセットも、一緒にグループ化され、累積ハッシュ値は、計算され、サブヘッダルートディレクトリに記憶されたこれらのサブディレクトリのために計算されてもよい。単一ディレクトリに関連した単一ハッシュ値は、同様にルートディレクトリのサブヘッダに記憶されてもよい。
【0069】
グループあるいは個別のデータファイルの認証は、もちろん、ルートディレクトリ(あるいは、実際に任意の他のファイル)が無効あるいは未ハッシュのデータファイルも示すことを防止しなくて、このようなファイルの確認がないことは、このファイルとの任意の動作を考慮する必要がある。この点では、例えば、システムオブジェクトを認証することは必要であり得ない。
【0070】
この場合のハッシング関数の使用によって、主にデコーダは、ダウンロードデータファイルの一貫性あるいはダウンロードデータファイルを完備していることを検証できる。例えば、伝送における故障あるいは遮断の場合、受信された従属ファイルの累積ハッシングアルゴリズムの演算は、ルートディレクトリに記憶されたこれらのファイルに対するハッシュ値と同じ結果を得られる。次に、デコーダは、ダウンロードデータの可能なエラーがあることに変更され、誤ったデータファイルを再ロードする。
【0071】
(ルートディレクトリのためのシグネチャ値)
高められたセキュリティの場合、ルートディレクトリ75のためのシグネチャ値が計算される。本実施形態では、リベスト(Rivest)、シャミール(Shamir)およびアデルマン(Adleman)あるいはRSAアルゴリズムが使用され、データファイルを生成する責任を負うべき放送会社は、私用鍵値を所有し、公開鍵は、デコーダによって保持される。一方、秘密鍵は、データ暗号規格あるいはDESアルゴリズムのような対称性鍵アルゴリズムによって得られる鍵に対応し得る。
【0072】
図7に示されるように、ルートディレクトリ75は、放送会社の私用鍵を使用して生成される計算されたシグネチャ値81とともに検証工程で使用される公開鍵をデコーダのために識別する放送会社識別子80を含む。この場合、シグネチャ値81は、放送会社によって保持される私用鍵を好ましくはペイロードデータ64および/または累積ハッシュ値79を含むディレクトリ75内のデータのいくつかあるいは全てに用いることによって生成される。次に、このデコーダは、放送会社識別子80によって識別される対応する公開鍵を使用してこのシグネチャ値81を検証できる。
【0073】
本例では、ディレクトリ75のデータは、暗号化されなくて、この私用鍵は、公開鍵によって検証できるシグネチャ値を生じるために単に使用できる。代替実施形態では、ディレクトリの内容のいくつかあるいは全ては、私用鍵によって暗号化され、その後、対応する鍵によって暗号解読されてもよい。
【0074】
どちらかの場合でも、秘密鍵の使用による暗号化コードのシグネチャ値あるいはブロックの生成によって、デコーダは、ディレクトリ75の一貫性および発生源、および密接な関係によってこのルートディレクトリによって参照されるファイルの一貫性および発生源を検証できる。参照ファイルのための累積ハッシュ値は、シグネチャ81の計算に含まれるので、これが検証工程で検出されない限りこれらの値を変更できない。各ハッシュ値は通常所与のデータのセットに固有であるので、したがってその固有のハッシュ値、それによってディレクトリの生じるシグネチャ値を変えないで従属ハッシュファイルのいずれかの内容を変えることができない。
【0075】
理解されるように、多数の変更は、特に各工程でハッシュされるかあるいは署名されるデータ量を減らすことを可能にし得る。特に、下部レベルデータファイルを検証するために使用されるディレクトリあるいはサブディレクトリのシグネチャあるいはハッシュ値の場合、ディレクトリシグネチャあるいはハッシュ値は、下部レベルハッシュ値だけを使用し、他のデータだけを使用しないで生成されてもよい。
【0076】
例えば、A0ディレクトリ75の結合ハッシュ値79は、76に示されるA1―A4サブディレクトリの各々の結合ハッシュ値82、83を使用して生成されてもよい。これらの値は、丁度サブディレクトリのペイロードのデータと同様に独自であるので、結合ハッシュ値79は、なお当のサブディレクトリに固有である。さらに、ハッシュ値82はなお計算で使用されるので、オブジェクトファイルおよびディレクトリファイル77、78の下部レベルの一貫性がなお推測される。
【0077】
(放送会社デジタル認証)
図8を参照すると、公開鍵91および放送会社識別子80は、好ましくは、製造中デコーダのメモリにハードコード化される周知の国際標準化機構(ISO)X.509の形のデジタル認証でデコーダのユーザに供給される。このような認証は、通常認証局(CA)と呼ばれる信用された第三者によってデコーダの製造者に配信される。このような認証の使用は、ワールドワイドウェブ(WWW)を介するクレジットカードトランザクションを保護するネットスケープ通信によって開発され、標準化された安全ソケットレイヤー(SSL)安全トランスポートプロトコルにより主により広く受け入れるようになる。
【0078】
公開鍵91および放送会社識別子80と同様に、放送会社に関連したデジタル認証あるいは放送会社認証90は、放送会社認証90のバージョン番号92;
放送会社認証90の連続番号93;
放送会社認証90を配信したCAのCAID94;
認証が使用されることを意図されている時間の開始および終了を示す放送会社認証90の有効期間95;および放送会社認証90のシグネチャ値96も含む。
【0079】
前述から分かるように、放送会社認証は、2つの異なる識別子、すなわち認証の分配者のID94に対応する第1の「発行者名」識別子および公開鍵91を識別する識別子80に対応する第2の「主題名」識別子を含む。
【0080】
CAは、CAの私用鍵、あるいはCA私用鍵を放送会社認証内のデータの少なくともいくつかあるいは全てに用いることによって放送会社認証90のシグネチャ値96を計算する。次に、デコーダは、CAID94によって識別される対応するCA公開鍵101を使用してシグネチャを処理することによってこのシグネチャ値96を検証し、認証の内容がCAによってシグネチャに続いて修正されなかったことを決定する。
デコーダは、異なるそれぞれの放送会社に対する複数のこのような認証を記憶してもよい。
【0081】
(認証局デジタル認証)
さらに図8を参照すると、対応するCA公開鍵101およびCA識別子94は、製造中デコーダでもハードコード化されるCA認証100のデコーダのユーザに供給される。CA認証100は、CA認証100のバージョン番号102;
【0082】
CA認証100の連続番号103;
CA認証100を配信した欧州電気通信標準化機構(ETSI)のようなルート認証局(RCA)のRCAID104;
CA認証100の妥当性期間105;および・CA認証100のシグネチャ値106も含む。
【0083】
前述から分かるように、CA認証は、2つの異なる識別子、すなわち認証の分配者のID104に対応する第1の「発行者名」識別子および公開鍵101を識別する識別子94に対応する第2の「主題名」識別子を含む。
【0084】
RCAは、RCAの私用鍵、あるいはRCA私用鍵をCA認証内のデータの少なくともいくつかあるいは全てに用いることによってCA認証100のシグネチャ値106を計算する。次に、デコーダは、RCAID104によって識別される対応するRCA公開鍵111を使用して認証を処理することによってこのシグネチャ値96を検証し、認証の内容がRCAによってシグネチャに続いて修正されなかったことを決定する。
【0085】
デコーダは、異なるそれぞれのCAに対する複数のこのような認証を記憶してもよい。
対応するRCA公開鍵111およびRCA識別子104は、製造中デコーダのメモリでもハードコード化されるRCAあるいはルート認証110のユーザに供給される。各デコーダは、一般的には2つあるいはそれ以上のルート認証のセットを含む。各ルート認証110は、ルート認証110のバージョン番号112;
【0086】
ルート認証110の連続番号113;
ルート認証110の妥当性期間114;およびルート認証110のシグネチャ値115も含む。
前述から分かるように、ルート認証は、単一識別子、すなわち認証の配信者のID104だけを含む。このID104は公開鍵111も含む。したがって、ルート認証は、発行者名が主題名と同じである認証として規定されてもよい。
【0087】
ルート認証は、放送会社認証90−CA認証100−ルート認証110の連鎖の最終認証であるので、ルート認証は、自動署名され、すなわち、シグネチャ値は、公開鍵111と等価の私用鍵を使用して計算される。したがって、ルート認証の内容が公に利用できるようにならないことに関心がある。
【0088】
もちろん、RCAは、放送会社認証をデコーダの製造者に直接供給することができ、その場合、放送会社認証は、RCA識別子111を含み、RCA私用鍵を使用して署名される。
【0089】
(認証取り消しリスト)
放送会社認証90およびCAのいずれかは、例えば認証に記憶された公開鍵に対応する私用鍵が危険にさらされるようになる場合、それで指定された妥当性期間の満了より前に例えば削除によって取り消されてもよい。このような取り消しは、取り消される認証の連続番号92、102のリストを含む認証取り消しリスト(CRL)のデコーダへの伝送によって行うことができる。取り消しの際に、認証は、好ましくは、デコーダのメモリからの認証の削除によって実行できないようになり、それによって危険にさらされた私用鍵を使用して署名される任意の不許可の可能性のある悪意のあるデータパケットのダウンロードを防止する。
【0090】
CRLは、モデム逆方向チャネル17あるいはCRLを放送することによるMPEGトランスポートストリームのいずれかに介してCRLをデコーダに伝送する放送会社にCAあるいはRCAのいずれかによって配信される。放送会社が、CRLを送信機からデコーダに送信されるトランスポートストリームの全てに挿入することは重要でない。CRLをデコーダによって同調されるのに非常に可能性があるトランスポートストリームに挿入することは放送会社にとって十分なことである。例えば、CRLは、データファイルとして送信機からデコーダへ放送されるデータファイルのセットのルートディレクトリ75あるいはサブディレクトリ76に挿入されてもよい。
【0091】
図9を参照すると、CRL120は、一般的には、
CRL120を配信したCAあるいはRCAのID94あるいは104;
CRL120が出された日付122;
次のCRLが出されることが予想される日付124;
【0092】
各々の取り消された認証に対して、この認証の取り消しの時間および日付を含む、取り消された認証の連続番号のリスト125;および・CRL120を配信したCAあるいはRCAの私用鍵を使用して計算されたCRLのシグネチャ値126を含む。
【0093】
CRLの受信の際に、デコーダは、予め受信されたCRLによって通知されるように、CRL120が発行された日付122を、CRL120が予想される日付124と比較する。新しく受信されたCRLの日付122がCRLが予想される日付124よりも後でない場合、CRLは無視される。
【0094】
新しく受信されたCRLの日付122がCRLが予想される日付124よりも後である場合、CRLのシグネチャは、CRLに含まれるID94あるいは104を使用して識別されるように、CAの発行者の公開鍵を使用して検証される。
【0095】
CRLの一貫性がそのように検証される場合、CRLは、次のCRLが出されることが予想される日付124を固定メモリに記憶し、取り消された認証の連続番号のリスト125を記憶するように日付124を加えるために処理される。取り消された認証の受信リスト125は、デコーダの固定メモリにも記憶される。性能の理由のために、CRL120がデコーダのメモリにキャッシュされるのが好ましい。デコーダのキャッシュメモリがCRL120を樹枝状に記憶することも好ましく、RCAのCRLは、「ツリー」の上部およびこのRCAがツリーの底部にある認証を配信するCAのCRLにある。
【0096】
放送会社90の取り消しの場合、例えば、放送会社の私用鍵が危険にさらされるようになる場合、この放送会社に対する認証局は、放送会社認証90の連続番号93をそのCRL120に加える。認証局は、その後新しいCRL120を放送するための放送会社認証90を配信する放送会社の全てに配信する。デコーダが新しいCRL120をダウンロードするや否や、例えば、放送会社のチャネルで早送りする際に、CRLキャッシュは、更新され、CRL120のリスト125でそのように識別されたいかなる認証の取り消しも行われる。
【0097】
交換放送会社認証90は、認証局によって生成され、ファイルのディレクトリ75あるいは76のユーザに放送する。交換放送会社認証は、とりわけ、新しい公開鍵91と、更新バージョン番号92と、更新妥当性期間95と、CAの私用鍵を使用して計算された新しいシグネチャ値96とを含む。放送会社識別子80およびCA識別子94は変更されないままである。交換放送会社認証90の受信際に、デコーダは、CAID94によって識別されたCA認証に含まれる対応するCA公開鍵を使用して認証を処理することによって認証を検証する。
【0098】
CA認証100の取り消しの際に、このCAのCRLは、デコーダのメモリから取り除かれる。したがって、例えば、このCAのCRLのサイズがデコーダのキャッシュメモリに記憶するためにあまりに大きくなる場合、CA認証100を任意に取り消すことは望ましいことで有り得る。この場合、CA認証100をこのCAに配信するRCAは、このCA認証100の連続番号をそのCRLに追加する。ルート認証局は、その後、RCAがCA認証を配信するCAが放送するための放送会社認証を順に配信する放送会社の全てに新しいCRLを配信する。デコーダが新しいCRLをダウンロードするや否や、例えば、放送会社のチャネルで早送りする際に、CRLキャッシュは更新され、CRL120のリスト125にそのように識別されたCA認証の取り消しが行われる。
【0099】
認証局のCA認証100の取り消しの際に、デコーダへのこの認証局のための新しいCA認証の記憶に加えて、この認証局のための私用鍵対はもはや有効でないので、認証局の異なるかあるいは更新私用鍵を使用して署名された新しい放送会社認証90が必要とされるためにこの認証局が認証を配信する放送会社の全てのための放送会社認証90を交換する必要がある。交換CA認証100は、ルート認証局110によって生成され、ファイルのディレクトリ75あるいは76のユーザに放送される。交換放送会社認証と同様に、交換CA認証は、とりわけ、新しいCA公開鍵101と、更新バージョン番号102と、更新妥当性期間105と、RCAの私用鍵を使用して計算された新しいシグネチャ値106とを含む。CA識別子94およびRCA識別子104は変更されないままである。交換CA認証100の受信の際に、デコーダは、RCAID104によって識別されたRCA認証100に含まれる対応するRCA公開鍵を使用して認証を処理することによって認証を検証する。
【0100】
(ルート認証管理メッセージ)
ルート認証局のRCA認証110の取り消しの際に、取り消されたRCA認証を新しいRCAと交換する必要がある。前述されるように、RCA認証は自動署名されるので、CRLへRCA認証を含めることは、ハッカーがCRLを署名するために使用される私用鍵を知っている場合、ハッカーは認証を持つことができるので望ましくない。したがって、例えば、RCA認証が旧式になったかあるいは取り消されるようになった場合、これまでRCA認証が更新されるべきである度にデコーダを製造者に戻すことが必要であった。
【0101】
この問題を解決するために、ルート認証管理メッセージ(RCMM)は、放送会社によってデコーダに放送するためにルート認証局によって生成される。下記により詳細に説明されるように、CRLと同様に、RCMMは、旧式になったかあるいはリスト125に識別されたこれらの認証のための1つあるいはそれ以上の交換ルート認証とともに、各々の取り消されたルート認証に対してこの認証の取り消しのための時間および日付を含む、取り消されるルート認証の連続番号のリスト125を含む。
【0102】
理解されるように、RCMMの秘密にかかわる内容(新しいルート認証)に関して、放送会社に「出されるような」デコーダによって受信されることを保証すること、すなわちRCMMの内容が配信と受信との間で交換されないことを保証することは、重要である。RCMMが、RCMMがアドレスされる誰かにデコーダによってだけアクセスできることを保証することも重要である。
【0103】
セキュリティを高めるために、CRLと違って、RCMMは、その中に含まれるデータの少なくともいくつか、好ましくは全てに対する少なくとも2つのシグネチャ値を含む。各々のシグネチャ値は、公開鍵/私用鍵対の私用鍵のようなそれぞれの暗号化アルゴリズムの鍵を使用して計算される。
【0104】
RCMMがルート認証局(RCA)によって出され、新しいルート認証110を含む場合、RCMMは、少なくとも2つのシグネチャ値を含む。各々のシグネチャ値は、例えば、RCAが認証を供給する認証局のそれぞれの私用鍵を使用して計算される(ただし、デコーダが等しい鍵を記憶するいかなる鍵も選択されてもよい)。これらの認証局の中の1つに未知であり、その私用鍵が危険にさらされるようになる場合、「ハッカー」は放送会社の放送を遮断することが可能であり得る、ハッカーが放送会社および認証局の両方の私用鍵を知っている場合、ハッカーは、RCMMの内容および認証局の私用鍵を使用して計算されたRCMMのシグネチャ値を変える。しかしながら、この鍵は危険にさらされているようにならないために、ハッカーは、他の認証局の私用鍵を使用して計算されたシグネチャ値を変えることができない。したがって、2つの認証局の公開鍵を使用してデコーダによるシグネチャの検証の際に、それぞれの公開鍵を使用してデコーダによって計算された2つの値は同じでない。したがって、デコーダは、RCMMの内容の一貫性の欠如のために変えられ、RCMMの処理を拒否し、またはその他RCMMの処理を続けない。
【0105】
したがって、もし危険にさらされた認証数がRCMMに含まれたシグネチャ数よりも小さいとすれば、ルート認証は安全に更新できる。したがって、RCMMのシグネチャ数は、RCMMを配信するルート認証局によって決定された変数である。
次に、RCMMのフォーマットは、図を参照してより詳細に示されている。
【0106】
RCMM130は、RCMM130を配信したRCAの一貫性132;
RCMM130が発行した日付134;
その後のRCMMが含むシグネチャ値の数136;
1つあるいはそれ以上の更新されるかあるいはデコーダに記憶される交換ルート認証を含むフィールド138;
【0107】
各々の取り消されたルート認証に対してこの認証の取り消しの時間および日付を含む、取り消されたルート認証の連続番号のリスト140;および各々が、このシグネチャフィールドに含まれたシグネチャ値を検証するために使用される公開鍵を含む、デコーダに記憶された認証の識別子144;および識別子144によって識別される認証に含まれる公開鍵に等しい私用鍵を使用して計算されたRCMMのシグネチャ値146を含む少なくとも2つのシグネチャフィールド142を含む。
【0108】
シグネチャフィールド数142は、予め受信されたRCMMに通知されるようなシグネチャフィールド数136に等しいかあるいはそれよりも大となるべきである。
モデム逆方向チャネルは容易に切り離してもよいしあるいは単に存在しなくてもよいので、RCMMはMPEGトランスポートストリームを介して伝送されることが好ましい。RCMMが、デコーダによってダウンロードされることを保証するために放送会社によってデータファイルとしてルートディレクトリ75に挿入されることも好ましい。
【0109】
(ルート認証管理メッセージの処理および生成)
次に、デコーダによるRCMMの受信および処理は、図11を参照して説明される。
RCMMの受信の際に、ステップ200では、デコーダは、予めRCMMを出されたRCMM130が出された日付134を比較する。新しい受信されたRCMMの日付134が前のRCMMが出された日付よりも後でない場合、RCMMは拒否される。
【0110】
新しく受信されたRCMMの日付134が前のRCMMの受信の日付よりも後である場合、予め受信されたRCMMによって通知されるように、新しく受信されたRCMMが含むべきであるシグネチャ値の数136は、ステップ202で新しく受信されたRCMMで実際に含まれたシグネチャ値の数と比較される。新しく受信されたRCMMに含まれたシグネチャの数が予想よりも低い場合、RCMMが拒否される。これは、RCMMが危険にさらされていない私用鍵/公開鍵対に関連したシグネチャを取り除くハッカーの結果として特に処理されることを防止する。
【0111】
新しく受信されたRCMMに含まれたシグネチャの数が予想されたシグネチャの数に等しいかあるいはそれよりも大きい場合、ステップ204で、RCMMに含まれた各々のシグネチャ値146は、このシグネチャ値と同じシグネチャフィールド142に含まれる識別子144によって識別された公開鍵を使用して検証される。ステップ206では、デコーダは、公開鍵を使用して計算された値の少なくとも1つが異なる公開鍵を使用して計算された他の値のいずれかと異なるかどうかを決定する。少なくとも1つの計算された値が他の計算された値の少なくとも1つと異なる場合、RCMMは拒否される。
【0112】
RCMMの一貫性がステップ206で証明される場合、RCMMは、ステップ208で処理され、デコーダの固定メモリに取り消されたルート認証の連続番号のリスト140を記憶するので、これらの認証は、ステップ212で、デコーダのメモリから削除され、フィールド138に含まれたルート認証あるいは各ルート認証をデコーダの固定メモリに記憶し、ステップ212でRCMMの日付134を固定メモリに記憶してもよい。ルート認証局の認証が削除される場合、この局によって出される任意のCRLも削除される。
【0113】
RCMMに含まれたデータの固定メモリの一貫性が、デコーダがRCMMメッセージの処理中スイッチオフされる場合、保持されることが好ましい。したがって、電力が実際にRCMM処理中スイッチオフされる場合、デコーダに記憶される予め処理されたRCMMに関連したリスト140は、あたかも新しく受信されたRCMMメッセージが全然処理されなかったかのように保持される。
【0114】
前述されるように、ルート認証局(RCA)は、一般的には各デコーダに記憶された少なくとも2つのRCA認証、すなわちRC0およびRC1を有する。これらの認証の1つ、例えばRC0が危険にさらされるようになる場合、RC0に記憶された公開鍵の等価私用鍵を使用して署名されたデコーダに記憶された全CA認証を交換し、新しいRCA認証RC2を生成し、RC0を交換する必要がある。
【0115】
図12を参照すると、これらのCA認証を交換するために、最初にステップ300では取り消されるCA認証の連続番号を識別する適切なCRLメッセージがRCAによって出される。第二に、ステップ302では、危険にさらされていない認証RC1の私用鍵を使用して署名され交換CA認証は、デコーダに放送するために放送会社に出される。
【0116】
次に、交換CA認証は、危険にさらされたRCA認証RC0を削除し、この認証を新しいRCA認証RC2と交換するままである。ステップ304では、RCAは、新しい公開鍵/私用鍵対を生成し、認証RC2に新しい公開鍵を挿入し、新しい私用鍵を使用して認証を署名する。
【0117】
ステップ306では、RCAは、フィールド138では、認証RC2およびリスト140ではRC0の連続番号を含むRCMMを生成する。このRCMMは、ステップ308では、デコーダに伝送するために放送会社に配信され、危険にさらされた認証RC0を削除し、これを新しい認証RC2と交換する。
【0118】
RCA認証RC1およびRC2は、その後新しいデコーダのメモリにハードコーディングするためにデコーダ製造者に供給される。
本発明は例として単に前述去れ、詳細の修正は本発明の範囲内に行うことができることが分かる。
【0119】
例えば、RCMMは、新しいRCA認証110に加えて、新しいCA認証100および/または新しい放送会社認証90を含んでもよく、リスト140は、CA認証および/または取り消されるべきである放送会社認証の識別子を含んでもよい。これは、RCAによる別個のCRLメッセージの生成が不要にされることを可能にすることができる。
説明で開示された各々の特徴、および(適切である場合)特許請求の範囲および図面は、独立してあるいは任意の適切な組み合わせで提供されてもよい。
【図面の簡単な説明】
【0120】
【図1】図1は本発明と併用するためのデジタルテレビシステムの概略図を示す。
【図2】図2は図1のシステムのデコーダの構成を示す。
【図3】図3はMPEG放送トランスポートシステム内の多数の構成要素の構成を示す。
【図4】図4は多数のMPEGテーブルへのソフトウェアアプリケーションの分割を示す。
【図5】図5はDES−CCデータファイルと最終的に発生されたMPEGテーブルとの関係を示す。
【図6】図6はDES−CCの前後関係で規定されるようなクライアント、サーバ、ネットワークマネージャ関係を示す。
【図7】図7は認証ディレクトリ、サブディレクトリおよびファイルオブジェクトを示す。
【図8】図8は放送認証、認証局認証およびルート認証局認証のフォーマットを示す。
【図9】図9は認証取消リストのフォーマットを示す。
【図10】図10はルート認証管理メッセージ(RCMM)のフォーマットを示す。
【図11】図11はデコーダによる受信の際にRCMMの処理に含まれるステップを示す。
【図12】図12は本発明の動作を説明するフローチャートである。
【符号の説明】
【0121】
1 デジタルテレビシステム
2 従来のデジタルテレビシステム
3 圧縮器
4 スクランブラ、マルチプレクサ
5 リンク装置
6 送信機
7 リンク結合装置
8 アップリンク
9 衛星トランスポンダ
10 ダウンリンク
12 受信機
13 統合受信機/デコーダ
14 テレビ受像機
15 条件付きアクセスシステム
16 対話システム
17 モデム逆方向チャネル
【技術分野】
【0001】
本発明は、デジタル伝送システムで伝送されるデータの認証及び証明の方法及びその装置に関するものである。
【背景技術】
【0002】
デジタルデータの同報伝送は、スクランブルオーディオビジュアル情報が、通常衛星あるいは衛星/ケーブルリンクによって各々がその後見るための伝送番組を暗号解読できるデコーダを所有する多数の加入者に送信されるペイTVシステムの分野で周知である。地上デジタル放送システムも公知である。最近のシステムは、視聴覚データに加えてあるいは視聴覚データと同様に、デコーダあるいは接続PCのためのコンピュータプログラムあるいは対話型アプリケーションのような他のデータを伝送する放送リンクも使用した。
【0003】
アプリケーションの伝送に関する特定の問題は、いかなるこのようなデータの一貫性および発生源も検証する必要性にある。この種のデータは、いかなる対話型アプリケーション数も実行するのと同様にデコーダを再構成するために使用されてもよいので、受信データは完全であり、かつ公知の発生源から発生するものとして識別されることの両方であることが重要である。特に、不完全なデータのダウンロードに関係付けられる操作上の問題が、デコーダが第三者等による攻撃を受けやすいようになる危険と同様に生じ得る。
【0004】
このようなデータの一貫性を検証することは、デコーダによって直接受信されたデータのパケットストリームの検証によって行われてもよい。伝送より前に、パケットは、一般的にはハッシングアルゴリズムをパケットのデータの少なくともいくつかに用いることによって署名される。生じるハッシュ値はパケットに記憶される。データパケットの受信の際に、デコーダは、同じハッシングアルゴリズムをデータに用い、受信データの一貫性を検証するためにデコーダによって計算されたハッシュ値を受信パケットに記憶されたハッシュ値と比較する。例えば、伝送の故障あるいは遮断の場合、計算ハッシュ値は、受信ハッシュ値と同じでない。次に、デコーダは、ダウンロードデータパケットの可能なエラーの存在のために変更され、間違ったデータパケットを再ロードする。
【0005】
メッセージダイジェストアルゴリズムMD5のような周知のハッシングアルゴリズムの使用に関連した問題は、ハッシュ値の計算が公に公知の一連の計算ステップに従って実行されるということであり、その結果、誰でもデータパケットのハッシュ値を計算できる。
【0006】
従って、デコーダによって受信されたデータパケットの発生源を検証できる。受信データがデコーダの演算データファイルを修正する場合、このことは特に重要であり得る。
【発明の開示】
【発明が解決しようとする課題】
【0007】
この問題を解決するために、データの少なくともいくつかに対するハッシュ値を計算するハッシングアルゴリズムを使用する代わりに、データパケットのシグネチャ値は、放送者にだけ公知である秘密鍵値を使用して計算されてもよい。この鍵は、データ暗号化規格、すなわちDESのアルゴリズムのような対称性鍵アルゴリズムを等価鍵を記憶するデコーダとともに使用して得ることができる。しかしながら、より便利なことは、公開鍵および私用鍵が数式の補数部を形成する、リベスト(Rivest)、シャミール(Shamir)およびアデルマン(Adleman)、あるいはRSAのアルゴリズムのような非対称性公開/私用鍵アルゴリズムを使用することによってもたらすことができることである。
【0008】
データパケットを生成する責任のある放送者は、私用鍵を記憶し、私用鍵を使用してシグネチャ値を計算する。この公開鍵は、製造中公開鍵をデコーダメモリへハードコーディングすることによってデータを受信すべきであるデコーダに記憶される。データパケットの受信の際に、デコーダは、受信データを公開鍵アルゴリズムを受信シグネチャ値に用いる結果と比較することによって記憶された公開鍵を使用してシグネチャ値を検証する。
【0009】
このような安全システムにおいてさえ、私用鍵の値は、例えば不法に公然と配信することによって危険にさらされ得る。このような場合、放送者は、データパケットの無許可受信を防止するために等しい公開鍵の使用を迅速に取り消すことが必要になる。さらに、新しい公開/私用鍵対が使用されることも必要になる。したがって、放送会社は、合法ユーザのデコーダに記憶された公開鍵を新しい公開鍵と交換する必要がある。公開鍵の感度に応じて、このことは、放送者がこれらのデコーダのメモリへの新しい公開鍵のハードコーディングするために製造者へのこれらのデコーダの高価で、煩わしい返却を計画することを必要とし得る。
【課題を解決するための手段】
【0010】
本発明の目的は、これらの問題および他の問題を解決しようとするものである。
本発明の第1の態様は、デジタル伝送システムで伝送されるデータを認証する方法を提供し、前記方法は、伝送より前に、データの少なくともいくつかに対する少なくとも2つの暗号化値を決定するステップであって、各暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して同じデータに対して決定されることと、前記少なくとも2つの暗号化値を前記データとともに出力するステップとを含む。
【0011】
本発明は、データが「出されるように」受信されることを保証するために新しい暗号化アルゴリズムで使用される鍵のような影響されやすいデータを安全に更新することが望ましい状態に特に応用できるが、これに限定されない。このようなセキュリティを行うために、データの少なくともいくつか、好ましくは多数、より好ましくは全てに対する少なくとも2つの暗号化値が決定される。各々の暗号化値は、それぞれの暗号化アルゴリズムの鍵を使用して決定される。鍵の1つが危険にさらされるようになった場合、「ハッカー」は、データを遮断し、データおよび危険にさらされた鍵を使用して計算された暗号化値の内容を変更でき得る。暗号化値を計算するために使用される鍵と等しい鍵を使用する暗号化値の検証の際に、データが破損されるようになったことを示す、等価鍵を使用する2つの値は同じでない。
データおよび暗号化値は、好ましくは受信機/デコーダに伝送するために出力される。
【0012】
好ましくは、前記データおよび前記暗号化値は、受信機/デコーダによって受信され、この受信機/デコーダで、各暗号化値は、前記それぞれの暗号化アルゴリズムの鍵を使用して処理され、各々のその後に生じる値は、データの前記少なくともいくつかと比較され、データの前記少なくともいくつかを認証する。このデータが破損されるようになった場合、受信機/デコーダは、データを無視するように選択できるので、危険にさらされるかあるいは破損された新しい鍵は、デコーダのメモリに記憶されない。好ましくは、その後に生じる値の少なくとも1つがデータの前記少なくともいくつかとは異なる場合、前記受信データは、受信機/デコーダによって拒否される。
【発明を実施するための最良の形態】
【0013】
したがって、本発明は、デジタル伝送システムで伝送されるデータを認証する方法に及び、前記方法は、前記データおよびデータの少なくともいくつかに対して決定された少なくとも2つの暗号化値を受信するステップであって、各々の暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して決定されることと、複数の鍵を記憶するステップと、それぞれの暗号化アルゴリズムの記憶された鍵を使用して各々の暗号化値を処理するステップと、各々のその後に生じる値をデータの前記少なくともいくつかと比較し、データの前記少なくともいくつかを認証するステップとを含む。
【0014】
好ましくは、各アルゴリズムは非対称である。好ましい実施形態では各々の暗号化値は暗号化アルゴリズムの私用鍵で計算されたデジタルシグネチャにそれぞれ対応し、各シグネチャは前記暗号化アルゴリズムの公開鍵を使用し処理しうる。
【0015】
好ましくは、この方法は、各々のシグネチャとともに、このシグネチャを処理するために使用される公開鍵の識別子を出力するステップを含む。これによって、受信機/デコーダは、このシグネチャを検証するために使用される鍵を容易に識別することを可能にできる。
【0016】
好ましくは、このデータは鍵を含む。好ましい実施形態では、データは、データを処理するための暗号化アルゴリズムの公開鍵を含む少なくとも1つのデジタル認証、好ましくは少なくとも1つのデジタルルート認証を含む。この少なくとも1つのデジタル認証は、この認証に含まれる公開鍵の暗号化アルゴリズムの私用鍵を使用して計算されたデジタルシグネチャを含んでもよい。したがって、デジタル認証は、デコーダのメモリの新しい認証のハードコーディングのために製造者に戻されねばならないデコーダなしにデコーダに安全に伝送できる。
【0017】
好ましくは、前記データは、取り消された公開鍵の識別子を含む。この識別子は、前記取り消された公開鍵を含む、デジタル認証、好ましくはデジタルルート認証の識別子を含んでもよい。このデータは、複数の前記識別子を含んでもよく、各々の識別子は、それぞれの取り消された公開鍵を識別する。したがって、取り消された鍵の識別子のリストは、デコーダに安全に伝送できる。
【0018】
前記の方法によって、危険にさらされた鍵の数がデータとともに記憶される暗号化値の数よりも小さいとすれば、データは安全に更新できる。したがって、前記データおよび前記少なくとも2つの暗号化値は、その後に生成されたデータファイルに記憶される暗号化値の最小数の指示を含んでもよいデータファイルに構成されてもよい。鍵が危険にさらされたようになるべきであるので、暗号化値の最小数が危険にさらされた鍵の数よりも大きいままである場合、これによって、暗号化値の最小数は、変更でき、例えば増加できる。
【0019】
好ましくは、前記データファイルに記憶された暗号化値の数を前記最小数と比較し、前記データファイルに記憶された暗号化値の数が前記最小数よりも小さい場合、前記データファイルを拒否する受信機/デコーダによって受信される。
【0020】
このデータファイルはデータモジュールに伝送されてもよい。前記モジュールのデータの少なくともいくつかに対するモジュール暗号化値は、送信機暗号化アルゴリズムの鍵を使用して計算し、前記データモジュールに記憶できる。このデータモジュールは、送信機暗号化アルゴリズムの鍵を使用して前記モジュール暗号化値を処理し、その後に生じる値を前記モジュールのデータの前記少なくともいくつかと比較し、前記モジュールのデータの前記少なくともいくつかを認証する受信機/デコーダによって受信されてもよい。
【0021】
前記モジュールのデータの少なくともいくつかに対する暗号化値は、送信機暗号化アルゴリズムの私用鍵を使用して計算され、前記送信機暗号化アルゴリズムの公開鍵を使用して処理可能であるデジタルシグネチャに対応し得る。
デジタル伝送システムは、テレビあるいはオーディオシステムのようなデジタル放送システムであってもよい。
【0022】
本発明は、デジタル伝送システムで伝送されるデータを認証する装置も提供し、前記装置は、データの少なくともいくつかに対する少なくとも2つの暗号化値を決定する手段であって、各々の暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して同じデータに決定されることと、前記データとともに前記少なくとも2つの暗号化値を出力する手段とを備えている。
【0023】
本発明は、デジタル伝送システムで伝送されるデータを認証するシステムも提供し、前記システムは前述されるような装置を含む。このシステムは、好ましくは、前記データおよび前記暗号化値を受信する手段と、前記それぞれの暗号化アルゴリズムの鍵を使用して各々の暗号化値を処理する手段と、各々のその後に生じる値をデータの前記少なくともいくつかと比較し、データの前記少なくともいくつかを認証する手段とを含む受信機/デコーダをさらに含む。
【0024】
本発明は、データおよびデータの少なくともいくつかに対して決定される少なくとも2つの暗号化値を含むデータファイルを受信する手段であって、各々の暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して決定されることと、複数の鍵を記憶する手段と、前記それぞれの暗号化アルゴリズムの記憶された鍵を使用して各々の暗号化値を処理する手段と、各々のその後に生じる値をデータの前記少なくともいくつかと比較し、データの前記少なくともいくつかを認証する手段とを含む受信機/デコーダに及ぶ。
【0025】
本発明は、デジタル伝送システムで伝送されるデータを認証するシステムにも及び、前記システムは、前述されたような装置および前述されたような受信機/デコーダを含む。
【0026】
本発明は、さらにデータおよびデータの少なくともいくつかに対して決定された少なくとも2つの暗号化値を含む信号に及び、各々の暗号化値は、それぞれの暗号化アルゴリズムの鍵を使用して決定される。
本発明は、さらに実質的に添付図面を参照してここに説明されるようなデータを認証する方法、あるいは装置、受信機/デコーダ、あるいは信号に及ぶ。
【0027】
ここで使用される用語「受信機/デコーダ」あるいは「デコーダ」は、いくつかの他の手段によって放送されてもよいしあるいは伝送されてもよい、符号化信号あるいは非符号化信号のいずれか、例えばテレビおよび/またはラジオ信号を受信する受信機を意味してもよい。この用語は、受信信号を復号化するデコーダも意味してもよい。このような受信機/デコーダの実施形態は、例えば、物理的に別個の受信機との組み合わせで機能を果たすデコーダ、あるいはウェブブラウザのようなあるいはビデオレコーダあるいはテレビのような他の装置と一体化された付加機能を含むデコーダのような「セットトップボックス」で受信信号を復号化する受信機と一体であるデコーダを含んでもよい。
【0028】
ここで使用されるように、用語「デジタル伝送システム」は、例えば、主に視聴覚データあるいはマルチメディアデータを伝送あるいは放送するいかなる伝送システムも含む。
本発明は、放送デジタルテレビシステムに特に用いることができるが、本発明は、マルチメディアインターネット用途のための固定電気通信網、閉回路テレビ等にも応用できてもよい。
【0029】
ここで使用されるように、用語「デジタルテレビシステム」は、例えば、任意の衛星システム、地上システム、ケーブルシステムおよび他のシステムを含む。
本発明で使用し、私用/公開鍵を生成するための適当なアルゴリズムは、RSA、フィアット−シャミール、あるいはディフィ−ヘルマンを含んでもよく、適当な対称鍵アルゴリズムは、例えばDES形アルゴリズムを含んでもよい。しかしながら、前後関係を考慮して不可欠でない限りあるいは別段の指定がない限り、対称アルゴリズムに関連した鍵と公開/私用アルゴリズムに関連した鍵との間の一般的な区別は全然行われない。
【0030】
用語「スクランブル」および「暗号化」および「制御ワード」および「鍵」は、用語を明瞭にするためにテキストのいろいろな部分で使用された。しかしながら、「スクランブルデータ」と「暗号化データ」、「制御ワード」と「鍵」との基本的区別は、全然行われるべきでないことが分かる。
【0031】
さらに、用語「暗号化」および「署名」や「暗号解読」および「検証」は、用語を明瞭にするためにテキストのいろいろな部分で使用された。しかしながら、「暗号化データ」と「署名データ」および「暗号解読データ」および「検証データ」との基本的区別は、全然行われるべきでないことが分かる。
【0032】
同様に、用語「等価鍵」は、第1の記載された鍵によって暗号化されたデータを暗号解読、あるいはその逆をするために構成された鍵を示すために使用される。
本発明の方法態様に関連する前述の機能は、装置態様にも応用でき、あるいはその逆でも用いることができる。
【0033】
次に、添付図面を参照して本発明の好ましい実施形態だけが例として説明される。
本発明によるデジタルテレビシステム1の概略1は、図1に示される。本発明は、圧縮デジタル信号を伝送するために公知のMPEG−2圧縮システムを使用する多くの従来のデジタルテレビシステム2を含む。より詳細には、放送局のMPEG−2圧縮器3は、デジタル信号ストリーム(一般的には、ビデオ信号のストリーム)を受信する。この圧縮器3は、リンク装置5によってマルチプレクサおよびスクランブラ4に接続される。
【0034】
マルチプレクサ4は、複数の他の入力信号を受信し、トランスポートストリームを組み立て、もちろん通信リンクを含むいろいろの形をとることができるリンク結合装置7を介して圧縮デジタル信号を放送局の送信機6に送信する。送信機6は、アップリンク8を介して電磁信号を電子的に処理される衛星トランスポンダ9の方へ送信し、概念上のダウンリンク10を介して従来はエンドユーザによって所有されるかあるいは賃貸される皿の形の地上受信機12に放送する。受信機12によって受信された信号は、ユーザエンドによって所有されるかあるいは賃貸され、エンドユーザのテレビ受像機14に接続された統合受信機/デコーダ13に送信される。この受信機/デコーダ13は、圧縮MPEG−2信号をテレビ受像機14のためのテレビ信号に復号化する。
【0035】
地上放送、ケーブル伝送、結合衛星/ケーブルリンク、電話網等のようなデータの伝送のための他のトランスポートチャネルは、もちろん可能である。
【0036】
マルチチャネルシステムでは、マルチプレクサ4は、多数の並列発生源から受信されたオーディオおよびビデオ情報を処理し、送信機6と対話し、対応するチャネル数に沿って情報を放送する。オーディオビジュアル情報に加えて、デジタルデータのメッセージあるいはアプリケーションもしくは任意の他の種類のデジタルデータは、送信されたデジタルオーディオおよびビデオ情報とインタレースされたこれらのチャネルのいくつかあるいは全部に導入される。このような場合、例えば、DSM−CC(デジタル記憶メディアコマンドおよびコントロール)フォーマットソフトウェアファイルおよびメッセージの形のデジタルデータのストリームは、圧縮器3によってMPEGフォーマットに圧縮され、パケット化される。ソフトウェアモジュールのダウンロードは、下記により詳細に説明される。
【0037】
条件付アクセスシステム15は、マルチプレクサ4および受信機/デコーダ13に接続され、一部が放送局にあり、一部がデコーダにある。このシステムによって、エンドユーザは、1つあるいはそれ以上の放送供給者からデジタルテレビ放送にアクセスできる。市販の売り物(すなわち、放送供給者によって宣伝された1つあるいはいくつかのテレビ番組)に関するメッセージを解読できるスマートカードは、受信機/デコーダ13に挿入できる。デコーダ13およびスマートカードを使用すると、エンドユーザは、加入モードあるいはペイ・パー・ビューモードのいずれかで市販の売り物を購入できる。実際には、デコーダは、例えば同時暗号あるいは複数暗号設計の多重アクセス制御システムを処理するように構成されてもよい。
【0038】
前述されたように、システムによって放送された番組は、マルチプレクサ4でスクランブルされ、所与の伝送に加えられる条件および暗号化鍵は、アクセス制御システム15によって決定される。このようにスクランブルされたデータの伝送は、ペイTVシステムの分野で周知である。一般的には、スクランブルデータは、データを暗号解読する制御ワードとともに伝送され、制御ワードそのものは、いわゆる利用鍵によって暗号化され、暗号化形式で伝送される。
【0039】
スクランブルデータおよび暗号化制御ワードは、次にデコーダに挿入されたスマートカードに記憶された利用鍵の均等物へのアクセス権を有するデコーダ13によって受信され、暗号化制御ワードを暗号解読し、その後、伝送データを暗号解読する。支払った加入者は、例えば、伝送を見ることができるように暗号化制御ワードを暗号解読するのに必要な利用鍵を放送月EMM(資格管理メッセージ)で受信する。視聴覚テレビ番組を暗号解読する際のその使用に加えて、同じ利用鍵が、前述されるようなソフトウェアモジュールのような他のデータの検証で使用するために生成され、送信されてもよい。
【0040】
マルチプレクサ4および受信機/デコーダ13にも接続され、さらに一部が放送局にあり、一部がデコーダにある対話システム16によって、エンドユーザは、モデム逆方向チャネル17を介していろいろなアプリケーションと対話できる。このモデム逆方向チャネルも、条件付アクセスシステム15で使用される通信のために使用されてもよい。対話システムは、例えば、視聴者は、直ちに放送局と通信し、特定の試合を見て、アプリケーション等をダウンロードするための許可を要求することができる。
【0041】
(受信機/デコーダの物理的要素)
図2を参照すると、本発明で使用されるように構成される受信機/デコーダ13あるいはセットトップボックスの物理的要素は、次に簡単に説明される。この図に示された要素は、機能ブロックによって説明される。
デコーダ13は、関連メモリ要素を含み、かつ直列インタフェース21、並列インタフェース22、および(図1のモデム逆方向チャネル17に接続される)モデムから入力データを受信するように構成される中央プロセッサ20を含む。
【0042】
デコーダは、さらに制御装置26を介して赤外線遠隔制御装置25からおよびデコーダの正面パネル上のスイッチコンタクト24から入力を受信するように構成される。このデコーダは、銀行スマートカードおよび加入スマートカード29、30のそれぞれを読み取るように構成される2つのスマートカード読み取り器27、28も持つ。入力も、赤外線キーボード(図示せず)を介して受信されてもよい。加入スマートカード読み取り器28は、挿入加入カード30および条件付アクセス装置29と係合し、必要な制御ワードを多重分離装置/暗号解読器30に供給し、暗号化放送信号は暗号解読できる。デコーダは、装置30によってフィルタリングされ、多重分離される前に衛星伝送を受信し、復調する従来のチューナ31および復調器32も含む。
【0043】
デコーダ内のデータの処理は、通常、中央プロセッサ20によって処理される。中央プロセッサのソフトウェアアーキテクチャは、デコーダのハードウェア構成要素で実行される下部レベルオペレーティングシステムと対話する仮想機械に対応する。
【0044】
(伝送データのパケット構造)
次に、図3および4を参照して、送信機からデコーダに送信される放送MPEGトランスポートストリーム内のデータのパケット構造が説明される。理解されるように、この説明はMPEG規格で使用される作表フォーマットに集中するが、同じ原理は、同様に他のパケット化データストリームフォーマットに用いる。
【0045】
特に、図3を参照すると、MPEGビットストリームは、0のパケット識別(PID)を有する番組アクセステーブル(PAT)40を含む。PATは、多数の番組の番組マップテーブル(PMT)41のPIDの関連を含む。各PMTは、この番組のためのオーディオMPEGテーブル42およびビデオMPEGテーブル43のストリームのPPIDの関連を含む。ゼロのPIDを有するパケット、すなわち、番組アクセステーブル40は、全MPEGアクセスのためのエントリポイントを与える。
【0046】
アプリケーションおよびそのためのデータをダウンロードするために、2つの新しいストリーム形式が規定され、関連するPMTは、アプリケーションMPEGテーブル44(あるいはこれらの一部)およびデータMPEGテーブル45(あるいはこれらの一部)のストリームのPIDの関連も含む。実際は、実行可能なアプリケーションソフトウェアおよびこのようなソフトウェアによって処理するためのデータのための別個のストリーム形式を規定することはいくつのかの場合便利であり得るが、これは重要でない。他の実現では、データおよび実行可能なコードは、記載されるようなPMTを介してアクセスされる単一ストリームに組み立てできる。
【0047】
図4を参照すると、例えばストリーム44内のアプリケーションをダウンロードするために、アプリケーション46は、各々がMPEGテーブルによって形成されるモジュール47に分割される。これらのテーブルのいくつかは単一部分を含むが、他のものは複数の部分48によって構成されてもよい。典型的なセクション48は、1バイトのテーブルID(「TID」)50、テーブルのこのセクションのセクション番号51、このテーブルの全セクション数52および2バイトのTID拡張関連53を含むヘッダを有する。各セクションは、データ部54およびCRC55も有する。特定のテーブル47の場合、このテーブル47を構成するセクション48の全ては、同じTID50および同じTID拡張部53を有する。特定のアプリケーション46の場合、このアプリケーション46を構成するテーブルの全ては、同じTID50であるが、異なるそれぞれのTID拡張部を有する。
【0048】
各々のアプリケーション46の場合、単一MPEGテーブルは、ディレクトリテーブル56として使用される。このディレクトリテーブル56は、そのヘッダにおいて、アプリケーションを構成する他のテーブル47と同じTIDを有する。しかしながら、ディレクトリテーブルは、ID目的のためにゼロの所定のTID拡張部を有し、この事実のために単一テーブルだけはディレクトリの情報に対して必要である。他のテーブル47の全ては、通常非ゼロTID拡張部を有し、多数の関連セクション48で構成される。ディレクトリテーブルのヘッダは、ダウンロードされるアプリケーションのバージョン番号も含む。
【0049】
戻って図3を参照すると、PAT40、PMT41、およびアプリケーション・データストリーム成分44、45は、周期的に伝送される。伝送される各アプリケーションは、それぞれの所定のTIDを有する。アプリケーションをダウンロードするために、適切なTIDおよびゼロのTID拡張部を有するMPEGテーブルは、受信機/デコーダにダウンロードされる。これは、必要とされるアプリケーションのためのディレクトリテーブルである。このディレクトリのデータは、次にデコーダによって処理され、必要とされるアプリケーションを構成するテーブルのTID拡張部を決定する。その後、ディレクトリテーブルと同じTIDおよびディレクトリから決定されるTID拡張部を有するいかなる必要とされるテーブルもダウンロードできる。
【0050】
このデコーダは、そのいかなる更新のためのディレクトリテーブルも検査するように構成される。これは、例えば、30秒あるいは1分あるいは5分毎に周期的に再度ディレクトリをダウンロードし、予めダウンロードされるディレクトリテーブルのバージョン番号を比較することによって行われてもよい。新しくダウンロードされたバージョン番号が後のバージョン番号である場合、前のディレクトリテーブルに関連したテーブルは削除され、新しいバージョンに関連したテーブルは、ダウンロードされ、集められる。
【0051】
代替の装置では、入ってくるビットストリームは、アプリケーションのTID、ゼロのTID拡張部および目下ダウンロードされたディレクトリのバージョン番号よりも1つ大きいバージョン番号のためにセットされる値とともにTID、TID拡張部およびバージョン番号に対応するマスクを使用してフィルタリングされる。したがって、バージョン番号の増加が検出され、一旦検出されると、前述されるように、ディレクトリはダウンロードされ、アプリケーションは更新される。アプリケーションが終了されるべきである場合、次のバージョン番号を有する空のディレクトリは、ディレクトリに列挙された少しのモジュールもないことを除いて伝送される。このような空のディレクトリの受信に応じて、デコーダ2020は、アプリケーションを削除するようにプログラムされる。
【0052】
実際には、デコーダでアプリケーションを実行するソフトウェアおよびコンピュータプログラムは、特に前述されるような衛星リンクを介して受信されるデータストリームに、デコーダの一部のいずれかを介してであるが、直列ポート、スマートカードリンク等も介して導入されてもよい。このようなソフトウェアは、ネットブラウザ、クイズアプリケーション、番組案内等のようなデコーダ内の対話型アプリケーションを実行するために使用される高レベルアプリケーションを含んでもよい。ソフトウェアも、例えば「パッチ」等によってデコーダソフトウェアの作動構成を変えるようにダウンロードされてもよい。
【0053】
アプリケーションも、デコーダを介してダウンロードされ、デコーダに接続されたPC等に送信されてもよい。このような場合、デコーダは、最終的には接続装置で実行されるソフトウェアのための通信ルータの役目を果たす。このルーティング機能に加えて、デコーダも、PCに経路指定する前にMPEGパケット化データを例えばDSM−CCプロトコル(下記を参照)に従って構成されたコンピュータファイルソフトウェアに変換する機能を果たしてもよい。
【0054】
(データファイルのデータの構成)
図5は、DSM−CC U−U(ユーザ対ユーザ)データファイル60のセット、集められたアプリケーション46に構成され、一連のMPEGテーブル47内にカプセル化されるようなデータ間の関係を示す。この関係は国際特許出願番号第99/49614に記載されており、その内容は下記に参照される。
【0055】
伝送より前に、データファイルは、アプリケーション46に集められ、その後、MPEG圧縮器によって、前述されるようにMPEGパケットストリームに固有なヘッダ49を含み、かつテーブルID、バージョン番号等を含むMPEGテーブルあるいはモジュール47にパケット化される。理解されるように、データファイル61に構成されるデータと最終的なMPEGテーブル47との間に一定の関係が全然ない。デコーダによる受信およびフィルタリング後、パケットヘッダ49は、廃棄され、アプリケーション46は、テーブル47のペイロードから再構成される。
【0056】
データファイルのためのDSM−CCフォーマットは、特にマルチメディアネットワークで使用するために適合され、図6に示されるように、クライアントユーザ70、サーバユーザ71とネットワーク資源マネージャ72との間の通信のための一連のメッセージフォーマットおよびセッションコマンドを規定する規格である。ネットワーク資源マネージャ72は、ネットワーク内の資源の属性を管理するように作動する論理エンティティとみなされてもよい。
【0057】
クライアントとサーバとの間の通信は、一連のセッションによって作動可能な状態にされ、第1の一連のメッセージは、通信のためのクライアントおよび/またはサーバを構成するためにユーザ(クライアント70あるいはサーバ71)とネットワークマネージャ72との間で交換される。このようなメッセージは、いわゆるDSM−CC U−N(ユーザ対ネットワーク)に従ってフォーマット化される。このプロトコルのサブセットは、特にデータを放送ダウンロードするために規定された。
【0058】
一旦通信リンクが確立されると、メッセージは、DSM−CC U−Uプロトコルに従ってクライアント70とサーバ71との間でその後交換される。この種の一連のメッセージは、図5のデータファイル60に対応する。DSM−CC U−Uメッセージの場合、データは、BIOP(BroadcastInterOrbProtocol)従ってグループ化される。
【0059】
各メッセージあるいはオブジェクト61は、ヘッダ62と、サブヘッダ63と、データそのものを含むペイロード64とを含む。BIOPプロトコルに従って、ヘッダ62は、とりわけ、メッセージおよびBIOPバージョンの形式の指示を含むが、サブヘッダは、システム設計者によって規定されるオブジェクトおよび他の情報の形式を示す。
【0060】
DSM−CC U−Uファイルのペイロード内のデータオブジェクト64は、通常3つの形式、すなわちディレクトリオブジェクト、ファイルオブジェクトおよびストリームオブジェクト、の中の1つとして規定できる。ディレクトリオブジェクトは、実際のアプリケーションデータを含む一連の関連ファイルオブジェクトを関連付けるために使用されるルートディレクトリあるいはサブディレクトリを規定する。
【0061】
ストリームオブジェクトは、一時の関係がデータファイルに含まれるデータとMPEGパケットストリームそのものとの間に確立できるために使用されてもよい。これは、例えば、データファイルに含まれ、かつデコーダによって受信され、処理される基本ビデオあるいはオーディオストリームと同期されるように設計される対話形アプリケーションの場合、使用されてもよい。前述されるように、特にMPEGパケット化データとデータファイルとの間に全然直接の相関が有り得ない。
【0062】
MPEGテーブルと違って、単一ディレクトリがテーブルのセットを単一レベルの階層のみと関連付ける場合、データファイル60は、かなりより複雑な階層のように構成されてもよい。PCあるいはサーバに記憶されるファイルのように、主ディレクトリあるいはルートディレクトリは、順に第2のレベルのデータファイルを参照する1つあるいはそれ以上のサブディレクトリを参照してもよい。(データファイルのセットのためのファイル構造)
【0063】
図7を参照すると、データファイルのセットのためのファイル構造の例が示されている。75に示されるルートディレクトリDIRA0は、サブディレクトリA1のグループをオブジェクトファイル77に関連付ける。明瞭にするために、サブディレクトリA4と関連するオブジェクトファイルF1、F2等の単一グループだけが示されている。実際には、多数のオブジェクトファイルのグループは、サブディレクトリA1からA4の各々によって関連付けられてもよい。
【0064】
各々のディレクトリおよびサブディレクトリ内で、認証ステップのセットは、このディレクトリに結合されるファイルのために導入される。ルートディレクトリ75を参照すると、サブヘッダ63は、ハッシュアルゴリズムを76と示されたサブディレクトリファイルA1からA4に記憶されたデータのいくつかあるいは全てに用いることによって得られたハッシュ値を含む。使用されるハッシングは、例えば、メッセージダイジェストアルゴリズムMD5のような任意の公知の形式のものであってもよい。
【0065】
1つの実現では、このアルゴリズムは、各々の関連ファイルあるいはサブディレクトリに個別に適用され、各サブディレクトリ76のためのハッシュ値のリストは、伝送より前にルートディレクトリ75に記憶されてもよい。しかしながら、このような解決策は、各々のサブディレクトリを検証することに関する分解能をチェックする度合いの増加を可能にするが、この解決策は、対応するシグネチャを計算するためにデコーダのために必要である処理時間に関してかなり役に立たないことが有り得る。したがって、ディレクトリ79のサブヘッダ63は、好ましくは、MD5ハッシングアルゴリズムを結合されたサブヘッダおよびサブディレクトリ76のペイロード部63、64に用いることによって計算され、すなわちヘッダ62がない累積ハッシュ値79を含む。特に、サブディレクトリ76内に含まれ、ファイルオブジェクト77の層を示すハッシュ値82は、このハッシング計算に含まれる。
【0066】
図7に示されたサブディレクトリA4の場合、このサブディレクトリそれ自体は、77に示されるオブジェクトF1〜Fnのセットを示す。この場合、累積ハッシュ値82は、オブジェクトファイル77の結合内容のために生成される。この値は、ハッシュ値79を生じるハッシング処理に含まれる。したがって、順にディレクトリ75のハッシュ値79を変えるサブディレクトリ76のハッシュ値82を変えないでオブジェクトファイル77のいずれかを変えることができない。
【0067】
この場合、結合されたハッシュ値は、ディレクトリに示されたサブディレクトリの全てに対して計算される。このハッシュ値は、そこからデータがとられるサブディレクトリのグループの識別子とともに記憶される。他の実施形態では、一連の結合されるかあるいは個別のハッシュ値および対応する識別子は、ディレクトリのサブヘッダに記憶されてもよい。
【0068】
例えば、ルートディレクトリとも関連するが、異なるデータのセットあるいは実行可能なコードに関する第2のサブディレクトリのセットも、一緒にグループ化され、累積ハッシュ値は、計算され、サブヘッダルートディレクトリに記憶されたこれらのサブディレクトリのために計算されてもよい。単一ディレクトリに関連した単一ハッシュ値は、同様にルートディレクトリのサブヘッダに記憶されてもよい。
【0069】
グループあるいは個別のデータファイルの認証は、もちろん、ルートディレクトリ(あるいは、実際に任意の他のファイル)が無効あるいは未ハッシュのデータファイルも示すことを防止しなくて、このようなファイルの確認がないことは、このファイルとの任意の動作を考慮する必要がある。この点では、例えば、システムオブジェクトを認証することは必要であり得ない。
【0070】
この場合のハッシング関数の使用によって、主にデコーダは、ダウンロードデータファイルの一貫性あるいはダウンロードデータファイルを完備していることを検証できる。例えば、伝送における故障あるいは遮断の場合、受信された従属ファイルの累積ハッシングアルゴリズムの演算は、ルートディレクトリに記憶されたこれらのファイルに対するハッシュ値と同じ結果を得られる。次に、デコーダは、ダウンロードデータの可能なエラーがあることに変更され、誤ったデータファイルを再ロードする。
【0071】
(ルートディレクトリのためのシグネチャ値)
高められたセキュリティの場合、ルートディレクトリ75のためのシグネチャ値が計算される。本実施形態では、リベスト(Rivest)、シャミール(Shamir)およびアデルマン(Adleman)あるいはRSAアルゴリズムが使用され、データファイルを生成する責任を負うべき放送会社は、私用鍵値を所有し、公開鍵は、デコーダによって保持される。一方、秘密鍵は、データ暗号規格あるいはDESアルゴリズムのような対称性鍵アルゴリズムによって得られる鍵に対応し得る。
【0072】
図7に示されるように、ルートディレクトリ75は、放送会社の私用鍵を使用して生成される計算されたシグネチャ値81とともに検証工程で使用される公開鍵をデコーダのために識別する放送会社識別子80を含む。この場合、シグネチャ値81は、放送会社によって保持される私用鍵を好ましくはペイロードデータ64および/または累積ハッシュ値79を含むディレクトリ75内のデータのいくつかあるいは全てに用いることによって生成される。次に、このデコーダは、放送会社識別子80によって識別される対応する公開鍵を使用してこのシグネチャ値81を検証できる。
【0073】
本例では、ディレクトリ75のデータは、暗号化されなくて、この私用鍵は、公開鍵によって検証できるシグネチャ値を生じるために単に使用できる。代替実施形態では、ディレクトリの内容のいくつかあるいは全ては、私用鍵によって暗号化され、その後、対応する鍵によって暗号解読されてもよい。
【0074】
どちらかの場合でも、秘密鍵の使用による暗号化コードのシグネチャ値あるいはブロックの生成によって、デコーダは、ディレクトリ75の一貫性および発生源、および密接な関係によってこのルートディレクトリによって参照されるファイルの一貫性および発生源を検証できる。参照ファイルのための累積ハッシュ値は、シグネチャ81の計算に含まれるので、これが検証工程で検出されない限りこれらの値を変更できない。各ハッシュ値は通常所与のデータのセットに固有であるので、したがってその固有のハッシュ値、それによってディレクトリの生じるシグネチャ値を変えないで従属ハッシュファイルのいずれかの内容を変えることができない。
【0075】
理解されるように、多数の変更は、特に各工程でハッシュされるかあるいは署名されるデータ量を減らすことを可能にし得る。特に、下部レベルデータファイルを検証するために使用されるディレクトリあるいはサブディレクトリのシグネチャあるいはハッシュ値の場合、ディレクトリシグネチャあるいはハッシュ値は、下部レベルハッシュ値だけを使用し、他のデータだけを使用しないで生成されてもよい。
【0076】
例えば、A0ディレクトリ75の結合ハッシュ値79は、76に示されるA1―A4サブディレクトリの各々の結合ハッシュ値82、83を使用して生成されてもよい。これらの値は、丁度サブディレクトリのペイロードのデータと同様に独自であるので、結合ハッシュ値79は、なお当のサブディレクトリに固有である。さらに、ハッシュ値82はなお計算で使用されるので、オブジェクトファイルおよびディレクトリファイル77、78の下部レベルの一貫性がなお推測される。
【0077】
(放送会社デジタル認証)
図8を参照すると、公開鍵91および放送会社識別子80は、好ましくは、製造中デコーダのメモリにハードコード化される周知の国際標準化機構(ISO)X.509の形のデジタル認証でデコーダのユーザに供給される。このような認証は、通常認証局(CA)と呼ばれる信用された第三者によってデコーダの製造者に配信される。このような認証の使用は、ワールドワイドウェブ(WWW)を介するクレジットカードトランザクションを保護するネットスケープ通信によって開発され、標準化された安全ソケットレイヤー(SSL)安全トランスポートプロトコルにより主により広く受け入れるようになる。
【0078】
公開鍵91および放送会社識別子80と同様に、放送会社に関連したデジタル認証あるいは放送会社認証90は、放送会社認証90のバージョン番号92;
放送会社認証90の連続番号93;
放送会社認証90を配信したCAのCAID94;
認証が使用されることを意図されている時間の開始および終了を示す放送会社認証90の有効期間95;および放送会社認証90のシグネチャ値96も含む。
【0079】
前述から分かるように、放送会社認証は、2つの異なる識別子、すなわち認証の分配者のID94に対応する第1の「発行者名」識別子および公開鍵91を識別する識別子80に対応する第2の「主題名」識別子を含む。
【0080】
CAは、CAの私用鍵、あるいはCA私用鍵を放送会社認証内のデータの少なくともいくつかあるいは全てに用いることによって放送会社認証90のシグネチャ値96を計算する。次に、デコーダは、CAID94によって識別される対応するCA公開鍵101を使用してシグネチャを処理することによってこのシグネチャ値96を検証し、認証の内容がCAによってシグネチャに続いて修正されなかったことを決定する。
デコーダは、異なるそれぞれの放送会社に対する複数のこのような認証を記憶してもよい。
【0081】
(認証局デジタル認証)
さらに図8を参照すると、対応するCA公開鍵101およびCA識別子94は、製造中デコーダでもハードコード化されるCA認証100のデコーダのユーザに供給される。CA認証100は、CA認証100のバージョン番号102;
【0082】
CA認証100の連続番号103;
CA認証100を配信した欧州電気通信標準化機構(ETSI)のようなルート認証局(RCA)のRCAID104;
CA認証100の妥当性期間105;および・CA認証100のシグネチャ値106も含む。
【0083】
前述から分かるように、CA認証は、2つの異なる識別子、すなわち認証の分配者のID104に対応する第1の「発行者名」識別子および公開鍵101を識別する識別子94に対応する第2の「主題名」識別子を含む。
【0084】
RCAは、RCAの私用鍵、あるいはRCA私用鍵をCA認証内のデータの少なくともいくつかあるいは全てに用いることによってCA認証100のシグネチャ値106を計算する。次に、デコーダは、RCAID104によって識別される対応するRCA公開鍵111を使用して認証を処理することによってこのシグネチャ値96を検証し、認証の内容がRCAによってシグネチャに続いて修正されなかったことを決定する。
【0085】
デコーダは、異なるそれぞれのCAに対する複数のこのような認証を記憶してもよい。
対応するRCA公開鍵111およびRCA識別子104は、製造中デコーダのメモリでもハードコード化されるRCAあるいはルート認証110のユーザに供給される。各デコーダは、一般的には2つあるいはそれ以上のルート認証のセットを含む。各ルート認証110は、ルート認証110のバージョン番号112;
【0086】
ルート認証110の連続番号113;
ルート認証110の妥当性期間114;およびルート認証110のシグネチャ値115も含む。
前述から分かるように、ルート認証は、単一識別子、すなわち認証の配信者のID104だけを含む。このID104は公開鍵111も含む。したがって、ルート認証は、発行者名が主題名と同じである認証として規定されてもよい。
【0087】
ルート認証は、放送会社認証90−CA認証100−ルート認証110の連鎖の最終認証であるので、ルート認証は、自動署名され、すなわち、シグネチャ値は、公開鍵111と等価の私用鍵を使用して計算される。したがって、ルート認証の内容が公に利用できるようにならないことに関心がある。
【0088】
もちろん、RCAは、放送会社認証をデコーダの製造者に直接供給することができ、その場合、放送会社認証は、RCA識別子111を含み、RCA私用鍵を使用して署名される。
【0089】
(認証取り消しリスト)
放送会社認証90およびCAのいずれかは、例えば認証に記憶された公開鍵に対応する私用鍵が危険にさらされるようになる場合、それで指定された妥当性期間の満了より前に例えば削除によって取り消されてもよい。このような取り消しは、取り消される認証の連続番号92、102のリストを含む認証取り消しリスト(CRL)のデコーダへの伝送によって行うことができる。取り消しの際に、認証は、好ましくは、デコーダのメモリからの認証の削除によって実行できないようになり、それによって危険にさらされた私用鍵を使用して署名される任意の不許可の可能性のある悪意のあるデータパケットのダウンロードを防止する。
【0090】
CRLは、モデム逆方向チャネル17あるいはCRLを放送することによるMPEGトランスポートストリームのいずれかに介してCRLをデコーダに伝送する放送会社にCAあるいはRCAのいずれかによって配信される。放送会社が、CRLを送信機からデコーダに送信されるトランスポートストリームの全てに挿入することは重要でない。CRLをデコーダによって同調されるのに非常に可能性があるトランスポートストリームに挿入することは放送会社にとって十分なことである。例えば、CRLは、データファイルとして送信機からデコーダへ放送されるデータファイルのセットのルートディレクトリ75あるいはサブディレクトリ76に挿入されてもよい。
【0091】
図9を参照すると、CRL120は、一般的には、
CRL120を配信したCAあるいはRCAのID94あるいは104;
CRL120が出された日付122;
次のCRLが出されることが予想される日付124;
【0092】
各々の取り消された認証に対して、この認証の取り消しの時間および日付を含む、取り消された認証の連続番号のリスト125;および・CRL120を配信したCAあるいはRCAの私用鍵を使用して計算されたCRLのシグネチャ値126を含む。
【0093】
CRLの受信の際に、デコーダは、予め受信されたCRLによって通知されるように、CRL120が発行された日付122を、CRL120が予想される日付124と比較する。新しく受信されたCRLの日付122がCRLが予想される日付124よりも後でない場合、CRLは無視される。
【0094】
新しく受信されたCRLの日付122がCRLが予想される日付124よりも後である場合、CRLのシグネチャは、CRLに含まれるID94あるいは104を使用して識別されるように、CAの発行者の公開鍵を使用して検証される。
【0095】
CRLの一貫性がそのように検証される場合、CRLは、次のCRLが出されることが予想される日付124を固定メモリに記憶し、取り消された認証の連続番号のリスト125を記憶するように日付124を加えるために処理される。取り消された認証の受信リスト125は、デコーダの固定メモリにも記憶される。性能の理由のために、CRL120がデコーダのメモリにキャッシュされるのが好ましい。デコーダのキャッシュメモリがCRL120を樹枝状に記憶することも好ましく、RCAのCRLは、「ツリー」の上部およびこのRCAがツリーの底部にある認証を配信するCAのCRLにある。
【0096】
放送会社90の取り消しの場合、例えば、放送会社の私用鍵が危険にさらされるようになる場合、この放送会社に対する認証局は、放送会社認証90の連続番号93をそのCRL120に加える。認証局は、その後新しいCRL120を放送するための放送会社認証90を配信する放送会社の全てに配信する。デコーダが新しいCRL120をダウンロードするや否や、例えば、放送会社のチャネルで早送りする際に、CRLキャッシュは、更新され、CRL120のリスト125でそのように識別されたいかなる認証の取り消しも行われる。
【0097】
交換放送会社認証90は、認証局によって生成され、ファイルのディレクトリ75あるいは76のユーザに放送する。交換放送会社認証は、とりわけ、新しい公開鍵91と、更新バージョン番号92と、更新妥当性期間95と、CAの私用鍵を使用して計算された新しいシグネチャ値96とを含む。放送会社識別子80およびCA識別子94は変更されないままである。交換放送会社認証90の受信際に、デコーダは、CAID94によって識別されたCA認証に含まれる対応するCA公開鍵を使用して認証を処理することによって認証を検証する。
【0098】
CA認証100の取り消しの際に、このCAのCRLは、デコーダのメモリから取り除かれる。したがって、例えば、このCAのCRLのサイズがデコーダのキャッシュメモリに記憶するためにあまりに大きくなる場合、CA認証100を任意に取り消すことは望ましいことで有り得る。この場合、CA認証100をこのCAに配信するRCAは、このCA認証100の連続番号をそのCRLに追加する。ルート認証局は、その後、RCAがCA認証を配信するCAが放送するための放送会社認証を順に配信する放送会社の全てに新しいCRLを配信する。デコーダが新しいCRLをダウンロードするや否や、例えば、放送会社のチャネルで早送りする際に、CRLキャッシュは更新され、CRL120のリスト125にそのように識別されたCA認証の取り消しが行われる。
【0099】
認証局のCA認証100の取り消しの際に、デコーダへのこの認証局のための新しいCA認証の記憶に加えて、この認証局のための私用鍵対はもはや有効でないので、認証局の異なるかあるいは更新私用鍵を使用して署名された新しい放送会社認証90が必要とされるためにこの認証局が認証を配信する放送会社の全てのための放送会社認証90を交換する必要がある。交換CA認証100は、ルート認証局110によって生成され、ファイルのディレクトリ75あるいは76のユーザに放送される。交換放送会社認証と同様に、交換CA認証は、とりわけ、新しいCA公開鍵101と、更新バージョン番号102と、更新妥当性期間105と、RCAの私用鍵を使用して計算された新しいシグネチャ値106とを含む。CA識別子94およびRCA識別子104は変更されないままである。交換CA認証100の受信の際に、デコーダは、RCAID104によって識別されたRCA認証100に含まれる対応するRCA公開鍵を使用して認証を処理することによって認証を検証する。
【0100】
(ルート認証管理メッセージ)
ルート認証局のRCA認証110の取り消しの際に、取り消されたRCA認証を新しいRCAと交換する必要がある。前述されるように、RCA認証は自動署名されるので、CRLへRCA認証を含めることは、ハッカーがCRLを署名するために使用される私用鍵を知っている場合、ハッカーは認証を持つことができるので望ましくない。したがって、例えば、RCA認証が旧式になったかあるいは取り消されるようになった場合、これまでRCA認証が更新されるべきである度にデコーダを製造者に戻すことが必要であった。
【0101】
この問題を解決するために、ルート認証管理メッセージ(RCMM)は、放送会社によってデコーダに放送するためにルート認証局によって生成される。下記により詳細に説明されるように、CRLと同様に、RCMMは、旧式になったかあるいはリスト125に識別されたこれらの認証のための1つあるいはそれ以上の交換ルート認証とともに、各々の取り消されたルート認証に対してこの認証の取り消しのための時間および日付を含む、取り消されるルート認証の連続番号のリスト125を含む。
【0102】
理解されるように、RCMMの秘密にかかわる内容(新しいルート認証)に関して、放送会社に「出されるような」デコーダによって受信されることを保証すること、すなわちRCMMの内容が配信と受信との間で交換されないことを保証することは、重要である。RCMMが、RCMMがアドレスされる誰かにデコーダによってだけアクセスできることを保証することも重要である。
【0103】
セキュリティを高めるために、CRLと違って、RCMMは、その中に含まれるデータの少なくともいくつか、好ましくは全てに対する少なくとも2つのシグネチャ値を含む。各々のシグネチャ値は、公開鍵/私用鍵対の私用鍵のようなそれぞれの暗号化アルゴリズムの鍵を使用して計算される。
【0104】
RCMMがルート認証局(RCA)によって出され、新しいルート認証110を含む場合、RCMMは、少なくとも2つのシグネチャ値を含む。各々のシグネチャ値は、例えば、RCAが認証を供給する認証局のそれぞれの私用鍵を使用して計算される(ただし、デコーダが等しい鍵を記憶するいかなる鍵も選択されてもよい)。これらの認証局の中の1つに未知であり、その私用鍵が危険にさらされるようになる場合、「ハッカー」は放送会社の放送を遮断することが可能であり得る、ハッカーが放送会社および認証局の両方の私用鍵を知っている場合、ハッカーは、RCMMの内容および認証局の私用鍵を使用して計算されたRCMMのシグネチャ値を変える。しかしながら、この鍵は危険にさらされているようにならないために、ハッカーは、他の認証局の私用鍵を使用して計算されたシグネチャ値を変えることができない。したがって、2つの認証局の公開鍵を使用してデコーダによるシグネチャの検証の際に、それぞれの公開鍵を使用してデコーダによって計算された2つの値は同じでない。したがって、デコーダは、RCMMの内容の一貫性の欠如のために変えられ、RCMMの処理を拒否し、またはその他RCMMの処理を続けない。
【0105】
したがって、もし危険にさらされた認証数がRCMMに含まれたシグネチャ数よりも小さいとすれば、ルート認証は安全に更新できる。したがって、RCMMのシグネチャ数は、RCMMを配信するルート認証局によって決定された変数である。
次に、RCMMのフォーマットは、図を参照してより詳細に示されている。
【0106】
RCMM130は、RCMM130を配信したRCAの一貫性132;
RCMM130が発行した日付134;
その後のRCMMが含むシグネチャ値の数136;
1つあるいはそれ以上の更新されるかあるいはデコーダに記憶される交換ルート認証を含むフィールド138;
【0107】
各々の取り消されたルート認証に対してこの認証の取り消しの時間および日付を含む、取り消されたルート認証の連続番号のリスト140;および各々が、このシグネチャフィールドに含まれたシグネチャ値を検証するために使用される公開鍵を含む、デコーダに記憶された認証の識別子144;および識別子144によって識別される認証に含まれる公開鍵に等しい私用鍵を使用して計算されたRCMMのシグネチャ値146を含む少なくとも2つのシグネチャフィールド142を含む。
【0108】
シグネチャフィールド数142は、予め受信されたRCMMに通知されるようなシグネチャフィールド数136に等しいかあるいはそれよりも大となるべきである。
モデム逆方向チャネルは容易に切り離してもよいしあるいは単に存在しなくてもよいので、RCMMはMPEGトランスポートストリームを介して伝送されることが好ましい。RCMMが、デコーダによってダウンロードされることを保証するために放送会社によってデータファイルとしてルートディレクトリ75に挿入されることも好ましい。
【0109】
(ルート認証管理メッセージの処理および生成)
次に、デコーダによるRCMMの受信および処理は、図11を参照して説明される。
RCMMの受信の際に、ステップ200では、デコーダは、予めRCMMを出されたRCMM130が出された日付134を比較する。新しい受信されたRCMMの日付134が前のRCMMが出された日付よりも後でない場合、RCMMは拒否される。
【0110】
新しく受信されたRCMMの日付134が前のRCMMの受信の日付よりも後である場合、予め受信されたRCMMによって通知されるように、新しく受信されたRCMMが含むべきであるシグネチャ値の数136は、ステップ202で新しく受信されたRCMMで実際に含まれたシグネチャ値の数と比較される。新しく受信されたRCMMに含まれたシグネチャの数が予想よりも低い場合、RCMMが拒否される。これは、RCMMが危険にさらされていない私用鍵/公開鍵対に関連したシグネチャを取り除くハッカーの結果として特に処理されることを防止する。
【0111】
新しく受信されたRCMMに含まれたシグネチャの数が予想されたシグネチャの数に等しいかあるいはそれよりも大きい場合、ステップ204で、RCMMに含まれた各々のシグネチャ値146は、このシグネチャ値と同じシグネチャフィールド142に含まれる識別子144によって識別された公開鍵を使用して検証される。ステップ206では、デコーダは、公開鍵を使用して計算された値の少なくとも1つが異なる公開鍵を使用して計算された他の値のいずれかと異なるかどうかを決定する。少なくとも1つの計算された値が他の計算された値の少なくとも1つと異なる場合、RCMMは拒否される。
【0112】
RCMMの一貫性がステップ206で証明される場合、RCMMは、ステップ208で処理され、デコーダの固定メモリに取り消されたルート認証の連続番号のリスト140を記憶するので、これらの認証は、ステップ212で、デコーダのメモリから削除され、フィールド138に含まれたルート認証あるいは各ルート認証をデコーダの固定メモリに記憶し、ステップ212でRCMMの日付134を固定メモリに記憶してもよい。ルート認証局の認証が削除される場合、この局によって出される任意のCRLも削除される。
【0113】
RCMMに含まれたデータの固定メモリの一貫性が、デコーダがRCMMメッセージの処理中スイッチオフされる場合、保持されることが好ましい。したがって、電力が実際にRCMM処理中スイッチオフされる場合、デコーダに記憶される予め処理されたRCMMに関連したリスト140は、あたかも新しく受信されたRCMMメッセージが全然処理されなかったかのように保持される。
【0114】
前述されるように、ルート認証局(RCA)は、一般的には各デコーダに記憶された少なくとも2つのRCA認証、すなわちRC0およびRC1を有する。これらの認証の1つ、例えばRC0が危険にさらされるようになる場合、RC0に記憶された公開鍵の等価私用鍵を使用して署名されたデコーダに記憶された全CA認証を交換し、新しいRCA認証RC2を生成し、RC0を交換する必要がある。
【0115】
図12を参照すると、これらのCA認証を交換するために、最初にステップ300では取り消されるCA認証の連続番号を識別する適切なCRLメッセージがRCAによって出される。第二に、ステップ302では、危険にさらされていない認証RC1の私用鍵を使用して署名され交換CA認証は、デコーダに放送するために放送会社に出される。
【0116】
次に、交換CA認証は、危険にさらされたRCA認証RC0を削除し、この認証を新しいRCA認証RC2と交換するままである。ステップ304では、RCAは、新しい公開鍵/私用鍵対を生成し、認証RC2に新しい公開鍵を挿入し、新しい私用鍵を使用して認証を署名する。
【0117】
ステップ306では、RCAは、フィールド138では、認証RC2およびリスト140ではRC0の連続番号を含むRCMMを生成する。このRCMMは、ステップ308では、デコーダに伝送するために放送会社に配信され、危険にさらされた認証RC0を削除し、これを新しい認証RC2と交換する。
【0118】
RCA認証RC1およびRC2は、その後新しいデコーダのメモリにハードコーディングするためにデコーダ製造者に供給される。
本発明は例として単に前述去れ、詳細の修正は本発明の範囲内に行うことができることが分かる。
【0119】
例えば、RCMMは、新しいRCA認証110に加えて、新しいCA認証100および/または新しい放送会社認証90を含んでもよく、リスト140は、CA認証および/または取り消されるべきである放送会社認証の識別子を含んでもよい。これは、RCAによる別個のCRLメッセージの生成が不要にされることを可能にすることができる。
説明で開示された各々の特徴、および(適切である場合)特許請求の範囲および図面は、独立してあるいは任意の適切な組み合わせで提供されてもよい。
【図面の簡単な説明】
【0120】
【図1】図1は本発明と併用するためのデジタルテレビシステムの概略図を示す。
【図2】図2は図1のシステムのデコーダの構成を示す。
【図3】図3はMPEG放送トランスポートシステム内の多数の構成要素の構成を示す。
【図4】図4は多数のMPEGテーブルへのソフトウェアアプリケーションの分割を示す。
【図5】図5はDES−CCデータファイルと最終的に発生されたMPEGテーブルとの関係を示す。
【図6】図6はDES−CCの前後関係で規定されるようなクライアント、サーバ、ネットワークマネージャ関係を示す。
【図7】図7は認証ディレクトリ、サブディレクトリおよびファイルオブジェクトを示す。
【図8】図8は放送認証、認証局認証およびルート認証局認証のフォーマットを示す。
【図9】図9は認証取消リストのフォーマットを示す。
【図10】図10はルート認証管理メッセージ(RCMM)のフォーマットを示す。
【図11】図11はデコーダによる受信の際にRCMMの処理に含まれるステップを示す。
【図12】図12は本発明の動作を説明するフローチャートである。
【符号の説明】
【0121】
1 デジタルテレビシステム
2 従来のデジタルテレビシステム
3 圧縮器
4 スクランブラ、マルチプレクサ
5 リンク装置
6 送信機
7 リンク結合装置
8 アップリンク
9 衛星トランスポンダ
10 ダウンリンク
12 受信機
13 統合受信機/デコーダ
14 テレビ受像機
15 条件付きアクセスシステム
16 対話システム
17 モデム逆方向チャネル
【特許請求の範囲】
【請求項1】
デジタル伝送システムで伝送されるデータを証明する方法であって、データは以前に伝送されたデータの更新データであり、前記方法は、
前記データ、前記データが発行された日付、及び前記データの少なくともいくつかに対して決定された少なくとも2つの暗号化値であって、各々の暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して、同じデータに対して決定される様な暗号化値とを受信するステップと、
前記データが発行された日付が以前に伝送されたデータが発行された日付よりも遅い事を証明するステップと、
前記それぞれの暗号化アルゴリズムの記憶鍵を使用して、各々の暗号化値を処理するステップと、
各々のその後に生じる値と前記データの少なくともいくつかと比較し、前記データの少なくともいくつかを証明するステップと
を含むことを特徴とするデジタル伝送システムで伝送されるデータを証明する方法。
【請求項2】
前記方法は、更に若し前記データの発行された日付が以前に伝送されたデータが発行された日付よりも遅くない場合には前記データを拒絶するステップを含んでいる事を特徴とする請求項1に記載の方法。
【請求項3】
前記データは、ルート認証管理メッセージ(RCMM)を含んでいる事を特徴とする請求項1に記載の方法。
【請求項4】
受信機/デコーダであって、複数の鍵を記憶する様手段を含んでおり、前記受信機/デコーダは更に、
データ、前記データが発行された日付及び前記データの少なくともいくつかに対して決定される少なくとも2つの暗号化値であって、各々の暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して、少なくとも同一のデータに対して決定される暗号化値とを受信する為の受信手段と、
前記データが発行された日付が以前に伝送されたデータの日付よりも遅い事を証明する手段と、
前記それぞれの暗号化アルゴリズムの記憶鍵を使用して、各々の暗号化値を処理する手段と、
各々のその後に生じる値と前記データの少なくともいくつかと比較し、前記データの少なくともいくつかを証明する手段と
を含むことを特徴とする受信機/デコーダ。
【請求項5】
前記受信機/デコーダは、更に若し前記データの発行された日付が以前に伝送されたデータの発行日付よりも遅くない場合には前記データを拒絶する手段を含んでいる事を特徴とする請求項4に記載の受信機/デコーダ。
【請求項6】
前記データは、ルート認証管理メッセージ(RCMM)を含んでいる事を特徴とする請求項4に記載の受信機/デコーダ。
【請求項7】
デジタル伝送システムで伝送されるデータを認証する方法であって、当該方法は、伝送より前に、
前記データの少なくともいくつかに対する少なくとも2つの暗号化値を決定するステップであって、各暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して同じデータのために決定されるステップと、
前記データが発行された日付を決定するステップと、
前記少なくとも2つの暗号化値と前記日付とを前記データと共に出力するステップと
から構成されている事を特徴とする方法。
【請求項8】
前記データは、ルート認証管理メッセージ(RCMM)を含んでいる事を特徴とする請求項7に記載の方法。
【請求項9】
デジタル伝送システムで伝送されるデータを認証する装置であって、当該装置は、
前記データの少なくともいくつかに対する少なくとも2つの暗号化値を決定する手段であって、各暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して同じデータに対して決定される手段と、
前記データが発行された日付を決定する手段と、
前記少なくとも2つの暗号化値と前記日付とを前記データと共に出力する手段と、
を含んでいる事を特徴とする装置。
【請求項10】
前記データは、ルート認証管理メッセージ(RCMM)を含んでいる事を特徴とする請求項9に記載の装置。
【請求項11】
デジタル信号であって、前記信号は、データ、前記データが発行された日付及び前記データの少なくともいくつかに対して決定された2つの暗号化値であって、各々の暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して同じデータに対して決定される値とを含んでいる事を特徴とするデジタル信号。
【請求項12】
前記データは、ルート認証管理メッセージ(RCMM)を含んでいる事を特徴とする請求項11に記載のデジタル信号。
【請求項13】
受信機/デコーダであって、前記受信機/デコーダは、
複数の鍵を格納する様に構成されている第1の記憶空間と、
データ、前記データが発行された日付及び前記データの少なくともいくつかに対して決定された少なくとも2つの暗号化値であって、各々の暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して同じデータに対して決定される値を受信する為の受信手段と、
プロセッサであって、当該プロセッサは、
前記データが発行された日付が以前に伝送されたデータの日付よりも遅い事を証明するステップと、
前記それぞれの暗号化アルゴリズムの記憶鍵を使用して、各々の暗号化値を処理するステップと、
各々のその後に生じる値と前記データの少なくともいくつかと比較し、前記データの少なくともいくつかを証明するステップと
を実行する様に構成されたプロセッサと
から構成されている事を特徴とする受信機/デコーダ。
【請求項1】
デジタル伝送システムで伝送されるデータを証明する方法であって、データは以前に伝送されたデータの更新データであり、前記方法は、
前記データ、前記データが発行された日付、及び前記データの少なくともいくつかに対して決定された少なくとも2つの暗号化値であって、各々の暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して、同じデータに対して決定される様な暗号化値とを受信するステップと、
前記データが発行された日付が以前に伝送されたデータが発行された日付よりも遅い事を証明するステップと、
前記それぞれの暗号化アルゴリズムの記憶鍵を使用して、各々の暗号化値を処理するステップと、
各々のその後に生じる値と前記データの少なくともいくつかと比較し、前記データの少なくともいくつかを証明するステップと
を含むことを特徴とするデジタル伝送システムで伝送されるデータを証明する方法。
【請求項2】
前記方法は、更に若し前記データの発行された日付が以前に伝送されたデータが発行された日付よりも遅くない場合には前記データを拒絶するステップを含んでいる事を特徴とする請求項1に記載の方法。
【請求項3】
前記データは、ルート認証管理メッセージ(RCMM)を含んでいる事を特徴とする請求項1に記載の方法。
【請求項4】
受信機/デコーダであって、複数の鍵を記憶する様手段を含んでおり、前記受信機/デコーダは更に、
データ、前記データが発行された日付及び前記データの少なくともいくつかに対して決定される少なくとも2つの暗号化値であって、各々の暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して、少なくとも同一のデータに対して決定される暗号化値とを受信する為の受信手段と、
前記データが発行された日付が以前に伝送されたデータの日付よりも遅い事を証明する手段と、
前記それぞれの暗号化アルゴリズムの記憶鍵を使用して、各々の暗号化値を処理する手段と、
各々のその後に生じる値と前記データの少なくともいくつかと比較し、前記データの少なくともいくつかを証明する手段と
を含むことを特徴とする受信機/デコーダ。
【請求項5】
前記受信機/デコーダは、更に若し前記データの発行された日付が以前に伝送されたデータの発行日付よりも遅くない場合には前記データを拒絶する手段を含んでいる事を特徴とする請求項4に記載の受信機/デコーダ。
【請求項6】
前記データは、ルート認証管理メッセージ(RCMM)を含んでいる事を特徴とする請求項4に記載の受信機/デコーダ。
【請求項7】
デジタル伝送システムで伝送されるデータを認証する方法であって、当該方法は、伝送より前に、
前記データの少なくともいくつかに対する少なくとも2つの暗号化値を決定するステップであって、各暗号化値がそれぞれの暗号化アルゴリズムの鍵を使用して同じデータのために決定されるステップと、
前記データが発行された日付を決定するステップと、
前記少なくとも2つの暗号化値と前記日付とを前記データと共に出力するステップと
から構成されている事を特徴とする方法。
【請求項8】
前記データは、ルート認証管理メッセージ(RCMM)を含んでいる事を特徴とする請求項7に記載の方法。
【請求項9】
デジタル伝送システムで伝送されるデータを認証する装置であって、当該装置は、
前記データの少なくともいくつかに対する少なくとも2つの暗号化値を決定する手段であって、各暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して同じデータに対して決定される手段と、
前記データが発行された日付を決定する手段と、
前記少なくとも2つの暗号化値と前記日付とを前記データと共に出力する手段と、
を含んでいる事を特徴とする装置。
【請求項10】
前記データは、ルート認証管理メッセージ(RCMM)を含んでいる事を特徴とする請求項9に記載の装置。
【請求項11】
デジタル信号であって、前記信号は、データ、前記データが発行された日付及び前記データの少なくともいくつかに対して決定された2つの暗号化値であって、各々の暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して同じデータに対して決定される値とを含んでいる事を特徴とするデジタル信号。
【請求項12】
前記データは、ルート認証管理メッセージ(RCMM)を含んでいる事を特徴とする請求項11に記載のデジタル信号。
【請求項13】
受信機/デコーダであって、前記受信機/デコーダは、
複数の鍵を格納する様に構成されている第1の記憶空間と、
データ、前記データが発行された日付及び前記データの少なくともいくつかに対して決定された少なくとも2つの暗号化値であって、各々の暗号化値が、それぞれの暗号化アルゴリズムの鍵を使用して同じデータに対して決定される値を受信する為の受信手段と、
プロセッサであって、当該プロセッサは、
前記データが発行された日付が以前に伝送されたデータの日付よりも遅い事を証明するステップと、
前記それぞれの暗号化アルゴリズムの記憶鍵を使用して、各々の暗号化値を処理するステップと、
各々のその後に生じる値と前記データの少なくともいくつかと比較し、前記データの少なくともいくつかを証明するステップと
を実行する様に構成されたプロセッサと
から構成されている事を特徴とする受信機/デコーダ。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公開番号】特開2007−6520(P2007−6520A)
【公開日】平成19年1月11日(2007.1.11)
【国際特許分類】
【出願番号】特願2006−216468(P2006−216468)
【出願日】平成18年8月9日(2006.8.9)
【分割の表示】特願2001−573687(P2001−573687)の分割
【原出願日】平成13年1月11日(2001.1.11)
【出願人】(502303843)カナル プラス テクノロジーズ ソシエテ アノニム (9)
【Fターム(参考)】
【公開日】平成19年1月11日(2007.1.11)
【国際特許分類】
【出願日】平成18年8月9日(2006.8.9)
【分割の表示】特願2001−573687(P2001−573687)の分割
【原出願日】平成13年1月11日(2001.1.11)
【出願人】(502303843)カナル プラス テクノロジーズ ソシエテ アノニム (9)
【Fターム(参考)】
[ Back to top ]