JP2007501556A

JP2007501556A - デジタル放送システムにおけるコピープロテクトアプリケーション

Info

Publication number: JP2007501556A
Application number: JP2006522437A
Authority: JP
Inventors: ジーフォスター，ジョナサン; ベンイェス，イモ
Original assignee: Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2003-08-02
Filing date: 2004-07-28
Publication date: 2007-01-25
Also published as: CN1833224A; WO2005013126A1; KR20060054419A; EP1654638A1; US20060191015A1; GB0318197D0

Abstract

DVB-MHPのようなデジタル放送システムは、端末（60）に暗号化形式でアプリケーション（320）を送信する。暗号化方法やコストや支払の詳細のようなアプリケーションについての詳細は、端末に送信される。端末は、許可エンティティ（55）からアプリケーション（320）にアクセスする許可を取得するために、インタラクション・チャンネル（85）を使用する。許可された端末は、暗号化アプリケーション（320）を解読するために使用され得る鍵（215）を受信する。端末を許可する機能は、端末（60）に存在してもよく、端末により受信されるランチャー・アプリケーション（図５の310）の一部を形成してもよい。

Description

本発明は、デジタル放送システムと、そのようなシステムでの端末へのアプリケーションの配信とに関する。本発明は、特にDigital Video Broadcasting Multimedia Home Platform（DVB-MHP）及び同様のシステムに適用可能である。

Digital Video Broadcasting（DVB）システムは、もともとオーディオ及びビデオ資料を配信するために開発された。近年、端末によりダウンロード及び実行可能なアプリケーションを配信することに更なる関心が生じてきている。Digital Video Broadcasting Multimedia Home Platform（DVB-MHP）は、マルチメディア・セットトップボックス用の標準を一致させる取り組みの結果である。それは、インタラクティブ・デジタル・テレビ用のオープンで公開された標準である。DVB-MHP又は簡単にはMHPは、インタラクティブ・デジタル・アプリケーションと、これらのアプリケーションを実行する端末との間の一般的なインタフェースを規定する。ETSI TS 101 812 V1.3.1のようなMHP標準は、www.etsi.orgで見ることができる。MHP標準の1.0.3版は、‘Xlets’と呼ばれる自由にダウンロード可能なアプリケーションをサポートしている。ETSI TS 102 819で提出されたDigital Video Broadcasting Globally Executable MHP（DVB-GEM）もまた、ダウンロード可能なアプリケーションをサポートしている。

いくつかの放送局は、サービスに加入している人に対してのみ放送チャンネル又はアプリケーションのようなコンテンツへのアクセスを制限するために、限定受信（CA：conditional access）システムを使用して全放送ストリームを暗号化するように選択している。これは、コンテンツの侵害行為に対して高度のプロテクトを提供することが証明されているが、ユーザのセットトップボックスで専用のスクランブル解除ハードウェアを必要とする。視聴者は、CAシステムを有する特別のセットトップボックスを必要とし、又はDVB Common Interface（DVB-CI）に準拠するスロットを備えたセットトップボックスとCAシステムを含むCIモジュールとを必要とする。視聴者はまた、それを特定するスマートカードを必要とし、放送局は、許可されたスマートカードの中央データベースを保持する必要がある。多数の放送局は、CAシステムについて独自にあつらえた暗号化アルゴリズムを使用する。現実的には、月額受信料を請求する放送局のみが、CAシステムに必要なインフラを設定することができる。前記のことを考慮して、多数の放送局は、このように全トランスポートストリームを暗号化しないことを選択している。

ユーザ端末にゲームのような利用回数制料金を供給することに関心が存在する。その理由は、放送局に更なる収益をもたらし得るからである。しかし、現在のMHP標準は、暗号化アプリケーションのサポートを含んでいない。アプリケーションを暗号化する機能がなく、CAシステムがなければ、ユーザ端末に配信される如何なるアプリケーションも侵害行為を受けやすくなる。実際に、何らかのアプリケーション用のコードを含み、放送システムの一部として放送されたファイルシステムの全コンテンツを‘横取り’して、これをハードディスクに保存することができる装置を入手することが既に可能になっている。

多数のMHPアプリケーションは、リバース・エンジニアリングされるのを更に困難にするように、あいまいになっている。これは、記述ラベルが小さい記述ラベルに除去又は名称変更されるようにコードが処理されることを意味する。このことは、ハッカーがアプリケーションの動作を変更することを困難にするが、アプリケーションが不正に格納又は実行されることを妨げない。

