JP2009500726A - インタラクティブ・メディア環境におけるアプリケーション・セキュリティ - Google Patents

Abstract

【課題】 インタラクティブ・マルチメディアの分野においてアプリケーションのシステム・リソースへのアクセスを制御するセキュリティ・システムについて記載する。
【解決手段】 本システムは、署名システムを含む、アプリケーション・セキュリティに合わせてフレームワークを確立し、更にセキュリティをサポートするファイル・フォーマットを規定する。署名済みのアプリケーションには、高いアクセス特権が与えられ、一方味署名のアプリケーションには低いアクセス特権が与えられる。例えば、ディスク上において署名済みおよび未署名のアプリケーションを組み合わせると、署名済みおよび未署名のアプリケーション全てに対して、低いアクセス特権を与える。
【選択図】 図１

Description

（関連出願の申告）
本願は、２００５年７月１日に出願した仮特許出願第６０／６９５，９４４号の優先権を主張する。その内容は、ここで言及したことにより、本願にも含まれるものとする。

マルチメディア再生システムの中には、オーディオ／ビデオ再生中にインタラクティブ・グラフィックを制限して提供する場合がある。インタラクティブ再生システムの能力が高い程、違法行為につけ込まれる状況も多くなる。ウイルス、スパイウェア、およびその他の悪意のソフトウェアに対抗して再生システムのセキュリティを維持することは肝要である。悪意のソフトウェアのために、インタラクティブ再生システムが誤動作を起こしたり、秘密のユーザ情報を集めて送信してしまう虞れがある。加えて、インタラクティブ再生システムをネットワークに接続することもある。ソフトウェアまたはユーザ情報は、再生システムから、ネットワークに取り付けられている他の精算システムに伝搬する可能性がある。その結果、インタラクティブ再生システムがしかるべきセキュリティ装備を含むことは、欠くことができなくなっている。

インタラクティブ・マルチメディアの分野において未署名アプリケーション(unsigned application)の特権を制御するセキュリティ・システムを提供する。

インタラクティブ・マルチメディアとは、アプリケーションが、通例、ユーザ入力イベントに応答して、同期を取りリアル・タイムで精度高くフレーム毎に、グラフィックス、オーディオ、およびビデオを含むマルチメディア・オブジェクトを管理する環境のことである。アプリケーションは高品位ＤＶＤ（ディジタル・バーサタイル・ディスク）メディアに関係するので、ここでは「ｉＨＤ」アプリケーションと呼ぶ。しかしながら、開示するセキュリティ・システムは、更に一般的に、その他のインタラクティブ・マルチメディア環境にも適用可能である。

具体的には、本システムは、コンテンツ・セキュリティではなく、アプリケーション・セキュリティに適用され、署名システムを含む、アプリケーション・セキュリティに合わせてフレームワークを確立し、更にセキュリティをサポートするファイル・フォーマットを規定する。インタラクティブ・マルチメディア・アプリケーションは、インタラクティブ再生システム（単体のハードウェア・デバイスとして実施され、あるいは、例えば、パーソナル・コンピュータ上で走るソフトウェア・アプリケーションとして実施される）上で走り、署名済みでも未署名でもよい。

アプリケーションに署名されていれば、実際上無制限の適用が許可される。未署名のアプリケーションでは、これがアクセスできる範囲が大幅に制限される。更に、署名済みのアプリケーションおよび未署名のアプリケーション双方が走っている場合、未署名のアプリケーションのセキュリティ・レベルおよびアクセス特権のみが双方に与えられる。未署名のアプリケーションに備えることによって、豊富な双方向参加機構を用いて家庭で著作したディスクをカスタム化することを可能にするが、ネットワーク、例えば、インターネットや、再生システム内に格納されている機密情報へのアクセスを、許可を付与された者に制限する。

署名済みのアプリケーションには、特殊なファイル・フォーマットを規定し、ファイル全体を解析する必要なく、署名ステータスの判定を可能にする。

