JP5061908B2 - プログラム実行制御方法および装置ならびに実行制御プログラム - Google Patents

Description

本発明はコンピュータにおけるアプリケーションプログラムの実行制御に関し、特に信頼できないコードを含むアプリケーションプログラムからシステム資源を保護して安全に実行する技術に関する。

有線または無線のネットワークや外部メモリカードを用いて、コンピュータ端末の外部からアプリケーションプログラム（以下、単に、アプリケーションと略す）を導入または取得する場合、アプリケーションの悪意ある動作や不具合等から、コンピュータ端末内の各種データに不正にアクセスされたり、端末システムの安定動作を妨害される恐れがある。そのため、信頼できないコードを含むアプリケーションをコンピュータ端末上で安全に実行する技術が重要である。

従来のこの種技術の一例が特表２００１−５１４４１１公報（特許文献１）に記載されている。この従来技術では、外部から導入または取得されたアプリケーションは、サンドボックスと呼ばれるメモリ範囲内にロードされ、メモリにアクセスする際、当該アプリケーションのコードに追加されたチェックコードによってそのアクセスがチェックされる。若し、メモリに対するアクセスがサンドボックス内であれば許可され、サンドボックス外であれば、そのアクセスが許容されるか否かを判断し、許容されれば許可し、そうでなければ阻止する。また、アプリケーションからのＡＰＩ（Application
Programming Interface）コールは、コンピュータシステムのセキュリティの侵害を防止しながらホストオペレーティングシステムにアクセスできるサンクと呼ばれる変換コードモジュールで置換される。アプリケーションの実行中にＡＰＩコールが行われると、制御が変換コードモジュールに移り、そのＡＰＩコードがホストオペレーティングシステムで実行されることが許容されるべきかどうかが判断される。許容されていればそのＡＰＩコールは処理され、許容されていなければそのＡＰＩコールは実行されない。幾つかのＡＰＩコールは所定の修正が施されて実行される場合がある。

特許文献１に開示された従来技術によれば、外部から導入または取得されたアプリケーションはメモリの外側へのアクセスが制限されたメモリ範囲にロードされ、またアプリケーション中のＡＰＩコールは変換コードモジュールで置換されてそのコール時に実行の可否がチェックされる。つまり、アプリケーションは隔離された実行環境の下で実行される。これによって、実行環境外部に存在するユーザデータやライブラリあるいはデバイスドライバといったシステム資源の保護を図りながら、信頼できないアプリケーションの実行を安全に実行できるようにしている。

しかしながら、特許文献１に開示された従来技術では、外部から導入または取得されたアプリケーションはライブラリやデバイスドライバなどをＡＰＩ経由でしか利用することができない。そして、ＡＰＩコールを行うと、その都度、変換コードモジュールにおいてその実行の可否の判定が行われるため、それがオーバーヘッドとなってアプリケーションの実行速度が低下する。

本発明は、従来技術の課題を克服し、信頼できないコードを含むプログラムを安全に、かつ、オーバーヘッドを少なくして実行するプログラム実行制御方法およびその装置ならびに実行制御プログラムを提供することができる。

本発明の第１のプログラム実行制御方法は、コンピュータ上でプログラムの実行を制御する方法であって、前記コンピュータに備わるデバイスドライバ、ライブラリおよびユーザデータのうち前記プログラムのドメインに基づいて決定される範囲のデバイスドライバ、ライブラリおよびユーザデータのフルセット又はサブセットが実行環境内にコピーされることにより作成されることにより、前記実行環境外へのアクセスが制限された実行環境内で動作するプログラムから参照可能に配置され、前記プログラムを前記実行環境内で実行し、
前記プログラムのドメインを、前記プログラムに関連付けられたドメイン情報に基づいて決定し、前記プログラムを含むパッケージに付与されているドメイン情報を取得し、前記プログラムに関連付けられたドメイン情報として使用し、前記取得したドメイン情報を前記プログラムに付与することを特徴とする。

本発明の第２のプログラム実行制御方法は、前記ドメイン情報が付与されたプログラムにデジタル署名を付与し、該付与したデジタル署名をプログラム実行ごとに検証することを特徴とする。

本発明の第１のプログラム実行制御装置は、コンピュータ上でプログラムの実行を制御する装置であって、前記コンピュータに備わるデバイスドライバ、ライブラリおよびユーザデータのうち前記プログラムのドメインに基づいて決定される範囲のデバイスドライバ、ライブラリおよびユーザデータのフルセット又はサブセットが実行環境内にコピーされることにより作成されることにより、前記実行環境外へのアクセスが制限された前記実行環境内で動作するプログラムから参照可能に配置する実行環境作成手段と、前記プログラムを前記実行環境内で実行する実行制御手段と、を具備し、前記実行環境作成手段は、前記プログラムのドメインを、前記プログラムに関連付けられたドメイン情報に基づいて決定し、前記プログラムに関連付けられたドメイン情報として使用するために、前記プログラムを含むパッケージに付与されているドメイン情報を取得するドメイン情報取得手段を有し、前記ドメイン情報取得手段は、前記取得したドメイン情報を前記プログラムに付与することを特徴とする。

本発明の第２のプログラム実行制御装置は、前記ドメイン情報が付与されたプログラムにデジタル署名を付与し、該付与したデジタル署名をプログラム実行ごとに検証する検証手段を有することを特徴とする。

本発明の第１の実行制御プログラムは、コンピュータを、前記コンピュータに備わるデバイスドライバ、ライブラリおよびユーザデータのうち前記プログラムのドメインに基づいて決定される範囲のデバイスドライバ、ライブラリおよびユーザデータのフルセット又はサブセットが実行環境内にコピーされることにより作成されることにより、前記実行環境外へのアクセスが制限された前記実行環境内で動作するプログラムから参照可能に配置する実行環境作成手段、前記プログラムを前記実行環境内で実行する実行制御手段、として機能させ、前記実行環境作成手段は、前記プログラムのドメインを、前記プログラムに関連付けられたドメイン情報に基づいて決定し、前記コンピュータを、さらに、前記プログラムに関連付けられたドメイン情報として使用するために、前記プログラムを含むパッケージに付与されているドメイン情報を取得するドメイン情報取得手段として機能させ、前記ドメイン情報取得手段は、前記取得したドメイン情報を前記プログラムに付与することを特徴とする。

本発明の第１０のプログラム実行制御方法は、第６、第８および第９のうち何れか１つのプログラム実行制御方法において、前記ドメイン情報が付与されたパッケージあるいは前記ドメイン情報が付与されたプログラムに添付されたデジタル証明書またはデジタル署名を検証することを特徴とする。

本発明にあっては、実行環境外へのアクセスが制限された実行環境内で外部から導入または取得されたプログラムを実行するため、実行環境外のユーザデータなどが不正にアクセスされるのを防止でき、信頼できないコードを含むプログラムを安全に実行できる。また、そのプログラムに使用させても差し支えのないデバイスドライバ、ライブラリおよびユーザデータが、実行環境内で動作するプログラムから参照可能に配置してあるため、ＡＰＩコールを通じてしかデバイスドライバやライブラリ等にアクセスできなかった従来技術に比べて、プログラム実行時のオーバーヘッドが低減する。

実行環境内で動作するプログラムから参照可能に配置されるデバイスドライバ、ライブラリおよびユーザデータの範囲を拡大すればするほど、プログラム実行時のオーバーヘッドは低減するが、その反面、システム損傷の危険性が増す。この問題を本発明では、プログラムの素性を表すドメインによって範囲を決定することで解決する。つまり、素性の良い安全性の高いプログラムには多くの範囲を、そうでないプログラムにはまったく割り当てないか、少ない範囲を割り当てる。

プログラムの素性を表すドメインは、例えば、プログラムに関連付けられたドメイン情報に基づいて決定することができる。この場合、外部から導入するプログラム自体に付与されているドメイン情報があればそれを利用し、プログラム自体になくそのパッケージにドメイン情報が付与されていればそれを利用する。また、ドメイン情報が改竄されていると安全性が脅かされるので、デジタル証明書あるいはデジタル署名が付与されていればそれを検証し、問題ないことを確認してから利用する。この検証はプログラムのインストール時に行う。また、プログラム自体にドメイン情報およびデジタル証明書あるいはデジタル署名が付与されている場合、あるいは付与されていなくてもシステムが自動的に付与して、プログラムの起動ごとに検証することで、より安全性が高まる。

プログラムの素性を表すドメインは、上述のように付加されドメイン情報に基づいて決定する以外に、プログラムに関連付けられたデジタル証明書またはデジタル署名の検証結果に基づいて決定することも可能である。

本発明によれば、信頼できないコードを含むプログラムをコンピュータ上で安全かつオーバーヘッド少なく実行することができる。その理由は、実行環境外へのアクセスが制限された実行環境を作成し、コンピュータに備わる、実行環境外部に存在するデバイスドライバ、ライブラリおよびユーザデータの少なくとも一部を実行環境内で動作するプログラムから参照可能に配置し、外部から導入または取得されたプログラムを実行環境内で実行するからである。

図１は、本発明による第１の実施の形態に係わる構成を示すブロック図である。 図２は、本発明による第１の実施の形態におけるインストール動作を示す流れ図である。 図３は、本発明による第１および第２の実施の形態における実行環境作成動作を示す流れ図である。 図４は、本発明による第１および第２の実施の形態におけるアクセス制御動作を示す流れ図である。 図５は、本発明による第１および第２の実施の形態に係わる実行環境の構成を示すブロック図である。 図６は、本発明による第２の実施の形態に係わる構成を示すブロック図である。 図７は、本発明による第２の実施の形態におけるアプリケーションのファイル構成を示す図である。 図８は、本発明による第２の実施の形態におけるアプリケーション起動時の動作を示す流れ図である。 図９は、本発明による第１の実施の形態で使用するドメインごとの実行環境作成内容を示すテーブルの構成図である。 図１０は、本発明による第３の実施の形態に係わる構成を示すブロック図である。 図１１は、本発明の実施例１および実施例２で使用するドメインごとの実行環境作成内容を示すテーブルの構成図である。 図１２は、本発明の実施例３で使用するドメインごとの実行環境作成内容を示すテーブルの構成図である。 図１３は、本発明による第１の実施の形態におけるインストール動作を示すシーケンス図である。 図１４は、本発明による第１の実施の形態における実行環境作成動作を示すシーケンス図である。 図１５は、本発明による第２の実施の形態における実行環境作成動作を示すシーケンス図である。

以下、本発明の好ましい幾つかの実施の形態について、添付の図面を参照して詳細に説明する。