本発明は、暗号化アプリケーションを端末に配信する方法を提供することを目的とする。

従って、本発明の第１の態様は、デジタル放送システムにおいて端末で暗号化アプリケーションを受信する方法を提供し、端末は、外部関係者に信号を運ぶことができるインタラクション・チャンネルへのアクセスを有し、その方法は、
暗号化アプリケーションについての詳細を受信するステップと、
インタラクション・チャンネルで許可エンティティに許可要求を送信することにより、端末がアプリケーションにアクセスすることを許可するステップと、
許可されたことに応じて、インタラクション・チャンネルで鍵を受信するステップと、
暗号化アプリケーションを受信するステップと、
受信した鍵を使用して暗号化アプリケーションを解読するステップと
を有する。

これから生じる利点のうちいくつかは、ユーザがサービスに加入する必要がないことが挙げられる。すなわち、その端末で加入カード、限定受信（CA）システム又はCAモジュールの必要性がない。ユーザは、現行の加入契約なしに、所望のどのようなアプリケーションにも単に支払うことができ、複数のアプリケーションプロバイダは、ユーザが端末に複数のあつらえたCAモジュールを必要とするという問題なく、このようにアプリケーションを提供することができる。トランザクションを処理する単一の許可エンティティが存在する必要はないため、アプリケーションプロバイダの間でユーザデータが共有される必要がない。様々な暗号化／解読アルゴリズム、鍵の長さ及び支払システムが容易に適応可能である。

端末を許可するように構成するステップ及び／又はアプリケーションを解読するステップは、端末により受信されたランチャー・アプリケーションによって実行され得る。ランチャー・アプリケーションは、暗号化されていない形式で放送されることが好ましい。ランチャー・アプリケーションが使用される場合には、暗号化メインアプリケーションは、ランチャー・アプリケーションへの同一又は異なる配信チャンネルを介して配信されてもよい。

ランチャー・アプリケーションの使用に対する好ましい選択肢は、ランチャー・アプリケーションの機能を端末自体に組み込むことである。その機能は、ソフトウェア、ハードウェア又はそれらの組み合わせで実装され得る。従って、本発明の更なる態様は、デジタル放送システムにおける端末用の制御装置と、端末の動作を制御するソフトウェアと、制御装置又はソフトウェアを組み込んだ端末とを提供する。ソフトウェアは、製造時に端末にインストールされてもよく、また、後日にアップグレードとして既存の端末にインストールされてもよい。ソフトウェアは、電子メモリ装置、ハードディスク、光ディスク又は他の機械読取可能記憶媒体に格納され得る。ソフトウェアは機械読取可能担体で配信されてもよく、また、ネットワークを介して端末に直接ダウンロードされてもよい。

本発明の他の態様は、デジタル放送システムにおいて端末（60）にアプリケーションを送信する方法を提供し、端末は、外部関係者（55）に信号を運ぶことができるインタラクション・チャンネル（85）へのアクセスを有し、その方法は、
インタラクション・チャンネル（85）で許可エンティティ（55）に許可要求（314）を送信し、許可されたことに応じて、インタラクション・チャンネル（85）で鍵（215）を受信し、鍵（215）を使用してアプリケーションを解読することにより、端末（60）が暗号化アプリケーション（320）にアクセスすることを許可するように構成されたランチャー・アプリケーション（320）を有する暗号化アプリケーションについての詳細を送信するステップと、
暗号化アプリケーション（320）を送信するステップと
を有する。

本発明の更なる態様は、限定受信（CA）システムが使用されていないデジタル放送システムにおいて端末に暗号化アプリケーションを送信する方法を提供し、その方法は、
暗号化アプリケーションについての暗号化されていない詳細を送信し、その詳細は、アプリケーションを暗号化するために使用される暗号化方法と、アプリケーションのコストと、支払の詳細とのうち１つ以上を有し、
暗号化アプリケーションを送信することを有する。