インタラクティブ・マルチメディア・アプリケーションとは、アプリケーションがユーザ・イベントに応答するアプリケーションである。一例を上げると、ユーザがアクセスするアプリケーション内部に実装されたメニューがあり、ユーザが入力を提出すると、アプリケーションが状態を変化させる。このような場合、双方向参加は、メニュー・グラフィクスによって行われ、メニュー・グラフィクスがレンダリングされている間、その下で、例えば、ｚ＝０レイヤ上で、リアル・タイムでフレーム同期に基づいて、ビデオを再生する。双方向参加により、例えば、ビデオ・ストリームの表示方法の変化をもたらすことができる。

例えば、下地のビデオは高品位ムービーとすることができる。グラフィック・オーバーレイは、ムービーのディレクタによる批評の一部とすることができ、例えば、場面自体の上に被せた種々のカメラ位置の模式図を示す。ユーザは、リモコンを用いて、これらのカメラ位置のいずれによって撮影された視界(view)にも切り換えることができる。

先に記したように、インタラクティブ再生システムの能力が高い程、違法行為につけ込まれる状況も増える。悪意のソフトウェアのために、インタラクティブ再生システムが誤動作を起こしたり、秘密のユーザ情報を集めて送信してしまう虞れがある。

本システムでは、再生システムにおいて用いるインタラクティブ・アプリケーションには、署名しても署名しなくてもよい。署名済みのアプリケーションとは、信頼できる起源の権威(trusted root authority)から起源証明書(root certificate)を継承し、安全と見なされるアプリケーションである。

署名済みのアプリケーションには、高レベルのアクセス特権が与えられる。この殆ど無制限の特権により、例えば、ネットワーキング、ファイルＩ／Ｏ、セキュリティ、および診断ＡＰＩへのアクセスが許され、永続的ストレージにアクセスして、アプリケーションの呼び出し(invocation)を何回行っても変化しないデータを格納および検索することができる。

一方、未署名のアプリケーションには、低レベルのアクセス特権が与えられる。これらは、高アクセス(high access)によって得られる種類の機能へのアクセスを拒絶される。これらは、マークアップ言語、ならびに、例えば、以下のECMAScriptにおけるＡＰＩ例からのある種のオブジェクト、ＸＭＬ（Ｉ／Ｏ機能なし）、グローバル化、グラフィック・エレメントに関連する描画機能、およびユーザ入力動作の利用に制限される場合がある。

このレベルの機能は、いずれのネットワーキング、セキュリティ、またはファイルＩ／Ｏへのアクセスをも禁止する。永続的ローカル・ストレージから前述の名称空間(namespace)またはロード・リソース(load resource)の外側の関数をコールしようとしても、いずれもが、例外となり、アプリケーションが終了する。

一実施形態では、メディア・ディスク、例えば、ＨＤ−ＤＶＤ上にアプリケーション集合があり、これらを用いてインタラクティブ・グラフィクスおよびビデオ・アプリケーションを走らせる。図１を参照すると、再生システムがメディア・ディスクを受ける（ステップ１２）。再生システムは、汎用のコンピュータ・システムまたは更に特殊化したメディア・センタ・システムでもよく、メディア上のアプリケーションの署名ステータスを判定する（ステップ１４）。全てのアプリケーションの署名ステータスが署名済みであると判定されると（ステップ１６）、アプリケーションの全てに高アクセス特権が与えられる（ステップ１８）。いずれか１つのアプリケーションでも署名ステータスが未署名であると判定された場合、全てのアプリケーションには低アクセス特権が与えられる（ステップ２２）。即ち、未署名のアプリケーションが走っている場合、同時に走っている全てのアプリケーションが署名済みであれ未署名であれ、これらを未署名アプリケーション許可レベルに制限することができる。これによって、未署名のアプリケーションが、同時の署名済みアプリケーションの特権を利用することを防止する。

