説明

プログラムデータファイル保存方法および認証プログラム実行方法

従来の技術では、プログラムのバージョンアップがあった場合、以前保存していたプログラムを全て削除し、新しいプログラムを保存し直し、新しいプログラムの起動時に認証し直す。一部だけのプログラムの変更のために全て保存と認証を行うのは時間を要し応答性が悪くなるという問題を有する。この課題を解決するために、プログラムの保存時に、以前保存していたプログラムとの差分抽出を行い、変更分のみ認証を行い保存する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ダウンロードしたプログラムの信用性を確認して保存し、信用性が確認されたプログラムを実行するプログラムデータファイル保存方法および認証プログラム実行方法に関する。特に、プログラムの更新と認証に関する。
【背景技術】
【0002】
デジタルテレビにおけるプログラムをダウンロードして、そのプログラムの信用性を確認・保証する機能は、DVB−MHP規格書“ETSI TS 101 812 V1.2.1 DVB−MHP仕様1.0.2”等に記載されている。ここでは、受信中の放送波に重畳されたプログラムに対し、改竄が行われていないかの検証と、そのプログラムが信用できる機関によって発行されたものであるかの検証を行う機能を有する。これにより、デジタルテレビにダメージを与えるような、書き換えられて本来とは異なる動作をするプログラムや、他人になりすました第三者のプログラムが起動されることを未然に防ぐことができる。
【0003】
またプログラムを更新する機能は、OCAP仕様(OCAP 1.0 Profile OC−SP−OCAP1.0−IF−I09−031121)に記載されている。ここでは、XAIT(プログラムに関して記述しているテーブル)でバージョンアップ(プログラムの記述内容が変わるごとにバージョンは上げられる)のシグナルを検知すると、以前にフラッシュROM等の2次記憶メモリーに保存していたプログラムのクラスやデータ等のファイル全てを削除し、バージョンアップしたプログラムのクラスやデータ等のファイル全てを保存して置き換える。
【0004】
一方、特開2000−259417号公報では、実行主体又は実行環境を構成するオブジェクトからの要求に基づいて、実行環境を構成するオブジェクトを削除する削除ステップと、外部システムから新たなオブジェクトを取り込む取込ステップとを行い、実行環境を構成するオブジェクトを置き換えすることができる。
【0005】
プログラムのバージョンアップが行なわれる場合、プログラムのクラスやデータ等のファイル全てが変更されていることはなく、部分的に変更されてバージョンアップされるのが通例である。しかしながら、従来の技術では、部分的な変更にもかかわらず、保存していたプログラムのクラスやデータ等のファイル全てを削除し、バージョンアップしたプログラムのクラスやデータ等のファイル全てを保存して置き換えなければならないので、保存に要する時間分だけ応答性が悪くなるという問題を有する。さらに、プログラムを不揮発性メモリーに一旦保存し、装置の電源のOFF/ON後にプログラムを起動する場合、起動直前にそのプログラムを認証する。この場合、プログラムの起動開始までには、暗号化された値を復号する等の計算が必要で、計算に要する時間の分だけ応答性が悪くなるという問題を有する。特に、プログラムが頻繁に起動される、もしくは、プログラムの容量規模が大きいような場合では、頻度と容量規模に比例して計算量が増えるので応答性が劣化していく。
【0006】
上記問題点を鑑みて、プログラムの更新時間を短縮し、プログラムの信用性を保証しながらも、プログラムの起動開始までに要する時間を短縮し、応答性の向上したデジタルテレビ等のプログラム認証装置を提供することが望まれる。
【発明の開示】
【0007】
本発明は、プログラムのバージョンアップ時に以前保存したプログラムとの差分抽出を行い、プログラムの保存直前に変更分のみ認証と更新を行い、プログラムの起動時には認証を一切しない、もしくは、一部のみ認証するだけでも、信用性の保証と応答性の向上が両立可能なプログラムデータファイル保存方法および認証プログラム実行方法を提供することを目的とする。
【0008】
前記従来の課題を解決するために、本発明に係るプログラムデータファイル保存方法は、第1のトランスポートストリームに含まれる第1のプログラムのデータファイルの保存に関する情報に従い、前記第1のプログラムのデータファイルを認証し放送受信装置に保存する第1のステップと、第2のトランスポートストリームに含まれる第2のプログラムのデータファイルの保存に関する情報を受信する第2のステップと、前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルがある場合、該当する第2のプログラムのデータファイルのハッシュ値を前記第2のプログラムに含まれ、前記該当する第2のプログラムのデータファイルに対応するハッシュファイルに格納されたハッシュ値に一致するかどうかを検証する第3のステップと、前記第2のプログラムに含まれる証明書ファイルの有効性を検証する第4のステップと、前記第2のプログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記第2のプログラム含まれる署名ファイルの署名値を復号した値と、前記第2のプログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第5のステップと、前記第3のステップにてハッシュ値が一致し、第4のステップにて前記証明書ファイルが有効であると判定され、第5のステップにおいてハッシュ値が一致すると判定された場合に前記第2のプログラムを認証し、前記第2のプログラムのデータファイルの保存に関する情報に従い前記第2のプログラムを保存する第6のステップとを有することを特徴とする。
【0009】
これによって、プログラムの認証時間と更新時間を短縮することができる。
また、前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルとは、前記第1のプログラムの保存時に認証されたデータファイルを更新するデータファイルであってもよい。
【0010】
これによって、第1のプログラムのデータファイルを、例えばバージョンアップされた第2のプログラムのデータファイルを用いて更新することができる。
【0011】
また、前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルとは、前記第1のプログラムの保存時に認証されたデータファイルとは異なる新規のデータファイルであってもよい。
【0012】
これによって、例えばバージョンアップされた第2のプログラムで追加されたデータファイルを保存することができる。
【0013】
また、前記プログラムがディレクトリ構造を有する場合には、各ディレクトリに含まれる前記データファイルと、対応する前記ハッシュファイルとは同一ディレクトリ内に存在し、前記第3のステップは前記該当する第2のプログラムのデータファイルが存在するディレクトリ毎に実行されてもよい。
【0014】
これによって、各ディレクトリに含まれるデータファイルごとに、データファイルのハッシュ値がデータファイルに対応するハッシュファイルに格納されたハッシュ値と一致するかどうかをチェックすることができる。
【0015】
また、前記第4のステップは、前記第2のプログラム含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致するかどうかを検証する第7のステップを有し、前記第2のプログラムに関連する証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致する場合、前記証明書ファイルが有効であると判定してもよい。
【0016】
ここで、前記第4のステップは、さらに、前記第2のプログラムに含まれる証明書ファイル中の証明書の有効期限をチェックする第8のステップを有し、前記第2のプログラムに関連する証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致し、認証日時が前記証明書ファイル中の証明書の有効期間内にある場合、前記証明書ファイルが有効であると判定してもよい。
【0017】
これによって、ルート証明書が一致しない、または証明書の有効期間が過ぎてしまったプログラムを保存するのを防止することができる。
【0018】
また、本発明に係る認証プログラム実行方法は、第1のトランスポートストリームに含まれる第1のプログラムのデータファイルの保存に関する情報に従い、前記第1のプログラムのデータファイルを認証し放送受信装置に保存する第1のステップと、第2のトランスポートストリームに含まれる第2のプログラムのデータファイルの保存に関する情報を受信する第2のステップと、前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルがある場合、該当する第2のプログラムのデータファイルのハッシュ値を前記第2のプログラムに含まれ、前記該当する第2のプログラムのデータファイルに対応するハッシュファイルに格納されたハッシュ値に一致するかどうかを検証する第3のステップと、前記第2のプログラムに含まれる証明書ファイルの有効性を検証する第4のステップと、前記第2のプログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記第2のプログラム含まれる署名ファイルの署名値を復号した値と、前記第2のプログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第5のステップと、前記第3のステップにてハッシュ値が一致し、第4のステップにて前記証明書ファイルが有効であると判定され、第5のステップにおいてハッシュ値が一致すると判定された場合に前記第2のプログラムを認証し、前記第2のプログラムのデータファイルの保存に関する情報に従い前記第2のプログラムを保存する第6のステップと、前記第2のプログラムを実行する場合、前記保存した前記第2のプログラムに関連する証明書ファイルの有効性を検証する第9のステップと、前記第9のステップにて、前記保存した第2のプログラムに含まれる証明書ファイルが有効であると判定された場合にのみ前記保存した第2のプログラムを再度認証し、実行する実行ステップとを有することを特徴とする。
【0019】
これによって、プログラムの認証時間と更新時間を短縮することができる。さらに、プログラムの信用性を確保しながら起動開始までに要する時間を短縮することができる。
【0020】
また、前記第9のステップは、前記保存したプログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致するかどうかを検証する第10のステップを有し、前記保存した第2のプログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致する場合、前記証明書ファイルが有効であると判定してもよい。
【0021】
ここで、前記第9のステップは、前記保存したプログラムに含まれる証明書ファイル中の証明書の有効期限をチェックする第11のステップを有し、前記保存した第2のプログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致し、実行日時が前記証明書ファイル中の証明書の有効期間内にある場合、前記証明書ファイルが有効であると判定してもよい。
【0022】
これによって、ルート証明書が一致しない、または証明書の有効期間が過ぎてしまったプログラムを実行するのを防止することができる。
【0023】
さらに、本発明は、このようなプログラムデータファイル保存方法および認証プログラム実行方法として実現することができるだけでなく、このようなプログラムデータファイル保存方法および認証プログラム実行方法が含む特徴的なステップを手段として備えるプログラム保存装置および認証プログラム実行装置として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、CD−ROM等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。
【0024】
以上の説明から明らかなように、本発明に係るプログラムデータファイル保存方法によれば、プログラムの認証時間と更新時間を短縮することができる。また、本発明に係る認証プログラム実行方法によれば、プログラムの信用性を確保しながら起動開始までに要する時間を短縮することができる。
【発明を実施するための最良の形態】
【0025】
以下本発明の実施の形態について、図面を参照しながら説明する。
【0026】
(実施の形態1)
本発明に係るケーブルテレビシステムの実施の形態を、図面を参照しながら説明する。図1は、ケーブルシステムを構成する装置の関係を表したブロック図であり、ヘッドエンド101及び3個の端末装置A111、端末装置B112、端末装置C113で構成される。本実施の形態では、1つのヘッドエンドに対して3つの端末装置が結合されているが、任意の数の端末装置をヘッドエンドに結合しても、本発明は実施可能である。
【0027】
ヘッドエンド101は、複数の端末装置に対して映像・音声・データ等の放送信号を送信するとともに、端末装置からのデータ送信を受信する。これを実現するため、ヘッドエンド101と端末装置A111、端末装置B112、端末装置C113間の伝送に用いられる周波数帯域は、分割して用いられる。
【0028】
図2は、周波数帯域の分割の一例を示す表である。周波数帯域は、Out Of Band(略称OOB)とIn−Bandの2種類に大別される。5〜130MHzがOOBに割り当てられ、主にヘッドエンド101と端末装置A111、端末装置B112、端末装置C113間のデータのやり取りに使用される。130MHz〜864MHzはIn−Bandに割り当てられ、主として、映像・音声を含む放送チャンネルに使用される。OOBではQPSK変調方式が、In−BandはQAM64変調方式が使用される。変調方式技術については、本発明に関与が薄い公知技術であるので、詳細な説明は省略する。
【0029】
図3は、OOB周波数帯域の更に詳細な使用の一例である。70MHz〜74MHzはヘッドエンド101からのデータ送信に使用され、全ての端末装置A111、端末装置B112、端末装置C113が、ヘッドエンド101から同じデータを受け取ることになる。一方、10.0MHz〜10.1MHzは端末装置A111からヘッドエンド101へのデータ送信に使用され、10.1MHz〜10.2MHzは端末装置B112からヘッドエンド101へのデータ送信に使用され、10.2MHz〜10.3MHzは端末装置C113からヘッドエンド101へのデータ送信に使用される。これにより、各端末装置固有のデータを各端末装置A111、端末装置B112、端末装置C113からヘッドエンド101に送信することができる。
【0030】
図4は、In−Bandの周波数帯に対する使用の一例である。150〜156MHzと156〜162MHzはそれぞれテレビチャンネル1とテレビチャンネル2に割り当てられ、以降、6MHz間隔でテレビチャンネルが割り当てられている。310MHz以降は、1MHz単位でラジオチャンネルに割り当てられている。これらの各チャンネルはアナログ放送として使用してもデジタル放送として使用してもよい。デジタル放送の場合は、MPEG2仕様に基づいたトラスポートパケット形式で伝送され、音声や映像に加え、各種データ放送用データも送信することができる。
【0031】
ヘッドエンド101は、これらの周波数帯域に適切な放送信号を送信するため、QPSK変調部やQAM変調部等を有する。また、端末装置からのデータを受信するため、QPSK復調器を有する。また、ヘッドエンド101は、これら変調部及び復調部に関連する様々な機器を有すると考えられる。しかし、本発明は主として端末装置に関わるので、詳細な説明は省略する。
【0032】
端末装置A111、端末装置B112、端末装置C113は、ヘッドエンド101からの放送信号を受信し再生する。また、ヘッドエンド101に対して、各端末装置固有のデータを送信する。3つの、端末装置は本実施の形態では同じ構成を取る。
【0033】
図5は、端末装置のハードウエア構成を表すブロック図である。500は端末装置であり、QAM復調部501、QPSK復調部502、QPSK変調部503、TSデコーダ505、オーディオデコーダ506、スピーカ507、ビデオデコーダ508、ディスプレイ509、2次記憶部510、1次記憶部511、ROM512、入力部513、CPU514で構成される。また端末装置500には、POD504が着脱できる。
【0034】
図6は、端末装置500の外観の一例である薄型テレビである。端末装置は様々な構成で実現できるが、本実施例ではOpenCable(R)及びOCAPに基づいて構成された端末装置を例にとって説明する。
【0035】
601は、薄型テレビの筐体であり、POD504を除く、端末装置500の構成要素をすべて内蔵している。
【0036】
602はディスプレイであり、図5におけるディスプレイ509に相当する。
603は複数のボタンで構成されるフロントパネル部であり、図5の入力部513に相当する。
【0037】
604は信号入力端子であり、ヘッドエンド101との信号の送受信を行うためにケーブル線を接続する。信号入力端子は、図5のQAM復調部501、QPSK復調部502、QPSK変調部503と接続されている。
【0038】
605は、図5のPOD504に相当するPODカードである。POD504は、図6のPODカード605のように、端末装置500とは独立した形態を取り、端末装置500に着脱可能となっている。POD504の詳細は後述する。
【0039】
606はPODカード605を挿入する挿入スロットである。
図5を参照して、QAM復調部501は、CPU514から指定された周波数を含むチューニング情報で、ヘッドエンド101でQAM変調され送信されてきた信号を復調し、POD504に引き渡す。
【0040】
QPSK復調部502は、CPU514から指定された周波数を含むチューニング情報で、ヘッドエンド101でQPSK変調され送信されてきた信号を復調し、POD504に引き渡す。
【0041】
QPSK変調部503は、CPU514から指定された周波数を含む復調情報で、POD504から渡された信号をQPSK復調し、ヘッドエンド101に送信する。
【0042】
POD504は、図6のように端末装置本体500から着脱可能な形態をしている。端末本体500とPOD504の接続インターフェースは、OpenCable(R) CableCARD(R) Interface Specification(OC−SP−CC−IF−I15−031121)及び、この仕様書から参照されている仕様書で定義されている。なお、仕様書のCableCARDとはPODのことを指している。ここでは、詳細は省略し、本発明に関する部分のみを解説する。
【0043】
図7は、POD504の内部構成を表すブロック図である。POD504は、第1デスクランブラ部701、第2デスクランブラ部702、スクランブラ部703、第1記憶部704、第2記憶部705、CPU706で構成される。
【0044】
第1デスクランブラ部701は、CPU706からの指示により、端末装置500のQAM復調部501から暗号化された信号を受け取り、復号を行う。そして、復号された信号を端末装置500のTSデコーダ505に送る。デコードに必要な鍵などの情報はCPU706から適宜与えられる。具体的には、ヘッドエンド101はいくつかの有料チャンネルを放送している。ユーザーが、この有料チャンネルを購買すると、第1デスクランブラ部701は、CPU706から鍵等の必要な情報を受け取りデスクランブルすることで、ユーザーは有料チャンネルを閲覧することができる。鍵などの必要な情報が与えられない場合は、第1デスクランブラ部701は、デスクランブルを行わず、受け取った信号をそのまま、TSデコーダ505に送る。
【0045】
第2デスクランブラ部702は、CPU706からの指示により、端末装置500のQPSK復調部502から暗号化された信号を受け取り、復号を行う。そして、復号されたデータをCPU706に引き渡す。
【0046】
スクランブラ部703は、CPU706からの指示により、CPU706から受け取ったデータを暗号化し、端末装置500のQPSK変調部503に送る。
【0047】
第1記憶部704は、具体的にはRAM等の1次記憶メモリーで構成され、CPU706が処理を行う際、一時的にデータを保存するために使用される。
【0048】
第2記憶部705は、具体的にはフラッシュROM等の2次記憶メモリーで構成され、CPU706が実行するプログラムを格納し、また、電源OFFになっても消去されては困るデータの保存に使用される。
【0049】
CPU706は、第2記憶部705が記憶するプログラムを実行する。プログラムは複数のサブプログラムで構成される。図8は、第2記憶部705が記憶するプログラムの一例である。図8では、プログラム800は、メインプログラム801、初期化サブプログラム802、ネットワークサブプログラム803、再生サブプログラム804、PPVサブプログラム805等複数のサブプログラムで構成されている。
【0050】
ここでPPVとはPay Per Viewの略であり、映画など特定の番組を有料で視聴できるようにするサービスである。ユーザーが暗証番号を入力すると、購入したことがヘッドエンド101に通知され、スクランブルが解除され、視聴することが出来る。この視聴により、ユーザーは後日、購入代金を支払うものである。
【0051】
メインプログラム801は、CPU706が電源投入時に最初に起動するサブプログラムであり、他のサブプログラムの制御を行う。
【0052】
初期化サブプログラム802は、電源投入時にメインプログラム801によって起動され、端末装置500との情報交換等を行い、初期化処理を行う。初期化処理の詳細は、OpenCable(R) CableCARD(R) Interface Specification(OC−SP−CC−IF−I15−031121)及び、この仕様書から参照されている仕様書で定義されている。また、仕様書に定義されていない初期化処理も行う。ここでは、その一部を紹介する。電源が投入されると、初期化サブプログラム802は、第2記憶部705が記憶する第1の周波数を端末装置500のCPU514を通して、QPSK復調部502に通知する。QPSK復調部502は、与えられた第1の周波数でチューニングを行い、信号を第2デスクランブラ部702に送る。また、初期化サブプログラム802は、第2記憶部705が記憶する第1の鍵等の復号情報を第2デスクランブラ部702に与える。その結果、第2デスクランブラ部702は、デスクランブルを行い、初期化サブプログラム802を実行するCPU706に引き渡す。よって、初期化サブプログラム802は情報を受け取ることができる。本実施の形態では、初期化サブプログラム802はネットワークサブプログラム803を通して情報を受け取ることとする。詳細は後述する。
【0053】
また、初期化サブプログラム802は、第2記憶部705が記憶する第2の周波数を端末装置500のCPU514を通して、QPSK変調部503に通知する。初期化サブプログラム802は第2記憶部705が記憶する暗号化情報をスクランブラ部703に与える。初期化サブプログラム802が送信したい情報を、ネットワークサブプログラム803を介して、スクランブラ部703に与えると、スクランブラ部703は、与えられた暗号化情報を用いて、データを暗号化し、端末装置500のQPSK変調部503に与える。QPSK変調部503は、与えられた暗号化された情報を変調し、ヘッドエンド101に送信する。
【0054】
この結果、初期化サブプログラム802は、端末装置500、第2デスクランブラ部702、スクランブラ部703、ネットワークサブプログラム803を通して、ヘッドエンド101と双方向通信を行うことができる。
【0055】
ネットワークサブプログラム803は、メインプログラム801、初期化サブプログラム802等の複数のサブプログラムから使用される、ヘッドエンド101との双方向通信を行うためのサブプログラムである。具体的には、ネットワークサブプログラム803を使用する他のサブプログラムに対して、TCP/IPによって、ヘッドエンド101と双方向通信を行っているように振舞う。TCP/IPは、複数の装置間で情報交換を行うためのプロトコルを規定した公知の技術であり、詳細な説明は省略する。ネットワークサブプログラム803は、電源投入時に初期化サブプログラム802に起動されると、予め第2記憶部705が記憶しているPOD504を識別する識別子であるMACアドレス(Media Access Controlアドレスの略)を、端末装置500を通してヘッドエンド101に通知し、IPアドレスの取得を要求する。ヘッドエンド101は、端末装置500を介してPOD504にIPアドレスを通知し、ネットワークサブプログラム803は、IPアドレスを第1記憶部704に記憶する。以降、ヘッドエンド101とPOD504は、このIPアドレスを、POD504の識別子として使用し、通信を行う。
【0056】
再生サブプログラム804は、第2記憶部705が記憶する第2の鍵等の復号情報や、端末装置500から与えられる第3の鍵等の復号情報を第1デスクランブラ部701に与えて、デスクランブルを可能にする。また、ネットワークサブプログラム803を通して、第1デスクランブラ部701に入力されている信号が、PPVチャンネルであることの情報を受け取る。PPVチャンネルと知ったときは、PPVサブプログラム805を起動する。
【0057】
PPVサブプログラム805は、起動されると、端末装置500に番組の購入を促すメッセージを表示し、ユーザーの入力を受け取る。具体的には、端末装置500のCPU514に画面に表示したい情報を送ると、端末装置500のCPU514上で動作するプログラムが、端末装置500のディスプレイ509上にメッセージを表示する。ユーザーは、端末装置500の入力部513を通して暗証番号を入力すると、端末装置500のCPU514が、それを受け取り、POD504のCPU706上で動作するPPVサブプログラム805に通知する。PPVサブプログラム805は、受け取った暗証番号をネットワークサブプログラム803を通してヘッドエンド101に送信する。ヘッドエンド101は、暗証番号が正しければ、復号に必要な第4の鍵などの復号化情報をネットワークサブプログラム803を介して、PPVサブプログラム805に通知する。PPVサブプログラム805は受け取った第4の鍵などの復号化情報を第1デスクランブラ部701に与え、第1デスクランブラ部701は、入力されている信号をデスクランブルする。
【0058】
図5を参照して、TSデコーダ505は、POD504から受け取った信号のフィルタリングを実施し、必要なデータをオーディオデコーダ506及びビデオデコーダ508、CPU514に引き渡す。ここで、POD504から来る信号はMPEG2トランスポートストリームである。MPEG2トランスポートストリームの詳細はMPEG規格書 ISO/IEC138181−1に記載されており、本実施の形態では詳細は省略する。MPEG2トランスポートストリームは、複数の固定長パケットで構成され、各パケットには、パケットIDが振られている。図9はパケットの構成図である。900はパケットであり、固定長の188バイトで構成される。先頭4バイトがヘッダー901で、パケットの識別情報を格納しており、残り184バイトがペイロード902で、送信したい情報を含んでいる。903は、ヘッダー901の内訳である。先頭から12ビット目〜24ビット目までの13ビットにパケットIDが含まれている。図10は送られてくる複数のパケットの列を表現した模式図である。パケット1001は、ヘッダーにパケットID「1」を持ち、ペイロードには映像Aの1番目の情報が入っている。パケット1002は、ヘッダーにパケットID「2」を持ち、ペイロードには音声Aの1番目の情報が入っている。パケット1003は、ヘッダーにパケットID「3」を持ち、ペイロードには音声Bの1番目の情報が入っている。
【0059】
パケット1004は、ヘッダーにパケットID「1」を持ち、ペイロードには映像Aの2番目の情報が入っており、これはパケット1001の続きになっている。同様にパケット1005、1026、1027も他のパケットの後続データを格納している。このように、同じパケットIDを持つ、パケットのペイロードの内容を連結すると、連続した映像や音声を再現することができる。
【0060】
図10を参照して、CPU514がパケットID「1」と出力先として「ビデオデコーダ508」をTSデコーダ505に指示すると、TSデコーダ505はPOD504から受け取ったMPEG2トランスポートストリームからパケットID「1」のパケットを抽出し、ビデオデコーダ508に引き渡す。図10においては、映像データのみをビデオデコーダ508に引き渡すことになる。同時に、CPU514がパケットID「2」と「オーディオデコーダ506」をTSデコーダ505に指示すると、TSデコーダ505はPOD504から受け取ったMPEG2トランスポートストリームからパケットID「2」のパケットを抽出し、オーディオデコーダ506に引き渡す。図10においては、音声データのみをビデオデコーダ508に引き渡すことになる。
【0061】
このパケットIDに応じて必要なパケットだけを取り出す処理が、TSデコーダ505が行うフィルタリングである。TSデコーダ505はCPU514から指示された複数のフィルタリングを同時に実行することができる。
【0062】
図5を参照して、オーディオデコーダ506は、TSデコーダ505から与えられたMPEG2トランスポートストリームのパケットに埋め込まれたオーディオデータを連結し、デジタル−アナログ変換を行いスピーカ507に出力する。
【0063】
スピーカ507は、オーディオデコーダ506から与えられた信号を音声出力する。
ビデオデコーダ508は、TSデコーダ505から与えられたMPEG2トランスポートストリームのパケットに埋め込まれたビデオデータを連結し、デジタル−アナログ変換を行いディスプレイ509に出力する。
【0064】
ディスプレイ509は、具体的にはブラウン管や液晶等で構成され、ビデオデコーダ508から与えられたビデオ信号を出力したり、CPU514から指示されたメッセージを表示したりする。
【0065】
2次記憶部510は、具体的には、フラッシュメモリーやハードディスク等で構成され、CPU514から指示されたデータやプログラムを保存したり削除したりする。また、保存されているデータやプログラムはCPU514に参照される。保存されているデータやプログラムは、端末装置500の電源が切断された状態でも保存しつづける。
【0066】
1次記憶部511は、具体的には、RAM等で構成され、CPU514から指示されたデータやプログラムを1次的に保存したり削除したりする。また、保存されているデータやプログラムはCPU514に参照される。保存されているデータやプログラムは、端末装置500の電源が切断された際に、抹消される。
【0067】
ROM512は、書き換え不可能なメモリーデバイスであり、具体的にはROMやCD−ROM、DVDなどで構成される。ROM512は、CPU514が実行するプログラムが格納されている。
【0068】
入力部513は、具体的には、フロントパネルやリモコンで構成され、ユーザーからの入力を受け付ける。図11は、フロントパネルで入力部513を構成した場合の一例である。1100はフロントパネルであり、図6のフロントパネル部603に相当する。フロントパネル1100は7つのボタン、上カーソルボタン1101、下カーソルボタン1102、左カーソルボタン1103、右カーソルボタン1104、OKボタン1105、取消ボタン1106、EPGボタン1107を備えている。ユーザーがボタンを押下すると、押下されたボタンの識別子が、CPU514に通知される。
【0069】
CPU514は、ROM512が記憶するプログラムを実行する。実行するプログラムの指示に従い、QAM復調部501、QPSK復調部502、QPSK変調部503、POD504、TSデコーダ505、ディスプレイ509、2次記憶部510、1次記憶部511、ROM512を制御する。
【0070】
図12は、ROM512に記憶され、CPU514に実行されるプログラムの構成図の一例である。
【0071】
プログラム1200は、複数のサブプログラムで構成され、具体的にはOS1201、EPG1202、Java(登録商標)VM1203(以後VM1203と称す)、サービスマネージャ1204、Javaライブラリ1205(以後ライブラリ1205と称す)で構成される。
【0072】
OS1201は、端末装置500の電源が投入されると、CPU514が起動するサブプログラムである。OS1201は、オペレーティングシステムの略であり、Linux等が一例である。OS1201は、他のサブプログラムを平行して実行するカーネル1201a及びライブラリ1201bで構成される公知の技術の総称であり、詳細な説明は省略する。本実施の形態においては、OS1201のカーネル1201aは、EPG1202とVM1203をサブプログラムとして実行する。また、ライブラリ1201bは、これらサブプログラムに対して、端末装置500が保持する構成要素を制御するための複数の機能を提供する。
【0073】
機能の一例として、チューニング機能を紹介する。チューニング機能は、他のサブプログラムから周波数を含むチューニング情報を受け取り、それをQAM復調部501に引き渡す。QAM復調部501は与えられたチューニング情報に基づき復調処理を行い、復調したデータをPOD504に引き渡すことができる。この結果、他のサブプログラムはライブラリ1201bを通してQAM復調器を制御することができる。
【0074】
EPG1202は、ユーザーに番組一覧を表示及び、ユーザーからの入力を受け付ける番組表示部1202aと、チャンネル選局を行う再生部1102bで構成される。ここで、EPGはElectric Program Guideの略である。EPG1202は、端末装置500の電源が投入されると、カーネル1201aによって起動される、起動されたEPG1202の内部では、番組表示部1202aが端末装置500の入力部513を通して、ユーザーからの入力を待つ。ここで、入力部513が図11で示されるフロントパネルで構成されている場合、ユーザーが、入力部513のEPGボタン1107を押下すると、EPGボタンの識別子がCPU514に通知される。CPU514上で動作するサブプログラムであるEPG1202の番組表示部1202aは、この識別子を受け取り、番組情報をディスプレイ509に表示する。図13A及び図13Bは、ディスプレイ509に表示された番組表の一例である。図13Aを参照して、ディスプレイ509には、格子状に番組情報が表示されている。列1301には、時刻情報が表示されている。列1302には、チャンネル名「チャンネル1」と、列1301の時刻に対応する時間帯に放映される番組が表示されている。「チャンネル1」では、9:00〜10:30に番組「ニュース9」が放映され、10:30〜12:00は「映画AAA」が放映されることを表す。列1303も列1302同様、チャンネル名「チャンネル2」と、列1301の時刻に対応する時間帯に放映される番組が表示されている。9:00〜11:00に番組「映画BBB」が放映され、11:00〜12:00は「ニュース11」が放映される。1330は、カーソルである。カーソル1330は、フロントパネル1100の左カーソル1103と右カーソル1104を押下すると移動する。図13Aの状態で、右カーソル1104を押下すると、カーソル1330は右に移動し、図13Bのようになる。また、図13Bの状態で、左カーソル1103を押下すると、カーソル1330は左に移動し、図13Aのようになる。
【0075】
図13Aの状態で、フロントパネル1100のOKボタン1105が押下されると、番組表示部1202aは、「チャンネル1」の識別子を再生部1102bに通知する。図13Bの状態で、フロントパネル1100のOKボタン1105が押下されると、番組表示部1202aは、「チャンネル2」の識別子を再生部1102bに通知する。
【0076】
また、番組表示部1202aは、表示する番組情報を、POD504を通してヘッドエンド101から定期的に、1次記憶部511に記憶しておく。一般的に、ヘッドエンドからの番組情報の取得は時間が掛かる。入力部513のEPGボタン1107が押下された時、1次記憶部511に予め保存された番組情報を表示することで、素早く番組表を表示することができる。
【0077】
再生部1102bは、受け取ったチャンネルの識別子を用いて、チャンネルを再生する。チャンネルの識別子とチャンネルの関係は、チャンネル情報として、2次記憶部510に予め格納されている。図14は2次記憶部510に格納されているチャンネル情報の一例である。チャンネル情報は表形式で格納されている。列1401は、チャンネルの識別子である。列1402は、チャンネル名である。列1403はチューニング情報である。ここで、チューニング情報は周波数や転送レート、符号化率などを含み、QAM復調部501に与える値である。列1404はプログラムナンバーである。プログラムナンバーとは、MPEG2規格で規定されているPMTを識別するための番号である。PMTに関しては、後述する。行1411〜1414の各行は、各チャンネルの識別子、チャンネル名、チューニング情報の組となる。行1411は識別子が「1」、チャンネル名が「チャンネル1」、チューニング情報に周波数「312MHz」、プログラムナンバーが「101」を含む組となっている。再生部1102bは、チャンネルの再生を行うため、受け取ったチャンネルの識別子をそのままサービスマネージャに引き渡す。
【0078】
また、再生部1102bは、再生中に、ユーザーがフロントパネル1100の上カーソル1101と下カーソル1102を押下すると、入力部513からCPU514を通して、押下された通知を受け取り、再生しているチャンネルを変更する。まず、再生部1102bは、1次記憶部511に現在再生中のチャンネルの識別子を記憶する。図15A、図15B及び図15Cは、1次記憶部511に保存しているチャンネルの識別子の例である。図15Aでは識別子「3」が記憶されており、図14を参照し、チャンネル名「TV 3」のチャンネルが再生中であることを示す。図15Aの状態で、ユーザーが上カーソル1101を押下すると再生部1102bは、図14のチャンネル情報を参照し、表中の前のチャンネルであるチャンネル名「チャンネル2」のチャンネルに再生を切り変えるため、サービスマネージャにチャンネル名「チャンネル2」の識別子「2」を引き渡す。同時に、1次記憶部511に記憶されているチャンネル識別子「2」に書き換える。図15Bは、チャンネル識別子が書き換えられた状態を表す。また、図15Aの状態で、ユーザーが下カーソル1102を押下すると再生部1102bは、図14のチャンネル情報を参照し、表中の次のチャンネルであるチャンネル名「TV Japan」のチャンネルに再生を切り変えるため、サービスマネージャにチャンネル名「TV Japan」の識別子「4」を引き渡す。同時に、1次記憶部511に記憶されているチャンネル識別子「4」に書き換える。図15Cは、チャンネル識別子が書き換えられた状態を表す。
【0079】
VM1203は、Java言語で記述されたプログラムを逐次解析し実行するJavaバーチャルマシンである。Java言語で記述されたプログラムはバイトコードと呼ばれる、ハードウエアに依存しない中間コードにコンパイルされる。Javaバーチャルマシンは、このバイトコードを実行するインタープリタである。また、一部のJavaバーチャルマシンは、バイトコードをCPU514が理解可能な実行形式に翻訳してから、CPU514に引き渡し、実行することも行う。VM1203は、カーネル1201aに実行するJavaプログラムを指定され起動される。本実施の形態では、カーネル1201aは、実行するJavaプログラムとしてサービスマネージャ1204を指定する。Java言語の詳細は、書籍「Java Language Specification(ISBN 0−201−63451−1)」等の多くの書籍で解説されている。ここでは、その詳細を省略する。また、JavaVM自体の詳細な動作などは、「Java Virtual Machine Specification(ISBN 0−201−63451―X)」等の多くの書籍で解説されている。ここでは、その詳細を省略する。
【0080】
サービスマネージャ1204は、Java言語で書かれたJavaプログラムであり、VM1203によって逐次実行される。サービスマネージャ1204は、JNI(Java Native Interface)を通して、Java言語で記述されていない他のサブプログラムを呼び出したり、または、呼び出されたりすることが可能である。JNIに関しても、書籍「Java Native Interface」等の多くの書籍で解説されている。ここでは、その詳細を省略する。
【0081】
サービスマネージャ1204は、JNIを通して、再生部1102bよりチャンネルの識別子を受け取る。
【0082】
サービスマネージャ1204は、最初にライブラリ1205の中にあるTuner1205cに、チャンネルの識別子を引き渡し、チューニングを依頼する。Tuner1205cは、2次記憶部510が記憶するチャンネル情報を参照し、チューニング情報を獲得する。今、サービスマネージャ1204がチャンネルの識別子「2」をTuner1205cに引き渡すと、Tuner1205cは、図14の列1412を参照して、対応するチューニング情報「156MHz,」を獲得する。Tuner1205cは、OS1201のライブラリ1201bを通して、QAM復調部501にチューニング情報を引き渡す。QAM復調部501は与えられたチューニング情報に従ってヘッドエンド101から送信されてきた信号を復調し、POD504に引き渡す。
【0083】
次にサービスマネージャ1204は、ライブラリ1205の中にあるCA1205bにデスクランブルを依頼する。CA1205dは、OS1201のライブラリ1201bを通して復号に必要な情報をPOD504に与える。POD504は、与えられた情報を元に、QAM復調部501から与えられた信号を復号しTSデコーダ505に引き渡す。
【0084】
次にサービスマネージャ1204は、ライブラリ1205の中にあるJMF1205aにチャンネルの識別子を与え、映像・音声の再生を依頼する。
【0085】
まず、最初にJMF1205aは、再生すべき映像と音声を特定するためのパケットIDをPAT、PMTから取得する。PATやPMTはMPEG2規格で規定されている、MPEG2トランスポートストリーム内の番組構成を表現するテーブルであり、MPEG2トランスポートストリームに含まれるパケットのペイロードに埋め込まれて、音声や映像と共に送信されるものである。詳細は規格書を参照されたい。ここでは、概略のみ説明する。
【0086】
PATは、Program Association Tableの略で、パケットID「0」のパケットに格納され送信されている。JMF1205aは、PATを取得するため、OS1201のライブラリ1201bを通して、TSデコーダ505にパケットID「0」とCPU514を指定する。TSデコーダ505がパケットID「0」でフィルタリングを行い、CPU514に引き渡すことでJMF1205aは、PATのパケットを収集する。図16は、収集したPATの情報の一例を模式的に表した表である。列1601は、プログラムナンバーである。列1602は、パケットIDである。列1602のパケットIDはPMTを取得するために用いられる。行1611〜1613は、チャンネルのプログラムナンバーと対応するパケットIDの組である。ここでは、3つのチャンネルが定義されている。行1611はプログラムナンバー「101」とパケットID「501」の組が定義されている。今、JMF1205aに与えられたチャンネルの識別子が「2」とすると、JMF1205aは、図14の列1412を参照して、対応するプログラムナンバー「102」を獲得し、次に、図16のPATの列1612を参照し、プログラムナンバー「102」に対応するパケットID「502」を獲得する。PMTは、Program Map Tableの略で、PATで規定されたパケットIDのパケットに格納され送信されている。JMF1205aは、PMTを取得するため、OS1201のライブラリ1201bを通して、TSデコーダ505にパケットIDとCPU514を指定する。ここで、指定するパケットIDは「502」とする。TSデコーダ505がパケットID「502」でフィルタリングを行い、CPU514に引き渡すことでJMF1205aは、PMTのパケットを収集する。
【0087】
図17は、収集したPMTの情報の一例を模式的に表した表である。列1701は、ストリーム種別であり。列1702は、パケットIDである。列1702で指定されるパケットIDのパケットには、ストリーム種別で指定された情報がペイロードに格納され送信されている。列1703は補足情報である。行1711〜1714はエレメンタリーストリームと呼ばれる、パケットIDと送信している情報の種別の組である。行1711は、ストリーム種別「音声」とパケットID「5011」の組であり、パケットID「5011」のペイロードには音声が格納されていることを表す。JMF1205aは、PMTから再生する映像と音声のパケットIDを獲得する。図17を参照して、JMF1205aは、行1711から音声のパケットID「5011」を、行1712から映像のパケットID「5012」を獲得する。
【0088】
次に、JMF1205aは、OS1201のライブラリ1201bを通して、獲得した音声のパケットIDと出力先としてオーディオデコーダ506、映像のパケットIDと出力先としてビデオデコーダ508の組を、TSデコーダ505に与える。TSデコーダ505は与えられたパケットIDと出力先に基づいて、フィルタリングを行う。ここではパケットID「5011」のパケットをオーディオデコーダ506に、パケットID「5012」のパケットをビデオデコーダ508に引き渡す。オーディオデコーダ506は、与えられたパケットのデジタル−アナログ変換を行いスピーカ507を通して音声を再生する。ビデオデコーダ508は、与えられたパケットのデジタル−アナログ変換を行いディスプレイ509に映像を表示する。
【0089】
最後にサービスマネージャ1204は、ライブラリ1205の中にあるAM1205bにチャンネルの識別子を与え、データ放送再生を依頼する。ここで、データ放送再生とは、MPEG2トランスポートストリームに含まれるJavaプログラムを抽出し、VM1203に実行させることである。MPEG2トランスポートストリームにJavaプログラムを埋め込む方法は、MPEG規格書ISO/IEC138181−6に記述されたDSMCCという方式を用いる。ここではDSMCCの詳細な説明は省略する。DSMCC方式は、MPEG2トランスポートストリームのパケットの中に、コンピュータで使用されているディレクトリやファイルで構成されるファイルシステムをエンコードする方法を規定している。また、実行するJavaプログラムの情報はAITと呼ばれる形式で、MPEG2トランスポートストリームのパケットの中に埋め込まれ送信されている。AITは、DVB−MHP規格(正式には、ETSI TS 101 812 DVB−MHP仕様V1.0.2)の10章に定義されている、Application Information Tableの略である。
【0090】
AM1205bは、まず、AITを獲得するため、JMF1205a同様PAT、PMTを取得し、AITが格納されているパケットのパケットIDを獲得する。今、与えられたチャンネルの識別子が「2」で、図16のPAT、図17のPMTが送信されていると、JMF1205aと同様の手順で、図17のPMTを獲得する。AM1205bは、PMTからストリーム種別が「データ」で補足情報として「AIT」を持つエレメンタリーストリームからパケットIDを抽出する。図17を参照して、行1713のエレメンタリーストリームが該当し、パケットID「5013」を獲得する。
【0091】
AM1205bは、OS1201のライブラリ1201bを通してTSデコーダ505にAITのパケットIDと出力先CPU514を与える。TSデコーダ505は、与えられたパケットIDでフィルタリングを行い、CPU514に引き渡す。この結果、AM1205bは、AITのパケットを収集することができる。
【0092】
図18は、収集したAITの情報の一例を模式的に表した表である。列1801はJavaプログラムの識別子である。MHP規格によれば、この識別子はApplication IDとして定義され、Javaプログラムが端末装置500のセキュリティマネージャ1205fによって認証されるべきものであるかが判別できることになっている。識別子の値が、0x0から0x3fffの範囲であれば認証は不要で、0x4000から0x7fffであれば認証されなければならない。以降では、識別子の値として、前者をもつJavaプログラムを「unsignedプログラム」、後者をもつJavaプログラムを「signedプログラム」と呼ぶこととする。列1802はJavaプログラムの制御情報である。制御情報には「autostart」「present」「kill」などがあり、「autostart」は即時に端末装置500がこのプログラムを自動的に実行することを意味し、「present」は自動実行しないことを意味し、「kill」はプログラムを停止することを意味する。列1803は、DSMCC方式でJavaプログラムを含んでいるパケットIDを抽出するためのDSMCC識別子である。列1804はJavaプログラムのプログラム名である。
【0093】
行1811と1812は、Javaプログラムの情報の組である。行1811で定義されるJavaプログラムは、識別子「301」、制御情報「autostart」、DSMCC識別子「1」、プログラム名「a/TopXlet」の組である。行1812で定義されるJavaプログラムは、識別子「302」、制御情報「present」、DSMCC識別子「1」、プログラム名「b/GameXlet」の組である。ここで2つのJavaプログラムは同じDSMCC識別子を持つが、これは1つのDSMCC方式でエンコードされたファイルシステム内に2つのJavaプログラムが含まれていることを表す。ここでは、Javaプログラムに対して4つの情報しか規定しないが、実際にはより多くの情報が定義される。詳細はDVB−MHP規格を参照されたい。
【0094】
AM1205bは、AITの中から「autostart」のJavaプログラムを見つけ出し、対応するDSMCC識別子及びJavaプログラム名を抽出する。図18を参照して、AM1205bは行1811のJavaプログラムを抽出し、DSMCC識別子「1」及びJavaプログラム名「a/TopXlet」を獲得する。
【0095】
次にAM1205bは、AITから取得したDSMCC識別子を用いて、JavaプログラムをDSMCC方式で格納しているパケットのパケットIDをPMTから獲得する。具体的には、PMTの中でストリーム種別が「データ」で、補足情報のDSMCC識別子が合致するエレメンタリーストリームのパケットIDを取得する。
【0096】
今、DSMCC識別子が「1」であり、PMTが図17とすると、行1714のエレメンタリーストリームが合致し、パケットID「5014」を取り出す。
【0097】
AM1205bは、OS1201のライブラリ1201bを通してTSデコーダ505にDSMCC方式でデータが埋めこめられたパケットのパケットIDと出力先としてCPU514を指定する。ここでは、パケットID「5014」を与える。TSデコーダ505、与えられたパケットIDでフィルタリングを行い、CPU514に引き渡す。この結果、AM1205bは、必要なパケットを収集することができる。AM1205bは、収集したパケットから、DSMCC方式に従ってファイルシステムを復元し、1次記憶部511に保存する。MPEG2トランスポート中のパケットからファイルシステム等のデータを取り出し1次記憶部511等の記憶手段に保存すことを以降、ダウンロードと呼ぶ。
【0098】
図19は、ダウンロードしたファイルシステムの一例である。図中、丸はディレクトリを四角はファイルを表し、1901はルートディレクトリ、1902はディレクトリ「a」、1903はディレクトリ「b」、1904はファイル「TopXlet.class」、1905はファイル「GameXlet.class」である。
【0099】
次にAM1205bは、1次記憶部511にダウンロードしたファイルシステム中から実行するJavaプログラムをVM1203に引き渡す。今、実行するJavaプログラム名が「a/TopXlet」とすると、Javaプログラム名の最後に「.class」を付加したファイル「a/TopXlet.class」が実行すべきファイルとなる。「/」はディレクトリやファイル名の区切りであり、図19を参照して、ファイル1904が実行すべきJavaプログラムである。次にAM1205bは、Javaプログラム識別子の列1801がunsignedプログラムを示しているので、セキュリティマネージャ1205fにJavaプログラムの認証実行を要求する必要はなく、ファイル1904をVM1203に引き渡す。
【0100】
VM1203は、引き渡されたJavaプログラムを実行する。
サービスマネージャ1204は、他のチャンネルの識別子を受け取ると、ライブラリ1205に含まれる各ライブラリを通して再生している映像・音声及びJavaプログラムの実行を、同じくライブラリ1205に含まれる各ライブラリを通して停止し、新たに受け取ったチャンネルの識別子に基づいて、映像・音声の再生及びJavaプログラムの実行を行う。
【0101】
ライブラリ1205は、ROM512に格納されている複数のJavaライブラリの集合である。本実施の形態では、ここでは、ライブラリ1205は、JMF1205a、AM1205b、Tuner1205c、CA1205d、POD Lib1205e、セキュリティマネージャ1205f、ダウンロードモジュール1206等を含んでいる。
【0102】
サービスマネージャ1204とダウンロードモジュール1206は、ライブラリ1205に含まれるPOD Lib1205eを通してヘッドエンド101と双方向通信を行う。この双方向通信は、POD Lib1205eはOS1201のライブラリ1201b及び、POD504を介して、QPSK復調部502、QPSK変調部503を使用して実現される。
【0103】
ダウンロードモジュール1206は、この通信を用いてヘッドエンド101から、コードデータを受け取ることができる。コードデータとは、X.509証明書と端末装置500のファームウェアのどちらかもしくは両方を含んだバイナリデータのことである。
【0104】
また、AM1205bは、ヘッドエンド101から、端末装置500が2次記憶部510に保存すべきJavaプログラムの情報を受け取る。この情報をXAIT情報と呼ぶ。XAIT情報は、ヘッドエンド101とPOD504間で、任意の形式で送信される。どのような送信形式を採用しても、XAITに必要とする情報が含まれていれば、本発明は実施可能である。
【0105】
図20は、ヘッドエンド101から取得したXAITの情報の一例を模式的に表した表である。列2001はJavaプログラムの識別子である。列2002はJavaプログラムの制御情報である。制御情報には「autostart」「present」などがあり、「autostart」は端末装置500が電源投入時にこのプログラムを自動的に実行することを意味し、「present」は自動実行しないことを意味する。列2003は、DSMCC方式でJavaプログラムを含んでいるパケットIDを抽出するためのDSMCC識別子である。列2004はJavaプログラムのプログラム名である。列2005は、Javaプログラムの優先度である。列2006は、Javaプログラムのバージョン番号である。行2011は、Javaプログラムの情報の組である。行2011で定義されるJavaプログラムは、識別子「0x7001」、制御情報「autostart」、DSMCC識別子「1」、プログラム名「a/xlet1」の組である。Javaプログラムの識別子Application IDから、Javaプログラムはsignedプログラムであることが分かる。ここでは、Javaプログラムに対して6つの情報しか規定しないが、より多くの情報が定義されていても本発明は実施可能である。
【0106】
AM1205bは、XAIT情報を受け取ると、AIT情報からJavaプログラムをダウンロードした手順と同じ手順で、MPEG2トランスポートストリームからファイルシステムを1次記憶部511上に展開する。
【0107】
その後、ファイルシステムは2次記憶部510に保存されるが、ファイルシステムに図34で示すような“application description file”が存在する場合、その記述内容に従ってAM1205bはファイルシステム中の特定のファイルを2次記憶部510に保存することになる。AM1205bがファイルシステムを2次記憶部510に保存する直前に、セキュリティマネージャ1205fへ保存直前通知を行う。セキュリティマネージャ1205fは認証を行いAM1205bに起動許可を通知する。AM1205bは、セキュリティマネージャ1205fより起動許可を通知されると、ファイルシステム中の特定のファイルを2次記憶部510に保存する。上記のAM1205bとセキュリティマネージャ1205fの処理は、本発明の主要な機能なので後で詳細に述べる。
【0108】
次に、AM1205bは、XAIT情報にダウンロードしたファイルシステムの格納位置を対応つけて2次記憶部510に保存する。図21は、XAIT情報とダウンロードしたファイルシステムが対応つけられて2次記憶部510に保存されている一例を表す。ここではOCAP規格で定義されているファイルを取り上げて説明する。図21の中で、図20と同じ番号の要素は図20と同じなので、説明は省略する。列2101は対応するダウンロードしたファイルシステムの保存位置を格納する。図中、保存位置は矢印で示している。2110はダウンロードしたファイルシステムであり、内部にトップディレクトリ(またはルートディレクトリともいう)2120、ディレクトリ「a」2121、ディレクトリ「b」2122、ファイル「ocap.storage」2130、ファイル「ocap.certificates.1」2131、ファイル「ocap.signaturefile.1」2132、ファイル「ocap.hashfile」2140〜2142、ファイル「xlet1.class」2150、ファイル「sub.class」2151を保持する。
【0109】
ファイル2130は“application description file”で、図34に示すようなXML(eXtensible Markup Language)形式で記述される。図35はファイル2130の記述内容を表したファイルリスト情報の一例を示す図である。図35において、351はファイル2130の記述内容を表したファイルリスト情報である。3511列は、ファイル名である。3512列は、バージョン番号である。ここでは、“application description file”に対して2つの情報しか規定しないが、より多くの情報が定義されていても本発明は実施可能である。尚、3512列の各ファイルのバージョン番号は、それを含むプログラム番号2006と同じ値が基本的に与えられ、プログラムのバージョンアップ時にファイルの内容が変わらないファイルに該当する3512列のファイルのバージョン番号のみ、プログラムのバージョンアップ前のプログラム番号2006の値が与えられるものとする。
【0110】
ファイル2140〜2142はハッシュファイルで、ファイル名またはディレクトリ名とそれらに対応するハッシュ値を格納している。図22Aの221は“ocap.hashfile”2116、図22Bの222は“ocap.hashfile”2117、図22Cの223は“ocap.hashfile”2118の内容をそれぞれ表した模式図である。221の“ocap.hashfile”は、“/”ディレクトリ2120に存在し、同じディレクトリ2120に存在する“ocap.storage”ファイル2130、“ocap.certificates.1”ファイル2131、“a”ディレクトリ2121を2211列に格納する。2212列は、2213列にそれぞれ記述されている値が何のハッシュアルゴリズムによって計算された値であるのかを示す。2213列は、2211列のファイルまたはディレクトリに関し、2212列で指定されたアルゴリズムを使って計算されたハッシュ値を格納する。ハッシュアルゴリズムには、SHA1(Secure Hash Algorithm 1)とMD5(Message Digest 5)というアルゴリズムが現在主に利用されている。これらは、任意の長さのデータを固定長のバイト値に変換する公知技術のアルゴリズムで、次の特徴をもつ。変換後のデータから元データを推測することができず、ファイルが破損もしくは改竄されていないかを確認するために使用される。
【0111】
一方、ハッシュ値とは、ハッシュアルゴリズムで生成された擬似乱数のことである。ハッシュアルゴリズムがSHA1の時、ハッシュ値の長さは20バイトで、MD5の時は、ハッシュ値の長さは16バイトに換算される。SHA1、MD5の詳細については、それぞれ“FIPS−PUB 186−2 Secure Hash Standard”、“IETF RFC1321”を参照されたい。ここで、2211列に記述された “a” ディレクトリに対応するハッシュ値は “a”ディレクトリに存在する“ocap.hashfile”ファイル2141に対して計算されたSHA1ハッシュ値である。
【0112】
221の“ocap.hashfile”と同様、222の“ocap.hashfile”は、同じディレクトリ2121に存在する“xlet1.class”ファイル2150のファイル名とディレクトリ“b”2122のディレクトリ名、ハッシュアルゴリズム、ハッシュ値を格納する。233の“ocap.hashfile”は、同じディレクトリ2122に存在する“sub.class”ファイル2151のファイル名、ハッシュアルゴリズム、ハッシュ値を格納する。
【0113】
ここでは、本発明に関係する属性のみを取り上げたが、“ocap.hashfile”の詳細な構成については、OCAP規格書である“OpenCable(R) Application Platform Specification OCAP 1.0 Profile(OC−SP−OCAP1.0−IF−I09−031121)”を参照されたい。
【0114】
ファイル2131は証明書チェーンである。図23は、“ocap.certificates.1”ファイル2131の構成内容を示した構成図である。“ocap.certificates.x”(xは正の整数)の一般的な構成を表現している231は、ルート証明書2311、中間証明書2312、リーフ証明書2313を内包する。これらは、ルート証明書2311の所有者が中間証明書2312を発行し、中間証明書2312の所有者がリーフ証明書2313を発行するといった、連鎖関係にある。なおOCAP規格では、署名ファイル“ocap.signaturefile.x”と関係する証明書チェーンは、同じ値“x”をもつ“ocap.certificates.x”である。
【0115】
図21の場合、“ocap.signaturefile.1”に対応する証明書チェーンは、“ocap.certificates.1”となる。そして、ルート証明書2311、中間証明書2312、リーフ証明書2313は、共通のX.509証明書のフォーマットで構成される。X.509証明書は、ITU−Tのレコメンデーションで、証明書の表現形式のデファクト標準として情報通信の各分野で広く普及している。図23では3つの証明書のみを図示しているが、中間証明書が複数存在することもある。但し、中間証明書間で相互に関連した連鎖状態になければならない。
【0116】
図24はX.509証明書の構成図である。ここでは、本発明の説明の上で必要な属性のみを列挙している。X.509証明書の詳細については、IETF RFC3280“Internet X.509 Public Key Infrastructure Certificates and CRL Profile”を参照されたい。241はX.509証明書の属性領域、242はX.509証明書の署名値を示す。シリアル番号2411は証明書を識別するための番号、署名アルゴリズム2412は署名値242を計算するために使用されたアルゴリズム、今回更新日時2413は本X.509証明書の有効開始日時、次回更新時間2414は本X.509証明書の有効満了日時、発行者名2415は本X.509証明書を発行する機関名、主体者名2416は本X.509証明書の所有者、公開鍵2417は主体者名2416の公開鍵、署名値242は本X.509証明書発行者の秘密鍵によって署名(暗号化)された値を表す。公開鍵と秘密鍵を使ったものとして、公開鍵暗号方式が電子商取引等で幅広く利用されている。公開鍵暗号方式では、平文を暗号化するときに使用した鍵と異なる鍵を使用して暗号文を復号する。暗号用の鍵と復号用の鍵が異なり、復号用の鍵を一般公開しても復号用の鍵から暗号用の鍵を推測することは不可能である。この暗号用の鍵が秘密鍵、復号用の鍵が公開鍵に該当する。公開鍵暗号方式の代表例としては、RSA(Rivest−Shamir−Adleman)、DSA(Digital Signature Standard)が挙げられる。
【0117】
ファイル2132は署名ファイルである。図25は、“ocap.signaturefile.1”ファイル2132の模式図である。251はどのX.509証明書と関係するのかを示す証明書識別子、252はハッシュ署名アルゴリズム、253は252で示されるハッシュ署名アルゴリズムを用いて、“ocap.hashfile”2140から計算された署名値を表す。
【0118】
Javaプログラムが2次記憶部510に保存されると、チャンネル変更、端末装置500の電源OFF等により1次記憶部511からそれが消去されたとしても、AM1205bが図20で示すXAITを受信すれば、ダウンロードを待たずにJavaプログラムが起動される。すなわち、図20では、プログラム“/a/xlet1”が制御情報2002として「autostart」になっている。そこで、図21の行2011において、“/a/xlet1”に対応するファイルシステムの保存位置2101を探し、ファイル2150をVM1203に引き渡すと、ファイルシステムに保有されているJavaプログラム“xlet1”が起動される。
【0119】
次に、本発明の主要な機能であるAM1205bとセキュリティマネージャ1205fの1次記憶部511上に展開されているファイルシステムを認証し、2次記憶部510に保存する処理について説明する。
【0120】
最初にAM1205bを説明し、次にセキュリティマネージャ1205fの機能を説明し、最後にAM1205bとセキュリティマネージャ1205fの処理の流れを説明する。
【0121】
最初に、AM1205bを説明する。
図36は、1次記憶部511上に展開されているファイルシステムを2次記憶部510に保存する際のAM1205bの構成要素を示す。
【0122】
ファイルシステム比較手段3601は、新たにダウンロードされたJavaプログラムを保存する時、1次記憶部511上に展開されているファイルシステムの”/”ディレクトリに存在する“ocap.storage”と保存先である2次記憶部510の”/”ディレクトリに存在する“ocap.storage”の記述内容の比較を行い、保存するファイルリスト情報を抽出し、抽出したファイルリスト情報とJavaプログラム識別子2001を組にしてファイルシステム管理手段3602に渡す。ファイルシステム管理手段3602は、ファイルシステム保存手段3603より問い合わされるとファイルシステム比較手段3601より渡されたファイルリスト情報を用いて保存するファイルリスト情報を伝える。
【0123】
ファイルシステム保存手段3603は、ファイルシステム管理手段3602に問い合わせて保存するファイルリスト情報を取得し、そのファイルリスト情報に基づいて1次記憶部511から2次記憶部510にファイルの保存を行う。
【0124】
例えば前回のダウンロードにより1次記憶部511に展開された後、認証を経て2次記憶部510に保存されたJavaプログラムのファイルシステムにおける“ocap.storage”に基づくファイルリスト情報の内容が図37に示すものであり、図21に示すXAIT情報に従った新たなダウンロードにより1次記憶部511に展開されたJavaプログラムのファイルシステムにおける“ocap.storage”に基づくファイルリスト情報の内容が図35に示すものである場合、ファイルシステム比較手段3601は図38に示すファイルリスト情報と新たに1次記憶部511に展開されたJavaプログラムのプログラム識別子2001をファイルシステム管理手段3602へ渡す。
【0125】
図38の内容から分かるように、図37にはあって図35にはないファイル(つまり“/a/c/ocap.hashfaile”、“/a/c/sub.class”)と図37、図35ともにあるがバージョン番号が異なるファイル(つまり“/ocap.hashfile”、“/ocap.signaturefile.1”、“/a/ocap.hashfile”、“/a/xlet.class”)が図38のファイルリスト情報に示され、図37、図35ともに共通するファイルは図38には示されない。
【0126】
ファイルシステム管理手段3602は、Javaプログラムのプログラム識別子2001とファイルリスト情報とを組にして管理し、ファイルシステム保存手段3603は、ファイルシステム管理手段3602へ保存するファイルを問い合わせ、受け取ったファイルリスト情報に従って保存する。
【0127】
ファイルシステム比較手段3601、ファイルシステム管理手段3602、ファイルシステム保存手段3603の詳細な処理を、行2011で定義されるJavaプログラムを保存する場合を例に説明する。
【0128】
図39は、ファイルシステム比較手段3601のフローチャートである。1次記憶部511上に展開されているファイルシステムの”/”ディレクトリに存在する“ocap.storage”が存在するかチェックする(ステップS391)。存在する場合は、1次記憶部511上の“ocap.storage”の記述内容に基づきファイルリスト情報351を作成する(ステップS392)。
【0129】
尚、ステップS391で存在しない場合は、この例においては処理を終えるが、1次記憶部511上のファイルシステムのファイル構成を参照してファイル名3511列とバージョン番号2006からバージョン番号3512列を作成しファイルリスト情報351としステップS393に進んでも良いものとする。
【0130】
次に、新たにダウンロードしたJavaプログラム(本例では図21に示すJavaプログラムを新たにダウンロードしたJavaプログラムとした例を説明する)を保存する2次記憶部510上の”/”ディレクトリに存在する“ocap.storage”が存在するかチェックする(ステップS393)。存在する場合は、2次記憶部510上の“ocap.storage”の記述内容に基づきファイルリスト情報371を作成する(ステップS394)。
【0131】
尚、ステップS393で存在しない場合は、この例においては処理を終えるが、2次記憶部510上のファイルシステムのファイル構成を参照してファイル名3711列とバージョン番号の最小値である1からバージョン番号3712列を作成しファイルリスト情報371としステップS395に進んでも良いものとする。
【0132】
次に、ファイルリスト情報351とファイルリスト情報371を比較して差分を抽出してファイルリスト情報381を作成する(ステップS395)。最後にJavaプログラム識別子2001とファイルリスト情報381を組にしてファイルシステム管理手段3602に渡す(ステップS396)。
【0133】
図40は、ファイルシステム管理手段3602のフローチャートである。Javaプログラム識別子2001を与えられてファイルリスト情報を問い合わされる(ステップS401)と、Javaプログラム識別子2001に対応するファイルリスト情報381を問い合わせ先に返す(ステップS402)。
【0134】
図41は、ファイルシステム保存手段3603のフローチャートである。Javaプログラム識別子2001を与えられて保存を要求される(ステップS411)と、ファイルシステム管理手段3602に与えられたJavaプログラム識別子2001にてファイルリスト情報381を取得する(ステップS412)。取得できたか判定(ステップS413)し取得できた場合、バージョン番号2006と取得したファイルリスト情報381の3812列のバージョン番号を先頭の行から順に比較する(ステップS414)。
【0135】
比較してバージョン番号2006が大きいか判定(ステップS415)し、大きい場合、ファイルリスト情報381のその行の3811列のファイル名に対応する2次記憶部510のファイルを削除する。図38に示す例では“/a/c/ocap.hashfaile”、“/a/c/sub.class”の2つのファイルが削除される(ステップS416)。大きくない場合、バージョン番号2006と等しいか判定(ステップS417)し、等しい場合、ファイルリスト情報381のその行の3811列のファイル名に対応する1次記憶部511のファイルを2次記憶部510に保存する(ステップS418)。尚、この保存とは2次記憶部510にファイルが存在する場合は上書き保存し、存在しない場合追加保存となる。また、ここでの保存動作の前には、後述する認証動作が完了しているものとする。最後に、ファイルリスト情報の行の終わりか判定(ステップS419)し、行の終わりではない場合、ステップS414に戻る。行の終わりの場合、処理は終わる。
【0136】
尚、バージョンの新しいファイルを保存し、バージョンが古いファイルを削除する目的を実現する方法であれば他の方法でも良い。ファイルの新旧を判断するためにバージョン番号2006とファイルリスト情報381の3812列のバージョン番号を用いたが、ファイルの新旧を判断する方法であればその他の方法を用いても良い。
【0137】
次に、セキュリティマネージャ1205fの一般的な動作について説明する。例えば、AM1205bから、行2011で定義されるJavaプログラムが保存されようとしていることを表す保存直前通知を通知される。その通知を受け取ると、Javaプログラム識別子2001の値を調べ、unsignedプログラムであるのか、signedプログラムであるのかを判断する。ここで、Javaプログラムはsignedプログラムであるので、“/”ディレクトリ以下のファイルシステムについて、認証を実行する。認証では、図21のocap.hashfile(2140〜2142)、ocap.certificates.1(2131)、ocap.signaturefile.1(2132)を使用して検証する。
【0138】
図26は、ファイルシステムの認証を実行する際のセキュリティマネージャ1205fの構成要素を示す。
【0139】
通知受取手段261は、AM1205bがファイルシステムを保存しようとする直前に保存直前通知を受け取るための手段であり、それを判定手段262へ伝える。
【0140】
判定手段262は、認証結果を決定する。ハッシュ計算手段263へファイルシステムのハッシュ計算を要求し、ハッシュ値を受け取る。判定手段262は“ocap.hashfile”ファイルに存在するハッシュ値2213、2223から比較すべき値を取り出して、一致するかを確認する。一致しなければ、改竄があったものと判断し、認証は失敗となる。
【0141】
また、判定手段262は、証明書抽出手段265を用いて各X.509証明書を取り出し、現在時刻がX.509証明書の今回更新日時2413と次回更新日時2414の間にあるかを判断する。なお、現在日時は、OS1201のライブラリ1201bから取得する。もし、“今回更新日時<現在日時<次回更新日時”という期間有効性がなければ、認証は失敗と判断する。
【0142】
さらに、判定手段262は、証明書チェーンの認証を行うために、X.509証明書の属性領域241のハッシュ計算をハッシュ計算手段263に要求する。そして、署名値復号手段264へX.509証明書に含まれる署名値242の復号計算を要求して、得られた復号値とハッシュ計算手段263で得られたハッシュ値を比較し、証明書連鎖の状況を確認する。もし不一致であれば、連鎖しておらず、認証は失敗と判断される。一方、一致して連鎖が確認できれば、証明書チェーンのルート証明書が、端末装置500の2次記憶部510に含まれているかを確認する。もし含まれていなければ、照合不可能として、認証は失敗と判断する。
【0143】
判定手段262が認証の成功と判断するのは、(1)改竄なし、(2)期間有効性あり、(3)証明書連鎖あり、(4)ルート証明書が一致、をすべて満たすときである。
【0144】
ハッシュ計算手段263は、判定手段262より各ファイルのハッシュ値計算を要求され、OS1201のライブラリ1201bから各ファイルを取り出して、そのハッシュ計算を行い、結果を判定手段262へ渡す。また、証明書チェーン231内の各X.509証明書を証明書抽出手段265から取得し、属性領域241に対してハッシュ計算を行う。
【0145】
署名値復号手段264は、判定手段262からX.509証明書もしくは“ocap.signaturefile.x”の署名値を復号計算するように要求される。X.509証明書の署名を復号計算する際には、証明書抽出手段265から証明書チェーン231の各X.509証明書を取得した上で、署名の復号計算を実施し、結果を判定手段262へ返す。
【0146】
証明書抽出手段265は、判定手段262、ハッシュ計算手段263、署名値復号手段264から、証明書チェーン231の中にある各X.509証明書を抽出するように要求を受けて、X.509証明書を抽出して返す。
【0147】
図27は、ファイルシステムの認証を実行する際のセキュリティマネージャ1205fの動作をまとめたフローチャートである。以下、ファイルシステムの構成が図21である場合の動作をフローチャートに則して説明する。AM1205bからファイルシステムの保存直前通知を受け付けると(ステップS271)、ファイルシステムの最上位ディレクトリ“/”以下のファイルシステムについて改竄チェックを行う(ステップS272)。改竄チェックでは、ファイルシステムの各ディレクトリに存在するファイルに対して、破損及び変更がなされていないかをハッシュ値比較で確認する。
【0148】
図29と図30は、ステップS272の詳細なフローチャートを示す。まず、ファイルシステム管理手段3602からJavaプログラム識別子2001にてファイルリスト情報381を取得する(ステップS290)。次に、ファイルシステムの“/”ディレクトリに注目する(ステップS291)。注目しているディレクトリの中のファイルが取得したファイルリスト情報381に存在するか比較する(ステップS292)。存在するかの判定(ステップS293)で存在する場合は、ファイル“ocap.certificates.1”、“ocap.storage”と、ディレクトリ“a”のハッシュ値を計算する(ステップS294)。なお、ディレクトリ“a”のハッシュ値は “/a/ocap.hashfile”ファイル222から計算される。ステップS294で計算したハッシュ値と、“/ocap.hashfile”中の2213のハッシュ値とをそれぞれ比較する(ステップS295)。ステップS296において、1つでも計算したハッシュ値と2213のハッシュ値とが異なれば、改竄があったと判断する(ステップS299)。一方、計算したハッシュ値と2213のハッシュ値がすべて一致した場合、ステップ297へ移る。存在するかの判定(ステップS293)で存在しない場合は、ステップS297へ移る。
【0149】
ステップ297では、改竄チェックが完了していないサブディレクトリがないかを確認する。現時点では、“a” のディレクトリが“/”のサブディレクトリとして存在するので、ステップS298として、“a”ディレクトリに注目することとし、“/”ディレクトリと同様の処理を行う。“a”ディレクトリでの改竄チェック完了後、“a” のディレクトリのサブディレクトリである“b”ディレクトリでの改竄チェックを実施する。全てのサブディレクトリに対する改竄チェックが完了すると、“/”ディレクトリに注目して、図30のステップS301の処理を行う。ステップS301では、証明書チェーン231である“/ocap.certificates.1”ファイル2131からリーフ証明書2313を抽出する。そして、抽出したリーフ証明書2313から公開鍵2417をステップS302で取り出す。その後、ステップS303では、“/ocap.hashfile”ファイル221のハッシュ値を計算する。
【0150】
一方、ステップS304で、“/ocap.certificatesfile.1”ファイル2131のリーフ証明書2313に存在する公開鍵2417を用いて、“/ocap.signaturefile.1”ファイル2132の署名値242に対して復号を行う。ステップS305では、ステップS303で計算したハッシュ値と、ステップS304で得た署名値を復号した値が等しいかを確かめる。もし、計算値が一致すれば、“/”ディレクトリ以下のファイルシステムは改竄されていないと判断できる(ステップS306)。一方、計算値が一致しなければ、ファイルシステムは改竄されていると判断できる(ステップS307)。なお、改竄チェックは、最上位である“/”ディレクトリからサブディレクトリに向かって降順に処理する例を挙げたが、本発明はこれに限定するものではない。最下位ディレクトリから最上位ディレクトリへ向かって昇順に処理することにしても構わない。以上により、図27中のステップS272の結果が得られる。
【0151】
ステップS273では、もしステップS272での結果が「改竄あり」であった場合、認証は失敗と判断して通知(ステップS279)後に終了する。ステップS272での結果が「改竄なし」の場合には、ステップS274を処理する。
【0152】
次に、図31〜図33を用いて、証明書チェーンの認証(ステップS274)を詳細に説明する。まず、中間証明書2312とリーフ証明書2313間でのチェックを行うこととし、図31にそのフローチャートを図示する。最初に、証明書チェーン231から中間証明書2312とリーフ証明書2313を抽出する(ステップS311)。抽出したリーフ証明書2313から今回更新日時2413、次回更新日時2414、発行者名2415を抽出する(ステップS312)。このうち、現在の日時が今回更新日時2413から次回更新日時2414までの証明書が有効な期間であるかを判断する(ステップS313)。もし、証明書が有効な期間外であれば、証明書チェーンの認証は失敗(ステップS319)となる。一方、証明書が有効な期間であると判断すると、中間証明書2312の主体者名2416と公開鍵2417を抽出し(ステップS314)、中間証明書2312の主体者名2416とリーフ証明書2313の発行者名2415を比較して、中間証明書2312とリーフ証明書2313が連鎖関係にあるかを判別する(ステップS315)。
【0153】
もし、証明書間で連鎖関係になければ、証明書チェーンの認証は失敗となる。他方、連鎖関係が成り立てば、リーフ証明書2313の属性領域241のハッシュ値を計算する(ステップS316)。また、中間証明書2312の公開鍵2417を利用して、リーフ証明書2313の署名値242を復号する(ステップS317)。ステップS316とステップS317が完了すると、それぞれから得られるハッシュ値と署名復号値が一致するかどうかを判断する(ステップS318)。もし、一致しなければ証明書チェーンの認証は失敗となる(ステップS319)。
【0154】
次に、ルート証明書2311と中間証明書2312間でのチェックを行う。図32にそのフローチャートを図示する。証明書チェーン231からルート証明書2311と中間証明書2312を抽出し(ステップS321)、中間証明書2312とリーフ証明書2313間のチェックと同様の処理を、ルート証明書2311と中間証明書2312に対して行う(ステップS322〜ステップS328)。
【0155】
そして、ステップS328で一致すると判断された場合、ルート証明書2311単独のチェックを行う。図33は、ルート証明書2311単独チェックのフローチャートである。ステップS321で抽出したルート証明書2311から、今回更新日時2413、次回更新日時2414、発行者名2415を抽出する(ステップS331)。このうち、現在の日時が今回更新日時2413から次回更新日時2414までの証明書が有効な期間であるかを判断する(ステップS332)。もし、証明書が有効な期間外であれば、証明書チェーンの認証は失敗となる。一方、証明書が有効な期間であると判断すると、ルート証明書2311の属性領域241のハッシュ値を計算する(ステップS334)。また、ルート証明書2311の公開鍵2417を利用して、ルート証明書2311の署名値242を復号する(ステップS335)。ステップS334とステップS335が完了すると、それぞれから得られるハッシュ値と署名復号値が一致するかどうかを判断する(ステップS336)。もし一致すれば、証明書チェーンの認証は成功(ステップS337)であり、一致しなければ証明書チェーンの認証は失敗(ステップS338)となる。ここで、ステップS274の処理が終了する。
【0156】
ステップS275では、S274の結果に応じて、処理が異なる。ステップ4の結果が「証明書チェーンの認証失敗」の場合、認証失敗と判断して通知し(ステップS279)、ファイルシステムとしての認証は終了する。一方、「証明書チェーンの認証成功」の場合、ステップS276を処理する。
【0157】
次に、“/ocap.certificates.1”ファイル2131のルート証明書2311と同じ証明書を端末装置500の2次記憶部510から探す(ステップS276)。ステップS277において、2次記憶部510に存在しない場合には、証明書チェーン231の認証は失敗と判断し、認証失敗を通知(ステップS279)後、終了する。一方、そのルート証明書2311が含まれている場合には、ファイルシステムの認証は成功と判断し、AM1205bへ認証成功を通知する(ステップS278)。その後、図28を参照して、Javaプログラムの起動直前通知を受けても(ステップS281)、何もせずに終了する。
【0158】
最後に、AM1205bとセキュリティマネージャ1205fの処理の流れを図42にて説明する。AM1205bは、Javaプログラムを保存する時、ファイルシステム比較手段3601に保存するファイルリスト情報の抽出を要求する。ファイルシステム比較手段3601は図39にて説明したフローチャートに従った処理を実行する(ステップS421)。次に、AM1205bはセキュリティマネージャ1205fにJavaプログラムの認証(例えば抽出したファイルリスト情報に対応した新規(バージョンアップも含む)のファイルの認証、新たにダウンロードしたJavaプログラムの“/ocap.hashfile”の改竄チェック(上述のファイルの認証時に行われているのであれば必ずしも再度行わなくてもよい)、新たにダウンロードしたJavaプログラムの証明書ファイルのルート認証)を要求する(ステップS422)。認証が失敗したか判定(ステップS423)し、失敗していない(つまり成功した)場合、AM1205bはファイルシステム保存手段3603にJavaプログラムの保存を要求する。ファイルシステム保存手段3603は図41にて説明したフローチャートに従った処理を実行する(ステップS424)。
【0159】
このように、以前に2次記憶部510に保存したJavaプログラムとの差分を抽出することにより、新たに保存するJavaプログラムの全体を認証と保存の対象とする必要はない。また、保存したJavaプログラムが一定時間経過後に起動されるとき、ファイルシステムの認証は保存直前に実行済みなので、この時点で再度認証する必要はない。より具体的には例えば実行時には保存時と同一の認証を再度行う必要はなく、例えば証明書ファイルのルート認証を行うのみであっても良い。
【0160】
なお、ファイルシステム保存手段3603は、前回の保存時に2次記憶部510に保存されたファイルシステムに含まれるファイルと異なるファイルを保存、削除の対象とし、前回の保存時に2次記憶部510に保存されたファイルシステムに含まれるファイルと同一のファイルについては、2次記憶部510へは再度保存しないものであるが、再度認証することなく上書き保存とするようにしても良い。
【0161】
(実施の形態2)
本発明に係るケーブルテレビシステムの実施の形態を、図面を参照しながら説明する。図1は、ケーブルシステムを構成する装置の関係を表したブロック図であり、ヘッドエンド101及び3個の端末装置A111、端末装置B112、端末装置C113で構成される。本実施の形態では、1つのヘッドエンドに対して3つの端末装置が結合されているが、任意の数の端末装置をヘッドエンドに結合しても、本発明は実施可能である。
【0162】
ヘッドエンド101は、複数の端末装置に対して映像・音声・データ等の放送信号を送信するとともに、端末装置からのデータ送信を受信する。これを実現するため、ヘッドエンド101と端末装置A111、端末装置B112、端末装置C113間の伝送に用いられる周波数帯域は、分割して用いられる。図2は、周波数帯域の分割の一例を示す表である。周波数帯域は、Out Of Band(略称OOB)とIn−Bandの2種類に大別される。5〜130MHzがOOBに割り当てられ、主にヘッドエンド101と端末装置A111、端末装置B112、端末装置C113間のデータのやり取りに使用される。130MHz〜864MHzはIn−Bandに割り当てられ、主として、映像・音声を含む放送チャンネルに使用される。OOBではQPSK変調方式が、In−BandはQAM64変調方式が使用される。変調方式技術については、本発明に関与が薄い公知技術であるので、詳細な説明は省略する。図3は、OOB周波数帯域の更に詳細な使用の一例である。70MHz〜74MHzはヘッドエンド101からのデータ送信に使用され、全ての端末装置A111、端末装置B112、端末装置C113が、ヘッドエンド101から同じデータを受け取ることになる。一方、10.0MHz〜10.1MHzは端末装置A111からヘッドエンド101へのデータ送信に使用され、10.1MHz〜10.2MHzは端末装置B112からヘッドエンド101へのデータ送信に使用され、10.2MHz〜10.3MHzは端末装置C113からヘッドエンド101へのデータ送信に使用される。これにより、各端末装置固有のデータを各端末装置A111、端末装置B112、端末装置C113からヘッドエンド101に送信することができる。図4は、In−Bandの周波数帯に対する使用の一例である。150〜156MHzと156〜162MHzはそれぞれテレビチャンネル1とテレビチャンネル2に割り当てられ、以降、6MHz間隔でテレビチャンネルが割り当てられている。310MHz以降は、1MHz単位でラジオチャンネルに割り当てられている。これらの各チャンネルはアナログ放送として使用してもデジタル放送として使用してもよい。デジタル放送の場合は、MPEG2仕様に基づいたトラスポートパケット形式で伝送され、音声や映像に加え、各種データ放送用データも送信することができる。
【0163】
ヘッドエンド101は、これらの周波数帯域に適切な放送信号を送信するため、QPSK変調部やQAM変調部等を有する。また、端末装置からのデータを受信するため、QPSK復調器を有する。また、ヘッドエンド101は、これら変調部及び復調部に関連する様々な機器を有すると考えられる。しかし、本発明は主として端末装置に関わるので、詳細な説明は省略する。
【0164】
端末装置A111、端末装置B112、端末装置C113は、ヘッドエンド101からの放送信号を受信し再生する。また、ヘッドエンド101に対して、各端末装置固有のデータを送信する。3つの、端末装置は本実施の形態では同じ構成を取る。
【0165】
図5は、端末装置のハードウエア構成を表すブロック図である。500は端末装置であり、QAM復調部501、QPSK復調部502、QPSK変調部503、TSデコーダ505、オーディオデコーダ506、スピーカ507、ビデオデコーダ508、ディスプレイ509、2次記憶部510、1次記憶部511、ROM512、入力部513、CPU514で構成される。また端末装置500には、POD504が着脱できる。
【0166】
図6は、端末装置500の外観の一例である薄型テレビである。端末装置は様々な構成で実現できるが、本実施例ではOpenCable(TM)及びOCAPに基づいて構成された端末装置を例にとって説明する。
【0167】
601は、薄型テレビの筐体であり、POD504を除く、端末装置500の構成要素をすべて内蔵している。
【0168】
602はディスプレイであり、図5におけるディスプレイ509に相当する。
603は複数のボタンで構成されるフロントパネル部であり、図5の入力部513に相当する。
【0169】
604は信号入力端子であり、ヘッドエンド101との信号の送受信を行うためにケーブル線を接続する。信号入力端子は、図5のQAM復調部501、QPSK復調部502、QPSK変調部503と接続されている。
【0170】
605は、図5のPOD504に相当するPODカードである。POD504は、図6のPODカード605のように、端末装置500とは独立した形態を取り、端末装置500に着脱可能となっている。POD504の詳細は後述する。
【0171】
606はPODカード605を挿入する挿入スロットである。
図5を参照して、QAM復調部501は、CPU514から指定された周波数を含むチューニング情報で、ヘッドエンド101でQAM変調され送信されてきた信号を復調し、POD504に引き渡す。
【0172】
QPSK復調部502は、CPU514から指定された周波数を含むチューニング情報で、ヘッドエンド101でQPSK変調され送信されてきた信号を復調し、POD504に引き渡す。
【0173】
QPSK変調部503は、CPU514から指定された周波数を含む復調情報で、POD504から渡された信号をQPSK復調し、ヘッドエンド101に送信する。
【0174】
POD504は、図6のように端末装置本体500から着脱可能な形態をしている。端末本体500とPOD504の接続インターフェースは、OpenCable(TM) CableCARD(TM) Interface Specification(OC−SP−CC−IF−I15−031121)及び、この仕様書から参照されている仕様書で定義されている。なお、仕様書のCableCARDとはPODのことを指している。ここでは、詳細は省略し、本発明に関する部分のみを解説する。
【0175】
図7は、POD504の内部構成を表すブロック図である。POD504は、第1デスクランブラ部701、第2デスクランブラ部702、スクランブラ部703、第1記憶部704、第2記憶部705、CPU706で構成される。
【0176】
第1デスクランブラ部701は、CPU706からの指示により、端末装置500のQAM復調部501から暗号化された信号を受け取り、復号を行う。そして、復号された信号を端末装置500のTSデコーダ505に送る。デコードに必要な鍵などの情報はCPU706から適宜与えられる。具体的には、ヘッドエンド101はいくつかの有料チャンネルを放送している。ユーザーが、この有料チャンネルを購買すると、第1デスクランブラ部701は、CPU706から鍵等の必要な情報を受け取りデスクランブルすることで、ユーザーは有料チャンネルを閲覧することができる。鍵などの必要な情報が与えられない場合は、第1デスクランブラ部701は、デスクランブルを行わず、受け取った信号をそのまま、TSデコーダ505に送る。
【0177】
第2デスクランブラ部702は、CPU706からの指示により、端末装置500のQPSK復調部502から暗号化された信号を受け取り、復号を行う。そして、復号されたデータをCPU706に引き渡す。
【0178】
スクランブラ部703は、CPU706からの指示により、CPU706から受け取ったデータを暗号化し、端末装置500のQPSK変調部503に送る。
【0179】
第1記憶部704は、具体的にはRAM等の一次記憶メモリーで構成され、CPU706が処理を行う際、一時的にデータを保存するために使用される。
【0180】
第2記憶部705は、具体的にはフラッシュROM等の2次記憶メモリーで構成され、CPU706が実行するプログラムを格納し、また、電源OFFになっても消去されては困るデータの保存に使用される。
【0181】
CPU706は、第2記憶部705が記憶するプログラムを実行する。プログラムは複数のサブプログラムで構成される。図8は、第2記憶部705が記憶するプログラムの一例である。図8では、プログラム800は、メインプログラム801、初期化サブプログラム802、ネットワークサブプログラム803、再生サブプログラム804、PPVサブプログラム805等複数のサブプログラムで構成されている。
【0182】
ここでPPVとはPay Per Viewの略であり、映画など特定の番組を有料で視聴できるようにするサービスである。ユーザーが暗証番号を入力すると、購入したことがヘッドエンド101に通知され、スクランブルが解除され、視聴することが出来る。この視聴により、ユーザーは後日、購入代金を支払うものである。
【0183】
メインプログラム801は、CPU706が電源投入時に最初に起動するサブプログラムであり、他のサブプログラムの制御を行う。
【0184】
初期化サブプログラム802は、電源投入時にメインプログラム801によって起動され、端末装置500との情報交換等を行い、初期化処理を行う。初期化処理の詳細は、OpenCable(TM) CableCARD(TM) Interface Specification(OC−SP−CC−IF−I15−031121)及び、この仕様書から参照されている仕様書で定義されている。また、仕様書に定義されていない初期化処理も行う。ここでは、その一部を紹介する。電源が投入されると、初期化サブプログラム802は、第2記憶部705が記憶する第1の周波数を端末装置500のCPU514を通して、QPSK復調部502に通知する。QPSK復調部502は、与えられた第1の周波数でチューニングを行い、信号を第2デスクランブラ部702に送る。また、初期化サブプログラム802は、第2記憶部705が記憶する第1の鍵等の復号情報を第2デスクランブラ部702に与える。その結果、第2デスクランブラ部702は、デスクランブルを行い、初期化サブプログラム802を実行するCPU706に引き渡す。よって、初期化サブプログラム802は情報を受け取ることができる。本実施の形態では、初期化サブプログラム802はネットワークサブプログラム803を通して情報を受け取ることとする。詳細は後述する。
【0185】
また、初期化サブプログラム802は、第2記憶部705が記憶する第2の周波数を端末装置500のCPU514を通して、QPSK変調部503に通知する。初期化サブプログラム802は第2記憶部705が記憶する暗号化情報をスクランブラ部703に与える。初期化サブプログラム802が送信したい情報を、ネットワークサブプログラム803を介して、スクランブラ部703に与えると、スクランブラ部703は、与えられた暗号化情報を用いて、データを暗号化し、端末装置500のQPSK変調部503に与える。QPSK変調部503は、与えられた暗号化された情報を変調し、ヘッドエンド101に送信する。
【0186】
この結果、初期化サブプログラム802は、端末装置500、第2デスクランブラ部702、スクランブラ部703、ネットワークサブプログラム803を通して、ヘッドエンド101と双方向通信を行うことができる。
【0187】
ネットワークサブプログラム803は、メインプログラム801、初期化サブプログラム802等の複数のサブプログラムから使用される、ヘッドエンド101との双方向通信を行うためのサブプログラムである。具体的には、ネットワークサブプログラム803を使用する他のサブプログラムに対して、TCP/IPによって、ヘッドエンド101と双方向通信を行っているように振舞う。TCP/IPは、複数の装置間で情報交換を行うためのプロトコルを規定した公知の技術であり、詳細な説明は省略する。ネットワークサブプログラム803は、電源投入時に初期化サブプログラム802に起動されると、予め第2記憶部705が記憶しているPOD504を識別する識別子であるMACアドレス(Media Access Controlアドレスの略)を、端末装置500を通してヘッドエンド101に通知し、IPアドレスの取得を要求する。ヘッドエンド101は、端末装置500を介してPOD504にIPアドレスを通知し、ネットワークサブプログラム803は、IPアドレスを第1記憶部704に記憶する。以降、ヘッドエンド101とPOD504は、このIPアドレスを、POD504の識別子として使用し、通信を行う。
【0188】
再生サブプログラム804は、第2記憶部705が記憶する第2の鍵等の復号情報や、端末装置500から与えられる第3の鍵等の復号情報を第1デスクランブラ部701に与えて、デスクランブルを可能にする。また、ネットワークサブプログラム803を通して、第1デスクランブラ部701に入力されている信号が、PPVチャンネルであることの情報を受け取る。PPVチャンネルと知ったときは、PPVサブプログラム805を起動する。
【0189】
PPVサブプログラム805は、起動されると、端末装置500に番組の購入を促すメッセージを表示し、ユーザーの入力を受け取る。具体的には、端末装置500のCPU514に画面に表示したい情報を送ると、端末装置500のCPU514上で動作するプログラムが、端末装置500のディスプレイ509上にメッセージを表示する。ユーザーは、端末装置500の入力部513を通して暗証番号を入力すると、端末装置500のCPU514が、それを受け取り、POD504のCPU706上で動作するPPVサブプログラム805に通知する。PPVサブプログラム805は、受け取った暗証番号をネットワークサブプログラム803を通してヘッドエンド101に送信する。ヘッドエンド101は、暗証番号が正しければ、復号に必要な第4の鍵などの復号化情報をネットワークサブプログラム803を介して、PPVサブプログラム805に通知する。PPVサブプログラム805は受け取った第4の鍵などの復号化情報を第1デスクランブラ部701に与え、第1デスクランブラ部701は、入力されている信号をデスクランブルする。
【0190】
図5を参照して、TSデコーダ505は、POD504から受け取った信号のフィルタリングを実施し、必要なデータをオーディオデコーダ506及びビデオデコーダ508、CPU514に引き渡す。ここで、POD504から来る信号はMPEG2トランスポートストリームである。MPEG2トランスポートストリームの詳細はMPEG規格書 ISO/IEC138181−1に記載されており、本実施の形態では詳細は省略する。MPEG2トランスポートストリームは、複数の固定長パケットで構成され、各パケットには、パケットIDが振られている。図9はパケットの構成図である。900はパケットであり、固定長の188バイトで構成される。先頭4バイトがヘッダー901で、パケットの識別情報を格納しており、残り184バイトがペイロード902で、送信したい情報を含んでいる。903は、ヘッダー901の内訳である。先頭から12ビット目〜24ビット目までの13ビットにパケットIDが含まれている。図10は送られてくる複数のパケットの列を表現した模式図である。パケット1001は、ヘッダーにパケットID「1」を持ち、ペイロードには映像Aの1番目の情報が入っている。パケット1002は、ヘッダーにパケットID「2」を持ち、ペイロードには音声Aの1番目の情報が入っている。パケット1003は、ヘッダーにパケットID「3」を持ち、ペイロードには音声Bの1番目の情報が入っている。
【0191】
パケット1004は、ヘッダーにパケットID「1」を持ち、ペイロードには映像Aの2番目の情報が入っており、これはパケット1001の続きになっている。同様にパケット1005、1026、1027も他のパケットの後続データを格納している。このように、同じパケットIDを持つ、パケットのペイロードの内容を連結すると、連続した映像や音声を再現することができる。
【0192】
図10を参照して、CPU514がパケットID「1」と出力先として「ビデオデコーダ508」をTSデコーダ505に指示すると、TSデコーダ505はPOD504から受け取ったMPEG2トランスポートストリームからパケットID「1」のパケットを抽出し、ビデオデコーダ508に引き渡す。図10においては、映像データのみをビデオデコーダ508に引き渡すことになる。同時に、CPU514がパケットID「2」と「オーディオデコーダ506」をTSデコーダ505に指示すると、TSデコーダ505はPOD504から受け取ったMPEG2トランスポートストリームからパケットID「2」のパケットを抽出し、オーディオデコーダ506に引き渡す。図10においては、音声データのみをビデオデコーダ508に引き渡すことになる。
【0193】
このパケットIDに応じて必要なパケットだけを取り出す処理が、TSデコーダ505が行うフィルタリングである。TSデコーダ505はCPU514から指示された複数のフィルタリングを同時に実行することができる。
【0194】
図5を参照して、オーディオデコーダ506は、TSデコーダ505から与えられたMPEG2トランスポートストリームのパケットに埋め込まれたオーディオデータを連結し、デジタル−アナログ変換を行いスピーカ507に出力する。
【0195】
スピーカ507は、オーディオデコーダ506から与えられた信号を音声出力する。
ビデオデコーダ508は、TSデコーダ505から与えられたMPEG2トランスポートストリームのパケットに埋め込まれたビデオデータを連結し、デジタル−アナログ変換を行いディスプレイ509に出力する。
【0196】
ディスプレイ509は、具体的にはブラウン管や液晶等で構成され、ビデオデコーダ508から与えられたビデオ信号を出力したり、CPU514から指示されたメッセージを表示したりする。
【0197】
2次記憶部510は、具体的には、フラッシュメモリーやハードディスク等で構成され、CPU514から指示されたデータやプログラムを保存したり削除したりする。また、保存されているデータやプログラムはCPU514に参照される。保存されているデータやプログラムは、端末装置500の電源が切断された状態でも保存しつづける。
【0198】
1次記憶部511は、具体的には、RAM等で構成され、CPU514から指示されたデータやプログラムを一次的に保存したり削除したりする。また、保存されているデータやプログラムはCPU514に参照される。保存されているデータやプログラムは、端末装置500の電源が切断された際に、抹消される。
【0199】
ROM512は、書き換え不可能なメモリーデバイスであり、具体的にはROMやCD−ROM、DVDなどで構成される。ROM512は、CPU514が実行するプログラムが格納されている。
【0200】
入力部513は、具体的には、フロントパネルやリモコンで構成され、ユーザーからの入力を受け付ける。図11は、フロントパネルで入力部513を構成した場合の一例である。1100はフロントパネルであり、図6のフロントパネル部603に相当する。フロントパネル1100は7つのボタン、上カーソルボタン1101、下カーソルボタン1102、左カーソルボタン1103、右カーソルボタン1104、OKボタン1105、取消ボタン1106、EPGボタン1107を備えている。ユーザーがボタンを押下すると、押下されたボタンの識別子が、CPU514に通知される。
【0201】
CPU514は、ROM512が記憶するプログラムを実行する。実行するプログラムの指示に従い、QAM復調部501、QPSK復調部502、QPSK変調部503、POD504、TSデコーダ505、ディスプレイ509、2次記憶部510、1次記憶部511、ROM512を制御する。
【0202】
図12は、ROM512に記憶され、CPU514に実行されるプログラムの構成図の一例である。
【0203】
プログラム1200は、複数のサブプログラムで構成され、具体的にはOS1201、EPG1202、JavaVM1203、サービスマネージャ1204、Javaライブラリ1205で構成される。
【0204】
OS1201は、端末装置500の電源が投入されると、CPU514が起動するサブプログラムである。OS1201は、オペレーティングシステムの略であり、Linux等が一例である。OS1201は、他のサブプログラムを平行して実行するカーネル1201a及びライブラリ1201bで構成される公知の技術の総称であり、詳細な説明は省略する。本実施の形態においては、OS1201のカーネル1201aは、EPG1202とJavaVM1203をサブプログラムとして実行する。また、ライブラリ1201bは、これらサブプログラムに対して、端末装置500が保持する構成要素を制御するための複数の機能を提供する。
【0205】
機能の一例として、チューニング機能を紹介する。チューニング機能は、他のサブプログラムから周波数を含むチューニング情報を受け取り、それをQAM復調部501に引き渡す。QAM復調部501は与えられたチューニング情報に基づき復調処理を行い、復調したデータをPOD504に引き渡すことができる。この結果、他のサブプログラムはライブラリ1201bを通してQAM復調器を制御することができる。
【0206】
EPG1202は、ユーザーに番組一覧を表示及び、ユーザーからの入力を受け付ける番組表示部1202aと、チャンネル選局を行う再生部1102bで構成される。ここで、EPGはElectric Program Guideの略である。EPG1202は、端末装置500の電源が投入されると、カーネル1201aによって起動される、起動されたEPG1202の内部では、番組表示部1202aが端末装置500の入力部513を通して、ユーザーからの入力を待つ。ここで、入力部513が図11で示されるフロントパネルで構成されている場合、ユーザーが、入力部513のEPGボタン1107を押下すると、EPGボタンの識別子がCPU514に通知される。CPU514上で動作するサブプログラムであるEPG1202の番組表示部1202aは、この識別子を受け取り、番組情報をディスプレイ509に表示する。図13A及び図13Bは、ディスプレイ509に表示された番組表の一例である。図13Aを参照して、ディスプレイ509には、格子状に番組情報が表示されている。列1301には、時刻情報が表示されている。列1302には、チャンネル名「チャンネル1」と、列1301の時刻に対応する時間帯に放映される番組が表示されている。「チャンネル1」では、9:00〜10:30に番組「ニュース9」が放映され、10:30〜12:00は「映画AAA」が放映されることを表す。列1303も列1302同様、チャンネル名「チャンネル2」と、列1301の時刻に対応する時間帯に放映される番組が表示されている。9:00〜11:00に番組「映画BBB」が放映され、11:00〜12:00は「ニュース11」が放映される。1330は、カーソルである。カーソル1330は、フロントパネル1100の左カーソル1103と右カーソル1104を押下すると移動する。図13Aの状態で、右カーソル1104を押下すると、カーソル1330は右に移動し、図13Bのようになる。また、図13Bの状態で、左カーソル1103を押下すると、カーソル1330は左に移動し、図13Aのようになる。
【0207】
図13Aの状態で、フロントパネル1100のOKボタン1105が押下されると、番組表示部1202aは、「チャンネル1」の識別子を再生部1102bに通知する。図13Bの状態で、フロントパネル1100のOKボタン1105が押下されると、番組表示部1202aは、「チャンネル2」の識別子を再生部1102bに通知する。
【0208】
また、番組表示部1202aは、表示する番組情報を、POD504を通してヘッドエンド101から定期的に、1次記憶部511に記憶しておく。一般的に、ヘッドエンドからの番組情報の取得は時間が掛かる。入力部513のEPGボタン1107が押下された時、1次記憶部511に予め保存された番組情報を表示することで、素早く番組表を表示することができる。
【0209】
再生部1102bは、受け取ったチャンネルの識別子を用いて、チャンネルを再生する。チャンネルの識別子とチャンネルの関係は、チャンネル情報として、2次記憶部510に予め格納されている。図14は2次記憶部510に格納されているチャンネル情報の一例である。チャンネル情報は表形式で格納されている。列1401は、チャンネルの識別子である。列1402は、チャンネル名である。列1403はチューニング情報である。ここで、チューニング情報は周波数や転送レート、符号化率などを含み、QAM復調部501に与える値である。列1404はプログラムナンバーである。プログラムナンバーとは、MPEG2規格で規定されているPMTを識別するための番号である。PMTに関しては、後述する。行1411〜1414の各行は、各チャンネルの識別子、チャンネル名、チューニング情報の組となる。行1411は識別子が「1」、チャンネル名が「チャンネル1」、チューニング情報に周波数「312MHz」、プログラムナンバーが「101」を含む組となっている。再生部1102bは、チャンネルの再生を行うため、受け取ったチャンネルの識別子をそのままサービスマネージャに引き渡す。
【0210】
また、再生部1102bは、再生中に、ユーザーがフロントパネル1100の上カーソル1101と下カーソル1102を押下すると、入力部513からCPU514を通して、押下された通知を受け取り、再生しているチャンネルを変更する。まず、再生部1102bは、1次記憶部511に現在再生中のチャンネルの識別子を記憶する。図15A、図15B及び図15Cは、1次記憶部511に保存しているチャンネルの識別子の例である。図15Aでは識別子「3」が記憶されており、図14を参照し、チャンネル名「TV 3」のチャンネルが再生中であることを示す。図15Aの状態で、ユーザーが上カーソル1101を押下すると再生部1102bは、図14のチャンネル情報を参照し、表中の前のチャンネルであるチャンネル名「チャンネル2」のチャンネルに再生を切り変えるため、サービスマネージャにチャンネル名「チャンネル2」の識別子「2」を引き渡す。同時に、1次記憶部511に記憶されているチャンネル識別子「2」に書き換える。図15Bは、チャンネル識別子が書き換えられた状態を表す。また、図15Aの状態で、ユーザーが下カーソル1102を押下すると再生部1102bは、図14のチャンネル情報を参照し、表中の次のチャンネルであるチャンネル名「TV Japan」のチャンネルに再生を切り変えるため、サービスマネージャにチャンネル名「TV Japan」の識別子「4」を引き渡す。同時に、1次記憶部511に記憶されているチャンネル識別子「4」に書き換える。図15Cは、チャンネル識別子が書き換えられた状態を表す。
【0211】
JavaVM1203は、Java言語で記述されたプログラムを逐次解析し実行するJavaバーチャルマシンである。Java言語で記述されたプログラムはバイトコードと呼ばれる、ハードウエアに依存しない中間コードにコンパイルされる。Javaバーチャルマシンは、このバイトコードを実行するインタープリタである。また、一部のJavaバーチャルマシンは、バイトコードをCPU514が理解可能な実行形式に翻訳してから、CPU514に引渡し、実行することも行う。JavaVM1203は、カーネル1201aに実行するJavaプログラムを指定され起動される。本実施の形態では、カーネル1201aは、実行するJavaプログラムとしてサービスマネージャ1204を指定する。Java言語の詳細は、書籍「Java Language Specification(ISBN 0−201−63451−1)」等の多くの書籍で解説されている。ここでは、その詳細を省略する。また、JavaVM自体の詳細な動作などは、「Java Virtual Machine Specification(ISBN 0−201−63451―X)」等の多くの書籍で解説されている。ここでは、その詳細を省略する。
【0212】
サービスマネージャ1204は、Java言語で書かれたJavaプログラムであり、JavaVM1203によって逐次実行される。サービスマネージャ1204は、JNI(Java Native Interface)を通して、Java言語で記述されていない他のサブプログラムを呼び出したり、または、呼び出されたりすることが可能である。JNIに関しても、書籍「Java Native Interface」等の多くの書籍で解説されている。ここでは、その詳細を省略する。
【0213】
サービスマネージャ1204は、JNIを通して、再生部1102bよりチャンネルの識別子を受け取る。
【0214】
サービスマネージャ1204は、最初にJavaライブラリ1205の中にあるTuner1205cに、チャンネルの識別子を引き渡し、チューニングを依頼する。Tuner1205cは、2次記憶部510が記憶するチャンネル情報を参照し、チューニング情報を獲得する。今、サービスマネージャ1204がチャンネルの識別子「2」をTuner1205cに引き渡すと、Tuner1205cは、図14の列1412を参照して、対応するチューニング情報「156MHz,」を獲得する。Tuner1205cは、OS1201のライブラリ1201bを通して、QAM復調部501にチューニング情報を引き渡す。QAM復調部501は与えられたチューニング情報に従ってヘッドエンド101から送信されてきた信号を復調し、POD504に引き渡す。
【0215】
次にサービスマネージャ1204は、Javaライブラリ1205の中にあるCA1205bにデスクランブルを依頼する。CA1205dは、OS1201のライブラリ1201bを通して復号に必要な情報をPOD504に与える。POD504は、与えられた情報を元に、QAM復調部501から与えられた信号を復号しTSデコーダ505に引き渡す。
【0216】
次にサービスマネージャ1204は、Javaライブラリ1205の中にあるJMF1205aにチャンネルの識別子を与え、映像・音声の再生を依頼する。
【0217】
まず、最初にJMF1205aは、再生すべき映像と音声を特定するためのパケットIDをPAT、PMTから取得する。PATやPMTはMPEG2規格で規定されている、MPEG2トランスポートストリーム内の番組構成を表現するテーブルであり、MPEG2トランスポートストリームに含まれるパケットのペイロードに埋め込まれて、音声や映像と共に送信されるものである。詳細は規格書を参照されたい。ここでは、概略のみ説明する。PATは、Program Association Tableの略で、パケットID「0」のパケットに格納され送信されている。JMF1205aは、PATを取得するため、OS1201のライブラリ1201bを通して、TSデコーダ505にパケットID「0」とCPU514を指定する。TSデコーダ505がパケットID「0」でフィルタリングを行い、CPU514に引き渡すことでJMF1205aは、PATのパケットを収集する。図16は、収集したPATの情報の一例を模式的に表した表である。列1601は、プログラムナンバーである。列1602は、パケットIDである。列1602のパケットIDはPMTを取得するために用いられる。行1611〜1613は、チャンネルのプログラムナンバーと対応するパケットIDの組である。ここでは、3つのチャンネルが定義されている。行1611はプログラムナンバー「101」とパケットID「501」の組が定義されている。今、JMF1205aに与えられたチャンネルの識別子が「2」とすると、JMF1205aは、図14の列1412を参照して、対応するプログラムナンバー「102」を獲得し、次に、図16のPATの列1612を参照し、プログラムナンバー「102」に対応するパケットID「502」を獲得する。PMTは、Program Map Tableの略で、PATで規定されたパケットIDのパケットに格納され送信されている。JMF1205aは、PMTを取得するため、OS1201のライブラリ1201bを通して、TSデコーダ505にパケットIDとCPU514を指定する。ここで、指定するパケットIDは「502」とする。TSデコーダ505がパケットID「502」でフィルタリングを行い、CPU514に引き渡すことでJMF1205aは、PMTのパケットを収集する。図17は、収集したPMTの情報の一例を模式的に表した表である。列1701は、ストリーム種別であり。列1702は、パケットIDである。列1702で指定されるパケットIDのパケットには、ストリーム種別で指定された情報がペイロードに格納され送信されている。列1703は補足情報である。行1711〜1714はエレメンタリ−ストリームと呼ばれる、パケットIDと送信している情報の種別の組である。行1711は、ストリーム種別「音声」とパケットID「5011」の組であり、パケットID「5011」のペイロードには音声が格納されていることを表す。JMF1205aは、PMTから再生する映像と音声のパケットIDを獲得する。図17を参照して、JMF1205aは、行1711から音声のパケットID「5011」を、行1712から映像のパケットID「5012」を獲得する。
【0218】
次に、JMF1205aは、OS1201のライブラリ1201bを通して、獲得した音声のパケットIDと出力先としてオーディオデコーダ506、映像のパケットIDと出力先としてビデオデコーダ508の組を、TSデコーダ505に与える。TSデコーダ505は与えられたパケットIDと出力先に基づいて、フィルタリングを行う。ここではパケットID「5011」のパケットをオーディオデコーダ506に、パケットID「5012」のパケットをビデオデコーダ508に引き渡す。オーディオデコーダ506は、与えられたパケットのデジタル−アナログ変換を行いスピーカ507を通して音声を再生する。ビデオデコーダ508は、与えられたパケットのデジタル−アナログ変換を行いディスプレイ509に映像を表示する。
【0219】
最後にサービスマネージャ1204は、Javaライブラリ1205の中にあるAM1205bにチャンネルの識別子を与え、データ放送再生を依頼する。ここで、データ放送再生とは、MPEG2トランスポートストリームに含まれるJavaプログラムを抽出し、JavaVM1203に実行させることである。MPEG2トランスポートストリームにJavaプログラムを埋め込む方法は、MPEG規格書 ISO/IEC138181−6に記述されたDSMCCという方式を用いる。ここではDSMCCの詳細な説明は省略する。DSMCC方式は、MPEG2トランスポートストリームのパケットの中に、コンピュータで使用されているディレクトリやファイルで構成されるファイルシステムをエンコードする方法を規定している。また、実行するJavaプログラムの情報はAITと呼ばれる形式で、MPEG2トランスポートストリームのパケットの中に埋め込まれ送信されている。AITは、DVB−MHP規格(正式には、ETSI TS 101 812 DVB−MHP仕様V1.0.2)の10章に定義されている、Application Information Tableの略である。
【0220】
AM1205bは、まず、AITを獲得するため、JMF1205a同様PAT、PMTを取得し、AITが格納されているパケットのパケットIDを獲得する。今、与えられたチャンネルの識別子が「2」で、図16のPAT、図17のPMTが送信されていると、JMF1205aと同様の手順で、図17のPMTを獲得する。AM1205bは、PMTからストリーム種別が「データ」で補足情報として「AIT」を持つエレメンタリ−ストリームからパケットIDを抽出する。図17を参照して、行1713のエレメンタリ−ストリームが該当し、パケットID「5013」を獲得する。
【0221】
AM1205bは、OS1201のライブラリ1201bを通してTSデコーダ505にAITのパケットIDと出力先CPU514を与える。TSデコーダ505は、与えられたパケットIDでフィルタリングを行い、CPU514に引き渡す。この結果、AM1205bは、AITのパケットを収集することができる。図18は、収集したAITの情報の一例を模式的に表した表である。列1801はJavaプログラムの識別子である。MHP規格によれば、この識別子はApplication IDとして定義され、Javaプログラムが端末装置500のセキュリティマネージャ1205fによって認証されるべきものであるかが判別できることになっている。識別子の値が、0x0から0x3fffの範囲であれば認証は不要で、0x4000から0x7fffであれば認証されなければならない。以降では、識別子の値として、前者をもつJavaプログラムを「unsignedプログラム」、後者をもつJavaプログラムを「signedプログラム」と呼ぶこととする。列1802はJavaプログラムの制御情報である。制御情報には「autostart」「present」「kill」などがあり、「autostart」は即時に端末装置500がこのプログラムを自動的に実行することを意味し、「present」は自動実行しないことを意味し、「kill」はプログラムを停止することを意味する。列1803は、DSMCC方式でJavaプログラムを含んでいるパケットIDを抽出するためのDSMCC識別子である。列1804はJavaプログラムのプログラム名である。行1811と1812は、Javaプログラムの情報の組である。行1811で定義されるJavaプログラムは、識別子「301」、制御情報「autostart」、DSMCC識別子「1」、プログラム名「a/TopXlet」の組である。行1812で定義されるJavaプログラムは、識別子「302」、制御情報「present」、DSMCC識別子「1」、プログラム名「b/GameXlet」の組である。ここで2つのJavaプログラムは同じDSMCC識別子を持つが、これは1つのDSMCC方式でエンコードされたファイルシステム内に2つのJavaプログラムが含まれていることを表す。ここでは、Javaプログラムに対して4つの情報しか規定しないが、実際にはより多くの情報が定義される。詳細はDVB−MHP規格を参照されたい。
【0222】
AM1205bは、AITの中から「autostart」のJavaプログラムを見つけ出し、対応するDSMCC識別子及びJavaプログラム名を抽出する。図18を参照して、AM1205bは行1811のJavaプログラムを抽出し、DSMCC識別子「1」及びJavaプログラム名「a/TopXlet」を獲得する。
【0223】
次にAM1205bは、AITから取得したDSMCC識別子を用いて、JavaプログラムをDSMCC方式で格納しているパケットのパケットIDをPMTから獲得する。具体的には、PMTの中でストリーム種別が「データ」で、補足情報のDSMCC識別子が合致するエレメンタリ−ストリームのパケットIDを取得する。
【0224】
今、DSMCC識別子が「1」であり、PMTが図17とすると、行1714のエレメンタリ−ストリームが合致し、パケットID「5014」を取り出す。
【0225】
AM1205bは、OS1201のライブラリ1201bを通してTSデコーダ505にDSMCC方式でデータが埋めこめられたパケットのパケットIDと出力先としてCPU514を指定する。ここでは、パケットID「5014」を与える。TSデコーダ505、与えられたパケットIDでフィルタリングを行い、CPU514に引き渡す。この結果、AM1205bは、必要なパケットを収集することができる。AM1205bは、収集したパケットから、DSMCC方式に従ってファイルシステムを復元し、1次記憶部511に保存する。MPEG2トランスポート中のパケットからファイルシステム等のデータを取り出し1次記憶部511等の記憶手段に保存すことを以降、ダウンロードと呼ぶ。
【0226】
図19は、ダウンロードしたファイルシステムの一例である。図中、丸はディレクトリを四角はファイルを表し、1901はルートディレクトリ、1902はディレクトリ「a」,1903はディレクトリ「b」,1904はファイル「TopXlet.class」、1905はファイル「GameXlet.class」である。
【0227】
次にAM1205bは、1次記憶部511にダウンロードしたファイルシステム中から実行するJavaプログラムをJavaVM1203に引き渡す。今、実行するJavaプログラム名が「a/TopXlet」とすると、Javaプログラム名の最後に「.class」を付加したファイル「a/TopXlet.class」が実行すべきファイルとなる。「/」はディレクトリやファイル名の区切りであり、図19を参照して、ファイル1904が実行すべきJavaプログラムである。次にAM1205bは、Javaプログラム識別子の列1801がunsignedプログラムを示しているので、セキュリティマネージャ1205fにJavaプログラムの認証実行を要求する必要はなく、ファイル1904をJavaVM1203に引き渡す。
【0228】
JavaVM1203は、引き渡されたJavaプログラムを実行する。
サービスマネージャ1204は、他のチャンネルの識別子を受け取ると、Javaライブラリ1205に含まれる各ライブラリを通して再生している映像・音声及びJavaプログラムの実行を、同じくJavaライブラリ1205に含まれる各ライブラリを通して停止し、新たに受け取ったチャンネルの識別子に基づいて、映像・音声の再生及びJavaプログラムの実行を行う。
【0229】
Javaライブラリ1205は、ROM512に格納されている複数のJavaライブラリの集合である。本実施の形態では、ここでは、Javaライブラリ1205は、JMF1205a,AM1205b,Tuner1205c,CA1205d、POD Lib1205e,セキュリティマネージャ1205f,ダウンロードモジュール1206等を含んでいる。
【0230】
サービスマネージャ1204とダウンロードモジュール1206は、Javaライブラリ1205に含まれるPOD Lib1205eを通してヘッドエンド101と双方向通信を行う。この双方向通信は、POD Lib1205eはOS1201のライブラリ1201b及び、POD504を介して、QPSK復調部502、QPSK変調部503を使用して実現される。
【0231】
ダウンロードモジュール1206は、この通信を用いてヘッドエンド101から、コードデータを受け取ることができる。コードデータとは、X.509証明書と端末装置500のファームウェアのどちらかもしくは両方を含んだバイナリデータのことである。図50は、本発明に関する部分のみを記述したコードデータの模式図である。ダウンロードモジュール1206がコードデータ5000を受け取ると、もしコードデータがルート証明書5001を含んでいるならば、それを抽出し、セキュリティマネージャ1205fへ引き渡たす。5002はファームウェア等その他のデータを示す。
【0232】
また、AM1205bは、ヘッドエンド101から、端末装置500が2次記憶部510に保存すべきJavaプログラムの情報を受け取る。この情報をXAIT情報と呼ぶ。XAIT情報は、ヘッドエンド101とPOD504間で、任意の形式で送信される。どのような送信形式を採用しても、XAITに必要とする情報が含まれていれば、本発明は実施可能である。
【0233】
図43は、ヘッドエンド101から取得したXAITの情報の一例を模式的に表した表である。列4301はJavaプログラムの識別子である。列4302はJavaプログラムの制御情報である。制御情報には「autostart」「present」などがあり、「autostart」は端末装置500が電源投入時にこのプログラムを自動的に実行することを意味し、「present」は自動実行しないことを意味する。列4303は、DSMCC方式でJavaプログラムを含んでいるパケットIDを抽出するためのDSMCC識別子である。列4304はJavaプログラムのプログラム名である。列4305は、Javaプログラムの優先度である。行4311と4312は、Javaプログラムの情報の組である。行4311で定義されるJavaプログラムは、識別子「0x7001」、制御情報「autostart」、DSMCC識別子「1」、プログラム名「a/PPV1Xlet」の組である。Javaプログラムの識別子Application IDから、Javaプログラムはsignedプログラムであることが分かる。ここでは、Javaプログラムに対して5つの情報しか規定しないが、より多くの情報が定義されていても本発明は実施可能である。
【0234】
AM1205bは、XAIT情報を受け取ると、AIT情報からJavaプログラムをダウンロードした手順と同じ手順で、MPEG2トランスポートストリームからファイルシステムを1次記憶部511上に展開する。その後、ファイルシステムを2次記憶部510に保存する直前に、セキュリティマネージャ1205fへ保存直前通知を行う。このとき、本発明に関するセキュリティマネージャ1205fの認証が動作するが、詳細は後に述べる。AM1205bは、セキュリティマネージャ1205fより起動許可を通知されると、ファイルシステムを2次記憶部510に保存する。次に、AM1205bは、XAIT情報にダウンロードしたファイルシステムの格納位置を対応つけて2次記憶部510に保存する。図44は、2次記憶部510がXAIT情報とダウンロードしたファイルシステムが対応つけられて保存されている一例を表す。ここではOCAP規格で定義されているファイルを取り上げて説明する。図44の中で、図43と同じ番号の要素は図43と同じなので、説明は省略する。列4401は対応するダウンロードしたファイルシステムの保存位置を格納する。図中、保存位置は矢印で示している。4410はダウンロードしたファイルシステムであり、内部にトップディレクトリ4411、ディレクトリ「a」4412、ディレクトリ「b」4413、ファイル「PPV1Xlet.class」4414、ファイル「PPV2Xlet.class」4415、ファイル「ocap.hashfile」4416〜4418、ファイル「ocap.certificate.1」4419、ファイル「ocap.signaturefile.1」4420を保持する。
【0235】
ファイル4416〜4418はハッシュファイルで、ファイル名またはディレクトリ名とそれらに対応するハッシュ値を格納している。図45Aの451は“ocap.hashfile”4416、図45Bの452は“ocap.hashfile”4417、図45Cの453は“ocap.hashfile”4418の内容をそれぞれ表した模式図である。451の“ocap.hashfile”は、“/”ディレクトリ4411に存在し、同じディレクトリ4411に存在する“ocap.certificate.1”ファイル4419、“ocap.signaturefile.1”ファイル4420、“a”ディレクトリ4412、“b”ディレクトリ4413を4511列に格納する。4512列は、4513列にそれぞれ記述されている値が何のハッシュアルゴリズムによって計算された値であるのかを示す。4513列は、4511列のファイルまたはディレクトリに関し、4512列で指定されたアルゴリズムを使って計算されたハッシュ値を格納する。ハッシュアルゴリズムには、SHA1(Secure Hash Algorithm 1)とMD5(Message Digest 5)というアルゴリズムが現在主に利用されている。これらは、任意の長さのデータを固定長のバイト値に変換する公知技術のアルゴリズムで、次の特徴をもつ。変換後のデータから元データを推測することができず、ファイルが破損もしくは改竄されていないかを確認するために使用される。一方、ハッシュ値とは、ハッシュアルゴリズムで生成された擬似乱数のことである。ハッシュアルゴリズムがSHA1の時、ハッシュ値の長さは20バイトで、MD5の時は、ハッシュ値の長さは16バイトに換算される。SHA1、MD5の詳細については、それぞれ“FIPS−PUB 186−2 Secure Hash Standard”、“IETF RFC1321”を参照されたい。ここで、4511列に記述されたディレクトリ“a”“b”に対応するハッシュ値はそれぞれ、“a”ディレクトリに存在する“ocap.hashfile”ファイル4417、“b”ディレクトリに存在する“ocap.hashfile”ファイル4418に対して計算されたSHA1ハッシュ値である。
【0236】
451の“ocap.hashfile”と同様、452の“ocap.hashfile”は、同じディレクトリ4412に存在する“PPV1Xlet.class”ファイル4414のファイル名、ハッシュアルゴリズム、ハッシュ値を格納する。453についても同様に、同じディレクトリ4413に存在する“PPV2Xlet.class”ファイル4415のファイル名、ハッシュアルゴリズム、ハッシュ値を格納する。
【0237】
ここでは、本発明に関係する属性のみを取り上げたが、“ocap.hashfile”の詳細な構成については、OCAP規格書である“OpenCable(TM) Application Platform Specification OCAP 1.0 Profile(OC−SP−OCAP1.0−IF−I09−031121)”を参照されたい。
【0238】
ファイル4419は証明書チェーンである。図23は、“ocap.certificate.1”ファイル4419の構成内容を示した構成図である。“ocap.certificate.x”(xは正の整数)の一般的な構成を表現している231は、ルート証明書2311、中間証明書2312、リーフ証明書2313を内包する。これらは、ルート証明書2311の所有者が中間証明書2312を発行し、中間証明書2312の所有者がリーフ証明書2313を発行するといった、連鎖関係にある。なおOCAP規格では、署名ファイル“ocap.signaturefile.x”と関係する証明書チェーンは、同じ値“x”をもつ“ocap.certificate.x”である。図44の場合、“ocap.signaturefile.1”に対応する証明書チェーンは、“ocap.certificate.1”となる。そして、ルート証明書2311、中間証明書2312、リーフ証明書2313は、共通のX.509証明書のフォーマットで構成される。X.509証明書は、ITU−Tのレコメンデーションで、証明書の表現形式のデファクト標準として情報通信の各分野で広く普及している。図23では3つの証明書のみを図示しているが、中間証明書が複数存在することもある。但し、中間証明書間で相互に関連した連鎖状態になければならない。
【0239】
図24はX.509証明書の構成図である。ここでは、本発明の説明の上で必要な属性のみを列挙している。X.509証明書の詳細については、IETF RFC3280“Internet X.509 Public Key Infrastructure Certificate and CRL Profile”を参照されたい。241はX.509証明書の属性領域、242はX.509証明書の署名値を示す。シリアル番号2411は証明書を識別するための番号、署名アルゴリズム2412は署名値242を計算するために使用されたアルゴリズム、今回更新日時2413は本X.509証明書の有効開始日時、次回更新時間2414は本X.509証明書の有効満了日時、発行者名2415は本X.509証明書を発行する機関名、主体者名2416は本X.509証明書の所有者、公開鍵2417は主体者名2416の公開鍵、署名値242は本X.509証明書発行者の秘密鍵によって署名(暗号化)された値を表す。公開鍵と秘密鍵を使ったものとして、公開鍵暗号方式が電子商取引等で幅広く利用されている。公開鍵暗号方式では、平文を暗号化するときに使用した鍵と異なる鍵を使用して暗号文を復号する。暗号用の鍵と復号用の鍵が異なり、復号用の鍵を一般公開しても復号用の鍵から暗号用の鍵を推測することは不可能である。この暗号用の鍵が秘密鍵、復号用の鍵が公開鍵に該当する。公開鍵暗号方式の代表例としては、RSA(Rivest−Shamir−Adleman)、DSA(Digital Signature Standard)が挙げられる。
【0240】
ファイル4420は署名ファイルである。図25は、“ocap.signaturefile.1”ファイル4420の模式図である。251はどのX.509証明書と関係するのかを示す証明書識別子、252はハッシュ署名アルゴリズム、253は252で示されるハッシュ署名アルゴリズムを用いて、“ocap.hashfile”4416から計算された署名値を表す。
【0241】
Javaプログラムが2次記憶部510に保存されると、チャンネル変更、端末装置500の電源OFF等により1次記憶部509からそれが消去されたとしても、AM1205bが図43で示すXAITを受信すれば、ダウンロードを待たずにJavaプログラムが起動される。すなわち、図43では、プログラム“/a/PPV1Xlet”が制御情報4302として「autostart」になっている。そこで、図44の4311において、“/a/PPV1Xlet”に対応するファイルシステムの保存位置4401を探し、ファイル4414をJavaVM1203に引き渡すと、ファイルシステムに保有されているJavaプログラム“PPV1Xlet”が起動される。
【0242】
次に、本発明の主要機能であるセキュリティマネージャ1205fについて説明する。
セキュリティマネージャ1205fは、AM1205bから図43の4304で示される“/a/PPV1Xlet”と“/b/PPVXlet2”が保存されようとしていることを表す保存直前通知を通知される。その通知を受け取ると、Javaプログラム識別子4301の値を調べ、unsignedプログラムであるのか、signedプログラムであるのかを判断する。ここで、Javaプログラムはsignedプログラムであるので、“/”ディレクトリ以下のファイルシステムについて、認証を実行する。認証では、図44のocap.hashfile(4416〜4418)、ocap.certificate.1(4419)、ocap.signaturefile.1(4420)を使用して検証する。
【0243】
図26は、ファイルシステムの認証を実行する際のセキュリティマネージャ1205fの構成要素を示す。
【0244】
通知受取手段261は、AM1205bがファイルシステムを保存しようとする直前に保存直前通知を受け取るための手段であり、それを判定手段262へ伝える。
【0245】
判定手段262は、認証結果を決定する。ハッシュ計算手段263へファイルシステムのハッシュ計算を要求し、ハッシュ値を受け取る。判定手段262は“ocap.hashfile”ファイルに存在するハッシュ値4513、4523、4533から比較すべき値を取り出して、一致するかを確認する。一致しなければ、改竄があったものと判断し、認証は失敗となる。
【0246】
また、判定手段262は、証明書抽出手段265を用いて各X.509証明書を取り出し、現在時刻がX.509証明書の今回更新日時2413と次回更新日時2414の間にあるかを判断する。なお、現在日時は、OS1201のライブラリ1201bから取得する。もし、“今回更新日時<現在日時<次回更新日時”という期間有効性がなければ、認証は失敗と判断する。
【0247】
さらに、判定手段262は、証明書チェーンの認証を行うために、X.509証明書の属性領域241のハッシュ計算をハッシュ計算手段263に要求する。そして、署名値復号手段264へX.509証明書に含まれる署名値242の復号計算を要求して、得られた復号値とハッシュ計算手段263で得られたハッシュ値を比較し、証明書連鎖の状況を確認する。もし不一致であれば、連鎖しておらず、認証は失敗と判断される。一方、一致して連鎖が確認できれば、証明書チェーンのルート証明書が、端末装置500の2次記憶部510に含まれているかを確認する。もし含まれていなければ、照合不可能として、認証は失敗と判断する。
【0248】
判定手段262が認証の成功と判断するのは、(1)改竄なし、(2)期間有効性あり、(3)証明書連鎖あり、(4)ルート証明書が一致、をすべて満たすときである。
【0249】
ハッシュ計算手段263は、判定手段262より各ファイルのハッシュ値計算を要求され、OS1201のライブラリ1201bから各ファイルを取り出して、そのハッシュ計算を行い、結果を判定手段262へ渡す。また、証明書チェーン231内の各X.509証明書を証明書抽出手段265から取得し、属性領域241に対してハッシュ計算を行う。
【0250】
署名値復号手段264は、判定手段262からX.509証明書もしくは“ocap.signaturefile.x”の署名値を復号計算するように要求される。X.509証明書の署名を復号計算する際には、証明書抽出手段265から証明書チェーン231の各X.509証明書を取得した上で、署名の復号計算を実施し、結果を判定手段262へ返す。
【0251】
証明書抽出手段265は、判定手段262、ハッシュ計算手段263、署名値復号手段264から、証明書チェーン231の中にある各X.509証明書を抽出するように要求を受けて、X.509証明書を抽出して返す。
【0252】
図27は、ファイルシステムの認証を実行する際のセキュリティマネージャ1205fの動作をまとめたフローチャートである。以下、ファイルシステムの構成が図44である場合の動作をフローチャートに則して説明する。AM1205bからファイルシステムの保存直前通知を受け付けると(ステップS271)、ファイルシステムの最上位ディレクトリ“/”以下のファイルシステムについて改竄チェックを行う(ステップS272)。改竄チェックでは、ファイルシステムの各ディレクトリに存在するファイルに対して、破損及び変更がなされていないかをハッシュ値比較で確認する。
【0253】
図46と図30は、ステップS272の詳細なフローチャートを示す。まず、ステップS461に示すとおり、“/”ディレクトリに存在するファイル“ocap.certificate.1”、“ocap.signaturefile.1”と、ディレクトリ“a”、“b”のハッシュ値をそれぞれ計算する。なお、ディレクトリ“a”、“b”のハッシュ値はそれぞれ、“/a/ocap.hashfile”ファイル452、“/b/ocap.hashfile”ファイル453から計算される。ステップS463で、ステップS462で計算したハッシュ値と、“/ocap.hashfile”中の4513のハッシュ値とをそれぞれ比較する。ステップS464において、一つでも計算したハッシュ値と4513のハッシュ値とが異なれば、改竄があったと判断する(ステップS467)。一方、計算したハッシュ値と4513のハッシュ値がすべて一致した場合、ステップ465へ移る。ステップ465では、改竄チェックが完了していないサブディレクトリがないかを確認する。現時点では、“a”と“b”のディレクトリが“/”のサブディレクトリとして存在し、それらはまだ改竄チェックが完了していないので、“a”と“b”ディレクトリに対して改竄チェックを行う必要がある。ステップS466として、まず“a”ディレクトリに注目することとし、“/”ディレクトリと同様の処理を行う。“a”ディレクトリでの改竄チェック完了後、“b”ディレクトリでの改竄チェックを実施する。“a”と“b”のディレクトリに対する改竄チェックが完了すると、“/”ディレクトリに注目して、図30のステップS301の処理を行う。ステップS301では、証明書チェーン231である“/ocap.certificate.1”ファイル4419からリーフ証明書2313を抽出する。そして、抽出したリーフ証明書2313から公開鍵2417をステップS302で取り出す。その後、ステップS303では、“/ocap.hashfile”ファイル451のハッシュ値を計算する。一方、ステップS304で、“/ocap.certificatefile.1”ファイル4419のリーフ証明書2313に存在する公開鍵2417を用いて、“/ocap.signaturefile.1”ファイル4420の署名値242に対して復号を行う。ステップS305では、ステップS303で計算したハッシュ値と、ステップS304で得た署名値を復号した値が等しいかを確かめる。もし、計算値が一致すれば、“/”ディレクトリ以下のファイルシステムは改竄されていないと判断できる(ステップS306)。一方、計算値が一致しなければ、ファイルシステムは改竄されていると判断できる(ステップS307)。なお、改竄チェックは、最上位である“/”ディレクトリからサブディレクトリに向かって降順に処理する例を挙げたが、本発明はこれに限定するものではない。最下位ディレクトリから最上位ディレクトリへ向かって昇順に処理することにしても構わない。以上により、図27中のステップS272の結果が得られる。
【0254】
ステップS273では、もしステップS272での結果が「改竄あり」であった場合、認証は失敗と判断して通知(ステップS279)後に終了する。ステップS272での結果が「改竄なし」の場合には、ステップS274を処理する。
【0255】
次に、図31〜図33を用いて、証明書チェーンの認証(ステップS274)を詳細に説明する。まず、中間証明書2312とリーフ証明書2313間でのチェックを行うこととし、図31にそのフローチャートを図示する。最初に、証明書チェーン231から中間証明書2312とリーフ証明書2313を抽出する(ステップS311)。抽出したリーフ証明書2313から今回更新日時2413、次回更新日時2414、発行者名2415を抽出する(ステップS312)。このうち、現在の日時が今回更新日時2413から次回更新日時2414までの証明書が有効な期間であるかを判断する(ステップS313)。もし、証明書が有効な期間外であれば、証明書チェーンの認証は失敗(ステップS319)となる。一方、証明書が有効な期間であると判断すると、中間証明書2312の主体者名2416と公開鍵2417を抽出し(ステップS314)、中間証明書2312の主体者名2416とリーフ証明書2313の発行者名2415を比較して、中間証明書2312とリーフ証明書2313が連鎖関係にあるかを判別する(ステップS315)。もし、証明書間で連鎖関係になければ、証明書チェーンの認証は失敗となる。他方、連鎖関係が成り立てば、リーフ証明書2313の属性領域241のハッシュ値を計算する(ステップS316)。また、中間証明書2312の公開鍵2417を利用して、リーフ証明書2313の署名値242を復号する(ステップS317)。ステップS316とステップS317が完了すると、それぞれから得られるハッシュ値と署名復号値が一致するかどうかを判断する(ステップS318)。もし、一致しなければ証明書チェーンの認証は失敗となる(ステップS319)。
【0256】
次に、ルート証明書2311と中間証明書2312間でのチェックを行う。図32にそのフローチャートを図示する。証明書チェーン231からルート証明書2311と中間証明書2312を抽出し(ステップS321)、中間証明書2312とリーフ証明書2313間のチェックと同様の処理を、ルート証明書2311と中間証明書2312に対して行う(ステップS322〜ステップS328)。
【0257】
そして、ステップS328で一致すると判断された場合、ルート証明書2311単独のチェックを行う。図33は、ルート証明書2311単独チェックのフローチャートである。ステップS321で抽出したルート証明書2311から、今回更新日時2413、次回更新日時2414、発行者名2415を抽出する(ステップS331)。このうち、現在の日時が今回更新日時2413から次回更新日時2414までの証明書が有効な期間であるかを判断する(ステップS332)。もし、証明書が有効な期間外であれば、証明書チェーンの認証は失敗となる。一方、証明書が有効な期間であると判断すると、ルート証明書2311の属性領域241のハッシュ値を計算する(ステップS334)。また、ルート証明書2311の公開鍵2417を利用して、ルート証明書2311の署名値242を復号する(ステップS335)。ステップS334とステップS335が完了すると、それぞれから得られるハッシュ値と署名復号値が一致するかどうかを判断する(ステップS336)。もし一致すれば、証明書チェーンの認証は成功(ステップS337)であり、一致しなければ証明書チェーンの認証は失敗(ステップS338)となる。ここで、ステップS274の処理が終了する。
【0258】
ステップS275では、S274の結果に応じて、処理が異なる。ステップ4の結果が「証明書チェーンの認証失敗」の場合、認証失敗と判断して通知し(ステップS279)、ファイルシステムとしての認証は終了する。一方、「証明書チェーンの認証成功」の場合、ステップS276を処理する。
【0259】
次に、“/ocap.certificate.1”ファイル4419のルート証明書2311と同じ証明書を端末装置500の2次記憶部510から探す(ステップS276)。ステップS277において、2次記憶部510に存在しない場合には、証明書チェーン231の認証は失敗と判断し、認証失敗を通知(ステップS279)後、終了する。一方、そのルート証明書2311が含まれている場合には、ファイルシステムの認証は成功と判断し、AM1205bへ認証成功を通知する(ステップS278)。その後、図28を参照して、Javaプログラムの起動直前通知を受けても(ステップS281)、何もせずに終了する。
【0260】
この実施の形態2では、保存したJavaプログラムが一定時間経過後に起動されるとき、ファイルシステムの認証は保存直前に実行済みなので、この時点で認証する必要はない。
【0261】
また、ファイルシステムに図47で示す“application description file”が存在し、それに記述されたファイルのみが保存対象である場合について説明する。例えばOCAP規格では、“application description file”はXML(eXtensible Markup Language)形式で記述される。この一例である図47に“application description file”の例を示す。図47では、図44の“PPV2Xet.class”4415が記述されていない。従って、この場合には“PPV2Xet.class”4415は保存対象外ということになる。この時、S462で“PPV2Xet.class”4415に対してはハッシュ値を計算せず、S463で“ocap.hashfile”ファイル4418に記述された4533のハッシュ値と比較しない。S464では、保存対象外のファイルは適用除外ということで、S465の処理へ進むことにしてもよい。
【0262】
(実施の形態3)
ファイルシステムを保存してから一定時間経過後にファイルシステムに含まれるJavaプログラム(PPV1Xlet.class4414もしくはPPV2Xlet.class4415)が起動されるとき、“/ocap.certificate.1”ファイル4419に含まれるX.509証明書のどれかが期限切れ(つまり、Javaプログラム起動日時>次回更新日時2414)になっている可能性がある。実施の形態2のままでは、すでに期限切れになってしまったX.509証明書が証明書チェーン231に含まれていても、Javaプログラムの起動を許してしまう。
【0263】
従って本実施の形態では、実施の形態2に、Javaプログラムの起動時には証明書チェーン231の各証明書2311、2312、2313が有効期限切れになっていないかを確認する機能を追加する。本実施の形態における構成要素を図26に示す。本実施の形態で必要な構成要素261〜265の説明は、実施の形態2で行ったのでここでは省略する。
【0264】
フローチャートにおいては、図27のフローチャートを図48のフローチャートに置き換え、図49のフローチャートを追加する。
【0265】
図48を参照して、ファイルシステムの保存直前時の処理(ステップS481〜ステップS487)は、実施の形態2で説明した処理(ステップS271〜ステップS277)と同じであるので、説明は省略する。認証失敗でなければ、処理は図49のフローチャートに続く。一定時間経過後に、JavaプログラムであるPPV1Xlet.class4414の起動通知を受けるとき(ステップS491)、“ocap.certificate.1”ファイル4419からルート証明書2311、中間証明書2312、リーフ証明書2313の各X.509証明書を抽出する(ステップS492)。抽出したX.509証明書をリーフ証明書からルート証明書の順に一つずつ選択して(ステップS493)、現在日時が選択したX.509証明書の今回更新日時2413と次回更新日時2414の間であるかを確認する(ステップS494)。もし、現在日時が今回更新日時2413と次回更新日時2414の間でなければ、認証失敗と判断し、それを通知する(ステップS497)。他方であれば、すべてのX.509証明書について確認が完了しているかを調べる(ステップS495)。もし、まだすべてのX.509証明書を確認完了していない場合、ステップS493に戻って処理を繰り返す。一方ステップS495で、すべてのX.509証明書を確認済みであれば、認証成功と判断し、認証成功を通知してから(ステップS496)、処理を終了する。図49のフローチャートに示した処理を追加することによって、証明書の期限切れが発生しているJavaプログラムを起動しないようにAM1205bに認証失敗を通知可能となる。AM1205bは、セキュリティマネージャ1205fから認証失敗を通知されると、JavaプログラムをJavaVM1203へ渡さず、起動を中止する。
【0266】
(実施の形態4)
実施の形態2で記述したように、2次記憶部510にはルート証明書であるX.509証明書が含まれており、それは証明書チェーン231のルート証明書2311と比較される。2次記憶部510に格納されたルート証明書は、ハック等によって証明書の信用性が低下する場合に備えて、新しいX.509証明書と交換される(以降では、証明書交換と呼ぶ)。新しいX.509証明書は、ヘッドエンド101から端末装置500へ送られ、ダウンロードモジュール106が仲介してセキュリティマネージャ1205fへと運ばれる。
【0267】
図51A〜図51Cは、セキュリティマネージャ1205fによって、2次記憶部510にあるルート証明書の交換(証明書交換)が行われる様子を示した図である。この場合、証明書A5101が交換される古い証明書で、証明書B5102が新しい証明書である。図51Aの51−1は証明書交換前の2次記憶部510にある証明書の状態、図51Bの51−2は証明書交換中の状態、図51Cの51−3は証明書交換後の2次記憶部510にある証明書の状態である。
【0268】
実施の形態2及び実施の形態3では、Javaプログラムの保存後に証明書交換が行われたとしても、Javaプログラムの起動時には、交換後の証明書が考慮されない。例えば、セキュリティマネージャ1205fがJavaプログラムの保存直前通知を受けて認証した時に、証明書チェーン231のルート証明書2311が証明書A5101と一致していたとする。そして、証明書A5101と証明書B5102の証明書交換を経て、Javaプログラムの起動直前通知を受け取ったとする。この時点で、信用性のある証明書を格納している2次記憶部510には、証明書チェーン231のルート証明書2311と一致する証明書は存在しないため、その証明書は信用性のないものとなっている。しかし、実施の形態2及び実施の形態3では、Javaプログラムの起動直前にルート証明書の照合を行わない(つまり、証明書チェーン231のルート証明書2311と証明書B5102とを比較しない)ので、AM1205bに認証失敗を通知しない。その結果、AM1205bがJavaプログラムを起動させてしまう。
【0269】
従って本実施の形態では、Javaプログラムの起動時に証明書交換を考慮して、ルート証明書の照合を行う機能を追加する。
【0270】
本実施の形態における構成要素を図26に示す。構成要素261〜265については前記したのでここでの説明は省略するが、証明書交換手段266、交換証明書特定手段267、証明書受信手段268を追加する。
【0271】
証明書交換手段266は、受け取った証明書より古い証明書が2次記憶部510に保存されていることを交換証明書特定手段267によって判断された場合には、古い証明書と新しい証明書を入れ替える。一方、交換証明書特定手段267が古い証明書を保存していないと判断した場合には、2次記憶部510に新しい証明書を保存する。
【0272】
交換証明書特定手段267は、証明書受信手段268で受信された証明書を受け取る。すると、OS1201のライブラリ1201bを利用して、2次記憶部510に格納している証明書を調べ、発行者が同じで、受け取った証明書より古い証明書を保存しているか確認する。
【0273】
証明書受信手段268は、ダウンロードモジュール1206が新しい証明書をヘッドエンド101から受信したときに、その新しい証明書を受け取る。証明書を受け取ると、証明書交換手段266と交換証明書特定手段267に渡す。
【0274】
また、図48のフローチャートに引き続いて、図52と図53を追加する。
図52は、証明書交換が行われる際のフローチャートであり、図53は、証明書交換後のJavaプログラムが起動される際のフローチャートである。図52を参照して、証明書交換要求を受け付けると(ステップS521)、受け取った証明書の発行者名を取り出す(ステップS522)。端末装置500の2次記憶部510に交換されるべき古い証明書が存在するかを確認し(ステップS523)、もし、存在する場合のみ、その古い証明書を削除する。そして、受け取った証明書を2次記憶部510に保存する(ステップS525)。一定時間経過後、Javaプログラムの起動通知を受け取ると(ステップS531)、2次記憶部510から証明書チェーン231のルート証明書2311と一致する証明書を探し(ステップS532)、存在すれば(ステップS533)、認証成功と判断して通知する(ステップS534)。存在しなければ(ステップS533)、認証失敗と判断して通知する(ステップS535)。なお、S534で認証成功と判断する前に、証明書チェーン中の各X.509証明書に対して、“今回更新日時<現在の日時<次回更新日時”であるかを確認した上で、認証成功を結論付けることにしてもよい。
【0275】
また、ルート証明書の一致を確認することに加えて、図31〜図33に示した証明書チェーンの証明書連鎖の確認をS532の前に行った上で、認証の成功・失敗を判断してもよい。
【0276】
また、発行者名をもとに交換すべき証明書を特定する記述を行っているが、主体者名などの別の属性値で証明書の特定を行ってもよい。
【0277】
(実施の形態5)
ファイルシステムを保存してから一定時間経過後にファイルシステムに含まれるJavaプログラム(PPV1Xlet.class4414もしくはPPV2Xlet.class4415)が起動されるとき、“/ocap.certificate.1”ファイル4419に含まれるX.509証明書のどれかが、証明書の満了期間を経過した、または、ルート証明書が交換されたこと以外でも無効化されることがある。このままでは、証明書が無効化されているにもかかわらず、Javaプログラムが起動されることを許してしまう。
【0278】
ここで、証明書を無効化するものとして、CRL(Certificate Revocation List)が広く知られている。図54は、CRLの構成図である。ここでは、本発明の説明の上で必要な属性のみを列挙している。CRLのより詳細については、IETF RFC3280“Internet X.509 Public Key Infrastructure Certificate and CRL Profile”を参照されたい。541はCRLの属性領域、542は署名値543の署名アルゴリズム、543はCRLの署名値を示す。発行者名5411は本CRLの発行者、今回更新日時5412は本CRLの有効開始日時、次回更新時間5413は本CRLの有効満了日時、失効証明書リスト5414は失効したX.509証明書の情報を示す。図55は、失効証明書リスト5414の構成図である。ここでも、本発明の説明の上で必要な属性のみを列挙している。失効証明書リスト5414は、複数の失効したX.509証明書の情報を格納する。図55の場合、失効した“証明書A”551には、証明書を一意に特定するシリアル番号5511、“証明書A”551の失効した日時5512が格納されている。他の失効証明書についても、551と同様である。
【0279】
図56は、CRLを含むファイルシステム構成の一例である。内部に“/”ディレクトリ561、“a”ディレクトリ562、“SimpleXlet.class”ファイル563、564〜565は“ocap.hashfile”ファイル、“ocap.certificate.1”ファイル566、“ocap.signaturefile.1”ファイル567、“ocap.crl.2”ファイル568、“ocap.certificate.2”ファイル569を保持する。CRLを含まないファイルシステムの認証については、実施の形態2で説明したとおりである。よって、本実施の形態では、CRLのフォーマットで構成される“ocap.crl.2”ファイル568と、そのファイルの証明書チェーンである“ocap.certificate.2”ファイル569に着目する。なおOCAP規格では、“ocap.crl.x”に対応する証明書チェーンは、“ocap.certificate.x”である。図56の場合、“ocap.crl.2”に対応する証明書チェーンは、“ocap.certificate.2”である。
【0280】
図59は、“ocap.hashfile”ファイル564の模式図である。591は564のocap.hashfileの内容を表す。591のocap.hashfileは、“/”ディレクトリ561に存在し、同じディレクトリ561に存在する“ocap.certificate.1”ファイル566、“ocap.signatrefile.1”ファイル567、“a”ディレクトリ562、“ocap.crl.2”ファイル568、“ocap.certificate.2”ファイル569に関するハッシュ値をそれぞれ格納する。
【0281】
図57は、CRLの認証について説明したフローチャートである。ファイルシステムが図56の構成を取っているときを例に挙げて以下に説明する。まず、CRLから今回更新日時5412と次回更新日時5413を抽出する(ステップS571)。現在日時が、今回更新日時5412と次回更新日時5413の間であるかを確認する(ステップS572)。もし、当てはまらないならば、本CRLは無効であると判断する(ステップS577)。当てはまるならば、“ocap.crl.2”ファイル568の署名値を検証するために、属性領域541部分のハッシュ値を計算する(ステップS573)。一方、証明書チェーン“ocap.certificate.2”ファイル569からリーフ証明書2313の公開鍵2417を抽出し(ステップS574)、抽出した公開鍵2417を用いて、“ocap.crl.2”ファイル568の署名値543を復号する(ステップS575)。そして、ステップS573で得たハッシュ値とステップS575での復号値が等しいかを確認し(ステップS576)、等しくなければCRLは無効だと判断する(ステップS577)。等しければ、図58を参照して、証明書チェーン“ocap.certificate.2”ファイル569の認証を行う(ステップS581)。証明書チェーンの認証方法は、前記した図31〜図33と同じであるので、ここでは省略する。その後、証明書チェーンの認証が成功したかを判断し(ステップS582)、もし失敗ならば、本CRLは無効であると判断する(ステップS586)。一方、成功ならば、2次記憶部510からルート証明書と同じ証明書を探す(ステップS583)。ここで、一致するルート証明書が存在しないならば、本CRLは認証失敗で無効と判断し(ステップS586)、含まれるならば、CRLは認証成功で有効と判断する(ステップS585)。
【0282】
ここから、証明書がCRLによって無効化されているにもかかわらず、Javaプログラムが起動されるという問題点の解決方法について記述する。これに対応するため、本実施の形態では、Javaプログラムの起動通知が行われたとき、Javaプログラムを認証した証明書がCRLによって失効されたか判断する機能を追加する。
【0283】
本実施の形態における構成要素を図26に示す。一部追加のある262とまだ説明していない269以外については、前記しているので説明を省略する。
【0284】
判定手段262は、CRLを認証する機能をさらに持ち、失効証明書特定手段269にCRLによって失効される証明書の特定を要求する。そして、失効証明書特定手段269で特定された失効した証明書と関係するJavaプログラムの起動直前通知を通知受取手段261で受け付けたとき、判定手段262は認証失敗と判断する。一方、判定手段262がCRLの認証に失敗してCRLは無効であると判断していれば、Javaプログラムの起動直前通知を通知受取手段261で受け付けたとき、判定手段262は認証成功と判断する。
【0285】
失効証明書特定手段269は、判定手段262でCRLの認証が成功であったことを認識するとき、証明書抽出手段265で抽出したX.509証明書のどれが失効した証明書であるかを特定する。
【0286】
また、フローチャートについては図60と図61を追加する。以下に、フローチャートに則して説明する。今、図44で示されるファイルシステムに対する保存直前通知が発生したとすると、図48のフローチャートで示される処理を開始し、やがてステップS487の処理が完了する。その後、図56で示される別のファイルシステムの保存直前通知を受け付けたとすると、図57のフローチャートで示す処理を完了後、ステップS6001〜ステップS6007を行う。ステップS6001〜ステップS6007の処理は、ステップS481〜ステップS487までと同様である。ステップS6008に到達したとき、“ocap.crl.2”ファイル568の認証(図57、図58のフローチャート)が成功であれば、それに内在する失効証明書の情報を失効証明書データベースに登録する。図62は失効証明書データベースの模式図である。621列に発行者名、622列に証明書のシリアル番号、623列に失効した日時を格納する。ここで、図44の“PPV1Xlet.class”4414の起動直前通知を受け付けると(ステップS611)、“ocap.certificate.1”ファイル4419の証明書チェーン231にあるX.509証明書が、失効証明書データベースに該当しないか確認する(ステップS613)。もし、該当する証明書があれば、認証失敗と判断して通知する(ステップS616)。一方、どの証明書も該当しないならば、すべての証明書チェーンについて確認した後(ステップS614)、認証成功と判断して通知する(ステップS615)。以上から、検証時は有効であった証明書が、Javaプログラムの起動時にはCRLによってすでに失効されていても、そのファイルシステムは認証失敗と判断され、起動すべきでないJavaプログラムが起動されてしまうという問題点を解決できる。
【0287】
なお、実施の形態1〜5において、Javaプログラムの起動直前通知を受け付けた際、各ディレクトリに配置された“ocap.hashfile”を利用して、ファイルシステムのツリー構成が正しいかの検証をさらに行ってもよい。
【0288】
また、証明書チェーンの中間証明書は、簡単のため一つにしているが、複数存在していても構わない。但し、証明書チェーンの認証の際には、すべての中間証明書間で連鎖状態になっている必要がある。
【0289】
また、改竄有無のチェック、証明書チェーンの認証、ルート証明書の2次記憶部に証明書チェーン中のルート証明書が存在するかの確認をこの順序で記述しているが、順序はこれにこだわるものではない。
【0290】
また、ファイルシステムの保存は、セキュリティマネージャ1205fがOSのライブラリ1201bを利用して保存してもよい。また、“application description file”がファイルシステムのトップディレクトリ“/”で提供され、その内容として、ファイルの保存対象としてファイルシステムの一部だけを指示している場合であっても、実施の形態1〜5は適用可能で、保存対象のファイルのみ扱っても問題ない。
【0291】
また、保存の対象としてプログラムを取り上げているが、プログラム以外のデータであってもよく、データに対して実施の形態1〜実施の形態5を適用してもよい。
【0292】
また、“ocap.signaturefile.x”に対応する“ocap.certificate.x”が複数存在することもあり得るが、その場合少なくとも一つの“ocap.certificate.x”で認証が成功すればよい。
【0293】
また、証明書チェーンとして“ocap.certificate.x”、ハッシュ値をもつファイルとして“ocap.hashfile”、“/”ディレクトリに存在する“ocap.hashfile”の改竄チェック用ファイルとして“ocap.signaturefile.x”を例として挙げたが、本発明はこれらのファイル名に限定されるものではない。
【0294】
また、認証失敗の場合はダウンロードし直して実行することにしてもよい。
また、認証失敗の場合には、保存領域の容量を確保するために、保存済みのプログラム及び認証に利用した証明書チェーン、署名ファイル、ハッシュファイルを削除してもよい。
【0295】
また、プログラムを構成するファイルシステムの構成が図63であるときに、図64の“application description file”のように認証に使用するファイルが記述されていない場合について説明する。図63中の6311から6320まではそれぞれ、図44の4411から4420と同じである。6321は、保存対象であるファイルを記述した“application description file”を表す。図64の“application description file”では、認証のために使用される“ocap.certificate.1”6319,“ocap.signaturefile.1”6320,“ocap.hashfile”6317が記述されていない。この場合、図64の“application description file”のとおりにファイルを保存すると、認証に使用されるファイルが保存されない。すると、保存したファイルだけでは、プログラムの起動時に実施の形態3から実施の形態5で記述した認証ができなくなる。よって、保存したプログラムを起動しようとするとき、保存前と同じ図63に示すファイルがダウンロードできる状態にあれば、起動するプログラムを構成するファイルは保存先からのものを使用し、認証に使用するファイルはダウンロードしなおしてから認証を行うことにしてもよい。
【0296】
また、保存前と同じ図63に示すファイルがダウンロードできるとは限らないことが想定される。よって、認証に使用されるファイルが“application description file”に記述されていなくても、プログラム起動時の認証に備えて、認証に必要となるファイルは保存しておくことにしてもよい。
【産業上の利用可能性】
【0297】
本発明に係るプログラムデータファイル保存方法および認証プログラム実行方法は、プログラムをダウンロードして実行する例えばデジタルテレビ受信機や携帯電話等のプログラム実行装置に利用可能である。
【図面の簡単な説明】
【0298】
【図1】図1は、本発明に係るケーブルテレビシステムの実施の形態1の構成図である。
【図2】図2は、本発明に係るケーブルテレビシステムにおいてヘッドエンドと端末装置間の通信に使用される周波数帯域の使い方の一例を示す図である。
【図3】図3は、本発明に係るケーブルテレビシステムにおいてヘッドエンドと端末装置間の通信に使用される周波数帯域の使い方の一例を示す図である。
【図4】図4は、本発明に係るケーブルテレビシステムにおいてヘッドエンドと端末装置間の通信に使用される周波数帯域の使い方の一例を示す図である。
【図5】図5は、本発明に係るケーブルテレビシステムにおいて端末装置の構成図である。
【図6】図6は、本発明に係るケーブルテレビシステムにおいて端末装置の外観の一例を示す図である。
【図7】図7は、本発明に係るPOD504のハードウエア構成の構成図である。
【図8】図8は、本発明に係るPOD504が保存するプログラム構成の構成図である。
【図9】図9は、MPEG規格で定義されているパケットの構成図である。
【図10】図10は、MPEG2トランスポートストリームの一例を示す図である。
【図11】図11は、入力部513をフロントパネルで構成した場合の外観の一例を示す図である。
【図12】図12は、本発明に係る端末装置500が保存するプログラム構成の構成図である。
【図13A】図13Aは、本発明に係るディスプレイ509の表示の一例を示す図である。
【図13B】図13Bは、本発明に係るディスプレイ509の表示の一例を示す図である。
【図14】図14は、本発明に係る2次記憶部510が保存する情報の一例を示す図である。
【図15A】図15Aは、本発明に係る1次記憶部511が保存する情報の一例を示す図である。
【図15B】図15Bは、本発明に係る1次記憶部511が保存する情報の一例を示す図である。
【図15C】図15Cは、本発明に係る1次記憶部511が保存する情報の一例を示す図である。
【図16】図16は、本発明に係るMPEG2規格が規定するPATの内容を表す模式図である。
【図17】図17は、本発明に係るMPEG2規格が規定するPMTの内容を表す模式図である。
【図18】図18は、本発明に係るAITの内容を表す模式図である。
【図19】図19は、本発明に係るDSMCC方式で送信されるファイルシステムを表す模式図である。
【図20】図20は、本発明に係るXAITの内容を表す模式図である。
【図21】図21は、本発明に係る2次記憶部510が保存する情報の一例を示す図である。
【図22A】図22Aは、本発明に係るファイルまたはディレクトリのハッシュ値を格納したファイルの例を示す図である。
【図22B】図22Bは、本発明に係るファイルまたはディレクトリのハッシュ値を格納したファイルの例を示す図である。
【図22C】図22Cは、本発明に係るファイルまたはディレクトリのハッシュ値を格納したファイルの例を示す図である。
【図23】図23は、本発明に係る証明書チェーンの構成図である。
【図24】図24は、本発明に係るX.509証明書の構成図である。
【図25】図25は、本発明に係る署名ファイルの構成図である。
【図26】図26は、本発明に係るセキュリティモジュールの構成要素を示した図である。
【図27】図27は、本発明に係るファイルシステムの認証を行う際の動作を示したフローチャートである。
【図28】図28は、本発明に係るプログラム起動直前通知を受け付けた際に、認証を行わないときのフローチャートである。
【図29】図29は、本発明に係るファイルシステムの改竄チェックを行う際の動作を示したフローチャートである。
【図30】図30は、本発明に係る署名ファイルを用いて改竄チェックを行う際の動作を示したフローチャートである。
【図31】図31は、本発明に係るリーフ証明書と中間証明書の連鎖関係を確認する際の動作を示したフローチャートである。
【図32】図32は、本発明に係る中間証明書とルート証明書の連鎖関係を確認する際の動作を示したフローチャートである。
【図33】図33は、本発明に係るルート証明書の署名を確認する際の動作を示したフローチャートである。
【図34】図34は、本発明に係る保存対照であるファイルを特定するために利用されるファイルの一例を示す図である。
【図35】図35は、本発明に係るファイル2130の記述内容を表したファイルリスト情報の一例を示す図である。
【図36】図36は、本発明に係るAMの構成要素を示した図を示す図である。
【図37】図37は、本発明に係る2次記憶部510に以前保存されたファイル2130の記述内容を表したファイルリスト情報の一例を示す図である。
【図38】図38は、本発明に係る差分を抽出して作成されたファイルリスト情報の一例を示す図である。
【図39】図39は、本発明に係るファイルシステム比較手段3601のフローチャートである。
【図40】図40は、本発明に係るファイルシステム管理手段3602のフローチャートである。
【図41】図41は、本発明に係るファイルシステム比較手段3603のフローチャートである。
【図42】図42は、本発明に係るAMとセキュリティマネージャのフローチャートである。
【図43】図43は、本発明に係るXAITの内容を表す模式図である。
【図44】図44は、本発明に係る2次記憶部510が保存する情報の一例である。
【図45A】図45Aは、本発明に係るファイルまたはディレクトリのハッシュ値を格納したファイルの例である。
【図45B】図45Bは、本発明に係るファイルまたはディレクトリのハッシュ値を格納したファイルの例である。
【図45C】図45Cは、本発明に係るファイルまたはディレクトリのハッシュ値を格納したファイルの例である。
【図46】図46は、本発明に係るファイルシステムの改竄チェックを行う際の動作を示したフローチャートである。
【図47】図47は、本発明に係る保存対象であるファイルを特定するために利用されるファイルの一例である。
【図48】図48は、本発明に係るファイルシステムの認証を行う際の動作を示したフローチャートである。
【図49】図49は、本発明に係るプログラム起動直前通知を受け付けた際に、X.509証明書の有効性を確認する際の動作を示したフローチャートである。
【図50】図50は、本発明に係るダウンロードモジュールから受け取るコードファイルの簡単な構成図である。
【図51A】図51Aは、本発明に係る端末装置が所有する証明書が交換される際の様子を示した図である。
【図51B】図51Bは、本発明に係る端末装置が所有する証明書が交換される際の様子を示した図である。
【図51C】図51Cは、本発明に係る端末装置が所有する証明書が交換される際の様子を示した図である。
【図52】図52は、本発明に係る証明書交換を行う際の動作を示したフローチャートである。
【図53】図53は、本発明に係るプログラム起動直前通知を受け付けた際に、ルート証明書を照合する際の動作を示したフローチャートである。
【図54】図54は、本発明に係るCRLの構成図である。
【図55】図55は、本発明に係るCRL中の失効証明書リストの模式図である。
【図56】図56は、本発明に係るCRLが存在するファイルシステムの一例である。
【図57】図57は、本発明に係るCRLの有効性をハッシュ値と署名値から確認する際の動作を示すフローチャートである。
【図58】図58は、本発明に係るCRLの有効性を証明書の連鎖関係及びルート証明書の照合によって確認する際の動作を示すフローチャートである。
【図59】図59は、本発明に係るファイルまたはディレクトリのハッシュ値を格納したファイルの例である。
【図60】図60は、本発明に係るプログラム保存時にCRLが存在する場合の認証の動作を示したフローチャートである。
【図61】図61は、本発明に係るプログラム起動時にCRLが存在する場合の認証の動作を示したフローチャートである。
【図62】図62は、本発明に係る失効証明書データベースの模式図である。
【図63】図63は、本発明に係る保存対象であるファイルを特定するために利用されるファイルが存在するファイルシステムの一例である。
【図64】図64は、本発明に係る保存対象であるファイルを特定するために利用されるファイルの一例である。