本発明は、Multimedia Home Platform（MHP）の現バージョンへの拡張として特に適用可能であるが、デジタルビデオ放送システムへの広範囲の適用を有する。それには次のものが含まれる。
・DVB-GEM（ETSI TS 102 819）=Globally Executable MHP、これはDVB-SIに依存しないMHPのサブセットである。
・OCAP=OpenCable Application Platform、GEMに基づく新しい米国ケーブル標準
・ATSC-DASE=Advanced Television Systems Committee（ATSC） Digital TV Applications Software Environment（DASE）、GEMに基づいて現在書き換えられている米国地上波標準
・ARIB-AE=ARIB（日本のTV標準機関）、GEMに基づく標準B-23“Application Execution Engine Platform for Digital Broadcasting”（ARIB-AE）

本発明の実施例について、添付図面を参照して、一例のみとして説明する。

図１は、端末にアプリケーションを配信するデジタルビデオ放送システムを示している。コンテンツは放送局30により生成され、放送チャンネル35を介してユーザ施設100に送信するために適切なフォーマットに変換される。１つのこのような施設100が図示されている。一般的に、放送チャンネル35は、衛星を介して配信されるが、地上波伝送ネットワーク、ケーブル配信ネットワーク又はデータネットワーク（インターネット等）により配信されてもよく、配信方法は本発明に重要ではない。ユーザ施設の端末（STB）60は、放送ストリームを受信し、この実施例では、その放送ストリームはアンテナ18を介したものである。放送チャンネル35を介して配信される放送ストリームは、オーディオ及びデータコンテンツと、様々なサービス及びアプリケーションをサポートするデータとを有する。DVB-MHP仕様では、アプリケーション用のデータは、Digital Storage Media-Command and Control（DSM-CC） Object Carouselの一部として放送される。これは、様々なアプリケーション用のデータファイルを含む繰返し放送ファイルシステムである。DSM-CCを含むDVB-MHPシステム用の放送チャンネルのフォーマットは、ISO/ISC13818-6に設定されており、更なる情報については、当業者に対してそのISO/ISC13818-6に示されている。

アプリケーションは、放送局30により生成されてもよく、また、DSM-CCへの挿入用に放送局30に所要のファイルを供給する独立アプリケーションプロバイダ50により生成されてもよい。アプリケーションの例は、電子番組ガイド（EPG）、ゲーム、クイズ、教育案内及び電子商取引アプリケーション（ホームバンキング等）を含む。

セットトップボックス60はまた、セットトップボックス60が外部関係者にデータを送信し、外部関係者からデータを受信することを可能にするためのインタラクション・チャンネル85をサポートするモデムを備えている。一般的に、インタラクション・チャンネル85は、POTSのような従来の電話ネットワークを使用する。インタラクション・チャンネル85は、POTSでのアプリケーションプロバイダ50への直接のダイヤルアップ接続、データネットワークを通じて運ばれるアプリケーションプロバイダ50とゲートウェイとの間の接続を備えたデータネットワーク（インターネット等）のゲートウェイへの接続、ケーブル・バックチャンネルとアプリケーションプロバイダへのデータネットワーク（インターネット）を通じた接続との組み合わせ、ADSL又は他のブロードバンドインターネット接続、衛星アップリンク又はISDN回線の形式になってもよい。

セットトップボックス60はまた、ユーザ入力を受け取るリモコン20又はキーボードとのユーザインタフェースと、テレビディスプレイ12に供給されるビデオ信号10に重ねられ得るメッセージを表示するグラフィック出力とを有する。

MHP端末はJava^TM Virtual Machine（JVM）を中心に構築され、アプリケーションはJava（登録商標）で記述される。Java（登録商標）の使用は、各種の端末で仮想機械が、その端末に存在する特定のハードウェア及びソフトウェアに互換のある形式にJava（登録商標）バイトコードを変換することで、アプリケーションが共通のフォーマットで記述され得るという利点を有する。