別の実施形態では、同様の方法を、再生システムにロードされたアプリケーションに直接適用することができる。図２を参照すると、アプリケーションを再生システムにロードすることができる（ステップ２４）。次いで、アプリケーションの署名ステータスを検出する（ステップ２６）。署名ステータスが署名済みであると判定されると（ステップ２８）、アプリケーションを高特権アクセス・レベルで走らせることができる（ステップ３２）。しかしながら、署名ステータスが未署名であると判定されると（ステップ２８）、低特権アクセス・レベルでアプリケーションを走らせる（ステップ３４）。この場合、アプリケーションをメディア、例えば、ディスクから直接走らせる（ステップ３６）。これによって、セキュリティを強化する。何故なら、未署名のアプリケーションは全て、走ることも、再生システムのローカル永続的ストレージからリソースをロードすることも妨げられるからである。追加のアプリケーションをロードする際には（ステップ３８）、これらの署名ステータスを検査してもしなくてもよい。一般に、これらには低アクセス・レベルが与えられる（ステップ３４）。アプリケーションが署名され、高アクセス特権が与えられ、その後にロードされたアプリケーションが未署名である場合、高アクセス・アプリケーションは低アクセス・レベルに格下げとなる。

図３を参照すると、署名済みアプリケーションに対して、再生システムは、メディアを再生システムに導入したとき（ステップ４２）に、検出した著作者識別子集合の採用を含むことができる（ステップ４４）。即ち、各メディアまたはアプリケーションには著作者識別子を関連させることができる。著作者識別子は、コンテンツ著作者を一意に識別し、永続的ストレージにおけるアプリケーション、即ち、呼び出しの度に変化しないことが望ましいデータを格納および検索するために永続的ストレージにアクセスすることができるアプリケーションのセキュリティには特に重要である。

次いで、著作者識別子を、当該著作者識別子と関連のあるディレクトリの作成と関連付ける（ステップ４６）。そのメディアからのアプリケーションは、永続的ストレージにおいてその著作者識別子に対応するディレクトリにしかアクセスすることができない。ファイル・システムは、アプリケーションがそれを見ると、そのディレクトリを起源とする。アプリケーションはサブディレクトリを管理することができるが、そのルート・ディレクトリを超えることや、他の著作者のデータを見ることはできない。

著作者識別子は、ディスク上の全てのアプリケーションを含むディスク、あるいはそのディスク上にある、数枚のディスクに跨って分散されている、またはそれ以外では例えばインターネット・ダウンロードによって再生システムにロードした、１つのアプリケーションのいずれにでも関連付けることができる。更に、所与のメディアに１つの著作者識別子を関連付けることができるが、所与の著作者識別子が多数のメディア上で発見されることもある。他の実施形態では、アプリケーションに署名したキーによって示される識別子を用いることができる。異なるアプリケーションが異なる人によって１つのメディア上で署名することができると仮定すると、この実施形態では、ストレージを更に大きく分離することになる。最後の署名の代わりに証明書の連鎖を用いると、更に一層そのようになる。
アプリケーションの構造
これより、署名済みアプリケーションの構造について説明する。図４を参照すると、署名済みアプリケーション５０は、目録ファイル５２と少なくとも１つのリソース・ファイル５４とを含むことができる。目録ファイル５２には著作者の署名および証明書が署名されており、それが参照するリソース全てを認証する。

アプリケーションは、その目録ファイル５２および全てのリソース・ファイル５４〜５８を纏めて１つの未圧縮アーカイブ４８にすることもできる。アーカイブ４８のファイル・フォーマットは、暗号化をサポートする必要もない。アーカイブ４８は、本質的に、コンテナであり、一般に独立して署名する必要はない。目録ファイル５２は、インタラクティブ・アプリケーションのリソース・ファイル５４〜５８の各々を参照することができる。アーカイブ４８のアーキテクチャは、アーカイブ４８を効率的に流動させるように指定することができる。例えば、署名済みの目録ファイル５２をアーカイブ４８における最初のファイルとすれば、アーカイブ全体を読み取ることなく、署名の検証が可能となる。アーカイブ・フォーマットの後続バージョンは、以前のバージョンと下位互換性を有するとよい。