第１の実施の形態：
図１を参照すると、本発明による第１の実施の形態は、クライアント端末１００と、このクライアント端末１００に有線もしくは無線ネットワークで接続されたアプリケーション配信サーバ２００とから構成されている。

クライアント端末１００は、ＣＰＵ１０１と、ＲＡＭ１０２と、ＲＯＭ１０３と、ＨＤＤ１０４と、外部メモリ１０５と、出力装置１０６と、通信装置１０７と、入力装置１０８と、端末システム１１０と、制御手段１２０と、アプリケーション取得手段１３０と、ドメイン情報取得手段１４０と、検証手段１５０と、実行制御手段１６０と、アクセス制御手段１７０と、リソース制御手段１８０と、実行環境作成手段１９０とを含む。各手段１２０〜１９０はクライアント端末１００のユーザ空間内に配置されている。

端末システム１１０は、アプリケーション保存領域１１１と、デバイスドライバ１１２と、ユーザデータ１１３と、ライブラリ（ライブラリプログラム）１１４とを含む。

これらの手段および装置はそれぞれ概略つぎのように動作する。

ＣＰＵ１０１はセントラル・プロセッシング・ユニットであり、各手段やプログラムの実行を制御および計算処理を行う。

ＲＡＭ１０２はランダム・アクセス・メモリであり、読書き可能な記憶装置である。各手段やプログラムの実行時には使用されるデータを読書きする場合に一時的な記憶領域となる。実行コードそのものを一時的に記憶する場合もある。

ＲＯＭ１０３はリード・オンリー・メモリであり、読込みのみ可能な記憶装置である。各手段やプログラムの実行コード、データなどについて記憶する。クライアント端末１の電源をOFFしても記憶されている実行コードおよびデータは消えない。

ＨＤＤ１０４はハード・ディスク・ドライブであり、読書き可能な記憶装置である。ＲＡＭ１０２と比べて読み込みおよび書き込み処理速度は遅いが、大容量であり、クライアント端末１の電源をOFFしても記憶されている実行コードおよびデータは消えない。

外部メモリ１０５はクライアント端末１に脱着可能な読書き可能な記憶装置である。アプリケーション、ライブラリ１１４、ユーザデータ１１３、およびデバイスドライバ１１２などの実行コードやデータなどを外部メモリ１０５に記憶させ、クライアント端末１に装着することでクライアント端末１に実行コードやデータを追加する。

出力装置１０６はクライアント端末１で実行された処理結果をディスプレイに表示したり、音声出力する。

通信装置１０７は、アプリケーション、ライブラリ１１４、ユーザデータ１１３、およびデバイスドライバ１１２などの実行コードやデータを外部と通信してクライアント端末１に取り込む。

入力装置１０８は、新たな処理の実行を依頼するためのキー（ボタン）、音声などにより、情報をクライアント端末１に取り込む。

制御手段１２０は、クライアント端末１００内の各手段を制御し、アプリケーションの取得から、アプリケーションを実行する環境の作成、アプリケーションの実行制御までを行う。

アプリケーション取得手段１３０は、アプリケーション配信サーバ２００もしくは外部メモリ１０５から、アプリケーションを含みドメイン情報とデジタル署名またはデジタル証明書が添付されているパッケージをクライアント端末１００内に取得し、アプリケーション保存領域１１１に格納する。

ドメイン情報取得手段１４０は、アプリケーション取得手段１３０で取得されたパッケージに添付されたドメイン情報を取得する。

検証手段１５０は、アプリケーション取得手段１３０で取得されたパッケージに添付されたデジタル署名やデジタル証明書の検証処理を行う。

実行制御手段１６０は、実行環境作成手段１９０が構築した実行環境内で、アプリケーションの実行及び各種制御を行う。

アクセス制御手段１７０は、アプリケーションが端末システム１１０へアクセスする際に、アプリケーションのドメイン情報に基づいてアクセス制限を行う。

リソース制御手段１８０は、アプリケーションの使用するＲＡＭ１０２、ＨＤＤ１０４、ＣＰＵ１０１といったリソースの使用量を、アプリケーションのドメイン情報に基づいて制限する。

実行環境作成手段１９０は、アプリケーションが動作するための、孤立した実行環境をクライアント端末１１０内に作成する。その際、アプリケーションに添付されたドメイン情報に応じて、端末システム１１０内のデバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４の一部を、そのアプリケーションの実行環境内から直接参照可能にする。なお、実行環境作成手段１９０が実行環境を作成するとは、実際に実行環境を作成するだけでなく、既に作成されている実行環境を選択することも含む概念である。この点は他の実施の形態でも同じである。

次に、図１の構成図及び、図２、図３、図４のフローチャート及び図１３、図１４のシーケンス図を参照して本第１の実施の形態全体における動作について詳細に説明する。

最初に、クライアント端末１００の外部からアプリケーションを取得して、クライアント端末１００内に格納する動作について説明する。

まず、クライアント端末１００内のアプリケーション取得手段１３０は、制御手段１２０の指示により、有線または無線ネットワークを通してアプリケーション配信サーバ２００からアプリケーションを含むパッケージを取得するか、もしくは、外部メモリ１０５からアプリケーションを含むパッケージを取得し、アプリケーション保存領域１１１に保存する（図２のステップＡ１）。次に、ドメイン情報取得手段１４０は、取得されたパッケージに添付されているドメイン情報データから、ドメイン情報を取得する（図２のステップＡ２）。ドメイン情報は、アプリケーションの配布者の種類を特定するための情報である。このように本第１の実施の形態では、クライアント端末１００がアプリケーションを獲得する際には、パッケージ化された１以上のアプリケーションを一度に獲得する。そのパッケージ１つにドメイン情報１つが含まれる。パッケージに１つ含まれるドメイン情報は、そのパッケージに含まれる各アプリケーションのドメイン情報として使用する。

次に、検証手段１５０は、アプリケーションに添付されたデジタル署名及びデジタル証明書の取得を行い（図２のステップＡ３）、その後それらの検証を行う（図２のステップＡ４）。これらの検証により、アプリケーションを含むパッケージ及びそれに添付されたドメイン情報が送信中に改竄されていないことを確認できる。

以上の処理を図１３のシーケンス図を参照して説明すると、まず制御手段１２０はアプリケーション取得手段１３０に対して、アプリケーションの取得を指示する（図１３のステップＥ１）。通信によって端末外部からアプリケーションを取得する場合は、通信装置１０７を利用して（図１３のステップＥ２）、アプリケーション配信サーバ２００よりアプリケーションを含むパッケージを取得する（図１３のステップＥ３）。次に制御手段１２０は、取得したアプリケーションを含むパッケージをアプリケーション保存領域１１１に保存する（図１３のステップＥ４）。このアプリケーション保存領域１１１は、ＲＡＭ１０２、ＨＤＤ１０４、外部メモリ１０５の何れかに獲得されている領域である。次に制御手段１２０は、ドメイン情報取得手段１４０に対してドメイン情報取得指示を出し（図１３のステップＥ５）、ドメイン情報取得手段１４０は、アプリケーション保存領域１１１に保存されたアプリケーションのパッケージに添付されたドメイン情報を取得する（図１３のステップＥ６）。さらに制御手段１２０は、検証手段１５０に指示して（図１３のステップＥ７）、アプリケーション保存領域１１１に保存されたアプリケーションのパッケージに添付されたデジタル署名またはデジタル証明書を取得し（図１３のステップＥ８）、さらに検証手段１５０に指示して（図１３のステップＥ９）、そのデジタル署名またはデジタル証明書の検証処理を行う（図１３のステップＥ１０）。

このようにしてクライアント端末１００外からダウンロードしたアプリケーションを、クライアント端末１００上で実行する場合の動作を、次に説明する。

まず、クライアント端末１００上の制御手段１２０は、実行環境作成手段１９０を用いて、アプリケーションをその中で実行させるための実行環境を作成する（図３のステップＢ１）。実行環境の構成図を図５に示す。

この実行環境３００は、実行環境外部、例えば端末システム１１０の機能や、デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４へのアクセスが制限された環境である。従って、この実行環境３００内でアプリケーション３０１を実行することにより、端末システム１１０の機能やデータをアプリケーション３０１から保護することができる。

さらに実行環境作成手段１９０は、実行環境３００内のアプリケーション３０１からアクセス可能なように、デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４各々の一部もしくは全部を実行環境３００内に配置する（図３のステップＢ２）。図５のデバイスドライバサブセット３０２は、デバイスドライバ１１２に含まれる複数のデバイスドライバのうち、一部分もしくはすべてのデバイスドライバが実行環境３００内に配置されていることを示している。また、ユーザデータサブセット３０３は、ユーザデータ１１３に含まれる複数のユーザデータのうち、一部分もしくはすべてのユーザデータが実行環境３００内に配置されていることを示している。同様にライブラリサブセット１１４は、ライブラリ１１４に含まれる複数のライブラリのうち、一部分もしくはすべてのライブラリが実行環境３００内に配置されていることを示している。

実行環境作成手段１９０は、デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４のどの部分を実行環境３００内に配置するかを、アプリケーション３０１のパッケージに添付されたドメイン情報と、予め設定された管理テーブルとに基づいて決定する。管理テーブルの一例を図９に示す。この管理テーブル４００は、実行環境作成手段１９０が管理し、ＲＡＭ１０２、ＲＯＭ１０３、ＨＤＤ１０４、外部メモリ１０５の何れか、好ましくは不正に書き換えられないように読み込み専用の記憶装置に置かれる。管理テーブル４００には、アプリケーションのドメイン種別ごとに、その実行可否、実行環境および作成可能データサイズに関する情報が記述されている。

図９に例示した管理テーブル４００は、すべてのアプリケーションが、そのパッケージに添付されるドメイン情報によって、ドメインＡ、ドメインＢ、ドメインＣ、ドメインＤの何れかに分類されるものとして作成されている。この管理テーブル４００では、何れのドメインに属するアプリケーションも実行可能となっている。

またドメインＡに属するアプリケーションは、実行環境３００内からデバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４ともすべてアクセス可能となるように、それらのフルセットが実行環境３００内に配置され、作成可能なデータの合計サイズに制限を設けないように設定されている。

またドメインＢに属するアプリケーションは、実行環境３００内からデバイスドライバ１１２とライブラリ１１４はすべてアクセス可能とし、ユーザデータ１１３はその一部のみアクセス可能となるように、デバイスドライバ１１２およびライブラリ１１４のフルセットとユーザデータ１１３のサブセットが実行環境３００内に配置され、作成可能なデータの合計サイズに制限が課せられるように設定されている。