図２は、一般的なMHP端末60内の機能ブロックを示している。既知のように、端末60は、受信放送信号35を処理するフロントエンドを有する。これは、所要のチャンネルを選択及び復調するチューナ及び復調器61と、信号を解読する任意選択の限定受信ユニット62とを有する。結果のデジタルデータストリームは、オーディオ及びビデオデータを表すデータストリーム（一般的にMPEG-2フォーマット）と、繰返し放送のDSM-CC Object Carousel64の形式のアプリケーション用のデータとに逆多重化される63。オーディオ及びビデオデータは、ユーザへの提示用に、適切な出力信号10、14を得るように更に処理され得る65。放送ストリームからダウンロードされると、アプリケーション（又は複数のアプリケーション）は、端末のメモリ69に存在し、マイクロプロセッサ68により実行される。アプリケーションは、ユーザ入力22を受け取り、オーディオ及びビデオ出力を生成し、アプリケーション・プログラミング・インタフェース（API）を介してインタラクション・チャンネル85にアクセスしてもよい。端末を動作する制御ソフトウェアもまた、メモリ装置に存在する。図２は、放送配信チャンネルを介して信号を受信することを目的とした端末を示している点に留意すべきである。端末の他の実施例では、非放送配信チャンネルとインタフェースすることを目的としており、チューナ／復調器61は、配信チャンネルに適したネットワークインタフェースと交換される。これは、インターネットプロトコル（IP）ベースの配信チャンネルでもよい。

本発明によれば、アプリケーションは暗号化形式で送信される。基本的に、端末60が暗号化アプリケーションを処理するように変更され得る２つの方法が存在する。

第１の方法は、メインプリケーションの前に放送ストリーム35からダウンロードされた暗号化されていないランチャー・アプリケーションを使用する。ランチャー・アプリケーションは、アプリケーションの支払を処理し、解読鍵を取得し、暗号化アプリケーションを開始すること等によって、端末がアプリケーションを使用することを許可する機能を端末に実装させるコードを有する。ランチャー・アプリケーションの使用は、APIを介して機能を公開するという欠点を有する。

第２の方法は、ランチャー・アプリケーションの機能を端末に組み込み、放送信号はアプリケーションについての情報（アプリケーションのコスト、使用された暗号化アルゴリズム及び解読鍵を取得するコンタクトの詳細等）を含むように変更される。

図３及び４は、放送ストリームから暗号化アプリケーションをダウンロードする処理の第１の実施例を示している。この実施例では、暗号化アプリケーションを処理する機能は、端末に内蔵されている。すなわち、ランチャー・アプリケーションは必要ない。図３は、処理のステップのフローチャートを示しており、図４は、端末60及びアプリケーションプロバイダ50の機能ブロックのいくつかと、暗号化鍵の転送とを示している。

まず、ステップ500において、端末STBは、ダウンロードに利用可能なアプリケーションの詳細を受信する。この情報は、アプリケーション情報テーブル（AIT：Application Information Table）で運ばれる。テーブルは、（バイナリ形式で）MPEGセクションで送信される。テーブルの全てのフィールドは、MHP仕様で指定されている。AITは、次のような詳細を有するように変更されることが好ましい。
・アプリケーションを暗号化するために使用された暗号化方法（鍵の長さを含む）
・使用可能な支払方法、及びアプリケーションプロバイダの電話番号又はサーバアドレスのように、許可用にアプリケーションプロバイダにコンタクトする方法の詳細
・アプリケーションの価格のようなユーザへの表示用の情報
次の表は、どのようにAITが変更され得るかの一例である。

暗号化アプリケーションと、アプリケーションを暗号化するために必要な情報とを伝達するための異なる方法が存在する。

まず、このAITの全アプリケーションが暗号化アプリケーションであるという情報をapplication_typeフィールドが有することを定義することができる。現在、このフィールドは、値0x0001（DVB-Jアプリケーション）又は0x0002（DVB-HTML）を有し得る。これは15ビットのフィールドであるため、最大値は0x7FFFになり得る。暗号化アプリケーション（AITの全アプリケーションが暗号化されている）を特定するために、0x4000のマスクを使用するという可能性がある。暗号化DVB-Jアプリケーション（通常のMHPアプリケーション）は、application_type 0x4001（0x0001|0x4000）を有する。

その他に、暗号化アプリケーションを特定するために、アプリケーションループで予備の4ビット（フィールド2）のビットを使用する可能性がある。同様に、暗号化情報を伝達する２つの方法が存在する。‘Descriptor A’として上記にラベルのある位置にこの記述子を定義すること等により、それはAITに追加され得る。AITが非常に小さくなければならないため（1K未満）、これは好ましくない。このことは、各AITがその自分のPIDを有する１つより多くのAITが送信される必要があることを意味する。記述子は次のようになってもよい。

ダイヤルアップ接続では、テキストのロケータはモデムがダイヤルするべき電話番号であり、IP接続では、テキストのロケータはURLである。