アーカイブ４８におけるデータの認証は、例えば、ＲＦＣ３２７５が定義するＸＬＭ−署名の使用によって行うことができる。
目録ファイルのフォーマット
一例では、署名済み目録ファイル５２のフォーマットは、ＲＦＣ３２７５によって定義されたＸＭＬ−署名シンタックスおよび処理に対するＷ３Ｃ推奨の部分集合を利用することができる。このように、以下の要素の部分集合を含めてサポートすることができる。

ds:Signature
ds:SignatureValue
ds:SignatureType
ds:Reference
ds:Reference/ds:DigestValue
他の要素は、システムによって決定することができる。目録に含まれるリソース項目毎のダイジェスト値(digest value)はds:Reference 要素としてリストに纏めることができる。
証明書および署名
一例として、要求される署名タイプが、例えば、Ｘ．５０９とすることができる。ds:SignatureMethodによって定義される署名方法は、ＲＳＡ−ＳＨＡ１とすることができる。カノニカル化方法(canonicalization method)は、Exclusive XML canonicalization 1.0とするように指定することができる。ダイジェスト方法は、署名方法、ＲＳＡ−ＳＨＡ１と同一とすることができる。キー情報は、システムによって、アプリケーションを走らせているメディアまたはローカル・ストレージ・エリアの個体情報(identity)から推論することができる。
証明書廃止リスト
悪化したアプリケーションの廃止および交換のためのメカニズムを設けるために、各インタラクティブ・ビデオおよびグラフィクス・アプリケーションの著作者は、廃止したアプリケーションのダイジェスト値を纏めてリストとしたコンテンツ廃止リスト（「ＣＲＬ」）を含むことができる。このＣＲＬは、別個のファイルに含めることができる。このファイルは、廃止した署名ダイジェストを纏めたリスト、およびディスクを著作したコンテンツ作成者の署名を収容する。廃止した各アプリケーションの元の著作者の署名が、ＣＲＬファイルにおける署名のそれと一致したと仮定すると、リストにあるアプリケーション・ダイジェストは、ローカル・ストレージのコンテンツ提供業者の制限された区域に格納されており、もはや走ることは許されない。ＣＲＬがアプリケーションに含まれている場合、Revocation.xmlのような認識可能な名称を与えることができる。

アプリケーション著作者は、廃止したアプリケーションを新バージョンと交換することを望むこともあり得る。これは、数種類の異なる方法で遂行することができる。インターネット接続プレーヤ上で走っているタイトル(title)に、これらのホーム・サーバをチェックさせて、新たにダウンロードするアプリケーションを指定する更新プレーリストまたはインタラクティブ・ビデオおよびグラフィクス群を求めることができる。あるいは、アプリケーションを廃止するメディアは、それ自体で代わりを供給することもできる。

以下の表は、アーカイブ・ファイルに可能な１つのフォーマットを、フィールドについて記述するコメントと共に記載する。尚、多数のその他のフォーマットも使用可能であることを記しておく。この表では、タイプを表すために略語を用いている。Uinは、ｎビットの符号無し整数を表す。例えば、Ui8は、８ビットの符号無し整数であり、Ui32は、３２ビットの符号内整数である。角括弧を用いることによってタイプのアレイを示し、アレイの長さをこれらの括弧の間に示す。長さが直前のフィールドに左右される場合、そのフィールドの名称、またはそのフィールド内に示されるそれよりも短い名称を用いて、そのフィールドの値に言及することができる。１６進数は、0xdd表記を用いて、示す。全ての可変長ストリング、したがって、リソース名は、UTF-8を用い、パスカル・ストリング表記（８ビット長とそれに続くバイト）を用いてエンコードすることができる。

以上に記したアプリケーション・リソースにある種の規則を適用してもよい。例えば、リソース名は、ファイル・システムの名称または論理ＵＲＩとしなければならない。アーカイブ・ファイルを抽出するディレクトリは、その抽出中におけるファイル・システムのルートとであると見なすことができる。このように、全ての名称をそのディレクトリに関して作り、絶対パスが関係あるものと同じように振る舞うようにする。ある名称からそのディレクトリの外部の位置が得られた場合、名称およびエントリを無効と見なすことができる。