【特許請求の範囲】
【請求項1】
第1のトランスポートストリームに含まれる第1のプログラムのデータファイルの保存に関する情報に従い、前記第1のプログラムのデータファイルを認証し放送受信装置に保存する第1のステップと、
第2のトランスポートストリームに含まれる第2のプログラムのデータファイルの保存に関する情報を受信する第2のステップと、
前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルがある場合、
該当する第2のプログラムのデータファイルのハッシュ値を前記第2のプログラムに含まれ、前記該当する第2のプログラムのデータファイルに対応するハッシュファイルに格納されたハッシュ値に一致するかどうかを検証する第3のステップと、
前記第2のプログラムに含まれる証明書ファイルの有効性を検証する第4のステップと、
前記第2のプログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記第2のプログラム含まれる署名ファイルの署名値を復号した値と、前記第2のプログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第5のステップと、
前記第3のステップにてハッシュ値が一致し、第4のステップにて前記証明書ファイルが有効であると判定され、第5のステップにおいてハッシュ値が一致すると判定された場合に前記第2のプログラムを認証し、前記第2のプログラムのデータファイルの保存に関する情報に従い前記第2のプログラムを保存する第6のステップとを有する
ことを特徴とするプログラムデータファイル保存方法。
【請求項2】
前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルとは、前記第1のプログラムの保存時に認証されたデータファイルを更新するデータファイルである
ことを特徴とする請求項1記載のプログラムデータファイル保存方法。
【請求項3】
前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルとは、前記第1のプログラムの保存時に認証されたデータファイルとは異なる新規のデータファイルである
ことを特徴とする請求項1記載のプログラムデータファイル保存方法。
【請求項4】
前記プログラムがディレクトリ構造を有する場合には、
各ディレクトリに含まれる前記データファイルと、対応する前記ハッシュファイルとは同一ディレクトリ内に存在し、
前記第3のステップは前記該当する第2のプログラムのデータファイルが存在するディレクトリ毎に実行される
ことを特徴とする請求項1記載のプログラムデータファイル保存方法。
【請求項5】
前記第3のステップにてハッシュ値が一致しない場合、第4のステップにてルート証明書が有効でない場合、または第5のステップにおいてハッシュ値が一致しない場合には、第6のステップにて前記第2のプログラムを保存しない
ことを特徴とする請求項1記載のプログラムデータファイル保存方法。
【請求項6】
前記第2のプログラムのデータファイルのうち、前記第1のプログラムのデータファイルのいずれかと同一のデータファイルがある場合には、
第6のステップにおいて、該当する第2のプログラムのデータファイルを前記放送受信装置に保存しない
ことを特徴とする請求項1記載のプログラムデータファイル保存方法。
【請求項7】
前記第2のプログラムのデータファイルのうち、前記第1のプログラムのデータファイルのいずれかと同一のデータファイルがある場合には、
第6のステップにおいて、該当する前記第2のプログラムのデータファイルを該当する前記第1のプログラムのデータファイルに上書き保存する
ことを特徴とする請求項1記載のプログラムデータファイル保存方法。
【請求項8】
前記第4のステップは、
前記第2のプログラム含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致するかどうかを検証する第7のステップを有し、
前記第2のプログラムに関連する証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致する場合、前記証明書ファイルが有効であると判定する
ことを特徴とする請求項1記載のプログラムデータファイル保存方法。
【請求項9】
前記第4のステップは、さらに、
前記第2のプログラムに含まれる証明書ファイル中の証明書の有効期限をチェックする第8のステップを有し、
前記第2のプログラムに関連する証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致し、認証日時が前記証明書ファイル中の証明書の有効期間内にある場合、前記証明書ファイルが有効であると判定する
ことを特徴とする請求項8記載のプログラムデータファイル保存方法。
【請求項10】
第1のトランスポートストリームに含まれる第1のプログラムのデータファイルの保存に関する情報に従い、前記第1のプログラムのデータファイルを認証し放送受信装置に保存する第1のステップと、
第2のトランスポートストリームに含まれる第2のプログラムのデータファイルの保存に関する情報を受信する第2のステップと、
前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルがある場合、
該当する第2のプログラムのデータファイルのハッシュ値を前記第2のプログラムに含まれ、前記該当する第2のプログラムのデータファイルに対応するハッシュファイルに格納されたハッシュ値に一致するかどうかを検証する第3のステップと、
前記第2のプログラムに含まれる証明書ファイルの有効性を検証する第4のステップと、
前記第2のプログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記第2のプログラム含まれる署名ファイルの署名値を復号した値と、前記第2のプログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第5のステップと、
前記第3のステップにてハッシュ値が一致し、第4のステップにて前記証明書ファイルが有効であると判定され、第5のステップにおいてハッシュ値が一致すると判定された場合に前記第2のプログラムを認証し、前記第2のプログラムのデータファイルの保存に関する情報に従い前記第2のプログラムを保存する第6のステップと、
前記第2のプログラムを実行する場合、前記保存した前記第2のプログラムに関連する証明書ファイルの有効性を検証する第9のステップと、
前記第9のステップにて、前記保存した第2のプログラムに含まれる証明書ファイルが有効であると判定された場合にのみ前記保存した第2のプログラムを再度認証し、実行する実行ステップとを有する
ことを特徴とする認証プログラム実行方法。
【請求項11】
前記第9のステップは、
前記保存したプログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致するかどうかを検証する第10のステップを有し、
前記保存した第2のプログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致する場合、前記証明書ファイルが有効であると判定する
ことを特徴とする請求項10記載の認証プログラム実行方法。
【請求項12】
前記第9のステップは、
前記保存したプログラムに含まれる証明書ファイル中の証明書の有効期限をチェックする第11のステップを有し、
前記保存した第2のプログラムに含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致し、実行日時が前記証明書ファイル中の証明書の有効期間内にある場合、前記証明書ファイルが有効であると判定する
ことを特徴とする請求項11記載の認証プログラム実行方法。
【請求項13】
前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルとは、前記第1のプログラムの保存時に認証されたデータファイルを更新するデータファイルである
ことを特徴とする請求項10記載の認証プログラム実行方法。
【請求項14】
前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルとは、前記第1のプログラムの保存時に認証されたデータファイルとは異なる新規のデータファイルである
ことを特徴とする請求項10記載の認証プログラム実行方法。
【請求項15】
前記プログラムがディレクトリ構造を有する場合には、
各ディレクトリに含まれる前記データファイルと、対応する前記ハッシュファイルとは同一ディレクトリ内に存在し、
前記第3のステップは前記該当する第2のプログラムのデータファイルが存在するディレクトリ毎に実行される
ことを特徴とする請求項10記載の認証プログラム実行方法。
【請求項16】
前記第3のステップにてハッシュ値が一致しない場合、第4のステップにてルート証明書が有効でない場合、または第5のステップにおいてハッシュ値が一致しない場合には、第6のステップにて前記第2のプログラムを保存しない
ことを特徴とする請求項10記載の認証プログラム実行方法。
【請求項17】
前記第2のプログラムのデータファイルのうち、前記第1のプログラムのデータファイルのいずれかと同一のデータファイルがある場合には、
第6のステップにおいて、該当する第2のプログラムのデータファイルを前記放送受信装置に保存しない
ことを特徴とする請求項10記載の認証プログラム実行方法。
【請求項18】
前記第2のプログラムのデータファイルのうち、前記第1のプログラムのデータファイルのいずれかと同一のデータファイルがある場合には、
第6のステップにおいて、該当する前記第2のプログラムのデータファイルを該当する前記第1のプログラムのデータファイルに上書き保存する
ことを特徴とする請求項10記載の認証プログラム実行方法。
【請求項19】
前記第4のステップは、
前記第2のプログラム含まれる証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致するかどうかを検証する第7のステップを有し、
前記第2のプログラムに関連する証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致する場合、前記証明書ファイルが有効であると判定する
ことを特徴とする請求項10記載の認証プログラム実行方法。
【請求項20】
前記第4のステップは、さらに、
前記第2のプログラムに含まれる証明書ファイル中の証明書の有効期限をチェックする第8のステップを有し、
前記第2のプログラムに関連する証明書ファイル中のルート証明書が前記放送受信装置内のルート証明書に一致し、認証日時が前記証明書ファイル中の証明書の有効期間内にある場合、前記証明書ファイルが有効であると判定する
ことを特徴とする請求項19記載の認証プログラム実行方法。
【請求項21】
第1のトランスポートストリームに含まれる第1のプログラムのデータファイルの保存に関する情報に従い、前記第1のプログラムのデータファイルを認証し、保存する第1保存手段と、
第2のトランスポートストリームに含まれる第2のプログラムのデータファイルの保存に関する情報を受信する保存情報受信手段と、
前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルがある場合、
該当する第2のプログラムのデータファイルのハッシュ値を前記第2のプログラムに含まれ、前記該当する第2のプログラムのデータファイルに対応するハッシュファイルに格納されたハッシュ値に一致するかどうかを検証する第1検証手段と、
前記第2のプログラムに含まれる証明書ファイルの有効性を検証する第2検証手段と、
前記第2のプログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記第2のプログラム含まれる署名ファイルの署名値を復号した値と、前記第2のプログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第3検証手段と、
前記第1検証手段にてハッシュ値が一致し、第2検証手段にて前記証明書ファイルが有効であると判定され、第3検証手段においてハッシュ値が一致すると判定された場合に前記第2のプログラムを認証し、前記第2のプログラムのデータファイルの保存に関する情報に従い前記第2のプログラムを保存する第2保存手段とを備える
ことを特徴とするプログラム保存装置。
【請求項22】
第1のトランスポートストリームに含まれる第1のプログラムのデータファイルの保存に関する情報に従い、前記第1のプログラムのデータファイルを認証し、保存する第1保存手段と、
第2のトランスポートストリームに含まれる第2のプログラムのデータファイルの保存に関する情報を受信する保存情報受信手段と、
前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルがある場合、
該当する第2のプログラムのデータファイルのハッシュ値を前記第2のプログラムに含まれ、前記該当する第2のプログラムのデータファイルに対応するハッシュファイルに格納されたハッシュ値に一致するかどうかを検証する第1検証手段と、
前記第2のプログラムに含まれる証明書ファイルの有効性を検証する第2検証手段と、
前記第2のプログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記第2のプログラム含まれる署名ファイルの署名値を復号した値と、前記第2のプログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第3検証手段と、
前記第1検証手段にてハッシュ値が一致し、第2検証手段にて前記証明書ファイルが有効であると判定され、第3検証手段においてハッシュ値が一致すると判定された場合に前記第2のプログラムを認証し、前記第2のプログラムのデータファイルの保存に関する情報に従い前記第2のプログラムを保存する第2保存手段と、
前記第2のプログラムを実行する場合、前記保存した前記第2のプログラムに関連する証明書ファイルの有効性を検証する第4検証手段と、
前記第4検証手段にて、前記保存した第2のプログラムに含まれる証明書ファイルが有効であると判定された場合にのみ前記保存した第2のプログラムを再度認証し、実行する実行手段とを備える
ことを特徴とする認証プログラム実行装置。
【請求項23】
第1のトランスポートストリームに含まれる第1のプログラムのデータファイルの保存に関する情報に従い、前記第1のプログラムのデータファイルを認証し放送受信装置に保存する第1のステップと、
第2のトランスポートストリームに含まれる第2のプログラムのデータファイルの保存に関する情報を受信する第2のステップと、
前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルがある場合、
該当する第2のプログラムのデータファイルのハッシュ値を前記第2のプログラムに含まれ、前記該当する第2のプログラムのデータファイルに対応するハッシュファイルに格納されたハッシュ値に一致するかどうかを検証する第3のステップと、
前記第2のプログラムに含まれる証明書ファイルの有効性を検証する第4のステップと、
前記第2のプログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記第2のプログラム含まれる署名ファイルの署名値を復号した値と、前記第2のプログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第5のステップと、
前記第3のステップにてハッシュ値が一致し、第4のステップにて前記証明書ファイルが有効であると判定され、第5のステップにおいてハッシュ値が一致すると判定された場合に前記第2のプログラムを認証し、前記第2のプログラムのデータファイルの保存に関する情報に従い前記第2のプログラムを保存する第6のステップとをコンピュータに実行させる
ことを特徴とするプログラム。
【請求項24】
第1のトランスポートストリームに含まれる第1のプログラムのデータファイルの保存に関する情報に従い、前記第1のプログラムのデータファイルを認証し放送受信装置に保存する第1のステップと、
第2のトランスポートストリームに含まれる第2のプログラムのデータファイルの保存に関する情報を受信する第2のステップと、
前記第2のプログラムのデータファイルのうち、前記第1のプログラムの保存時に認証されたデータファイルとは異なるデータファイルがある場合、
該当する第2のプログラムのデータファイルのハッシュ値を前記第2のプログラムに含まれ、前記該当する第2のプログラムのデータファイルに対応するハッシュファイルに格納されたハッシュ値に一致するかどうかを検証する第3のステップと、
前記第2のプログラムに含まれる証明書ファイルの有効性を検証する第4のステップと、
前記第2のプログラムの証明書ファイルに含まれるリーフ証明書の公開鍵を用いて前記第2のプログラム含まれる署名ファイルの署名値を復号した値と、前記第2のプログラム中最上位ディレクトリに位置するハッシュファイルのハッシュ値が一致するかどうかを検証する第5のステップと、
前記第3のステップにてハッシュ値が一致し、第4のステップにて前記証明書ファイルが有効であると判定され、第5のステップにおいてハッシュ値が一致すると判定された場合に前記第2のプログラムを認証し、前記第2のプログラムのデータファイルの保存に関する情報に従い前記第2のプログラムを保存する第6のステップと、
前記第2のプログラムを実行する場合、前記保存した前記第2のプログラムに関連する証明書ファイルの有効性を検証する第9のステップと、
前記第9のステップにて、前記保存した第2のプログラムに含まれる証明書ファイルが有効であると判定された場合にのみ前記保存した第2のプログラムを再度認証し、実行する実行ステップとをコンピュータに実行させる
ことを特徴とするプログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13A】
image rotate