第２の好ましい手法は以下のようになる。（transport_protocol_discriptorを介して）AITで指定されたDSM-CCオブジェクト・カルーセルでは、暗号化アプリケーション毎のXMLファイル（例えば“organization_id”.“application_id”-encryption.htmlという名前を有する）、又はそのオブジェクト・カルーセルの全暗号化アプリケーションについての情報を有する１つのXMLファイルが存在する。このようなXMLファイルは次のようになってもよい。

端末ClassLoaderは２つの異なるアプリケーション・クラスパス（すなわちクラスを検索する経路）を有する。それは、通常のクラスパス（暗号化されていないクラスを検出した場合）と、encrypted_classpath（暗号化クラスパス）（暗号化されたクラスを検出した場合）とを有する。従って、AITを解析するときに、端末はアプリケーションが暗号化されているか否かを検査しなければならない。暗号化されている場合には、記述子の１つで指定されたクラスパスは、encrypted_classpathに追加され、そうでない場合には、通常のクラスパスに追加される。

AITはまた、アプリケーションが端末により格納又はコピー可能であるか否かを示すフラグを有し得る。如何なる端末もこれらの詳細を正確に解釈できるように、これらの拡張は標準化されることが好ましい。

次に、ステップ502において、ユーザは、利用可能なアプリケーションのうち１つを選択し、ダウンロード処理を開始する。次に、端末は、端末がアプリケーションにアクセスすることを許可する処理を開始する。端末により行われる動作は、AIT又はXMLファイルで運ばれる拡張子により決定される。ステップ506において、端末60は、（AITで運ばれる）アプリケーションのコストを指示し、ユーザがアプリケーションの支払に合意するか否かをユーザに尋ねるメッセージを表示する。ユーザが支払うことを希望しない場合、エラーメッセージが表示されてもよく、更に何も生じない。ユーザがアプリケーションの支払に合意した場合、端末はステップ510に進み、アプリケーションプロバイダ50の許可／支払エンティティ55にダイヤルして許可要求314を送信するために、インタラクション・チャンネル85を使用する。この例では、アプリケーションに支払う機構は、端末がプレミアムレートの電話番号にダイヤルすることによる。

図４は、端末60とアプリケーションプロバイダ50との間で行われる暗号化鍵の交換を示している。端末は一対の暗号化鍵（公開鍵210と秘密鍵220）を有する。この一対の鍵210、220は端末に固有であり、端末の製造者により承認されている。同様に、その端末の製造者は信頼を受けた証明書機関により承認されている。端末がMHP標準に準拠しているとして認定されたときに、証明が与えられてもよい。秘密鍵220は端末を離れず、アプリケーションに対して直接に見ることができない。秘密鍵220は、Trusted Computing Platform Alliance（TCPA）／Palladiumのような不正使用できないハードウェア222に格納されてもよい。

端末60が最初にアプリケーションプロバイダ50にコンタクトするときに、それは公開鍵210を送信する。公開鍵210を受信すると、許可エンティティ55の許可ユニット56は、この鍵が有効であるか否かを検査する。公開鍵210は、端末60を特定するために使用され得る。前述の署名及び証明書のチェーンは、鍵210が承認済のMHP端末から生じたものであることを確保するために使用される。無効の鍵の‘ブラックリスト’もまた調べられ得る。端末がハッキングされていることがわかったときや、その鍵を備えた端末が以前に無効の支払の詳細を供給したときのように、端末は様々な理由でブラックリストに挙げられてもよい。鍵を送信した端末が許可されていない又は準拠していないことを、これらの検査のうちいずれかが示すと、ステップ514においてエラーメッセージが返信され得る。

鍵が有効である場合、アプリケーションプロバイダ50は、プレミアムレートの電話番号への電話の持続時間が要求のアプリケーション（すなわち、ユーザが支払ったもの）の価格と等しくなるまで待機し、鍵生成器58にアプリケーション鍵215を生成するように指示する。この鍵215は、端末が要求したアプリケーションを解読する。アプリケーション鍵215は、暗号化アプリケーション鍵216を得るSTBの公開鍵210を使用して暗号化されることが好ましい。暗号化アプリケーション鍵216は、インタラクション・チャンネル85で端末60に返信される。