以下の章では、前述のアーカイブ・ファイル例の種々のフィールドおよびセクションに関する更に詳細な情報を示す。

アーカイブ・ヘッダ
マジック・フィールド
これは、アーカイブを一意に識別するために用いられる「マジック数」である。これは、ストリング"iHDar"、即ち、UTF-8、ASCII等の５文字値のシーケンスとして符号化したiHDアーカイブ、即ち、0x69、0x48、0x44、0x61、0x72から成るとすることができる。

バージョン・フィールド
バージョン・フィールドは、アーカイブリーダが異なるバージョンのアーカイブ・フォーマットを読みとれるようにする。バージョン・フィールドを見ることにより、ファイルの異なるセクションにおいて何が予期されるかを知ることができ、したがってあるバージョンのファイル・フォーマットにはなかった情報を読み出すことができる。このフィールドの値は、例えば、0x01とすることができる。今後のバージョンは、0x02から0xffまでの値を有することができる。

リソース・カタログおよびリソース・エントリ
リソース・カタログは、多数のリソース・エントリを含む角エントリは、同じフォーマットに従う。

リソース・エントリ長
これは、リソース・エントリ自体の長さであり、バイト単位で表す。この値は、バージョンがわからないフォーマットを読んでいるリーダによって用いられる。バージョン２のフォーマットを用いて書かれたアーカイブが、バージョン１に合わせて作られたリーダによって見られていると仮定すると、リーダは、それに分かるフィールドを読み、次いで、現エントリの長さが分かるので、次のリソース・エントリまで飛ばすことができる。

リソース・オフセット
これは、リソース・データ・ブロックにおけるリソースのバイト・オフセットを示す。最初のリソースのオフセットは0x0000である。

リソース長
これは、リソースの長さであり、バイト単位である。

リソースＡおよびＢがアーカイブ・ファイルにおいて連続している場合、Ｂに対するリソース・オフセットは、Ａのリソース・オフセットとリソース長との和に等しい。

リソース・チェックサム
これは、ISO3309が定義する、リソースのＣＲＣ−３２チェックサムを表す。尚、このチェックサムは、信頼性のない媒体を通じて輸送されたリソースの保全性の単純な検証に限って用いてもよいことを記しておく。ＣＲＣ−３２チェックサムは、キーが付けられておらず、耐変転(collision-proof)でもないので、認証の目的には用いてはならない。リソースを認証する必要がある場合、前述の署名メカニズムを用いるとよい。

リソース・タイプ
これは、リソースのMIMEタイプである。

リソース名の長さ
これは、リソース名の長さであり、バイト単位である。リソース名はこのフィールドの直後にある。

リソース名
これは、リソース名自体である。

リソース・データ・ブロック
リソース・データ・ブロックは、リソースに対する全てのバイトを、リソース・カタログに出てくる順に収容する。一般に、２つのリソース間には明示的な分離はない。これは、そのオフセットおよび長さが周知の量であるためである。

本システムの説明は、全体的に、コンピュータが実行するプログラム・モジュールのような、コンピュータ実行可能命令に関して行う。一般に、プログラム・モジュールは、ルーチン、オブジェクト、コンポーネント、データ構造等を含み、特定のタスクを実行するか、または特定の抽象的データ・タイプを実現する。本システムおよび方法は、分散型計算環境においても採用することができ、その場合、通信ネットワークを通じてリンクされているリモート処理デバイスによってタスクを実行する。分散型計算環境では、プログラム・モジュールは、メモリ記憶デバイスを含む、ローカルおよびリモート・コンピュータ記憶デバイス双方に位置することもできる。