またドメインＣに属するアプリケーションは、実行環境３００内からデバイスドライバ１１２はアクセス不可能で、ユーザデータ１１３とライブラリ１１４に関してはその一部のみアクセス可能となるように、ユーザデータ１１３とライブラリ１１４のサブセットが実行環境３００内に配置され、作成可能なデータの合計サイズには制限が課せられるように設定されている。

またドメインＤに属するアプリケーションは、実行環境３００内からデバイスドライバ１１２とユーザデータ１１３はアクセス不可能で、ライブラリ１１４は一部のみアクセス可能となるように、ライブラリ１１４のサブセットが実行環境３００内に配置され、作成可能なデータの合計サイズにも制限が課せられるように設定されている。これは、最小限アプリケーションの動作に必要なライブラリのみ参照可能とする場合に相当する。

このように実行環境作成時には、アプリケーションが生成する複数データ（ファイル）の合計サイズの上限も図９に示される管理テーブル４００の作成可能データサイズで制限された環境が構築される。

以上の処理を図１４のシーケンス図を参照して説明すると、まず制御手段１２０が実行環境作成手段１９０に対して実行環境の作成指示を出すと（図１４のステップＦ１）、実行環境作成手段１９０はクライアント端末１００上にアプリケーションをその中で実行させるための実行環境３００を作成する（図１４のステップＦ２）。この実行環境３００は、ＲＡＭ１０２、ＨＤＤ１０４、外部メモリ１０５の何れかに作成される。次に制御手段１２０は、実行環境作成手段１９０にデバイスドライバ配置処理、ユーザデータ配置処理、ライブラリ配置処理を順に指示する（図１４のステップＦ３、Ｆ５、Ｆ７）。これらの指示を受けて実行環境作成手段１９０は、デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４それぞれの中から、対象アプリケーションのドメインに対して参照可能であると規定されている部分のみを実行環境３００内に配置し、対象アプリケーションから参照可能となるようにする（図１４のステップＦ４、Ｆ６、Ｆ８）。こうして、図５に示したように、デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４のサブセットを内部に配置した実行環境３００が構築される。

なお、この実行環境作成手段１９０による実行環境３００の作成は、アプリケーションをダウンロードした直後、あるいは、アプリケーションの実行直前に行ってもよい。

実行環境３００の作成後、実行制御手段１６０は、アプリケーション３０１を実行環境３００内で実行させる。実行環境３００内で実行中のアプリケーション３０１の動作について、以下説明する。

実行環境３００内のアプリケーション３０１は、実行環境３００内に配置されたデバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４のセット（フルセットあるいはサブセット）に関しては、自由にアクセスすることができる。一方、実行環境３００外にアクセスする場合、例えば端末システム１１０の機能にアクセスする場合は、アクセス制御手段１８０によってチェックされ（図４のステップＣ１）、許可されればアクセスでき（図４のステップＣ２）、不許可の場合はアクセスできない（図４のステップＣ３）。アクセスの許可、不許可の判断は、アプリケーション３０１に添付されたドメイン情報に応じて決定する。また、アプリケーション３０１が実行する際に使用するＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０４、出力装置１０６、通信装置１０６、入力装置１０８等のクライアント端末１００内のリソースに対しては、リソース制御手段１８０によって使用量の制限が行われる。最大使用量に関しては、アプリケーション３０１に添付されたドメイン情報に応じて決定する。

次に、本第１の実施の形態による効果について説明する。

本第１の実施の形態では、外部から取得したアプリケーションは、クライアント端末１００内のデータや機能に直接アクセスできない、孤立した実行環境３００内で実行されるというように構成されているため、クライアント端末１００内のデータや機能を不正なアクセスから保護しながら、外部から導入または取得されたアプリケーションをクライアント端末１００上で実行できる。

さらに、本第１の実施の形態では、外部から導入または取得されたアプリケーションのパッケージに添付されたドメイン情報に応じて、上記の孤立した実行環境３００内にクライアント端末１００内のユーザデータ１１３やデバイスドライバ１１２、ライブラリ１１４の一部もしくは全部を配置するように構成されているため、アプリケーションのドメインに応じて、外部から導入または取得されたアプリケーションが利用することのできるデータ及び機能の範囲を設定することができる。そして、実行環境３００内に配置されたデバイスドライバ１１２、ユーザデータ１１３およびライブラリ１１４のアプリケーションによるアクセスに関しては、実行環境３００外のデータ及び機能に対する図４のステップＣ１のようなチェック処理が介在しないので、高速なアクセスが可能であり、またチェック処理が介在しないことによりクライアント端末１００のオーバーヘッドが減少する。

また本第１の実施の形態では、ドメイン情報に応じた実行環境３００ごとにアプリケーションが作成できるデータ（ファイル）の合計サイズの上限が設定できる。このことにより、無限にデータファイルを作り続けるような悪意あるアプリケーション、あるいはバグのため同様な不正行為を行うアプリケーションに制限を加えることができるため、他のアプリケーションが使用すべき領域を横取りするような被害を抑えることができる。

第２の実施の形態：
次に、本発明による第２の実施の形態について図面を参照して詳細に説明する。

図６を参照すると、本発明による第２の実施の形態は、クライアント端末１から構成されている。

クライアント端末１は、ＣＰＵ１０１と、ＲＡＭ１０２と、ＲＯＭ１０３と、ＨＤＤ１０４と、外部メモリ１０５と、出力装置１０６と、通信装置１０７と、入力装置１０８と、ユーザデータ１１３と、ライブラリ（ライブラリプログラム）１１４と、アプリケーション１１７と、ＯＳ処理手段１１８と、デバイスドライバ１１２と、実行制御処理手段１１６とを含む。

実行制御処理手段１１６は、制御手段１１６１と、ドメイン情報取得手段１１６２と、検証手段１１６３と、実行許可判断手段１１６４と、アクセス制御手段１１６５と、リソース制御手段１１６６と、実行環境作成手段１１６７とを含む。

ユーザデータ１１３、ライブラリ１１４およびアプリケーション１１７は、クライアント端末１のユーザ空間で動作する。また、ＯＳ処理手段１１８、デバイスドライバ１１２および実行制御処理手段１１６は、クライアント端末１のカーネル空間で動作する。すなわち、実行制御処理手段１１６に含まれる各手段１１６１〜１１６７はＯＳ（オペレーティングシステム）の一部の機能として構成されている。図１の各手段１２０〜１９０がユーザ空間内に構成されている第１の実施の形態とはこの点で相違する。また、本実施の形態では、ドメイン情報およびデジタル署名またはデジタル証明書がアプリケーションごとに添付されている点で、パッケージ単位で添付されている第１の実施の形態と相違する。

これらの手段、装置はそれぞれ概略つぎのように動作する。

ＣＰＵ１０１は、セントラル・プロセッシング・ユニットであり、各手段やプログラムの実行を制御および計算処理を行う。

ＲＡＭ１０２は、ランダム・アクセス・メモリであり、読書き可能な記憶装置である。各手段やプログラムの実行時には使用されるデータを読書きする場合に一時的な記憶領域となる。実行コードそのものを一時的に記憶する場合もある。

ＲＯＭ１０３は、リード・オンリー・メモリであり、読込みのみ可能な記憶装置である。各手段やプログラムの実行コード、データなどについて記憶する。クライアント端末１の電源をOFFしても記憶されている実行コードおよびデータは消えない。

ＨＤＤ１０４はハード・ディスク・ドライブであり、読書き可能な記憶装置である。ＲＡＭ１０２と比べて読み込みおよび書き込み処理速度は遅いが、大容量であり、クライアント端末１の電源をOFFしても記憶されている実行コードおよびデータは消えない。

外部メモリ１０５は、クライアント端末１に脱着可能な読書き可能な記憶装置である。アプリケーション１１７、ライブラリ１１４、ユーザデータ１１３、およびデバイスドライバ１１２などの実行コードやデータなどを外部メモリ１０５に記憶させ、クライアント端末１に装着することでクライアント端末１に実行コードやデータを追加する。

出力装置１０６は、クライアント端末１で実行された処理結果をディスプレイに表示したり、音声出力する。

通信装置１０７は、アプリケーション１１７、ライブラリ１１４、ユーザデータ１１３、およびデバイスドライバ１１２などの実行コードやデータを外部と通信してクライアント端末１に取り込む。

入力装置１０８は、新たな処理の実行を依頼するためのキー（ボタン）であり、音声などにより、情報をクライアント端末１に取り込む。

ＯＳ処理手段１１８はＯＳが行う処理であり、アプリケーション１１７が呼び出すシステムコールの処理を行う。また、このシステムコール処理の中で制御手段１１６１を呼び出す。

制御手段１１６１は、各手段１１６２〜１１６７を制御し、アプリケーション１１７とライブラリ１１４を実行する環境の作成および実行制御を行う。

ドメイン情報取得手段１１６２は、ライブラリ１１４、アプリケーション１１７に関連付けられたドメイン情報を取得する。

検証手段１１６３は、アプリケーション１１７に添付されたデジタル署名やデジタル証明書の検証処理を行う。

実行許可判断手段１１６４は、実行環境作成手段１１６７が構築した実行環境内で、アプリケーション１１７およびライブラリ１１４の実行及び各種制御を行う。

アクセス制御手段１１６５は、アプリケーション１１７がクライアント端末１内の資源へアクセスする際に、アクセス制限を行う。

リソース制御手段１１６６は、アプリケーション１１７やライブラリ１１４が使用するＲＡＭ１０２、ＨＤＤ１０４、ＣＰＵ１０１といったリソースの使用量を、そのアプリケーション１１７のドメイン情報に基づいて制限する。

実行環境作成手段１１６７は、アプリケーション１１７が動作するための、孤立した実行環境をクライアント端末１内に作成する。その際、アプリケーション１１７に添付されたドメイン情報に応じて、クライアント端末１内のデバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４の一部を、実行環境内から参照可能にする。実行環境作成手段１９０は、第１の実施の形態と同様に図９に示すような実行環境作成に関する管理テーブル４００を、ＲＡＭ１０２、ＲＯＭ１０３、ＨＤＤ１０４、外部メモリ１０５の何れかに置いて管理する。また、実行環境作成時にはアプリケーションが生成する複数データ（ファイル）の合計サイズの上限も図９の管理テーブル４００に示される作成可能データサイズで制限された環境が構築される。

次に、図８、図３及び図４のフローチャート、そして図１５のシーケンス図を参照して本第２の実施の形態全体における動作について詳細に説明する。