ステップ518において、端末は暗号化アプリケーション鍵216を受信する。端末は、もう一度アプリケーション鍵215を得るために、その秘密鍵220を使用して鍵を解読する225。次に、端末はDSM-CCから暗号化アプリケーション320をダウンロードし始める。ステップ520において、アプリケーションは鍵215を使用して解読され、解読済アプリケーション330は通常の方法で実行され得る。

Data Encryption Standard（DES）やTriple Data Encryption Standard（3DES）やAdvanced Encryption Standard（AES）やBlowFishのように、如何なる標準的な解読アルゴリズムが使用されてもよい。端末は複数の暗号化標準をサポートしてもよく、１つのみをサポートしてもよい。

アプリケーション鍵215は、アプリケーションの種類に応じて、将来の使用のために端末60に格納されてもよく、アプリケーションが閉じられたときに破棄されてもよい。利用回数制料金のアプリケーションはそれぞれの場合に新しい鍵を必要とするが、一回毎料金のアプリケーションはそれぞれの場合に同じ鍵を使用してもよい。端末は全体の解読済アプリケーションを格納することができるほど十分な永続的な記憶装置を有さなくてもよい。暗号化アプリケーションが継続して放送されている場合には、端末は単に鍵を格納すればよい。次にユーザがアプリケーションを作動しようとすると、アプリケーションは再びダウンロードされて、再び解読される。アプリケーションを解読するために必要な鍵は端末に既に格納されているため、ユーザは再び支払う必要はない。更に、アプリケーションがローカルの記憶装置にキャッシュ／格納されている場合でも、ハッカーがローカルの記憶装置からアプリケーションを抽出することを妨げるために、アプリケーションは暗号化されるべきである。その場合、ハッカーがアプリケーションをコピーしたとしても、それは依然として暗号化されている。アプリケーション鍵が暗号化形式で（例えばアプリケーション鍵がインタラクション・チャンネルを通じて送信されたのと同じように端末の公開鍵で暗号化される）格納されている場合、アプリケーションが侵害者により解読され得る容易な方法は存在しないはずである。

この例では、許可は、プレミアムレートの電話番号にダイヤルすることで実現されている。しかし、許可が実現され得る他の様々な方法が存在する。許可を得るいくつかの可能な方法には次のものがある。
・端末はクレジットカードの詳細についてユーザに促す。クレジットカードの詳細を受信すると、端末はアプリケーションサーバ50の支払許可エンティティ55にコンタクトし、クレジットカードの詳細と公開鍵210とを渡す。許可ユニット56は、クレジットカードの詳細が有効であることを検査するために、外部組織にコンタクトすることを必要としてもよい。支払が受け入れられると、前述のように、暗号化アプリケーション鍵216は、インタラクション・チャンネル85でアプリケーションプロバイダ50から端末60に返信される。アプリケーションプロバイダ50が端末の所有者を認識している場合、クレジットカードの詳細は、アプリケーションプロバイダにより保持されている詳細と比較され得る。
・端末は加入又はクラブ会員番号について、場合によってはパスワード又はPINと共にユーザに促す。端末はアプリケーションプロバイダ50にコンタクトし、この情報と公開鍵210とを提供する。ユーザが許可されると、暗号化アプリケーション鍵216はアプリケーションプロバイダ50から端末60に送信される。
・端末は、端末60のカードリーダに挿入されたスマートカード（例えばGerman GeldKarte）から支払を行い、支払を示すメッセージと共にアプリケーションプロバイダ50に公開鍵210を送信する。暗号化アプリケーション鍵216はアプリケーションプロバイダ50から端末60に送信される。

好ましくは何らかの方法でアプリケーションプロバイダ50に支払った後で、端末が鍵216を取得するためにアプリケーションプロバイダ50にコンタクトする場合に、その他の手段が使用されてもよいことがわかる。第三者が鍵を傍受してそれを配信する可能性を低減するために、アプリケーション鍵215はそのままではなく、暗号化形式で送信されることが好ましい。STBの公開鍵を使用してアプリケーション鍵215を暗号化することは、端末がアプリケーションプロバイダ50に提示する証明書を所有していることを確保する。アプリケーション鍵215を安全に送信する代替の方法は、Secure Socket Layer（SSL）プロトコルのような認証プロトコルを使用することによるものがある。端末の証明書は、クライアント証明書として使用され得る。