本方法およびシステムを実行する命令は、種々のコンピュータ読み取り可能媒体上に格納することができる。コンピュータ読み取り可能媒体は、コンピュータがアクセス可能な入手可能な媒体であればいずれでも可能であり、揮発性および不揮発性の双方、リムーバブル、および非リムーバブル媒体を含む。限定ではない一例をあげると、コンピュータ読み取り可能媒体は、コンピュータ記憶媒体および通信媒体から成ると考えられる。コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、またはその他のデータというような情報の格納のために、あらゆる方法または技術で実施される、揮発性および不揮発性の双方、リムーバブル、および非リムーバブル媒体を含む。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリまたはその他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル・ビデオ・ディスク（ＤＶＤ）またはその他の光ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、あるいは所望の情報を格納するために用いることができしかもコンピュータがアクセス可能なその他のいずれの媒体も含むが、これらに限定されるのではない。通信媒体は、通例、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、またはその他のデータを、搬送波またはその他の移送機構のような変調データ信号において具体化し、あらゆる情報配信媒体を含む。「変調データ信号」という用語は、その特性集合の１つ以上が、情報を信号内にエンコードするようなやり方で、変化している信号を意味する。限定ではなく、一例として、通信媒体は、有線ネットワークまたは直接有線接続というような有線媒体、ならびに音響、ＲＦ、赤外線、およびその他のワイヤレス媒体というようなワイヤレス媒体を含む。前述のいずれの組み合わせも、コンピュータ読み取り可能媒体の範囲に当然含まれるものとする。

コンピュータを含む計算システム環境の一例に関して説明したが、本システムは、本発明は、その他の多数の汎用または特殊目的計算システム環境または構成でも動作可能である。計算システム環境は、本発明の使用や機能の範囲に関していずれの限定をも示唆することを意図していない。更に、計算システム環境は、動作環境例に示す構成要素のいずれの１つまたは組み合わせに関しても、いかなる依存性や必須要件をも有するという解釈は行わないこととする。本発明と共に用いるのに適していると思われる周知の計算システム、環境、および／または構成の例には、パーソナル・コンピュータ、サーバ・コンピュータ、ハンド・ヘルドまたはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサに基づくシステム、セット・トップ・ボックス、プログラマブル消費者用電子機器、移動体電話、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ、前述のシステムまたはデバイスのいずれをも含む分散型計算機環境等が含まれる。

ここに記載したシステムおよび方法は、ソフトウェアまたはハードウェア、あるいは一部は当技術分野では周知である技法を用いて双方で実施することができる。

ここに図示し説明した方法の実行順序は、特に指定がない限り、必須ではない。即ち、方法の要素は、特に指定がない限り、いずれの順序で実行してもよく、本方法は、ここに開示した要素よりも多いまたは少ない要素を含んでもよい。

本発明またはその実施形態の要素を導入する際において、冠詞「a」、「an」、「the」、「said」は、１つ以上の要素があることを意味することを意図している。「comprising」、「including」、および「having」は、内包的であることを意図しており、掲示する要素以外にも追加の要素があり得ることを意味する。

前述の構造、生産物、および方法には、本発明の範囲から逸脱することなく種々の変更を行うことができるので、以上の説明に内包される事項全ては、限定の意味ではなく、例示と解釈することを意図している。

以上構造的特徴および／または方法論的ステップに対して特定の言葉で主題について説明したが、添付した特許請求に定めた主題は、必ずしも前述の特定の特徴や行為(act)に限定されるのではないことは言うまでもない。逆に、前述の特定の特徴や行為は、特許請求の範囲を実施する形態例として開示したものである。

図１は、アプリケーションの署名ステータスをディスクから検出する、特権をアプリケーションに割り当てる方法を示すフローチャートである。 図２は、再生システムに装填するときにアプリケーションの署名ステータスを検出する、特権をアプリケーションに割り当てる方法を示すフローチャートである。 図３は、著作者識別子−キー・ディレクトリ(keyed directory)の作成を示すフローチャートである。 図４は、アプリケーション・ファイルの模式図である。

Claims (23)