まず、クライアント端末１は、外部からアプリケーション１１７を取得して、クライアント端末１内に格納する。クライアント端末１は、アプリケーション１１７を外部から獲得する場合、どのような経路であってもよい。通信装置１０７を利用して受信してもよいし、アプリケーション１１７が格納された外部メモリ１０５をクライアント端末１に装着することにより獲得してもよい。さらに、第１の実施の形態に係わる図１のアプリケーション取得手段１３０のようにアプリケーション１１７を取得するための特別な手段は不要である。つまり、アプリケーション１１７が他のアプリケーション１１７をクライアント端末１の外部から取得してもよい。外部から取得するのは、アプリケーション１１７だけでなく、ライブラリ１１４、ユーザデータ１１３も考えられる。取得されたアプリケーション１１７は、ＲＡＭ１０２、ＨＤＤ１０４、外部メモリ１０５などの記憶装置のどこに格納されてもよい。本実施の形態の場合、取得されたアプリケーション１１７にはドメイン情報とデジタル署名またはデジタル証明書とが添付されている。

次に、アプリケーション１１７が起動する場合の動作について図８を参照しながら説明する。

アプリケーション１１７が起動する時は、ＯＳ処理手段１１８により、ＲＡＭ１０２などの記憶領域にそのドメイン情報およびデジタル署名またはデジタル証明書とともにロードされる（図８のステップＤ１）。

ＯＳ処理手段１１８は、このタイミングで制御手段１１６１を呼び出す。制御手段１１６１は、アプリケーション１１７の素性を示すドメイン情報を獲得するためにドメイン情報取得手段１１６２を呼び出す（図８のステップＤ２）。ドメイン情報取得手段１１６２は、アプリケーション１１７に添付されているドメイン情報を取り出す。ドメイン情報は、アプリケーション１１７の配布者の種類を特定するための情報である。もし、ドメイン情報が添付されていない場合、信頼できないドメインに属する配布者によって配布されたものと判断し、そのアプリケーション１１７は、信頼できないドメインに属するものとして扱われる。

次に、検証手段１１６３は、アプリケーション１１７に添付されたデジタル署名またはデジタル証明書を取得する（図８のステップＤ３）。そして検証手段１１６３は、取得したデジタル署名またはデジタル証明書について検証を行う（図８のステップＤ４）。この検証に使用する鍵は、ＲＡＭ１０２、ＲＯＭ１０３、ＨＤＤ１０４、外部メモリ１０５、あるいはＣＰＵ１０１に付属されているような耐タンパ領域、クライアント端末１内の耐タンパ領域に置かれている。この検証により、アプリケーション１１７およびそれに添付されたドメイン情報が改竄されていないことを確認できる。もし、デジタル署名またはデジタル証明書が添付されていない場合、添付されていても検証に失敗した場合、改竄された疑いがあるとして、エラーを返す。

なお、ドメイン情報とデジタル署名またはデジタル証明書は、第１の実施の形態では、複数のアプリケーションを含むパッケージ単位で添付されていたが、この第２の実施の形態では、アプリケーション１１７ごとに添付されている。それらの情報を埋め込んだアプリケーション１１７となるファイルの構成を図７に示す。図７で示すファイル５００は、アプリケーションとなるクライアント端末１上で実行可能なコードである実行コード５０１と、このアプリケーションとなる実行コード５０１が属するドメインの情報となるドメイン情報５０２と、これら実行コード５０１とドメイン情報５０２とを署名した情報となるデジタル署名５０３とで構成されている。この図７では、デジタル署名５０３を添付したファイル５００を例示したが、デジタル署名５０３の代わりにデジタル証明書が添付されたファイルであっても良い。

次に実行許可判断手段１１６４は、アプリケーション１１７に添付されたドメイン情報が示すドメイン種別と図９の管理テーブル４００とに基づいて、アプリケーション１１７の実行を許可するか許可しないかを決定する（図８のステップＤ５）。もし、実行許可を与えられなかった場合は、エラーリターンする。

以上の処理を図１５のシーケンス図を参照して説明すると、アプリケーションがロードされると、制御手段１１６１はアプリケーション１１７の素性を示すドメイン情報を獲得するためにドメイン情報取得手段１１６２を呼び出す（図１５のＧ１）。ドメイン情報取得手段１１６２は、アプリケーション１１７に添付されているドメイン情報を取り出す（図１５のＧ２）。さらに制御手段１１６１は、検証手段１１６３に指示して（図１５のステップＧ３）、アプリケーション１１７からデジタル署名またはデジタル証明書を取得し、さらにその署名または証明書の検証処理を行わせる（図１５のステップＧ４）。次に制御手段１１６１は、実行許可判断手段１１６４にそのアプリケーション１１７を実行させて良いかどうかの判断を依頼する（図１５のＧ５）。

次に、アプリケーション１１１を実行させるための環境作成について、図３および図１５を参照して説明する。

アプリケーション１１７について実行許可判断手段１１６４により実行許可が与えられた後、制御手段１１６１は、実行環境作成手段１１６７を呼び出して（図１５のＧ７）、アプリケーション１１７をその中で実行させるための実行環境を作成する（図３のステップＢ１、図１５のＧ８）。この実行環境は、実行環境外部、例えばデバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４へのアクセスが制限された環境である。従って、この実行環境内でアプリケーション１１７を実行することにより、クライアント端末１の機能やデータをアプリケーションから保護することができる。この実行環境には、図９の管理テーブル４００で示されるドメインごとのアプリケーションが許されている生成可能な領域が確保されている。

さらに実行環境作成手段１１６７は、実行環境内のアプリケーション１１７からアクセス可能なように、デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４の一部もしくは全部を実行環境内に配置する（ステップＢ２）。この実行環境内でアプリケーション１１７は実行することになる。デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４のどの部分を配置するかは、アプリケーション１１７に添付されたドメイン情報と図９に示した管理テーブルとに基づいて決定する。

実行環境作成後、制御手段１１６１、ＯＳ処理手段１１８からリターンし、アプリケーション１１７は正常に起動し、実行を開始する。

次にアプリケーション１１７の実行中に、アクセス制御手段１１６５により特定のデバイスドライバ、ユーザデータまたはライブラリに対するアプリケーション１１７からのアクセスを制限する方法について説明する。

アプリケーション１１７の実行中は、実行環境作成手段１１６７で作成された実行環境内に配置されたデバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４の各セットに関しては、自由にアクセスすることができる。他方、デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４中の実行環境内に配置されていないセットについては、アクセス制御手段１１６５によりアクセス制限がかかる。

たとえば、アプリケーション１１７がデバイスドライバ１１２となる通信装置１０７の制御用デバイスドライバにアクセスしようとしてＯＳ処理手段１１８を呼び出したとする。ＯＳ処理手段１１８は、アクセス許可されているか調べるためにアクセス制御手段１１６５を呼び出す。アクセス制御手段１１６５は、アプリケーション１１７となる元ファイルの置き場所からそのアプリケーション１１７がクライアント端末１にもともと存在するアプリケーションか、外部から獲得したアプリケーションかを判断する。もともと存在するアプリケーションであれば、アクセスを許可し、そうでなければアクセスを許可しない。この結果が戻り値として、制御手段１１６１、ＯＳ処理手段まで戻される。ここで、もしアクセス許可であればＯＳ処理手段１１８は、アプリケーション１１７からの呼び出しに応答して、通信装置１０７の制御用デバイスドライバにアクセスする。他方、不許可であればエラーリターンする。

また、アプリケーション１１７が実行する際に使用するＣＰＵ１０１、メモリ、ＨＤＤ１０４、ネットワーク等のクライアント端末１内のリソースに対しては、リソース制御手段１１６６によって使用量の制限が行われる。最大使用量に関しては、リソース制御手段１１６６において、アプリケーション１１７がクライアント端末１の外部から獲得されたものなのか、そうでないのかに基づいて、リソースにアクセス許可を決定したのと同様に、リソースの最大使用量が決定される。

この第２の実施形態では、アプリケーション１１７についての実行制御について記述したが、ライブラリ１１４にもドメイン情報、デジタル署名またはデジタル証明書を添付することで、アプリケーション１１７と同様な実行制御が可能である。

次に、本第２の実施の形態による効果について説明する。

本第２の実施の形態によれば、第１の実施の形態と同様の効果が得られると共に、以下のような効果が奏される。

本第２の実施の形態によれば、クライアント端末１上で他の何者かによって、アプリケーションが改竄された場合も検知することができる。その理由は、図７に示されるようにドメイン情報５０２およびデジタル署名５０３またはデジタル証明書がアプリケーションとなる実行コード５０１を含む実行ファイル５００ごとに添付されており、かつ、その実行ファイル５００がアプリケーションとして起動するごとにドメイン情報５０２およびデジタル署名５０３またはデジタル証明書による改竄チェックを実施しているからである（図８のステップＤ１〜Ｄ５）。第１の実施の形態では、複数アプリケーションを含むパッケージを展開する際にドメイン情報およびデジタル署名またはデジタル証明書による改竄チェックを一度だけ実施しているため、処理は簡素化される反面、それ以降に改竄されてもチェックできないため、パッケージから展開されたアプリケーションは厳重な管理が必要になる。

また本第２の実施の形態によれば、クライアント端末１は、誰かが外部からアプリケーションを獲得しようとする場合、あらゆる方法で安全に獲得することができる。その理由は、図７に示されるようにドメイン情報５０２およびデジタル署名５０３またはデジタル証明書がアプリケーションとなる実行コード５０１を含む実行ファイル５００ごとに添付されており、かつ、その実行ファイル５００がアプリケーションとして起動するごとにドメイン情報５０２およびデジタル署名５０３またはデジタル証明書による改竄チェックを実施しているからである（図８のステップＤ１〜Ｄ５）。第１の実施の形態では、複数アプリケーションを含むパッケージを展開する際にドメイン情報およびデジタル署名またはデジタル証明書による改竄チェックを一度だけ実施しているため、もし、安全であると思われるクライアント端末１上のアプリケーションが外部の想定外のサーバと通信して、悪意あるアプリケーションを受信し、クライアント端末１上の記憶装置に格納したとすると、その悪意あるアプリケーションのチェックは行えず、何もチェックされないで悪意あるアプリケーションが実行される。よって、第１の実施の形態でのアプリケーションは、信頼できるサーバとのみしか通信させない制御が必要である。または、パッケージを展開して格納されたことが保証されたアプリケーションしか実行させないようにする必要がある。