図５は、ランチャー・アプリケーション310が暗号化メインアプリケーション320の前に送信される本発明の代替実施例を示している。この実施例では、暗号化アプリケーションについての情報は、AIT又はXMLファイルではなく、ランチャー・アプリケーションで運ばれ、ランチャー・アプリケーションは、暗号化アプリケーションに通知するカスタムUI（ユーザインタフェース）を生成し得る。

ランチャー・アプリケーションが使用される場合、解読をサポートするためにAPIが必要になる。ランチャー・アプリケーションが暗号化MHPアプリケーションを単に開始した場合、それは、特別のクラスの関数（静的関数等）を使用し得る。
例えば、
public Boolean startEncryptedApp(int org_id, int app_id, byte[] key);
端末は、AITからアプリケーション情報を受信するが、ランチャー・アプリケーションはアプリケーション鍵を取得する役目をする。そのアプリケーション鍵はビットの配列を介して渡される。

ランチャー・アプリケーションがメインアプリケーションであり、単に暗号化モジュールを（Java reflection APIを介して）ロードしようとする場合、他の工場定義のメソッドが必要になる。
public static ClassLoader createDecryptionClassLoader(EncryptionInfo info, String[] classpath, byte[] key)
但し、クラス‘EncryptionInfo’は使用される暗号化システムについての情報を有し、‘classpath’はクラスパスの配列であり、‘key’は鍵である。

更なる代替のメソッドは、
public static ClassLoader createDecryptionClassLoader(DecryptionEngine decryptor, String[] classpath)
これはまた、新しいClassLoaderを生成するが、実際の解読を行うクラスは引数として渡される。DecryptionEngineはインタフェースである。新しいClassLoaderで読み取ったものの全てが最初にDecryptionEngineに渡され、ClassLoaderによりリードバック（解読）される。このように、（例えばボックスの解読アルゴリズムがクラックされているとわかっている場合）アプリケーションは自分の解読の実装を送信することができる。鍵はアプリケーションを離れることはない（暗号化鍵（前述を参照）の使用は可能でなくてもよい）。

解読ルーチンはボックスに存在するが、ダウンロードされることも可能である。ランチャー・アプリケーションは、新しいClassLoaderを生成するように端末に指示する。

前記の実施例では、許可エンティティ55は、アプリケーションプロバイダ50の一部として図示されている。これは必ずしも必要ではない。許可エンティティ55は、アプリケーションプロバイダから物理的に離れて、アプリケーションプロバイダ50の代わりに許可機能を実行してもよい。

アプリケーション（及び存在する場合にはランチャー・アプリケーション）は、リバース・エンジニアリングされることを困難にするようにあいまいになっている。これは、記述ラベルが小さい記述ラベルに除去又は名称変更されるようにコードが処理されることを意味する。従って、ハッカーがアプリケーションをうまく解読したとしても、アプリケーションの動作を変更することを困難にすることがわかる。短い記述的でないラベルの使用は、コードのサイズを低減することに役立つ。

本発明は、ここで説明した実施例に限定されず、本発明の範囲を逸脱することなく、変更又は変形されてもよい。

本発明を具現したデジタルビデオ放送（DVB）システム図１のシステムでの加入者端末内の機能ブロック暗号化アプリケーションを受信するときのステップのフローチャート図１の端末と許可エンティティとの部分を詳細に示した図ランチャー・アプリケーションが暗号化メインアプリケーションの前にダウンロードされる本発明の代替実施例

Claims