1. インタラクティブ・マルチメディア環境においてアプリケーションのセキュリティを保証する方法であって、
   ａ．インタラクティブ・ビデオおよびフレーム同期グラフィックスを実施するアプリケーションを受けるステップと、
   ｂ．前記アプリケーションの署名ステータスを検出するステップと、
   ｃ．前記署名ステータスが署名済みである場合、ローカル・ストレージのソースおよびネットワーク・リソースへの許可アクセスを与えるステップと、
   ｄ．前記署名ステータスが未署名である場合、ローカル・ストレージのソースおよびネットワーク・リソースへの許可アクセスを拒否するステップと、
   を備えた、方法。
2. 請求項１記載の方法であって、更に、前記署名ステータスが署名済みである場合、ファイルＩ／Ｏならびにセキュリティおよび診断ＡＰＩへの許可アクセスを与えるステップを備えた、方法。
3. 請求項１記載の方法において、前記検出するステップは、前記アプリケーションに関連する目録ファイルを読み取り、前記目録に著作者の署名および証明書が署名されているか否か判定を行うステップを備えた、方法。
4. 請求項３記載の方法において、前記アプリケーションは、前記目録ファイルと少なくとも１つのリソース・ファイルとを貯蔵するアーカイブを収容し、前記目録ファイルは、前記アーカイブにおける最初のファイルである、方法。
5. 請求項４記載の方法において、前記アーカイブは、当該アーカイブを効率的に流動させることができるようなフォーマットを有する、方法。
6. 請求項１記載の方法であって、更に、前記署名ステータスが署名済みである場合、前記アプリケーションは、署名済みの起源証明書、コンテンツ廃止リスト、または著作者識別子を含む、方法。
7. 請求項１記載の方法において、前記ローカル・ストレージのソースは、著作者識別子とキーで結ばれたディレクトリである、方法。
8. 請求項１記載の方法であって、更に、前記署名ステータスが未署名である場合、ファイルＩ／Ｏならびにセキュリティおよび診断ＡＰＩへの許可アクセスを拒否するステップを備えた、方法。
9. 請求項１記載の方法であって、更に、前記署名ステータスが未署名である場合、マークアップ言語の利用、ならびに、Ｉ／Ｏ機能のないＸＭＬ、グローバル化、描画機能、およびユーザ入力動作から成るオブジェクトの利用への許可アクセスを与えるステップを備えた、方法。
10. 請求項１記載の方法であって、更に、前記署名ステータスが未署名であり、光ディスクから前記アプリケーションを受けた場合、前記アプリケーションを前記光ディスクのみから走らせるステップを備えた、方法。
11. 請求項１記載の方法であって、更に、
    ａ．他のアプリケーションを受けるステップと、
    ｂ．前記他のアプリケーションの署名ステータスを検出するステップと、
    ｃ．前記アプリケーションまたは前記他のアプリケーションの署名ステータスが未署名である場合、双方のアプリケーションのローカル・ストレージのソースおよびネットワーク・リソース双方への許可アクセスを拒否するステップと、
    ｄ．前記アプリケーションおよび前記他のアプリケーションの署名ステータスが双方共署名済みである場合、双方のアプリケーションのローカル・ストレージのソースおよびネットワーク・リソース双方への許可アクセスを与えるステップと、
    を備えた、方法。
12. メディア・ディスクのセキュリティを保証する方法であって、
    ａ．再生システムにおいてメディア・ディスクを受けるステップであって、該メディア・ディスクが１つ以上のアプリケーションを収容しており、該アプリケーションがインタラクティブ・マルチメディア環境においてインタラクティブ・ビデオ・フレーム同期グラフィクスを実施する、ステップと、
    ｂ．前記メディア・ディスク上の各アプリケーションの署名ステータスを検出するステップと、
    ｃ．前記アプリケーション全ての署名ステータスが署名済みである場合、ローカル・ストレージのソースおよびネットワーク・リソースへの高い許可アクセスを各アプリケーションに与えるステップと、
    ｄ．前記アプリケーションのいずれかの署名ステータスが未署名である場合、ローカル・ストレージのソースおよびネットワーク・リソースへの高い許可アクセスをいずれのアプリケーションに対しても拒否するステップと、
    を備えた、方法。