また本第２の実施の形態によれば、或るアプリケーションから別のアプリケーションを、セキュリティを意識せずに、安全に起動させることが可能である。その理由は、ドメイン情報取得手段１１６２、検証手段１１６３、実行許可判断手段１１６４、実行環境作成手段１１６７がＯＳ機能の一部として存在し、アプリケーション起動時に必ず呼び出されるＯＳ処理手段１１８（システムコール）からそれらすべての手段が呼び出され、起動されるアプリケーションの配布者／素性に応じた実行環境を作成するからである。第１の実施の形態では、各手段がユーザ空間で動作するため、図１のドメイン情報取得手段１４０、検証手段１５０、実行制御手段１６０、実行環境作成手段１９０を持つ特別なアプリケーションでないと、別のアプリケーションを、素性に応じた実行環境を作成して起動することはできない。つまり、第１の実施の形態では、特別なアプリケーション以外のアプリケーションから別のアプリケーションを安全に起動させることはできない。

第３の実施の形態：
次に、本発明による第３の実施の形態について図面を参照して詳細に説明する。

本発明による第３の実施の形態に係わる構成を図１０に示す。第２の実施の形態に係わる構成を示す図６と比べると、クライアント端末１のカーネル空間に存在していたアクセス制御手段１１６５、リソース制御手段１１６６および実行環境構築手段１１６７が削除されていること、アプリケーション配信サーバ２がクライアント端末１に接続されること、およびクライアント端末１のユーザ空間に実行環境構築手段１１５が追加されていることが相違する。

実行環境構築手段１１５は、制御手段１１５１、アプリケーション取得手段１１５２、ドメイン情報設定取得手段１１５３、署名埋込み検証手段１１５４、実行制御手段１１５５、アクセス制御手段１１５６、リソース制御手段１１５７、実行環境作成手段１１５８、アプリケーション保存領域１１５９を含む。

アプリケーション配信サーバ２、制御手段１１５１、アプリケーション取得手段１１５２、実行制御手段１１５５、アクセス制御手段１１５６、リソース制御手段１１５７、実行環境作成手段１１５８は、第１の実施の形態に係わる構成図である図１のアプリケーション配信サーバ２００、制御手段１２０、アプリケーション取得手段１３０、実行制御手段１６０、アクセス制御手段１７０、リソース制御手段１８０、実行環境作成手段１９０と同じものであり、その動作もほぼ同じである。

ドメイン情報設定取得手段１１５３は、第１の実施の形態に係わる構成図である図１のドメイン情報取得手段１４０の機能であるアプリケーションのパッケージからドメイン情報を取り出すだけでなく、そのパッケージを展開して取り出したアプリケーション１１７にドメイン情報を埋め込む機能も合わせ持つ。また、署名埋込み検証手段１１５４は、第１の実施の形態に係わる構成図である図１の検証手段１５０の機能であるアプリケーションのパッケージに添付されるデジタル署名の検証あるいはデジタル証明書を検証する機能だけでなく、そのパッケージを展開して取り出したアプリケーション１１７に新たにデジタル署名またはデジタル証明書を添付する機能を合わせ持つ。

本第３の実施の形態における構成要素のうち、上述した以外の構成要素は、第２の実施の形態における該当する構成要素と同じであり、その動作もほぼ同じである。

以下、本第３の実施の形態における動作を、第１および第２の実施の形態との相違箇所を中心に説明する。

アプリケーション配信サーバ２あるいは外部メモリ１０５からアプリケーション取得手段１１５２が獲得するアプリケーションは、第１の実施の形態と同様に、複数アプリケーションをパッケージ化したアプリケーションパッケージでもよいし、１つのアプリケーションでもよい。

獲得されるのがアプリケーションパッケージの場合は、１つのドメイン情報およびデジタル署名あるいはデジタル証明書がそのパッケージに添付される。さらに、アプリケーションパッケージ内の各アプリケーションには、第２の実施の形態による場合と同様に図７に示されるようにアプリケーション１つにドメイン情報およびデジタル署名あるいはデジタル証明書が添付されていても良いし、添付されていなくても良い。クライアント端末１が獲得するアプリケーションパッケージに含まれる個々のファイルにドメイン情報およびデジタル署名またはデジタル証明書が添付されていない場合、本実施の形態では、アプリケーションパッケージ展開後、個々のファイルにドメイン情報およびデジタル署名またはデジタル証明書が添付される。つまり、アプリケーションパッケージに含まれるドメイン情報をドメイン情報設定取得手段１１５３で取り出しておき、そのパッケージに含まれていたアプリケーション１１７に同じドメイン情報を添付する。その後、そのアプリケーション１１７に対して署名埋め込み検証手段１１５４によりデジタル署名またはデジタル証明書を添付する。

獲得されるのがアプリケーションの場合には、１つのドメイン情報およびデジタル署名あるいはデジタル証明書がそのアプリケーションに添付されている。

アプリケーション１１７の獲得から実行までの動作は、第１の実施の形態と同じである。ただし、第１の実施の形態の動作と異なるのは、アプリケーション実行時にさらにアプリケーションの署名検証を行うことである。つまり、アプリケーションパッケージおよびアプリケーションにデジタル署名が添付されることにより、アプリケーションパッケージを獲得する場合に改竄チェックをおこない、アプリケーション実行時にもう一度改竄チェックを行う。

第１の実施の形態と同様にアプリケーション１１７の獲得から実行までの間に実行環境作成手段１１５８により実行環境を構築しておく。その後、その実行環境内でアプリケーション１１７は実行される。

アプリケーション１１７の起動時には、実行制御処理手段１１６でドメイン情報およびデジタル署名またはデジタル証明書が正しいことを確認する。

なお、図１０では、アクセス制御手段１１５６、リソース制御手段１１５７および実行環境作成手段１１５８がユーザ空間にある実行環境構築手段１１５に含まれているが、これら手段のうちのいくつかは実行環境構築手段１１５に含めるのではなく、カーネル空間の実行制御処理手段１１６に含まれる構成であっても良い。

さらに、図１０では、ドメイン情報設定取得手段１１５３および署名埋込み検証手段１１５４がユーザ空間にある実行環境構築手段１１５に含まれているが、これら手段は、実行環境構築手段１１５に含めるのではなく、カーネル空間の実行制御処理手段１１６に含まれる構成であっても良い。この場合は、ドメイン情報設定取得手段１１５３および署名埋込み検証手段１１５４は、ドメイン情報取得手段１１６２および検証手段１１６３に含まれる。そして、アプリケーションパッケージ展開後に、そのパッケージに含まれる個々のファイルにドメイン情報を埋め込む、あるいは、デジタル署名またはデジタル証明書を添付するといった処理を行う場合は、ユーザ空間にある実行環境構築手段１１５に含まれる制御手段１１５１が、ＯＳ処理手段１１８を経由してカーネル空間にある実行制御処理手段１１６に含まれる制御手段１１６１からドメイン情報取得手段１１６２および検証手段１１６３を呼び出すことで実現する。

次に、本第３の実施の形態による効果について説明する。

本第３の実施の形態によれば、第１および第２の実施の形態と同様の効果が得られると共に、以下の効果が奏される。

本第３の実施の形態では、アプリケーションを含むパッケージに付与されているドメイン情報をそのアプリケーションに付与し、ドメイン情報を付与したアプリケーションに新たにデジタル署名またはデジタル証明書を付与し、アプリケーションの起動時にアプリケーションに付与されているデジタル署名またはデジタル証明書を検証するようにしているので、ドメイン情報が付与されているパッケージに添付されているデジタル署名またはデジタル証明書をプログラムのインストール時のみ検証する第１の実施の形態に比べて、より安全にプログラムを実行することが可能になる。

第４の実施の形態：
次に、本発明による第４の実施の形態について図面を参照して詳細に説明する。

第１〜第３の実施の形態では、アプリケーション実行時（起動時）のオーバーヘッドを軽減するために、実行環境構築のための処理をアプリケーション実行前に行っている。これに対して本実施の形態は、アプリケーションの起動後、速やかにアプリケーションの実行を中断してアプリケーションの実行環境を構築し、この構築した実行環境内でアプリケーションの実行を再開させる。

本第４の実施の形態は、第３の実施の形態と同様に図１０に示す構成を有しており、実行制御処理手段１１６の呼び出し順序と実行環境作成手段１１５８の呼び出し順序が第３の実施の形態における場合と逆転している。ここで、アプリケーション１１７はアプリケーション取得手段１１５２で獲得されても良いし、他の方法で獲得しても良い。つまり、どのような方法で獲得されてもよい。また、アプリケーション保存領域１１５９に保存しなくてもよい。アプリケーション１１７にはドメイン情報およびデジタル署名あるいはデジタル証明書が添付されていればよい。

実行制御手段１１５５により、あるいはその他の手段によりアプリケーション１１７が起動されると、直ちに、ＯＳ処理手段１１８を経由してカーネル空間にある実行制御処理手段１１６に含まれる制御手段１１６１からドメイン情報取得手段１１６２および検証手段１１６３を呼び出す。これらの動作により、アプリケーション１１７のドメイン情報を獲得し、署名検証あるいは証明書検証が完了し、アプリケーション１１７の完全性が確認される。

ドメイン情報が実行制御処理手段１１６で獲得されると、一旦、ユーザ空間の手段により処理を続ける。ＯＳ処理手段１１８を経由して、ユーザ空間に存在する制御手段１１５１、そして、実行環境作成手段１１５８が呼び出される。このとき、ドメイン情報も渡される。そして、実行環境作成手段１１５８によりドメイン情報に対応する実行環境が構築される。その後、アプリケーション１１７は正常に起動し、実行を続ける。

このことにより、カーネル空間では、ドメイン情報の獲得とデジタル署名あるいはデジタル証明書の検証に関する処理のみ行い、残りの処理は、その後ユーザ空間で行うことになる。

なお、ドメイン情報取得手段１１６２は、カーネル空間から削除し、その代わり、ユーザ空間のドメイン情報設定取得手段１１５３がドメイン情報の取得を行っても良い。この場合、カーネル空間では、アプリケーション１１７に添付されたデジタル署名あるいはデジタル証明書の検証のみを行う。

以上の各実施の形態では、アプリケーションパッケージまたはプログラムに付加されているドメイン情報に基づいてプログラムのドメインを決定したが、本発明はこのようなドメイン決定方法に限定されず、他の方法によってプログラムのドメインを決定しても良い。他の方法の一例として、アプリケーションパッケージまたはプログラムにデジタル証明書またはデジタル署名が付与されている場合に、そのデジタル証明書またはデジタル署名の検証結果に基づいて当該プログラムのドメインを決定する方法がある。より具体的には、付与されているデジタル証明書またはデジタル署名に対する検証を、それぞれのドメインに予め対応付けられているroot証明書または公開鍵を順番に使用して行い、その検証に成功（正常終了）したroot証明書または公開鍵に対応するドメイン、および何れのroot証明書または公開鍵を用いても検証に成功しない場合に対応するドメインを、当該プログラムのドメインとするものである。

