(57)【特許請求の範囲】
【請求項１】
ソフトウェアを、転送先の実行システム内で安全に実行可能とするソフトウェア安全実行システムであって、
実行ファイルを含む、使用するファイルのファイル名と共にディレクトリ名も格納できるファイル名格納部と、ファイル実体を格納するファイル格納部とを有するポットと、
前記ファイル名格納部内のファイル名を、実行システムのファイル名に変換するマッピング手段とを備え、
前記ファイル名格納部は、前記ファイル格納部内のファイル名及びそれ以外のファイル名も格納しており、
前記マッピング手段は、
実行前又は実行中の必要とされたときに、前記ファイル格納部から実行システムにファイルを抽出し、
前記ファイル名を前記ディレクトリ名と共に実行システムのファイル及び／ 又は他のポットのファイルにマッピングし、
さらに、ポットで実行ファイルを実行したときに、ファイルへのアクセスを、ポットに関連するマップ及びセキュリティ・ポリシーの規定に従って、マッピング手段により変換して行なう
ことを特徴とするソフトウェア安全実行システム。
【請求項２】
請求項１に記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部には、最初に起動する実行ファイル名を格納できることを特徴とするソフトウェア安全実行システム。
【請求項３】
請求項１又は２に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、前記ディレクトリ名に対して、複数のディレクトリと定まった順番で対応させ、その順に該ディレクトリ内のファイルとマッピングする
ことを特徴とするソフトウェア安全実行システム。
【請求項４】
請求項１〜３のいずれかに記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部は、ネット上のサイトのファイル名を格納でき、
前記マッピング手段は、サイトから該ファイル名のファイルを実行するシステムに転送する
ことを特徴とするソフトウェア安全実行システム。
【請求項５】
請求項１〜４のいずれかに記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、プロセスをファイルとしてマッピングできる
ことを特徴とするソフトウェア安全実行システム。
【請求項６】
請求項１〜５のいずれかに記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、プロセスが作成したファイルをマッピングできる
ことを特徴とするソフトウェア安全実行システム。
【請求項７】
請求項１〜６のいずれかに記載のソフトウェア安全実行システムにおいて、
前記セキュリティ・ポリシーの規定には、実行中に発行できるシステム・コールの規定が含まれる
ことを特徴とするソフトウェア安全実行システム。
【請求項８】
請求項１〜７のいずれかに記載のソフトウェア安全実行システムにおいて、
前記セキュリティ・ポリシーの規定は、ネット上の他のサイトからダウンロードできるかを規定していることを特徴とするソフトウェア安全実行システム。
【請求項９】
請求項１〜８のいずれかに記載のソフトウェア安全実行システムにおいて、
前記ファイル名格納部には、ユーザごとのファイルへのアクセス権の規定を格納しており、
前記マッピング手段は、前記アクセス権の規定により、ファイルへのアクセスを制御する
ことを特徴とするソフトウェア安全実行システム。
【請求項１０】
請求項９に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、ユーザごとの読み出し権の鍵で、ファイルを復号化して読み出すことを特徴とするソフトウェア安全実行システム。
【請求項１１】
請求項９に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、ユーザごとに対応する秘密鍵で、読み出し権の鍵を復号化し、復号化した鍵を用いてファイルを復号化して読み出す
ことを特徴とするソフトウェア安全実行システム。
【請求項１２】
請求項９に記載のソフトウェア安全実行システムにおいて、
前記マッピング手段は、ユーザごとに対応する秘密鍵で、公開鍵− 秘密鍵のペアである読み出し権および書き込み権の鍵を復号化し、復号化した鍵を用いてファイルを復号化または暗号化する
ことを特徴とするソフトウェア安全実行システム。
【請求項１３】
ポット情報とセキュリティ・ポリシー情報とを格納したサーバ・システムであって、
ポット情報と、前記ポット情報に対応したセキュリティ・ポリシー規定を格納したデータベースと、
前記セキュリティ・ポリシーを、ポットを特定して検索できる検索手段と
を備えることを特徴とするサーバ・システム。
【請求項１４】
実行ファイルを含む、使用するファイルのファイル名と共にディレクトリ名も格納するファイル名格納部と、ファイルを格納するファイル格納部とを有するポットに対して、前記ポット中のファイル名格納部内のファイル名を、実行するシステムのファイル名に変換するマッピング手段をコンピュータ・システムに実装させるプログラムを記録する記録媒体であって、
該プログラムを実行したときに、
実行前又は実行中の必要とされたときに、前記ファイル格納部から実行システムにファイルを抽出し、
前記ファイル名を前記ディレクトリ名と共に実行システムのファイル及び／ 又は他のポットのファイルにマッピングし、
さらに、ポットで実行ファイルを実行したときに、ファイルへのアクセスを、ポットに関連するマップ及びセキュリティ・ポリシーの規定に従って、マッピング手段により変換して行なう
ことを特徴とするプログラムを記録する記録媒体。
【請求項１５】
実行ファイルを含む、使用するファイルのファイル名と共にディレクトリ名も格納するファイル名格納部と、ファイルを格納するファイル格納部とを有するポットに対して、前記ポット中のファイル名格納部内のファイル名を、実行するシステムのファイル名に変換するマッピング手段をコンピュータ・システムに実装させるプログラムであって、
該プログラムを実行したときに、
実行前又は実行中の必要とされたときに、前記ファイル格納部から実行システムにファイルを抽出し、
前記ファイル名を前記ディレクトリ名と共に実行システムのファイル及び／ 又は他のポットのファイルにマッピングし、
さらに、ポットで実行ファイルを実行したときに、ファイルへのアクセスを、ポットに関連するマップ及びセキュリティ・ポリシーの規定に従って、マッピング手段により変換して行なうことを特徴とするプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ソフトウェアを安全に実行する機構に関するものであり、特に、ソフトウェア流通に適した機構に関するものである。
【０００２】
【技術的背景】
インターネットの一番顕著な特徴の１つは、それが本当に開放的な環境であるということである。常に世界中に広がっているとともに、だれも完全には、だれがユーザであるかや、どのようなソフトウェアやコンテンツがこれを通じて交換されているかの制御や決定をできない。これらの特徴は、バッチ，ＴＳＳ，ＬＡＮやパーソナル・システム等の伝統的で、閉鎖的なコンピュータ環境に対して鋭く対峙している。コンピュータ・システムの歴史の全てにおいて、コンピュータ環境は常に閉鎖的であり、システム・ソフトウェアの設計者は、暗黙的に閉鎖的な環境が通常であると仮定している。コンピュータ・システムの発展の歴史の中で、比較的短い期間内で、インターネットの世界的な展開が行われたので、システム・ソフトウェアの設計者は、閉鎖的な環境が開放的になる場合に生じる問題に対して、手当てする時間がほとんどなかった。環境が劇的に開放されているが、われわれは、基本的な設計が閉鎖的な環境の仮定に基づいているソフトウェアを未だに使用している。このように、現在のコンピュータ・システムは、新しい酒を古い瓶に入れているようだと言われている。
【０００３】
ネットワーク環境が閉鎖的であり、ユーザが、インターネットのような開放的なネットワーク環境にアクセスできない場合、悪意のあるユーザや、そのようなユーザによって作成されたファイルは、存在しそうにもない。不運にも、インターネット環境では、このように仮定することはできない。このため、インターネットからファイル、特に実行可能又はインタープリット可能なコードを含んでいるソフトウェアを得ることは、リスクのある行為である。リスクを低減するために用いられているアプローチの１つは、マイクロソフトのAuthenticodeのようなコード署名手法である。この問題を解決するために期待できる技術的アプローチは、「砂箱」を作成して、リスクのある影響を、ユーザの通常の環境から隔離された、制限された制御可能な環境に閉じこめることである。このアプローチは、Java，SFI，Janus，Mapbox，およびSubDomainなどの多数のシステムに適用されている。
【０００４】
安全なソフトウェア流通の概念を明確にするため、まず初めに、安全でないソフトウェア流通のモデルについて説明する。このモデルは、伝統的に行われているソフトウェア配布を一般化したものである。次に、安全なソフトウェア流通を説明し、その用い方を説明する。
【０００５】
＜安全でないソフトウェア流通のモデル＞
ソフトウェア流通（Software Circulation）は、「ソフトウェア配布（Software Distribution）」の概念の一般化したものを指す用語として以下で使用する。ソフトウェア配布は、一方向、一時的、１対多のソフトウェア・パッケージの配布を意味する。これらの特性を緩くする、即ち、ソフトウェア配布を、多方向、多時的、多対多とすることで、ソフトウェア流通の概念を得ることができる。ソフトウェア流通は、カプセル化（Encapsulation），転送（Transfer），抽出（Extraction），実行（Execution）の４つの基本的な処理で行われる。これらの処理を図１に示す。
図１（ａ）で示される「カプセル化処理」は、１以上のファイル１１０，１２０，１３０に対して適用され、これらのファイルでカプセル化したアーカイーブ・ファイル１５０を作成する。図１（ｂ）の「転送処理」では、カプセル化したファイル１５０を送信元サイト１６２から送信先サイト１６４に移動する。図１（ｃ）の「抽出処理」は、カプセル化処理の逆の処理である。即ち、１以上のファイル１１０，１２０，１３０がアーカイーブ・ファイル１５０から抽出される。抽出されたファイルは、処理が実行されたサイト１６４のファイル・システム中のどこかに格納される。ファイル位置、名前、アクセス制御設定はその時に行われる。図１（ｄ）の「実行処理」では、丸の中にクロスがあるもので示されている実行可能なプログラム１４０が実行される。実行中、ファイル（クロスがない丸）１１０，１２０，１３０は、入力され、出力され、修正される。
【０００６】
これらの処理を結合することにより、典型的なソフトウェア流通のシナリオを行うことができる。図２はソフトウェア配布を図示している。送信者サイト（例えば、ソフトウェア・パッケージ配布者）１６２では、ソフトウェア・プログラムを構成するファイルをカプセル化して、アーカイーブ・ファイル１５０を生成する。アーカイーブ・ファイル１５０は配布者のサイト１６２から受信者（ユーザ）のサイト１６４へ移動する。ユーザのサイト１６４では、アーカイーブ・ファイル１５０は抽出されて、ファイル処理又はインストールのプログラム１４０により、ユーザのファイル・システム中に格納される。
【０００７】
図３は、図２のソフトウェア配布の変形を示している。抽出及び／又はインストール・プログラム１４２はアーカイーブ・ファイル１５２中に含まれている。アーカイーブ・ファイルを受け取ったユーザは、アーカイーブ・ファイル１５２中のプログラム１４２を使用して、インストール等を行うことができる。この配布形態は、柔軟性があり、便利である。ユーザが抽出プログラムやインストール・プログラムを持っていなくても、配布者は、インストール・プログラム中に書き込むことで、どんなことでもインストール中に行うことができるからである。
【０００８】
図４および図５は、ソフトウェア流通の繰り返しスタイルを示している。図４は作業の流れをモデル化して示している。図４において、各サイト１６６，１６８のプログラム１４４，１４６は流通するファイル１５４，１５５等に適用されている。図５では、流通するファイル１５７，１５８に含まれているプログラム１４８が実行される。これはモバイル・エージェント・システムをモデル化している。
【０００９】
図１〜図５に示されたモデルは、次の観点で安全ではない。
（１）カプセル化処理で、悪意のある人間が、例えば、実行されたとき悪いことを行う、又は、抽出したときに悪意の目的で既存のファイルに上書きするファイルをアーカイーブ・ファイル中に含ませる罠を置くかもしれない。
（２）転送処理の間に、ファイルは悪意のある中途妨害、横取り、修正、偽造に会うかも知れない。
（３）抽出処理の間に、抽出されたファイルはユーザのファイル・システム中に格納される。この時に、このファイル格納が位置決めされ、名付けられて、これらのアクセス制御が設定される。これらの処理はユーザのファイル・システムの管理にとって危険である。そして、ユーザの管理手法に従って行われないと大変危険である。
これらの理由により、このモデルは安全でないソフトウェア流通（ＵＳＣ：Unsecure Software Circulation）モデルと呼ばれる。
【００１０】
【発明が解決しようとする課題】
本発明の目的は、上述の問題点を解消し、ソフトウェア流通に適した、安全にソフトウェアを実行する機構を提供することである。
【００１１】
【課題を解決するための手段】
上記の目的を達成するために、本発明は、ソフトウェアを、転送先の実行システム内で安全に実行可能とするソフトウェア安全実行システムであって、実行ファイルを含む、使用するファイルのファイル名と共にディレクトリ名も格納できるファイル名格納部と、ファイル実体を格納するファイル格納部とを有するポットと、前記ファイル名格納部内のファイル名を、実行システムのファイル名に変換するマッピング手段とを備え、
前記ファイル名格納部は、前記ファイル格納部内のファイル名及びそれ以外のファイル名も格納しており、
前記マッピング手段は、実行前又は実行中の必要とされたときに、前記ファイル格納部から実行システムにファイルを抽出し、前記ファイル名を前記ディレクトリ名と共に実行システムのファイル及び／ 又は他のポットのファイルにマッピングし、さらに、ポットで実行ファイルを実行したときに、ファイルへのアクセスを、ポットに関連するマップ及びセキュリティ・ポリシーの規定に従って、マッピング手段により変換して行なうことを特徴とする。
【００１２】
前記ファイル名格納部には、最初に起動する実行ファイル名を格納するとよい。
また、前記マッピング手段は、前記ディレクトリ名に対して、複数のディレクトリと定まった順番で対応させ、その順に該ディレクトリ内のファイルとマッピングすることもできる。
さらに、前記ファイル名格納部は、ネット上のサイトのファイル名を格納でき、前記マッピング手段は、サイトから該ファイル名のファイルを実行するシステムに転送することもできる。
前記マッピング手段は、プロセスをファイルとしてマッピングでき、また、前記マッピング手段は、プロセスが作成したファイルをマッピングできるようにしてもよい。
その上、前記セキュリティ・ポリシーの規定には、実行中に発行できるシステム・コールの規定が含まれ、また、前記セキュリティ・ポリシーの規定は、ネット上の他のサイトからダウンロードできるかを規定してもよい。
前記ファイル名格納部には、ユーザごとのファイルへのアクセス権の規定を格納しており、
前記マッピング手段は、前記アクセス権の規定により、ファイルへのアクセスを制御してもよく、また、前記マッピング手段は、ユーザごとの読み出し権の鍵で、ファイルを復号化して読み出してもよい。
前記マッピング手段は、ユーザごとに対応する秘密鍵で、読み出し権の鍵を復号化し、復号化した鍵を用いてファイルを復号化して読み出すこともでき、また、前記マッピング手段は、ユーザごとに対応する秘密鍵で、公開鍵− 秘密鍵のペアである読み出し権および書き込み権の鍵を復号化し、復号化した鍵を用いてファイルを復号化または暗号化することもできる。
【００１３】
ポット情報とセキュリティ・ポリシー情報とを格納したサーバ・システムであって、ポット情報と、前記ポット情報に対応したセキュリティ・ポリシー規定を格納したデータベースと、前記セキュリティ・ポリシーをポットを特定して検索できる検索手段とを備えることを特徴とするサーバ・システムも本発明である。
さらに、実行ファイルを含む、使用するファイルのファイル名と共にディレクトリ名も格納するファイル名格納部と、ファイルを格納するファイル格納部とを有するポットに対して、前記ポット中のファイル名格納部内のファイル名を、実行するシステムのファイル名に変換するマッピング手段をコンピュータ・システムに実装させるプログラムや、そのプログラムを記録する記録媒体であって、該プログラムを実行したときに、実行前又は実行中の必要とされたときに、前記ファイル格納部から実行システムにファイルを抽出し、前記ファイル名を前記ディレクトリ名と共に実行システムのファイル及び／ 又は他のポットのファイルにマッピングし、さらに、ポットで実行ファイルを実行したときに、ファイルへのアクセスを、ポットに関連するマップ及びセキュリティ・ポリシーの規定に従って、マッピング手段により変換して行なうことを特徴とするものも本発明である。
【００１４】
【発明の実施の形態】
以下、図面を参照して、本発明の実施形態を説明する。
まず、安全であるソフトウェア流通（ＳＳＣ：Secured Software Circulation）モデルを考える。初めに、安全の意味を説明する必要がある。第１に、絶対的安全であるシステムは事実上設計不可能であることは一般的に認められていることである。このモデルおよびこのモデルを基にした我々の実装システムは、システマチックに容易に操作することで、安全に関する問題に関してＵＳＣモデルより、単にもっと安全であるものである。第２に、移転処理の安全でない面は、ソフトウェア流通に制限されるものではない。これはまた、一般的な情報移転に関する問題でもある。
以下に説明するＳＳＣモデルの中心的アイディアは、実行及びカプセル化の両方の間、流通されたソフトウェアの内側および外側を区別することである。これを可能とするため、２つのアイディアがこのモデルに導入された。第１は、ファイルをアーカイーブから抽出せず、代わりに、アーカイーブ・ファイルをファイル・システムとして使用するように概念を拡張した。第２に、アーカイーブ・ファイルと関連付けられた、区別された仮想アドレス空間内でプログラム実行を可能とした。ＳＳＣモデルは、仮想アドレス空間とファイル・システムの２つの空間を、１つに統合して、ポットと呼ばれる砂箱（sandbox）を作成している。各ポットは、仮想アドレス空間と仮想ファイル・システムの両方に対して、自分自身の区別された観点を有している。
【００１５】
＜ＳＳＣモデルの基本処理＞
ＳＳＣモデルの基本処理について、次に述べるように定義した。図６はそれを図示したものである。なお、以下ではＵｎｉｘのシステムに適用した場合で説明する。
図６（ａ）に示したカプセル化処理は、１以上のファイル２１２，２１４，２１６に適用されて、これらをポット２２０中に格納する。格納する際に、各ファイルは、Ｕｎｉｘと互換性があるユニークなパス名を与えられる。そして、最新修正時刻や実行可能性等の属性情報が記録される。図６（ｂ）の移転処理は、送信元サイトＡ２３２から目的のサイトＢ２３４に、カプセル化されたファイル（ポット）２２０が移動する。
ＳＳＣモデルのマッピング処理は、ＵＳＣモデルの抽出処理に代わるものである。図６（ｃ）において、マッピング処理は白抜きの矢印で表されている。ポット中のファイルｆＡ２１２またはｆＡ’２１４から、ローカル・ファイルのファイルｆＢ２１６またはポット２２２中のファイルｆＢ’２１８にマッピングするとは、ポットでの実行中におけるファイルｆＡ２１２またはｆＡ’２１４へのアクセスは、ファイルｆＢ２１６またはｆＢ’２１８にリダイレクトされることである。
図６（ｄ）は実行処理を示している。実行処理中、ポット２４０中のプログラム２４２は、実行サイト２３４のファイル・システムと共有している仮想アドレス空間中では実行されない。代わりに、ポット２４０は自分自身のファイル・システムのような仮想アドレス空間と関連付けられる。そして、ポット中のプログラム２４２はこの環境内、即ち、ポット中に現れるファイル以外は見えない状況で実行される。この実行は、マッピング・スキームと使用許可される資源とで規定されている。
上述したように、本発明のポットは、処理がポットと関連付けられているかどうかにより、２つの状態を有している。２つの状態の間を区別するため、処理がポットと関連しない場合のポット・ファイル（pot-file）と、処理に関連している場合のポット・プロセス（pot-process）の用語を使用する。
【００１６】
図７は、４つの処理を結合した典型的なＳＳＣモデルの使用を図示している。図７において、送信者側のサイト３１２では、１つの実行ファイル（クロスを含む丸）３３２と実行ファイルで処理される１つのデータファイル（クロスなしの丸）３３４がカプセル化される。２つの残りのファイル（点線の丸）３３６，３３８は、送信者側のサイトのポット３２０では物理的に存在していない。このファイルは実行時に受信者側サイトでマップされる。これについては後で説明する。ポット・ファイル３２０は送信者サイト３１２から受信者サイト３１４に、ＦＴＰ，ＷＷＷ，電子メール等の転送方法で転送される。
【００１７】
受信者サイト３１４では、ユーザは、ポット中のファイルとローカル・ファイルとの間や、ポット中のファイルと他のポット中のファイルとの間のマッピング・スキームを特定するセキュリティ・ポリシー記述３４０を用意する。このセキュリティ・ポリシー３４０の規定により、ポット内でプログラムが実行中、他のローカル・ファイルを見ることができない。セキュリティ・ポリシー・ファイル３４０は、実行中に発行が許されるＯＳカーネルのシステム・コールも記述できる。このセキュリティ・ポリシーについては後で詳しく説明する。
受信者サイト３１４では、セキュリティ・ポリシー３４０の規定に従って、プログラム３３２は、ポット内の実体のないファイル３３６，３３８を、ローカル・ファイル・システムのファイル３５４や、他のポット３５０内のファイル３５６にマッピングして、ポット内のファイル３３４やマッピングされたファイル３５４，３５６を用いて、処理を行うことができる。
この様に、ポットは、ユーザの処理における通常の実行環境から区別される砂箱を形成している。
【００１８】
マッピング処理に対して２つの小さい拡張をしている。
（１）ディレクトリ・マッピング
ポット内のディレクトリを、他のポット内やローカルの通常のファイル・システムのディレクトリにマッピングすることを許している。これを図８（ａ）で説明する。図８（ａ）では、ポット３２０中のディレクトリ３６２，３６４と、ローカル・ファイル・システム中のディレクトリ３６６および他のポット３６７中のディレクトリ３６８とをマッピングしていることを示している。
【００１９】
（２）縦続マッピング（cascade mapping）
マッピングの縦続（cascade）を許している。簡単な縦続マッピングの動作的意味は次の通りである。縦続マッピング処理は、ポット中及び／又は通常ファイル・システムの多重ディレクトリ（multiple directories）間の完全な順序関係を規定している。マッピング処理でファイルのパス名を得たとき、完全に順序付けられた複数のディレクトリがその順序で得られて、発見された最初のファイルがその結果である。これらの拡張は、セキュリティ・ポリシーの記述を簡単にし、容易にすることに役立つとともに、転送されたポットの処理をより柔軟にする。これを図８（ｂ）で説明する。
図８（ｂ）において、ポット中のディレクトリ３７２と、ポット３８２中のディレクトリ３９２およびポット３８６中のディレクトリ３９６とがこの順序で縦続マッピングされている。マッピング処理においては、ディレクトリ３７２中のファイルは、ディレクトリ３９２とディレクトリ３９６とをこの順序でサーチして、最初に発見したものとマッピングする。図８（ｂ）においては結果的に、ディレクトリ３７２中の３つのファイルは、ディレクトリ３９２内の２つのファイル，ディレクトリ３９６内の１つのファイルとマッピングされる。ポット３２０中のディレクトリ３７４も同様にマッピングされる。
【００２０】
＜ＳＳＣ（Secured Software Circulation）モデルの利用＞
ＳＳＣモデルを適用して、開放的なネットワーク環境中で安全なソフトウェア転送を必要としている典型的な処理（computation）をいかにして表現するかを示す。
（１）ダウンロードされたコードの安全な解釈実行（interpretation）
ＳＳＣの典型的な利用は、ダウンロードされたコードの安全な解釈実行である。この形式の処理は、広く使用されている Java やその applet システムにより普及した。ＳＳＣは、ダウンロードされたコードの安全な解釈実行を可能とする一般的なフレームワークを提供する。これを図９で説明する。図９において、サーバ・サイト４３２で、コードのファイル４１２をポット４１０にカプセル化する。このコード４１２を含むポット４１０は、クライアント・サイト４３４に送られて、そのサイト４３４のポット４２０中に格納されているインタプリタ４１４で解釈実行される。クライアント・サイト４３４に送られたポット４１０は、インタプリタ実体４１４をマッピング処理により結びつけられる。そして、送信者から送られたポット４１０中にインタプリタが現れたかのように、関連するセキュリティ・ポリシー４４０の制御に基づき、コード４１２を解釈して実行する。この安全なダウンロードされたコードの解釈実行のためのフレームワークは、使用できるプログラミング言語システムや仮想マシン命令セットに制限されないことに注意されたい。
【００２１】
（２）動的に生成されたネイティブ・コードの安全な実行
次に、もっと進化したダウンロードされたコードの実行を説明する（図１０）。この形式の処理は、ジャスト・インタイム（ＪＩＴ）コンパイルと通常呼ばれている。
図１０（ａ）において、送信者サイト４３２から受信者サイト４３４にダウンロードされたポット４６０中のコード４６２は、マッピングされたコンパイラ４６４により、受信者サイト４３４のＣＰＵアーキテクチャに対するネイティブ・コード４６６にコンパイルされる。生成されたネイティブ・コード４６６は、受信者サイト４３４で、セキュリティ・ポリシー４４０の規定に従って、送られてきたポット４６０中で実行される。必要なら、その実行結果は、ローカル・ファイル・システムのファイル４６９にマッピングされる。
図１０（ｂ）は、生成されたネイティブ・コード４６６が、他のポット４８０中にマッピングされて、そのポット４８０中でセキュリティ・ポリシー４４０の規定に従って実行される。
図１０に示されるように、この処理は、基本的な処理を単純に組み合わせることで表現することができる。このように、比較的複雑な処理をシステマチックな手法で実現して、システムがＳＳＣモデルを実装できることを期待している。
【００２２】
（３）モバイル・エージェントの安全な実行
モバイル・エージェント・システムは、分散処理（distributed computation）の最も精巧な形式の１つである。興味深いことに、この形式の処理は、ＳＳＣモデルを用いることにより、原理的に素直な手法で表現することができる。
図１１において、受信者サイト４５２，４５４では、ポット４９０を受信した後、ポット４９０中に格納されているプログラム４９２は、規定されたセキュリティ・ポリシー４４２，４４４の制御下、各サイトのポット環境内で実行される。この図は、モバイル・エージェント処理の原理のみを示している。もっと複雑な設定が現実の状況では必要である。例えば、受信者サイトのローカル・ファイル・システム中のファイルが、ポットに対してマッピングされており、実行コードは図９のように解釈されているか、図１０のようにＪＩＴコンパイラを用いて実行されている。
【００２３】
（４）安全なワークフロー処理（workflow computing）
安全なワークフロー処理の表現は、安全なモバイル・エージェント処理に対するものを少し修正することで得ることができる。相違点は、モバイル・エージェント処理ではプログラム・コードが転送されたポット中に含まれているが、ワークフロー処理では各実行プログラム・コードが各処理サイトでローカルに通常用意されていることである。典型的な設定例が図１２に示されてる。
図１２（ａ）において、プログラムが処理する対象のファイルを格納したポット５３０が、各サイト５１２，５１４を移転して、各サイトにあるポット５２０，５４０中のプログラム・コード５２２，５４２が処理することを示している。各サイトでは、プログラム５２２，５４２があるポット５２０，５４０から、移転してきたポット５３０内のファイルに対してマッピングしている。
図１２（ｂ）では、各サイト５１２，５１４で、移転してきたポット５５０から、各サイト５１２，５１４内のプログラム・コード５６２，５６４にマッピングして、ポット内のファイルに対して処理を行っている。
【００２４】
＜ソフトウェア・ポット（SoftwarePot）：ＳＳＣモデルの実装例＞
先に記述されているＳＳＣモデルは、いろいろな手法で実装することができる。ここでは、ＯＳカーネルを修正しない、移植可能なアプローチを記述する。その代わりに、この手法は、発行されたシステム・コールを解釈して操作する機能を使用する。このような機能は、多数の現在のオペレーティング・システム（例えば、Solaris, Linux, FreeBSD 等）で提供されている。このアプローチを基に設計されているシステムをソフトウェア・ポットと呼ぶ。ソフトウェア・ポットは、図６に記述されているＳＳＣモデルの４つの処理をサポートしている。これらの処理の１つである転送処理は、よく知られたどのネットワーク転送方法（例えば、ＦＴＰ，Ｗｅｂ，電子メール等）を用いても実装することができる。 以下に、他の３つの処理の実装スキームを、図１３〜図１９を用いて説明する。
【００２５】
（１）カプセル化処理
カプセル化処理は、カプセル化対象として規定されたファイルを集めて、これらのファイルをポット・ファイル中に格納することで実装される。図１３は、カプセル化の規定の例を示している。キーワードの"static:"６１２が前に置かれている静的ファイル・セクション６１０は、それぞれの行の第２項で規定されている、ローカル・ファイル・システム中のファイルが、第１項で規定されているパス名でポット・ファイル中に格納されることを規定している。例えば、図１３の第２行６１３は、ローカル・ファイルである /home/user1/picture/picA.jpg がポット・ファイル中に /data/pic1.jpg のパス名で格納されることを規定している。
【００２６】
これを、図１４および図１５で説明する。図１４は、送信者サイト７１２でポット・ファイル７２２をカプセル化して、送信者サイト７１２から受信者サイト７１４へポット・ファイル７２２を転送している。図１５は、現在の実装におけるポット・ファイルの内部構造８００を示している。なお、図１５でマジック・ワード８１０とは、ポット・ファイルを識別するためのものである。
図１４では、送信者サイト７１２中のファイル７４２は、実体的にポット・ファイル７２２中に格納されている。これを静的に格納されているという。
静的に格納されたファイルは、図１５の静的ファイル情報８１２に静的ファイル・セクション６１０（図１３参照）内のパス名が格納されるとともに、ファイルの実体が「ファイル格納」領域８２２と名付けられている領域に格納される。ファイルをファイル格納領域８２２に格納するために、例えばモジュール構造を採用でき、現在は tar，tar+gzip，又は zip のフォーマットを使用している。格納したフォーマットの選択は、次のセクションで説明される機構により、ポット・プロセス中で実行されるプログラムに対して完全に透明（transparent）である。
【００２７】
ファイルを静的（statically）にポット・ファイル中に格納する基本的な機能に加えて、ソフトウェア・ポット・システムは、格納されるファイルのもともとの位置のみを格納して、ファイルの内容は要求されたときに動的（dynamically）に格納するときに使用する機能を有している。これは、図１３のカプセル化規定の "dynamic:"６２２で示している動的ファイル・セクション６２０において規定されている。図１３の例では、行６２４におけるパス名 /mybin/viewer_plugin1 のファイルは、ＵＲＬの http://www.foo.com/viewer_plugin1 で規定される位置から得るべきであり、行６２６でのファイル /mybin/viewer_plugin2 は、ポット・ファイルが作成されたサイトの /home/user1/bin/viewer_plugin2 の位置から得るべきであることを規定している。
【００２８】
図１４では、送信者サイト７１２のファイル７４４，他のサイト７１６内のポット７２６に格納されているファイル７４６，他のサイト７１８のファイル７４８のそれぞれのパス名（他のサイトの場合は、それぞれのサイトのＵＲＬを含む）を、ポット７２２内にカプセル化の際に格納することを示している。これらのファイルは受信者サイト７１４での実行時に必要になったときに得ている。図１５で、これらの情報はファイル構造８００における動的ファイル情報８１４に含まれている。
静的メソッド（static method）は、絶対に必要なファイルを格納するために有効である。一方、動的メソッド（dynamic method）は、選択的に必要なファイルを格納することや、ポット・ファイルのサイズを縮小することに有効である。
【００２９】
"required:"６３２が前に置かれているセクション６３０は、実行時にマッピングされるファイルやディレクトリを規定している。図１３において、規定例では、ディレクトリ /var６３４および /extern_world６３６が、実行時にマッピングされることを規定している。図１５で、これらの情報はファイル構造８００におけるマップ・ファイル情報８１６に含まれている。
"saved:"６４２で始まるセクション６４０は、列挙されているディレクトリ中のファイルの修正は、ポット・ファイル・システム中に永久的に反映すべきであり、他のファイルの修正は、実行セッション中に一時的に反映されて、セッション後は捨てられることを規定している。また、"entry"６５２のセクション６５０は、最初に実行すべきデフォルトのファイル（図１３の６５４参照）を規定している。図１５で、これらの情報はファイル構造８００におけるセーブ・ファイル情報８１８およびエントリ情報８２０に含まれている。
【００３０】
（２）マッピングおよび実行処理
マッピング及び実行処理の実装は、ソフトウェア・ポット・システム中では統合されており、このため、これを一緒に、図１６〜図１９を用いて説明する。
双方の処理のエッセンスは名前の変換である。即ち、ファイルを操作する全ての基本的な処理（例えば、open, read, write, lseek, close のシステム・コール）は、マッピングされた目的のファイルにリダイレクトされる。図１６は、この名前変換スキームを図示している。マッピングされている・されていないに関わらず、ポット内の全てのファイル・アクセスは、一様にマッピングを介して取り扱われる。これは、ファイルがアクセスされたときまでに、ポット中に静的に格納されている全てのファイルは、ローカル・ファイル・システムへ抽出されているからである。
【００３１】
図１６において、ポット・プロセス９１０の初期設定の途中で、名前変換スキームが、マッピング及びセキュリティ・ポリシー記述（mapping and security policy description）に従って用意される。ポット・プロセス９１０がプログラムで記述したファイルをアクセスするとき、名前変換により、ローカル・ファイル・システム中のポット９３０内のファイル９３２，９３４、ポット９４０内のファイル９４４、およびファイル９５２にアクセスされる。また、他のプロセス９６０に対してプロセス間通信（ＩＰＣ）を介してアクセスしたり、他のサイト９７０にＨＴＴＰ等のネットワーク・プロトコルを介してアクセスしている。
また、他のプロセス９８０が生成したテンポラリ・ファイル９８２に対してもアクセスすることができる。この機能により、ポット・プロセス９１０に見せてもよい情報を制限したり、あるいは実際には存在しないファイルをポット・プロセス９１０に対して存在するかのように見せることができる。
ポット・プロセス９１０から見たファイル・システム空間は、名前変換規定により生成された仮想的なものである。ポット・プロセス９１０は、実行してるオペレーション・システムの「実」ファイル・システムを直接見ることはない。
抽出に対して、２つのモードが用意されてる。イーガー抽出モード（eager extraction mode）とレージー抽出モード（lazy extraction mode）である。イーガー抽出モードでは、ポットに静的に格納されている全てのファイルは、実行処理が起動されるときに、一度に抽出される。他方、レージー抽出モードでは、各ファイルが、アクセスに必要なときに抽出される。
【００３２】
図１７に示されている例を用いて、ソフトウェア・ポットにおいて、どのように名前マッピングとセキュリティ・ポリシーの規定が記述されているかを説明する。
"map:" セクション１０１０は、第１項で規定されているポット中の各ファイルまたはディレクトリが、第２項で規定されてる既存のファイル又はディレクトリにマッピングされることを規定している。例において、"/etc/termcap  /lib/tools.pot:/etc/termcap" の行は、ポット・プロセス中でアクセスされる "/etc/termcap" ファイルが、"/lib/tools.pot" という名前のポット・ファイル中の同じ名前を有するファイルへリダイレクトされることを規定している。"/alpha /beta,/gamma,/delta" の行は、縦続マッピングの規定の仕方を示している。例えば、"/alpha/x" ファイルへのアクセスは、"/beta/x"，"/gamma/x"，"/delta/x" の各ファイルの１つにリダイレクトされる。このファイル選択では、"/beta/x" ファイルが最も優先され、"/delta/x" ファイルが一番低い。
【００３３】
"temporary:" セクション１０２０は、"/sbin/account_processing/users all" という起動コマンドで指定されたプログラムの実行出力を一時ファイルに格納し、その一時ファイルにポット・プロセス内の"/etc/account" というファイルをマップすることを規定している。
"indirect:" セクション１０３０は、「プロセス・マッピング（process mapping）」と呼ばれる特別のマッピング処理を規定している。即ち、ポット・プロセス中のファイルＩ／Ｏは、プロセス間通信にリダイレクトされる。この例では、"/etc/passwd /home/user2/bin/passwd_filter" は、ポット・ファイル中の "/etc/passwd" ファイルへのアクセスは、コマンド "/home/user2/bin/passwd_filter" で起動されたプロセスに対するプロセス間通信にリダイレクトされることを規定している。
上述したように、"indirect" セクションで指定する機能は，起動したプロセスとのプロセス間通信を，ファイルであるかのようにマップする機能であるのに対し，temporaryセクションで指定する機能は、実行出力を一時ファイルに格納し、その一時ファイルにマッピングを行うものである。一時ファイルを生成するコスト（時間，ファイル容量）が小さいときは"temporary" セクション、大きいときは"indirect"セクション機能を使うとよい。また，"indirect" の方がより動的であり、内容を動的に生成することができる。なお、"temporary" セクションで規定したプログラムは、マップ前に一時ファイル内容を生成する必要がある。
【００３４】
残りのセクション１０４０，１０５０は、セキュリティ・ポリシーを規定している。"network:" セクション１０４０では、例においては、全ての通信関連のシステム・コールは、ＩＰアドレス１３０．１５８．８０．＊のＴＣＰポート８０への接続（connection），１３０．１５８．８５．９７のＴＣＰポート２１への接続，"*.tsukuba.ac.jp" のＴＣＰポート２２への結び付き（bind）が許されていることを除いて、禁止されていることを規定している。
また、"syscall:" セクション１０５０では、ネットワーク関連以外のシステム・コールに対しての許可（permission）を規定している。例では、ネットワーク関連と（キーワード "deny" が前に置かれている）最後の２行に列挙されているもの以外の、全てのシステム・コールが許可されている。
【００３５】
ここで、名前変換を実装している方法について、図１８を用いて説明する。ここで示している例は、ポット・プロセス１１００で発行したオープン（open）のシステム・コールの引数を、以下の様に実行時に書き換えるものである。
open("/foo.txt", ...)   ------>  open("/tmp/XXX/foo.txt", ...)
さて、ほとんどの現在のオペレーティング・システムは、システム・コールを、ＯＳカーネル中のコールの実行の前および後に横取りして、横取りしたときにユーザ・レベルのコードを実行する機能をサポートしている。また、現在のＯＳは、ユーザ・プロセスが、他のユーザ・プロセスを、制限された仕方で調べて修正することを許容している。これらの機能を結合することで、ＯＳカーネルを修正することなく、要求される名前マッピング機構を透過的（transparently）に実装できる。
【００３６】
図１８において、初期設定により、モニタ・プロセス（以下、モニタ）１２００は起動されて、ポット・プロセス１１００と関連付けられて実行を監視している。名前マッピングに対する設定は、図１８のパス名変換テーブル１２２０に記録されている。
ポット・プロセス１１００がオープン・システム・コールを発行したとき、カーネル１３００はそのコールを捕らえてモニタを呼び出す（Ｓ１３０２）。モニタ１２００は、ポット・プロセス１１００の内容を調べ、オープンされるべきファイルのパス名１１２２を得る（Ｓ１２０４）。パス名変換テーブル１２２０を参照して、モニタ１２００は、オープン・システム・コールが適用すべき実際のファイルを決定する。レージー・ファイル抽出モードが規定されている場合、ファイルがポット・ファイルのファイル格納から抽出される。縦続マッピングが規定されている場合、ファイル検索は、規定された完全順序付けのディレクトリ・リストに従って行われる。動的ファイル転送がマッピング規定に規定されている場合、適切なファイルがネットワークを介して獲得される。"indirect:" オプションが規定されている場合、規定されたプロセスが起動され、ポット・プロセスと起動されたプロセスとの間で、プロセス間通信が確立される。
【００３７】
モニタ・プロセス１２００は、変換されたパス名１１４２をポット・プロセス１１００の使用されていない領域（図１８ではスタック・セグメント１１４０）に書き込み、レジスタに格納されているパス名へのポインタを、変換されたファイル名１１４２への参照として書き直す（Ｓ１２０６）。レジスタへの書き直しの直前、モニタ・プロセスは、レジスタの内容を、後で回復するためにセーブする。
次に、モニタ１２００は、その後、カーネル１３００にオープンの実際の処理を実行するように指示する（Ｓ１２０８）。カーネル１３００は、オープンの処理を実行する（Ｓ１３１０）。カーネル１３００が再びモニタ１２００を呼び出す（Ｓ１３１２）。モニタ１２００は、レジスタの内容を回復して、ステップＳ１２０６で書いた変換されたパス名を消去する（Ｓ１２１４）。モニタ１２００は最後に、カーネル１３００にポット・プロセス１１００を再開するように指示する。
実行中、ポット・プロセスはフォーク（fork）システム・コールを発行して、他のポット・プロセスを子プロセスとして生成できる。これを図１９を用いて説明する。図１９において、ポット・プロセス１４０８は、セキュリティ・ポリシーにより許可されている場合、フォーク・システム・コールを発行して、ポット・プロセス１４１０を子プロセスとして生成できる。このとき、モニタ１４０２もフォークして、子のモニタ・プロセス１４０４が子のポット・プロセス１４１０を監視する。
【００３８】
＜安全なソフトウェア流通＞
ソフトウェア・ポット内のソフトウェアを実行する際に、そのソフトウェアの挙動を監視して，ユーザの意図に反した挙動を示した場合は、異常終了させたり、その挙動の続行を許すかどうかをユーザが定める必要がある。これを規定するセキュリティ・ポリシーは、ソフトウェアごとに作成する必要がある。計算機システムに対する詳しい知識を有するユーザはこのセキュリティ・ポリシーを自身で作成してよい。そうではないユーザのために、第三者機関がセキュリティ・ポリシーを作成できるようにする必要がある。図２０を用いて、これらの関係について説明する。
【００３９】
図２０において、ソフトウェア作成は、ポット・ファイル１５１４としてポット・ファイル作成サイト１５１０で作成される。ソフトウェア作者は、ソフトウェアの配布前にあらかじめ認証局（認証登録サイト１５３０）にソフトウェア・ポット１５１４を登録する。この登録は、ソフトウェア・ポットのダイジェスト（digest）をとり、ダイジェスト１５３２とポット情報１５３４を認証局に登録しておけばよい。
また、このソフトウェアに対するセキュリティ・ポリシーを作成した作成者（図２０のセキュリティ・ポリシー・サイト１５２０参照）は、セキュリティ・ポリシー，対象ソフトウェア等を認証局１５３０に登録する。ソフトウェア・ポットのユーザは、そのソフトウェア・ポットのダイジェストを生成し、そのダイジェストを認証局に送って、それをキーとして登録されているセキュリティ・ポリシーを検索する（図２０のユーザ・サイト１５４０参照）。複数登録されている場合は、その中からもっとも自分にふさわしいものを選択入手する。ソフトウェア作成者，認証局，検査コード提供者，利用者が全く独立の組織である必要はなく、それらの二つ以上の組み合わせが同一組織であってもよい。
これらの処理について、図２１〜図２９を用いて詳しく説明する。
【００４０】
（ポット・ファイル登録）
図２０におけるポット・ファイル作成サイト１５１０と認証登録サイト１５３０におけるポット・ファイルの登録について、図２１，図２２を用いて説明する。
図２１において、ポット・ファイル作成者は、まず、登録対象となるポット・ファイルを指定して、そのダイジェストを例えばＭＤ５等のハッシュ値計算アルゴリズムを用いて計算する（Ｓ１６１２）。図２２（ａ）に示した送信ボタン１６３６を押下して、計算したポット・ファイルのダイジェスト（ハッシュ値）を送信内容１６３２に表示されているポット・ファイルの属性（作成者、内容等）と共に、登録のために認証登録サイト１５３０へ送る（Ｓ１６１４）。認証登録サイト１５３０では、ダイジェスト（ハッシュ値）と属性情報を受け取り、ハッシュ値をキーとしたテーブル１５３２，１５３４に登録する（Ｓ１６１６）。そして、ファイル作成サイト１５１０に登録が成功したことを通知する（Ｓ１６１８）。ポット作成者は、登録完了を図２２（ｂ）の画面１６４０で知ることができる（Ｓ１６２０）。
【００４１】
（セキュリティ・ポリシー登録）
図２０におけるセキュリティ・ポリシー・サイト１５２０と認証登録サイト１５３０の間におけるセキュリティ・ポリシーの登録について、図２３〜図２５を用いて説明する。
まず、入手したポット・ファイルに対するセキュリティ・ポリシーを作成した作成者は、作成したセキュリティ・ポリシーの登録のために、そのポット・ファイルのダイジェストであるハッシュ値を、例えばＭＤ５等のアルゴリズムを用いて計算する（Ｓ１７１２，Ｓ１７１４）。図２４（ａ）の画面１７４０の送信ボタン１７４６を押下することで、求めたダイジェスト（ハッシュ値）１７４２を認証と検索のために認証サイト１５３０へ送る（Ｓ１７１６）。認証サイト１５３０では、ハッシュ値を受け取る（Ｓ１７１８）と、これをキーとして検索を行い、ポット・ファイルの情報を得る（Ｓ１７２０）。得られた場合は入手したポット・ファイルが認証されたことになる。求めたポット・ファイルの属性情報をセキュリティ・ポリシー・サイト１５２０に送信する。ポット・ファイルが見つからない場合はその旨をサイト１５２０に送信する（Ｓ１７２２）。図２４（ｂ）に示すような画面を用いて、受信したポット・ファイルの属性情報をユーザに提示する（Ｓ１７２６）。ポット・ファイルの属性情報でポット・ファイルの認証を確認したユーザは、作成したセキュリティ・ポリシーを登録する。この登録には、図２５（ｃ）の画面１７６０のラジオボタン１７６４で、セキュリティ・ポリシーの実体か、又はセキュリティ・ポリシー・サイト１５２０のＵＲＬかを選択して、認証サイト１５３０に送ることで行う（Ｓ１７２８）。
受け取った認証サイト１５３０は、送られたセキュリティ・ポリシーの実体（ファイル）又はＵＲＬをポット・ファイルに対応するように登録して（Ｓ１７３０）、登録終了を図２５（ｄ）に示す画面１７７０で通知する（Ｓ１７３２）。ユーザはこの画面１７７０を見て、登録を確認する（Ｓ１７３４）。
【００４２】
（セキュリティ・ポリシーのダウンロード）
図２０におけるユーザ・サイト１５４０と認証登録サイト１５３０の間におけるポット・ファイルの認証と、これに対応するセキュリティ・ポリシーのダウンロードについて、図２６〜図２９を用いて説明する。
ユーザは、ポット・ファイルをメール，Ｗｅｂ，ＣＤ−ＲＯＭ等により入手する（Ｓ１８１２）。これを実行するためには、このファイルが例えばウィルス等に汚染されていないか等の認証を得ることと、セキュリティ・ポリシーを得る必要がある。このため、まず、入手したポット・ファイルのダイジェスト（ハッシュ値）を例えばＭＤ５等により得る（Ｓ１８１４）。図２７（ａ）の画面１８４０の送信ボタン１８４６を押下することで、このダイジェスト（ハッシュ値）を認証登録サイト１５３０に送信して、ポット・ファイルの認証を行う（Ｓ１８１６）。認証登録サイト１５３０は、ポット・ファイルのダイジェスト（ハッシュ値）を受け取り（Ｓ１８１８）、このハッシュ値をキーとして登録ファイルを検索する（Ｓ１８２０）。ポット・ファイルの検索が成功した場合、認証されたことになり、検索されたポット・ファイルの属性情報および登録されているセキュリティ・ポリシー・ファイルの属性情報をユーザ・サイト１５４０に送る（Ｓ１８２２）。見つからない場合は、その旨をユーザ・サイト１５４０に送る（Ｓ１８２２）。
ユーザ・サイト１５４０では、図２７（ｂ）の画面例１８５０のように受け取ったファイル属性情報１８５２を表示する（Ｓ１８２４）。これでポット・ファイルの認証が完了したので、次に、このポット・ファイルを安全に実行するためのセキュリティ・ポリシーをダウンロードする。セキュリティ・ポリシーは複数登録されているので、例えば、図２８（ｃ）の画面１８６０のラジオボタン１８６２のように、安全性の面から選択して（Ｓ１８２６）、この選択を認証サイト１５３０に送信する（Ｓ１８２８）。これを受けた認証サイト１５３０は、セキュリティ・ポリシーの実体かＵＲＬをユーザ・サイト１５４０へ送る（Ｓ１８３０）。ユーザ・サイトでは、セキュリティ・ポリシーを受け取る。ＵＲＬの場合は、そのＵＲＬのサイトにアクセスして、セキュリティ・ポリシーをダウンロードする（Ｓ１８３２）。これで、図２９（ｅ）の画面例１８８０に示す実行ボタン１８８６を押下して、入手したポット・ファイルを、セキュリティ・ポリシーを用いて安全に実行することができる（Ｓ１８３４）。
【００４３】
＜実施例＞
ソラリス５．６（Solaris 5.6）オペレーティング・システム上に、前に記述した実装スキームを基礎としてソフトウェア・ポットを実装した（表１参照）。約５０００行のＣプログラム・コードが実装に必要であった。ここでは、実装した実施例の結果を説明する。ハードウエア・プラットフォームは、Sun Ultra 60 ワークステーション（ＣＰＵ：UltraSPARC II, 4MB Cache Memory, 512MB main memory, 36GB hard disc）である。
【表１】
0004522705.tif 000002
【００４４】
３つのマイクロベンチマーク・プログラムが書かれ、ソフトウェア・ポットあり、なしでのこれらのプログラムの実行時間を比較することで、システム・コールに課したオーバーヘッドを特定した。ベンチマーク・プログラムは以下のものである。
（１）Ｆｉｂ
このプログラムは、フィボナッチ数を計算する。計算中はシステム・コールを呼び出さない。
（２）getpid-caller
このプログラムは、"getpid" システム・コールを、メインループで繰り返し（１０００万回）呼び出すが、他のシステム・コールを呼び出さない。
（３）open-caller
このプログラムは、同じファイルを開き（open）、すぐに閉じる（close）処理を繰り返す。これはパス名システム・コールを多数回呼び出す。オープン・システム・コールとクローズ・システム・コールの対を１万回実行する。
【００４５】
イーガー抽出モードをこの実施例の実行では用いた。上述のプログラムにおけるファイル抽出時間は大変小さく、示す結果には含まれない。実施例の実行結果は表２で示す。
【表２】
0004522705.tif 000003
【００４６】
表２において、Ｆｉｂの動作は、ソフトウェア・ポットで実行しているかどうかにより影響を受けない。これは大変自然であり、ソフトウェア・ポットにおけるモニタ・プロセスは、システム・コールのみを横取りしているからである。"getpid-caller" では、ソフトウェア・ポットで実行したとき遅くなっている。これは予期しない結果である。なぜなら、"getpid" はパス名システム・コールではなく、この呼び出しは横取りされないからである。システム・コールが横取りされるように構成されると、オーバーヘッドが全てのシステム・コールに追加されると思われる。"open-caller" ベンチマークは、ソフトウェア・ポットで１桁遅くなる（全ての実行時間での差は８，２４６ミリ秒であった）。"open-caller" は"open" を１万回呼び出すので、各"open" に対するペナルティは、０．８ミリ秒である。ソフトウェアが実行する、１つのパス名システム・コールを横取りするときの処理の量はシステム・コールの種類によらないので、同じペナルティが全てのパス名システム・コールに対して課せられている。
【００４７】
＜ファイルのアクセス制御機能＞
上述したように、本発明のソフトウェア安全実行システムによれば、ソフトウェアをポット・ファイル内に隔離した状態で、安全性を検証しながら実行することができる。これにより、ソフトウェアの導入時および実行時に悪意のある動作や誤動作が発生した場合でも、ユーザの計算機資源などの安全性を確保することができる。
また、本発明のシステムでは、ファイルを流通させる際に、ファイルの獲得法や生成法などを動的に定める機能を提供している。これにより、ファイルをソフトウェア・ポットに格納する際に、ファイルの実体そのものを格納するだけでなく、ファイルの所在場所もしくはファイルの動的獲得法を格納しておき、実行時にファイルを獲得することを、アプリケーションに透明に（すなわち、アプリケーションに意識させずに）実現している。
【００４８】
しかしながら、従来のファイル流通における他の問題として、特定のユーザに対してファイルへのアクセス権（読み出し権・書き込み権）を与えることを、アプリケーションに透明に実現することができていないという問題がある。
この問題を解決するために、本発明のソフトウェア安全実行システムには、さらにファイルのアクセス制御機能を追加することができる。ファイルのアクセス制御機能とは、あらかじめ定められたユーザに対してのみ、ファイルの読み出しおよびファイルへの書き込みを許可する機能である。この機能は、次の（１）および（２）を行なうことにより実現される。
（１）ファイル・ポット作成時のカプセル化処理において、カプセル化の規定にアクセス制御の規定を記述する。
（２）暗号技術を用いてファイル実体や鍵などを暗号化・復号化する。
以降、まず（１）について説明し、次に（２）について説明する。
【００４９】
（１）アクセス制御の規定の記述
上述の＜ソフトウェア・ポット（SoftwarePot）：ＳＳＣモデルの実装例＞の「（１）カプセル化処理」の項で説明したように、カプセル化処理は、カプセル化対象として規定されたファイルを集めて、これらのファイルをポット・ファイル中に格納することで実装される。上述では、図１３を用いてカプセル化の規定の例を説明した。
図１３に示すカプセル化の規定にアクセス制御の規定を付加した例を、図３０に示す。図３０において、アクセス制御の規定を付加した記述例は、６１８（静的ファイル・セクション６１０の第４行から第６行）および６２８（動的ファイル・セクション６２０の第４行から第６行）に示されている。なお、行末の記号 "\" は、記述が次の行に続いていることを示す記号である。
【００５０】
図３０の６１８において、１行目は、上述で図１３を用いて説明したとおり、ローカル・ファイルである静的ファイル /home/user1/picture/picC.jpg が、ポット・ファイル中に /data/pic3.jpg のパス名で格納されることを規定している。そして、続く２行目・３行目でこのファイルのアクセス制御を規定している。２行目の read = {kato@orange.com, yosh@banana.com} は、このファイルの読み出し権を kato@orange.com と yosh@banana.com に与えることを示している。また、３行目の write = {kato@oragne.com} は、このファイルへの書き込み権をkato@orange.com に与えることを示している。
【００５１】
同様に、図３０の６２８において、１行目は、上述で図１３を用いて説明したとおり、動的ファイル /mybin/viewer_plugin3 のファイルは、ＵＲＬの http://www.foo.com/viewer_plugin3 で規定される位置から得るべきであることを規定している。そして、続く２行目・３行目でこのファイルのアクセス制御を規定している。２行目の read = {kato@orange.com, yosh@banana.com} は、このファイルの読み出し権を kato@orange.com と yosh@banana.com に与えることを示している。また、３行目の write = {kato@oragne.com} は、このファイルへの書き込み権をkato@orange.com に与えることを示している。
【００５２】
なお、図３０において、 "hybrid:" ６６２で示している混合ファイル・セクション６６０は、混合ファイルに関する規定の例である。混合ファイルとは、静的ファイルと動的ファイルの機能を合わせたものである。混合ファイルでは、ファイル実体の獲得として、静的ファイルに対応するものを一つ、動的ファイルに対応するものを一つまたは複数、指定する。ポット・ファイル作成時には、指定された静的ファイルに対応するファイル実体獲得に基づき、ファイル実体がポット・ファイルに格納される。そして、ポット・ファイル使用時には、指定された動的ファイルに対応するファイル実体獲得に基づき、ファイル実体の獲得を試みる。なお、動的ファイルに対応するファイル実体獲得法が複数ある場合は、優先度（例えば、記述されている順番に優先度が高いものとする）の順に従う。ファイル実体の獲得の試みが成功しないときは、静的ファイルとして格納されたファイル実体が使用される。
【００５３】
混合ファイル・セクション６６０の２行目から４行目に示す６６４は、動的ファイルとして "dynamic=" で指定した http://www.foo.com/viewer_pluginA_1 と http://www.foo.com/viewer_pluginA_2 の二つのファイル（左側に指定したものほど、優先度が高いとする）が、静的ファイルとして "static=" で指定したファイル http://www.foo.com/viewer_pluginA_1 が、混合ファイル /mybin/viewer_pluginA として登録される。
なお、図３０において上述で説明した以外の規定については、図１３と同様である。
【００５４】
（２）暗号技術を用いたアクセス制御
上述の（１）に示すようにアクセス制御の規定を記述することで、ポット・ファイルの作成者は、ファイル実体の読み出し権および書き込み権を持つユーザを指定することができる。ここで指定されたアクセス制御は、暗号技術を利用して実現される。
【００５５】
以降、図３１〜図３３を参照しながら、暗号技術を利用したアクセス制御について説明する。なお、本発明では、アクセス制御の実現に際し以下の二点を仮定しているものとする。
・ＰＫＩ（Public Key Infrastructure ；公開鍵暗号系基盤）を利用可能である。すなわち、指定されたユーザの正しい公開鍵を入手することができ、各ユーザは個々の公開鍵に対応する秘密鍵の秘密性を護持している。
・暗号化アルゴリズムは、特に断りがないときは、ＲＳＡアルゴリズムに代表される既存の公開鍵アルゴリズムを使用する。
【００５６】
本発明では、アクセス制御を実現するために、以下の方法１〜方法３に示す三つの方法を用いる。
方法１：単純公開鍵法によるアクセス制御
方法２：秘密鍵法によるアクセス制御
方法３：公開鍵技術を用いたｒｅａｄ／ｗｒｉｔｅ鍵法によるアクセス制御
以降、これらの三つの方法をそれぞれ順に説明する。
【００５７】
（方法１：単純公開鍵法によるアクセス制御）
方法１は、読み出し権のみを指定する場合に使用可能な方法である。方法１の単純公開鍵法によるアクセス制御の例を、図３１に示す。
図３１において、ポット・ファイル１９２０の作成者は、アクセスを制御したいファイル実体Ｆ（１９１０）の読み出し権を、ユーザＡ（１９７２）、ユーザＢ（１９７４）、ユーザＣ（１９７６）に与えるものとする。
【００５８】
この場合、ファイル実体Ｆ（１９１０）はユーザＡ，Ｂ，Ｃの公開鍵を用いて暗号化され、ポット・ファイル１９２０（静的ファイルの場合）、またはネットワーク上のサーバ（動的ファイルの場合）に格納される。図３１はこれらの暗号化されたファイルがポット・ファイル１９２０に格納される場合を示しており、ユーザＡの公開鍵を用いて暗号化されたファイル実体Ｆ（１９３２）、ユーザＢの公開鍵を用いて暗号化されたファイル実体Ｆ（１９３４）、ユーザＣの公開鍵を用いて暗号化されたファイル実体Ｆ（１９３６）が、ポット・ファイル１９２０に格納される。
そして、各ユーザがポット・ファイル１９２０を使用する際、ファイル実体Ｆは各ユーザの秘密鍵を用いて復号化される。例えば、ユーザＡの公開鍵を用いて暗号化されているファイル実体Ｆ（１９３２）が、ユーザＡの秘密鍵を用いて復号化される。この復号化により、各ユーザはファイル実体Ｆ（１９１０）を読み出すことができる。一方、読み出し権を与えられていないユーザは復号化を行なえないため、ファイル実体Ｆ（１９１０）の内容を読み出すことができない。
【００５９】
（方法２：秘密鍵法によるアクセス制御）
上述の方法１は、読み出し権を与えるユーザの数だけファイル実体を暗号化する必要があるため、大きな格納領域を必要とする場合がある。方法２は、方法１を改良したものであり、暗号化されたファイル実体の数を減らすことにより格納領域を節約することができる方法である。
方法２は、方法１と同様、読み出し権のみを指定する場合に使用可能な方法である。方法２の秘密鍵法によるアクセス制御の例を、図３２に示す。
図３２においては、方法１と同様に、ポット・ファイル１９２０の作成者は、アクセスを制御したいファイル実体Ｆ（１９１０）の読み出し権を、ユーザＡ（１９７２）、ユーザＢ（１９７４）、ユーザＣ（１９７６）に与えるものとする。
【００６０】
この場合、まず、秘密鍵暗号アルゴリズム（例えばＤＥＳアルゴリズムなど）用の秘密鍵Ｋ（１９４０）が生成され、秘密鍵Ｋと秘密鍵暗号アルゴリズムを用いてファイル実体Ｆ（１９１０）が暗号化される。次に、秘密鍵ＫがユーザＡ，Ｂ，Ｃの公開鍵を用いて暗号化される。これらの暗号化されたファイルは、ポット・ファイル１９２０（静的ファイルの場合）、またはネットワーク上のサーバ（動的ファイルの場合）に格納される。図３２はこれらの暗号化されたファイルがポット・ファイル１９２０に格納される場合を示しており、秘密鍵Ｋと秘密鍵暗号アルゴリズムを用いて暗号化されたファイル実体Ｆ（１９３０）、ユーザＡの公開鍵を用いて暗号化された秘密鍵Ｋ（１９４２）、ユーザＢの公開鍵を用いて暗号化された秘密鍵Ｋ（１９４４）、ユーザＣの公開鍵を用いて暗号化された秘密鍵Ｋ（１９４６）が、ポット・ファイル１９２０に格納される。
そして、各ユーザがポット・ファイル１９２０を使用する際、まず、秘密鍵Ｋが各ユーザの秘密鍵を用いて復号化される。例えば、ユーザＡの公開鍵を用いて暗号化されている秘密鍵Ｋ（１９４２）が、ユーザＡの秘密鍵を用いて復号化される。次に、秘密鍵Ｋを用いて暗号化されているファイル実体Ｆ（１９３０）が、秘密鍵Ｋと秘密鍵暗号アルゴリズムを用いて復号化される。この復号化により、各ユーザはファイル実体Ｆ（１９１０）を読み出すことができる。一方、読み出し権を与えられていないユーザは秘密鍵Ｋの復号化を行なえないため、ファイル実体Ｆ（１９１０）の内容を読み出すことができない。
【００６１】
（方法３：公開鍵技術を用いたｒｅａｄ／ｗｒｉｔｅ鍵法によるアクセス制御）
方法３は、一つのファイルについて、読み出し権のみを指定する場合にも、読み出し権と書き込み権の両方を指定する場合にも使用可能な方法である。方法３のｒｅａｄ／ｗｒｉｔｅ鍵法によるアクセス制御の例を、図３３に示す。
図３３において、ポット・ファイル１９２０の作成者は、アクセスを制御したいファイル実体Ｆ（１９１０）の読み出し権および書き込み権を、ユーザＡ（１９７２）とユーザＢ（１９７４）に、読み出し権のみをユーザＣ（１９７６）に与えるものとする。
【００６２】
この場合、まず、ファイル実体Ｆ（１９１０）に対して公開鍵アルゴリズム用の公開鍵・秘密鍵のペアが一組生成され、一方がｒｅａｄ鍵（１９５０）、他方がｗｒｉｔｅ鍵（１９６０）とされる。次に、ｗｒｉｔｅ鍵を用いてファイル実体Ｆ（１９１０）が暗号化される。そしてｗｒｉｔｅ鍵は、書き込み権を与えるユーザ（Ａ，Ｂ）の公開鍵を用いて暗号化される。一方、ｒｅａｄ鍵は、読み出し権を与えるユーザ（Ａ，Ｂ，Ｃ）の公開鍵を用いて暗号化される。これらの暗号化されたファイルは、ポット・ファイル１９２０（静的ファイルの場合）、またはネットワーク上のサーバ（動的ファイルの場合）に格納される。図３３はこれらの暗号化されたファイルがポット・ファイル１９２０に格納される場合を示しており、ｗｒｉｔｅ鍵を用いて暗号化されたファイル実体Ｆ（１９３０）、ユーザＡの公開鍵を用いて暗号化されたｒｅａｄ鍵（１９５２）およびｗｒｉｔｅ鍵（１９６２）、ユーザＢの公開鍵を用いて暗号化されたｒｅａｄ鍵（１９５４）およびｗｒｉｔｅ鍵（１９６４）、ユーザＣの公開鍵を用いて暗号化されたｒｅａｄ鍵（１９５６）が、ポット・ファイル１９２０に格納される。
【００６３】
そして、読み出し権を与えられている各ユーザ（Ａ，Ｂ，Ｃ）がポット・ファイル１９２０を使用する際、まず、ｒｅａｄ鍵が各ユーザの秘密鍵を用いて復号化される。例えば、ユーザＡの公開鍵を用いて暗号化されているｒｅａｄ鍵（１９５２）が、ユーザＡの秘密鍵を用いて復号化される。次に、ｗｒｉｔｅ鍵を用いて暗号化されているファイル実体Ｆ（１９３０）が、ｒｅａｄ鍵を用いて復号化される。この復号化により、読み出し権を与えられている各ユーザはファイル実体Ｆ（１９１０）を読み出すことができる。
また、書き込み権を与えられている各ユーザ（Ａ，Ｂ）がファイル実体Ｆへの書き込みを行なう場合には、まず、ｗｒｉｔｅ鍵が各ユーザの秘密鍵を用いて復号化される。そして、書き込み後のファイル実体Ｆは、ｗｒｉｔｅ鍵を用いて暗号化される。
【００６４】
読み出し権を与えられていないユーザはｒｅａｄ鍵の復号化を行なえないため、ファイル実体Ｆ（１９１０）の内容を読み出すことができない。また、書き込み権を与えられていないユーザはｗｒｉｔｅ鍵の復号化を行なえないため、ソフトウェア・ポット・システムによって書き込み権がないことを検出される。たとえソフトウェア・ポット・システムを不正に操作して書き込みを行なおうとしても、ファイル実体Ｆの暗号化を正しく行なえないために、不正な書き込みは読み出し権を与えられたユーザによって検出される。
【００６５】
（ファイルのアクセス制御機能の効果）
上述のアクセス制御機能を用いることにより、特定のユーザに対してファイルへのアクセス権（読み出し権・書き込み権）を与えることを、アプリケーションに透明に（すなわち、アプリケーションに意識させずに）実現することができる。
さらに、上述のアクセス制御機能は暗号技術を用いているため、仮にアクセス権を与えられていないユーザが不当にソフトウェア・ポット・システム自体の改変を行なったとしても、改変されていない他のソフトウェア・ポット・システムは正しくアクセス制御を行なうことができる（すなわち、読み出し／書き込み権をもつユーザのみが読み出し／書き込みを行なえる）。
また、上述の方法３によれば、仮に不正な書き込み（改変）を行なったファイルを流通させようとしても、正常なソフトウェア・ポット・システムがその改変を検知することができる。すなわち、アクセス権のないユーザが不正な書き込み（改変）を行なったファイルを流通させようとした場合、そのファイルを読み出し権を与えられたユーザが読み出す際に、不正な改変が検知される。
【００６６】
また、ポット・ファイルの作成者が、アドホックにユーザグループを構成し、そのユーザグループ内でアクセス制御を設けたグループウェア処理を行なうことができる。このとき、既存のシングルユーザ用アプリケーション自体に全く手を加える事なく、グループウェア処理を行なうことができる。
【００６７】
【発明の効果】
上述したような構成により、ソフトウェア流通に適した、安全にソフトウェアを実行する機構を提供することができる。
【００６８】
【図面の簡単な説明】
【図１】ソフトウェア流通の４つの基本処理を示す図である。
【図２】ソフトウェア配布を示す図である。
【図３】自己解凍の転送を示す図である。
【図４】ワークフローを示す図である。
【図５】モバイル・エージェントを示す図である。
【図６】実施形態の安全なソフトウェア流通の４つの基本処理を示す図である。
【図７】典型的なソフトウェア流通モデルを示す図である。
【図８】ディレクトリ等のマッピングを示す図である。
【図９】ダウンロードされたコードの解釈実行を示す図である。
【図１０】動的に生成されたコードの実行を示す図である。
【図１１】モバイル・エージェントの実行を示す図である。
【図１２】ワークフローの処理を示す図である。
【図１３】カプセル化の規定の例を示している。
【図１４】動的ファイル転送を示す図である。
【図１５】ファイル構成を示す図である。
【図１６】実装スキームの例を示す図である。
【図１７】マッピングおよび実行の規定例を示す図である。
【図１８】名前変換の実装例を示す図である。
【図１９】モニタのフォークの実装例を示す図である。
【図２０】安全なソフトウェア流通形態を示す図である。
【図２１】ファイル登録の処理を示すフローチャートである。
【図２２】ファイル登録処理における画面例を示す図である。
【図２３】セキュリティ・ポリシーの登録処理を示すフローチャートである。
【図２４】セキュリティ・ポリシー登録処理画面を示す図である。
【図２５】セキュリティ・ポリシー登録処理画面を示す図である。
【図２６】ファイル検索の処理を示すフローチャートである。
【図２７】ファイル検索の処理画面を示す図である。
【図２８】ファイル検索の処理画面を示す図である。
【図２９】ファイル検索の処理画面を示す図である。
【図３０】カプセル化の規定にアクセス制御を指定する例を示している。
【図３１】単純公開鍵法によるアクセス制御の例を示す図である。
【図３２】秘密鍵法によるアクセス制御の例を示す図である。
【図３３】ｒｅａｄ／ｗｒｉｔｅ鍵法によるアクセス制御の例を示す図である。
【図１】
0004522705.tif 000004
【図２】
0004522705.tif 000005
【図３】
0004522705.tif 000006
【図４】
0004522705.tif 000007
【図５】
0004522705.tif 000008
【図６】
0004522705.tif 000009
【図７】
0004522705.tif 000010
【図８】
0004522705.tif 000011
【図９】
0004522705.tif 000012
【図１０】
0004522705.tif 000013
【図１１】
0004522705.tif 000014
【図１２】
0004522705.tif 000015
【図１３】
0004522705.tif 000016
【図１４】
0004522705.tif 000017
【図１５】
0004522705.tif 000018
【図１６】
0004522705.tif 000019
【図１７】
0004522705.tif 000020
【図１８】
0004522705.tif 000021
【図１９】
0004522705.tif 000022
【図２０】
0004522705.tif 000023
【図２１】
0004522705.tif 000024
【図２２】
0004522705.tif 000025
【図２３】
0004522705.tif 000026
【図２４】
0004522705.tif 000027
【図２５】
0004522705.tif 000028
【図２６】
0004522705.tif 000029
【図２７】
0004522705.tif 000030
【図２８】
0004522705.tif 000031
【図２９】
0004522705.tif 000032
【図３０】
0004522705.tif 000033
【図３１】
0004522705.tif 000034
【図３２】
0004522705.tif 000035
【図３３】
0004522705.tif 000036