13. アプリケーション用マルチメディア再生システムであって、前記アプリケーションが、インタラクティブ・マルチメディア環境において、インタラクティブ・ビデオ・フレーム同期グラフィクスを実施し、
    ネットワーク・リソースと、
    ローカル・ストレージのソースと、
    インタラクティブ・グラフィクスおよびビデオを組み込んだアプリケーションを受けるデバイスと、
    前記アプリケーションの署名ステータスを検出するプロセッサと、
    を備えており、
    前記アプリケーションが署名されている場合、前記ローカル・ストレージのソースおよび前記ネットワーク・リソースへの許可アクセスを前記アプリケーションに与え、
    前記アプリケーションが未署名である場合、前記ローカル・ストレージのソースおよび前記ネットワーク・リソースへの許可アクセスを前記アプリケーションに対して拒否する、マルチメディア再生システム。
14. 請求項１３記載のシステムにおいて、前記プロセッサは、前記アプリケーションに関連する目録ファイルを読み取り、前記目録に著作者の署名および証明書が署名されているか否か判定することによって、前記アプリケーションの署名ステータスを検出する、システム。
15. 請求項１４記載のシステムにおいて、前記アプリケーションは、前記目録ファイルおよび少なくとも１つのリソース・ファイルを貯蔵するアーカイブを収容し、前記目録ファイルは、前記アーカイブにおける最初のファイルである、システム。
16. 請求項１３記載のシステムにおいて、前記署名ステータスが署名済みである場合、前記アプリケーションは、署名済みの起源証明書、コンテンツ廃止リスト、または著作者の識別子を含む、システム。
17. 請求項１６記載のシステムにおいて、前記ローカル・ストレージのソースは、著作者識別子とキーで結ばれたディレクトリである、システム。
18. 請求項１３記載のシステムにおいて、前記署名ステータスが署名済みである場合、ファイルＩ／Ｏならびにセキュリティおよび診断ＡＰＩへの許可アクセスを前記アプリケーションに与える、システム。
19. 請求項１３記載のシステムにおいて、前記署名ステータスが未署名である場合、前記アプリケーションは、
    ａ．ファイルＩ／Ｏならびにセキュリティおよび診断ＡＰＩへの許可アクセスを拒否される、または
    ｂ．マークアップ言語の利用、ならびに、Ｉ／Ｏ機能のないＸＭＬ、グローバル化、描画機能、およびユーザ入力動作から成るオブジェクトの利用への許可アクセスが与えられる、システム。
20. 請求項１３記載のシステムにおいて、前記プロセッサは、別のアプリケーションの署名ステータスを検出するように構成されており、
    ａ．前記アプリケーションまたは前記他のアプリケーションの署名ステータスが未署名である場合、双方のアプリケーションのローカル・ストレージのソースおよびネットワーク・リソース双方への許可アクセスを拒否し、
    ｄ．前記アプリケーションおよび前記他のアプリケーションの署名ステータスが双方共署名済みである場合、双方のアプリケーションのローカル・ストレージのソースおよびネットワーク・リソース双方への許可アクセスを与える、システム。
21. 請求項１３記載のシステムであって、更に、前記署名ステータスが未署名であり、光ディスクから前記アプリケーションを受け取った場合、前記アプリケーションを前記光ディスクのみから走らせることを備えた、システム。
22. 安全なアプリケーションを著作する方法であって、
    インタラクティブ・マルチメディア環境においてインタラクティブ・ビデオ・フレーム同期グラフィクスを実施するアプリケーションを開発するステップと、
    前記アプリケーションを、目録ファイルと少なくとも１つのリソース・ファイルとを有するアーカイブ・ファイル・フォーマットに変換するステップと、
    前記目録ファイル内に、署名を収容する証明書を配置するステップと、
    前記目録ファイルを前記アーカイブ・ファイルの先頭に配置するステップと、
    を備えた、方法。
23. 請求項２２記載の方法であって、更に、前記アプリケーションをディスク上に焼き付けるまたは保存するステップを備えた、方法。

Images