次に、具体的な実施例を用いて本発明による実施の形態の構成と動作をより詳しく説明する。

まず、第１の実施の形態に基づく実施例を実施例１として、図１の構成図を用いて説明する。なお、ドメインごとの実行環境の構築方法を示す管理テーブル４００の具体例として、図１１に示す管理テーブル４０１を使用する。本実施例１では、図１１の内容をもとに実行環境が構築される。

本実施例１において、クライアント端末１００の外部から、アプリケーションをクライアント端末１００にインストールする場合の処理の流れは、次のようになる。

外部のアプリケーションは、図１に示すように、有線もしくは無線のネットワークで接続されたアプリケーション配信サーバ２００上、もしくは、外部メモリ１０５内に配置されているとする。外部メモリ１０５としては、SDカード、コンパクトフラッシュ（登録商標）等の取り外し可能なメモリカードが想定される。

ここで取り扱うアプリケーションの形態としては、単一のファイルのみからなる場合、複数のファイル群、例えば実行ファイルと実行に必要な各種設定ファイル、データ類からなる場合、複数のファイル群を一般のデータアーカイブソフトウェア（例えばzip，tar等と呼ばれるソフトウェア類）によって一つのファイルとしてパッケージ化したもの等が想定される。

また、本実施例１では、外部のアプリケーションは、そのアプリケーションのドメイン情報を記した情報ファイルを含む。本実施例では、複数のファイル群を一つのファイルとしてパッケージ化した、アプリケーションパッケージの形態でアプリケーションが配布されるとし、このドメイン情報ファイルは、一つのアプリケーションパッケージに対して一つ含まれるものとする。

ドメイン情報には、アプリケーションの所属を分類するための情報が含まれ、この所属によって、作成する実行環境を制御すると共に、後述するアクセス制御やリソース制御の範囲、制限の度合いを変更する。この所属の記述内容に関しては、例えばアプリケーション作成者の属する企業名を使用することも可能であるし、また、クライアント端末１００が携帯電話である場合に、図１１のように携帯電話キャリア、携帯電話ベンダ、信頼できるサードベンダ、それ以外の信頼できないベンダ、といった組織の種類に合わせた分類を行い、これを利用することも可能である。また、ドメイン情報を記した情報ファイルの形式の一例として、一般的なデジタル証明書を利用することが考えられる。デジタル証明書の形式としては、例えばX.509形式が広く利用されている。デジタル証明書を利用することで、そこに記載されたドメイン情報は信頼できる認証機関によって保証されることになる。

さらに本実施例１が対象とする外部アプリケーションには、一般的なデジタル署名を添付して送付することも可能である。デジタル署名を添付することで、ネットワークでの配信途上等におけるアプリケーションファイルの改竄を検出することが可能である。デジタル署名の形式としては、例えばＳＨＡ−１(Secure
Hash Algorithm 1)等のハッシュアルゴリズ
ムを利用したアプリケーションパッケージファイルのハッシュデータを、アプリケーション配布者が保持している秘密鍵によって暗号化したものを署名データとして利用するといった手法が広く使われている。アプリケーション配布者が保持している秘密鍵と、アプリケーションに添付された証明書に含まれる公開鍵は対応しており、この証明書に含まれる公開鍵を利用することで暗号化された署名データを復号化することが可能である。

本実施例１では、これらのデジタル証明書もしくはデジタル署名を添付する場合に関しても、アプリケーションパッケージに対してそれぞれ一つ添付されることを想定している。クライアント端末１００上の制御手段１２０は、アプリケーション取得手段１３０を用いて、このような形式の外部アプリケーション及び添付されたドメイン情報、証明書、デジタル署名ファイル等を、有線または無線ネットワークによって接続されたアプリケーション配信サーバ２００から取得するか、もしくは、外部メモリ１０５から取得し、クライアント端末１００内部のアプリケーション保存領域１１１に保存することで、外部から端末内にアプリケーションを取得する（図２のステップＡ１）。保存されたアプリケーションパッケージは展開され、アプリケーションとなるファイルとして格納される。なお、それぞれのファイルにドメイン情報が関連付けられる。

その後、ドメイン情報取得手段１４０を用いて、アプリケーションパッケージに含まれたドメイン情報ファイルからドメイン情報を取得する（図２のステップＡ２）。次に、検証手段１５０を用いて、アプリケーションに添付されたデジタル証明書または署名の取得を行い（図２のステップＡ３）、その後それらの検証を行う（図２のステップＡ４）。これによって、アプリケーションに添付されたドメイン情報の正しさ及び、アプリケーションファイルが改竄されていないことのチェックが行える。

以上の処理により、クライアント端末１００外部から、アプリケーションを端末にインストールする処理が完了する。

次に、クライアント端末１００上での、外部から取得したアプリケーションの実行について説明する。

制御手段１２０は、アプリケーション保存領域１１１に格納された、外部から取得したアプリケーションを実行する前に、まず実行環境作成手段１９０を用いて、アプリケーションの実行環境を作成する（図３のステップＢ１）。ここで作成するアプリケーションの実行環境とは、クライアント端末１００内の保護すべきメモリ空間、ディスク、ライブラリ、デバイスドライバといった各種資源、機能から切り離された、孤立した環境であり、この中で実行されるアプリケーションは、それらの資源、機能に自由にアクセスすることはできない。これによって、外部から取得したアプリケーションが、不正にクライアント端末１００内のデータや機能にアクセスしたり、他のアプリケーションの動作を妨害することを防ぐことができる。

またこの実行環境には、クライアント端末１００上のファイルシステムとは別の、独立したファイルシステムを準備して割り当て、またこのファイルシステムは、ドメインに応じて許可されているサイズで作成する。このような独立した実行環境やファイルシステムを実現させる手段の例としては、まず、クライアント端末１００上のＯＳ、ファイルシステム上に、別のアプリケーション実行環境や、ファイルシステムを構築するというやり方がある。これは、クライアント端末１００のＯＳ（ホストＯＳと呼ばれる）上のアプリケーションとして、別のＯＳ（ゲストＯＳと呼ばれる）を動作させ、ゲストＯＳ上で外部アプリケーションを動作させるというものであり、Ｊａｖａ（登録商標）ＶＭや、Use
Mode Linux（ＵＭＬ＝LinuxＯＳ上で他のLinuxＯＳを動かす技術）等と呼ばれる技術は、その一例である。また、別のファイルシステムを構築するやり方の一例としては、ＵＮＩＸ（登録商標）などにおけるコマンドであるchrootを使って、外部アプリケーションから参照可能なディレクトリを、ファイルシステム全体の一部分のみに限定してしまうという方法も考えられる。他の例としては、複数のプロセッサを持つマルチプロセッサ環境において、プロセッサＡにはクライアント端末１００の基本システムおよびＯＳを動作させ、別のプロセッサＢ上でもう一つ別のＯＳを動作させるというものが考えられる。この場合、プロセッサＢで動作するＯＳ上の環境を、基本システムが動作する環境とは別の、独立した実行環境とみなし、ここで外部アプリケーションを動作させる。

図１１に示す管理テーブル４０１に設定されているドメインごとの作成可能なデータサイズの値に従えば、携帯電話キャリアには、別個のファイルシステムを構築しないで、ベースとなるクライアント端末１００上のファイルシステムをそのまま使用して制限なしにデータ（ファイル）を作成することができるようにする。携帯電話ベンダ、信頼できるサードベンダ、そして、信頼できないベンダには、それぞれ１Ｍbyte、３００Ｋbyte、１０Ｋbyteのデータが作成可能な領域が得られるファイルシステムが作成される。

さらに実行環境作成手段１９０は、アプリケーションのドメイン情報に応じて、上述のように作成したアプリケーションの実行環境内に、デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４の一部もしくは全部を配置する（図３のステップＢ２）。

本実施例１では、デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４等は、クライアント端末１００内の端末システム１１０内で、それぞれ複数のディレクトリで構成されているとする。ユーザデータ１１３を例にすると、電話帳データ、メールアドレスデータ、画像データといったデータ種別ごとに、それぞれ異なるディレクトリに格納されている。従ってユーザデータの一部を配置するという処理は、これらのディレクトリの一部を配置するということである。

配置後の実行環境を示す図５に示されるように、アプリケーションの実行環境３００内にデバイスドライバサブセット３０２、ユーザデータサブセット３０３およびライブラリサブセット３０４を配置することで、実行環境３００内で動作するアプリケーション３０１は、ここで配置された範囲内のデバイスドライバ、ユーザデータ、ライブラリを参照及び利用することが可能となる。

デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４に関して、どれだけの範囲を実行環境内に配置するかは、アプリケーションに関連付けられたドメイン情報と図１１に示した管理テーブル４０１とによって決定する。例えばドメイン情報を、先に述べたように携帯電話キャリア、携帯電話ベンダ、信頼できるサードベンダ、それ以外の信頼できないベンダといった４種類に分類した場合は、携帯電話キャリア、携帯電話ベンダに関しては全ての範囲のデバイスドライバ、ユーザデータ、ライブラリを実行環境内に配置し、信頼できないベンダには一切配置しない、また、信頼できるサードベンダに対しては、これらの一部を配置する、といった処理を行う。これはベースとなるファイルシステム上にデバイスドライバ、ユーザデータ、ライブラリのフルセットあるいはサブセットが置かれたディレクトリを用意し、参照可能とするといったことで実現可能である。図１１の実行環境の欄にある/dev,/bin,/lib,/usr,/etcなどを実行環境内にディレクトリとして作成し、そのディレクトリにベースとなるファイルシステム上のデバイスドライバ、ユーザデータ、ライブラリのフルセットあるいはサブセットのディレクトリをドメインに応じて参照可能にすれば実行環境内にドメインに応じたデバイスドライバ、ユーザデータ、ライブラリを配置することが可能である。また、場合によっては、デバイスドライバ、ユーザデータ、ライブラリのフルセット、あるいは、サブセットを実行環境内にコピーして配置することもあり得る。

実行環境を作成した後は、制御手段１２０は実行制御手段１６０を使って、この実行環境３００内でアプリケーション３０１を実行させる。Linux上などでアプリケーション３０１を実行した場合は、プロセスとして実行される。このプロセスを一意に識別する識別子と、アプリケーションに関連付けられたドメイン情報を関連付けておく。