【図13B】
image rotate

【図14】
image rotate

【図15A】
image rotate

【図15B】
image rotate

【図15C】
image rotate

【図16】
image rotate

【図17】
image rotate

【図18】
image rotate

【図19】
image rotate

【図20】
image rotate

【図21】
image rotate

【図22A】
image rotate

【図22B】
image rotate

【図22C】
image rotate

【図23】
image rotate

【図24】
image rotate

【図25】
image rotate

【図26】
image rotate

【図27】
image rotate

【図28】
image rotate

【図29】
image rotate

【図30】
image rotate

【図31】
image rotate

【図32】
image rotate

【図33】
image rotate

【図34】
image rotate

【図35】
image rotate

【図36】
image rotate

【図37】
image rotate

【図38】
image rotate

【図39】
image rotate

【図40】
image rotate

【図41】
image rotate

【図42】
image rotate

【図43】
image rotate

【図44】
image rotate

【図45A】
image rotate

【図45B】
image rotate

【図45C】
image rotate

【図46】
image rotate

【図47】
image rotate

【図48】
image rotate

【図49】
image rotate

【図50】
image rotate

【図51A】
image rotate

【図51B】
image rotate

【図51C】
image rotate

【図52】
image rotate

【図53】
image rotate

【図54】
image rotate

【図55】
image rotate

【図56】
image rotate

【図57】
image rotate

【図58】
image rotate

【図59】
image rotate

【図60】
image rotate

【図61】
image rotate

【図62】
image rotate

【図63】
image rotate

【図64】
image rotate


【公表番号】特表2007−515092(P2007−515092A)
【公表日】平成19年6月7日(2007.6.7)
【国際特許分類】
【出願番号】特願2006−520486(P2006−520486)
【出願日】平成16年12月15日(2004.12.15)
【国際出願番号】PCT/JP2004/019125
【国際公開番号】WO2005/060255
【国際公開日】平成17年6月30日(2005.6.30)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.Linux
【出願人】(000005821)松下電器産業株式会社 (73,050)
【Fターム(参考)】