デジタル放送システムにおいて端末で暗号化アプリケーションを受信する方法であって、
前記端末は、外部関係者に信号を運ぶことができるインタラクション・チャンネルへのアクセスを有し、
前記方法は、
暗号化アプリケーションについての詳細を受信するステップと、
前記インタラクション・チャンネルで許可エンティティに許可要求を送信することにより、前記端末が前記アプリケーションにアクセスすることを許可するステップと、
許可されたことに応じて、前記インタラクション・チャンネルで鍵を受信するステップと、
前記暗号化アプリケーションを受信するステップと、
前記受信した鍵を使用して前記暗号化アプリケーションを解読するステップと
を有する方法。
請求項１に記載の方法であって、
前記アプリケーションについての詳細を受信するステップは、前記端末を許可するように構成されたランチャー・アプリケーションを受信することを有する方法。
請求項１又は２に記載の方法であって、
前記アプリケーションについての詳細を受信するステップは、前記アプリケーションを解読するように構成されたランチャー・アプリケーションを受信することを有する方法。
請求項２又は３に記載の方法であって、
前記ランチャー・アプリケーションは、前記暗号化アプリケーションへの異なる配信チャンネルを介して受信される方法。
請求項１ないし４のうちいずれか１項に記載の方法であって、
前記アプリケーションを解読するステップは、アプリケーション・ローダにより実行される方法。
請求項５に記載の方法であって、
前記アプリケーション・ローダは、Java ClassLoaderである方法。
請求項１ないし６のうちいずれか１項に記載の方法であって、
前記受信した詳細は、前記アプリケーションを暗号化するために使用される暗号化方法と、前記アプリケーションのコストと、支払の詳細とのうち１つ以上を有する方法。
請求項１ないし７のうちいずれか１項に記載の方法であって、
前記端末のユーザから支払の詳細を収集するステップを更に有する方法。
請求項１ないし８のうちいずれか１項に記載の方法であって、
前記端末のユーザから支払を収集するステップを更に有する方法。
請求項１ないし９のうちいずれか１項に記載の方法であって、
前記端末は、秘密／公開鍵の対を有し、
外部関係者にコンタクトするステップは、前記公開鍵を前記外部関係者に送信することを有する方法。
請求項１０に記載の方法であって、
前記公開鍵を使用して暗号化された解読鍵を前記外部関係者から受信することを更に有する方法。
請求項１０又は１１に記載の方法であって、
前記公開／秘密鍵の対は、前記端末を一意に特定する方法。
請求項１０ないし１２のうちいずれか１項に記載の方法であって、
前記公開鍵は、前記端末の製造者により承認されている方法。
請求項１ないし１３のうちいずれか１項に記載の方法であって、
前記デジタル放送システムは、限定受信システムを使用しない方法。
請求項１ないし１４のうちいずれか１項に記載の方法であって、
前記デジタル放送システムは、Multimedia Home Platform（MHP）である方法。
請求項１ないし１５のうちいずれか１項に記載の方法を実行するように構成されたデジタル放送システムにおける端末用の制御装置。
請求項１ないし１５のうちいずれか１項に記載の方法に従って端末の動作を制御するソフトウェア。
請求項１６に記載の制御装置又は請求項１７に記載のソフトウェアを組み込んだ端末。
デジタル放送システムにおいて端末にアプリケーションを送信する方法であって、
前記端末は、外部関係者に信号を運ぶことができるインタラクション・チャンネルへのアクセスを有し、
前記方法は、
前記インタラクション・チャンネルで許可エンティティに許可要求を送信し、許可されたことに応じて、前記インタラクション・チャンネルで鍵を受信し、前記鍵を使用してアプリケーションを解読することにより、端末が暗号化アプリケーションにアクセスすることを許可するように構成されたランチャー・アプリケーションを有する暗号化アプリケーションについての詳細を送信するステップと、
前記暗号化アプリケーションを送信するステップと
を有する方法。
デジタル放送システムにおいて端末にアプリケーションを送信するアプリケーション用のソフトウェアであって、
前記端末は、外部関係者に信号を運ぶことができるインタラクション・チャンネルへのアクセスを有し、
前記アプリケーションは、前記端末のプロセッサにより実行されると、
前記インタラクション・チャンネルで許可エンティティに許可要求を送信し、許可されたことに応じて、前記インタラクション・チャンネルで鍵を受信することにより、前記端末が暗号化アプリケーションにアクセスすることを許可するステップと、
前記受信した鍵を使用して前記暗号化アプリケーションを解読するステップと
を前記プロセッサに実行させるコードを有するランチャー・アプリケーションを有するソフトウェア。
デジタル放送システムにおける伝送用の信号であって、
請求項２０に記載のソフトウェアを具現した信号。
限定受信システムが使用されていないデジタル放送システムにおいて端末に暗号化アプリケーションを送信する方法であって、
前記暗号化アプリケーションについての暗号化されていない詳細を送信し、前記詳細は、前記アプリケーションを暗号化するために使用される暗号化方法と、前記アプリケーションのコストと、支払の詳細とのうち１つ以上を有し、
前記暗号化アプリケーションを送信することを有する方法。
実質的に添付図面を参照して説明し、添付図面に図示した、暗号化アプリケーションを受信する方法、制御装置、ソフトウェア、端末、アプリケーションを送信する方法又は信号。