実行環境３００内で動作しているアプリケーション３０１は、この実行環境３００内に配置されたデバイスドライバ、ユーザデータ、ライブラリに関しては自由にアクセス可能であるが、実行環境外の、端末システム１１０の各種機能（例えば表示機能や通信機能）や、端末システム１１０内のデバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４へのアクセスは、アクセス制御手段１７０によって制限される。

アクセス制御手段１７０がアクセスを制限する具体的な手法の一例としては、これらのアクセスを行うために端末システム１１０に用意されたＡＰＩ内にチェック関数を埋め込み、各ＡＰＩが呼び出された際にこのチェック関数がアクセス制御手段１７０にアクセス可否を問い合わせ、許可されたのみＡＰＩ呼出しを実行するという手法が挙げられる。

アクセス制御手段１７０によるアクセス制限に関しても、アプリケーション３０１に関連付けられたドメイン情報に応じて制限の範囲を変えることも可能である。この場合、プロセス識別子から関連付けられたドメイン情報を取得して利用する。例えば、携帯電話キャリア、携帯電話ベンダに関しては全ての機能およびデータへのアクセスを許可し、信頼できないベンダには一切許可しない、また、信頼できるサードベンダに対しては、これらの一部を許可するといったことも可能である。

また同時に、実行環境３００内で動作しているアプリケーション３０１の、クライアント端末１００及び端末システム１１０内のハードウェア及びソフトウェア資源の使用量を、リソース制御手段１８０によって制限する。クライアント端末１００及び端末システム１１０内の資源としては、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ１０４、通信装置１０７や、端末画面に表示するウインドウの数などがある。

次に、第２の実施の形態に基づく実施例を実施例２として、図６の構成図を用いて説明する。なお、ドメインごとの実行環境の構築方法を示す管理テーブル４００の具体例として、図１１に示す管理テーブル４０１を使用する。本実施例２では、図１１の内容をもとに実行環境が構築される。また、クライアント端末１に搭載されるＯＳはLinuxとする。

本実施例２において、クライアント端末１の外部から、アプリケーション１１７をクライアント端末１に持ち込む場合は、次のようになる。

まず、クライアント端末１は、外部からアプリケーション１１７を取得して、クライアント端末１内に格納する。クライアント端末１は、アプリケーション１１７を外部から獲得する場合、どのような経路であってもよいし、どのような方法であってもよい。通信装置１０７を利用して外部のサーバからアプリケーション１１７を受信してもよいし、アプリケーション１１７を格納した外部メモリ１０５をクライアント端末１に装着することにより獲得してもよい。第１の実施の形態に係わる図１のアプリケーション取得手段１３０のようにアプリケーション１１７を取得するための特別な手段は不要である。つまり、アプリケーション１１７が他のアプリケーション１１７をクライアント端末１の外部から取得してもよい。外部から取得するのは、アプリケーション１１７だけでなく、ライブラリ１１４、ユーザデータ１１３も考えられる。取得されたアプリケーション１１７はＲＡＭ１０２、ＨＤＤ１０４、外部メモリ１０５などの記憶装置のどこに格納されてもよい。

次に、アプリケーション１１７が起動する場合の動作について図８を参照しながら説明する。

アプリケーション１１７が起動する時は、ＯＳ処理手段１１８により、ＲＡＭ１０２などの記憶領域にアプリケーション１１７となる実行ファイルの内容がロードされる。この場合、Linuxでは、execシステムコールが呼び出される。この時にＯＳ処理手段１１８が呼び出される（図８のステップＤ１）。

ＯＳ処理手段１１８は、呼び出されると速やかに制御手段１１６１を呼び出す。制御手段１１６１は、アプリケーション１１７の素性を示すドメイン情報を獲得するためにドメイン情報取得手段１１６２を呼び出す。ドメイン情報取得手段１１６２は、アプリケーション１１７に添付されているドメイン情報を取り出す。もし、ドメイン情報が添付されていない場合、信頼できないベンダによって配布されたものと判断し、そのアプリケーション１１７は、ドメインとして信頼できないベンダに属するものとして扱われる。

ドメイン情報は、アプリケーション１１７の配布者の種類を特定するための情報であり、例えば図１１の管理テーブル４０１の場合は携帯電話キャリア、携帯電話ベンダ、信頼できるサードベンダ、信頼できないベンダといったような種類の情報である。作者名（企業名）の情報が付け加えられてもよい。これらドメイン情報は、文字列による平文、または暗号化されたものを実行ファイル内の最後に添付する。

さらに、一般的なデジタル署名を添付させることも可能である。デジタル署名を添付することで、ネットワーク上での配信途上、クライアント端末１に格納された後でのアプリケーション１１７となる実行ファイルの改竄が検出可能となる。デジタル署名の形式として、例えば、ＳＨＡ−１(Secure
Hash Algorithm 1)等の一方向ハッシュアルゴリズムを使用したアプリケーション１１７のハッシュデータを、アプリケーション配布者が保持している秘密鍵によって暗号化されたものを署名データとして利用するといった手法が広く使われている。

また、このドメイン情報を記した一般的なデジタル証明書を利用することも考えられる。たとえば、X.509形式が広く利用されている。デジタル証明書を利用することで、そこに記載されたドメイン情報は信頼できる認証機関によって保証されることになる。さらに、この証明書にデジタル署名を添付することもありえる。アプリケーション配布者が保持している秘密鍵と、アプリケーションに添付された証明書に含まれる公開鍵は対応しており、この証明書に含まれる公開鍵を利用することで暗号化された署名データを復号化することが可能である。

次に、検証手段１１６３がアプリケーション１１７に添付されたデジタル署名またはデジタル証明書の検証を行う。この検証により、アプリケーション１１７が改竄されていないことを確認できる。もし、デジタル署名またはデジタル証明書が添付されていない、改竄された疑いがあるなど、検証に失敗した場合、エラーを返す（図８のステップＤ３）。署名検証に用いられる、配布者が保持している秘密鍵に対応する公開鍵は、検証手段１１６３が予め保持しておいてもよいし、証明書を利用する場合は、その証明書内に公開鍵を含み、その公開鍵を利用しても良い。また、検証手段１１６３が予め公開鍵を保持しておく場合、すべてのドメインに共通な公開鍵１つを保持しておく方法と、ドメインごとに公開鍵を保持しておく方法が考えられる。例えばドメインが４つあれば公開鍵も４つ保持することになる。このように複数の公開鍵を保持しておく場合は、アプリケーション１１７に含まれるドメイン情報に対応する公開鍵を指定して改竄チェックを行う必要がある。

なお、ドメイン情報とデジタル署名またはデジタル証明書は、実施例１では、複数のアプリケーションを含むパッケージ単位で添付されていたが、本実施例２では、アプリケーション１１７ごとに添付されている。アプリケーション１１７となる、それら情報を埋め込んだファイルの構成を図７に示す。この図７では、デジタル証明書ではなく、デジタル署名５０３を添付したファイル５００を示している。

アプリケーション１１７がどのドメインに属するか決定した後、実行許可判断手段１１６４がそのアプリケーション１１７を実行させて良いかどうかの判断を下す。実行許可判断手段１１６４は、アプリケーション１１７に添付されたドメイン情報に応じて実行を許可するか許可しないかといった決定を行う。もし、実行許可を与えられなかった場合は、エラーリターンする（図８のステップＤ４）。

この実行を許可するか否かの判断は、図１１で示される管理テーブル４０１を参照して判断される。図１１の管理テーブル４０１に従えば、アプリケーション１１７から取り出した、ドメイン情報が携帯端末ベンダであれば、クライアント端末１上での実行を許可する。なお、この図１１に示すような管理テーブル４０１は、クライアント端末１の使用する用途により柔軟に変更される可能性がある。

次に、アプリケーション１１１を実行させるための環境の作成について説明する。

アプリケーション１１７は、実行許可判断手段１１６４により実行許可が与えられた後、実行環境作成手段１１６７を用いて、アプリケーション１１７をその中で実行させるための実行環境を作成する。

またこの実行環境には、クライアント端末１上のファイルシステムとは別の、独立したファイルシステムを準備して割り当て、またこのファイルシステムは、ドメインに応じて許可されているサイズで作成する。このような独立した実行環境やファイルシステムを実現させる手段の例としては、実施例１の説明箇所で述べたように、クライアント端末１上のＯＳ、ファイルシステム上に、独自のアプリケーション実行環境やファイルシステムを構築するというやり方や、マルチプロセッサ環境において、クライアント端末１の基本システムおよびＯＳが動作するプロセッサとは別のプロセッサ上に、外部アプリケーション専用のＯＳやファイルシステムを用意するというやり方等がある。

図１１に示すドメインごとの作成可能なデータサイズの値に従えば、携帯電話キャリアには、別個のファイルシステムを構築しないで、ベースとなるクライアント端末１００上のファイルシステムをそのまま使用して制限なしにデータ（ファイル）を作成することができるようにする。携帯電話ベンダ、信頼できるサードベンダ、そして信頼できないベンダには、それぞれ１Ｍbyte、３００Ｋbyte、１０Ｋbyteのデータが作成可能な領域が得られ
るファイルシステムが作成される。

この実行環境は、実行環境外部、例えばデバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４へのアクセスが制限された環境である。従って、この実行環境内でアプリケーション１１７を実行することにより、クライアント端末１の機能やデータをアプリケーションから保護することができる。

ここで作成する実行環境は、クライアント端末１のデバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４といった各種資源、機能から切り離された、孤立した環境であり、この中で実行されるアプリケーション１１７は、それらの資源、機能に自由にアクセスすることはできない。これによって、外部から取得したアプリケーション１１７が、不正にクライアント端末１内のデータや機能にアクセスしたり、他のアプリケーション１１７の動作を妨害することを防ぐことができる。環境構築に関しては、Linuxを用いたシステムでは、ユーザ空間のコマンドとしてmkdirおよびchrootコマンドを用いることが知られている。本実施例２では、これらコマンドと同等機能をカーネル空間で実行環境作成手段１１６７によって実行することで実現可能である。

さらに実行環境作成手段１１６７は、実行環境内のアプリケーションからアクセス可能なように、デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４の一部もしくは全部を実行環境内に配置する。デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４のどの部分を配置するかは、アプリケーション１１７に添付されたドメイン情報と図１１の管理テーブル４０１とに応じて決定する（ステップＢ２）。

本実施例２では、デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４等は、クライアント端末１内で、それぞれ複数のディレクトリで構成されているとする。ユーザデータ１１３を例にすると、電話帳データ、メールアドレスデータ、画像データといったデータ種別ごとに、それぞれ異なるディレクトリに格納されている。従ってユーザデータの一部を配置するという処理は、これらのディレクトリの一部を実行環境内に参照可能なように配置するということである。本実施例２では、この配置機能をカーネル空間で実行環境作成手段１１６７によって実行することで実現可能である。

実行環境内にこれらを配置することで、実行環境内で動作するアプリケーション１１７は、ここで配置された範囲内の各資源を参照及び利用することが可能となる。デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４に関して、どれだけの範囲を実行環境内に配置するかは、アプリケーション１１７に添付されたドメイン情報と図１１の管理テーブル４０１とによって決定する。

配置後の実行環境を示す図５のように、実行環境３００内にデバイスドライバサブセット３０２、ユーザデータサブセット３０３およびライブラリサブセット３０４を配置することで、実行環境３００内で動作するアプリケーション３０１は、ここで配置された範囲内のデバイスドライバ、ユーザデータ、ライブラリを参照及び利用することが可能となる。

デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４に関して、どれだけの範囲を実行環境３００内に配置するかは、アプリケーション３０１に関連付けられたドメイン情報によって決定する。例えばドメイン情報を、先に述べたように携帯電話キャリア、携帯電話ベンダ、信頼できるサードベンダ、それ以外の信頼できないベンダといった４種類に分類した場合は、携帯電話キャリア、携帯電話ベンダに関しては全ての範囲のデバイスドライバ、ユーザデータ、ライブラリを実行環境内に配置し、信頼できないベンダには一切配置しない、また、信頼できるサードベンダに対しては、これらの一部を配置する、といった処理を行う。ベースとなるファイルシステム上にデバイスドライバ、ユーザデータ、ライブラリのフルセットあるいはサブセットが置かれたディレクトリを用意し、実行環境内から参照可能とすることで実現可能である。図１１の実行環境の欄にある/dev,/bin,/lib,/usr,/etcなどを実行環境内にディレクトリとして作成し、そのディレクトリにベースとなるファイルシステム上のデバイスドライバ、ユーザデータ、ライブラリのフルセットあるいはサブセットのディレクトリをドメインに応じて参照可能にすれば実行環境内にドメインに応じたデバイスドライバ、ユーザデータ、ライブラリを配置することが可能である。また、場合によっては、デバイスドライバ、ユーザデータ、ライブラリのフルセット、あるいは、サブセットを実行環境内にコピーして配置することもありえる。

実行環境作成後、制御手段１１６１およびＯＳ処理手段１１８からリターンし、アプリケーション１１７は正常に起動し、実行を開始する。

次にアプリケーション１１７の実行中に、アクセス制御手段１１６５により各種資源へのアプリケーション１１７からのアクセスを制御する方法を説明する。このアクセス制御手段１１６５は、アプリケーション１１７が実際に資源へアクセスする場合に動作する。実行環境作成手段１１６７によりデバイスドライバ、ユーザデータおよびライブラリなどの資源へのアクセス制御はすでに実施されているが、アクセス制御手段１１６５により、さらに細かくアクセス制御することが可能となる。

アプリケーション１１７の実行中は、実行環境作成手段１１６７で作成された実行環境内に配置されたデバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４に関しては、自由にアクセスすることができる。ただし、デバイスドライバ１１２、ユーザデータ１１３、ライブラリ１１４の中でクライアント端末１の外部から獲得したアプリケーション１１７にアクセスさせたくないものが存在すれば、アクセス制御手段１１６５によりアクセス制限される。

たとえば、アプリケーション１１７がデバイスドライバ１１２となる通信装置１０７の制御用デバイスドライバにアクセスしようとしてＯＳ処理手段１１８を呼び出す。ＯＳ処理手段１１８は、アクセス許可されているか調べるためにアクセス制御手段１１６５を呼び出す。アプリケーション１１７からデバイスドライバ１１２にアクセスするには、Linux上では、open,
close, read, writeなどのシステムコールを呼び出す。この時にＯＳ処理手段１１８が呼び出される。アクセス制御手段１１６５は、アプリケーション１１７となる元ファイルの置き場所からそのアプリケーション１１７がクライアント端末１にもともと存在するものなのか、外部から獲得したものなのか判断する。もともと存在するものであれば、アクセスを許可し、そうでなければアクセスを許可しない。この結果を戻り値として、制御手段１１６１およびＯＳ処理１１２手段までもどる。ここで、もしアクセス許可であればＯＳ処理手段１１８は、通信装置１０７の制御用デバイスドライバにアクセスし、そうでなければエラーとする。

つまり、ある資源に関して、クライアント端末１にもともと存在しているアプリケーション１１７については、アクセス制御手段１１６５により予めアクセス許可の設定をしておき、クライアント端末１の外部から獲得したアプリケーション１１７に関してはアクセスを不許可といった設定にしておく。これらを実現する方法として、LinuxではＳＥLinuxが知られている。クライアント端末１にＯＳとしてLinuxを採用する場合、システム構築時にＳＥLinuxのポリシーファイルにおいて、アクセス設定の対象となるある資源について、デフォルトでアクセス禁止としておき、クライアント端末１内の既存アプリケーション１１７についてだけアクセス許可を与えるといった設定をしておくことで容易に実現可能である。

また、アプリケーション１１７が実行する際に使用するＣＰＵ101、メモリ、ＨＤＤ１０４、ネットワーク等のクライアント端末１内のリソースに対しては、リソース制御手段１１６６によって使用量の制限が行われる。最大使用量に関しては、リソース制御手段１１６６が、「アプリケーション１１７がクライアント端末１の外部から獲得されたものなのか。」、「そうでないのか。」でリソースにアクセス許可を決定したのと同様に、リソースの最大使用量が決定される。

次に、第３の実施例を説明する。本実施例では、ドメインごとの実行環境構築に関するテーブルは、図１２の管理テーブル５０１で示される内容を用いる。第１の実施例および第２の実施例では、図１１に示すテーブル４０１を使用した。本実施例の処理内容は、第１の実施例および第２の実施例と同じであり、図１１と図１２とのテーブル内容に相違があるだけである。つまり、図１１の信頼できないベンダに属するアプリケーションは実行可能であり、実行環境として/bin,/libサブセット、そして、生成可能なデータ（ファイル）のサイズは１０Ｋbyteが許されていた。これに対して図１２では、信頼できないベンダに属するアプリケーションは、実行許可が与えられておらず、また、実行環境およびデータ（ファイル）作成も不可能である。このように管理テーブルの内容を書き換えることで、ドメインごとの実行環境構築方法が変更される。つまり、本実施例３は、図１１および図１２に示すテーブルの内容を書き換えることで、実行環境の構築方法を柔軟に変更することができる利点を示している。

本発明は、クライアント端末に外部からアプリケーションをダウンロードして安全に実行する実行制御装置や、外部アプリケーションのダウンロード及び実行制御装置をコンピュータに実現するための実行制御プログラムといった用途に適用することができる。

Claims (6)

1. コンピュータ上でプログラムの実行を制御する方法であって、前記コンピュータに備わるデバイスドライバ、ライブラリおよびユーザデータのうち前記プログラムのドメインに基づいて決定される範囲のデバイスドライバ、ライブラリおよびユーザデータのフルセット又はサブセットが実行環境内にコピーされることにより作成されることにより、前記実行環境外へのアクセスが制限された前記実行環境内で動作するプログラムから参照可能に配置され、前記プログラムを前記実行環境内で実行し、
   前記プログラムのドメインを、前記プログラムに関連付けられたドメイン情報に基づいて決定し、
   前記プログラムを含むパッケージに付与されているドメイン情報を取得し、前記プログラムに関連付けられたドメイン情報として使用し、
   前記取得したドメイン情報を前記プログラムに付与することを特徴とするプログラム実行制御方法。
2. 前記ドメイン情報が付与されたプログラムにデジタル署名を付与し、該付与したデジタル署名をプログラム実行ごとに検証することを特徴とする請求項１に記載のプログラム実行制御方法。
3. コンピュータ上でプログラムの実行を制御する装置であって、前記コンピュータに備わるデバイスドライバ、ライブラリおよびユーザデータのうち前記プログラムのドメインに基づいて決定される範囲のデバイスドライバ、ライブラリおよびユーザデータのフルセット又はサブセットが実行環境内にコピーされることにより作成されることにより、前記実行環境外へのアクセスが制限された前記実行環境内で動作するプログラムから参照可能に配置する実行環境作成手段と、前記プログラムを前記実行環境内で実行する実行制御手段と、を具備し、
   前記実行環境作成手段は、前記プログラムのドメインを、前記プログラムに関連付けられたドメイン情報に基づいて決定し、
   前記プログラムに関連付けられたドメイン情報として使用するために、前記プログラムを含むパッケージに付与されているドメイン情報を取得するドメイン情報取得手段を有し、
   前記ドメイン情報取得手段は、前記取得したドメイン情報を前記プログラムに付与することを特徴とするプログラム実行制御装置。
4. 前記ドメイン情報が付与されたプログラムにデジタル署名を付与し、該付与したデジタル署名をプログラム実行ごとに検証する検証手段を有することを特徴とする請求項３に記載のプログラム実行制御装置。
5. コンピュータを、前記コンピュータに備わるデバイスドライバ、ライブラリおよびユーザデータのうち前記プログラムのドメインに基づいて決定される範囲のデバイスドライバ、ライブラリおよびユーザデータのフルセット又はサブセットが実行環境内にコピーされることにより作成されることにより、前記実行環境外へのアクセスが制限された前記実行環境内で動作するプログラムから参照可能に配置する実行環境作成手段、前記プログラムを前記実行環境内で実行する実行制御手段、として機能させ、
   前記実行環境作成手段は、前記プログラムのドメインを、前記プログラムに関連付けられたドメイン情報に基づいて決定し、
   前記コンピュータを、さらに、前記プログラムに関連付けられたドメイン情報として使用するために、前記プログラムを含むパッケージに付与されているドメイン情報を取得するドメイン情報取得手段として機能させ、
   前記ドメイン情報取得手段は、前記取得したドメイン情報を前記プログラムに付与することを特徴とする実行制御プログラム。
6. 前記コンピュータを、さらに、前記ドメイン情報が付与されたプログラムにデジタル署名を付与し、該付与したデジタル署名をプログラム実行ごとに検証する検証手段として機能させることを特徴とする請求項５に記載の実行制御プログラム。

Images